Unit I Object Oriented Databases
Slide 20- 1
Chapter Outline
• 1 Overview of O-O Concepts
• 2 O-O Identity, Object Structure and Type Constructors
• 3 Encapsulation of Operations, Methods and Persistence
• 4 Type and Class Hierarchies and Inheritance
• 5 Complex Objects
• 6 Other O-O Concepts
• 7 Summary & Current Status
Slide 20- 2
Introduction
• Traditional Data Models:
• Hierarchical
• Network (since mid-60’s)
• Relational (since 1970 and commercially since 1982)
• Object Oriented (OO) Data Models since mid-90’s
• Reasons for creation of Object Oriented Databases
• Need for more complex applications
• Need for additional data modeling features
• Increased use of object-oriented programming languages
• Commercial OO Database products –
• Several in the 1990’s, but did not make much impact on
mainstream data management
Slide 20- 3
History of OO Models and Systems
• Languages:
• Simula (1960’s)
• Smalltalk (1970’s)
• C++ (late 1980’s)
• Java (1990’s and 2000’s)
Slide 20- 4
History of OO Models and Systems (contd.)
• Experimental Systems:
• Orion at MCC
• IRIS at H-P labs
• Open-OODB at T.I.
• ODE at ATT Bell labs
• Postgres - Montage - Illustra at UC/B
• Encore/Observer at Brown
Slide 20- 5
History of OO Models and Systems (contd.)
• Commercial OO Database products:
• Ontos
• Gemstone
• O2 ( -> Ardent)
• Objectivity
• Objectstore ( -> Excelon)
• Versant
• Poet
• Jasmine (Fujitsu – GM)
Slide 20- 6
20.1 Overview of Object-Oriented Concepts(1)
• Main Claim:
• OO databases try to maintain a direct correspondence
between real-world and database objects so that objects do
not lose their integrity and identity and can easily be identified
and operated upon
• Object:
• Two components:
• state (value) and behavior (operations)
• Similar to program variable in programming language, except
that it will typically have a complex data structure as well as
specific operations defined by the programmer
Slide 20- 7
Overview of Object-Oriented Concepts (2)
• In OO databases, objects may have an object structure of arbitrary
complexity in order to contain all of the necessary information that
describes the object.
• In contrast, in traditional database systems, information about a
complex object is often scattered over many relations or records,
leading to loss of direct correspondence between a real-world object
and its database representation.
Slide 20- 8
Overview of Object-Oriented Concepts (3)
• The internal structure of an object in OOPLs includes the
specification of instance variables, which hold the values that define
the internal state of the object.
• An instance variable is similar to the concept of an attribute, except
that instance variables may be encapsulated within the object and
thus are not necessarily visible to external users
Slide 20- 9
Overview of Object-Oriented Concepts (4)
• Some OO models insist that all operations a user can apply to an
object must be predefined. This forces a complete encapsulation of
objects.
• To encourage encapsulation, an operation is defined in two parts:
• signature or interface of the operation, specifies the operation name and
arguments (or parameters).
• method or body, specifies the implementation of the operation.
Slide 20- 10
Overview of Object-Oriented Concepts (5)
• Operations can be invoked by passing a message to an object, which
includes the operation name and the parameters.
• The object then executes the method for that operation.
• This encapsulation permits modification of the internal structure of
an object, as well as the implementation of its operations, without
the need to disturb the external programs that invoke these
operations
Slide 20- 11
Overview of Object-Oriented Concepts (6)
• Some OO systems provide capabilities for dealing with multiple
versions of the same object (a feature that is essential in design and
engineering applications).
• For example, an old version of an object that represents a tested and verified
design should be retained until the new version is tested and verified:
• very crucial for designs in manufacturing process control, architecture ,
software systems …..
Slide 20- 12
Overview of Object-Oriented Concepts (7)
• Operator polymorphism:
• This refers to an operation’s ability to be applied to different types of objects;
in such a situation, an operation name may refer to several distinct
implementations, depending on the type of objects it is applied to.
• This feature is also called operator overloading
Slide 20- 13
20.2 Object Identity, Object Structure, and
Type Constructors (1)
• Unique Identity:
• An OO database system provides a unique identity to each independent
object stored in the database.
• This unique identity is typically implemented via a unique, system-generated object
identifier, or OID
• The main property required of an OID is that it be immutable
• Specifically, the OID value of a particular object should not change.
• This preserves the identity of the real-world object being represented.
Slide 20- 14
Object Identity, Object Structure, and Type
Constructors (2)
• Type Constructors:
• In OO databases, the state (current value) of a complex object
may be constructed from other objects (or other values) by
using certain type constructors.
• The three most basic constructors are atom, tuple, and set.
• Other commonly used constructors include list, bag, and
array.
• The atom constructor is used to represent all basic atomic
values, such as integers, real numbers, character strings,
Booleans, and any other basic data types that the system
supports directly.
Slide 20- 15
Object Identity, Object Structure, and Type
Constructors (3)
• Example 1
• One possible relational database state corresponding to COMPANY schema
Slide 20- 16
Object Identity, Object Structure, and Type
Constructors (4)
• Example 1 (contd.):
Slide 20- 17
Object Identity, Object Structure, and Type
Constructors (5)
• Example 1 (contd.)
Slide 20- 18
Object Identity, Object Structure, and Type
Constructors (6)
• Example 1 (contd.)
• We use i1, i2, i3, . . . to stand for unique system-generated object identifiers.
Consider the following objects:
• 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 = (i7, set, {i1, i2, i3})
Slide 20- 19
Object Identity, Object Structure, and Type
Constructors (7)
• Example 1(contd.)
• o8 = (i8, tuple, <dname:i5, dnumber:i4, mgr:i9, locations:i7, employees:i10, projects:i11>)
• o9 = (i9, tuple, <manager:i12, manager_start_date:i6>)
• o10 = (i10, set, {i12, i13, i14})
• o11 = (i11, set {i15, i16, i17})
• o12 = (i12, tuple, <fname:i18, minit:i19, lname:i20, ssn:i21, . . ., salary:i26, supervisor:i27,
dept:i8>)
• ...
Slide 20- 20
Object Identity, Object Structure, and Type
Constructors (8)
• Example 1 (contd.)
• The first six objects listed in this example represent atomic values.
• Object seven is a set-valued object that represents the set of locations for
department 5; the set refers to the atomic objects with values {‘Houston’,
‘Bellaire’, ‘Sugarland’}.
• Object 8 is a tuple-valued object that represents department 5 itself, and has
the attributes DNAME, DNUMBER, MGR, LOCATIONS, and so on.
Slide 20- 21
Object Identity, Object Structure, and Type
Constructors (9)
• Example 2:
• This example illustrates the difference between the two definitions for
comparing object states for equality.
• 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)
Slide 20- 22
Object Identity, Object Structure, and Type
Constructors (10)
• Example 2 (contd.):
• In this example, The objects o1 and o2 have equal states, since their states at
the atomic level are the same but the values are reached through distinct
objects o4 and o5.
• However, the states of objects o1 and o3 are identical, even though the
objects themselves are not because they have distinct OIDs.
• Similarly, although the states of o4 and o5 are identical, the actual objects o4
and o5 are equal but not identical, because they have distinct OIDs.
Slide 20- 23
Object Identity, Object Structure, and Type
Constructors (11)
Slide 20- 24
Object Identity, Object Structure, and Type
Constructors (12)
Slide 20- 25
20.3 Encapsulation of Operations, Methods,
and Persistence (1)
• Encapsulation
• One of the main characteristics of OO languages and systems
• Related to the concepts of abstract data types and information hiding in
programming languages
Slide 20- 26
Encapsulation of Operations, Methods, and
Persistence (2)
• Specifying Object Behavior via Class Operations:
• The main idea is to define the behavior of a type of object based on the
operations that can be externally applied to objects of that type.
• In general, the implementation of an operation can be specified in a general-
purpose programming language that provides flexibility and power in
defining the operations.
Slide 20- 27
Encapsulation of Operations, Methods, and
Persistence (3)
• Specifying Object Behavior via Class Operations (contd.):
• For database applications, the requirement that all objects be completely
encapsulated is too stringent.
• One way of relaxing this requirement is to divide the structure of an object
into visible and hidden attributes (instance variables).
Slide 20- 28
Encapsulation of Operations, Methods, and
Persistence (4)
Slide 20- 29
Encapsulation of Operations, Methods, and
Persistence (5)
• Specifying Object Persistence via Naming and Reachability:
• Naming Mechanism:
• Assign an object a unique persistent name through which it can
be retrieved by this and other programs.
• 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.
Slide 20- 30
Encapsulation of Operations, Methods, and
Persistence (6)
• Specifying Object Persistence via Naming and Reachability (contd.):
• In traditional database models such as relational model or EER model, all
objects are assumed to be persistent.
• In OO approach, a class declaration specifies only the type and operations for
a class of objects. The user must separately define a persistent object of type
set (DepartmentSet) or list (DepartmentList) whose value is the collection of
references to all persistent DEPARTMENT objects
Slide 20- 31
Encapsulation of Operations, Methods, and
Persistence (7)
Slide 20- 32
20.4 Type and Class Hierarchies and
Inheritance (1)
• Type (class) Hierarchy
• A type in its simplest form can be defined by giving it a type name and then
listing the names of its visible (public) functions
• When specifying a type in this section, we use the following format, which
does not specify arguments of functions, to simplify the discussion:
• TYPE_NAME: function, function, . . . , function
• Example:
• PERSON: Name, Address, Birthdate, Age, SSN
Slide 20- 33
Type and Class Hierarchies and Inheritance (2)
• Subtype:
• When the designer or user must create a new type that is similar but not
identical to an already defined type
• Supertype:
• It inherits all the functions of the subtype
Slide 20- 34
Type and Class Hierarchies and Inheritance (3)
• Example (1):
• PERSON: Name, Address, Birthdate, Age, SSN
• EMPLOYEE: Name, Address, Birthdate, Age, SSN, Salary, HireDate, Seniority
• STUDENT: Name, Address, Birthdate, Age, SSN, Major, GPA
• OR:
• EMPLOYEE subtype-of PERSON: Salary, HireDate, Seniority
• STUDENT subtype-of PERSON: Major, GPA
Slide 20- 35
Type and Class Hierarchies and Inheritance (4)
• Example (2):
• Consider a type that describes objects in plane geometry,
which may be defined as follows:
• GEOMETRY_OBJECT: Shape, Area, ReferencePoint
• Now suppose that we want to define a number of subtypes
for the GEOMETRY_OBJECT type, as follows:
• RECTANGLE subtype-of GEOMETRY_OBJECT: Width, Height
• TRIANGLE subtype-of GEOMETRY_OBJECT: Side1, Side2, Angle
• CIRCLE subtype-of GEOMETRY_OBJECT: Radius
Slide 20- 36
Type and Class Hierarchies and Inheritance (5)
• Example (2) (contd.):
• An alternative way of declaring these three subtypes is to specify the
value of the Shape attribute as a condition that must be satisfied for
objects of each subtype:
• RECTANGLE subtype-of GEOMETRY_OBJECT (Shape=‘rectangle’): Width,
Height
• TRIANGLE subtype-of GEOMETRY_OBJECT (Shape=‘triangle’): Side1, Side2,
Angle
• CIRCLE subtype-of GEOMETRY_OBJECT (Shape=‘circle’): Radius
Slide 20- 37
Type and Class Hierarchies and Inheritance (6)
• Extents:
• In most OO databases, the collection of objects in an extent
has the same type or class.
• However, since the majority of OO databases support types,
we assume that extents are collections of objects of the same
type for the remainder of this section.
• Persistent Collection:
• This holds a collection of objects that is stored permanently in
the database and hence can be accessed and shared by
multiple programs
• Transient Collection:
• This exists temporarily during the execution of a program but is
not kept when the program terminates
Slide 20- 38
20.5 Complex Objects (1)
• Unstructured complex object:
• These is provided by a DBMS and permits the storage and
retrieval of large objects that are needed by the database
application.
• Typical examples of such objects are bitmap images and long
text strings (such as documents); they are also known as
binary large objects, or BLOBs for short.
• This has been the standard way by which Relational DBMSs
have dealt with supporting complex objects, leaving the
operations on those objects outside the RDBMS.
Slide 20- 39
Complex Objects (2)
• Structured complex object:
• This differs from an unstructured complex object in that the object’s
structure is defined by repeated application of the type constructors
provided by the OODBMS.
• Hence, the object structure is defined and known to the OODBMS.
• The OODBMS also defines methods or operations on it.
Slide 20- 40
20.6 Other Objected-Oriented Concepts (1)
• Polymorphism (Operator Overloading):
• This concept allows the same operator name or symbol to be bound to two
or more different implementations of the operator, depending on the type
of objects to which the operator is applied
• For example + can be:
• Addition in integers
• Concatenation in strings (of characters)
Slide 20- 41
Other Objected-Oriented Concepts (2)
• Multiple Inheritance and Selective Inheritance
• Multiple inheritance in a type hierarchy occurs when a certain subtype T is a
subtype of two (or more) types and hence inherits the functions (attributes
and methods) of both supertypes.
• For example, we may create a subtype ENGINEERING_MANAGER that is a
subtype of both MANAGER and ENGINEER.
• This leads to the creation of a type lattice rather than a type hierarchy.
Slide 20- 42
Other Objected-Oriented Concepts (3)
• Versions and Configurations
• Many database applications that use OO systems require the
existence of several versions of the same object
• There may be more than two versions of an object.
• Configuration:
• A configuration of the complex object is a collection consisting
of one version of each module arranged in such a way that the
module versions in the configuration are compatible and
together form a valid version of the complex object.
Slide 20- 43
20.7 Summary (1)
• Object identity:
• Objects have unique identities that are independent of their attribute values.
• Type constructors:
• Complex object structures can be constructed by recursively applying a set of
basic constructors, such as tuple, set, list, and bag.
• Encapsulation of operations:
• Both the object structure and the operations that can be applied to objects
are included in the object class definitions.
Slide 20- 44
Summary (2)
• Programming language compatibility:
• Both persistent and transient objects are handled uniformly.
Objects are made persistent by being attached to a persistent
collection.
• Type hierarchies and inheritance:
• Object types can be specified by using a type hierarchy, which
allows the inheritance of both attributes and methods of
previously defined types.
• Extents:
• All persistent objects of a particular type can be stored in an
extent. Extents corresponding to a type hierarchy have
set/subset constraints enforced on them.
Slide 20- 45
Summary (3)
• Support for complex objects:
• Both structured and unstructured complex objects can be stored and
manipulated.
• Polymorphism and operator overloading:
• Operations and method names can be overloaded to apply to different
object types with different implementations.
• Versioning:
• Some OO systems provide support for maintaining several versions of the
same object.
Slide 20- 46
Current Status
• OODB market growing very slowly these days.
• O-O ideas are being used in a large number of applications,
without explicitly using the OODB platform to store data.
• Growth:
• O-O tools for modeling and analysis, O-O Programming
Languages like Java and C++
• Compromise Solution Proposed:
• Object Relational DB Management (Informix Universal Server,
Oracle 10i, IBM’s UDB, DB2/II …)
Slide 20- 47
