C H A PTE R 9

Obect-Based Databases

Traditional database applications consist of

and payroll management, with relatively data-processing tasks, such as
simple data types, whích are wellbanking
tothe relational data model. As
database systems were applied to a wider rangesuited
applications, such as computer-aided design and geographical of
limitations imposed by the relational model emerged as an information systems,
the introduction of object-based obstacle. The solution was
databases, which allow one to deal with complex
data types.

9.1 Overview
The first obstacie faced by programmers using the relational data
ited type systen1 supported by the relational model. Complex model was the lim
require correspondingly complex data types, such as nested recordapplication domains
valued attrabutes and inheritance, which are supported by structures, multi
languages. uch features are in fact supported in the E-Rtraditional programming
and extended E-R nota
tions, buthad to be translated to simpler SQL data types. The object-relational data
modelexte:is the relational data model by providing a richer tvpe system including
Complex data tvpes and object orientation. Relational query languages, in particu
lar QL, neec to be correspondingly extended to deal with the richer tvpe svstem.
Such extensions attempt to preserve the relational foundations-in particular, the
declarativeaccess to data-while extending the modeling power. Object-relational
database systems, that is, database systems based on the object-relation model, pro
Vide a
Convenient migration path for users of relational databases who wish to use
object-oriented features.
Ihe second obstacle was the difficulty in accessing database data from programs
written in programming languages such as Ct+ or Java. Merely extending the tvpe
yStem supported by the database was not enough to solve this problem completely.
361
362
Chapter o Object-Based Databases

Differences between the type system of the database and the type system of the po.
gramming language make data storage and retrieval more complicated and need to
be minimized. Having to express database access using a language (SQL) which is
language again makes the job of the
harder. Ittrom
irterent the programming programmer
is desirable, for many applications, to have programming language on-
structs or extensions that permit direct access to datain the database. without having

an intermediate language such as SQL.

Thethrough
to go term persistent programming languages refers to extensions of existing pro-
and other database features,
using the
languages to add persistence *.
gramming
system of the programming language. The tern object-oriented database svsto
type that support an object-oriented type
tems is used to refer to database systemsobject-oriented programming language usino
and allow direct access to data from an
the native type system of the language. motivation for the development of complaw
explain the
In this chapter, we first object-relational database systems; our coverage is bàsed
data types. We then study added to the SQL:1999 version of the SQL
standard
on the object-relational extensions
Our description is based on the SQL Notestandard, specifically using features that were
introduced in SQL:1999 and SQL:2003. that most database products support only
the database
a subset of the SQL features
described here. Refer to the user manual of
it supports.
system you use to find out what features that add persistence sup
We then briefly study object-oriented database systems outline situations in which
Finally, we
port to object-oriented programming languages. object-oriented approach, and vice
the object-relational approach is better than the them.
between
versa, and mention criteria for choosing

9.2 Complex Data Types

Traditional database appiications consist of data-processing tasks, such as banking
and payroll management. Such applications have conceptually simple data types.
The basic data items are records that are fairly small and whose fields are atomic
that is, they are not further structured, and first normal form holds (see Chapter /.
Further, there are only a few record types.
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
atomic data item of type string, this view would hide details such as theOnstree
theother
dress, city, state, and postal code, which could be of interest to queries. (streetad-
hand, if an address were represented by breaking it into the components
complicatedsince
dress, city, state, and postal code), writing queries would be more structured data
they would have to mention each field. Abetter alternative is to allow and yostal
types, which allow a type address with subparts street address, city, state,
code.
Such
As another example, consider multivalued attributes from the E-R model.pepl
attributes are natural, tor example, for representing phone numbers, since nen
may have morethan one phone. The alternative of normalization by creating a
relation expensive and artificial for this example.
is
 Compley Data IvyeN 363

tvpe svstems
Ith omper multivalued we can teptesent ER model
',attrilutes, Iattributes, generalization, and
convepts, such as com
translationto the relational
hater7, we detined first normal torm model.
speialization dinlv.
ln domins, Recall that a (INE), which eyuires that all
ito be indivisible units. domain is atoic it
elements ot the domain attributes
are
The assumption ot INF is a natural one in the bank
Howeve, t ot all applications are best modeled by INEexamples we have considered.
than
eH'.adatabase asaset ot records, users ot relations.
certain applicationsorexample, rather
obts
(orentities). These objects
mv requite several records tor view it as a setot
simple. caSV-t0-Use intertace a their
requires one-to-one Orrespondenervpresentation.
A
LUSCT'S intuitive notion of an object and the database betwen the
Consider, tor example, a librarv svstem's otion ot a data item.
tollowing intormation tor each book: application, and suppose we wish to stoe the
" Book title

" List ot authors

" Publisher

" Set of kevwords

Ile can see that, if we detine arelation for the

will be nonatomic.
preceding intormation, severaldomains
" Authors. A book mav have a list of
array. Nevertheless, we may want to authors, which We can represent as an
find all books of which Jones was one
of the authors. Thus, we are
"authors.
interested in a subpart of the domain element
" Keywords. f we store a set of kevwords for a book, we
retrieve ail' iwhose kevwords include one or more expect to be able to
Thus, weLhe domain of the set ot kevwords as specitied kevwords.
nonatomic.
" Publisher
iyvOords and authors, publisher does not have a set-valued
domain. i: T, We may view publislher as consisting of the subtields nme
and brane View makes the domain of publisher nonatomic.
Figure 9.1 sho e\ample relation, books.

title ublislher
auiliorarray (name, branci)
keyword_set
Compilers Snith, Jonesl (McGraw-Hill, NewYork) parsing, analvsis)
Networks |lones, Frick] (Oxford, Londom) {lnternet, Web}

Figure 9.1 Non-1NF books relation, books.

364
Chapter 9 Object-Based Databases

