The Web Server Environment - Database Processing: Fundamentals, Design, and Implementation - page 451

forth. But, unlike relations, they are not all of the same type. Some addresses are for individuals;
others are for mailing lists. Thus, any action on a recordset that depends on everything in the
recordset being the same kind of thing cannot be used on a rowset.
Working from the top down, OLE DB defines a set of data properties and behaviors for
rowsets. Every rowset has those properties and behaviors. Furthermore, OLE DB defines a
recordset as a subtype of a rowset. Recordsets have all of the properties and behaviors that
rowsets have, plus they have some that are uniquely characteristic of recordsets.
Abstraction is both common and useful. You will hear of abstractions of transaction
management or abstractions of querying or abstractions of interfaces. This simply means that
certain characteristics of a set of things are formally defined as a type.
An object-oriented programming object is an abstraction that is defined by its properties
and methods. For example, a recordset object has an AllowEdits property and a RecordsetType
property and an EOF property. These properties represent characteristics of the recordset
abstraction. An object also has actions that it can perform that are called methods . A
recordset has methods such as Open, MoveFirst, MoveNext, and Close. Strictly speaking, the
definition of an object abstraction is called an object class or just a class. An instance of an
object class, such as a particular recordset, is called an object . All objects of a class have the
same methods and the same properties, but the values of the properties vary from object
to object.
The last term we need to address is collection . A collection is an object that contains a
group of other objects. A recordset has a collection of other objects called Fields. The collec-
tion has properties and methods. One of the properties of all collections is Count, which is
the number of objects in the collection. Thus, recordset.Fields.Count is the number of fields
in the collection. In OLE DB, collections are named as the plural of the objects they collect.
Thus, there is a Fields collection of Field objects, an Errors collection of Error objects, a
Parameters collection of Parameters, and so forth. An important method of a collection is an
iterator, which is a method that can be used to pass through or otherwise identify the items
in the collection.
Goals of OLE DB
The major goals for OLE DB are listed in Figure 11-12. First, as mentioned, OLE DB breaks
DBMS functionality and services into object pieces. This partitioning means great flexibility
for both data consumers (users of OLE DB functionality) and data providers (vendors of
products that deliver OLE DB functionality). Data consumers take only the objects and func-
tionality they need; a wireless device for reading a database can have a very slim footprint.
Unlike with ODBC, data providers need only implement a portion of DBMS functionality. This
partitioning also means that data providers can deliver capabilities in multiple interfaces.
This last point needs expansion. An object interface is a packaging of objects. An inter-
face is specified by a set of objects and the properties and methods that they expose. An object
need not expose all of its properties and methods in a given interface. Thus, a recordset object
would expose only read methods in a query interface, but would expose create, update, and
delete methods in a modification interface.
How the object supports the interface, or the implementation , is completely hidden
from the user. In fact, the developers of an object are free to change the implementation when-
ever they want. Who will know? But they may not ever change the interface without incurring
the justifiable disdain of their users!
OLE DB defines standardized interfaces. Data providers, however, are free to add inter-
faces on top of the basic standards. Such extensibility is essential for the next goal, which is to
provide an object interface to any data type. Relational databases can be processed through
OLE DB objects that use ODBC or that use the native DBMS drivers. OLE DB includes support
for the other types as indicated.
The net result of these design goals is that data need not be converted from one form to
another, nor need they be moved from one data source to another. The Web server shown in
Figure 11-11 can utilize OLE DB to process data in any of the formats, right where the data
reside. This means that transactions may span multiple data sources and may be distrib-
uted on different computers. The OLE DB provision for this is the Microsoft Transaction
Manager (MTS); however, discussion of the MTS is beyond the scope of this text.