Object-Oriented Database Design Clearly Explained / Edition 1

Chapter 1: Introduction

In this chapter, you will find an overview of the history of data modeling so that you will understand why the object-oriented data model is both a step forward and a step backward. You will also be introduced to the two ways in which objects have been integrated into the data model and read an overview of current uses for object-oriented databases.

A Short History of Data Modeling

The Hierarchical Data Model

The hierarchical data model, which was implemented primarily by IBM's Information Management System (IMS), allows only one-to-one or one-to-many relationships between entities. Any entity at the "many" end of a relationship can be related to only one entity at the "one" end.

As an example, take a look at Figure 1-1. This ER diagram represents two relationships between Product and Vendor entities. The first is a many-to-many relationship indicating which vendor can supply which product. The second is orders placed for products with specific vendors.

The many-to-many relationshipthat represents the products sold by a vendor requires a composite entity to contain the price charged by the vendor for that specific product. Logically, this entity Catalog Entry in Figure 1-1-is related to both the Product and Vendor entities. However, the hierarchical data model forbids this type of multiple parentage.

Note: To be strictly correct, IMS does allow multiple parentage in some limited instances, in particular when the parent entity types are in different hierarchies. There are, however, significant restrictions on exactly where this can be used.

One solution is to duplicate the entity, as was done in Figure 1-1. Alternatively, you could relate an entity to only one of its two parents, the solution used to handle the Product to Order to Order Item relationships in Figure 1-1.

Neither solution is optimal. The duplicated Catalog Entry entities introduce possible problems with data consistency. The single Order and OrderItem entities cut down on the type of access provided by the database.

Hierarchical databases are navigational. That means that data access is only through the predefined relationships. In addition, access to a hierarchy is typically through the entity at the top of the hierarchy (the root) and must proceed in hierarchical order. For example, to reach an instance of the Order Line entity, an application program must first find the appropriate instance of the Product entity and then traverse all Order instances related to that Product until the correct product is found. Then the program can access the OrderItem instances related to that Order. In a hierarchy, direct access to data is very limited, if available at all.

Using the two hierarchies in Figure 1-1, there is no reasonable way to answer the question "From which vendor did we order that specific product?" The only way to complete that query would be to search from the Product to the Order to the OrderItem to find all instances in which the product was ordered. Then an application would need to search the Catalog Entry instances in the second hierarchy to find the vendor.

The benefit of a hierarchical database is that its navigational nature makes access very fast when you are following the predefined relationships. However, the rigidity of the data model-in particular, the inability to give an entity multiple parents and the absence of direct data access-makes it unsuitable for environments where ad hoc queries are important.

IMS is still in use today in some legacy mainframe systems. However, IBM no longer sells the product and encourages its customers whenever possible to migrate to a relational DBMS.

The Network Data Models

Long before computer networks came to the forefront of our consciousness, database designers created two data models that represented networks of data relationships: the simple network data model and the complex network data model. The intent of these data models was to eliminate the restrictions placed on databases by the hierarchical data model.

The Simple Network Data Model

In a simple network database, all relationships are one-to-one or one-to-many-direct many-to-many relationships are not allowed-but multiple parentage is permitted. As you can see in Figure 1-2, allowing multiple parentage eliminates the problems with unnecessary duplicated data and access restrictions.

Simple network databases are nonetheless navigational: Most access is through the predefined relationships. Some direct access to instances of entities is supported through hashing, but because hashing affects the physical placement of data in a data file, in a practical sense only one entity in a hierarchy of entities can be given a hashed fast access path. For example, in the Product and Vendor database that we have been using as an example, the Product and Vendor entities could be stored using hashing to provide direct access to instances of those entities. However, the remaining entities would probably be accessible only through their parents.

Note: Hashing is a technique in which a key value (much like the primary key of a relation) is put through a transformation process (a hashing algorithm) to generate a location for the instance of an entity in a data file. When the user supplies the key value, the DMBS can recompute the hash value and use it to access the data directly. This is a very fast form of access.

Simple network databases therefore perform well when access follows the relationships but perform poorly if manual searches that are not based on hash keys or predefined relationships must be coded into an application program. Depending on the design of the database, ad hoc queries can be very difficult to satisfy.

Note: As relational databases began to supplant simple networks, many people designed their simple networks as if they were relational including foreign keys in related entities. As a result, some vendors of simple network DBMSs were able to add ad hoc query languages to their products to allow ad hoc querying in a "relational-like" manner. However, this worked well only if the database design was normalized.

The national standard for the simple network data model was initially proposed by the Database Task Group (DBTG) or the Committee on Data Systems Languages (CODASYL), the same committee that developed COBOL. Although some legacy databases based on the CODASYL standard are still in use, few new CODASYL databases are being installed at this time.

The Complex Network Data Model

The complex network data model is similar to the simple network, but it allows the direct implementation of many-to-many relationships. As an example, consider Figure 1-3, which contains a many-to-many relationship. The many-to-many relationship is between employees and children; the second relationship in the diagram is a one-to-one relationship indicating who is married to whom. As long as there are no relationship data, the direct many-to-many relationship in this case presents no problems and eliminates the need for a composite entity that serves only to represent a relationship. However, when there are relationship data, even a complex network database must include the composite entity. In addition, as you will see in Chapter 3, there are situations in which a direct many-to-many relationship actually causes the database to lose information. There have been no commercially successful complex network DBMSs, primarily because the many-to-many relationships become very complicated and nearly impossible to maintain. This data model therefore is of theoretical interest only and generally continues to exist only in college database textbooks....