Industry literature is rife with articles describing 3-tier architectures, with something called a "data tier"  represented as a single database. And to many people, "Data Access" is equivalent to "Database Access." Though most data access involves a client accessing a database through technologies such as ADO, JDBC or ODBC, data access implies a much more flexible approaching to retrieving data from data "stores."

Tying a mission-critical application architecture to a single source of data can be a very dangerous form of myopia. Suppose an application begins as a manipulation of a single SQL Server database. Suddenly, the decision makers in the business want access to email stores contained in an Exchange server, or perhaps the application needs to access the enterprise Oracle server as well. If you make the business objects understand the nuances of connecting to Exchange to retrieve data, what happens if another email package is adopted?

Microsoft has made significant advances in the field of data access, primarily through its development of OLE DB. Using this COM-based technology, every data store "looks" the same to the client using the OLE DB interfaces. It is interesting to think of Exchange, SQL Server, Excel spreadsheets and even text files having similar characteristics in terms of storing and retrieving data. Because anyone can implement the OLE DB Provider interfaces, almost any conceivable type of data store could be accessed in the same manner. And, since ADO can access OLE DB, the ADO objects become a well-known, flexible mechanism to retrieve data from many diverse data sources.

My interests in the data tier run the full gamut of data access tasks, because data access is often the most computationally-intensive part of an application. From optimizing database access to providing flexible ways of accessing diverse data stores to business-tier objects, the data tier has required the most knowledge, sophistication and challenge in most of the projects I've been involved in.