title author position

Compilers Smith
Compilers Jones 2
1
Networks Jones
Networks Frick
autlhors

title keyword
Compilers parsing
Compilers analysis
Networks Internet
Networks Web
keywords
fitle pub_name pub_branch
Compilers McGraw-Hill New York
Networks Oxford London
books4

books.
Figure 9.2 4NF version of the relation

simplicity we assume that the title of a book uniquely identifies the book'We
For
using the following schema:
can then represernt the same information
21tlhors(title, author position)
s keyerdsltile, keyvord)

normalized representation ot
ite ac:he saiies 4NE. iigure 9.2 shows the

e t e trak rtntabase can be adequately expressed without ustis

Athos' easier-to-understand mode.
ä s , Ci nesti relations leads to an
sted O
The iyit2l isc: rraraaer of an information-retrieval system thinks
design o
databas terns of books having sets of authors, as the non-1NF
relation, whereas the non-IN
The 4NF design requires queries to join multiple
Sign makes many types of queries easier. representation
first normal form
On the other hand, it may be better to use a
the depositorrela-
instead of collections in other situations. For instance, consider CUstomers
between
tionship in our bank example. The relationship is many-to-many each Customer, ora
and acounts. We could conceivably store a set of accounts with would have data
set of Customers with each account, or botlh. If we store both, we W
10-digitISEN
a
This assumption does not hold in the real world. Books are usually identified by
number that uniquely identifies each published book.
 9.3 Structured Types and Inheritance in SQL 365

rdundancy(the relationship of a particular customer to a particular account would

bestoredtwice),
The
abilityto use complex data types such as sets and arrays can be useful in many
applications but should be used with care.

9.3 Structured|Types and Inheritance in SQL

BeforeSQL:1999, the SQL type system consisted of a fairly simple set of predefined
types.SQL:11999 added an extensive type system to SQL, allowing structured types
and type inheritance.

9.3.1 Structured Types

Structured types allow composite attributes of E-R diagrams to be represented di-
rectly. For instance, we can define the following structured type to represent a com-
nsite attribute name with component attribute firstname and lastname:

create type Name as

