Unit 1: Object-Oriented

Databases
 Unit 1: Object-Oriented Databases
• Complex Data Types and Object Orientation
• Structured Data Types and Inheritance in SQL
• Table Inheritance
• Array and Multiset Types in SQL
• Object Identity and Reference Types in SQL
• Implementing O-R Features

Mrs. Deepali Jaadhav 2

 Object-Based Database
• Traditional database applications consist of data-processing tasks,
such as banking and payroll management, with relatively simple
data types that are well suited to the relational data model.
• As database systems were applied to a wider range of applications,
such as computer-aided design and geographical information
systems
• Limitations imposed by the relational model emerged as an
obstacle.
• The solution - object-based databases, which allow one to deal
with complex data types.
• Extend the relational data model by including object orientation
and constructs to deal with added data types.

Mrs. Deepali Jaadhav 3

 Object-Based Database
Object-database systems have developed along two distinct paths:
• Object-oriented database systems (OODBMS):
• Alternative to relational systems
• Aimed at application domains where complex objects play a central
role.
• Heavily influenced by object-oriented programming languages
• An attempt to add DBMS functionality to a programming language
environment.
• Ex: Versant Object Database, ObjectDB, db4o, and Zope Object Database
(ZODB)
• Object-relational database systems (ORDBMS):
• An attempt to extend relational database systems with the functionality
necessary to support a broader class of applications
• Provide a bridge between the relational and object-oriented paradigms
• Ex: IBM Db2, Oracle database, and Microsoft SQL Server

Mrs. Deepali Jaadhav 4

 Object-Relational Database
• Allow attributes of tuples to have complex types, including non-
atomic values such as nested record, structures, multivalued
attributes, and inheritance.
• Object-relational database systems based on the object-relation
model,
• Provide a convenient migration path from relational databases to
object-oriented features.
• It is desirable, for many applications, to have programming
language constructs or extensions that permit direct access to data
in the database.
• Upward compatibility with existing relational languages.

Mrs. Deepali Jaadhav 5

 Object-Relational Database
• The idea of object databases was originated in 1985 and today has
become common for various common OOP languages, such as C++,
Java, C#, Smalltalk, and LISP.
• Common examples are Smalltalk is used in GemStone, LISP is used
in Gbase, and COP is used in Vbase.
• Object databases are commonly used in applications that require
high performance, calculations, and faster results.
• Common applications - real-time systems, architectural &
engineering for 3D modeling, telecommunications, and scientific
products, molecular science, and astronomy.

Mrs. Deepali Jaadhav 6

 ORDBMS -Complex Data Types
• Traditional database applications have conceptually simple
data types.
• In recent years, demand has grown for ways to deal with more
complex data types.
• Eg: address (Street, city, state, postal code) : Composite
attribute or employee phone_no: Multivalued attribute.
• With complex type systems, we can represent E-R model
concepts, such as composite attributes, multivalued attributes,
generalization, and specialization directly, without a complex
translation to the relational model.
• Not all applications are best modeled by 1NF relations.
• Rather than view a database as a set of records, users of certain
applications view it as a set of objects (or entities).

Mrs. Deepali Jaadhav 7

 Complex Data Types
• Motivation:
• Permit non-atomic domains (atomic  indivisible)
• Example of non-atomic domain: set of integers, or set of
tuples
• Allows more intuitive modeling for applications with
complex data
• Intuitive definition:
• allow relations whenever we allow atomic (scalar) values
— relations within relations
• Retains mathematical foundation of relational model
• Violates first normal form.

Mrs. Deepali Jaadhav 8

 Complex Data Types
• User-defined abstract data types (ADTs): special
functions to manipulate objects
• Structured types: sets, tuples, arrays, sequences, and so on.
• Inheritance: inherit some features of parent object

Mrs. Deepali Jaadhav 9

 Example of a Nested Relation
• Example: library information system
• Each book has
• title,
• a list (array) of authors,
• Publisher, with subfields name and branch, and
• a set of keywords
• Non-1NF relation books

Mrs. Deepali Jaadhav 10

 Example of a Nested Relation
