Behaviors must be dynamic, and human experience shows that human associations of behaviors with attributes also change with time. In the 1930s, people with tattoos were usually categorized as belonging to the sailor class. In the 1980s, tattoos were generally categorized as belonging to the criminal class, while today, tattoos are also indicative of the college_student class of humans. The ODMG object model partially addressed this issue, whereby objects are assigned lifetimes by the object-oriented database system. Unfortunately, the concept of object lifetimes has not been included in Oracle8.

Humans are also familiar with the concept of abstraction. Intangible objects such as time are easily understood, and the conceptual, nonconcrete existence of time has meaning to most individuals.

The distinguishing characteristic of the object-oriented database is its ability to store data behavior, but how is the behavior of the data incorporated into the database? At first glance, this may seem to be a method for moving application code from a program into a database. While it is true that an object-oriented database stores “behaviors,” these databases must also have the ability to manage many different objects—each with different data items.

The “ISA” Relationship

The ISA relationship (pronounced “is a”) is a data relationship that indicates a type/subtype data relationship. While traditional E/R modeling deals only with single entities, the ISA approach recognizes that many “types” or classes of an individual entity may exist. In fact, the ISA relationship is the foundation of object-oriented programming, which allows the designer to create hierarchies of related classes and then use inheritance and polymorphism to control which data items will participate in the low-level objects.

After establishing a class hierarchy with the Entity/Relation model, the object-oriented principle of generalization is used to identify the class hierarchy and the level of abstraction associated with each class. Generalization implies a successive refinement of the class, allowing the superclasses of objects to inherit the data attributes and behaviors that apply to the lower levels of the class. Generalization establishes “taxonomy hierarchies,” which organize the classes according to their characteristics in increasing levels of detail. These hierarchies begin at a very general level, proceeding to a specific level, with each sublevel having its own unique data attributes and behaviors.

In Figure 2.11, the ISA relationship is used to create a hierarchy within the CUSTOMER and ORDER entities, and all of the lower-level classes will inherit the data items and behaviors from the “base” classes. The ISA relationship is used to model the hierarchy, which is created as the class entity is decomposed into its logical subcomponents. Customers may be preferred_customers or new_customers, and orders may be cod_orders or prepaid_orders, each with their own data items and behaviors. Those data items that are generic to customers and orders would reside in the CUSTOMER and ORDER entities, while the data items that are unique to preferred_customers (such as percent_discount) would reside in the lower-level entities.

Figure 2.11  An entity/relation model with added “ISA” relationships.

Let’s look at an application of the ISA relationship for a vehicle dealership as shown in Figure 2.12.

Figure 2.12  A sample class hierarchy.

As you can see, the highest level in the hierarchy is VEHICLEs; and beneath the VEHICLE class, we may find subclasses for CARs and for BOATs. Within CARs, the classes may be further partitioned into classes for TRUCK, VAN, and SEDAN. The VEHICLE class would contain the data items that are unique to vehicles, including the vehicle ID and the year of manufacture. The CAR class, because it ISA VEHICLE, would inherit the data items of the VEHICLE class. The CAR class might contain data items such as the number of axles and the gross weight of the vehicle. Because the VAN class ISA CAR, which in turn ISA VEHICLE, objects of the VAN class will inherit all data items and behaviors relating to CARs and VEHICLEs.

These types of ISA relationships, while valid from a data modeling viewpoint, do not have a simple implementation in Oracle. Since Oracle does not support hierarchical relationships, it is impossible to directly represent the fact that a database entity has subentities. However, we can model this type of relationship in a relational database in two ways.

The first technique is to create subtables for car, boat, sedan, and so on. This encapsulates the data items within their respective tables, but it also creates the complication of doing unnecessary joins when retrieving a high-level item in the hierarchy. For example, the following SQL would be required to retrieve all of the data items for a luxury sedan:

SELECT
        VEHICLE.vehicle_number,
        CAR.registration_number,
        SEDAN.number_of_doors,
        LUXURY.type_of_leather_upholstery
FROM
        VEHICLE,
        CAR,
        SEDAN,
        LUXURY
WHERE
VEHICLE.key = CAR.key
AND
CAR.key = SEDAN.key
AND
SEDAN.key = LUXURY.key;

The second approach is to create a megatable in Oracle with each data item represented as a column, regardless of whether or not it is needed by the individual row. A “type” column would be used to identify if the row represents a car, a van, or a sailboat; and the application must have intelligence to access only those columns that are applicable to the row. For example, the sail-size column may have meaning for a sailboat row, but would be irrelevant to a sedan row.

The ISA relationship is best suited to the object-oriented data model, where each level in the hierarchy has associated data items and methods, and inheritance and polymorphism can be used to complete the picture. It is important to note that not all classes within a generalization hierarchy will be associated with objects. These “non-instantiated” classes only serve the purpose of passing data definition to the lower-level classes. The object-oriented paradigm allows for abstraction, which means that a class may exist only for the purpose of passing inherited data and behaviors to the lower-level entities. The classes VEHICLE and CAR would probably not have any concrete objects, while objects within the VAN class would inherit from the abstract VEHICLE and CAR classes.