With respect to your needing to reference the business layer from the DAL, I would agree that this is probably not optimal -- lower tiers should not know about the ones above them, it reduces reusability and adds extra/potentially circular dependencies.
Have you considered having your business entities "fill themselves up" and do their own persistence operations using the DAL classes, rather than the DAL acting like a factory for them (as in your current design)? That way, your DAL would be a more direct representation of the database, and the business entities would contain the (business) logic needed to fill and persist themselves appropriately.
Also, the "BLL" layer you spec out doesn't really appear to me to contain business logic; it looks to me to be more of a persistence services layer for the entities.
So a variation of what you propose could be:
- Web/UI, referencing Business Entities
- BusinessEntities, contains interfaces and classes with business logic. References DataServices layer
- DataServices, contains classes that load, find and persist data. Can serve up "generic" structures containing the data (Data Transfer Objects) that can be produced, consumed and processed by Business Entities. References DAL.
- DAL, which simply provides classes that map to tables.
Depending on your requirements, I would consider merging your BusinessEntities and DataServices (BLL in your original design) into a single tier; the only reason I can think of to split them apart is if you are doing something like Silverlight where you need asynchronous data operations on client-side business entities.
Of course all of this is with an incomplete knowledge of your specific system requirements -- you will need to design what is best for your specific application. Good luck!