• Authors. A book may have a list of authors, which we can
represent as an array.
• Keywords. If we store a set of keywords for a book, we expect to
be able to retrieve all books whose keywords include one or more
specified keywords. Thus, we view the domain of the set of
keywords as nonatomic.
• Publisher. we may view publisher as consisting of the subfields
name and branch. This view makes the domain of publisher
nonatomic.

Mrs. Deepali Jaadhav 11

 4NF Decomposition of Nested Relation
• Suppose for simplicity that
title uniquely identifies a
book
• In real world ISBN is a
unique identifier
• Decompose books into 4NF
using the schemas:
• (title, author, position )
• (title, keyword )
• (title, pub-name, pub-
branch )
• 4NF design requires users
to include joins in their
queries.
Mrs. Deepali Jaadhav 12
 Complex Types and SQL
• Extensions introduced in SQL:1999 to support complex types:
• Collection and large object types
• Nested relations are an example of collection types
• Structured types
• Nested record structures like composite attributes
• Inheritance
• Object orientation
• Including object identifiers and references
• Not fully implemented in any database system currently
• But some features are present in each of the major
commercial database systems

Mrs. Deepali Jaadhav 13

 Structured Types and Inheritance in SQL

• Structured types allow composite attributes of E-R

designs to be represented directly.
• Structured types (a.k.a. user-defined types) can be
declared and used in SQL
• CREATE TYPE TYPE_NAME AS (<component
declarations>);

Mrs. Deepali Jaadhav 14

 Structured Types and Inheritance in SQL
• Example:
• create type Name as object
(firstname varchar(20),
lastname varchar(20))
final;
create type Address as object
(street varchar(20),
city varchar(20),
zipcode varchar(20))
not final;
• Note: final and not final indicate whether subtypes can be
created or not.

Mrs. Deepali Jaadhav 15

 Structured Types and Inheritance in SQL
• Structured types can be used to create tables with composite
attributes
create table person (
name Name,
address Address,
dateOfBirth date);
• Dot notation used to reference components: name.firstname :
returns the firstname component of the name attribute.

Mrs. Deepali Jaadhav 16

 Structured Types (cont.)
• User-defined row types
create type PersonType as object (
name Name,
address Address,
dateOfBirth date)
not final;
• Can then create a table whose rows are a user-defined type
create table person of PersonType
• Alternative using unnamed row types.
create table person_r(
name row(firstname varchar(20),
lastname varchar(20)),
address row(street varchar(20),
city varchar(20),
zipcode varchar(20)),
dateOfBirth date);
• Attributes name and address have unnamed type
Mrs. Deepali Jaadhav 17
 Structured Types (cont.)

• The query finds the last name and city of each person.
select name.lastname, address.city
from person;
select p.name.lastname from person p;

Mrs. Deepali Jaadhav 18

 Methods (Encapsulation of Operations)

• A structured type can have methods defined on it. Can

add a method declaration with a structured type.
• CREATE TYPE <TYPE-NAME> ( <LIST OF COMPONENT
ATTRIBUTES AND THEIR TYPES>
<DECLARATION OF FUNCTIONS (METHODS)> );

Mrs. Deepali Jaadhav 19

 Methods (Encapsulation of Operations)
Ex: method ageOnDate (onDate date)
returns interval year
• Method body is given separately.
create instance method ageOnDate (onDate date)
returns interval year
for PersonType
begin
return onDate - self.dateOfBirth;
end
• The for clause indicates which type this method is for, while
the keyword instance indicates that this method executes on
an instance of the Person type.
• The variable self refers to the Person instance on which the
methodMrs.isDeepali
invoked.
Jaadhav 20
 Methods
• Methods can be invoked on instances of a type.
• If we had created a table person of type PersonType, we could
invoke the method ageOnDate to find the age of each person:
select name.lastname, ageOnDate (current_date)
from person;

Mrs. Deepali Jaadhav 21

 Constructor Functions
• Type Constructors define and create types or classes within an OODB.
• Specifying how objects of a particular type should be constructed,
including their attributes and methods.
• Type Constructors support features such as inheritance, allowing for the
creation of new types based on existing ones.
• Constructor functions are used to create values of structured
types including attributes and methods.
• A function with the same name as a structured type is a constructor
function for the structured type.

Mrs. Deepali Jaadhav 22

 Constructor Functions
