To meet its goal of providing data access to all types of data in a COM environment, OLE DB is designed as a component technology. Data sources expose the interfaces that reflect their functionality, and common components can be built on top of those interfaces to expose more robust data models. OLE DB creates components by identifying common characteristics among different data providers and services, and defining common interfaces to expose those characteristics. So, for example, while a rowset can be obtained through a number of very different mechanisms, the end result is still a rowset with well-defined interfaces, methods, and characteristics. Navigating the results of a complex multitable join is no different from navigating the results of a text file containing tabular data. Defining common interfaces in this manner allows components to more efficiently augment the individual data provider's native functionality.
An OLE DB provider exposes OLE DB interfaces over some type of data. OLE DB providers include everything from a full SQL DBMS to an ISAM file to a text file or data stream. Obviously, these types of data providers have different functionality, and it's important not to limit that functionality. But at the same time it's not reasonable to expect all providers that expose simple tabular data to implement a full-blown query engine. Instead of looking at the differences between providers, OLE DB looks at the similarities and defines the common interfaces used to expose those similarities.
Once the base functionality is defined, the next step is to view the additional functionality as incremental additions to this base functionality. Thus, the more sophisticated providers can expose these advanced features in addition to the base-level interfaces. Furthermore, individual service components can be built to implement these features on top of the simpler providers.