Datasheet

9
Chapter 1 ✦ The Information Architecture Principle
Table 1-2: Comparing Database Terms
Development Style The Common List An Item in the List A Piece of Information in the List
Spreadsheet Spreadsheet/ Row Column/cell
worksheet/
named range
Historic information File Record Field
Relational algebra/ Entity Tuple (rhymes Attribute
logical design with couple) or
Relation
SQL/physical design Table Row Column
Object-oriented analysis Class Object instance Property
and design
Because the OO DBMSs must store objects, a key criterion for an OO DBMS is that it must be
able to store complex objects, such as XML files, or .NET classes.
OO DBMSs are suitable for applications that expect significant schema change, include com-
plex data types, involve several is-a relationships between classes, include complex multi-
associations, and require ease of data connectivity with application software.
There are three primary types of object-oriented databases:
✦ An object-persistence data store (OP DBMS) is designed to be little more than a reposi-
tory for object states. All integrity issues are handled by the object-oriented applica-
tion code, and the database schema is designed to map perfectly with the application’s
class diagram.
✦ An object-oriented data store (OO DBMS) persists application objects and uses metadata
(data that describes the way data is organized) to model the object-oriented class
structure and enforce object-class integrity.
✦ An object/relational data store (O/R DBMS) persists the application objects, and models
the class structure within a relational DBMS. O/R DBMSs provide the benefits of OO A/D
with the traditional query and reporting ability of relational databases.
For more information about Nordic (New Object Relational Database Design), by the author,
visit www.SQLServerBible.com.
Generic Pattern DBMS
The generic pattern database, sometimes called the dynamic-diamond pattern, illustrated in
Figure 1-2, is sometimes used as an OO DBMS physical design within a RDBMS product. This
design can be useful when applications require dynamic attributes. A manufacturing material-
specifications system, for example, would require different attributes for nearly every mate-
rial type. To further complicate matters, the attributes that are tracked frequently change
depending on the Total Quality Management (TQM) or ISO 9000 process within the company.
A purely relational database might use an entity for each material type, requiring constant
schema changes to keep current with the material tracking requirements.
Note
05_542567 ch01.qxp 9/27/06 9:58 PM Page 9