• Constructor functions are used to create values of structured types.
• A function with the same name as a structured type is a constructor
function for the structured type.
• E.g.
create function Name (firstname varchar (20), lastname varchar (20))
returns Name
begin
set self.firstname = firstname;
set self.lastname = lastname;
end
• To create a value of type Name, we use
new Name(‘John’, ‘Smith’)
• Normally used in insert statements
insert into Person values
(new Name(‘John’, ‘Smith),
new Address(’20 Main St’, ‘New York’, ‘11001’),
date Mrs.
‘1960-8-22’);
Deepali Jaadhav 23
 Type Inheritance
• Inheritance creates a hierarchical relationship between related classes
while making parts of code reusable.
• Defining new types inherits all the existing class fields and methods
plus further extends them.
• The existing class is the parent class, while the child class extends the
parent.
• For example, a parent class called Vehicle will have child
classes Car and Bike.
• Both child classes inherit information from the parent class
and extend the parent class with new information depending on the
vehicle type.

Mrs. Deepali Jaadhav 24

 Type Inheritance
Key Terminologies
• Supertable: The class or table whose methods and attributes are
inherited is called the supertable or base tabe. Another name for it is
the parent table.
• Subtable/Derived table: In an inheritance structure, a sub table is a
class or table that receives some methods and attributes from parent
table. Another name for it is the child table.

Mrs. Deepali Jaadhav 25

 Type Inheritance
• Suppose that we have the following type definition for people:
create type Person
(name varchar(20),
address varchar(20))
• Using inheritance to define the student and teacher types
create type Student
under Person
(degree varchar(20),
department varchar(20))
create type Teacher
under Person
(salary integer,
department varchar(20))
• Both Student and Teacher inherit the attributes of Person—namely,
name and address. Student and Teacher are said to be subtypes of
Person, and Person is a supertype of Student, as well as of Teacher.
Mrs. Deepali Jaadhav 26
 Type Inheritance
• Methods of a structured type are inherited by its subtypes, just as
attributes are.
• Subtypes can redefine methods by using overriding method in
place of method in the method declaration.
• The SQL standard requires an extra field at the end of the type
definition, whose value is either final or not final.
• The keyword final says that subtypes may not be created from the
given type, while not final says that subtypes may be created.

Mrs. Deepali Jaadhav 27

 Multiple Type Inheritance
• Now suppose that we want to store information about teaching
assistants, who are simultaneously students and teachers.
• We can do this if the type system supports multiple inheritance,
where a type is declared as a subtype of multiple types.
• SQL:1999 and SQL:2003 do not support multiple inheritance
• If our type system supports multiple inheritance, we can define a
type for teaching assistant as follows:
create type Teaching Assistant
under Student, Teacher
• Teaching Assistant inherits all the attributes of Student and
Teacher.

Mrs. Deepali Jaadhav 28

 Multiple Type Inheritance
• The attribute department is defined separately in Student and
Teacher. In fact, a teaching assistant may be a student of one
department and a teacher in another department.
• To avoid a conflict between the two occurrences of department we
can rename them
create type Teaching Assistant
under
Student with (department as student_dept ),
Teacher with (department as teacher_dept )
• Each value of a structured type must have a most-specific type -
each value must be associated with one specific type.
• For example, suppose that an entity has the type Person, as well as
the type Student. Then, the most-specific type of the entity is
Student, since Student is a subtype of Person.
Mrs. Deepali Jaadhav 29
 Table Inheritance
• Tables created from subtypes can further be specified as
subtables
• E.g. create table people of Person;
create table students of Student under people;
create table teachers of Teacher under people;
• The types of the subtables (Student and Teacher) are subtypes of
the type of the parent table (Person).
• As a result, every attribute present in the table people is also
present in the subtables students and teachers.
• When we declare students and teachers as subtables of people,
every tuple present in students or teachers becomes implicitly
present in people.

Mrs. Deepali Jaadhav 30

 Table Inheritance
• Tuples added to a subtable are automatically visible to queries on
the supertable
• Similarly updates/deletes on people also result in updates/deletes
on subtables
• E.g. a statement: delete from people where P;
would delete all tuples from the table people, as well as its subtables
students and teachers, that satisfy P.
• To override this behaviour, use “only people” in query
• If the only keyword is added to the above statement, tuples that
were inserted in subtables are not affected, even if they satisfy the
where clause conditions.

