1 / 30

ODB Design: Handling Associations and Inheritance in ODL

ODB Design: Handling Associations and Inheritance in ODL. M. Akhtar Ali School of CEIS. Lecture outline. Different ways of representing links between objects Multiplicity of Associations in UML Types of Associations in UML Mapping Associations in ODL Modelling with inheritance

sybil-arnold
Télécharger la présentation

ODB Design: Handling Associations and Inheritance in ODL

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ODB Design: Handling Associations and Inheritance in ODL M. Akhtar Ali School of CEIS

  2. Lecture outline • Different ways of representing links between objects • Multiplicity of Associations in UML • Types of Associations in UML • Mapping Associations in ODL • Modelling with inheritance • Different kinds of inheritance • Handling inheritance in ODL • Summarizing OODB Design Advanced Databases (CM036) – Lecture # 10: 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 Advanced Databases (CM036) – Lecture # 10: 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) Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  5. UNN-IS COMPLETE CLASS DIAGRAM Advanced Databases (CM036) – Lecture # 10: 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. Advanced Databases (CM036) – Lecture # 10: 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. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  8. Bi-Directional Associations in ODL • Syntax diagram of relationship declaration in ODL Advanced Databases (CM036) – Lecture # 10: 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; Advanced Databases (CM036) – Lecture # 10: 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<Student> students inverse Student::enrolledOn; Advanced Databases (CM036) – Lecture # 10: 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<Module> 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. Advanced Databases (CM036) – Lecture # 10: 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<Passport> passports; • There is no automatic referential integrity for the passports attribute. Advanced Databases (CM036) – Lecture # 10: 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; attributedate startDate; Advanced Databases (CM036) – Lecture # 10: 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; attributeunsignedshort hours; }; Advanced Databases (CM036) – Lecture # 10: 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 • inverse Student::takes; • relationship Module forModule • inverse Module::takenBy; }; Advanced Databases (CM036) – Lecture # 10: 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: relationshiplist<StudentModule> takes inverse StudentModule::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: relationshipset<StudentModule> takenBy inverse StudentModule::forModule; Advanced Databases (CM036) – Lecture # 10: 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. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  18. Association Classes … • struct ItemType { • unsigned short units; • Product item; • }; • class Invoice (...) { • ... // attributes etc • attribute set<ItemType> 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. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  19. Modelling with Inheritance • Inheritance is usually termed as specialization/generalization relationship among super-classes and sub-classes. • Super-class: An entity type or class that includes one or more distinct sub-groupings of its instances. • Sub-class: A distinct sub-grouping of instances of an entity type or class. • Each instance of a sub-class is also an instance of the super-class. • Generalization relationship specifies that a super-class generalizes the properties of several sub-classes. • The Super-class contains the properties and behaviour that the sub-classes share. • All Sub-classes inherit the properties and behaviour of the super-class. • Specialization relationship specifies that several sub-classes are in some way specialized form of the super-class. • A Sub-class may include properties not present in the super-class or other sub-classes thereby making it distinguished. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  20. Specialization Process • The process of maximizing the differences between members of an entity by identifying their distinguishing characteristics. • It is a top-down approach to defining a set of super-classes and their sub-classes. • Once super-classes and sub-classes are identified, attributes and operations specific to sub-classes and their relationships with other classes are then identified. • For example, having defined Person class, we then define Lecturer and Student classes to be sub-classes of Person class. • Given the Student class, there are differences between under-graduate and post-graduate students e.g., under-graduate have personal tutors but post-graduates don’t. Also, post-graduate write dissertation where as under-graduate don’t. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  21. Generalization Process • The process of minimizing the differences between members of an entity by identifying their common characteristics. • It is a bottom-up approach which results in the identification of a generalized super-class from the original entity types. • We try to identify similarities among the original entity types e.g., common attributes, relationships, and operations. • For example, full-time lecturers may be module tutor and supervise post-graduate’s dissertations, whereas part-time lecturer only teach on certain modules and work for a department for certain hours. This leads to a generalized Lecturer as super-class of more specialized classes FullTimeLecturer and PartTimeLecturer as its sub-classes. • Generalization can be seen as reverse of specialization. In practice, both processes are used to complement each other. That’s we refer to them as specialization/generalization. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  22. Different kinds of inheritance • Single verses Multiple Inheritance • In Single inheritance, a sub-class has only one super-class. • In Multiple inheritance, a sub-class has more than one super-class. • Inheritance of Behaviour • A sub-class inherits only the behaviour (operations) of a super-class. The super-class in this case usually only defines operations i.e., an interface. For example, defining a common interface for students and lecturers. • It is also known as is-a or is-a-kind relationship. • Inheritance of State • When a sub-class extends a super-class by adding attributes, operations or relationships and both of them are concrete classes. The sub-class inherits every thing defined in the super-class. For example, Lecturer and Student classes inherit all the attributes and operations of Person class. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  23. Interface verses Class • An interfaceis a classifier that represents an abstract collection of operations. • A class may have one or more interfaces, and an interfaces can group operations of several different classes. • Although Person class is super-class of Student and Lecturer, yet it would be useful to define a common interface. • Given the Identification interface, we can have several classes that would realize the same interface. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  24. Example Class Diagram for UNN-IS Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  25. Handling inheritance in ODL • The inheritance of behaviour is represented by “:” • For example: class Person : Identification {...}; • Defines that Person class inherits all the operations defined in the Identification interface. The object type after the : must be an interface. • The inheritance of state is represented by “extends” • For example: class Student extends Person {...}; • Defines that Student class inherits all the operations, relationships and attributes defined in the Person class. • A class extends another class, an interface may inherit from another interface but not from a class. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  26. Implementing Inheritance in UNN-IS interface Identification { short getAge(); void changeAddress(in Address addr); date getBirthDate(); string getName(); string getGender(); set<Address> getAddresses(); }; class Person : Identification {...}; class Student extends Person {...}; class Lecturer extends Person {...}; class UGStudent extends Student {...}; class PGStudent extends Student {...}; class FullTimeLecturer extends Lecturer {...}; class PartTimeLecturer extends Lecturer {...}; Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  27. Summarizing OODB Design: Classes • Each UML class becomes an ODL class. • Each attribute or method in a UML class becomes an attribute or operation of an ODL class with appropriate types. • Specify a suitable extent name unless the class diagram explicitly indicates otherwise. • Specify a unique key if one or more attributes of a UML class are shown in bold or tagged with {PK}. • For a composite attribute, specify a structure literal type. • Specify a suitable positive integer type (i.e. unsigned short or unsigned long) if an attribute / operation of a UML class has type int {+} or integer {+}. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  28. Summarizing OODB Design: Associations • Bi-Directional Associations • Define relationships in both classes with appropriate types and inverses. • Aggregations • Week: Define a single or collection valued attribute of an appropriate type in the aggregating class. • Strong: Define the aggregated class as and define a single or collection valued attribute of the struct type in the aggregating class. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  29. Summarizing OODB Design: Associations… • Association Classes • One-to-one: Define a single or collection valued attribute and include the attributes of the association class in one of the participating classes. • One-to-many: Define a bi-directional relationship in both classes and include attributes of the association class in the class on the to-many side. • Many-to-many: Define a new class for the association class including all of its attributes. Define bi-directional relationships between the new class and the participating classes with appropriate types and inverses. In certain cases (e.g. when navigation from classes at both ends of the association is not required) it be desirable to embed the association class in one of the classes that participate in the association. See an example of this scenario near the end of week 11 lecture. Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

  30. Summarizing OODB Design: Inheritance • Single Inheritance interface A {...}; class B {...}; class C : A {...}; interface D : A {...}; • Multiple Inheritance class E : D extends B {...}; • Inheritance of Behaviour class C : A {...}; • Inheritance of State class F extends E {...}; Advanced Databases (CM036) – Lecture # 10: The ODMG Standard for Object Databases

More Related