Advanced Databases The ODMG Standard for Object Databases

1. Advanced DatabasesThe ODMG Standard for Object Databases

2. ODMG 3 Object Database Standard • Object Database Management Group, formed 1991, intended to: • provide a standard where previously there was none • support portability between products • move away from single language systems • standardize model, querying and programming issues • Enables both designs and implementations to be ported between compliant systems • Currently on version 3.0 • Most vendor products are moving toward compliance; O2 is possibly the closest • Vendors: Object Design,Objectivity, O2 Technology, POET, etc. • URL: www.odmg.org

3. ODMG Components • An architecture for OODBMS. • An object model. • that will act as the logical model for all OODBMS and provide a level of interoperability. • A data definition language (ODL). • a concrete specification of the operations permitted over a schema defined in the data model. • A query language (OQL). • for posing ad-hoc queries but not for data definition or data manipulation. • Language bindings to existing OOPL, (C++, Java, Smalltalk). • the object manipulation languages are the integration of a PL with the ODMG model, so the OOPL’s get persistence and the OODB gets a flexible and standard DB programming language.

4. An Architecture for OODBMS

5. Object Model 1. Data Model • state and structure of data 2. Behaviour model • dynamics of the data • operations on the data 3. Persistence model • the way the persistent and transient data is created & changes status 4. Naming model • naming and accessing objects Object identity Complex objects Types and classes Inheritance hierarchies Encapsulation Late binding/overriding Extensibility Completeness

6. Object Identity • An object’s unique identifier maintained throughout the object’s lifetime • Not user visible • System generated • An object has an existence independent of its value (identity vs equality) thus implying • object sharing • object updating • supports referential integrity • Objects can be cyclic Susan John Mary Name: Age: School: Children: Children: The composition graph is an object network Susan Susan

7. ODMG Model supports databases... • Built-in structured types which permit traditional database modelling to be used • Objects and Literals (atomic and complex) • Relationships and Attributes • Transactions • nested transactions, where transaction semantics only apply to persistent data • Databases • built-in object types for databases, schemas and sub-schemas • Persistence • lifetime of object specified when created • Names • handles by which persistent information can be accessed

8. Objects are addressed through an object identifier are instances of classes are packaged structures can be shared will be stored separately—the oid will be stored in the containing structure properties have different levels of visibility new operations can be user-defined for classes mutable (components can be updated but it remains as the same object) can be arranged into hierarchies name Carole address age house 3 21 street Arcacia Ave name Ian address age 47 Objects, Literals and Mutability

9. Objects, Literals and Mutability • Literals • do not have an identity: are addressed by a physical address • are instances of types • are simple structures • are not shared • will be embedded in any containing structure • properties are all public • no methods can be defined against types • immutable (the value is the identity, so if one of the components change its a different value) • can’t be arranged into hierarchies name Ian address house 3 street Arcacia Ave age 47 name Carole address house 3 street Arcacia Ave age 21

10. Complex Objects • Atomic built-in literal types: • long, short, unsigned long, unsigned short, float, double, string, boolean, char, any, octet • The simplest objects are made up of these atomic types • Complex objects are built from simple ones by applying type constructors which can be nested • Type constructors • collections • record structures Person: <oid:#2, name:Henah, address: “Heaton”, birthDate: 12/02/1990> employee: <oid:#18, name:Neil, address:”Newcastle”, birthDate: 23/09/1970, children: set(#2, #3), dept:#100, manager:#19>

11. Object Types, Collections, Structures • Object Types • interface: specifies abstract behaviour of objects • Instances of an interface cannot be created. • class: specifies state and behaviour of objects • Instances of a class can be created. • Collection types • set (unordered collection without duplicates) • bag (unordered collections with duplicates allowed) • list (ordered collectionwith duplicates allowed) • array ( indexed lists, ordered, of fixed size) • dictionary (unordered, variable size, direct access) • enumerations (explicitly listed group of values, “Mr”, “Ms”) • Record types • struct (tuple) struct Address { unsigned short house, string street, set<Person > residents }

12. Attributes Unidirectional Values could be literals and objects Single as well as multi-valued Relationships Implicitly modelled as properties whose values are objects Frequently bidirectional Bidirectional relationships require inverses 1:many, 1:1, many:many Attributes and Relationships Resort 1 Hotel hotels name location beachType numberOfBeaches transferTime name address numberOfRooms isOverBooked * resort addFacility(F) isChildFriendly(): B checkAvailability(S,R) addFacility(F) showHotels(): set(H)