Mrs. Deepali Jaadhav 31

 Table Inheritance
• Conceptually, multiple inheritance is possible with tables
• e.g. teaching_assistants under students and teachers
create table teaching assistants
of Teaching_Assistant
under students, teachers;
• Every tuple present in the teaching assistants table is also
implicitly present in the teachers and in the students table, and in
turn in the people table.
• But is not supported in SQL currently
• So we cannot create a person (tuple in people) who is both
a student and a teacher

Mrs. Deepali Jaadhav 32

 Table Inheritance

• The objects Circle, Rectangle and Triangle inherit from the object
Shape.
Mrs. Deepali Jaadhav 33
 Array and Multiset Types in SQL
• SQL supports two collection types: arrays and multisets; array types
were added in SQL:1999, while multiset types were added in
SQL:2003.
• An array is a collection of similar data elements stored at
contiguous memory locations. The elements of an array are ordered.
• It is the simplest data structure where each data element can be
accessed directly by only using its index number.
• A multiset is an unordered collection, where an element may occur
multiple times.
• Multisets are like sets, except that a set allows each element to occur
at most once.

Mrs. Deepali Jaadhav 35

 Array and Multiset Types in SQL
• Suppose we wish to record information about books, including a set
of keywords for each book.
• Suppose also that we wished to store the names of authors of a book
as an array; the elements of an array are ordered, so we can
distinguish the first author from the second author, and so on.
• Example of array and multiset declaration:
create type Publisher as
(name varchar(20),
branch varchar(20));
create type Book as
(title varchar(20),
author_array varchar(20) array [10],
pub_date date,
publisher Publisher,
keyword-set varchar(20) multiset);
createMrs.table books of Book;
Deepali Jaadhav 36
 Creation of Collection Values

• Array construction
array [‘Silberschatz’,`Korth’,`Sudarshan’]
• Multisets
multiset [‘computer’, ‘database’, ‘SQL’]
• To create a tuple of the type defined by the books relation:
(‘Compilers’, array[`Smith’,`Jones’], 16-02-1990,
new Publisher (`McGraw-Hill’,`New York’),
multiset [`parsing’,`analysis’ ])

Mrs. Deepali Jaadhav 37

 Creation of Collection Values
• To insert the preceding tuple into the relation books
insert into books
values
(‘Compilers’, array[`Smith’,`Jones’], 16-02-1990,
new Publisher (`McGraw-Hill’,`New York’),
multiset [`parsing’,`analysis’ ]);
• We can access or update elements of an array by specifying the
array index, for example author array[1].
• To find all books that have the word “database” as a keyword,
select title
from books
where ‘database’ in (unnest(keyword-set ))
• unnest(keyword_set): This expands the array stored in
keyword_set into individual rows .
Mrs. Deepali Jaadhav 38
 Querying Collection-Valued Attributes