(firstname varchar(20),
lastname varchar(20)
final

Similarly, the following structured type can be used to represent a composite attribute
address:

create type Address as

(street varchar(20),
city varchar(20)
zipcode varchar(9))
not final

Such types are called user-defined types in SQL. The above definition corresponds
tothe E-R diagrar: in Figure 6.4. The final and not final specifications are related to
subtyping,whi: iie describe later, in Section9.3.2.2
We can now ethese types to create composite attributes in a relation, by simply
declaring an aibute to be of oneof these types. For example, we could create a table
Customer as fo
create table customer (
name Name,
address Address,
dateOfBirth date)
2. The
final final specification for Name indicates that we cannot create subtypes for name, whereas the not
specification
for Address indicates that we can create subtypes of address.
366 Chapter 9 Object-Based Databases

attribute can be accessed using a "dor

of a composite
for The components
instance ane. frstnanie
notation,
returns the firstname component of the name attributa
avalue of the
structured
type Nane.
An access to attribute nane would return
We can also create a table whose rows are of a user-defined type. For example, w
as
CustomerType and createthe table customer follows:
could define atype
CustomerTiype as (
create type
name Name,
address Address,
dateOfBirth date)
not final
of CustomerType
create table customer

defining composite attributes in SQL is to use unnamed

of b
An alternative way representing customer intormation could have
relation
types. For instance, the follows:
created using row types as
create table custoner_r(
varchar(20),
name row (firstname
lastname varchar(20)
address row (street varchar(20),
city varchar(20)
zipcode varchar(9),
dateOfBirth date)
except that the at
definition is equivalent to the preceding table definition, the table also have
This types, and the rowws of
::le and address have unnamed
tribuies
arn r e d fvpe.
access component attributes of acomposite
T c e h qusr histrates how to city of each customer.
ali at incs he last name and
select name.lastname, address.city
iON CuStomer
methods as part o
tve znetihods defined on it. We declare
istteoyietured type:
Create type CustomerType as (
11ame Name,
address Address,
dateOfBirth date)
not final
method ageOnDate(onDate date)
returns interval year

We create the method body separately:

 9.3 Structured Types and Inheritance in SQL 367

create instance method ageOnDate (onDate date)

returns interval year
for CustomerType
begin
return onDate - self.dateOfBirth;
end

Notethat the for clause indicates which type this method is for, while the keyword
instance indicates that this method executes on an instance of the Customer type.
self refers to the Customer instance on which the method is invoked.
The variable
of the method can contain procedural statements, which we saw earlier
The body
in Section
4.6. Methods can update the attributes of the instance on which they are
executed.
Methods can be invoked on instances of a type. If we had created atable customer
ftne CustomerType,we can invoke the method ageOnDate() as illustrated below, to
customer.
find the age of each
select name.lastname, ageOnDate(current date)
from customer

In SOL:1999 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. For instance, we could declare a constructor for the type Name like
this:

Create function Name (firstname varchar(20), lastname varchar(20))

returns Name
begin
set self.firstname = firstname;
set self.lastname = lastname;
end

We can then use new Name('John','Smith') to create a valueof the type Name.
We can consiia row value by listing its attributes within parentheses. For in
stance, if we de : an attribute nane as a row type with components firstnane and
lastname we car ruct this value for it:

("Ted', 'Codd')

without using ac Tstructor.

Dy default every siructured type has a constructor with no arguments, which sets
eattributes to their default values. Any other constructors have to be created explic
itly. There can be more than one constructor for the same structured type; although
they have the same name, they must be distinguishable bythe number of arguments
and types of their
arguments.illustrates how we can create anew tuple in the Custoer
The following statement
relation. We assume that aconstructor has been defined for Address, just like the con-
Structor we defined for Name.
Chapter 9 Object-Based Databases

insert into Customer

values
(new NameC]ohn', 'Smith),
Main St','New York', '11001),
new Address("20
date 1960-8-22)

9.3.2 Type Inheritance

we have the following type definition tor people:
Suppose that
create type Person
(name varchar(20),
address varchar(20))
as
information in the database about people who
extra are also nes
We mav want to store who are teachers. Since students and teachers SOL:
dents, and about people to define the student and teacher types in
inheritance
ple, we can use
create type Student
under Person
(degree varchar(20),
departent varchar(20)
create type Teacher
under Person
(salary intcger,
te prarlment varchar(20))

atlribules of Person-namely, name and address.

irinierit the supertype
PersOn, and Person is a
d to te suhtyes of
attributes are.
etvg statiidiy its subtypes, just as
i clrt a method by declaring the method
oit i method declaration.
og.,'ovrtdeg method iee sofrethod in the definition,
i ra fieti at the end of the type
The lasheil ilso requires subtypes y
Ti:e kevword final says that
whoc ooe is tlar final or not final.
that subtypes may be created.
not final says who
not be reated Iro]11 the zive type, wlileintormaion about teaching assistants, wMe
Nov sippose that we Want lo store departments.
perhaps even in different eisde-
are simultareously studenls and teahers, where a type
SQ::19w
inheritance,
could dro this if the type system supports multiple standard (up tothe tutur'
lared as asubtypr of multiple types. Note that the SQL
multipleinheritance, although
and . 2003 versions at Jeast) does not support
Versions of the 4)1. standard may support it. detined
Can
Ior instante, if our typ system supports multiple inheritance,
we
type for teathing asstant as follows:

create type TihingAssistant

under Student, Tacher
 9.4 Table Inheritance 369

Iwould inherit all the attributes of Student and Teacher. There is a

hwe:sinethe attributes name, address, and departnent are present in
lasinlicher.
address are actually inherited from a commnon source, Per
hntsttoOntlict caused by inheriting them from Student as well as Teacher.
eattribute department is defined separately in Student and Teacher. In fact,
mav be a student of one department and a teacher in another
between the two oCcurrences of department, we can
using an as clause, as in this definition of the type
TeachingAssistant:
ereate type liachingAssistant
under Student with (dezart1ment as studentdept),
Tcer with (department as teacierdept)
h N asain that SQL suPports only single inheritance-that is, a type can in
asingle type: the syntax used is as in our earlier examples. Multiple
tatNw as in the liahingAssistant example is not supported in SQL.
as in most other laguages, a value of astructured tvpe must have exactly
Swiir Vpe That is, each value must be associated with one specific
X Rll its most-specitfie type, when it is created. By means of inheritance, it
t Niatertwith whot the supertypes of its most-specific type. For example,
KYNthat at entitr has the tvpe Person, as well as the tvpe Student. Then, the most
SIH Ne ot the ntitr is Student, since Student is a subtype of Person. However,
at entv canlOt hve the pe $tudent as well as the tvpe Teacer unless it has a type,
Natas Taaing Assst.:nt. that is a subtvpe of Teacher, as well as of Student (which is
tANhle in sQl sive ultiple inheritance is not supported by SQL).

9.4 Table Inberitance

Niratles
s in n d to the F-R notion ot specialization/generalization. For
inee the :pe table as tollows:
create table vrle of Person

ttthen det"s sthaietsand toaclers as subtables of people, asfollows:

ereate table stuuients of Student
under pple
create table teachers of Teacher
under pple
Thetps ot the subtables must esubtvpes of the tvpe of the parent table. Thereby,
er
attnbutewhenPRent in ;wple is also present inthe subtables.
present in stuietts or teachersstudents
Further. Ne drlare becomesandalso
techers as subtables
implicitly present ofinpeople,
people.everv
Thus,tuple
if a
370 Object-Based Databases
Chapter 9

query usesthe table people, it will tind not onlytuples directly inserted into that llb
students and
into its subtables, namely techers.
but also
thOse
OnlySQL
tuples
permits
inserted
tindare
us tothat
attributes present in eole can be accessed by thatat query.
tuples that are in pvple but not in its subtables by ising
"only people" in place of people in a query. The only keyword can also be Usel in
tlowever,
delete,
update statements. Without the only keyword, a statement
pertable,
delete andsuch as pople, also deletes tuples that were originally inserted in subtabley
statement
(such as students); for example, a
P
delete from people where
well as its subtables students
delete all tuples from the table people, as to the above
Would only keyword is added statement,
whero tuples
teachers,that satisfy P. If the affected, even if they satisfy the
subtables are not these bm
that were inserted in supertable would continue to find
conditions. Subsequent queries on the wi
multiple inheritance is possible with tables, just as it is possible
Conceptually, table of type
TenchingAssistant:
create a
tvpes. For example, we can
create table tenchingassistants
of TncingAssistant
under students, eachers

present in the teaching assistants table i

declaration, every tuple turn in the
result of the teaclers and in the st1udents table, and in
mplicitly present in the supported by
muliple inheritance of tables is not
able. We note, however, that
we state the con
consisteny requirernents for subtables. Before
re are some correspond to tuples
we need a defition: Wesiv iha kuies in asubtable Thus, corre
it,
ihe 'avethoiues for allinherited attributes.
rCnt table i
dig iuples represrii tt:
cnistency r e q u i r e e i 2s are:
he
in each ofits
rOGnd to at most one tuple
1. Eacii tupie of the superiaiie
immediate subtabBos.
each
all the tuples
corresponding to
2. SQL has an additional constraint hat
into one table).
other must be derived from one tuple (inserted
studts(or
in
tuples
For example, without the first condition, we could have two
teachers) that correspond to the same person. bothatuplein
to because
The second condition rules out atuple in people corresponding presenttnchers
students and atuple in teachers, unless all these tuples are implicitly
subtable of
both
a tuple was inserted in atable teaching assistants, which is a actually
and students.
condition
Since SQL does not support multiple inheritance, the second nmultipleinheri
prevents a person from being both a teacher and a student. Even if
 9.5 Array and Multiset Types in SQL 371

supported, the same problem would arise if the subtable teachingAssistants

alsent. Obviously it would be useful to model a situation where a person can be
teacher.and a student, even a common
IN
if subtable teaching assistants is not present.
a be 1seful to remove the second
consistency constraint. Doing so Would
Thus, it can
allowanobject to have multiple types, without requiring it to have a most-specific
tvpe.
For.example, suppose we again have the type Person, with subtypes Student and
liahr, and the corresponding table people, with subtables teachers and students. We
Ganthen have a tuple in teachers and a tuple in students corresponding to the same
tupleiin poplke. There is no need to have a type TeachingAssistant that is a subtype of
both Student and Teacher. We need not create atype TeachingAssistant unless we wish
to store extra attributes or redefine methods in a manner specific to people who are
both students and teachers.
We note, however, that SQL unfortunately prohibits such a situation, because of
pansistency requirement 2.Since SQL also does not support multiple inheritance, we
cannot use inheritance to model a situation where a person can be both a student
and a teacher. As a result, SQL subtables cannot be used to represent overlapping
specializations from the E-R model.
We can of course create separate tables to represent the overlapping specializa
tions/generalizations without using inheritance. The process was described earlier,
inSection 6.9.5. In the above example, we would create tables people, students, and
toaclers, with the students and teachers tables containing the primary-key attribute of
Persouand other attributes specific to Student and Teacher, respectively. The people ta
ble would contain information about all persons, including students and teachers.
IWe would then have to add appropriate referential-integrity constraints to ensure
that students and teachers are also represented in the people table.
In other words, we can create our own improved implementation of the subtable
mechanism using existing features of sQL, with some extra effort in defining the table,
as wellas some extra effort at query time to specify joins to access required attributes.
lo end the seion, we note that SQL defines a new privilege called under, which
IS required in oroer tocreate a subtype or subtable under another type or table.The
motivation for trivilege is similar to that for the references privilege.

9.5 Array nd Multiset Types in SQL

Supports t. oliection types: arrays and multisets; array types were added in
SQL: :1999, while utiset types were added in SQL:2003. Recall that a multiset is an
unordered colleciin, where an element may occur Multiple times. Multisets are like
sets, except that aset allows each element to occur at most once.
forPpOse we wish torecord information about books, including a set of keywords
each book. Suppose also that we wished to store the names of authors of a book
as an array;
we can unlike elements in a multiset, the elements of an array are ordered, so
example
SQL.
distinguish
illustrates
the first author from the second author, and so on. The
how these array and multiset-valued attributes can be following
defined in
372 Chapter Objet-ased Datalvases

create type Pubislher as

(name varchar(2),
branchvarchar(20))
create type Book as
(title varchar(20),
array |10],
authorarrau varchar(20)
pubdate date,
publisher Publisher,
kevordset varchar(20) multiset)
of Book
create table books
components:a nam.
detines atype called Publisher, which has twO contaim
The tirst statement statenent detines a structured type BoOk, which
and a tranch. The seond array of up to 10 author names, apublicabos
which is an Finally, a table w
a titke, an authorarrau, and a multiset of keywords.
Publisher),
date, apublisher (of tvpe Book is created. authos
cOntaining tuples of tvpe arrav, instead of a multiset, tostore the namesof beliee
Note that we isd an we
authors generally has some signiticance, whereas
since the odering of
kevwords associated with a book is not significant. multist.
that the ordering ot
attributes trom an E-R schema can be mapped to
ln general multivalued ordering is important, SQL arrays can be used instead of
ralued attrilutes in sQL; it
ultise'ts.

Creating and Accessing Collection Values

95.1 this Wav: SOL:1000 in
alites cn be crated in

r v Silbershil Korth', Sudarshan']

