The document discusses mapping problem domain objects to different object persistence formats, including files, object-oriented databases (OODBMS), object-relational databases (ORDBMS), and relational databases (RDBMS). It provides rules for mapping problem domain classes and relationships like inheritance, aggregation, and association to tables and columns when using an OODBMS, ORDBMS, or RDBMS. Overall, the rules aim to maximize portability of problem domain classes while accounting for limitations of each persistence format, such as lack of inheritance support in ORDBMS and RDBMS.

1. Mapping Problem Domain Objects
to Object-Persistence Formats
1

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
2

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 “
3

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
4

5. Appointment System Example
5

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 6

7. Mapping problem domain objects to
Single I-B OODBMS
7

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”
8

9. Mapping problem domain objects to
an ORDBMS format
Assumption,
o supports
-Objects IDs,
-Multi valued attributes,
-Stored procedures
o Does not support
-inheritance
9

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

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

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

13. Mapping problem domain objects to
an ORDBMS schema example
13

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”
14

15. Mapping problem domain objects to
an RDBMS format
o Similar to the mapping to an ORDBMS
o Assumptions(ORDBMS) are no longer valid
15

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

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

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
18

19. Mapping Problem Domain objects to
RDBMS schema example
19

20. Continued…
Conclusion :
“use RDBMS for storage of objects than the other approaches because are by
far the most popular format”
20

21. 21