VNSISPL_DBMS_Concepts_ch9

Chapter 9: Object-Based Databases

Database System Concepts, 1 st Ed.
©VNS InfoSolutions Private Limited, Varanasi(UP), India 221002
See www.vnsispl.com for conditions on re-use

Chapter 9: Object-Based Databases
s Complex Data Types and Object Orientation
s Structured Data Types and Inheritance in SQL
s Table Inheritance
s Array and Multiset Types in SQL
s Object Identity and Reference Types in SQL
s Implementing O-R Features
s Persistent Programming Languages
s Comparison of Object-Oriented and Object-Relational Databases

Database System Concepts – 1 st Ed. 9.2 © VNS InfoSolutions Private Limited, Varanasi(UP), India 22100

Object-Relational Data Models
s Extend the relational data model by including object orientation and
constructs to deal with added data types.
s Allow attributes of tuples to have complex types, including non-atomic
values such as nested relations.
s Preserve relational foundations, in particular the declarative access to
data, while extending modeling power.
s Upward compatibility with existing relational languages.


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


Example of a Nested Relation
s Example: library information system
s Each book has
q title,
q a set of authors,
q Publisher, and
q a set of keywords
s Non-1NF relation books


4NF Decomposition of Nested
Relation
s Remove awkwardness of flat-books by assuming that the following
multivalued dependencies hold:
q title author
q title keyword
q title pub-name, pub-branch
s Decompose flat-doc into 4NF using the schemas:
q (title, author )
q (title, keyword )
q (title, pub-name, pub-branch )


4NF Decomposition of flat– books


Problems with 4NF Schema
s 4NF design requires users to include joins in their queries.
s 1NF relational view flat-books defined by join of 4NF relations:
q eliminates the need for users to perform joins,
q but loses the one-to-one correspondence between tuples and
documents.
q And has a large amount of redundancy
s Nested relations representation is much more natural here.


Complex Types and SQL:1999
s Extensions to SQL to support complex types include:
q Collection and large object types
 Nested relations are an example of collection types
q Structured types
 Nested record structures like composite attributes
q Inheritance
q Object orientation
 Including object identifiers and references
s Our description is mainly based on the SQL:1999 standard
q Not fully implemented in any database system currently
q But some features are present in each of the major commercial
database systems
 Read the manual of your database system to see what it
supports


Structured Types and Inheritance in
SQL
s Structured types can be declared and used in SQL
create type Name as
(firstname varchar(20),
lastname varchar(20))
final
create type Address as
(street varchar(20),
city varchar(20),
zipcode varchar(20))
not final
q Note: final and not final indicate whether subtypes can be created
s Structured types can be used to create tables with composite attributes
create table customer (
name Name,
address Address,
dateOfBirth date)
s Dot notation used to reference components: name.firstname


Structured Types (cont.)
s User-defined row types
create type CustomerType as (
name Name,
address Address,
dateOfBirth date)
not final
s Can then create a table whose rows are a user-defined type
create table customer of CustomerType


Methods
s Can add a method declaration with a structured type.
method ageOnDate (onDate date)
returns interval year
s Method body is given separately.
create instance method ageOnDate (onDate date)
returns interval year
for CustomerType
begin
return onDate - self.dateOfBirth;
end
s We can now find the age of each customer:
select name.lastname, ageOnDate (current_date)
from customer


Inheritance
s Suppose that we have the following type definition for people:
create type Person
(name varchar(20),
address varchar(20))
s 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))
s Subtypes can redefine methods by using overriding method in place of
method in the method declaration


Multiple Inheritance
s SQL:1999 and SQL:2003 do not support multiple inheritance
s If our type system supports multiple inheritance, we can define a type for
teaching assistant as follows:
create type Teaching Assistant
under Student, Teacher
s 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 )


Consistency Requirements for Subtables
s Consistency requirements on subtables and supertables.
q 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)
q 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


Array and Multiset Types in SQL
s 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 )
create table books of Book
s Similar to the nested relation books, but with array of authors
instead of set


