Step-by-step Beginning Database: A Practical Approach for Non-relational Database.

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