13. Inheritance • Classes are organized into inheritance hierarchies • The properties and operations of an object type are inherited by its subclasses and so only need to be written once. • Saves code through reuse • Makes code simpler • Provides a compact, well structured and easy to understand • Two kinds of inheritance supported: • Inheritance of Behaviour or ISA • Inheritance of State • Inheritance of behaviour denoted by “:” • interface Person {…}; • class Student : Person {…}; • Inheritance of state denoted by “extends” • class Vehicle {…}; • class Car extends Vehicle {…};

14. Object Definition Language (ODL) • ODL is a specification language used to define the schema of an ODMG compliant database. • ODL supports all semantic constructs of the ODMG object model. • ODL is independent of any programming language, and hence provides means for the portability of database schema across complaint OODBMSs. • The database schema may comprise of: • an ODL module (i.e. a higher level construct for grouping ODL specifications), • some generic object types using interface, • some concrete object types using class, and • some literal types using struct, etc.

15. University schema in ODL • class Person • { attributestring name; • attributestring address; • attribute date birthDate; • short age();}; • class Lecturer extends Person (extent Lecturers) • { attributeshortroom; • relationship set<Student> tutees inverse Student::tutor; • relationship Department worksFor inverse Department::staff; • relationship set<Unit> teaches inverse Unit::taughtBy; • boolean teachUnit(in Unit U); }; • class Student extendsPerson (extent Students) • { attribute string major; • relationship Lecturer tutor inverse Lecturer::tutees; • relationship Course enrolledOn inverse Course::hasStudents; • relationship set<Unit> takes inverse Unit::takenBy; • boolean register(in Course C); • boolean takeUnit(in Unit U); };

16. University schema in ODL – cont … • class Department (extent Departments) • { attribute string name; • relationshipset<Lecturer> staff inverse Lecturer::worksFor; • relationshipset<Course> offers inverse Course::offeredBy; }; • class Course (extent Courses) • { attribute string name; • relationship Department offeredBy inverse Department::offers; • relationship set<Student> hasStudents inverse Student::enrolledOn; • relationship set<Unit> hasUnits inverse Unit::partOf; }; • class Unit (extent Units) • {attribute string name; • attribute string code; • relationship set<Student> takenBy inverse Student::takes; • relationship set<Lecturer> taughtBy inverse Lecturer::teaches; • relationship set<Course> partOf inverse Course::hasUnits; };

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

18. 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 l denotes 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”

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

20. 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).

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

22. Language Binding • Extends an OOPL (C++, Java, Smalltalk) with ODL and OML (Object Manipulation Language) for building OODB applications. • ODL binding defines how ODL constructs are mapped onto an OOPL. • OML binding defines how objects are created, deleted, and modified in an OOPL. • An OOPL may embed OQL where results returned by OQL queries can be manipulated by OOPL.

23. C++ ODL class Department (extent Departments) { attribute string name; relationshipset<Lecturer> staffinverseLecturer::worksFor; relationshipset<Course)> offers inverse Course::offeredBy; }; ODL const char _worksFor[ ] = “worksFor”; const char _offeredBy[ ] = “offeredBy”; class Department : d_Object {public: d_Stringname; d_Rel_Set<Lecturer, _worksFor>staff; d_Rel_Set<Course, _offeredBy>offers; }; d_Extent<Department> Departments(DB1); // for extent // DB1 is the database name C++ for inverse relationships

24. C++ OML • Object Creation d_Ref<Student> S = new(DB1, “Student”) Student; // creates a new Student object in DB1 database d_Ref<Lecturer> L = new(DB1, “Lecturer”) Lecturer; // creates a new Lecturer object in DB1 database • Object Modification S->name = “Richard Spring”;// modifies name attribute of Student S S->address = “Durham”;// similarly L->room = 103; // modifies room attribute of Lecturer L L->tutees.insert_element(&S); // establishes a relationship // between Lecturer L and Student S • Object Deletion L.delete_object(); // deletes the Lecturer object from the database

25. C++ OQL • Define variables for the query result d_Bag<d_Ref<Lecturer>> ComMathStaff; d_Bag<d_Ref<Student>> ToonArmy; • Create an instance of type d_OQL_Query d_OQL_Query q (“select l from l in Lecturers where l.worksFor.name = $1); d_OQL_Query q1 (“select s from s in Students where s.address = “Newcastle”); • Modify the query with Parameters q << “Computing and Maths”;// Imposes a restriction on the query • Execute the query d_oql_execute(q, ComMathStaff); // executes the query q and stores the result into ComMathsStaff variable d_oql_execute(q1, ToonArmy); // executes the query q1 and stores the result into ToonArmy variable

26. Summary • An overview of ODMG standard • An introduction to the Object Data Model • A little bit of ODL • Introduction to OQL • Introduction to language binding