9.10 Chapter Summary
Object-oriented (OO) databases allow database designers and developers to express complex data structures, operations, and relationships more naturally than traditional relational databases. OO programming languages, including C++, Java, and Smalltalk, have been extended to allow persistent storage of the objects they create and manipulate. The fundamental concepts of the OO paradigm involve an understanding of objects, methods, encapsulation, classes, and inheritance. In an OO database, the class definitions correspond to class definitions for an OO programming language. The set of object instances in a class is called the extent of the class. Each object instance is given a unique object identifier (OID) that is independent of any of the values of the object and that is unchanging. OIDs are used to establish relationships between object instances. Attributes in a class can be atomic types, enumerated types, structured types, or collection types.
The Object Management Group (OMG) has defined standards for the object model and for Unified Modeling Language (UML), as a modeling standard. UML class diagrams are a useful method of representing classes and relationships, and they fit well with the OO data model. From a UML diagram, it is relatively easy to translate the design into class definitions that correspond directly to the items on the diagram, including the relationships between classes. A class is represented by a rectangle having three parts—the class name, the attributes, and the methods. Relationships are shown by lines, with multiplicity indicators of the form min..max, but placed on the opposite side to that used in entity-relationship (ER) diagrams. Relationships between classes, called associations, can be unidirectional or bidirectional, which is represented by defining an inverse for the relationship. They can specify a one relationship with a member of a class, or a many, which is represented by specifying Set before the name of the related class. Aggregation is a special type of relationship that connects a whole to its parts. Generalization is indicated by lines connecting the subclasses to the superclass, with a triangle on the line into the superclass.
Before it disbanded in 2001, the Object Database Management Group (ODMG) established industry-accepted standards for OO databases, including standards for Object Definition Language (ODL) and Object Query Language (OQL). In ODL, we give class declarations, including the name of the class, any inheritance, extent and keys, and descriptions of the attributes, relationships, and methods. OQL uses a syntax that is similar to SQL, but it has greater flexibility for dealing with a variety of structures. Because of the ODMG standards for OO language extensions, the process of developing a database using an object-oriented database management system (OODBMS) is closely linked to applications in those languages. There are numerous OODMBS products in existence. InterSystems Iris is an example of an OODMBS that supports the ODMG data model, together with an SQL-like query interface and programming language access to objects through application programming interfaces.
The relational model has been extended with additional fundamental data types like BOOLEAN and LOB, collection types such as arrays and nested tables or row types, user-defined data types (UDTs), class hierarchies, and reference types, as well as other enhancements. UDT definitions include specification of attributes and methods. They can be final or not, instantiable or not. Oracle syntax differs slightly from the SQL standard. In Oracle, UDTs can have a single method, either a map method or an order method, which defines the order of members. Object types can be used to create column objects in a table, or object tables, in which each row represents an object of the defined type.
Each row in an object table has a unique object identifier (OID), either system generated or user-defined. Reference types use the OID values as pointers to an object type. They can be used as attributes to represent relationships, similar to foreign keys. A scope can be specified that identifies the table referred to. A DEREF operator retrieves the tuple referred to, or a path expression can be used to retrieve the value of an attribute in the tuple referred to by a reference. Dangling pointers can result when referenced objects are deleted, but a referential integrity constraint provides some integrity protection. If the type is not final, subtypes that inherit all attributes and methods can be created, and we can add additional attributes and methods for the subtype. The type hierarchy can be extended by creating subtypes of subtypes. However, multiple inheritance is not permitted. In standard SQL, subtables consisting of the subtype can be created under tables that consist of the supertype.
In Oracle, a substitutable table can be created to hold all the objects in a hierarchy. Each tuple has a most specific type identified by the constructor used when it is inserted. The VALUE function is useful for retrieving data from a hierarchical table. The ONLY keyword and the IS OF type clause can be used to restrict the type of the result, and the TREAT keyword provides access to subtype-specific attributes in retrieving subtypes. An object view is a mechanism for treating a strictly relational database as if it were an OR one. It provides an OR view for users.
When a UML diagram is mapped to an OR model, classes are mapped to UDTs, with a multivalued attribute represented as an array and structured attributes as nested UDTs. Member methods are mapped to methods in the type body. Class inheritance is represented by base types and subtypes. Binary one-to-one, one-to-many, and many-to-many relationships are represented using reference attributes, with single references or arrays of references. Many-to-many relationships with descriptive attributes and higher-order relationships require a relationship type.
To convert an extended entity-relationship (EER) diagram to an OR model, we can modify the standard relational conversion mechanism, using new data types and collection types, which are useful for multivalued and composite attributes. Relationships can be represented by reference types instead of by foreign keys. Hierarchies can be represented using base types and subtypes.