Object Database SystemBy Sudarshan

MCA Sem V

OO Data Modelling: Example Case Study: UNN Information System (UNNIS) Northumbria University has several academic departments. Each department provides one or more courses. Each course is composed of several modules, where a module may be part of more than one course. A student enrolls on a course and every year takes a specified number of modules. Note that several students are usually registered for a course. Every student is assigned a tutor at the start of the course, who is a lecturer in the department providing the course. A lecturer works for a department and usually teaches on several modules. Each module has a module tutor who is a lecturer. A lecturer may be a tutor of several modules.

Class Diagram for UNN-IS

Mapping Class Diagrams into ODL At this stage, we are dealing with classes, attributes, and operations. Different associations and inheritance will be covered next.

Mapping (general case) 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.

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

University schema in ODL cont class Department (extent Departments) { attribute string name; relationship set staff inverse Lecturer::worksFor; relationship set offers inverse Course::offeredBy; }; class Course (extent Courses) { attribute string name; relationship Department offeredBy relationship set hasStudents relationship set hasUnits class Unit (extent Units) { attribute string name; attribute string code; relationship set takenBy relationship set taughtBy relationship set partOf

inverse Department::offers; inverse Student::enrolledOn; inverse Unit::partOf; };

inverse Student::takes; inverse Lecturer::teaches; inverse Course::hasUnits; };

UNN-IS COMPLETE CLASS DIAGRAM

OQL for querying the database OQL is the the query language in ODMG standard. OQL is a superset of the SQL (in selectfrom-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). OQL includes operators for creating collections, arithmetic and logical operators, aggregation, sorting and

Retrieving Objectsselect l from l in Lecturers where l.address = Newcastle The query returns all Lecturer objects who live in Newcastle. The type of the query result is bag. 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.

orselect l from Lecturers as l where l.address = Newcastle

orselect l from Lecturers l where l.address = Newcastle

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.

Database Entry Points To use named objects, you dont have to write a query in select-fromwhere 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.

Retrieving data from multiple objects Without using Joinsselect 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 Joinsselect 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