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

2,236 views

Published on

Published in: Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,236
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
34
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

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

  1. 1. Mapping Problem Domain Objects to Object-Persistence Formats 1
  2. 2. Introductiono Each different formats can have some conversion requirementso 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. 3. Continued…Types of Object persistence formats  Files  Object oriented databases  Object relational databases  Relational databasesFrom a practical perspective , ”File formats are used mostly for temporary storage “ 3
  4. 4. Mapping problem domain objects to an OODBMS formato Straight forwardo Each problem domain class should have a corresponding object persistence classo DAM class manage the interaction between the object persistence class and problem domain classo Once the object persistence format is adopted ,only the DAM will have to be modifiedo This approach increases the portability and potential reuse of the problem domain classes 4
  5. 5. Appointment System Example 5
  6. 6. Mapping problem domain objects to an OODBMS format -RulesRule 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. 7. Mapping problem domain objects to Single I-B OODBMS 7
  8. 8. Continued…Pros: Maximum flexibility of the maintenance of designCons: Reduces the overall efficiency of the designConclusion: “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. 9. Mapping problem domain objects to an ORDBMS formatAssumption,o supports -Objects IDs, -Multi valued attributes, -Stored procedureso Does not support -inheritance 9
  10. 10. Mapping problem domain objects to an ORDBMS format -RulesRule 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. 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. 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. 13. Mapping problem domain objects to an ORDBMS schema example 13
  14. 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. 15. Mapping problem domain objects to an RDBMS formato Similar to the mapping to an ORDBMSo Assumptions(ORDBMS) are no longer valid 15
  16. 16. Mapping problem domain objects to an RDBMS format-RulesRule 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. 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 tableRule 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. 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. 19. Mapping Problem Domain objects to RDBMS schema example 19
  20. 20. Continued…Conclusion : “use RDBMS for storage of objects than the other approaches because are by far the most popular format” 20
  21. 21. 21

×