The OR model provides much more flexibility in mapping an EER diagram than does the strictly relational model. As illustrated in our examples, we can make use of new data types, user-defined structured types, inheritance, and reference types in creating our tables. We modify the EER-to-relational mapping algorithm (presented in Chapter 4, Section 4.8.2) to incorporate the extensions.
For entity sets and relationships that are not part of generalizations or unions, the mapping can proceed in a manner similar to the relational model. Entity sets can be mapped to tables, creating a type and then creating an object table of that type. For composite attributes, we can define a structured type for the composite, with the components as attributes of the type. Multivalued attributes can be expressed as collection types, either varrays or nested tables in Oracle. In representing relationships, reference types can be used in place of the foreign key mechanism. For specialization hierarchies, types and subtypes can be defined as needed and substitutable tables to correspond to the types can be created. However, because no subtypes can have multiple inheritance, the designer must choose among potential supertypes for a shared subtype. There is no direct representation of unions (categories) in the OR model, but we can use the same method as we did for the relational model. We create a table for the union itself and individual tables for each of the superclasses, using foreign keys or references to connect them.
FIGURE 9.18 shows an EER diagram that corresponds to the UML diagram shown in Figure 9.5. The result of mapping the EER diagram for the revised University database to an object-relational model is identical to that of mapping the UML diagram, so the OR schema shown in Section 9.8 and the Oracle SQL shown in Figure 9.18 represent that mapping as well.
FIGURE 9.18 EER Diagram for the Revised University Database
3.14.248.69