Object relational data model - CO4, BTL4

As in Syllabus:
Object Relational Data Models – Complex Data Types, Inheritance, Nesting and Unnesting.
Text Book:
Silberschatz A, Korth H F and Sudharshan S, “Database System Concepts”, Sixth Edition, Tata
McGraw-Hill Publishing Company Limited, 2010.
Chapter 22. pp. 945 – 964

Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Overview
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 (CAD) and geographical information systems
(GIS), limitations imposed by the relational model emerged as an obstacle.

The solution was the introduction of object-based databases, which allow

one to deal with complex data types.
Overview
The object-relational model, combines features of the relational and object-
oriented models.

This model provides the rich type system of object-oriented languages,

combined with relations as the basis for storage of data.

It applies inheritance to relations, not just to types.

The object-relational data model provides a smooth migration path from

relational databases, which is attractive to relational database vendors.

As a result, the SQL standard includes a number of object-oriented features

in its type system, while continuing to use the relational model as the
underlying model.
Overview Obstacle of relational data model

(1)Relational model has limited type system.

(but the complex data types includes nested record structures,
multivalued attributes and inheritance etc.)

• The object-relational data model extends the relational data model

by providing a richer type system including complex data types and
object orientation.

• Object-relational database systems, that is, database systems

based on the object-relational model, provide a convenient migration
path for users of relational databases who wish to use object-oriented
features.
Overview Obstacle of relational data model

(2) The second obstacle was the difficulty in accessing database data from
programs
written in programming languages such as C++ or Java.

Differences between the type system of the database and the type system
of the programming language make data storage and retrieval more
complicated, and need to be minimized.

It is desirable, for many applications, to have programming language

constructs or extensions that permit direct access to data in the database,
without having to go through an intermediate language such as SQL.
Overview
We will discuss the following
(1) Motivation for the development of complex data types.

(2) Issues of supporting native type system of an object-oriented

programming language.

Two approaches
(a) Build an object-oriented database system, that is, a database
system that natively supports an object-oriented type system, and allows
direct access to data from an object-oriented programming language using
the native type system of the language.

(b) Automatically convert data from the native type system of the
programming language to a relational representation, and vice versa. Data
conversion is specified using an object-relational mapping.
Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Complex Datatypes
Traditional database applications have conceptually simple data types – Numeric,
Text, Date, etc.

In recent years, demand has grown for ways to deal with more complex data
types.

Consider, for example, addresses.

While an entire address could be viewed as an atomic data item of type string,
this view would hide details such as the street address, city, state, and
postal code, which could be of interest to queries.

On the other hand, if an address were represented by breaking it into the

components (street address, city, state, and postal code), writing queries would
be more complicated since they would have to mention each field.

A better alternative is to allow structured data types that allow a type address
with subparts
Complex Datatypes
Another Example:
• Phone Number – it is a multivalued attribute.
• In relational model, we need to create a separate table to store multivalued attribute.

With complex type systems we can represent E-R model concepts, such
as
composite attributes (Eg. Address)
multivalued attributes (Eg. Phone numbers),
generalization, and
specialization
directly, without a complex translation to the relational model.

Recall 1 NF…
First Normal Form (1NF)-The
Requirements
The requirements to satisfy the First Normal Form (1NF):

Each table has a primary key: minimal set of attributes

which can uniquely identify a record.

The values in each column of a table are atomic (No multi-

valued attributes allowed).

There are no repeating groups: two columns do not store

similar information in the same table .

Recall 1 NF…
First Normal Form - No multivalued
attributes
• A domain is atomic if elements of the domain are indivisible.
• We say that a relation schema R is in first normal form (1NF) if the
domains of all attributes of R are atomic.

Recall 1 NF…
A table is considered to be in 1NF if all the fields contain
only scalar values (as opposed to list of values).
Example (Not 1NF)

Author
Authorand
andAuPhone
AuPhonecolumns
columnsare
arenot
notscalar
scalar

Recall 1 NF…
 1NF - Decomposition
1.Place all items that appear in the repeating group in a new table
2.Designate a primary key for each new table produced.
3.Duplicate in the new table the primary key of the table from which
the repeating group was extracted or vice versa.
Example (1NF)

