Chapter 5 Object Oriented Database Systems

Chapter 5
Object Oriented
Database Systems
Chapter 5 - Objectives
 Advanced database applications.
 History of Database System
 Weakness of RDBMSs for advanced database applications.
 Object-oriented concepts.
 Problems of storing objects in relational database.
 Basics of object-oriented database analysis and design.
 The next generation of database systems.
 Brief Overview of OODBMS (ODL+OQL)
 Brief Overview of ORDBMS (SQL/Object(SQL3), UDT ..etc
2 Object Oriented Database Systems 04/13/2024

Introduction
We have seen the widespread acceptance of RDBMSs
for traditional business applications such as ,
order processing,
inventory control,
banking, and
airline reservations ….etc.
However, existing RDBMSs have proven to be
inadequate for applications whose needs are quite
different from those of traditional business database
applications.
Those applications need to model very complex
behavior.
Advanced Database Applications
Computer-Aided Design/Manufacturing (CAD/CAM)
Computer-Aided Software Engineering (CASE)
Network Management Systems
Office Information Systems (OIS) and Multimedia
Systems
Digital Publishing
Geographic Information Systems (GIS)
Interactive and Dynamic Web sites
Other applications with complex and interrelated
objects and procedural data.

History of Database Systems

Application Matrix Object orientation
Added to RDBMS
This Diagram shows how data can be accessed.

Note : Most Applications will move to the upper right Corner.
i.e. ORDBMS are getting the upper hand in the market

The database Design Process

Logical and Physical Layers of Designs

UML Class Example

Weaknesses of RDBMSs
Poor Representation of “Real World” Entities
Normalization leads to relations that do not correspond
to entities in “real world”.
Semantic Overloading
Relational model has only one construct for
representing data and data relationships: the relation.
Even difficult to differentiate between multiple
relationships among two relations
Relational model is semantically overloaded.

 Poor Support for Integrity and Enterprise Constraints
 Unfortunately, many commercial systems do not fully support these
constraints and it is necessary to build them into the applications.
 Assumption of a Homogeneous Data Structure
 Relational model assumes both horizontal and vertical
homogeneity.
 Many RDBMSs now allow Binary Large Objects (BLOBs).
 BLOBs are usually used to store large sized images,
audio/video or other multimedia data in binary format .
 The DBMS does not have any knowledge concerning the
content of the BLOB or its internal structure.
 BLOBs cannot contain other BLOBs, so they cannot
take the form of composite objects.
Limited Operations
RDBMs only have a fixed set of operations which
cannot be extended.
Difficulty Handling Recursive Queries
Extremely difficult to produce recursive queries, that
is, queries about relationships that a relation has with
itself

Example - Recursive Query
Assuming we have a recursive relationship

in a table named category . Getting the sub
categories of a given category( recursively)
is difficult.
Example. Look at the following schema
and try to solve the above problem.
Category( catID, catName,parentCatId)

Impedance Mismatch
Most DMLs lack computational completeness.
To overcome this, SQL can be embedded in a
high-level 3GL.
SQL and 3GLs use different models to represent
data
This produces an impedance mismatch - mixing
different programming paradigms.
Estimated that as much as 30% of programming
effort and code space is expended on this type of
conversion.
Other Problems with RDBMSs
Transactions are generally short-lived and
concurrency control protocols not suited for long-lived
transactions.
Schema changes are difficult.
RDBMSs are poor at navigational access.(Through
Reference Attributes.)

Other Problems cont’d…
Three areas that are problematic for relational DBMSs:
Long-duration transactions;
The types of transaction found in business applications are
typically of short duration. In contrast, transactions involving
complex objects, such as those found in engineering and
design applications, can continue for several hours, or even
several days.
Versions;
(different states of an object), such as ability to see d/t
“design version”
Schema evolution.
Changing members definition, inheritance hierarchy,
modifying list of classes. etc.
RDBMS vs ODBMS
 With a traditional DBMS, we find that:
It is the programmer’s responsibility to decide when to read
and update objects (records).
The programmer has to write code to translate between the
application’s object model and the data model of the DBMS
(for example, relations), which might be quite different.
 With an object-oriented programming language, where an object may
be composed of many sub-objects represented by pointers, the
translation may be particularly complex.
 As noted previously, it has been claimed that as much as 30% of
programming effort and code space is devoted to this type of mapping.
It is the programmer’s responsibility to perform additional
type-checking when an object is read back from the database

Two-level storage model for conventional
(relational) DBMS

Single-level storage model for OODBMS

RDBMS VS ODBMS

Object-Oriented Concepts
Abstraction, encapsulation, information hiding.
Objects and attributes.
Object identity.
Methods and messages.
Classes, subclasses, superclasses, and inheritance.
Overloading.
Polymorphism and dynamic binding.

Abstraction
Process of identifying essential aspects of an entity
and ignoring unimportant properties ( details).
Concentrate on what an object is and what it does,
before deciding how to implement it.

Encapsulation and Information Hiding
Encapsulation
Object contains both data structure and set of
operations used to manipulate it.
Information Hiding
Separate external aspects of an object from its
internal details, which are hidden from outside.
Eg. Private field vs. Public properties
 Allows internal details of an object to be changed

without affecting applications that use it, provided
external details remain same.
 Provides data independence.

Object
Uniquely identifiable entity that contains both the
attributes that describe the state of a real-world object
and the actions associated with it.
Definition very similar to that of an entity, however,

object encapsulates both state and behavior; an entity
only models state.
 An object is made of two things:
 State: attributes (name, address, birthDate of a person
 Behavior: operations (age of a person is computed from
birthDate and current date)

Attributes
Contain current state of an object.
Attributes can be classified as simple or complex.
Simple attribute can be a primitive type such as
integer, string, etc., which takes on literal values.
Complex attribute can contain collections and/or
references to other objects.
Reference attribute represents relationship.
An object that contains one or more complex
attributes is called a complex object.

Object Identity
Object identifier (OID) assigned to object when it is
created and has the following characteristics; It is
System-generated.
Unique to that object.
Invariant.
Independent of the values of its attributes (that is, its
state).
Invisible to the user (ideally).

Object Identity - Implementation
In RDBMS, object identity is value-based: primary
key is used to provide uniqueness.
Primary keys do not provide type of object identity
required in OO systems:
key only unique within a relation, not across entire
system;
key generally chosen from attributes of relation, making
it dependent on object state.

Object Identity - Implementation
Programming languages use variable names and
pointers/virtual memory addresses, which also
compromise object identity.
In C/C++, OID is physical address in process
memory space, which is too small - scalability
requires that OIDs be valid across storage volumes,
possibly across different computers.
Further, when object is deleted, memory is reused,
which may cause problems.
OID can never be reused even when an object is deleted

Advantages of OIDs
 They are efficient.
 They are fast.
 They cannot be modified by the user.
 They are independent of content.
 They cannot be used by another object even when the
object is no more in use (Deleted).
 objects, and relationships between objects, are identified
by object identifiers (OIDs).
 There are two types of OID:
 Logical (are independent of the physical location of the object
on disk)
 Physical ( encodes the physical location of object storage)

Methods and Messages
Method
Defines behavior of an object, as a set of
encapsulated functions.
Message
Request from one object to another asking second
object to execute one of its methods.

Object Showing Attributes and Methods

Example of a Method

Class
Blueprint for defining a set of similar objects.
Objects in a class are called instances.

In some object-oriented systems, Class is also an
object with own class attributes and class methods.

Class Instance Share Attributes and Methods

Subclasses, Superclasses, and Inheritance
Inheritance allows one class of objects to be defined
as a special case of a more general class.
Special cases are subclasses and more general cases
are superclasses.
Process of forming a superclass is generalization;
while that of forming a subclass is called
specialization.
Subclass inherits all properties of its superclass and
can define its own unique properties.
Subclass can redefine inherited methods.

Subclasses, Superclasses, and Inheritance
All instances of subclass are also instances of
superclass.
Principle of substitutability states that instance of
subclass can be used whenever method/construct
expects instance of superclass.
Relationship between subclass and superclass is
known as A KIND OF (AKO) relationship.
Four types of inheritance: single, multiple, repeated,
and selective.

Single Inheritance

Multiple Inheritance

Repeated Inheritance

Selective inheritance
Allows a subclass to inherit a limited number of
properties from the superclass.
This feature may provide similar functionality to the
view mechanism in relational databases

Overriding, Overloading, and Polymorphism
Overriding
 Process of redefining a member within a subclass.
Overloading
 Allows name of a method to be reused with a class or
across classes.
Polymorphism
Means ‘many forms’. Three types: operation,
inclusion, and parametric.
 Overloading is one kind of polymorphism– operation
 A method defined in a superclass and inherited in its
subclasses is an example of inclusion polymorphism
 Parametric polymorphism, or genericity as it is
sometimes called, uses types as parameters in generic
type, or class, declarations. (Templates in C++)
Complex Objects
An object that consists of subobjects but is viewed as
a single object.
Objects participate in a A-PART-OF (APO)
relationship.
Contained object can be encapsulated within
complex object, accessed by complex object’s
methods.
Or have its own independent existence, and only an
OID is stored in complex object.

Advantages of OODBMSs
Enriched modeling capabilities
Extensibility
Removal of impedance mismatch
More expressive query language (Navigational
access is more suitable for handling parts explosion,
recursive queries, and so on)
Support for schema evolution
Support for long-duration transactions
Applicability to advanced database applications
Improved performance

Disadvantages of OODBMSs
Lack of universal data model
Lack of experience
Lack of standards (This is may be the single most
damaging factor for the adoption of OODBMSs)
Competition
Query optimization compromises encapsulation
Locking at object level may impact performance
Complexity
Lack of support for views
Lack of support for security

Storing Objects in Relational Databases
One approach to achieving persistence with an
OOPL is to use an RDBMS as the underlying
storage engine.
Requires mapping class instances (i.e. objects) to one
or more tuples distributed over one or more
relations.
To handle class hierarchy, have two basics tasks to
perform:
(1) design relations to represent class hierarchy;
(2) design how objects will be accessed.

Next Generation Database Systems
First Generation DBMS: Network and Hierarchical
Required complex programs for even simple
queries.
Minimal data independence.
No widely accepted theoretical foundation.
Second Generation DBMS: Relational DBMS

Helped overcome the problems of the first
generations.
Third Generation DBMS: OODBMS and ORDBMS.

History of Data Models

OODBMS and ORDBMS
Brief Overview

OODBMS –Object Oriented
DBMS
The Persistent, Sharable collections of
Objects in Database.

Object Oriented Model
Several important vendors formed the Object Data
Management Group(ODMG) to define standards for
OODBMSs.
These vendors included Sun Microsystems, eXcelon
Corporation, Objectivity Inc., POET Software,
Computer Associates, and Versant Corporation.
The major components of the ODMG architecture for
an OODBMS are:
Object Model (OM);
Object Definition Language (ODL);
Object Query Language (OQL);
C++, Java, and Smalltalk language bindings
Object Oriented Database Systems
50 04/13/2024
Object Oriented Model
 Relations are not the central concept, classes and objects are
the main concept
 Object-Oriented DBMS(OODBMS) are DBMS based on an
Object Oriented Data Model inspired by OO programming
languages
 Main Features:
 Powerful type system
 Classes
 Object Identity
 Inheritance
 OODBMS are capable of storing complex objects, i.e.,

objects that are composed of other objects, and/or multi-
valued attributes
Powerful type system

Classes
 A ‘class’ is
in replacement of ‘relation’
Same concept as in OO programming languages •
All objects belonging to a same class share the same
properties and behavior
 An ‘object’ can be thought of as ‘tuple’ (but richer
content)
Classes encapsulate data + methods +
relationships
Unlike relations that contain data only
In OODBMSs objects are persistent (unlike OO
programming languages -transient)
Object Identity
OID is a unique identity of each object
regardless of its content
Even if all attributes are the same, still
objects have different OIDs
Easier for references
An object is made of two things:
State: attributes (name, address, birthDate of a
person)
Behavior: operations (age of a person is
computed from birthDate and current date)
OO Inheritance

OODBMS Standards
 ODMG: Object Data Management Group (1991)
provide a standard where previously there was none
support portability between products
standardize model, querying and programming
issues
 Language of specifying the structure and querying of
object database
ODL: Object Definition Language
OQL: Object Query Language
ODL is somehow similar to DDL (Data
Definition Language) in SQL
Overview of ODL & OQL
Classes& Attributes

ODL- Relationships

ODL – Relationship and Inverse Relationships

ODL- Multiplicity of relationships

ODL- Method Declarations

ODL -Inheritance

ODL - Instances & Keys
Instance of a class are all objects of that class that
currently exist in the database.
In ODL that is called extent (and is given a name,
usually a plural noun.)
Extents are used as entry points to the database; that
is, by locating these objects by their unique name, the
user can then locate other objects that are referenced
from these objects
Keys are not as such important for referencing objects
Because each object already has a unique OID
Defining keys in ODL is optional
ODL allows defining multiple keys (Comma separated)
ODL- Extent and Keys

Examples of how Relationships are implemented.
Relationships represented using reference attributes,

typically implemented using OIDs.
Consider how to represent the following binary
relationships according to their cardinality:
1:1
1:*
*:*.

1:1 Relationship Between Objects A and B
Add reference attribute to A and, to maintain
referential integrity, reference attribute to B.

1:* Relationship Between Objects A and B
Add reference attribute to B and attribute containing
set of references to A.

*:* Relationship Between Objects A and B
Add attribute containing set of references to each
object.
For relational database design, would need to
decompose *:N into two 1:* relationships linked by
intermediate entity. Can also represent this model in
an ODBMS.

*:* Relationships

Alternative Design for *:* Relationships

OQL- Object Oriented Query Language
Have you heard about LINQ Query in C#??
OQL is a query language designed to operate on
databases described in ODL.
Provides declarative access to the object database
using an SQL-like syntax.
Tries to bring some concepts from the relational model
to the ODBMs
E.g., the SELECT statement, joins, aggregation, etc.
Does not provide explicit update operators, but
leaves this to the operations defined on object types

OQL- Object Oriented Query Language
Reference of class properties (attributes,
relationships, and methods) using:
Dot notation (p.a), or
Arrow notation (p->a)
In OQL both notations are equivalent
In addition, OML (Object Manipulation Language) is

used to specify how database objects are retrieved and
manipulated within the application program(C++, Java
etc.)

OQL - Example

OQL- OUTPUT
Unlike SQL which produces relations, OQL produces
collection (set, bag, list) of objects
 The object can be of any type

Integrating OQL & External Languages
OQL fits naturally in OO host languages.
Returned objects are assigned in variables
in the host program
Variables in OO C++, Java, C# etc. can be
used

Integrating OQL & External Languages

Object-Oriented Data Model
No one(single) agreed up on object data model.
However, One possible definition:
Object-Oriented Data Model (OODM)

Data model that captures semantics of objects as
supported in object-oriented programming.
Object-Oriented Database (OODB)
Persistent and sharable collection of objects defined by an
ODM.
Object-Oriented DBMS (OODBMS)
Manager of an ODB.

Prototype/Commercial OODBMS
 While RDBMS market exceeds $50 billion annually,
OODBMS in contrast has an estimated $50 million market
share
 Many prototypes as well as commercial OODBMS such as
O2,
Versant,
POET,
ONTOS,
Objectivity,
GemStone, and
ObjectStore
have been developed by both industrial and research
laboratories around the world.
Commercial OODBMSs
GemStone from Gemstone Systems Inc.,
Objectivity/DB from Objectivity Inc.,
ObjectStore from Progress Software Corp.,
Ontos from Ontos Inc.,
FastObjects from Poet Software Corp.,
Jasmine from Computer Associates/Fujitsu,
Versant from Versant Corp.

Origins of the Object-Oriented Data Model

ORDBMS –Object Relational
DBMS
The Object Oriented Concepts Directly
supported in Relational Databases.

Object Relational Data Model
Object-oriented model tries to bring the main
concepts from relational model into the OO
domain
The heart is OO concepts with some extensions
 Object-relational
model tries to bring the
main concepts from the OO domain to the
relational model
The heart is the Relational model with some
extensions
Extensions through user-defined types

Object Relational DM
Object-Relational Database (ORDB) captures the semantic
richness of OO Data Model (OODM) and the simplicity
of Relational Model implementation.
ORDBMS was created to handle new types of data

such as audio, video, and image files that relational
databases were not equipped to handle.
Object-relational systems include features such as
complex object extensibility, encapsulation,
inheritance, and better interfaces to OO languages

Conceptual View of Object-relational Model
Relation is still the fundamental structure
Relational model extended with the following features
 Type system with primitive and structure types
(UDT)
 Including set, Multisets, array, list collection types
Including structure like records
Methods
Special operations can be defined over the user-defined
types (UDT)
Specialized operators for complex types, e.g., images,
multimedia, etc.

Conceptual View of Object-relational Model..
Identifiers for tuples

Unique identifiers even for identical
tuples •
 References
Several ways for references and de-
references

Conceptual View of ORDBMS Cont’d…

Conceptual View of ORDBMS Cont’d…

Support from vendors
Several major software companies including IBM,
Informix, Microsoft, Oracle, and Sybase have all
released object-relational versions of their products.
 ANSI/ISO has introduced new SQL standards called
SQL3(SQL-99).
SQL-99 or SQL3 was Extended (to support other
features several times in; SQL:2003, 2006 with
extensions for XML (SQL:2006), 2008 (SQL:2008)
and 2011 (SQL:2011)
 Was also known as SQL/Object initially.
At present, ANSI/ISO is working on SQL4 that has
even more OO extensions
SQL-99(SQL/Object) SQL3: SQL for
Object-Relational Model
User-defied types (UDT) replace the
concept of classes
 Then create relations on top of the UDTs
Multiple relations can be created on top of
the same UDT.
General structure of a type:
Create Type <name> AS (attributes and)
method declarations;

SQL3 Supported features
Row Types - is a sequence of field name/data type pairs
Other collection types have the following meaning:
ARRAY—one-dimensional array with a maximum number of
elements;
MULTISET—unordered collection that does allow
duplicates;
LIST—ordered collection that allows duplicates;
SET—unordered collection that does not allow duplicates
These types are similar to those defined in the ODMG
3.0(ODL&OQL) standard with the name Bag replaced with the
SQL MULTISET
Support for large objects—Binary Large Objects (BLOBs)
and Character Large Objects (CLOBs);
Object Orientation in SQL3( Extensions)
Some of the object database features that have
been included in SQL
Type constructors such as
Row type
A mechanism for specifying object identity
through the use of reference type is included
Encapsulation of operations is provided
through the mechanism of user-defined types
(UDTs)
Inheritance mechanisms are provided using the
keyword UNDER
Creating a UDT – an Example

CREATE TYPE PERSON_TYPE AS (
NAME VARCHAR (35), You can create a
table
SEX CHAR,
BIRTH_DATE DATE,
PHONES PHONE_TYPE ARRAY [4], You can create a
sub class/type
ADDR ADDR_TYPE ) Method
INSTANTIABLE OID
declaration
NOT FINAL (Encapsulation)
REF IS SYSTEM GENERATED
INSTANCE METHOD AGE() RETURNS INTEGER;
CREATE INSTANCE METHOD AGE() RETURNS INTEGER FOR
PERSON_TYPE
BEGIN
RETURN /* CODE TO CALCULATE A PERSON’S AGE FROM
TODAY’S DATE AND SELF.BIRTH_DATE */
92 END;Oriented Database Systems
Object 04/13/2024
UDT Methods
A method is associated with a single UDT;
The signature of every method associated with a UDT must be
specified in that UDT and the definition of the method must
specify that UDT (and must also appear in the same schema
as the UDT).
There are three types of methods:
constructor methods, which initialize a newly created instance of a
UDT, using the NEW keyword
instance methods, which operate on specific instances of a UDT;
 Eg. P as StaffType; p.Fname, p.Salary etc
Static methods, which are analogous to class methods in some
object-oriented Programming languages and operate at the UDT
level rather than at the instance level.
 eg. if totalStaff is a static method of StaffType, we could invoke it as
StaffType::totalStaff()
Type(UDT) Inheritance
Type inheritance (specified via the UNDER
keyword)
In general, both attributes and instance
methods (operations) are inherited.
REF IS SYSTEM GENERATED is also
inherited.
The phrase NOT FINAL must be included
in a UDT if subtypes are allowed to be
created under that UDT
Creating a UDT – an Inheritance
Example
CREATE TYPE STUDENT_TYPE UNDER PERSON_TYPE AS (
MAJOR_CODE CHAR (4),
STUDENT_ID CHAR (12),
DEGREE VARCHAR (5),
TRANSCRIPT GRADE_TYPE ARRAY [100] )
INSTANTIABLE
NOT FINAL
INSTANCE METHOD GPA( ) RETURNS FLOAT;
CREATE INSTANCE METHOD GPA( ) RETURNS FLOAT FOR
STUDENT_TYPE
BEGIN
RETURN /* CODE TO CALCULATE A STUDENT’S GPA FROM
SELF.TRANSCRIPT */
END;
Relationships( Cardinality)
Using the Ref keyword
<RefVariable> REF(referencedUDTType)
SCOPE <Referenced table>
One-to-many Or one-to-one
Plug it inside the existing types
Many-to-many
Create a new type or new table referencing
existing types with a scope indicating the
referenceable table
Creating Tables Based on the UDTs
A UDT instance can persist only if it is stored as the
column value in a table.
For each UDT that is specified to be instantiable via the
phrase INSTANTIABLE, one or more tables may be
created.
Tables(views) can be Typed ( has “OF <Typename>”or
not Typed.
 CREATE TABLE PERSON OF PERSON_TYPE
REF IS PERSON_ID SYSTEM GENERATED;
 CREATE TABLE EMPLOYEE OF EMPLOYEE_TYPE
UNDER PERSON;
 CREATE TABLE MANAGER OF MANAGER_TYPE UNDER
EMPLOYEE;
 CREATE TABLE STUDENT OF STUDENT_TYPE UNDER
97 PERSON;
Object Oriented Database Systems 04/13/2024
Primary Key and Reference Attribute

Relationships( based on Cardinality)

Extended SQL Features(SQL3)
 An array type can have its elements referenced using the common
notation of square brackets.
Eg. PHONES[1] refers to the first location value in a PHONES
attribute.
 A built-in function CARDINALITY can return the current
number of elements in an array (or any other collection type).
E.g CARDINALITY (PHONES) returns the number of phones
 The commonly used dot notation is used to refer to components
of a ROW TYPE or a UDT.( if not a reference attribute)
e.g ADDR.CITY refers to the CITY component of an ADDR
attribute
 Another facility in SQL is table inheritance via the
supertable/subtable facility. This is also specified using the
100 keyword UNDER
Object Oriented Database Systems 04/13/2024
Querying Data - SQL3(SQL-
2011)
SQL-2011 -provides the same syntax as traditional
SQL for querying and updating tables, with various
extensions to handle objects.
Most relational operators work on the object relational
tables
E.g., selection, projection, aggregation, set operations
SQL-99( 2011 the latest) (SQL3): Extended SQL to
operate on object relational databases.

Consider the following UDT for Person Type
CREATE TYPE PersonType AS (
dateOfBirth DATE,
fName VARCHAR(15),
lName VARCHAR(15),
sex CHAR)
INSTANTIABLE
NOT FINAL
REF IS SYSTEM GENERATED
INSTANCE METHOD age () RETURNS INTEGER;
CREATE INSTANCE METHOD age () RETURNS

INTEGER FOR PersonType
BEGIN
RETURN /* age calculated from
SELF.dateOfBirth */;
Object Oriented Database Systems
102 END; 04/13/2024
Consider the following UDT for Staff Type
CREATE TYPE StaffType UNDER PersonType AS
(
staffNo VARCHAR(5),
position VARCHAR(10) DEFAULT ‘Assistant’,
salary DECIMAL(7, 2),
branchNo CHAR(4)
)
INSTANTIABLE
NOT FINAL
INSTANCE METHOD isManager () RETURNS BOOLEAN;
CREATE INSTANCE METHOD isManager() RETURNS BOOLEAN

FOR StaffType
BEGIN
IF SELF.position = ‘Manager’
THEN RETURN TRUE; ELSE RETURN FALSE;
END IF
103 END;Oriented Database Systems
Object 04/13/2024
SQL3 Query Examples
Find the names of all Managers.
SELECT s.lName
FROM Staff s
WHERE s.position = ‘Manager’;
Implicit getter method s.position compares

the returned value with the constant
“Manager”

Example: Invoking a user-defined
function
Find the names and ages of all Managers.
SELECT s.lName, s.age

FROM Staff s
WHERE s.isManager;
•Uses the user-defined method is Manager as a
predicate of the WHERE clause, which returns
a Boolean.
•Also, notice the s.age method which is
inherited from the person type
ORDBMS Query and Inheritance
Find the names of all people in the database over 65
years of age.
SELECT p.lName, p.fName
FROM Person p
WHERE p.age > 65;
This Query lists not only the details of rows that have
been explicitly inserted into the Person table, but also
the names from any rows that have been inserted into
any direct or indirect subtables of Person, in this case,
Staff and Client
But if you want objects only in the person table …???
ORDBMS Query -Examples
Using the Only Phrase in the Where clause
SELECT p.lName, p.fName
FROM ONLY (Person) p
WHERE p.age > 65;
Use of the dereference operator(get the tuple
pointed to by the pointer(Ref attribute)
SQL uses a dot notation to build path expressions
that refer to the component attributes of tuples
and row types. However, for an attribute whose
type is REF, the dereferencing symbol (–>) is
used.
dereference operator cont’d…
Find the name of the member of staff who manages
property ‘PG4’.
SELECT p.staffID–>fName AS fName,

p.staffID–>lName AS lName
FROM PropertyForRent p
WHERE p.propertyNo = ‘PG4’;
•Thus, if r is a reference to a tuple (object) and a is a

component attribute in that tuple, then r –> a is the
value of attribute a in that tuple.
Use of a collection Multisets
Extending the Staff table to contain the details of a
number of next-of-kin and then find the first and last
names of John White’s next-of-kin.
Need to include the definition of a nextOfKin column in
Staff as follows (NameType contains a fName and lName
attribute): (this creates a nested table in the staff)
nextOfKin NameType MULTISET
The Query becomes
SELECT n.fName, n.lName FROM Staff s,
UNNEST (s.nextOfKin) AS n(fName, lName)
WHERE s.lName = ‘White’ AND s.fName =
‘John’;
Multiset Collection Conceptual View of data in
ORDBMS Cont’d…

Chapter 5 Object Oriented Database Systems

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter 5 Object Oriented Database Systems

Uploaded by

Copyright:

Available Formats

Chapter 5

2 Object Oriented Database Systems 04/13/2024

4 Object Oriented Database Systems 04/13/2024

5 Object Oriented Database Systems 04/13/2024

This Diagram shows how data can be accessed.

6 Object Oriented Database Systems 04/13/2024

7 Object Oriented Database Systems 04/13/2024

8 Object Oriented Database Systems 04/13/2024

9 Object Oriented Database Systems 04/13/2024

10 Object Oriented Database Systems 04/13/2024

12 Object Oriented Database Systems 04/13/2024

Assuming we have a recursive relationship

Category( catID, catName,parentCatId)

15 Object Oriented Database Systems 04/13/2024

17 Object Oriented Database Systems 04/13/2024

18 Object Oriented Database Systems 04/13/2024

19 Object Oriented Database Systems 04/13/2024

20 Object Oriented Database Systems 04/13/2024

21 Object Oriented Database Systems 04/13/2024

22 Object Oriented Database Systems 04/13/2024

 Allows internal details of an object to be changed

23 Object Oriented Database Systems 04/13/2024

Definition very similar to that of an entity, however,

24 Object Oriented Database Systems 04/13/2024

25 Object Oriented Database Systems 04/13/2024

26 Object Oriented Database Systems 04/13/2024

27 Object Oriented Database Systems 04/13/2024

28 Object Oriented Database Systems 04/13/2024

30 Object Oriented Database Systems 04/13/2024

31 Object Oriented Database Systems 04/13/2024

32 Object Oriented Database Systems 04/13/2024

Objects in a class are called instances.

33 Object Oriented Database Systems 04/13/2024

34 Object Oriented Database Systems 04/13/2024

35 Object Oriented Database Systems 04/13/2024

36 Object Oriented Database Systems 04/13/2024

37 Object Oriented Database Systems 04/13/2024

38 Object Oriented Database Systems 04/13/2024

39 Object Oriented Database Systems 04/13/2024

40 Object Oriented Database Systems 04/13/2024

42 Object Oriented Database Systems 04/13/2024

43 Object Oriented Database Systems 04/13/2024

44 Object Oriented Database Systems 04/13/2024

45 Object Oriented Database Systems 04/13/2024

Second Generation DBMS: Relational DBMS

46 Object Oriented Database Systems 04/13/2024

47 Object Oriented Database Systems 04/13/2024

48 Object Oriented Database Systems 04/13/2024

49 Object Oriented Database Systems 04/13/2024

 OODBMS are capable of storing complex objects, i.e.,

52 Object Oriented Database Systems 04/13/2024

55 Object Oriented Database Systems 04/13/2024

57 Object Oriented Database Systems 04/13/2024

58 Object Oriented Database Systems 04/13/2024

59 Object Oriented Database Systems 04/13/2024

60 Object Oriented Database Systems 04/13/2024

61 Object Oriented Database Systems 04/13/2024

62 Object Oriented Database Systems 04/13/2024

64 Object Oriented Database Systems 04/13/2024

Relationships represented using reference attributes,

65 Object Oriented Database Systems 04/13/2024

66 Object Oriented Database Systems 04/13/2024

67 Object Oriented Database Systems 04/13/2024

68 Object Oriented Database Systems 04/13/2024