0% found this document useful (0 votes)
11 views

Advanced DB# Chapter 1

The document discusses concepts related to Object-Oriented Databases (OODBs), including the need for OODBs due to the complexity of applications and the limitations of traditional data models. It covers key topics such as object identity, encapsulation, type constructors, and inheritance, emphasizing the importance of maintaining the integrity and identity of objects. Additionally, it highlights the mechanisms for object persistence and the structure of complex objects within OODBs.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views

Advanced DB# Chapter 1

The document discusses concepts related to Object-Oriented Databases (OODBs), including the need for OODBs due to the complexity of applications and the limitations of traditional data models. It covers key topics such as object identity, encapsulation, type constructors, and inheritance, emphasizing the importance of maintaining the integrity and identity of objects. Additionally, it highlights the mechanisms for object persistence and the structure of complex objects within OODBs.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 45

Advanced

Database Systems
Chapter One

Concepts for Object-Oriented Databases


OUTLINE
• Overview of OO Concepts

• OO Identity, Object Structure and Type Constructors

• Encapsulation of Operations, Methods and Persistence

• Type and Class Hierarchies, and Inheritance

• Summary & Contemporary Status

3
. Lecture 1: Concepts for Object-Oriented Databases .
Introduction
• Traditional Data Models: • Reasons for creation of Object
Oriented Databases:
• Hierarchical
• Need for more complex
• Network (since mid-60’s) applications
• Relational (since 1970 • Need for additional data
• Object Oriented (OO) Data modeling features
Models since mid-90’s • Increased use of oop languages
• Commercial OO Database Products
Several in the 1990’s, but did not make
much impact on mainstream data
management

4
. Lecture 1: Concepts for Object-Oriented Databases .
Overview of Object-Oriented Concepts
• 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
5
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors
• 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

6
. Lecture 1: Concepts for Object-Oriented Databases .
OID has following characteristics
 It is generated by system.
 It is unique to that object in the entire system.
 It is used only by the system, not by the user.
 It is independent the state of the object.
Object Structure
 In OODBS, the state (current value) of a complex object
may be constructed from other objects (or other values)
using type constructors.
 Formal representation of an object as a triple (i, c, v), with i
being OID, c a type constructor, and v is the object state.
 Basic type constructors are atom, tuple, and set; can also
include list, bag, and array.
Examples
O0 = (i0, atom, 815)
O1 = (i1, atom, ‘UC Davis‘)
O2 = (i2, atom, ‘Computer Science‘)
O3 = (i3, atom, ‘Art‘)
O4 = (i4, set, {i1, i2})
O5 = (i5, tuple, <University: i1, Major: i2>)
Type Constructors
 A type constructor is used to define the data structure for object-
oriented.
 A type constructor is the collection of multiple similar basic types
under a common name.
 It determines how the object is constructed.
 The type constructors can be used to define the data structures for
an object-oriented database schema.
 The three basic type constructors are atom, tuple, and set. Other
commonly used constructors include list, bag, and array.
Type Constructors
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
Set constructor
 Set of values of same type
 All the elements in a particular collection value must be of the
same type.
 For example, all values in a collection of type set(string) must be
string values.
tuple constructor - collection of the above types
 Can be represent < >
 E.g tuple Name<FirstName: string, MiddleInitial: char,
LastName: string>,
11
. Lecture 1: Concepts for Object-Oriented Databases .
Bag- A set with no duplicate items.
List- is ordered collection of values or object of same types
Array- similar to list but it has a fixed size
Example
Object Identity, Object Structure, and
Type Constructors
• Example 1
• One possible relational database state corresponding to
COMPANY schema

14
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors

15
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors

16
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors

• 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})

17
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors
• 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>)
• ...

18
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors

• 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

19
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors
• 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)

20
. Lecture 1: Concepts for Object-Oriented Databases .
Object Identity, Object Structure, and
Type Constructors
 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 21
. Lecture 1: Concepts for Object-Oriented Databases .
22
. Lecture 1: Concepts for Object-Oriented Databases .
Operation

• 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

23
. Lecture 1: Concepts for Object-Oriented Databases .
• 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

24
. Lecture 1: Concepts for Object-Oriented Databases .
25
. Lecture 1: Concepts for Object-Oriented Databases .
• 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

26
. Lecture 1: Concepts for Object-Oriented Databases .
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)
Methods and Persistence
 Transient objects exist in the executing program and disappear once the
program terminates.

• This exists temporarily during the execution of a program but is


not kept when the program terminates

• Persistent objects are stored in the database and persist after program
termination.

• This holds a collection of objects that is stored permanently in the


database and hence can be accessed and shared by multiple programs
 The typical mechanisms for making an object persistent are naming and
reachability.
Encapsulation of Operations, Methods, and Persistence
• 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
• It is not practical to give names to all objects in a large database that
includes thousands of objects.
• 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 database lead from object A to object B.
29
. Lecture 1: Concepts for Object-Oriented Databases .
Encapsulation of Operations, Methods,
and Persistence
• Specifying Object Persistence via Naming and Reachability (contd.):
• In traditional database models such as relational model or ER 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

30
. Lecture 1: Concepts for Object-Oriented Databases .
Encapsulation of Operations, Methods, and Persistence

31
. Lecture 1: Concepts for Object-Oriented Databases .
Type and Class Hierarchies and
Inheritance
• 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

32
. Lecture 1: Concepts for Object-Oriented Databases .
Type and Class Hierarchies and
Inheritance
• Subtype:
• When the designer or user must create a new type that is
similar but not identical to an already defined type

• Supertype:
• It allows inheritance of all the functions (attributes and
methods) to the subtype

33
. Lecture 1: Concepts for Object-Oriented Databases .
Type and Class Hierarchies and
Inheritance
• 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

34
. Lecture 1: Concepts for Object-Oriented Databases .
Type and Class Hierarchies and
Inheritance
• 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

35
. Lecture 1: Concepts for Object-Oriented Databases .
Type and Class Hierarchies and
Inheritance
• 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

36
. Lecture 1: Concepts for Object-Oriented Databases .
Complex Objects
• 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

37
. Lecture 1: Concepts for Object-Oriented Databases .
Complex Objects
• 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

38
. Lecture 1: Concepts for Object-Oriented Databases .
Other Objected-Oriented Concepts
• 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

39
. Lecture 1: Concepts for Object-Oriented Databases .
Other Objected-Oriented Concepts
• 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

40
. Lecture 1: Concepts for Object-Oriented Databases .
Summary
• 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

41
. Lecture 1: Concepts for Object-Oriented Databases .
Summary
• 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 46
. Lecture 1: Concepts for Object-Oriented Databases .
Summary
• 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

43
. Lecture 1: Concepts for Object-Oriented Databases .
Contemporary Status
• OODB market growing very slowly these days
• OO ideas are being used in a largenumberof applications,
without explicitly using the OODB platform to store data
• Growth:
• OO 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 …)

44
. Lecture 1: Concepts for Object-Oriented Databases .
End Of
Chapter One

???

You might also like