Mapping Problem Domain Objects to Object-Persistence Formats(OOAD)

Mapping Problem Domain Objects
to Object-Persistence Formats

1

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

2

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 “

3

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

4

Appointment System Example

5

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 6

Mapping problem domain objects to
Single I-B OODBMS

7

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”

8

an ORDBMS format
Assumption,

o supports

-Objects IDs,

-Multi valued attributes,

-Stored procedures

o Does not support

-inheritance

9

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 .

10

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.
11

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 .

12

an ORDBMS schema example

13

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”

14

an RDBMS format

o Similar to the mapping to an ORDBMS

o Assumptions(ORDBMS) are no longer valid

15

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 .

16

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.

17

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

18

Mapping Problem Domain objects to
RDBMS schema example

19

Continued…
Conclusion :

“use RDBMS for storage of objects than the other approaches because are by
far the most popular format”

20

Mapping Problem Domain Objects to Object-Persistence Formats(OOAD)

Recommended

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Mapping Problem Domain Objects to Object-Persistence Formats(OOAD) (20)

More from Meenakshi Devi (7)

Recently uploaded (20)

Mapping Problem Domain Objects to Object-Persistence Formats(OOAD)