Appendix G Object Oriented Databases

Appendix G

Object-Oriented Databases

Discussion Focus

Because an OO model necessarily forces the student to come to terms with some very abstract notions,
begin the discussion by pointing out the practical benefits of system modularity; then carefully delineate
the OO features that almost inevitably lead to modularity.

At this point, students should be familiar with the relational model, so show how the OO model handles
attributes and demonstrate that:
1. Although the term "object" in a relational environment is sometimes used as synonymous with
"entity," an object in an OO environment contains much more than attributes. Use Figure G.2 to
show that the object contains both data and methods: Every operation to be performed on the
object is implemented by a method! And the methods are carried along with the object, thus
producing modularity!
2. An OO attribute (not its value!) can reference one or more other objects.
3. Unlike the relational model, the OO model does not need a JOIN to link tables through their
common attribute values.
4. There is quite a difference between the relational model's primary key and the OO model's OID.

Section G.5, “OODM and Previous Data Models: Similarities and Differences,” yields an excellent
summary of the OO data model; do not omit any of its subsections in your discussion. Next, it is crucial
that you shift attention to Section G.5.1's Figure G.34, “An Invoice Representation”; this is where
students are most likely to see the database's conceptual modeling implications.

581
 Appendix G Object Oriented Databases

Answers to Review Questions

NOTE
To ensure in-depth chapter coverage, most of the following questions cover the same material
that we covered in detail in the text. Therefore, in most cases, we merely cite the specific
section, rather than duplicate the text material.

1. Discuss the evolution of object-oriented concepts. Explain how those concepts have affected
computer-related activities.

See Section G.2.

2. How would you define object orientation? What are some of its benefits? How are OO
programming languages related to object orientation?

See the definition of OO in Section G.1, “Object Orientation and Its Benefits.”

The benefits derived from the application of OO concepts are summarized in Table G.1, “Object
Orientation Contributions.”

The relationship between OO and OO programming languages (OOPL) is discussed in Section

G.3.5, “Messages and Methods.” Add to this discussion that OO concepts have created a powerful
programming environment that has radically changed both programming and systems development.
Although traditional programmers tended to agree that modularity is one of the primary goals of
structured programming and good design, modularity was often difficult to achieve. Even a cursory
examination of OO concepts leads to the conclusion that the conceptually autonomous structure (in
which an object contains both data and methods) makes the much sought-after modularity almost
inevitable.

3. Define and describe the following:

