Chapter 9: Object Based Databases
Session 18 (contd)
Object- Based Databases-Introduction
Developed data model based on object oriented approach
to overcome the restrictions posed by the relational model.
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 to types.
Object oriented database supports direct access to data
from object oriented programming languages, without the need for a relational query language as the database interface.
Database System Concepts
8.2
Silberschatz, Korth and Sudarshan
Why we go for Object Oriented database?
Limited type system in relational model. Complex applications require complex data types such
as nested record types, multivalued attributes and inheritance which are supported by traditional programming languages.
providing a richer type system.
Object relational data model extends relational model by
Second difficulty was accessing database data from
programming languages such as C++ or Java. many applications
Direct access to data without SQL interface needed by Differences between the type system of database and the
type system of programming language make data storage and retrieval complicated.
Database System Concepts
8.3
Silberschatz, Korth and Sudarshan
Object Oriented Database System
The term object oriented database system
is used to refer to database systems that support an object oriented type system and allow direct access to data from an object oriented programming language using the native type system of the language.
Database System Concepts
8.4
Silberschatz, Korth and Sudarshan
Complex Data Types
Example: library information system
Each book has
title, a set of authors,
Publisher, and
a set of keywords
Non-1NF relation books
Database System Concepts
8.5
Silberschatz, Korth and Sudarshan
1NF Version of Relation book
1NF version of books
flat-books
Database System Concepts
8.6
Silberschatz, Korth and Sudarshan
4NF Decomposition of Nested Relation
Decompose into 4NF using the schemas:
(title, author) (title, keyword) (title, pub-name, pub-branch)
Database System Concepts
8.7
Silberschatz, Korth and Sudarshan
4NF Decomposition of flatbooks
Database System Concepts
8.8
Silberschatz, Korth and Sudarshan
Problems with 4NF Schema
4NF design requires users to include joins in their
queries.
1NF relational view flat-books defined by join of 4NF
relations:
eliminates the need for users to perform joins, but loses the one-to-one correspondence between tuples and documents. And has a large amount of redundancy
Database System Concepts
8.9
Silberschatz, Korth and Sudarshan
Structured and Collection Types
Structured types allow composite
attributes of E-R diagrams to be represented directly.
Similarly, collection types allow
multivalued attributes of E-R diagrams to be represented directly.
Database System Concepts
8.10
Silberschatz, Korth and Sudarshan
Structured and Collection Types
Structured types can be declared and used in SQL
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 setof(varchar(20)))
Note: setof declaration of keyword-set is not supported by SQL:1999 Using an array to store authors lets us record the order of the authors
Structured types can be used to create tables
create table books of Book
Database System Concepts 8.11 Silberschatz, Korth and Sudarshan
Structured types- Customer table creation
Create type
Name as
(firstname varchar(20),Lastname varchar (20))
final
Create type as
Address
(street varchar(20), not final
city varchar (20), zipcode varchar (9)))
Database System Concepts
8.12
Silberschatz, Korth and Sudarshan
Table creation using user defined types
Create table
customer ( name Name, address Address, dateOfBirth date)
The componeents of a composite attribute can be accessed
using a dot .
eg.
name.firstname
Database System Concepts
8.13
Silberschatz, Korth and Sudarshan
Create a table of user defined type
Create type
CustomerType as (
name Name,
address Address, dateOfBirth date)
not final
Create table
customer of CustomerType
Database System Concepts
8.14
Silberschatz, Korth and Sudarshan
Table creation using row type
Create table
customer_r( name row( firstname varchar(20),
lastname varchar(20)), address row (street varchar(20), city varchar(20), zipcode varchar(9)), dateOfBirth date)
select
name. lastname , address. city from customer
Database System Concepts
8.15
Silberschatz, Korth and Sudarshan
Defining methods on a structured type
Create type
CustomerType as (
name Name,
address Address, dateOfBirth date)
not final
method
ageOnDate(OnDate date)
returns interval year
Database System Concepts
8.16
Silberschatz, Korth and Sudarshan
Creating the method
Create instance method returns interval year for
ageOnDate(OnDate date)
CustomerType
return
begin
OnDate self. dateOfBirth;
end
Invoking the method
select
name.lastname, ageOnDate(current_date)
from
customer
Database System Concepts
8.17
Silberschatz, Korth and Sudarshan
Creating constructor function for name
Create function returns begin set self.firstname =firstname; set self. end
To create a value for the name
Name(firstname varchar(20),lastname varchar(20))
Name
lastname = lastname;
new
Name(John,Smith)
Database System Concepts
8.18
Silberschatz, Korth and Sudarshan
Inserting a tuple into customer
insert into Customer values(new new
Name(John,Smith), Address(20 Main St,New York,11001), )
date 1960-8-22
Database System Concepts
8.19
Silberschatz, Korth and Sudarshan
Large Object Types
Large object types
clob: Character large objects
book-review clob(10KB)
blob: binary large objects
image movie
blob(10MB) blob (2GB)
JDBC/ODBC provide special methods to access large
objects in small pieces
Similar to accessing operating system files Application retrieves a locator for the large object and then manipulates the large object from the host language
Database System Concepts
8.20
Silberschatz, Korth and Sudarshan
Type Inheritance
Create type
Person
(name varchar(20),
address varchar(20))
Create type
Student
under
Person
(degree varchar(20),
department varchar(20))
Create type
Teacher
under
Person
(salary integer,
department varchar(20))
Database System Concepts 8.21 Silberschatz, Korth and Sudarshan
Multiple Inheritance
SQL:1999 does 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
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)
Database System Concepts
8.22
Silberschatz, Korth and Sudarshan
Table Inheritance
Table inheritance allows an object to have multiple types by
allowing an entity to exist in more than one table at once. E.g. people table: create table people of Person We can then define the students and teachers tables as subtables of people create table students of Student under people create table teachers of Teacher under people Each tuple in a subtable (e.g. students and teachers) is implicitly present in its supertables (e.g. people) Multiple inheritance is possible with tables, just as it is possible with types. create table teaching-assistants of Teaching Assistant under students, teachers
Multiple inheritance not supported in SQL:1999
Database System Concepts
8.23
Silberschatz, Korth and Sudarshan
Table Inheritance: Roles
Table inheritance is useful for modeling roles permits a value to have multiple types, without having a
most-specific type (unlike type inheritance).
e.g., an object can be in the students and teachers subtables simultaneously, without having to be in a subtable student-teachers that is under both students and teachers object can gain/lose roles: corresponds to inserting/deleting object from a subtable
NOTE: SQL:1999 requires values to have a most specific
type
so above discussion is not applicable to SQL:1999
Database System Concepts
8.24
Silberschatz, Korth and Sudarshan
Table Inheritance: Consistency Requirements
Consistency requirements on subtables and supertables.
Each tuple of the supertable (e.g. people) can correspond to at most one tuple in each of the subtables (e.g. students and teachers) Additional constraint in SQL:1999:
All tuples corresponding to each other (that is, with the same values for inherited attributes) must be derived from one tuple (inserted into one table).
That is, each entity must have a most specific type
We cannot have a tuple in
people corresponding to a tuple each in students and teachers
Database System Concepts
8.25
Silberschatz, Korth and Sudarshan
Table Inheritance: Storage Alternatives
Storage alternatives
1. Store only local attributes and the primary key of the supertable in subtable
Inherited attributes derived by means of a join with
the supertable
2. Each table stores all inherited and locally defined attributes
Supertables implicitly contain (inherited attributes
of) all tuples in their subtables required
Access to all attributes of a tuple is faster: no join
If entities must have most specific type, tuple is
stored only in one table, where it was created Otherwise, there could be redundancy
Database System Concepts
8.26
Silberschatz, Korth and Sudarshan
Reference Types
Object-oriented languages provide the ability to create and
refer to objects.
In SQL:1999
References are to tuples, and References must be scoped,
I.e., can only point to tuples in one specified table
We will study how to define references first, and later see how
to use references
Database System Concepts
8.27
Silberschatz, Korth and Sudarshan
Reference Declaration in SQL:1999
E.g. 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)
Database System Concepts
8.28
Silberschatz, Korth and Sudarshan
Initializing Reference Typed Values
In Oracle, to create a tuple with a reference value, we can
first create the tuple with a null reference and then set the reference separately by using the function ref(p) applied to a tuple variable person named John, we use insert into departments values (`CS, null) update departments set head = (select ref(p) from people as p where name=`John) where name = `CS
E.g. to create a department with name CS and head being the
Database System Concepts
8.29
Silberschatz, Korth and Sudarshan
Initializing Reference Typed Values (Cont.)
SQL:1999 does not support the ref() function, and instead
requires a special attribute to be declared to store the object identifier clause to the create table statement: create table people of Person ref is person_id system generated
The self-referential attribute is declared by adding a ref is
Here, person_id is an attribute name, not a keyword.
To get the reference to a tuple, the subquery shown earlier
would use
select p.person_id instead of insert into departments values (`CS, null) update departments set head = (select p.person_id from people as p where name=`John) where name = `CS
8.30
select ref(p)
Database System Concepts
Silberschatz, Korth and Sudarshan
User Generated Identifiers
SQL:1999 allows object identifiers to be user-generated
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 E.g. create type Person (name varchar(20) address varchar(20)) ref using varchar(20) create table people of Person ref is person_id user generated
When creating a tuple, we must provide a unique value for
the identifier (assumed to be the first attribute): insert into people values (01284567, John, `23 Coyote Run)
Database System Concepts
8.31
Silberschatz, Korth and Sudarshan
User Generated Identifiers (Cont.)
We can then use the identifier value when inserting a
tuple into departments Avoids need for a separate query to retrieve the identifier: E.g. insert into departments values(`CS, `02184567) It is even possible to use an existing primary key value as the identifier, by including the ref from clause, and declaring the reference to be derived 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)
Database System Concepts 8.32 Silberschatz, Korth and Sudarshan
Path Expressions
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
Database System Concepts
8.33
Silberschatz, Korth and Sudarshan
Querying with Structured Types
Find the title and the name of the publisher of each book.
select title, publisher.name from books
Note the use of the dot notation to access fields of the composite attribute (structured type) publisher
Database System Concepts
8.34
Silberschatz, Korth and Sudarshan
Collection-Value Attributes
Collection-valued attributes can be treated much like
relations, using the keyword unnest The books relation has array-valued attribute authorarray and set-valued attribute keyword-set To find all books that have the word database as one of their keywords, select title from books where database in (unnest(keyword-set)) Note: Above syntax is valid in SQL:1999, but the only collection type supported by SQL:1999 is the array type To get a relation containing pairs of the form title, authorname for each book and each author of the book select B.title, A from books as B, unnest (B.author-array) as A
Database System Concepts
8.35
Silberschatz, Korth and Sudarshan
Collection Valued Attributes (Cont.)
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
Database System Concepts
8.36
Silberschatz, Korth and Sudarshan
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 as keyword from books as B, unnest(B.author-array) as A, unnest (B.keyword-list) as K
Database System Concepts
8.37
Silberschatz, Korth and Sudarshan
Nesting
Nesting is the opposite of unnesting, creating a collection-
valued attribute NOTE: SQL:1999 does not support nesting
Nesting can be done in a manner similar to aggregation, but
using the function set() in place of an aggregation operation, to create a set To nest the flat-books relation on the attribute keyword: select title, author, Publisher(pub_name, pub_branch) as publisher, collect(keyword) as keyword-list from flat-books groupby title, author, publisher To nest on both authors and keywords: select title,collect(author) as author-list, Publisher(pub_name, pub_branch) as publisher, collect (keyword) as keyword-list from flat-books groupby title, publisher
Database System Concepts 8.38
Silberschatz, Korth and Sudarshan
Nesting (Cont.)
Another approach to creating nested relations is to use
subqueries in the select clause. select title, ( select author from flat-books as M where M.title=O.title) as author-set, Publisher(pub-name, pub-branch) as publisher, (select keyword from flat-books as N where N.title = O.title) as keyword-set from flat-books as O Can use orderby clause in nested query to get an ordered collection
Database System Concepts
8.39
Silberschatz, Korth and Sudarshan
A Partially Nested Version of the flat-books Relation
Database System Concepts
8.40
Silberschatz, Korth and Sudarshan
