Why OLE DB?

OLE DB exists to provide a uniform way to access all sorts of disparate data sources. For example, imagine all the types of data sources you might find in a typical organization. These might include sources as varied as production systems, file systems, spreadsheets, personal databases (such as Xbase and Btrieve), and e-mail. The problem is that each of these sources requires its own protocol: if you want to access data from a specific source, you need to learn the protocol for managing the data source. (ugh!) OLE DB is the middle layer that makes accessing data from different sources uniform. With OLE DB, client-side developers need to concentrate on only a few details to get access to data (instead of needing to know tons of different database access protocols).

The most important thing to realize about OLE DB is that it is built upon COM. In other words, OLE DB is a set of ActiveX interfaces for accessing data through COM. The OLE DB interfaces are general enough to provide a uniform means of accessing data, regardless of the method that is used to store the data. For example, developers use the same OLE DB interfaces to get to data without being concerned as to whether data is stored in a DBMS or a non-DBMS information source. At the same time, OLE DB lets developers continue to take advantage of the benefits of the underlying database technology (like speed and flexibility) without having to move data around just to access those benefits.

At the highest level, the OLE DB architecture consists of consumers and providers. A consumer is any bit of system or application code that uses an OLE DB interface. This includes OLE DB components themselves. A provider is any software component that exposes an OLE DB interface.

There are two types of OLE DB providers: data providers and service providers. The names are pretty self-explanatory. Data providers own data and expose that data in a tabular form as a rowset. (A rowset is just an abstraction for exposing data in a tabular form.) Some good examples of data providers include relational Database Management Systems (DBMS's), storage managers, spreadsheets, and Indexed Sequential Access Method (ISAM) databases.

A service provider is any OLE DB component that does not own data but encapsulates some service by massaging data through OLE DB interfaces. In one sense, a service component is both a consumer and a provider. For example, a heterogeneous query processor is a service component. In one case where a consumer tries to join data from tables in two different data sources, as a consumer the query processor retrieves rows from rowsets created over each of the base tables. As a provider, the query processor creates a rowset from these rows and returns it to the consumer.

To sum up, there are many different kinds of data and numerous ways of accessing that data in the real world. However, many developers understand how to manipulate data using standard database-management techniques. OLE DB defines an architecture that "component-izes" data access. As a component database-management system, OLE DB offers greater efficiency than traditional database-management systems by separating database functionality into the roles of consumers and producers. Because data consumers generally require only a portion of the database-management functionality, OLE DB separates that functionality, thereby reducing client-side resource overhead.

By the same token, OLE DB reduces the burden on the provider side, since providers need to worry only about providing data (and don't have to concern themselves with any client-side junk). For example, OLE DB allows a simple tabular data provider to implement functionality native to its data store yet provide a singular access protocol to get to the data. That way, a minimal implementation of a provider can choose to use only the interfaces that expose data as tables. This opens up the opportunity for the development of completely different query-processor components that can consume tabular information from any provider that exposes its data through OLE DB. In addition, SQL DBMS's can expose their functionality in a more layered manner by using the OLE DB interfaces.



Programming Microsoft Visual C++
Programming Microsoft Visual C++
ISBN: 1572318570
EAN: 2147483647
Year: 1997
Pages: 332

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net