a. Object See Section G.3.1, “Objects: Components and Characteristics.”
b. Attributes See Section G.3.3, “Attributes (Instance Variables.”
c. Object state See Section G.3.4, “Object State.”
d. Object ID See Section G.3.2, “Object Identity.”

4. Define and contrast the concepts of method and message. What OO concept provides the
differentiation between a method and a message? Give examples.

Methods and messages are discussed in Section G.3.5, “Messages and Methods.”

Use Figure G.3, “Method Components,” to illustrate the role of methods and messages.

582
 Appendix G Object Oriented Databases

5. Explain how encapsulation provides a contrast to traditional programming constructs such as

record definition. What benefits are obtained through encapsulation? Give an example.

Encapsulation hides the object's internal data representation and method implementation, thus
ensuring the object's data integrity and consistency. The programmer needs only ask an object to
perform an action, without having to specify how the action is to be performed. Since the
implementation details need not be specified, the programmer can concentrate on the overall
process.

Clearly, an object is an independent entity. Therefore, object independence assures system

modularity. For example, an object-oriented system is formed by possibly thousands of independent
objects (or even more) that interact to perform specific actions. In short, what we have just described
is a perfectly modular system.

In contrast, the programmer who uses traditional programming languages has direct access to the
internal components of a record type. Therefore, the programmer can directly manipulate the data
elements at will. This ability is not necessarily valuable; programmers can (and do) make mistakes,
thus causing problems in critical systems. For example, when you create a record type "customer" in
your program, you have direct access to all the data elements of such a record, so there is no
protection of the data.

6. Using an example, illustrate the concepts of class and class instances.

See Section G.3.6, “Classes.” Use Figure G.5, “Class Illustration,” to illustrate that a class is
composed of objects or object instances; then use the example summarized in Figure G.6,
“Representation of the Class STUDENT.”

As you discuss the example in Figure G.5, note that each class instance is an object with a unique
OID and that each object knows to which class it belongs.

7. What is a class protocol, and how is it related to the concepts of methods and classes? Draw a
diagram to show the relationship between these OO concepts: object, class, instance variables,
methods, object's state, object ID, behavior, protocol, and messages.

See Section G.3.7, “Protocol.” Use the summary presented in Figure G.8, “OO Summary: Object
Characteristics,” to tie the OO concepts together.

8. Define the concepts of class hierarchy, superclasses, and subclasses. Explain the concept of
inheritance and the different types of inheritance. Use examples in your explanations.

See Sections G.3.8, “Superclasses, Subclasses, and Inheritance,” and G.3.9, “Method Overriding and
Polymorphism.” The examples are illustrated in Figures G.9 - G.14.

583
 Appendix G Object Oriented Databases

9. Define and explain the concepts of method overriding and polymorphism. Use examples in
your explanations.

See Section G.3.9, “Method Overriding and Polymorphism.” Illustrate the example with reference to
Figure G.14, “Employee Class Hierarchy Polymorphism.”

10. Explain the concept of abstract data types. How they differ from traditional or base data
types? What is the relationship between a type and a class in OO systems?

See Sections G.3.10 - G.4. Show Figure G.17, “Defining Three Abstract Data Types,” to illustrate
the use of abstract data types. Use Table G.3, “Comparing the OO and ER Model Components,” to
illustrate the distinction between type and class.

11. What are the five minimum attributes of an OO data model?

See Section G.6, “Object Oriented Database Management Systems.” Note especially Table G.4,
“The Thirteen OODBMS Rules. Table G.4’s subsection, “Rules that make it a DBMS,” lists the five
characteristics (rules) that define an OO data model.

12. Describe the difference between early and late binding. How does each of those affect the
object-oriented data model? Give examples.

Late and early binding are discussed and illustrated in Section G.4.4, “Late and Early Binding: Use
and Importance.” See particularly Figures G.32, “Inventory Class with Early Binding” and G.33,
OODM Inventory Class with Late Binding.”

13. What is an object space? Using a graphic representation of objects, depict the relationship(s)
that exist between a student taking several classes and a class taken by several students. What
type of object is needed to depict that relationship?

The object space or object schema is the equivalent of a database schema. The object space is used
to represent the composition of the state of an object at a given time. For example, to represent the
M:N relationship between students and classes, you can use the schema shown in Figure QG.13 to
represent the M:N relationship between CLASS and STUDENT:

584
 Appendix G Object Oriented Databases

Figure QG.13 The Object Schema for the Relationship

between Student and Class

As you discuss Figure QG.13, note the use of an interSection class (ENROLL) to represent the M:N
relationship between STUDENT and CLASS. This interSection class contains the GRADE attribute,
which represents the student's grade in a given course.

NOTE
Now's the time to tie the OO concepts and constructs together. Show how the OO model uses
objects, object instances, and object sharing, then explore the 1:1, 1:M, and M:N relationships
illustrated in Figures G.23 trough G.28. Next, show how an object space may be represented,
using Figure G.29 as an example. Finally, show how abstract data types help the designer
implement the OO model.

14. Compare and contrast the OODM with the ER and relational models. How is a weak entity
represented in the OODM? Give examples.

Section G.4, “Characteristics of an Object Oriented Data Model,” sets the discussion stage. Use
Table G.3, “Comparing the OO and ER Model Components,” to summarize the comparisons
between the OO model and the ERM. (The acronym “ERM” denotes the Entity Relationship
Model.) This question is also address extensively in Section G.9, “How OO Concepts have
Influenced the Relational Model.” Section G.5.1, “Object, Entity, and Tuple,” is and excellent
comparison source. Your students may get an “I got it!” moment when they examine Figure G.34,
“An Invoice Representation.”

585
 Appendix G Object Oriented Databases

Although the OODM has much in common with relational and ER data models, the OODM
introduces some fundamental differences. Table QG.14 provides the summary that will help you
clarify the OODM characteristics we introduced in this appendix. (Although a case may be made
for the OO data model’s contributions, we urge you to let your students read and discuss C. J.
Date’s “Third Manifesto,” referenced in Section G.9.)

Table QG.14 A Comparison of OODM, ERM, and Relational Model Features

OODM ER Model (ERM) Relational Model
Type Entity definition (limited) Table definition (limited)
Object Entity Table row or tuple
Class Entity set Table
Instance variable Attribute Column (attribute)
OID N/A N/A
N/A Primary key Primary key
Object schema ER diagram Relational schema
Class hierarchy N/A* N/A
Inheritance N/A* N/A
Encapsulation N/A N/A
Method N/A N/A

You may find it useful to point out the similarities between (entity type and subtypes) and (class
hierarchy and inheritance.) Remember that entity types and subtypes are design constructs that
provide data modeling with data abstraction, but these constructs do not automatically imply the
existence of inheritance. In fact, no RDBMS supports these constructs directly; instead, the
programmer has to link the tables at run time to ensure that the attributes will be “inherited”. You
could also create views to ensure that the constructs include the “inherited” attributes.

15. Name and describe the 13 mandatory features of an OODBMS.

See Section G.6.1, “Features of an Object Oriented Database,” and use the thirteen OODBMS
commandments listed in Table G.4, “The Thirteen OODBMS Rules.”

16. What are the advantages and disadvantages of an OODBMS?

See Section G.8, “OODBMS: Advantages and Disadvantages.”

17. Explain how OO concepts affect database design. How does the OO environment affect the
DBA's role?

See Section G.9, “How OO Concepts have Influenced the Relational Model.”

586
 Appendix G Object Oriented Databases

18. What are the essential differences between the relational database model and the object
database model?

Start by using Table QG.14 – shown in the answer to question 14 -- to show and contrast the basic
concepts of the object model, the entity-relationship model, and the relational model. A more
detailed discussion of the similarities and differences among the models is found in Section G.5,
“OODM and Previous Data Models: Similarities and Differences.” In this section, we have shown
that:
 An object extends beyond the static concept of an entity or tuple in the other data models.
 Like the entity set and table, a class includes the data structure. However, unlike the entity
set and table, the class also includes methods.
 Unlike its relational and ER counterparts, encapsulation allows an object’s “internals” to be
hidden from the outside
 Unlike its relational and ER counterparts, inheritance allows an object to inherit attributes
and methods from a parent class.
 The Object Id is a concept associated with the primary key concept in the relational and ER
model, but it is not quite the same thing. An object Id is an attribute that is not directly
exposed, user definable, or directly accessible as the PK is in the relational model.
 The relational and ER model relationships are based on the primary key/foreign key
relationships. Such relationships are “value” based; that is, they are based on having two
attributes in different tables sharing equal values. The relationships in the object model are
not based in the specific value of any attributes.
 Data access in the relational model is based on a query language known as SQL. SQL is a
set-oriented language that uses associative access methods to retrieve related rows from
tables. In contrast with the relational model, the object data model suffers from the lack of a
standard query language. Because of its identity based access style, the object model
resembles the record-at-a-time access of older hierarchical and network models.

19. Using a simple invoicing system as your point of departure, explain how its representation in
an entity relationship model (ERM) differs from its representation in an object data model
(ODM). (Hint: Check Figure G.34.)

Use the appendix’s Figure G.34 to illustrate the idea that the object model represents the INVOICE
as an object containing other objects (CUSTOMER and LINE). In contrast, the ER model uses three
different and separate entities related to each other through their primary key/foreign key attributes.
Note that the object model automatically includes the CUSTOMER and LINE object instances when
each INVOICE line instance is made current.

20. What are the essential differences between an RDBMS and an OODBMS?

Section G.6, “Object Oriented Database Management Systems,” explains the basic characteristics of
an OODBMS. Such characteristics clearly show that the OODBMS shares features such as data
accessibility, persistence, backup and recovery, transaction management, concurrency control, and
security and integrity with the RDBMS. In addition, the OODBMS has unique characteristics such
as support for complex objects, encapsulation and inheritance, abstract data types, and object
identity.

587
 Appendix G Object Oriented Databases

21. Discuss the object/relational model's characteristics.

See Section G.9, “How OO Concepts Have Influenced the Relational Model.” Section G.5.1,
“Object, Entity, and Tuple,” is and excellent comparison source. Your students may get an “I got
it!” moment when they examine Figure G.34, “An Invoice Representation.”

Problem Solutions

1. Convert the following relational database tables to the equivalent OO conceptual

representation. Explain each of your conversions with the help of a diagram. (Note: The RRE
Trucking Company database includes the three tables shown in Figure PG.1).

588
 Appendix G Object Oriented Databases

FIGURE PG.1 The RRE Trucking Company Database

589
 Appendix G Object Oriented Databases

As you examine Figure PG.1, note that, for simplicity's sake, we have chosen not to represent
BASE_MANAGER as an abstract data type belonging to the class PERSON.

Figure PG.1 The OO Conceptual

1
1
Representation

Figure PG.1 also illustrates that the CTRUCK class represents a collection of TRUCK objects. In other
words, one instance of the CTRUCK class will contain several instances of the class TRUCK.

2. Using the tables in Figure PG.1 as a source of information:

a. Define the implied business rules for the relationships.

Given the tables in Figure PG.1, you may develop the following relationships:
 A BASE can have many TRUCKs.
 Each TRUCK belongs to only one BASE.
 A TRUCK has only one truck TYPE.
 Each truck TYPE may have several TRUCKs belonging to it.

590
 Appendix G Object Oriented Databases

b. Using your best judgment, choose the type of participation of the entities in the
relationship (mandatory or optional). Explain your choices.

From the data shown in Figure PG.1 you can conclude that:
 BASE and TYPE are mandatory for TRUCK.
 A TRUCK must have a BASE.
 A truck is of a given TYPE.
 TRUCK is mandatory for BASE.
 A BASE must have at least one TRUCK to be considered a BASE.
 TRUCK is optional for TYPE. There can be zero, one, or more TRUCKs belonging to a
TYPE.

c. Develop the conceptual object schema.

Using the results of Problems (a) and (b), the conceptual object schema is represented by Figure
PG.2C.

Figure PG.2C The Conceptual Object Schema

591
 Appendix G Object Oriented Databases

3. Using the data presented in Problem 1, develop an object space diagram representing the
object's state for the instances of TRUCK listed below. Label each component clearly with
proper OIDs and attribute names.
a. The instance of the class TRUCK with TRUCK_NUM = 5001

The instance of this class is shown in problem 2c's conceptual object schema. (Figure PG.2c.)

b. The instances of the class TRUCK with TRUCK_NUM = 5003 and 5004.

As you examine the conceptual object schema shown in problem 2c, note the following features:
 OIDs are used to reference the object instances of the classes BASE and TYPE.
 The BASE and TYPE object instances reference two different CTRUCK object
instances.
 Using the OIDs, each CTRUCK object instance contains the reference to several object
instances of the class TRUCK.

Using these features, the conceptual object schema looks like Figure PG.3b.

Figure PG.3b The Conceptual Object Schema

592
 Appendix G Object Oriented Databases

As you examine Figure PG.3b’s conceptual object schema, note the following features:
 OIDs are used to reference the object instances of the classes BASE and TYPE.
 Both object instances reference the same BASE and TYPE object instances. This property
is also called referential object sharing.

4. Given the information in Problem 1, define a superclass VEHICLE for the TRUCK class.
Redraw the object space you developed in Problem 3, taking into consideration the new
superclass that you just added to the class hierarchy.

To add a superclass VEHICLE to the TRUCK class, first define the superclass VEHICLE, after
which you can create the subclass TRUCK. After this task has been completed, the end user will see
only the attributes and methods that were inherited from VEHICLE. (The user does not perceive the
difference!) To illustrate this point, the object space must also show the new VEHICLE instance.
(See Figure PG.4.)

Figure PG.4 The Conceptual Object Schema

593
 Appendix G Object Oriented Databases

5. Assume the following business rules:

 A course contains many Sections, but each Section references only one course.
 A Section is taught by one professor, but each professor may teach one or more different
Sections of one or more courses.
 A Section may contain many students, and each student may be enrolled in many
Sections.
 A Section may contain many students, and each student is enrolled in many Sections, but
each Section belongs to a different course. (Students may take many courses, but they
cannot take many Sections of the same course.)
 Each Section is taught in one room, but each room may be used to teach different
Sections of one or more courses.
 A professor advises many students, but a student has only one advisor.

Based on those business rules:

a. Identify and describe the main classes of objects.

Using the business rules 1 through 6, we may identify the objects:

COURSE STUDENT
CLASS ROOM
PROFESSOR

NOTE
We commonly use CLASS to identify a Section of a COURSE. (IN fact, all of the
examples in Chapters 2 and 3 were based on this convention.) Therefore, we use
CLASS to identify a Section of a COURSE. We use this convention for the simple
reason that it properly reflects commonly used language. For example, students
invariably will tell you that they have enrolled in your class; they'll tell you they're
going to your class, rather than going to your Section. However, do keep in mind
that "class" has a specific (and different!) meaning in the OO environment.
Fortunately, the context in which "class" is used easily identifies which "class"
you're talking about.

The classes corresponding to these objects are shown in Figure PG.5a.

594
 Appendix G Object Oriented Databases

Figure PG.5a The Conceptual Object Schema

Use the following descriptions to characterize the model's components:

COURSE OFFERING INCLUDES CLASS

A COURSE CAN GENERATE MANY CLASSES
CLASS IS OPTIONAL TO COURSE (a course may not be offered)

PROFESSOR TEACH_LOAD INCLUDES CLASS

A PROFESSOR CAN TEACH MANY CLASSES
CLASS IS OPTIONAL TO PROFESSOR (a professor may not teach a class)

ADVISEES INCLUDES STUDENT

A PROFESSOR MAY ADVISE MANY STUDENTS
STUDENT IS OPTIONAL TO PROFESSOR (in the advises relationship)

ROOM RESERVATION INCLUDES CLASS

ONE ROOM CAN HAVE MANY CLASSES SCHEDULED IN IT
CLASS IS OPTIONAL TO ROOM (a room may not have classes scheduled in it)

595
 Appendix G Object Oriented Databases

STUDENT ADVISOR INCLUDES PROFESSOR

A STUDENT HAS ONE PROFESSOR (who advises that student)
PROFESSOR IS MANDATORY (a student must have an advisor)
SCHEDULE INCLUDES CLASS
A STUDENT MAY TAKE MANY CLASSES (i.e., SECTIONS OF A COURSE)
CLASS IS MANDATORY TO STUDENT
(a student must take at least one Section of a course)

CLASS REQUIRES A COURSE

COURSE IS MANDATORY (a class can't exist without a course)
PROFESSOR IS MANDATORY (a class must have a professor)
ROOM IS MANDATORY (a class must be taught in a room)
A CLASS MAY HAVE MAY STUDENTS ENROLLED IN IT
STUDENT IS OPTIONAL ( a class may not have any students enrolled in it)
AN ENROLLED STUDENT RECEIVES A GRADE

b. Modify your description in Part (a) to include the use of abstract data types such as NAME,
DOB, and ADDRESS.

An abstract data type allows us to create user-defined operations for that new type. To create a
new data type, first define the abstract data types or classes: NAME, DOB (date of birth), and
ADDRESS, as shown in Figure PG.5B-1.

Figure PG.5B-1 The Abstract Data Types (Classes)

Having created the new abstract data types or classes, we must redefine PROFESSOR and
STUDENT classes so they can reference these newly created classes. For example, the object
instance representation for a PROFESSOR will look like Figure PG.5B-2.

596
 Appendix G Object Oriented Databases

Figure PG.5B-2 The Object Instance Representation for PROFESSOR

Within the new object space illustrated in Figure PG.5B-2, the PROFESSOR object instance now
contains references to the NAME, DOB, and ADDRESS object instances.

c. Use object-representation diagrams to show the relationships between:

 Course and Section.
 Section and Professor.
 Professor and Student.

To answer this question, we must remember how 1:M relationships are interpreted in the OODM.
We must also remember that the OODM interpretation of such 1:M relationships yields some
important implications. Keep in mind that all pairs of objects exist in a 1:M relationship: A
course has many Sections (classes), a professor teaches many classes, and a professor advises
many students.

597
 Appendix G Object Oriented Databases

To save space in this manual, we will illustrate only one case of 1:M relationships; the same
concepts apply to all cases. We will focus our attention on the relationships of the objects in the
class PROFESSOR. The object representation for an object of the (OO) class PROFESSOR will
look like Figure PG.5C.

Figure PG.5C The Object Representation for an Object

of the Class PROFESSOR

Note that we have omitted the object instances for the classes NAME, DOB, and ADDRESS.
(These classes are shown in the answer to problem 5g.) Note also that we have used the
"collection of" classes to represent the collection of
 CLASSes taught by the PROFESSOR.
 STUDENTs advised by the PROFESSOR.

Collection objects are used to implement 1:M relationships.

598
 Appendix G Object Oriented Databases

d. Use object representation diagrams to show the relationships between:

 Section and Student.
 Room and Section.

What type of object is necessary to represent those relationships?

The relationship between CLASS (Section) and STUDENTS is M:N; that is, each class has many
students, and each student has many classes. The relationship between CLASS and ROOM is
1:M, because each class is taught in only one room and each room is used to teach several classes.

We covered the use and representation of 1:M relationships in our answer to question 5c, so
please refer to that material.

Depending on the level of abstraction used, representing a M:N relationship in an object

representation diagram is fairly simple. For example, at the conceptual level, we can show the
relationship between CLASS and STUDENT in Figure PG.5D-1:

Figure PG.5D-1 The Relationship Between CLASS and STUDENT

599
 Appendix G Object Oriented Databases

As you examine Figure PG.5D-1, note that:

 A student must be registered in one or more CLASSes, and the student earns a GRADE in
each CLASS. (Reminder: We’ve used CLASS to represent a Section of a course.)
 The CLASS requires a COURSE, a PROFESSOR, and a ROOM.
 The CLASS may have one or more STUDENTS, each of whom earns a GRADE in that
CLASS. In other words, STUDENT is optional to CLASS.

From a conceptual point of view, the preceding diagram captures both the nature and
characteristics of the relationship between CLASS and STUDENT.

At the implementation level, the object-oriented data model uses an intersection-class to manage
M:N relationships only when additional information (attributes) about the M:N relationship
between the objects is required. In this case, GRADE is our additional information, so a GRADE
is associated with a CLASS and a STUDENT.

The intersection-class is automatically included within the STUDENT and CLASS object space
and represents the individual characteristics of the M:N relationship among them. For clarity’s
sake we have label this new object as STU-REC. In this case the STU-REC object illustrates what
students are in which Section, and in which Sections is the student registered? And what is the
grade of each student registered in a Section? The object diagram in Figure PG.5d-2 shows such
relationships:

Figure PG.5D-2 The Object Diagram for Problem PG.5d

As you discuss Figure PG.5D-2, note that STU_REC (the student record) is the intersection class
that represents the M:N relationship between STUDENT and CLASS.

600
 Appendix G Object Oriented Databases

e. Using an OO generalization, define a superclass PERSON for STUDENT and

PROFESSOR. Describe this new superclass and its relationship to its subclasses.
A superclass PERSON can be defined for STUDENT and PROFESSOR. PERSON will contain
the following attributes:

Attribute name Data Type

NAME NAME
DOB DOB
ADDRESS ADDRESS
STUDENT and PROFESSOR will inherit the above attributes from their superclass PERSON.
The class hierarchy will look like Figure PG.5E.

Figure PG.5e The Class Hierarchy

As you discuss Figure PG.5E, note the differences between inheritance and interclass
relationships. Explain that:
 Inheritance is automatic.
 Inheritance moves from top to bottom within the class hierarchy.
 Inheritance represents a 1:1 relationship between the superclass and its subclass(es).
 Inheritance need not be explicitly defined through the attribute data type.
In contrast, interclass relationships must be defined explicitly through the attribute's data type. In
addition, interclass relationships may represent a 1:1, a 1:M, or a M:N relationship.

601
 Appendix G Object Oriented Databases

6. Convert the following relational database tables to the equivalent OO conceptual

representation. Explain each of your conversions with the help of a diagram. (Note: The R&C
Stores database includes the three tables shown in Figure PG.6)

FIGURE PG.6 The R&C Stores Database

602
 Appendix G Object Oriented Databases

The conversion is shown in Figure PG.6-1.

Figure PG.6-1 The Completed OO Conceptual Representation

for the R&C Stores Database

Note that Figure PG.6-1 reflects the following conditions:

 Each REGION can have many STOREs.
 The STORE object includes references to the REGION and EMPLOYEE objects. The
EMPLOYEE object references reflect that an employee is a manager of a store and that each
store employs many employees.
 The EMPLOYEE object has reciprocal relationships with the STORE object. These
relationships reflect that each employee works at one store and that each store is managed by
one employee. The latter relationship makes STORE optional to EMPLOYEE, because not all
employees manage a store.

603
 Appendix G Object Oriented Databases

7. Convert the following relational database tables to the equivalent OO conceptual

representation. Explain each of your conversions with the help of a diagram. ) Note: The
Avion Sales database includes the tables shown in Figure PG.7).

