Database Reference
In-Depth Information
Relational Databases:
Oracle Database,
Microsoft SQL Server,
MySQL, Microsoft Access,
IBM DB2 . . .
Native
Interfaces
DBMS
Nonrelational
Databases
ODBC
Browser
O
L
E
VSAM, ISAM,
Other File
Processors
D
B
Web
Server
Browser
E-mail, Other
Document Types
Browser
Pictures, Audio,
Other????
Figure 11-11
the role of OLE DB
through this interface. OLE DB can also be used as an interface to ODBC data sources. Finally,
OLE DB was developed to support the processing of nonrelational data as well.
OLE DB is an implementation of the Microsoft Object Linking and Embedding (OLE)
object standard. OLE DB objects are Component Object Model (COM) objects and support all
required interfaces for such objects. Fundamentally, OLE DB breaks up the features and func-
tions of a DBMS into COM objects. Some objects support query operations; others perform
updates; others support the creation of database schema constructs, such as tables, indexes,
and views; and still others perform transaction management, such as optimistic locking.
This characteristic overcomes a major disadvantage of ODBC. With ODBC, a vendor must
create an ODBC driver for almost all DBMS features and functions in order to participate in
ODBC at all. This is a large task that requires a substantial investment. With OLE DB, however, a
DBMS vendor can implement portions of a product. One could, for example, implement only the
query processor, participate in OLE DB, and hence be accessible to customers using ADO.NET.
Later, the vendor could add more objects and interfaces to increase OLE DB functionality.
This text does not assume that you are an object-oriented programmer, so we need to
develop a few concepts. In particular, you need to understand objects, abstractions, properties,
methods, and collections. An abstraction is a generalization of something. ODBC interfaces
are abstractions of native DBMS access methods. When we abstract something, we lose detail,
but we gain the ability to work with a broader range of types.
For example, a recordset is an abstraction of a relation. In this abstraction, a recordset is
defined to have certain characteristics that will be common to all recordsets. Every recordset,
for instance, has a set of columns, which in this abstraction is called Fields. Now, the goal of
abstraction is to capture everything important but to omit details that are not needed by users
of the abstraction. Thus, Oracle relations may have some characteristics that are not repre-
sented in a recordset; the same might be true for relations in SQL Server, in DB2, and in other
DBMS products. These unique characteristics will be lost in the abstraction, but if the abstrac-
tion is a good one, no one will care.
Moving up a level, a rowset is the OLE DB abstraction of a recordset. Now, why does OLE
DB need to define another abstraction? Because OLE DB addresses data sources that are not
tables but that do have some of the characteristics of tables. Consider all of the e-mail addresses
in your personal e-mail file. Are those addresses the same as a relation? No, but they do share
some of the characteristics that relations have. Each address is a semantically related group of
data items. Like rows of a table, it is sensible to go to the first one, move to the next one, and so
 
Search WWH ::




Custom Search