NelICSdeOnstcted as tollows
s

niseilvompu:, datalase','SQLI
books relation as:
Tius. w'cal ceale anple o! he Ve deined bv the
Publisler('McGraw-HilI,'New York
(Compilers arravi Smith'. ]ones1, new multisetl'parsing', 'analysis')
constructor
a
Here we have created a value tor the attribute Publisher by invoking for Pul-
function for Publisler with. appoiate arguments. Note that this constructor
declaredjust
Iisher must be explicitlv created, and is not present by default; it can be
like the constructor for NaC, whichwe saw earlier in Section 9.3.
It we want to insert the preceding tuple into the relation books. we could exe
the statement
 9,5 Array and Multiset Types in SQL 373

insert into books

values
(Compilers', arrayl'Smith', lones'],
new Publisher('McGraw-Hill,New York'),
multiset|'parsing', 'analysis )
update elements of an array by specifying the array index, for
arraul L.
(hampeauthor
9.5.2 Querying Collection-Valued Attributes
consider how to handle collection-valued attributes in queries. An expres-
Ile now
evaluating to a collection can appear anywhere that a relation name may appear,
nhas in a from clause, as the following paragraphs illustrate.We use the table books
earlier.
thatltwewedetined
want to find all books that have the word database as one of their key-
wonds, we can use this query:
select title
from books
where 'database' in (unnest(keyuord set))
Note that we have used unnest(keyivord set) in aposition where SQL without nested
lations would have required aselect-from-where subexpression.
It we know that aparticular book has three authors, we could write:
select authorarrav|l |, authorarravl21. authorarravl3]
trom books
where title = 'Database System Concepts'
Now, suppose tha: ve want a relation containing pairs of the form "title, author
name" for each nd each author of the book. We can use this query:
ee 8.tite, A.author
tran rwhsas B, unnest(B.authorarray) as A(author)
ce the authorttribute of books is a collection-valued field, unnest(B.author
ycan be uscdita from clause, where arelation is expected. Note that the tuple
Variable Bis visible lo this expression since it is defined earlier in the from clause.
When unnesting an array, the previous query loses information about the ordering
of eleements in the raY. The unnest with ordinality clause can be used to get this

intormation, as illustrated by the following query. This query can be used to

the authors relation, vhich we saw earlier, fronm the books relation.
generate

select title, A.author, A.positio

from books as B,
unnest(B.authorarray) with ordinality as A(author, position)
374
Chapter 9 Object-Based Databases

records
The with ordinality clause generates an extra attribute which the position of
the element in the array. Asimilar query, but without the with
be used to generate the keywvord relation. ordinality clause, can
9.5.3 Nesting and Unnesting
fewer (orr no)
The transformation of a nested relation into a form with
attributes relation-valued
is called unnesting. The books relation has two attributes. authorarray and
keyvord set,that are collections, and two attributes, title and publisher, that are not.
relation, with n L
Suppose that we want to convert the relation into a single flat
relations or structured types as attributes. We can use the following query to carry out
the task:

select title, A.author, publisher.name as pubname, publisher.branch

as pub.branch, K.keyword
from books as B, unnest(B.authorarray) as A(author),
unnest (B.keyword set) as K(keyword)
The variable B in the from clause is declared to range over books. The variable Ais
is declared to
declared to range over the authors in authorArray for the book B, and K
sae ver the keywords in the keyvord set of the bookB. Figure 9.1 shows an instance
elation. and Figure 9.3 shows the relation, which we shall call flat.books that is
"1i of the preceding query. Noie that the relation flat_b0oks is in INE, since all
sare atomic valued.
Se pOcess of transiarning a iNF relation into a nested relation is called
can becareittr extension of grouping in SQL. In the nor
ing ins , e iratpaiiy ndtiset relation is (logically) created for
*nat agregale iutcinpited on the temporary relation to get a
i a u e . ?he coler: :iy ticy: ns the multiset of values, instead of
ration. Suppose that we are given the
itVIng query nests the relation on the

title pub_branch keyword

Compilers Simith McGraw-Hil New York parsing
Compilers Jones MeGraw-Hill New York parsing
Compilers Smith McGraw-Hill New York analysis
Compilers Jones McGraw-Hill New York analysis
Networks Jones Oxford London Internet
NetworkS Frick Oxford Internet
London
Networks Jones Oxford Web
London
Networks Frick Oxford Web
London
Fiqure 9.3 flat books: result of unnesting attributes authorarray andIkeyvordstof
relation books.
 375

utit hh nolatiom tm igurv , aparN in iyue .4.

the authr attribute alsointoaultic, wecante the quev:
select h, collectuuthor) aN utrt.
'ublisrub name pb bnanh as publisler,
collectivivn) as keyeond set
trom et
Aroup by it publister
ANther yah nting nested lations is to use subqueries in the select
g A dlvantag' ot the subquery approach is that an order by clause van be
st in the subquery, tw generate esults in a desind onter, which can
h l tN wnte an array. The tollowing query illustrates this apprch; the
ns array and multiset speity that an array and multiset (rsptively) are tw
Mtud to the sults ot the subqueries,
select itlc.
array( select autlor
from autiors as A
where A.ithe B.title
order by Asition) as authr array,
I'ublisheryub nam. pub branh) as publiser,
multiset( select kevvond
trom kevwnds as K
where A.title Btitle) as keviord set,
OmoAN as B

lhsstemew ie nested subqueries in the select elause tor ach tuple gener
atrd by the trou 'reelausS of theouter query.Observe that the attribute B.title
!nnm the outer Sed in the nested queries, to ensurethatonly the corretsets
saegenerated tor each title.

title sthor ublisher kevord set

(pub name,pub _branc)
Compilers lonos
mith (MGtaw-Hill, Ner York) Iparsing, analysis)
Compilers
Networks lones
(MeGraw-Hill, New York)
(Oxtord, London)
Iparsing, analvsis)
|lnternet, Web)
Network Frick (ONtord, London) Ilnternet, Web}