Recall 1 NF…
 Not in 1 NF

In 1 NF

Recall 1 NF…
  There are no repeating groups: two columns
do not store similar information in the same
table.
This violates first normal form.
An apparent solution is to
introduce more columns:
The two telephone number columns
still form a "repeating group":
Adding an extra telephone number
may require the table to be
reorganized by the addition of a new
column.
And we ensure no row contains more
than one phone number

Recall 1 NF…
Complex Datatypes
The assumption of 1NF is a natural one in the database application
examples, we have considered till now.

However, not all applications are best modeled by 1NF relations.

For example, rather than view a database as a set of records, users of

certain applications view it as a set of objects (or entities).

These objects may require several records for their representation.

Complex Datatypes
Consider, for example, a library application, and suppose we wish to
store the following information for each book:
• Book title. • List of authors. • Publisher. • Set of keywords.
We can see that, if we define a relation for the preceding information, several
domains will be nonatomic.
Complex Datatypes Figure 22.1 shows an example relation, books.

We can then represent the same information

using the following schema, where the
primary key attributes are underlined:
• authors(title, author, position)
• keywords(title, keyword)
• books4(title, pub name, pub branch)

The above schema satisfies 4NF. Figure 22.2

shows the normalized representation of the
data from Figure 22.1.
Complex Datatypes
Although our example book database can be adequately expressed
without using nested relations, the use of nested relations leads to an
easier-to-understand model.

Complex data types such as sets and arrays can be useful.

Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Structured types and inheritance in SQL Structured types
Before SQL:1999, the SQL type system consisted of a fairly simple set of predefined types.
SQL:1999 added an extensive type system to SQL, allowing structured types and type
inheritance.
22.3.1 Structured Types
Structured types allow composite attributes to be represented directly.

For instance, we can define the following structured type to represent a composite
attribute name with component attribute firstname and lastname:
Similarly, the following structured type can be used
to represent a composite attribute address:

The final and not final specifications are

Such types are called user-defined types in related to subtyping, which will be discussed
SQL.
Structured types and inheritance in SQL Structured types
We can now use these types to create composite attributes in a relation,
by simply declaring an attribute to be of one of these types. For example,
we could create a table person as follows:

The components of a composite attribute can be accessed using a “dot”

notation; for instance name.firstname returns the firstname component of
the name attribute.
Structured types and inheritance in SQL Structured types
We can also create a table whose rows are of a user-defined type.

For example, we could define a type PersonType and create the table
person as follows:

Previous Slide….
Structured types and inheritance in SQL Structured types
An alternative way of defining composite attributes in SQL is to use unnamed row
types.

For instance, the relation representing person information could have been created using
row types as follows:

This definition is equivalent to the preceding table definition, except that

the attributes name and address have unnamed types, and the rows of
the table also have an unnamed type.
Structured types and inheritance in SQL Structured types
The following query illustrates how to access component attributes of a
composite attribute.

The query finds the last name and city of each person.

select
selectname.lastname,
name.lastname,address.city
address.city
from
fromperson;
person;
Structured types and inheritance in SQL Structured types
A structured type can have methods defined on it. We declare
methods as part of the type definition of a structured type:
We create the method body
separately:

Note that the for clause indicates which

If we had created a table person of type this method is for, while the keyword
type PersonType, we could invoke the instance indicates that this method
method ageOnDate() as illustrated executes on an instance of the Person
below, to find the age of each person. type. The variable self refers to the
Person instance on which the method is
invoked.
Structured types and inheritance in SQL Structured types
In SQL:1999, constructor functions are used to inititaize values of
structured types.

A function with the same name as a structured type is a constructor

function for the structured type. For instance, we could declare a
constructor for the type Name like this:

The following statement illustrates how we can create a new tuple in the
Person relation. We assume that a constructor has been defined for
Address, just like the constructor we defined for Name.
Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Structured types and inheritance in SQL Type inheritance

Suppose that we have the following type definition for

people:
We may want to store extra information in the
database about people who are students, and
about people who are teachers.

Since students and teachers are also people, we

can use inheritance to define the student and
teacher types in SQL:

Both Student and Teacher inherit the

attributes of Person—namely, name and
address.

