CHAPTER 11

Concepts for Object-Oriented Databases

Overview of Object-Oriented ConceptsObject-oriented databases give designer to specify The structure of complex objectsThe operations that can be applied to objects

Increase uses of OOPLObjectState(Value)Behavior(operations)transient vs. persistent

Overview of Object-Oriented Concepts (Cont.)Maintain a direct correspondence between real-world and database objectsA real-world object may have different names for key attributes in different relations in traditional database systems E.G. EMP_ID, SSN in different relations

OODBs provide a unique system-generated object identifier for each object

Overview of Object-Oriented Concepts (Cont.)

Objects may have an object structure of arbitrary complexityInformation about a complex object is often scattered over many relations or records in traditional database systems1NF in relational databases

Object Identityunique identity for each independent object stored in the database created by a unique, system-generated object identifier, or OID

Object Identity (Cont.)properties of OID immutable: the OID value of a particular object should not change Each OID is used only once.Most OO database systems allow for the representation of both objects and values (having no OIDs)

Object Structure(i, c, v)i: a unique object identifier (OID) c: a type constructorbasic type: atomstructured type: tuplecollection type: array vs. list, set vs. bag System supports (integer,real,string,Boolean,)number of elementsdistinct vs.duplicateorderunorder

v: object statec=atom ::: an atomic value from the domainc=set ::: a set of object identifiers {i1, i2, , in}c=tuple ::: a tuple of c=list ::: an ordered list [i1, i2, , in]c=array ::: a single-dimensional array of object identifiersc=bagObject Structure (Cont.)ij : OID aj : attribute name

Example 1: Complex Object

Example 1: Complex Object (Cont.)o1=(i1,atom,Houston)o2=(i2,atom,Bellaire)o3=(i3,atom,Sugarland)o4=(i4,atom,5)o5=(i5,atom,Research)o6=(i6,atom,1988-05-22)o7=(i5,set,{i1, i2, i3}) ::: the set of locations for department 5

Example 1: Complex Object (Cont.)o8=(i8, tuple, ) ::: department 5o9=(i9, tuple, )o10=(i10,set,{i12, i13, i14})o11=(i11,set,{i15, i16, i17})o12=(i12, tuple, )employee John B. Smith

Graphical representation of a complex objectLEGEND:objecttuplesetDNAME DNUMBER MGR LOCATIONS EMPLOYEES PROJECTSMANAGER MANAGERSTRATDATEO5O4O9O7O10O11O8O1O2O3Houston Bellaire Sugarland i8:tuple i5:atom i4:atom i9:tuple i7:set i10:set i11:set i15: .....tuple i16: .....tuple i17: .....tuple i12: .....tuple i13: .....tuple i14: .....tuple i6: atomO61988-05-22V4V9V5V7V10V11V1V2V3V6Research 5Object instance of department type

Comparisons of the states of two objects for equalityidentical states (deep equality)the graphs representing their states are identical in every respect, including the OIDs at every levelequal states (shallow equality)the graph structures must be the sameall the corresponding atomic values in the graphs should be the sameallow some corresponding internal nodes in the two graphs to have objects with different OIDs(Current Values)

Example 2: Identical vs. Equal Object Stateso1=(i1, tuple, ) o2=(i2, tuple, ) o3=(i3, tuple, ) o4=(i4, atom, 10) o5=(i5, atom, 10) o6=(i6, atom, 20)o1 and o2 have equal stateso1 and o3 have identical stateso4 and o5 have identical stateso4 and o5 are equal but not identical

Using OODDL to define Employee, Date, and Department typesdefine type tuple (

Employee: fname: minit: lname: ssn: birthdate: address sex: salary: supervisor: dept:

string;char;string;string;Date;string;char;float;Employee;Department);

Attributes refer to Employee, Department objects relationship among objects

define type tuple (

define type tuple ( Date: year: month: day:

Department dname: dnumber: mgr:

locations: employees: projects:

integer;integer;integer; );

string;integer;tuple (manager: startdate:set (string);set (Employee);set (Project); );Employee;Date; );Using OODDL to define Employee, Date, and Department types (Cont.)Inverse reference: dept. of employee employee of dept.set of references

Specifying Object Behavior via Class OperationsDefine the behavior of a type of object based on the operations that can be externally applied to object of that typecreate (insert) or destroy (delete) objectsupdate the object stateretrieve parts of the object stateapply some calculationscombination of retrieval, calculation, and updateIn relational model, selecting, inserting, deleting and modifying tuples are generic.

Specifying Object Behavior via Class Operations (Continued)interfacedefine the name and arguments (parameters) of each operationsignature (included in the class definition)implementationmethod (defined using programming languages)it is invoked by sending a message to the object to execute the corresponding methodOperations 1. object constructors 2. object destructor 3. object modifier 4. retrieval