rigure 9,.4 Apartially nested version of thetlat bvoks relation.

376 Chapter 9 Object-Based Databases

operators on multisets, including afunction sol s.

SQ:2003
which provides
returns a duplicate freeofversion of a multiset M, an intersection aggregate op-
a variety
eralion, which returns the intersection of all the multisets in a group, a fusion aggre-
of allmultisets in a groUp, and a submu
8ate operation, which returns the unioncontained
checks multiset is
if anot in another multiset.
The SQLwhich
predicate, standard does provide any wayto update multiset attributes except
to delete a value vfrom a multiset attribut.
by assigning a new value. For example,all multiset|v).
A, we would have to set it to (Aexcept

ObËect-ldentity and Reference Types in SQL

9.6 refer to objects. An attribute of ahve.
to
Object-oriented languages provide the abilitytype.
to an object of a specified For example, in SQL we can define
can be areference reference to the tvno
Department with a field name and a field head which is a
a lype Department, as follows:
Person, and a table departments of type
create type Departnent (
name varchar(20),
lead ref(Person) scope prope

create table departments of Department

the
of the table people. The restriction of
ie, t eeree is restricted to tuplesmandatory in SQL, and it makes references
cope ot i itcence to uples of atable is
heth:liletoreign kevs.
type declaration and instead
iv tit the decaration scope people from the
sth od diio0n (o the create table statement:
reate tatble epartents of Department
Uti wih options scope people)

The releOHdble e;) atiribute that stores the identifier of the tu

ple. Wedeclare os attrt ne lldthe self-referential attribute, by adding arer b
clause lo the cre.ale lable stelenet

create table people of Person

ref is person id system generated
statement
table
Here, pTSon dis an attribute name, not a keyword, and the create
specifies that the identifier is generated automatically by the database.
ofthetuple
In order to initialize areference attribute, we need to getthe identifier of a quer:
that is to be referenced. We can get the identifier value of atuple by meanstuple
witha
Thus, to create atuple with the reference value, we may first createthe
null reference and then set the reference separately:
 Objvlentitv and Retene I v p n Ql 177

insert into deurtnents

values ((CS, nul)
update deartments
set hevad= (select so l
trom;ple as
where me lohn)
where 2me='S

Analternative to systegeneatetidentitiers is to allow users to geeate iden

tuiers. The tve ot the selt-etenntial attrilute nmust es i i d as portot the tv
detinition otthe reerenvd ttable, and thee table deinition must spei that the ter
etS User generated:

create tvpe Person

(name varchar(20),
address varchar20)
ref using varchar20)
create table pople of Person
ref is eN user generated
Nhen inserting atuple in pople. we must then provide a value tor the identitier:
insert into ple (persoLd, nme', dddrss) values
(01284567,'lohn','23 Covote Ru)
Noother tuple tor pople or its supertables orsubtables canhave the same identitier.
We can then use the identifier value when inserting a tuple into deartments, withoul
the need for a separate query to retrieve the identifier:
insert into departnents
values ((CS, 01284507)

It is evenpossible to Use an existing prinmary-kev value as the identitier, by incud

Ing the ref from .use in the tvpe detinition:

create type PersOn

(name varchart20) primary key.
addrss varchar20))
ref fronm(name)
create table people of Persn
ref is prsOnid derived
Notethat the tabi detinition must specity that the reterenee is derived, and must still
sperify aself-reterential attribute name. When inserting atuple tor departntents, we
can then use

insert into departments

values ('CS, lohn)
378
(hapter9 (Object Based Datalbases

by the Symbol. Consider the

Reterenwes are dereferecod in sOL:(909
addressesdepart-of
lames and
this query to tind the
carlier. Wecan use
ments talble deined
the heads of all departments:
selecte d H a , eal ddress

from deurtments

as "hed hme" is calleda path expression.attribute

Anexpr'ssionsuch the
tuple in the people table,peopletable. name in the
reference to a
Sine ed is
query
a
isthe ume References can
attribute of thetuple fromthe without the references
PReding operations;in the preceding example, the table people. To fo
be used to hide join be declared a foreign key of
Ivad ield ofdeortmnt would head of a department, we would require an explii
the name and address of the
peple. The use of references simplifies theoor
and
jon of the relations lepartmnts
considerably.
to return the tuple pointed to by a reference and
deref
We canUse the operation below.
atributes, s shown
thenavess its
select deref(/a).ame
from deyartments

Features
9.7 Implementing0-Rbasically extensions of existing relational data
Oberelationalatabasesyvstemsare levels of the database system.
clearly required at many
Ise syslems. Chages are to the storge Svstem code (relation
storage, indices.
"iovevrto minimize changes can be translated
theomplerata tvpes supportedv object-relational svstems
) relational databaseS.
to the simpler (ype system of transltion wened only look at how some featurs
lounderstand how lo do this iustance, multivalued atributesim
theFRmodelare translated intoel:tioas or in the object-relational model.
to multis :ietribules
i 1Rnodelcorrespond wtured types. ISA
hierarchies in the
(onposile attributes roughlv O
object-relational model.
"Kodlcorrespond to table inherv, we saw in Se
convertin: 1 s totables, which
The techniques tor
slate object-relational data to rela
(iono9, can be used, with some e
lional data at the slorge level. allinherited
of
subtables can be stordin an eticNtittvithout replication
tields, in one of twoways.
parentti-
trom d
" Each tuble slores the"pimarv ker úrhwh may be inherited (otherthanthe'
ble) andthe attributesi are detined locallv. Inherited attributes meansotajoin
primary key) do not need to be slored, and can be derived bv
with the supertable, based on tlhe prinarv key. i
tupl
When a
" Fach table stores all inherited and locally detined attributes. itspreseneN
inserted, it isstoredonlv inthe table in which it is inserted,and p
 l'ersistent I'ogramnming Languages 379

tterndinevch ot the supertables, Acvess to all attributes of a tuple is taster,

B.NVer, incase the tvpe SVstenmallows an entity to be represented in two

Nultalbles without being present ina common subtable ot both, this represen-
ncan nsult in rpliation ot intormation. Further, it is hard to translate
torigu evs eterring to a supertable into constraints on the subtables; to et-
iently implemntsuch toreign keys, the supertable will have to be detined
the database sstem would have to support toreign keys on

lmplementations choose to represent array and multiset types directly, or

choose to use a normalized representation internally. Normalized representa-
tend to take up more spe and require an extra join/grouping cost to collect
ita im an arrV or multiset. However, normalized representations mav be easier to
implement.
The0DBC and |DBC application programintertaces have been extendedtoretrieve
md stune structured tvpes; tor eample, |DBC provides amethod getObject() which
is similarto getString) but returns a lava Struct objet, trom which the components
otthe structuredtvpe can beetracted. It is also pussible toassociate a lava class with
mOL structured tvpe, and |DBC will then convert between the tvpes. See the ODBC
or |DBC rterence manuals tor details.

9.8 Persistent Programming Languages

Database languages ditter tronm traditional programming languages in that theyv di
Ntly manipulate data that are persistent-that is, data that continue to exist even
atter the program th.at created it has terminated. A relation in a database and tuples
in arelation are evamples ofpersistent data. In contrast, the only persistent data that
traditional programming languages directly manipulate are files.
Aes to a database is only one component of any real-world application. While a
data-manipulatie: iangLagelike SQL 0s quite ettective tor accessing data, a program
ming language i uitvd for implementing other conmponents of the application
sCn as user interirommunication with other comnputers. The traditional way
of intertacing da: languages to progranming languages is by embedding SQL.
within the pro ng language.
A persistent
aming language is a programming language extended with
COnstructs to hà
ersistent data. Persistent progranmming languages can be dis
gushed trom.s with embedded SQL in at least two ways:
With anerded language, the tvpe svstem of the host language usually dit
ers trom tlhe ixpe system of the data-manipulation language. The program
er is resOnsible tor any tvpe conversions between the host language and
SQL. Having the programmer carry out this task has several drawbacks:
Thecode to convert between objects and tuples operates outside the object
Onentedtvpe svstem, and hence has a higher chance of having undetected
errors.
3S0

Ivwn the ohtorientd mat ant the wlatinl tuma

The omat
hanslatonudealmy wth theonte for latng. tdundng tala thm
Ninittnt vnntaeotthe otal

the qe\ languageN

lngu'
ulll mte)gatBwith the host
tomathan
cmlvBet quen languaz Nnsille otu
NNmer usn% an tom the datalNe
inepit teto teth ata must INie nBeyliwitl the n
rm,the pnogmner
aR the tatalus:
dated data lch n
without witin; nepit uewht mm
manulate pesistent data

withut havn; tothughdat.l tanipul.aton langhag

gmminglangue ti;hter inNLatinot the pngrammng langugn
shts Q Thehv thevvide

wtulone t Is vitiel N to make pgnng

itug is usuallN a
toiuedisIO hder SuppVt tor dvratve
h knl optimiation suh s
must inw
n thushuer desna en:tonepaliNSUes th,at

nos lt
s n the bibliogrrhi
ulhr detans ot inrement.tts

9.8.1 Persistence of Objets

Howerr the
ae hset thev hINwhes the gm emmates. Nhat.
 9.8 Persistent Programming Languages 381

database programming language, the first step is to provide a way to make

ersistent. Several approaches have been proposed.
bnt
Persistence by class. The simplest, but least convenient, way is to declare that
aclass is persistent. All objects of the class are then persistent objects by de-
fatult. Objects of nonpersistent classes are all transient.
This approach is not flexible, since it is often useful to have both transient
nd rersistent objects in a single class. Many object-oriented database sys
tems interpret declaring a class to be persistent as saying that objects in the
dass potentially can be made persistent, rather than that allobjects in the class
are persistent. Such classes might more appropriately be called "persistable"
classes.
, Persistence by creation. In this approach, new syntax is introduced to create
persistent objects, by extending the syntax for creating transient objects. Thus,
an object is either persistent or transient, depending on how it was created.
Several obiect-oriented database systems follow this approach.
. Persistence by marking. Avariant of the preceding approach is to mark ob
iects as persistent after they are created. AIl objects are created as transient
objects, but, if an object is to persist beyond the execution of the program, it
must be marked explicitly as persistent before the program terminates. This
approach, unlike the previous one, postpones the decision on persistence or
transience until after the object is created.
" Persistence by reachability. One or more objects are explicitly declared as
(root) persistent objects. All other objects are persistent if (and only if) they are
reachable from theroot object through a sequence of oneor morereferences.
Thus, all biects referenced by (that is, whose object identifiers are stored
in) the root rsistent objects are persistent. But also, all objects referenced
from these ets are persistent, and objects to which they refer are in turn
persisternt, .so on.
A bene!i his scheme is that it is easy to make entire data structures per
sistent by r i declaring the root of such structures as persistent. However,
the databa stern has the burden of following chains of references to detect
which obj -1 persistent, and that can be expensive.

9.3.2 Object ldentity and Pointers

In an object-oriented programming language that has not been extended to handle
persistence, when aN object is created, the system returns atransient object identifier.
Ieecut
tansiienntg object identifiers are valid only when the program that created them is
after that program terminates, the objects are deleted, and the identifier
S
dentmeani
ifier. ngless. When a persistent object is created, it is assigned a persistent object
The notion of wbyect identity has an interesting relationship to pointers in pro
famming, languages. A
simple way to achieve built-in identity isthrough pointers
382 Chaptero Objct BaNt Databases

tophvsical locationsin storage. In particular,in many object-oriented

asC++, atransient object identifier is actually an in-memory pointer,
lowever, the association ot an objert with a physical location in languages such
change ver time. There are severaldegrees of permanence of identity: storage may
Intraproccdure. ldentity persists only during the execution of a
ceure. Examples of intraprogram identity are local variables
durs. wisingle
thin proce-pro-
" Intraprogram. ldentity persists only during the execution of a
single pro-
gram or query. Examples of intraprogram identity are global variables
gramming languages. Main-Memory or virtual-memory pointers offerin pro-
intraprogramidentity. only
" Interprogram. ldentity persists rom one program execution to another. Pins
ersto tile-system data on disk ofter interprogramidentity, but they may
if the way data is stored in the file system is changed. change
" Persistent. ldentity persists not only among program executions, but als
among structural reorganizations of the data. It is the persistent form of iden.
tity that is required tor object-oriented systems.
In persistent extensions of languages such as C++, object identifiers for persis.
tent objects are implemented as "persistent pointers. A persistent pointer is a type of
pointer that, unlike in-memory pointers, remains valid even after the end of a po
gram execution, and acrOss sOme torms of data reorganization. A programmer mav
Luse d persistent pointer in the same ways that she may use an in-memory pointer
in a programming language. Conceptually, we may think of a persistent pointer as a
pointer to anobject in the database.
9.8.3 Storage and Access of Persistent Objects
What does it mean to store an objct in adatalase? Clearly, the data part of an ob
ject has to be stored individually tor each obet. iogically, the code that implements
methods of aclass should be stod in he dattiase as nart of the database schema,
along with the tvpe detintions elihess wever, many implementations sim
plv store the code in files outsid thei i avoid having to integrate system
sottware such s COpilers wih t h e c . s i s 1.
Therc are sev0lal wa1s oti:htsi atabase. One way is to give names
to obics, just Wilc1 0ach works for a relatively small
number ot obiet:, :do no: 'sotobjects. Asecond way is to expose
obedentitic ito bicts, which can be stored externall:
omnemonic, and can even be physical
Aibd w cbes, and to allow programs to iterate
t h e c o l l u l e t b ollections of obiects can themselves be mou
cied .s obe ts
0otlecion tvpes include sets, multisets (that is,sets
With p0ssiblv 1anv ourences of a value), lists, and so on. A special case o e
 biOrientrd SUS QHitAelational 3S7

Wnow describe an alternative appch which allows esistent otbits

automativlly tetehed into menorr when yuinNi. while allowing all
to be
containedin in-memorv objevts to be in-memorv eers INhen
r e t is fetehed. a hollow object is enatnd tor ch objvt that it
rternOS, andi the in-memorv copy ot Ahas reteenes tu the wNsnding
llw birt for ach B, Otourse the svstem has to ensue tht it an otbvt
R was tetehed alrdy. the reterne points tu the alrvdr tetehei obNt in
std ot ereating a new hollow objt. Smilarlv. it an objt B, has not n
hod. but is retereneed by another objet tetehei earlier. it would aludr
bave ahollow objct crated tor it: the eterene to the evisting hollr obt
is reused, instead ot eeating a new hollow objct.
Thus, tor everv objet0, that has been tetchat. everv tenne tnm O, is
ither to an alady tetched objt or to a hollow obirt. The holw obts
torm a fringe surrounding tetched objeNts.
Whenever the progranm actually avesses a hollow objt 0, the enh.ant
byte code deterts this and tetches the objevt tnm the databuse When this
obiet is tetehed. thesame proes ot cnating hollow objvts is carrindot tor
all obijcts reterenced by 0. Atter this the acess to the objvt is allwni t'
proceed.
An in-nemorv indey structure napping pesistent ponters to il-MemOrv
reterences is requird to implement this seheme When writing objts huk tw
disk, this inder vOuld be used to eplace in-memorv NternY by NNitent
pointers in the cvpy written to lisk.

The |D) stadard is still at aneurly stage, and undeging nevisiOns. Sveraln
punies provideinppleentations ot|0, Hovever, it rmains to be sn it lWwill l
widely usd, unlikeMG++.

9.9 Object-Oriented versus Object-Relational

We have now su bjt-relational datalases, which are objrtrienterd data
bases built on top lation model, as well as objvtorienterd datalses, whih
are built around
pogamminglnguages.
l'ersistent exte rOgramming lnguages and obNt-lationalsvstems tar
get ditferent nar teclarative natur and limited power (vmpard twa p
gTamning lan:u QL language provides good pntvtionot data thm pn
gramming erro
tively easy. (\Ve kes high-leveloptimizations, uch as rduing l 0, rla
nizationof relationalepsions in Chapter 14.) 0bN
relational system ahing data modeling and querving usier by using vm
The tvhnique u ioty obwts desibed abve iscoselv eateni to the haniw aeswi:-ling tuth
hique
tations(mentioned
tu Phrideaarltee wion9s4).
wnter tvpe torHniwan
pesistentsuizzling is US brVntes
andin-memV smewsistwnt -implee-
Haniwa (swi-litg tiNN
virtual memorv PIotdton tovntques when nyuind. nwntrast. the lava veNiM mnitiestvt' nie
tethes the
cherk tor hollow ob
t mstel ot
letthng whole PaS tomthe ditabse.
38S Chapter Objt-Based Databases

plex data tvpes. Typical applications include storage and querying of

including multimedia data. complex data,
Adeclarative language such asSQL, however, imposes a significant
penalty for certain kinds of applications that run primarily in main
that perform a large number of accesses to the database.
performanceand
memory,
Persistent
languages target such applications that have high performance progrdataammiThenyg
provide low-overhead access to persistent data, and eliminate the requirements.
need for
lation ifthe data are to be manipulated by a programming language. However h trans-
are more susceptible to data corruption by programmung errorS, and usually do ma
havea pOwerful querying capability. Typical applications include CAD databaso
We can summarize the strengths of the various kinds of database systems in thi.
Wav:

" Relational systems: Simple data types, powerful query languages, high pro
tection

Persistent programming language-based OODBs: Complex data types, in

tegration with programming language, high performance
Object-relational systems: Complex data types, powerful query languages,
high protection

These descriptions hold in general, but keep in mind that some database systems
blur the boundaries. For example, object-oriented database systems built aroundor
relational
a persistent programming language can be implemented on top of a
object-relational database system. Such systems may provide lower performance than
object-oriented database systems built directly on astorage system, but provide some
of the stronger protectionguarantees of relational systems.

9.10 Summary
The object-reiational data model extends the relational data model by provid
ing aricher typ system incl:ncing coliection types and object orientation.
" Colection types inciud postrdrelations, sets, multisets, and arrays, a
obiect-relaticnaB modei pot fits attributes of a table to be collections.
as well
" Object orientation provides ioheritance with subtypes and subtables,
as object (tuple) reierences.
" The SOI1999 standard extends the SQL data-definition and query langucs
deal with the new data typesand with object orientation.
,as
language,
" We saw a variety of features of the extended data-definition
collection-valued
well as the query language, and in particular support for pre-
attempttodata
attributes, inheritace, and tuple references. Such extensions accessto
serve the relational foundations-in particular, the declarative
-whileoxtending, the modeling power.