1. 1 ODB Design Handling Associations in ODL M. Akhtar Ali School of Informatics

2. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 2 Lecture outline Different ways of representing links between objects Single/Collection valued Attribute Single reference or Collection of references Relationships Multiplicity of Associations in UML Optional or Mandatory one-to-one, one-to-many, and many- to-many Types of Associations in UML Directed, Bi-directional and Aggregation Mapping Associations in ODL Attributes (Uni-directional relationships), without referential integrity management. True Relationships (Bi-directional) with referential integrity management.

3. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 3 Different ways of representing links Single valued attribute Single reference Collection valued attribute Collection of references A B A B A B1, B2, … Bn A B1 B2 Bn

4. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 4 Multiplicity of associations in UML 0..1 (to-one, optional) 1..1 (to-one, mandatory) 0..* (to-many, optional) 1..* (to-many, mandatory)

5. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 5 Example Class Diagram for UNN-IS

6. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 6 Types of Associations: Bi-Directional These are true relationships so they require automatic referential integrity (in UML shown as lines without arrows or symbols). Since bi-directional, both participating classes (e.g., A and B) know about each other. Any changes to the state (e.g., initialising relationship) of an object of class A may affect the state of some object(s) of class B and vice versa. For example, when a Student object’s enrolledOn relationship is initialised with a reference to a Course object, that Course object’s students relationship will be automatically updated to include that Student object as one of the students enrolled on the course.

7. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 7 Types of Associations: Aggregation Aggregation represents a part-whole relationship between two classes. Two kinds of Aggregation: Weak or shared aggregation (shown by ) Lets you model a part-whole relationship in which one object owns another object, but yet other objects can own that object as well. For example, several Person objects may share a same Address object. However, if no Person or Department object is associated with an Address object then that Address object should be deleted. Strong aggregation/composition (shown by ) Lets you model the part-whole relationship where one object exclusively owns another object. The life-time of the part depends on the life-time of the whole object. For example, a Person object owns a Passport object exclusively and whenever a Person object is deleted any associated Passport objects are also deleted.

8. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 8 Bi-Directional Associations in ODL Syntax diagram of relationship declaration in ODL

9. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 9 Bi-Directional Associations in ODL … Implementing the to-one (1..1) relationship from Student to Course class. relationship Course enrolledOn inverse Course::students;

10. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 10 Bi-Directional Associations in ODL … Implementing the to-many (0..*) relationship from Course to Student class. relationship set students inverse Student::enrolledOn;

11. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 11 Aggregation in ODL Week Aggregation (part-whole relationship) Maps onto an attribute in the aggregating class. Single valued (if 0..1 or 1..1). Collection valued (if 0..* or 1..*). For example, a Course is a whole object made up of several Module objects. The modules aggregation in the Course class is defined as follows: attribute set modules; The application need to maintain the integrity of modules attribute and to make sure that the set must contain at least one reference to a module object.

12. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 12 Aggregation in ODL … Strong Aggregation (part-whole relationship) Maps onto an attribute in the aggregating class. Single valued (if 0..1 or 1..1). Collection valued (if 0..* or 1..*). The aggregated class becomes a structured literal if it does not participate in any association with another class. Otherwise, it becomes a self-standing class. For example, a Person object owns at least one or more Passport objects. The aggregated class: Passport becomes a structure: struct Passport { string passportNum; string nationality; date issueDate; date expiryDate; }; The passports aggregation in the Person class is defined as follows: attribute set passports; There is no automatic referential integrity for the passports attribute.

13. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 13 Association Classes When the association is one-to-one The association can be implemented as bi- or uni-directional depending on the situation. Add the attributes of the Association class to the participating class whose objects are more likely to get involved in the relationship. For example, suppose that every department has a chair who is one of the lecturer’s in the department. It would be better to define the association as an attribute (uni- directional relationship) in Department including startDate as only few lecturer will ever participate in the relationship. attribute Lecturer hasChair; attribute date startDate;

14. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 14 Association Classes … When the association is one-to-many The association can be implemented as bi- or uni-directional depending on the situation though preferably bi-directional. Add the attributes of the Association class to the participating class on the to-many side. For example, part-time lecturers works for a department for certain hours. It is better to use bi-directional relationship for the above. class PartTimeLecturer {... relationship Department worksFor inverse Department::partTimeStaff; attribute unsigned short hours; };

15. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 15 Association Classes … When the association is many-to-many The association class becomes a self-standing ODL class with bi-directional relationships to both participating classes. The attributes of the association class becomes attribute of the ODL class representing it. For example, the many-to-many association between Student and Module (having the association class) becomes: class StudentModule (extent AllStudentMoudles) { attribute unsigned short marks; relationship Student ofStudent inverseStudent::takes; relationship Module forModule inverseModule::takenBy; };

16. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 16 Association Classes … When the association is many-to-many … The Student class will include to-many relationship with StudentModule class: relationship list takes inverseStudentModule::ofStudent; list is used to keep track of the order in which modules were taken. The Module class will include to-many relationship with StudentModule class: relationship set takenBy inverseStudentModule::forModule;

17. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 17 Association Classes … But in some situations you may implement many-to- many Association classes differently. That is you may embed the association class inside one of the participating classes if navigation from both sides is not desirable/required. For example: In the above case the association class can be embedded inside the Invoice class if it is not necessary for products to have information about invoices on which they appear.

18. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 18 Association Classes … struct ItemType { unsigned short units; Productitem; }; class Invoice (...) {... // attributes etc attribute set items; }; class Product (...) {... // attributes etc, no need to define attribute // of type Invoice or ItemType or relationship // with Invoice class. }; Invoice objects will not be dependent upon Product objects or will not require joins or navigation to obtain information about items.

19. Advanced Databases – Lecture # 11: The ODMG Standard for Object Databases 19 UNN-IS COMPLETE CLASS DIAGRAM