You are on page 1of 31

CHAPTER 11

Concepts for Object-Oriented Databases

11-1

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
Object State(Value)

Increase uses of OOPL

Behavior(operations) transient vs. persistent


11-2

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 systemgenerated object identifier for each object


11-3

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-4

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

11-5

Object Identity (Cont.)


properties of OID
immutable: the OID value of a particular object should not change
OID should not depend on any physical address attribute values of the object

Each OID is used only once.


Most OO database systems allow for the representation of both objects and values (having no OIDs)
11-6

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

Object Structure (Cont.)


v: object state c=atom ::: an atomic value from the domain c=set ::: a set of object identifiers {i1, i2, , in} c=tuple ::: a tuple of <a1:i1, a2:i2, , an:in> c=list ::: an ordered list [i1, i2, , in] c=array ::: a single-dimensional array of object identifiers c=bag
11-8

ij : OID aj : attribute name

Example 1: Complex Object


EMPLOYEE FNAME John Franklin licia Jenni er amesh Joyce hmad James
N

MINIT B T J

LNAME mith Wong Zelaya Wallace

SSN

BDATE

ADDRESS 731 Fondren, ouston, TX 638 Voss, ouston, TX 3321 Castle, pring, TX 291 Berry, Bellaire, TX 975 Fire Oak, umble, TX 5631 ice, ouston, TX

SEX

SALARY 30000 40000

SUPERSSN 333445555 888665555 987654321 888665555 333445555 333445555 987654321 null

DNO 5 5 4 4 5 5 4 1

123456789 09-J N-55 333445555 08- EC-45 999887777 19-JU -58 987654321 20-JUN-31 666884444 15- E -52 453453453 31-JU -62 987987987 29-

F F

25000 43000 38000

Narayan English

25000 25000 55000

V E

Jabbar Borg

-59 980 allas, oustom TX

888665555 10-NOV-27 450 tone, ouston, T

11-9

Example 1: Complex Object (Cont.)


o1=(i1,atom,Houston) o2=(i2,atom, ellaire) 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
11-10

Example 1: Complex Object (Cont.)


o8=(i8, tuple, <D AME:i5, D M ER: i4, MGR: i9, LOCATIO S: i7, EMPLOYEES: i10, PROJECTS: i11>) ::: department 5 o9=(i9, tuple, <MA AGER:i12, MA AGER_START_DATE: i6>) o10=(i10,set,{i12, i13, i14}) o11=(i11,set,{i15, i16, i17}) o12=(i12, tuple, < AME:i18, MI IT: i19, L AME: i20, SS : i21, , SALARY: i26, S PER ISOR: i27, DEPT: i28>) employee John B. Smith
11-11

Graphical representation of a complex object


LEGE D: object tuple set D AME D M ER MGR LOCATIO S EMPLOYEES PROJECTS
i8 : O 8 tuple

Object instance of department type

i5 : O 5 atom
5

i4 : O 4 i : O 9 9 atom tuple
4

i7 : O 7 set

i10: O10 set


10

i11: O11 set


11

Research

O1
1

O2
2

O3
3

Houston MA AGER MA AGERSTRATDATE


i6 : O 6 atom

ellaire Sugarland

i15: ..... tuple

i16: ..... i17: ..... tuple tuple

1988-05-22 i12: ..... tuple

i13: ..... tuple

i14: ..... tuple 11-12

Comparisons of the states of (Current Values) 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
11-13

Example 2: Identical vs. Equal Object States


o1=(i1, tuple, <a1:i4, a2:i6>) o2=(i2, tuple, <a1:i5, a2:i6>) o3=(i3, tuple, <a1:i4, a2:i6>) o4=(i4, atom, 10) o5=(i5, atom, 10) o6=(i6, atom, 20) o1 and o2 have equal states o1 and o3 have identical states o4 and o5 have identical states o4 and o5 are equal but not identical
11-14

sing 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; string; Date; string; char; float; Employee; Department); Attributes refer to Employee, Department objects relationship among objects
11-15

sing OODDL to define Employee, Date, and Department types (Cont.)


define type Date: Inverse reference: tuple ( year: dept. of employee month: day:
employee of dept.

integer; integer; integer; );

define type Department tuple ( dname: dnumber: mgr:

string; integer; tuple (manager: Employee; startdate: Date; ); locations: set (string); set of references employees: set (Employee); projects: set (Project); );
11-16

Specifying Object ehavior via Class Operations


In relational model, selecting, inserting, deleting and modifying tuples are generic. generic.

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

Specifying Object ehavior via Class Operations (Continued)


interface
Operations 1. object constructors 2. object destructor 3. object modifier 4. retrieval

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 11-18

sing OODDL to define Employee and Department classes


define class Employee: type tuple ( fname: minit: lname: ssn: birthdate: address sex: salary: supervisor: dept: string; char; string; string; Date; string; char; float; Employee; Department);

type definition

definition of operations

integer; operations age Employee; create_emp: destroy_emp : boolean; end Employee;

11-19

sing 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); );

type definition

Employee; Date; );

definition of operations

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;

11-20

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

Specifying Object Persistence via aming 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-22

Reachability
reachability mechanism
make the object reachable from some persistent object an object is said to be reachable from an object A if a sequence of references in the object graph lead from object A to object e.g., if o8 is persistent, then all other objects also become persistent (next slide) defines a persistent collection of objects of class C create a named persistent object , 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
11-23

Graphical representation of a complex object


LEGE D: object tuple set D AME D M ER MGR LOCATIO S EMPLOYEES PROJECTS
i8 : O 8 tuple

Object instance of department type

i5 : O 5 atom
5

i4 : O 4 i : O 9 9 atom tuple
4

i7 : O 7 set

i10: O10 set


10

i11: O11 set


11

Research

O1
1

O2
2

O3
3

Houston MA AGER MA AGERSTRATDATE


i6 : O 6 atom

ellaire Sugarland

i15: ..... tuple

i16: ..... i17: ..... tuple tuple

1988-05-22 i12: ..... tuple

i13: ..... tuple

i14: ..... tuple 11-24

Creating persistent objects by naming and reachability


define class DepartmentSet: type set (Department); operations add_dept(d: Department): remove_dept (d: Department): create_dept_set: destroy_dept_set: end DepartmentSet;

boolean; boolean, DepartmentSet; boolean;

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-25

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 11-26 persistent

Type Hierarchies and Inheritance


type (or class) hierarchy
define new types based on other predefined types (or classes) type
functions with zero arguments type name a number of attributes (instance variables) functions operations (methods)

TYPE_ AME: function, function, , function PERSO : ame, Address, irthdate, Age, SS EMPLOYEE subtype-of PERSO : Salary, HireDate, Seniority ST DE T subtype-of PERSO : Major, GPA
11-27

Type Hierarchies and Inheritance


attributes(triangle,rectangle,circle)

GEOMETRY_O JECT: Shape, Area, ReferencePoint RECTA GLE subtype-of GEOMETRY_O JECT: Width, Height
method attribute

TRIA GLE subtype-of GEOMETRY_O JECT: Side1, Side2, Side3 CIRCLE subtype-of GEOMETRY_O JECT: Radius
11-28

Type Hierarchies and Inheritance (Cont.)


RECTA GLE subtype-of
GEOMETRY_O JECT (Shape=rectangle): Width, Height

TRIA GLE subtype-of


GEOMETRY_O JECT (Shape=triangle): Side1, Side2, Side3

CIRCLE subtype-of
GEOMETRY_O JECT (Shape=circle): Radius
11-29

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-30

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

11-31

You might also like