Student and Teacher are said to be subtypes

of Person.

Person is a supertype of Student, as well as of

Structured types and inheritance in SQL Type inheritance

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.

Examples
Structured types and inheritance in SQL Type inheritance
Multiple
inheritance
Now suppose that we want to store information about teaching assistants, who are
simultaneously students and teachers, perhaps even in different departments.

For instance, if SQL’s type system supports multiple inheritance, we can define a type
for teaching assistant as follows:

To avoid a conflict between the two occurrences of department, we can

rename them by using an as clause, as in this definition of the type
TeachingAssistant:
From Previous Slide…
Table inheritance

Subtables in SQL correspond to the E-R notion of specialization /

generalization.

Tables
Person(Name, Phone, Address)
Employee(Empid, Name, Phone, Address, Salary)
Customer(Customer_id, Name, Phone, Address, Email, Credit)
Table inheritance

For instance, suppose we define the people table as follows:

create table people of Person;

We can then define tables students and teachers as

subtables of people, as follows:

As a result
(1) Every attribute present in the table people is also present in the
subtables students and teachers.

(2)Every tuple present in students or teachers becomes implicitly present

in people.
Table inheritance
If a query uses the table people, it will find not only tuples directly inserted into that table,
but also tuples inserted into its subtables, namely students and teachers.

However, only those attributes that are present in people can be accessed by that query.

SQL permits us to find tuples that are in people but not in its subtables by
using “only people” in place of people in a query.

The only keyword can also be used in delete and update statements.

Without the only keyword, a delete statement on a supertable, such as

people, also deletes tuples that were originally inserted in subtables (such
as students); for example, 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.
delete from only people where P; would delete records
Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Array and Multiset types in SQL
SQL supports two collection types: arrays and multisets

• multiset is an unordered collection, where an element may occur multiple times.

• the elements of an array are ordered, so we can distinguish the first element from the
second element, and so on.
The following example illustrates how these array and multiset-valued attributes can be
defined in SQL:
The first statement defines a type called Publisher
with two components: a name and a branch.

The second statement defines a structured type

Book that contains a title, an author array, which
is an array of up to 10 author names, a publication
date, a publisher (of type Publisher), and a multiset
of keywords.

Finally, a table books containing tuples of type

Book is created.
Array and Multiset types in SQL

In general, multivalued attributes can be mapped to multiset-valued

attributes in SQL; if ordering is important, SQL arrays can be used instead
of multisets.
Array and Multiset types in SQL Creating and Accessing Collection
Values

we can create a tuple of the type defined by the books

relation as:

If we want to insert the preceding tuple into the relation

books, we could execute the statement:

We can access or update elements of an array by specifying the array index, for example
author array[1].
Array and Multiset types in SQL Querying Collection-Valued
Attributes

To find all books that have the word “database” as one of their
keywords, we can use this query:

If we know that a particular book has three authors, we could

write:
Array and Multiset types in SQL Querying Collection-Valued
Attributes
Now, suppose that we want a relation containing pairs of the form “title,
author name” for each book and each author of the book.

We can use this query:

Since the author_array attribute of books is a collection-valued field,

unnest(B.author_array) can be used in a from clause, where a relation
is expected.

Note that the tuple variable B is visible to this expression since it is

defined earlier in the from clause.
Array and Multiset types in SQL Querying Collection-Valued
Attributes

When unnesting an array, the previous query loses information about the
ordering of elements in the array.

The unnest with ordinality clause can be used to get this information,
as illustrated by the following query.

This query can be used to generate the authors relation ,which we saw
earlier, from the books relation

The with ordinality clause generates an extra attribute which records the position of
the element in the array.

A similar query, but without the with ordinality clause, can be used to generate the
Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Nesting and Unnesting
The transformation of a nested relation into a form with fewer (or no)
relation valued attributes is called unnesting.

The books relation has two attributes, author_array and keyword_set,

that are collections, and two attributes, title and publisher, that are not.

Suppose that we want to convert the relation into a single flat relation, with
no nested relations or structured types as attributes.

flat books: result of

unnesting attributes
author_array and
keyword_ set of relation
books.
Nesting and Unnesting

We can use the following query to get the above result

