1

Mapping Problem Domain Objects to Object-Persistence Formats

2

Introduction

o Each different formats can have some conversion requirements

o Regardless of the object persistence format chosen,

-supporting primary keys and foreign keys to the problem domain classes

additional processing required

(i.e.,)developer have to set a value for foreign key when adding the relationships

Too costly

o The design of the PD classes to be independent of any specific object persistence

environment increasing their portability and potential reuse

3

Continued…

Types of Object persistence formats

Files

Object oriented databases

Object relational databases

Relational databases

From a practical perspective ,

”File formats are used mostly for temporary storage “

4

Mapping problem domain objects to an OODBMS format

o Straight forward

o Each problem domain class should have a corresponding object persistence class

o DAM class manage the interaction between the object persistence class and

problem domain class

o Once the object persistence format is adopted ,only the DAM will have to be

modified

o This approach increases the portability and potential reuse of the problem domain

classes

5

Appointment System Example

6

Mapping problem domain objects to an OODBMS format -Rules

Rule 1a:

o Add an attribute(s) to the OODBMS class(es) that represents the subclass(es) that

contain an ObjectID of the instance stored in the OODBMS class that represent s

the “additional “ superclass(es).

o The multiplicity of this subclass new association from the subclass to the

“superclass” should be 1..1.

o An exclusive-or(XOR) constraint must be added between the associations. –each

“additional superclass” (OR)

Rule 1b:

o Flatten the inheritance hierarchy of the OODBMS classes by copying the attributes

and methods of the additional OODBMS superclass(es) down to all of the

OODBMS subclasses and remove the additional superclass from the design

7

Mapping problem domain objects to Single I-B OODBMS

8

Continued…

Pros:

Maximum flexibility of the maintenance of design Cons:

Reduces the overall efficiency of the design

Conclusion:

“if the multiple inheritance used in the problem domain ,but not supported by the OODBMS, then the multiple inheritance should be factored out of the OODBMS classes”

9

Mapping problem domain objects to an ORDBMS format

Assumption,

o supports

-Objects IDs,

-Multi valued attributes,

-Stored procedures

o Does not support

-inheritance

10

Mapping problem domain objects to an ORDBMS format -Rules

Rule 1:Map all concrete problem domain classes to the ORDBMS tables.

Also if an abstract problem domain class has multiple direct subclasses, map the

abstract class to an ORDBMS table.

Rule 2:Map single valued attributes to columns of the ORDBMS tables.

Rule 3:Map methods and derived attributes to stored procedures or to program

modules.

Rule 4:Map single-valued aggregation and association relationships to a column that

can store an Object ID. Do this for both sides of the relationship.

Rule 5:Map multi-valued attributes to a column that can contain a set of values .

11

Continued…Rule 6:Map repeating groups of attributes to a new table and create a one-to-many

association from the original table to the new one .

Rule7:Map multi-valued aggregation and association relationships to a column that

can store an Object IDs. Do this for both sides of the reationship.

Rule 8:For aggregation and association relationships of mixed type(one-to-many or

many-to-one),on the single –valued side(1..1or 0..1) of the relationship, add a

column that can store a set of Object IDs.

The values contained in this new column will be the Object IDs from the

instances of the class on the multi-valued side.

On the multi-valued side(1..*or0..*),add a column that can store a single

Object ID that wll contain the value of the instance of the class on the single-valued

side.

12

Continued…

For generalization/inheritance relationships:

Rule 9a: Add a column(s) to the table(s) that represents the subclass(es) that will contain an

Object ID of the instance stored in the table that represents the superclass. The multiplicity

of this new association from the subclass to the “superclass” should be 1..1.

If the superclasses are concrete i.e.,they can be instantiated themselves,then the

multiplicity from the superclass ta the baseclass is 0..*,otherwiseit is 1..1.An exclusive-

or(XOR) constraint must be added between the associations. –each “superclass”

(OR)

Rule 9b:Flatten the inheritance hierarchy by copying the superclass attributes down to all of

the subclasses and remove the superclass from the design .

13

Mapping problem domain objects to an ORDBMS schema example

14

Continued…

Conclusion :

“the development and production cost of using an OODBMS may be less than

the development and production cost implementation cost of using an

ORDBMS”

15

Mapping problem domain objects to an RDBMS format

o Similar to the mapping to an ORDBMS

o Assumptions(ORDBMS) are no longer valid

16

Mapping problem domain objects to an RDBMS format-Rules

Rule 1:Map all concrete problem domain classes to the RDBMS tables.

also if an abstract problem domain class has multiple direct subclasses, map the

abstract class to a RDBMS table.

Rule 2:Map single valued attributes to columns of the RDBMS tables.

Rule 3:Map methods and derived attributes to stored procedures or to program

modules.

Rule 4:Map single-valued aggregation and association relationships to a column that

can store the key of the related table . Do this for both sides of the relationship.

Rule 5:Map multi-valued attributes and repeating groups of attributes to a new table

and create a one-to-many association from the original table to the new ones .

17

Continued…

Rule6:Map multi-valued aggregation and association relationships to a new

associate table that relates the two original table together.

copy the primary key from both original table to the new associate table

Rule 7:For aggregation and association relationships of mixed type, copy the

primary key from the single-valued side (1..1 or 0..1) of the relationship to a

new column in the table on the multi-valued side (1..* or 0..*) of the

relationship that can store the key of the related table.

18

Continued…

Rule 8a: Ensure that the primary key of the subclass instance is the same as the primary key of

the superclass.

The multiplicity of this new association from the subclass to the “superclass” should be 1..1.

If the superclasses are concrete i.e.,they can be instantiated themselves,then the multiplicity

from the superclasses the subclass is 0..*,otherwiseit is 1..1.

An exclusive-or(XOR) constraint must be added between the associations. –each

“superclass” (OR)

Rule 8b: Flatten the inheritance by copying the superclass attributes down to all of the

subclasses and remove the superclass from the design

19

Mapping Problem Domain objects to RDBMS schema example

20

Continued…

Conclusion :

“use RDBMS for storage of objects than the other approaches because are by

far the most popular format”

21

Thank

you !

!!