Database and Design system in Fundamentals ppt

Chapter 20
Concepts for
Object-Oriented Databases
Copyright © 2004 Pearson Education, Inc.

Copyright © 2004 Ramez Elmasri and Shamkant Navathe
Elmasri/Navathe, Fundamentals of Database Systems, Fourth Edition Chapter 20-3
Chapter Outline
20.1 Overview of O-O Concepts
20.2 O-O Identity, Object Structure and Type
Constructors
20.3 Encapsulation of Operations, Methods and
Persistence
20.4 Type and Class Hierarchies and Inheritance
20.5 Complex Objects
20.6 Other O-O Concepts
20.7 Summary & Current Status

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

History of OO Models and Systems
 Languages: Simula (1960’s), Smalltalk (1970’s), C++
(late 1980’s), Java (1990’s)
 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
 Commercial OO Database products: Ontos,
Gemstone, O2 ( -> Ardent), Objectivity, Objectstore (
-> Excelon), Versant, Poet, Jasmine (Fujitsu – GM)

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

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.

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

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:
1. signature or interface of the operation, specifies the
operation name and arguments (or parameters).
2. method or body, specifies the implementation of the
operation.

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

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 …..

Concepts (7)
 Operator polymorphism: It 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

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; that is, the OID value of a particular
object should not change. This preserves the
identity of the real-world object being represented.

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.

 Example 1, one possible relational database state
corresponding to COMPANY schema

 Example 1 (cont.):

 Example 1 (cont.)

 Example 1 (cont.)
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})

 Example 1(cont.)
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>)
. . .

Object Identity, Object Structure,
Example 1 (cont.)
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.

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)

Example 2 (cont.):
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.

Figure 20.1 Representation of a DEPARTMENT complex object
as a graph

Figure 20.2 Specifying the object types Employee, date, and
Department using type constructors

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

Encapsulation of Operations,
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.

Specifying Object Behavior via Class Operations
(cont.):
 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).

Figure 20.3 Adding operations to definitions of
Employee and Department

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.

Specifying Object Persistence via Naming and
Reachability (cont.):
 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

Note: The above figure is now called Figure 20.4 in Edition 4

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

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

Inheritance (3)
Example (1):
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

Inheritance (4)
Example (2):
Consider a type that describes objects in plane geometry,
which may be defined as follows:
GEOMETRY_OBJECT: Shape, Area, ReferencePoint

Inheritance (5)
 Example (2) (cont.):
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

Inheritance (6)
 Example (2) (cont.):
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

Inheritance (7)
 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: It holds a collection of
objects that is stored permanently in the database
and hence can be accessed and shared by multiple
programs

Inheritance (8)
 Transient Collection: It exists temporarily during
the execution of a program but is not kept when the
program terminates

20.5 Complex Objects (1)
 Unstructured complex object: It 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.

Complex Objects (2)
 Structured complex object: It 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.

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

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.

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.

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.

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.

Summary (3)
 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.
 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.

Summary (4)
 Versioning: Some OO systems provide support for
maintaining several versions of the same object.

Current Status
 OODB market not growing much per se. Currently
around $250M as opposed to the relational DB
revenue upwards of $50B.
 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 …)

Database and Design system in Fundamentals ppt

More Related Content

Similar to Database and Design system in Fundamentals ppt (20)

Recently uploaded (20)

Database and Design system in Fundamentals ppt

Editor's Notes