Data Layer is mainly a set of Data Access Logic Components(logic to access data from your data store),Helper/Utilities(for manipulation/transformation), Service Agents( when you are using external service that help to shape your database to application needs).

In Business Logic, you are going to design business entities(like customer, supplier etc)  thats represents custom objects  required by your application which are needed to be mapped to your data. So if you are going for Domain Driven Design, you are going to have entities, values(domain properties), aggregate roots(set of entities that group related child entities), Repositories(responsible for retrieving/storing aggregate roots) and domain services(business process).

Check following link for the source of above paragraph

Now main job of DAL involves around connections, queries and mapping above entities to real data structure in your database. I suggest you to look at ADO.NET Entity Framwork  to find about a new technology available to access database.  Business Logic contains entities(for eg. Customer Class), which are similar to DAO objects(create in DAL) but customized with business needs with business workflows and business components. 

So you have to create DAO classes in Data Access Layer which are consumed by your business logic to create business entities. This might create a problem of dependency, the way entities are created shows data access layer and business layer are tightly coupled and dependant of each other. To save yourself from this circular reference you can use a technique called Inversion of Control where you depend on separated interfaces to communicate. Following article discuss about it in more detail(though the article may not look relevant to you at first but might be useful):

I strongly suggest you to read "Pattern of Enterprise Application Architecture" written by Martin Flower if you want to understand all these things in more