ODMG: ODL and OQL

1. ODMG: ODL and OQL This lecture is a short version of: Lecture 11 (on ODL) & Lecture 12 (on OQL) M. Akhtar Ali School of Informatics

2. Lecture outline • Different ways of representing links between objects • Mapping Associations in ODL • Different kinds of inheritance • Handling inheritance in ODL • OQL (object query language) Advanced Databases (CM036) – Lecture # 11 & 12: 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 # 11 & 12: The ODMG Standard for Object Databases

4. UNN-IS COMPLETE CLASS DIAGRAM Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases

5. 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 # 11 & 12: The ODMG Standard for Object Databases

6. 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 # 11 & 12: The ODMG Standard for Object Databases

7. 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 # 11 & 12: The ODMG Standard for Object Databases

8. 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 # 11 & 12: The ODMG Standard for Object Databases

9. 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 # 11 & 12: The ODMG Standard for Object Databases

10. 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 # 11 & 12: The ODMG Standard for Object Databases

11. 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 # 11 & 12: The ODMG Standard for Object Databases

12. 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 # 11 & 12: The ODMG Standard for Object Databases

13. 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 # 11 & 12: The ODMG Standard for Object Databases

14. 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 # 11 & 12: The ODMG Standard for Object Databases

15. 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 # 11 & 12: The ODMG Standard for Object Databases

16. 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 # 11 & 12: The ODMG Standard for Object Databases

17. Example Class Diagram for UNN-IS Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases

18. 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 # 11 & 12: The ODMG Standard for Object Databases

19. 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 # 11 & 12: The ODMG Standard for Object Databases

20. OQL – for querying the database • OQL is the the query language in ODMG standard. • OQL is a superset of the SQL (in select-from-where clauses). • It can be interactive as well as embedded in other programming languages. • It is a declarative language. • OQL can invoke operations written in programming languages (C++, Java, Smalltalk). • The operators in the language can be freely composed. • OQL includes operators for creating collections, arithmetic and logical operators, aggregation, sorting and grouping. Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases

21. Retrieving Objects • The query returns all Lecturer objects who live in Newcastle. The type of the query result is bag<Person>. • Whenever the scope of an OQL query is a collection (e.g. Lecturers, a set of Lecturer objects), we define an iterator variable that ranges over the collection (e.g. l in Lecturer). In the query ldenotes an object of type Lecturer. select l from l in Lecturers where l.address = “Newcastle” or select l from Lecturers as l where l.address = “Newcastle” or select l from Lecturers l where l.address = “Newcastle” Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases

22. Database Entry Points • Named objects are entry points to the database (same as table or view names in RDBs). • Class extents are usually used to refer to in OQL queries. • Some frequently used objects can be assigned unique names e.g. ComMath a named Department object or AdvDB as named Unit object. • To use named objects, you don’t have to write a query in select-from-where form. You can simply write: ComMath.staff • which returns all staff member objects in the school of computing and mathematics. Students • which returns a set of all Student objects in the database. Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases

23. Retrieving data from multiple objects • Without using Joins select struct(LName:l.name, DName:l.worksFor.name) from l in Lecturers • The query contains an implicit join based on the relationship that exists between Lecturer and Department object types and due to the path expression l.worksFor.name. However, the user does not need to tell the OQL compiler. • Using Joins select struct(LName:l.name, DName:d.name) from l in Lecturers, d in Departments where l.worksFor = d • Here the user explicitly tells that a join should be performed on the basis of matching OIDs (l.worksFor and d denote an OID of a Department object). Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases

24. Unnesting and Nesting Collections • Unnesting a collection select struct(LName:l.name, SName:s.name) from l in Lecturers, s in l.tutees • The query retrieves names of lecturers and their tutees in pairs. • The query iterates over the collection Lecturers via the variable l; then iterates over l.tutees (a set of Student objects) via the variable s; then projects out name from l and name from s. The type of the query result is bag<LName:string, SName:string>. • Nesting a collection select struct(LName:l.name, SNames:(select s.name from s in l.tutees) from l in Lecturers • The query retrieves for every lecturer, his/her name and all his/her tutees names. • Here instead of unnesting l.tutees, the query iterates over l.tutees via s and projects out name attribute and then constructs a collection out of it. The type of the query is bag<LName:string, SNames:bag<string>>. Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases

25. Summary of OODB • An overview of ODMG standard • An introduction to the Object Data Model • Comprehensive introduction to ODL • Introduction to OQL Advanced Databases (CM036) – Lecture # 11 & 12: The ODMG Standard for Object Databases