11-1 CHAPTER 11 Concepts for Object-Oriented Databases

11-2 Overview of Object-Oriented Concepts Object-oriented databases give designer to specify –The structure of complex objects –The operations that can be applied to objects Increase uses of OOPL Object State(Value) Behavior(operations) transient vs. persistent

11-3 Overview of Object-Oriented Concepts (Cont.) Maintain a direct correspondence between real-world and database objects –A 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

11-4 Overview of Object-Oriented Concepts (Cont.) Objects may have an object structure of arbitrary complexity –Information about a complex object is often scattered over many relations or records in traditional database systems 1NF in relational databases

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

11-6 Object Identity (Cont.) properties of OID –immutable: the OID value of a particular object should not change –Each OID is used only once. OID should not depend on any physical address attribute values of the object Most OO database systems allow for the representation of both objects and values (having no OIDs)

11-7 Object Structure (i, c, v) –i: a unique object identifier (OID) –c: a type constructor basic type: atom structured type: tuple collection type: array vs. list, set vs. bag System supports (integer,real,string,Boolean,…) number of elements distinct vs. duplicate orderunorder

11-8 –v: object state c=atom ::: an atomic value from the domain c=set ::: a set of object identifiers {i 1, i 2, …, i n } c=tuple ::: a tuple of c=list ::: an ordered list [i 1, i 2, …, i n ] c=array ::: a single-dimensional array of object identifiers c=bag Object Structure (Cont.) i j : OID a j : attribute name

11-9 Example 1: Complex Object

11-10 Example 1: Complex Object (Cont.) o 1 =(i 1,atom,’Houston’) o 2 =(i 2,atom,’Bellaire’) o 3 =(i 3,atom,’Sugarland’) o 4 =(i 4,atom,5) o 5 =(i 5,atom,’Research’) o 6 =(i 6,atom,’ ’) o 7 =(i 5,set,{i 1, i 2, i 3 }) ::: the set of locations for department 5

11-11 o 8 =(i 8, tuple, ) ::: department 5 o 9 =(i 9, tuple, ) o 10 =(i 10,set,{i 12, i 13, i 14 }) o 11 =(i 11,set,{i 15, i 16, i 17 }) o 12 =(i 12, tuple, ) Example 1: Complex Object (Cont.) employee ‘John B. Smith’

11-12 Graphical representation of a complex object LEGEND:object tuple set DNAME DNUMBER MGR LOCATIONS EMPLOYEES PROJECTS MANAGER MANAGERSTRATDATE ．． O5O5 O4O4 O9O9 O7O7 O 10 O 11 O8O8 O1O1 O2O2 O3O3 Houston Bellaire Sugarland i 8 : tuple i 5 : atom i 4 : atom i 9 : tuple i 7 : set i 10 : set i 11 : set i 15 :..... tuple i 16 :..... tuple i 17 :..... tuple i 12 :..... tuple i 13 :..... tuple i 14 :..... tuple i 6 : atom O6O V4V4 V9V9 V5V5 V7V7 V 10 V 11 V1V1 V2V2 V3V3 V6V6 Research 5 Object instance of department type

11-13 Comparisons of the states of two objects for equality identical states (deep equality) –the graphs representing their states are identical in every respect, including the OIDs at every level equal states (shallow equality) –the graph structures must be the same –all the corresponding atomic values in the graphs should be the same –allow some corresponding internal nodes in the two graphs to have objects with different OIDs (Current Values)

11-14 Example 2: Identical vs. Equal Object States o 1 =(i 1, tuple, ) o 2 =(i 2, tuple, ) o 3 =(i 3, tuple, ) o 4 =(i 4, atom, 10) o 5 =(i 5, atom, 10) o 6 =(i 6, atom, 20) o 1 and o 2 have equal states o 1 and o 3 have identical states o 4 and o 5 have identical states o 4 and o 5 are equal but not identical

11-15 Using OODDL to define Employee, Date, and Department types define type tuple ( Employee: fname: minit: lname: ssn: birthdate: address sex: salary: supervisor: dept: string; char; string; Date; string; char; float; Employee; Department); Attributes refer to Employee, Department objects relationship among objects

