5.2 Step-by-step
Students may follow the steps outlined below before attempting to make schema transformation. These are general steps for conceptual schema transformation :
Step 1: Mapping class inheritance tree and abstract class
Oracle 9i allows specialization of an object type by creating subtypes. Subtypes can be created by deriving them from a parent object typesupertype. Subtypes and supertypes
are related by inheritance. Since subtypes are specialized versions of their parent, subtypes have all the parents attributes and methods plus any specializations that are
defined in the subtype itself. Subtypes and supertypes connected by inheritance make up
a type hierarchy.
Figure 5-2 shows an example of class inheritance tree in UML class diagram where there is one superclass Person and two subclasses Employee and customer. Address
and Name are actually abstract class that represents user-defined types. In O-R approach, the main classes in UML class diagram become object types. Therefore we
would expect that class Person, Employee and Customer in Figure 5-2 will all be transformed into object types.
+personId : String +personName
+personAddress +phoneNumber : String
+birthDate : Date
Person
-employeeId : String -startDate : Date
Employee
-customerId : String
Customer {optional,disjoint}
+firstName : String +midName : String
-lastName : String
Name
+street : String +city : String
-state : String +poscode : String
Address
-Has 1
-refers_to 1
-lives_at 1
-belongs_to 1
Figure 5-2: Class Inheritance Tree in UML class diagram
31
The example of Object-relational design of these object types based on Oracle 9i syntax is illustrated by the following figures :
Type NAME_OBJTYP firstName
midName lastName
VARCHAR215 VARCHAR215
VARCHAR215
Figure 5-3: Object relational representation of the NAME_OBJTYP
Type ADDRESS_OBJTYP street
city state
poscode VARCHAR215
VARCHAR210 VARCHAR210
NUMBER
Figure 5-4: Object relational representation of the ADDRESS_OBJTYP Type PERSON_OBJTYP
personIdPK personName personAddress
phoneNumber birthDate VARCHAR210 NAME_OBJTYP ADDRESS_OBJTYP VARCHAR29 DATE
Figure 5-5: Object relational representation of the PERSON_OBJTYP
Type EMPLOYEE_OBJTYP under PERSON_OBJTYP EmployeeId PK
startDate VARCHAR210
DATE
Figure 5-6: Object relational representation of the EMPLOYEE_OBJTYP
Type CUSTOMER_OBJTYP under PERSON_OBJTYP CustomerId PK
VARCHAR210
Figure 5-7: Object relational representation of the CUSTOMER_OBJTYP
32
Step 2: Mapping class association
Next, relationship or in UML terminology is called association can be mapped into O-R model by selecting one REF attribute that establishes connection between objects.
Figure 5-1 shows two classes that are involved in association. These classes are Employee and Customer. REF attribute is actually a foreign key in relational data model
terms. Since object types for Customer Customer_ObjTyp has been created before, some modification need to be made on its logical design in order to add REF attribute.
The result of the transformation is shown in Figure 5-8.
Type CUSTOMER_OBJTYP under PERSON_OBJTYP
CustomerId PK emp_ref FK
VARCHAR210 EMPLOYEE_OBJTYP
Figure 5-8: Object relational representation of the CUSTOMER_OBJTYP
Step 3: Mapping class composition
Relationship strength or specifically in UML terminology is called composition can be transformed into an O-R model by transforming the childdependent object into a nested
table. Before this transformation is possible, the child object need to be first mapped into an object type. For example, child object in Figure 5-1 is Dependant, which is
related to its parent object, Employee. The result of transformation is shown in Figure 5-9 and Figure 5-10.
33
Type DEPENDANT_OBJTYP DependantId PK
dependantName dependantAddress
VARCHAR210 NAME_OBJTYP
ADDRESS_OBJTYP
Figure 5-9: Object relational representation of the DEPENDANT_OBJTYP Column dependantList
of DEPENDANT_NESTEDTAB as table of DEPENDANT_OBJTYP DependantId PK
dependantName dependantAddress
VARCHAR210 NAME_OBJTYP
ADDRESS_OBJTYP
Figure 5-10: Object relational representation of the Nested Table dependantList
Beside that, logical design for Employee_ObjTyp Figure 5-6 need to be modified in order to add an attribute that reflects composition of Dependant nested table. The new
representation of O-R model for Employee_ObjTyp is illustrated in Figure 5-11.
Type EMPLOYEE_OBJTYP under PERSON_OBJTYP EmployeeId PK
startDate dependantList
VARCHAR210 DATE
DEPENDANT_NESTEDTAB
Figure 5.11: Object relational representation of the EMPLOYEE_OBJTYP after modification
34
Step 4: Creating Object Tables
O-R data model is never complete without creating tables. Creating object types alone will only defines logical templatestructure, but not its storage specification. In order to
use these objects types, they need to be associated in object tables as column object or used to construct the whole structure of object table.
For example ADDRESS_OBJTYP and NAME_OBJTYP are used as column objects in Person table PERSON_OBJTAB. Person table is created based on object type
PERSON_OBJTYP.
Figure 5-12 shows Object relational representation of the PERSON_OBJTAB.
Table PERSON_OBJTAB of PERSON_OBJTYP PersonId
PK personName
personAddress phoneNumber birthDate
VARCHAR210 NAME_OBJTYP ADDRESS_OBJTYP VARCHAR29 DATE
Figure 5-12: Object relational representation of the PERSON_OBJTAB
Other object tables that need to be created are Employee and Customer object table. Note:
1 Not all object types are used to define object table. User-defined type like address and name are usually used as column objects.
2 Not all classes need to be transformed into object types. It depends on application requirements.
35
5.3 Exercise