The variable B in the from clause is declared to range over books.
The variable A is declared to range over the authors in author array for the book B.
The variable K is declared to range over the keywords in the keyword set of the
book B.

The result of this query is below (will name it as flat_books).

The relation flat_books is in 1NF, since all its attributes are atomic valued.
Nesting and Unnesting
The reverse process of transforming a 1NF relation into a nested relation is
called nesting.

Nesting can be carried out by an extension of grouping in SQL.

Suppose that we are given the 1NF relation flat books, the following query
nests the relation on the attribute keyword:

In the normal use of grouping in SQL, a temporary multiset relation is (logically) created
for each group, and an aggregate function is applied on the temporary relation to get a
single (atomic) value.

The collect function returns the multiset of values, so instead of creating a single
Nesting and Unnesting
The result of the query on
the flat books relation from
Figure 22.3 appears in
Figure 22.4.
If we want to nest the author attribute also into a multiset, we can use the query:
Nesting and Unnesting
Another approach to creating nested relations is to use subqueries in the select clause.

An advantage of the subquery approach is that an order by clause can be used in the
subquery to generate results in the order desired for the creation of an array.

The following query illustrates this approach; the keywords array and multiset specify
that an array and multiset (respectively) are to be created from the results of the
subqueries.

The system executes the nested

subqueries in the select clause for each
tuple generated by the from and where
clauses.

Observe that the attribute B.title is used

in the nested queries, to ensure that only
the correct sets of authors and keywords
are generated for each title.
Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
 Type creations Table Creation (1) Table Creation (2)

Table Creation (3)

Type Inheritance

Type Inheritance - Multiple

Table Inheritance

create table people of

Person;

Recall…..
Object-identity and references types in SQL.
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.

For example, in SQL we can define a type Department with a field name
and a field head that is a reference to the type Person, and a table
departments of type Department, as follows:

Here, the reference is restricted to tuples of

the table people.

Ie., the head is of type person in the people

table.

Recall: create table people of

Object-identity and references types in SQL.
We can omit the declaration scope people
from the type declaration and instead make
an addition to the create table statement:

The referenced table must have an attribute that

stores the identifier of the tuple.

We declare this attribute, called the self-

referential attribute, by adding a ref is clause
to the create table statement:
The person id is an attribute name, and is generated automatically by
the database.
Note – now the Department table has two attributes : name and head.

The head attribute to stored with the person_id of the person table, who is the head of
the department.
Object-identity and references types in SQL.
In order to initialize a reference attribute, we need to get the identifier of the tuple that
is to be referenced.

We can get the identifier value of a tuple by means of a query.

Thus, to create a tuple with the reference value, we may first create the tuple with a null
reference and then set the reference separately: (Assume, it is known that ‘John’ is the
head of ‘CS’ department.
Object-identity and references types in SQL.
An alternative to system-generated identifiers is to allow users to
generate identifiers.

The type of the self-referential attribute 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: Now, when inserting a tuple in people, we must
then provide a value for the identifier:

We can then use the identifier value when inserting a

tuple into departments, without the need for a
separate query to retrieve the identifier:
Object-identity and references types in SQL.
It is even possible to use an existing primary-key value as the identifier, by
including the ref from clause in the type definition:
When inserting a tuple for departments, we can
then use:

References are dereferenced in SQL:1999 by the −>

symbol.

Consider the departments table defined earlier.

We can use this query to find the names and

addresses of the heads of all departments:
An expression such as “head−>name” is called a path
expression.
Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.
Implementing O-R features.
Object-relational database systems are basically extensions of existing
relational database systems.

Changes are clearly required at many levels of the database system.

However, to minimize changes to the storage-system code (relation

storage, indices, etc.), the complex data types supported by object-
relational systems can be translated to the simpler type system of
relational databases.
There are techniques, to translate object-relational data to
relational data at the storage level.
 Object relational data model - CO4, BTL4

Topics to Discuss:
1) Overview
2) Complex datatypes
3) Structure types and inheritance in SQL.
4) Table inheritance.
5) Array and multiset types in SQL.
6) Nesting and Unnesting
7) Object-identity and references types in SQL.
8) Implementing O-R features.

… The End ….