Using OODDL to define Employee and Department classesoperations age create_emp: destroy_emp :end Employee;integer;Employee;boolean;define class type tuple (

Employee: fname: minit: lname: ssn: birthdate: address sex: salary: supervisor: dept:

string;char;string;string;Date;string;char;float;Employee;Department);type definitiondefinition of operations

Using OODDL to define Employee and Department classes (Continued)define class type tuple (Department

dname:dnumber:mgr:

locations:employees:projects:

string;integer;tuple (manager: startdate:set (string);set (Employee);set (Project); );Employee;Date; );operations number_of_emps : integer; create_dept: Department, destroy_dept: boolean; assign_emp (e: Employee): boolean; (* adds a new employee to the department *) remove_emp (e: Employee): boolean; (* removes an employee from the department *)end Department;type definitiondefinition of operations

Class Operationsobject constructorcreate a new objectdestructordestroy an objectobject modifiermodify various attribute of an objectdot notationd.no_of_emps where d is a reference to a department object and no_of_emps is an operationrefer to attributes of an object: d.dnumber, d.mgr.startdate

Specifying Object Persistence via Naming and Reachabilitytransient objectexist in the executing program and disappear once the program terminatespersistent objectstored in the database and persist after program terminationnaming mechanismgive an object a unique persistent name through which it can be retrieved by this and other program

Reachabilityreachability mechanismmake the object reachable from some persistent objectan object B is said to be reachable from an object A if a sequence of references in the object graph lead from object A to object Be.g., if o8 is persistent, then all other objects also become persistent (next slide)N defines a persistent collection of objects of class Ccreate a named persistent object N, whose state is a set or list of objects of some class Cadd objects of C to the set or list and make them reachable from N

Graphical representation of a complex objectLEGEND:objecttuplesetDNAME DNUMBER MGR LOCATIONS EMPLOYEES PROJECTSMANAGER MANAGERSTRATDATEO5O4O9O7O10O11O8O1O2O3Houston Bellaire Sugarland i8:tuple i5:atom i4:atom i9:tuple i7:set i10:set i11:set i15: .....tuple i16: .....tuple i17: .....tuple i12: .....tuple i13: .....tuple i14: .....tuple i6: atomO61988-05-22V4V9V5V7V10V11V1V2V3V6Research 5Object instance of department type

Creating persistent objects by naming and reachabilitydefine class DepartmentSet:type set (Department);

operations add_dept(d: Department):boolean; remove_dept (d: Department): boolean, create_dept_set: DepartmentSet; destroy_dept_set:boolean;end DepartmentSet;

persistent name AllDepartments: DepartmentSet ; (* AllDepartments is a persistent named object of type set DepartmentSet*)

.....

d := create_dept ; ..... (* creates a new department object in the variable d *)b := AllDepartments.add_dept (d) ; (* make d persistent by adding it to the persistent named object AllDepartments *)AllDepartments object: extent of the class Department

differences between traditional databases and OO databasestraditional database modelswhen an entity type or class is defined in EER, it represents both type declaration and persistent setOO approachesa class declaration specifies only the type and operations for a class of objectsuser must define a persistent object whose value is the collection of references to all persistent

Type Hierarchies and Inheritancetype (or class) hierarchydefine new types based on other predefined types (or classes)typetype namea number of attributes (instance variables)operations (methods)TYPE_NAME: function, function, , functionPERSON: Name, Address, Birthdate, Age, SSN EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority STUDENT subtype-of PERSON: Major, GPAfunctions with zero argumentsfunctions

Type Hierarchies and InheritanceGEOMETRY_OBJECT: Shape, Area, ReferencePoint RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height TRIANGLE subtype-of GEOMETRY_OBJECT: Side1, Side2, Side3 CIRCLE subtype-of GEOMETRY_OBJECT: Radius attributes(triangle,rectangle,circle)methodattribute

Type Hierarchies and Inheritance (Cont.)RECTANGLE subtype-of GEOMETRY_OBJECT (Shape=rectangle): Width, Height TRIANGLE subtype-of GEOMETRY_OBJECT (Shape=triangle): Side1, Side2, Side3 CIRCLE subtype-of GEOMETRY_OBJECT (Shape=circle): Radius

Inheritancemultiple inheritancewhen T is a subtype of two (or more) types, T inherits the functions (attributes and methods) of both supertypestype lattice instead of type hierarchyif a function is inherited from some common supertype, it is inherited only onceambiguity resolutionalarm userssystem defaultdisallow multiple inheritance

Inheritance (Continued)Selective Inheritancea subtype inherits only some of the functions of a supertypean EXCEPT clause may be used to list the functions in a super type that are not to be inherited by the subtype