Creation of Collection Values
s Array construction
array [‘Silberschatz’,`Korth’,`Sudarshan’]
s Multisets
q multisetset [‘computer’, ‘database’, ‘SQL’]
s To create a tuple of the type defined by the books relation:
(‘Compilers’, array[`Smith’,`Jones’],
Publisher (`McGraw-Hill’,`New York’),
multiset [`parsing’,`analysis’ ])
s To insert the preceding tuple into the relation books
insert into books
values
(‘Compilers’, array[`Smith’,`Jones’],
Publisher (`McGraw-Hill’,`New York’),
multiset [`parsing’,`analysis’ ])


Querying Collection-Valued
Attributes
s To find all books that have the word “database” as a keyword,
select title
from books
where ‘database’ in (unnest(keyword-set ))
s We can access individual elements of an array by using indices
q 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’
s 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 )
s 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 )


Unnesting
s The transformation of a nested relation into a form with fewer (or no)
relation-valued attributes us called unnesting.
s 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 )


Nesting
s Nesting is the opposite of unnesting, creating a collection-valued attribute
s NOTE: SQL:1999 does not support nesting
s Nesting can be done in a manner similar to aggregation, but using the function
colect() in place of an aggregation operation, to create a multiset
s 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
s 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


1NF Version of Nested Relation

1NF version of books

flat-books


Nesting (Cont.)
s Another approach to creating nested relations is to use subqueries in
the select clause.
select title,
array ( select author
from authors as A
where A.title = B.title
order by A.position) as author_array,
Publisher (pub-name, pub-branch) as publisher,
multiset (select keyword
from keywords as K
where K.title = B.title) as keyword_set
from books4 as B


Object-Identity and Reference Types
s 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)
s We can then create a table departments as follows
create table departments of Department
s 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)


Initializing Reference-Typed Values
s 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’)
where name = `CS’


User Generated Identifiers
s The type of the object-identifier must be specified as part of the type
definition of the referenced table, and
s The table definition must specify that the reference is user generated
create type Person
(name varchar(20)
ref using varchar(20)
create table people of Person
ref is person_id user generated
s 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’)
s We can then use the identifier value when inserting a tuple into
departments
q Avoids need for a separate query to retrieve the identifier:
values(`CS’, `02184567’)


User Generated Identifiers (Cont.)

s Can use an existing primary key value as the identifier:
create type Person
(name varchar (20) primary key,
ref from (name)
create table people of Person
ref is person_id derived
s When inserting a tuple for departments, we can then use
values(`CS’,`John’)


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


Implementing O-R Features
s Similar to how E-R features are mapped onto relation schemas
s Subtable implementation
q Each table stores primary key and those attributes defined in that
table
or,
q Each table stores both locally defined and inherited attributes


Persistent Programming Languages
s Languages extended with constructs to handle persistent data
s Programmer can manipulate persistent data directly
q no need to fetch it into memory and store it back to disk (unlike
embedded SQL)
s Persistent objects:
q by class - explicit declaration of persistence
q by creation - special syntax to create persistent objects
q by marking - make objects persistent after creation
q by reachability - object is persistent if it is declared explicitly to be
so or is reachable from a persistent object


Object Identity and Pointers
s Degrees of permanence of object identity
q Intraprocedure: only during execution of a single procedure
q Intraprogram: only during execution of a single program or query
q Interprogram: across program executions, but not if data-storage
format on disk changes
q Persistent: interprogram, plus persistent across data
reorganizations
s Persistent versions of C++ and Java have been implemented
q C++
 ODMG C++
 ObjectStore
q Java
 Java Database Objects (JDO)


Comparison of O-O and O-R
Databases

s Relational systems
q simple data types, powerful query languages, high protection.
s Persistent-programming-language-based OODBs
q complex data types, integration with programming language, high
performance.
s Object-relational systems
q complex data types, powerful query languages, high protection.
s Note: Many real systems blur these boundaries
q E.g. persistent programming language built as a wrapper on a
relational database offers first two benefits, but may have poor
performance.


End of Chapter

Database System Concepts, 1 st Ed.
©VNS InfoSolutions Private Limited, Varanasi(UP), India 221002
See www.vnsispl.com for conditions on re-use

VNSISPL_DBMS_Concepts_ch9

More Related Content

Similar to VNSISPL_DBMS_Concepts_ch9 (20)

More from sriprasoon (8)

Recently uploaded (20)

VNSISPL_DBMS_Concepts_ch9