The UML diagram for the revised University example shown in Figure 9.5 mapped directly to both the ODL schema in Figure 9.6 and to the Iris schema shown in Figure 9.8. ORDBMSs are limited in their ability to express all of the semantic information in a UML diagram, but the basic elements of classes, hierarchies, and relationships are easily represented using the OO features of an ORDBMS such as Oracle.
For each class in a UML diagram, we create a UDT, which can include single attributes of the class using built-in data types, user defined types, structured attributes using nested UDTs, multivalued attributes using arrays, and multivalued structured attributes using nested tables. Some special types, such as enumerated types, can be simulated using constraints, triggers, or stored procedures. Class hierarchies are defined by creating subtypes UNDER previously defined types, creating a single substitutable table for all subtypes, as described in Section 9.7.6. Shared subclasses cannot be represented directly and there is no way to represent specialization constraints. Class member methods can be implemented directly by creating them in the UDT body.
Binary one-to-one, one-to-many, and many-to-many associations without descriptive attributes are represented using references. If an association is bidirectional, references are required in both tables, but if the association is unidirectional, references are needed only in the table on the stem side of the arrow. For the one-to-one bidirectional case, each table must have a single attribute that references the other, but for the one-to-many case, An array of references can be used to store the multiple references on the “one” side, and a single reference on the “many” side. A many-to-many bidirectional association without a descriptive attribute can be represented by arrays of references in both tables. Higher-order relationships and many-to-many relationships with descriptive attributes require a separate relationship type with references or arrays of references from the individual types. Aggregation can be represented in the same way as association. Object tables are then created for the UDTs.
We will use the revised University example to illustrate the mapping process. The following is an OR schema for this example
The DDL for an OR Oracle database for this example is shown in FIGURE 9.17.
In FIGURE 9.17(A) we create the UDTs to correspond to the UML classes. First, we create UDTs for AddressType, NameType, and PhoneType to use later as column objects. We create a PersonType, making sure it is NOT FINAL, which will allow us to create subtypes. We create subtype StudentType UNDER PersonType, and the subtypes GraduateType and UndergraduateType UNDER StudentType, with TeachAsstType UNDER GraduateType. We create FacultyType UNDER PersonType. In creating these types, we defer entering any REF attributes that refer to types not yet defined. We will add these relationships later.
For the weak entity Evaluation, we created a type EvalType that included the discriminator evalDate and a reference attribute, is EvalOf, to the faculty member being evaluated. For simplicity, we chose the name given to the relationship in the UML diagram as the name of the reference attribute.
For the DeptType, we need an array to store the many references to the faculty members for each department, so we first created a RefFacArrayType as a VARRAY of REF FacultyType, and then used that type for the attribute hasFaculty. For the reference to the chairperson, the attribute hasChair is a single reference because that is a one relationship.
For CourseType we have a reference attribute isOffering to the department, a VARRAY of REF CourseType for hasPrerequisites, and a VARRAY of REF CourseType for isPrereqOf.
We create a type for ClassSection, with single references for CourseType, FacultyType, and TeachAsstType, an array of references to StudentType to represent the relationship hasStudent, and an array of references to Grade to represent givenStudent.
For Grade, which is a descriptive attribute of the many-to-many relationship between Student and classSection, we create a type that includes references to both Student and ClassSection named stu and classSect, respectively.
To ensure that we have represented all associations, we then return to add single references or arrays of references for all the types created earlier for which we omitted reference attributes originally, altering the types to include them, as shown in FIGURE 9.17(B). The CASCADE option in the ALTER TYPE command propagates the change to dependent types and tables
After creating all the required UDTs, including their relationships, we create the tables, identifying primary keys, foreign keys, and any other constraints for them. We cannot use a REF attribute as a primary key or unique attribute, so in cases where such an attribute would normally be part of the primary key, we will use the NOT NULL constraint and limit the scope of the attribute to the referenced table, which is not a completely satisfactory solution.
We decide not to create a table for Person, but to begin with Faculty and Student, which serves as the base type for the hierarchy consisting of Student, Graduate, Undergraduate, and TeachAsst. We use a substitutable table for all students, using the type constructors to insert the more specialized records, as described earlier. The other tables, Depts, Evaluations, Courses, ClassSections, and Grades, are straightforward object tables for their corresponding types. It is important to read the completed schema carefully and to compare it with the UML diagram to make sure that all classes and all relationships shown on the diagram are represented in the database before executing the code. Also recall that when inserting records, it may be necessary to temporarily disable some constraints. FIGURE 9.17(C) shows code for creating the object tables.
FIGURE 9.17(D) shows some DML commands for inserting data and querying the tables. Note that when inserting records, it may be necessary to insert null values initially, especially for references, or to disable some constraints temporarily.
3.16.139.8