11-16 define type tuple ( define type tuple ( Date: year: month: day: Department dname: dnumber: mgr: locations: employees: projects: 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

11-17 Specifying Object Behavior via Class Operations Define the behavior of a type of object based on the operations that can be externally applied to object of that type –create (insert) or destroy (delete) objects –update the object state –retrieve parts of the object state –apply some calculations –combination of retrieval, calculation, and update In relational model, selecting, inserting, deleting and modifying tuples are generic.

11-18 Specifying Object Behavior via Class Operations (Continued) interface –define the name and arguments (parameters) of each operation –signature (included in the class definition) implementation –method (defined using programming languages) –it is invoked by sending a message to the object to execute the corresponding method Operations 1. object constructors 2. object destructor 3. object modifier 4. retrieval

11-19 Using OODDL to define Employee and Department classes operations 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; Date; string; char; float; Employee; Department); type definition definition of operations

11-20 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 definition definition of operations

11-21 Class Operations object constructor –create a new object destructor –destroy an object object modifier –modify various attribute of an object dot notation –d.no_of_emps where d is a reference to a department object and no_of_emps is an operation refer to attributes of an object: d.dnumber, d.mgr.startdate

11-22 Specifying Object Persistence via Naming and Reachability transient object –exist in the executing program and disappear once the program terminates persistent object –stored in the database and persist after program termination naming mechanism –give an object a unique persistent name through which it can be retrieved by this and other program

11-23 Reachability reachability mechanism –make the object reachable from some persistent object –an 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 B –e.g., if o 8 is persistent, then all other objects also become persistent (next slide) –N defines a persistent collection of objects of class C create a named persistent object N, whose state is a set or list of objects of some class C add objects of C to the set or list and make them reachable from N

11-24 Graphical representation of a complex object LEGEND:object tuple set DNAME DNUMBER MGR LOCATIONS EMPLOYEES PROJECTS MANAGER MANAGERSTRATDATE ．． O5O5 O4O4 O9O9 O7O7 O 10 O 11 O8O8 O1O1 O2O2 O3O3 Houston Bellaire Sugarland i 8 : tuple i 5 : atom i 4 : atom i 9 : tuple i 7 : set i 10 : set i 11 : set i 15 :..... tuple i 16 :..... tuple i 17 :..... tuple i 12 :..... tuple i 13 :..... tuple i 14 :..... tuple i 6 : atom O6O V4V4 V9V9 V5V5 V7V7 V 10 V 11 V1V1 V2V2 V3V3 V6V6 Research 5 Object instance of department type

11-25 Creating persistent objects by naming and reachability define 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

11-26 differences between traditional databases and OO databases traditional database models –when an entity type or class is defined in EER, it represents both type declaration and persistent set OO approaches –a class declaration specifies only the type and operations for a class of objects –user must define a persistent object whose value is the collection of references to all persistent

11-27 Type Hierarchies and Inheritance type (or class) hierarchy –define new types based on other predefined types (or classes) –type type name a number of attributes (instance variables) operations (methods) –TYPE_NAME: function, function, …, function –PERSON: Name, Address, Birthdate, Age, SSN EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority STUDENT subtype-of PERSON: Major, GPA functions with zero arguments functions

11-28 Type Hierarchies and Inheritance –GEOMETRY_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

11-29 Type Hierarchies and Inheritance (Cont.) –RECTANGLE TRIANGLE CIRCLE –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

11-30 Inheritance multiple inheritance –when T is a subtype of two (or more) types, T inherits the functions (attributes and methods) of both supertypes –type lattice instead of type hierarchy –if a function is inherited from some common supertype, it is inherited only once –ambiguity resolution alarm users system default disallow multiple inheritance

11-31 Inheritance (Continued) Selective Inheritance –a subtype inherits only some of the functions of a supertype –an EXCEPT clause may be used to list the functions in a super type that are not to be inherited by the subtype