• We can access individual elements of an array by using indices
• E.g.: If we know that a particular book has three authors, we
could write:
select author_array[1], author_array[2], author_array[3]
from books
where title = `Database System Concepts’

Mrs. Deepali Jaadhav 39

 Querying Collection-Valued Attributes
• To get a relation containing pairs of the form “title, author_name” for
each book and each author of the book
select B.title, A.author
from books as B, unnest (B.author_array) as A (author )
• To retain ordering information we add a with ordinality clause
select B.title, A.author, A.position
from books as B, unnest (B.author_array) with ordinality as
A (author, position )

Mrs. Deepali Jaadhav 40

 Unnesting
• The transformation of a nested relation into a form with fewer (or no)
relation-valued attributes us called unnesting.
• E.g.
select title, A as author, publisher.name as pub_name,
publisher.branch as pub_branch, K.keyword
from books as B, unnest(B.author_array ) as A (author ),
unnest (B.keyword_set ) as K (keyword )
• Result relation flat_books

Mrs. Deepali Jaadhav 41

 Nesting
• Nesting is the opposite of unnesting, creating a collection-valued
attribute
• Nesting can be done in a manner similar to aggregation, but using
the function collect() in place of an aggregation operation, to
create a multiset.
• To nest the flat_books relation on the attribute keyword:
select title, author, Publisher (pub_name, pub_branch ) as
publisher,
collect (keyword) as keyword_set
from flat_books
groupby title, author, publisher

Mrs. Deepali Jaadhav 42

 Nesting
• To nest on both authors and keywords:
select title, collect (author ) as author_set,
Publisher (pub_name, pub_branch) as publisher,
collect (keyword ) as keyword_set
from flat_books
group by title, publisher

Mrs. Deepali Jaadhav 43

 Object-Identity and Reference Types
• Object-oriented languages provide the ability to refer to objects.
• An attribute of a type can be a reference to an object of a specified
type.
• Define a type Department with a field name and a field head which is
a reference to the type Person, with table people as scope:
create type Department (
name varchar (20),
head ref (Person) scope people)
• We can then create a table departments as follows
create table departments of Department
• We can omit the declaration scope people from the type declaration
and instead make an addition to the create table statement:
create table departments of Department
(head with options scope people)
Mrs. Deepali Jaadhav 45
 Initializing Reference-Typed Values
• Referenced table must have an attribute that stores the identifier,
called the self-referential attribute
create table people of Person
ref is person_id system generated;
• Here, person_id is an attribute name, not a keyword, and the create
table statement specifies that the identifier is generated
automatically by the database.
• To create a tuple with a reference value, we can first create the tuple
with a null reference and then set the reference separately:
insert into departments
values (`CS’, null)
update departments
set head = (select p.person_id
from people as p
where name = `John’)
Mrs. Deepali Jaadhav 46
where name = `CS’;
 User Generated Identifiers
• An alternative to system-generated identifiers is to allow users to
generate identifiers.
• The type of the object-identifier must be specified as part of the
type definition of the referenced table, and
• The table definition must specify that the reference is user
generated
create type Person
(name varchar(20)
address varchar(20))
ref using varchar(20)

create table people of Person

ref is person_id user generated

Mrs. Deepali Jaadhav 47

 User Generated Identifiers
• When creating a tuple, we must provide a unique value for the
identifier:
insert into people (person_id, name, address ) values
(‘01284567’, ‘John’, `23 Coyote Run’)
• We can then use the identifier value when inserting a tuple into
departments
• Avoids need for a separate query to retrieve the identifier:
insert into departments
values(`CS’, `02184567’)

Mrs. Deepali Jaadhav 48

User Generated Identifiers (Cont.)
• Can use an existing primary key value as the identifier:
create type Person
(name varchar (20) primary key,
address varchar(20))
ref from (name)

create table people of Person

ref is person_id derived
• When inserting a tuple for departments, we can then use
insert into departments
values(`CS’,`John’)

Mrs. Deepali Jaadhav 49

 Path Expressions
• References are dereferenced in SQL:1999 by the −> symbol.
• Find the names and addresses of the heads of all departments:
select head –>name, head –>address
from departments
• An expression such as “head–>name” is called a path expression
• Path expressions help avoid explicit joins
• If department head were not a reference, a join of departments
with people would be required to get at the address
• Makes expressing the query much easier for the user

Mrs. Deepali Jaadhav 50

 Implementing O-R Features
• Object-relational database systems
are basically extensions of existing
relational database systems.
• The complex data types supported
by object-relational systems can be
translated to the simpler type
system of relational databases.
• EX: multivalued attributes in the E-R
model correspond to multiset-
valued attributes in the object-
relational model.
• Composite attributes roughly
correspond to structured types.

Mrs. Deepali Jaadhav 51

 Implementing O-R Features
• ISA hierarchies in the E-R model correspond to table inheritance in
the object-relational model.
• The techniques for converting E-R model features to tables can be
used, with some extensions, to translate object-relational data to
relational data at the storage level.
• Subtable implementation
• Each table stores the primary key (which may be inherited from a
parent table) and the attributes that are defined locally.
• Each table stores both locally defined and inherited
attributes. When a tuple is inserted, it is stored
only in the table in which it is inserted, and its
presence is inferred in each of the
supertables.
• Access to all attributes of a tuple
is faster, since a join is not required.
Mrs. Deepali Jaadhav 52
End of Unit 1