FIGURE PG.7 The Avion Sales Database

The OO representation is shown in Figure PG.7-1.

604
 Appendix G Object Oriented Databases

Figure PG.7-1 The Completed OO Conceptual Representation

for the Avion Sales Database

8. Using the ERD shown in Appendix C, “The University Lab Conceptual Design Verification,
Logical Design, and Implementation,” Figure C.22 (the Check_Out component), create the
equivalent OO representation.

Figure E.22 in Appendix C shows how the M:N relationship of USER and ITEM can be
implemented by modeling this relationship through the Check_Out (bridge) entity.

The OO representation of the M:N USER and ITEM relationship uses a CHECKOUT object. This
object will have its own attributes and it will reference the USER and ITEM objects as shown in
Figure PG.8. Note that the CHECKOUT object is a complex object that contains a group of
repeating attributes: item, location, quantity, and date in.

605
 Appendix G Object Oriented Databases

Figure PG.8 The Completed OO Conceptual Representation

for Figure E.22's Check-Out Component

606
 Appendix G Object Oriented Databases

9. Using the contracting company’s ERD in Chapter 6, “Normalization of Database Tables,”

Figure 6.15, create the equivalent OO representation.

Figure 6.15 depicts the M:N relationship between EMPLOYEE and PROJECT. The object
representation of this relationship is shown in Figure PG.9.

Figure PG.9 The Completed OO Conceptual Representation for Figure 6.15's

Contracting Company ERD

607