The Object Database Management Group (ODMG) was a group of vendors that developed and published standards for OO databases and languages. It was founded in 1991 and published several standards, including the ODMG 3.0 standard, published in 1999, before disbanding in 2001. Its work has been taken over by the OMG. The ODMG established standards for the object data model, the Object Definition Language (ODL), the OQL, and language bindings for C++, Java, and Smalltalk. ODL is a standard language for describing schemas in OO terms, serving the same function that SQL Data Definition Language (DDL) serves. FIGURE 9.6 shows the ODL definition for the revised University schema shown in Figure 9.5.
FIGURE 9.6 ODL Definition for the University Schema
Each class declaration begins with the keyword class, the name of the class, an optional extent and key declaration in parentheses, and a list of attributes, methods, and relationships enclosed in curly brackets.
The extent of a class can be thought of as the set of object instances for that class that are stored in the database at a given time. Using terms introduced earlier, the class definition is part of the intension of the database, while the extent is part of the extension of the database. In ER terms, the class is like the entity type, and the extent is the set of entity instances. It is good practice to choose a name for the extent that is slightly different from the name of the class. For the Person class, we called the extent People. The parentheses can also contain the name of the key, which we discuss in a later section.
The attributes for a class are listed, preceded by their datatypes, within curly brackets. A wide variety of types are permitted in ODL, including simple types and more complex types that can be built from them.
Atomic types include integer, float, character, string, Boolean, and enumerated types. Enumerated types are identified by the keyword enum, the user-defined name of the type, a list of literals for the type within curly braces, and the name of the attribute with that type. For example, we made attribute rank in Faculty have an enumerated type called FacultyRank. We can also have structured types, identified by the keyword Struct, the name of the type, and parentheses containing each attribute with its data type. In the Person class definition, Addr is a structured type that we have used for the attribute address. Because we defined the type, we can use it again for other classes, but we must identify the class it was defined in, using the form Person::Addr, which is called the scoped name and consists of the class name, a double colon, and the structure name. This scoped form is used to refer to any property in a different class. Besides Struct, there are type constructors for five collection types, namely Set, List, Array, Bag, and Dictionary.
Relationships represent connections between object instances. For example, faculty members relate to class sections because they teach them, students relate to classes that they take, departments relate to faculty who are employed in them, and so on. The OO model represents these connections using references. In ODL, the description of a relationship implies that the system stores and maintains such references. For example, there is a relationship called takesClass defined for the Student class in the line
which tells us that each Student instance can contain a set of references, called takesClass, to ClassSection instances. Typically, the references are simply the OIDs of the related objects. The keyword Set shows that this is a “many” relationship for each student; that is, a Student instance can be related to a set of ClassSection instances, not just one.
Given a specific Student instance, we can use the takesClass relationship to find out what classes the student is taking. We also expect to turn the query around and, given a ClassSection instance, ask what students are in the class. We see that there is such an inverse relationship, hasStudent, defined for ClassSection. The phrase
which appears on the same line as the takesClass relationship definition, means that each ClassSection object contains references to the corresponding Student instances. We note that in addition to specifying in the Student class that the inverse exists, we also specify this relationship in the ClassSection class in this line
The connection between takesClass and hasStudent is that if a class appears in the takesClass set of references for a student, that same student should appear in the hasStudent set of references for the class. These two relationships are therefore inverses of each other, as indicated. Note that when we identify the inverse relationship, we normally use the scoped form for its name
because the inverse relationship is usually in another class definition.
In ODL, a relationship is not required to have an inverse. A relationship without an inverse is described as unidirectional, while a relationship with an inverse is bidirectional. A relationship also has cardinality, which can be one-to-one, one-to-many, many-to-one, or many-to-many. The bidirectional Student-ClassSection relationship is many-to-many in both directions, and both relationship specifications include a set of references. If a relationship is one-to-many, as in the relationship between Department and Faculty, the class on the “one” side, Department, defines the relationship as a set. In the Department definition, we have the relationship Set<Faculty> because each Department instance has references to many Faculty instances as shown in the line
However, the relationship on the Faculty side
specifies just Department (not Set<Department>) because a faculty record refers to only one department.
Method declarations in ODL specify the signature, which consists of the return type, the name of the method, and the names and types of parameters. Each parameter also has a mode that is identified as IN, OUT, or IN OUT, depending on whether the parameter is input, output, or both. In ODL, classes have automatic get() and set() methods for each attribute, so we need not list these unless we wish to override them. There are also other automatic methods for the manipulation of collections, such as sets, bags, and lists. Class member methods are applied to an instance of the class, which is referred to as self in the code for the method. The actual code for the method is not part of the ODL but is written in one of the host languages.
A subclass is identified by the keyword extends and the name of the superclass following the subclass name. The subclass inherits all the attributes, relationships, and methods of the superclass, and it can have some additional properties of its own that appear in the definition. For example, in Figure 9.6, Faculty extends Person, so it inherits pId, name, address, phone, birthdate, and findAge() from Person but adds some additional properties. If the subclass has more than one superclass, we add a colon and the name of the second superclass immediately after the name of the first superclass. As discussed earlier, different systems implement this feature in their own ways, if at all.
Relationships in ODL are binary, but if we must model a ternary or higher-order relationship, we can do so by creating a class for the relationship. The class definition would include three or more relationships that connect the new class to the originally related classes. For example, in a different class diagram we could have a ternary relationship connecting courses, instructors, and textbooks, shown in Chapter 3, Figure 3.6, which we might call BookOrder. For this example, we assume that the same course can be taught by different professors who may choose to use different textbooks. In the OO model, we would define the class for the BookOrder relationship, as shown in the following sketch:
If the relationship has any descriptive attributes, they are listed as well. The inverse relationships must be included in the corresponding Faculty, TextBook, and Course class definitions. Note that this technique is similar to the way we treated higher-order relationships in the relational model, where we created tables for such relationships.
Binary many-to-many relationships with descriptive attributes cannot be handled by the usual solution of making the relationship a set in both directions, because that leaves no place for descriptive attributes. Referring to the UML diagram in Figure 9.5, we see that grade is an example of a descriptive attribute. We use the same solution as for n-ary relationships, setting up a class for the relationship. We place the descriptive attributes as attributes of the new class, and we define two one-to-many relationships between the two original classes and the new class. We have done this in Figure 9.6 by defining the class Mark. Note that we also kept the many-to-many relationship between Student and ClassSection that represents enrollment in the section by defining set relationships in both. This relationship did not require a new class definition because it has no descriptive attributes.
Keys are optional in ODL because the unique OID automatically given to each object instance allows the system to tell instances apart. However, the designer may choose to identify any candidate keys as well. This is done at the beginning of the class declaration within the same parentheses as the extent declaration. A key can be a single attribute or a composite, which is identified by placing parentheses around the names of component attributes. For example, we could have written
This indicates that pId is a key, and the combination of name and belongsTo is a key. Keys are not restricted to attributes, as shown in the composite key definition. We can list a relationship (such as belongsTo) or even a method as a key, provided it gives us unique values.
Weak entity sets can often be represented as subclasses in which the relationship to the superclass is part of the key, with the discriminator as another part. For example, for the weak entity set Evaluation, we wrote
This means the composite key consists of the date of the evaluation and the identity of the related faculty member.
3.12.150.203