II IV

CS 8492
DATABASE MANAGEMENT SYSTEMS
(Common to CSE & IT)

UNIT NO. 5

5.2 OBJECT BASED DATABASES; OBJECT DATABASE

CONCEPTS,OBJECT RELATIONAL FEATURES

Version: 1.0
 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

OBJECT-BASED DATABASES

An object-oriented database system 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.

Complex Data Types

Traditional database applications have conceptually simple data types. The basic data
items are records that are fairly small and whose fields are atomic.

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 street address, city,
state, and postal code.

Structured Types

Structured types allow composite attributes of E-R designs 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

create type Name as

(firstname varchar(20),

lastname varchar(20))
 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

final;

Such types are called user-defined types in SQL.

The final and not final specifications are related to subtyping.

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

for instance, name.

firstname returns the first name component of the name attribute.

An access to attribute name would return a value of the structured type Name.

We can also create a table whose rows are of a user-defined type.

For example, we could define a type

Person Type and create the table person as follows

create type PersonType as (

name Name,

address Address,

dateOfBirth date)

not final

create table person of PersonType;

Type Inheritance

Suppose that we have the following type definition for people:

create type Person

(name varchar(20),
 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

address varchar(20));

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:

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 super type of
Student, as well as of Teacher.

Table Inheritance

Sub tables in SQL correspond to the E-R notion of specialization/generalization. For

instance, suppose we define the people table as follows:

create table people of Person;

We can then define tables students and teachers as sub tables of people, as follows:

create table students of Student

 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

under people;

create table teachers of Teacher

under people;

The types of the sub tables (Student and Teacher in the above example) are subtypes
of the type of the parent table (Person in the above example). As a result, every
attribute present in the table people is also present in the sub tables students and
teachers.

Array and Multiset Types in SQL

SQL supports two collection types: arrays and multi sets

A multi set is an unordered collection, where an element may occur multiple times.

Multi sets are like sets, except that a set allows each element to occur at most once.

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; unlike elements in a multi set, the elements of an array are ordered, so we can
distinguish the first author from the second author, and so on.

The following example, illustrates how these array and multi set-valued attributes can
be defined in SQL:

create type Publisher as

(name varchar(20),

branch varchar(20));

create type Book as

(title varchar(20),

Autho_arrray varchar(20) array [10],

 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

Pub_date date, publisher Publisher, keyword_set varchar(20) multiset);

create table books of Book;

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 multi set of keywords.

Finally, a table books containing tuples of type Book is created.

Object-Identity and Reference 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:

create type Department (

name varchar(20),

head ref(Person) scope people);

create table departments of Department;

Here, the reference is restricted to tuples of the table people. The restriction of the
scope of a reference to

tuples of a table is mandatory in SQL, and it makes references behave like foreign
keys.

Object-relational Features
 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

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.

Sub tables can be stored in an efficient manner, without replication of all inherited
fields, in one of two ways:

Each table stores the primary key (which may be inherited from a parent table) and
the attributes that are defined locally.

Inherited attributes (other than the primary key) do not need to be stored, and can be
derived by means of a join with the super table, based on the primary key.

Each table stores all inherited and locally defined 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 super tables.

Access to all attributes of a tuple is faster, since a join is not required.

The ODMG· Object Model

The ODMG object model is the data model upon which the object definition
language (ODL) and object query language (OQL) are based. It is meant to provide a
standard data model for object databases, just as SQL describes a standard data model
for relational databases. It also provides a standard terminology in a field where the
same terms were sometimes used to describe different concepts.

Objects and Literals

Objects and literals are the basic building blocks of the object model. The main
difference between the two is that an object has both an object identifier and a state
(or current value), whereas a literal has a value (state) but no object identifier. In
either case, the value can have a complex structure.
 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

The object state can change over time by modifying the object value. A literal is
basically a constant value, possibly having a complex structure, but it does not change.

An object has five aspects: identifier, name, lifetime, structure, and creation.

1. The object identifier is a unique system-wide identifier (or Object_id). Every

object must have an object identifier.

2. Some objects may optionally be given a unique name within a particular ODMS—
this name can be used to locate the object, and the system should return the object
given that name.

Obviously, not all individual objects will have unique names.

Typically, a few objects, mainly those that hold collections of objects of a

particular object type—such as extents—will have a name. These names 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. Other important objects in the
application may also have unique names, and it is possible to give more than one
name to an object.

All names within a particular ODMS must be unique.

3. The lifetime of an object specifies whether it is a persistent object (that is, a

database object) or transient object (that is, an object in an executing pro-gram that
disappears after the program terminates).

Lifetimes are independent of types—that is, some objects of a particular type may be
transient whereas others may be persistent.

4. The structure of an object specifies how the object is constructed by using the type
constructors. The structure specifies whether an object is atomic or not. An atomic
 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

object refers to a single object that follows a user-defined type, such as Employee or
Department. If an object is not atomic, then it will be composed of

other objects.

For example, a collection object is not an atomic object, since its state will be a
collection of other objects. In the ODMG model, an atomic object is any individual
user-defined object. All values of the basic built-in data types are considered to be
literals.

5. Object creation refers to the manner in which an object can be created. This is
typically accomplished via an operation new for a special Object_Factory interface.

In the object model, a literal is a value that does not have an object identifier.
However, the value may have a simple or complex structure.

There are three types of literals: atomic, structured, and collection.

1. Atomic literals

correspond to the values of basic data types and are predefined.

The basic data types of the object model include long, short, and unsigned integer
numbers (these are specified by the keywords long, short, unsigned long, and
unsigned short in ODL), regular and double precision floating point numbers (float,
double), Boolean values (boolean), single characters (char), character strings (string),
and enumeration types (enum), among others.

2. Structured literals correspond roughly to values that are constructed using the
tuple constructor. The built-in structured lit-erals include Date, Interval,Time, and
Timestamp.

3. Collection literals specify a literal value that is a collection of objects or values but
the collection itself does not have an Object_id. The collections in the object model
can be defined by the type generators set<T>,bag<T>, list<T>, and array<T>, where T
is the type of objects or values in the collection.28 Another
 CS8492

DATABASE MANAGEMENT SYSTEMS

(Common to CSE & IT)

collection type is dictionary<K, V>, which is a collection of associations <K, V>,

where each K is a key (a unique search value) associated with a value V; this can be
used to create an index on a collection of values V.

The notation of ODMG uses three concepts: interface, literal, and class. Following
the ODMG terminology, we use the word behavior to refer to operations and state to
refer to properties (attributes and relationships).

An interface specifies only behavior of an object type and is typically non

instantiable (that is, no objects are created corresponding to an interface). Although an
interface may have state properties (attributes and relationships) as part of its
specifications, these cannot be inherited from the interface. Hence, an interface serves
to define operations that can be inherited by other interfaces, as well as by classes that
define the user-defined objects for a particular application.

A class specifies both state (attributes) and behavior (operations) of an object type,
and is instantiable. Hence, database and application objects are typically created based
on the user-specified class declarations that form a database schema.

Finally, a literal declaration specifies state but no behavior. Thus, a literal instance
holds a simple or complex structured value but has neither an object identifier nor
encapsulated operations.