What Is a Data Access Layer?

Article Details
  • Written By: T.S. Adams
  • Edited By: C. Wilborn
  • Last Modified Date: 10 September 2019
  • Copyright Protected:
    Conjecture Corporation
  • Print this Article
Free Widgets for your Site/Blog


A data access layer (DAL) is a specific portion of every computer program which facilitates access between the program and any type of persistent storage. Programs are any applications running on the computer; persistent storage refers to any permanent storage location on the computer, such as the hard drives. While they are running, programs are constantly writing and reading information to and from the hard drive. The data access layer's function is to ensure that any program running on the system is able to get the information it needs as soon as it needs it.

Like a middleman or supplier in a business relationship, the data access layer stands between the program and the storage device. Each program running on the computer which needs to access information on the hard drive has working data access layers. Instead of the main body of the program communicating directly with the persistent storage location, it delegates the responsibility to the data access layer, which then acts on the program's behalf to carry out the task. Its only "job" is to shuffle information back and forth, freeing up the rest of the program to accomplish its other responsibilities.


A typical example of a functioning layer of data access involves a program which requires external information to operate; in other words, information that the program does not intuitively possess. For example, if a program is trying to calculate changes in a company's profit margin over the past 10 years, that information is unlikely to exist within the actual program. It will exist within a company financial records database, however. As the program realizes that it requires "Financial Statement X" or "Earnings Report Y," it tells the data access layer to find that information. The data access layer then siphons the necessary information from the appropriate database or table, returning it to the program so it can continue operating.

Some programs that use a data access layer are database dependent; this means that they are designed to work with one specific database type, limiting their transferability. Others are database independent, providing the ability to function with a wider range of database software. Although it might seem as though dependent data access layer programs are less useful, that is not necessarily the case. As they are programmed to work with one kind of database, they are likely to be optimized more efficiently, providing faster performance while functioning with the intended type of database system.


You might also Like


Discuss this Article

Post 4

@David09 - Just from the looks of it, it appears that a DAAL is like a cache. A cache is local storage of commonly accessed information. I see the DAAL operating the same way, pulling data into memory where it can be juggled around more easily.

Post 3

@Mammmood - You’ll find that each database platform has its own providers for the data access layer.

I know nothing about SQL Server but I did work in an all Oracle shop once. We built applications with Oracle forms. Oracle had its own data access layer, and a provider to enable it to work with the Oracle database.

I do believe it was more efficient than a generic provider. Microsoft is supposed to be able to work with Oracle as well but I don’t think it works as well. However, I haven’t done any benchmark tests.

I say it depends on your purposes. If you are only targeting one platform then don’t worry about generic providers for your data access layer. Use the database’s proprietary provider. It should work better in most cases.

Post 2

@miriam98 - I’m fairly new to all this stuff. My background is old school Visual FoxPro, where the application and the database were basically tied together. There was no data access object as such, at least not one that I was aware of. The program hit the database directly.

Then my company started transitioning into .NET, Microsoft’s programming platform. I was introduced to the data access layer .NET design pattern.

They say the whole concept is to fetch the data and work with it locally, so as not to tie up the server by being constantly connected. This is supposed to help in multiuser arrangements with a whole bunch of people hitting the database at the same time.

They can fetch what they need, update it and then send it back to the server. I suppose I understand that but it takes some getting used to, for me at least.

Post 1

I work at a software company and we use data access layers in our software products. I would have to say that the kind of layer that I use is “independent.”

What that means is that it can work with different databases. For example, the data can reside in Oracle, Sybase or SQL Server databases. Our program doesn’t care either way. It fetches the data from where it’s stored, manipulates it and then sends it back to the target database.

Is this method less optimized as the article says? I honestly don’t know. Perhaps it is, but we haven’t noticed any noticeable deterioration in performance. The data access layer design pattern we work with seems to do a good enough job for our purposes.

Post your comments

Post Anonymously


forgot password?