Download OB JECT CATEGORY DATA MODEL: A NEW DATA MODEL FOR

OBJECT CATEGORY DATA MODEL: A NEW DATA MODEL FOR
OBJECT-ORIENTED DATABASE MANAGEMENT SYSTEMS
by
Adane H.Zygta
A thesis submtted to
the Faculty of Graduate Studies and Research
in partial fulfilment of the requirements for the degee of
Master of Computer Science
Ottawa-Carleton lnstitute for Computer Science
School of Computer Science
Carleton University
Ottawa, Ontario
2000
8 Copyright
2000, Adane H.Zygta
Bibliothbque nationale
National Library
of Canada
du Canada
Acquisitions and
Bibliogaphic Services
Acquisitions et
services bibliographiques
395 Wellington Street
OttawaON K1AON4
395, nie Wellington
Ottawa ON KlAON4
Canada
Canada
The author has granted a nonexclusive Licence allowing the
National Libraxy of Canada to
reproduce, loan, distribute or seIl
copies of t h s thesis in rnicroform,
paper or electronic formats.
L'auteur a accordé une licence non
exclusive permettant à la
Bibliothèque nationale du Canada de
reproduire, prêter, distribuer ou
vendre des copies de cette thèse sous
la forme de rnicrofiche/film, de
reproduction sur papier ou sur format
électronique.
The author retains ownership of the
copyright in this thesis. Neither the
thesis nor substantial extracts fiom it
may be printed or otherwise
reproduced without the author's
permission.
L'auteur conserve la propriété du
droit d'auteur qui protège cette thèse.
Ni la thèse ni des extraits substantiels
de celle-ci ne doivent être imprimés
ou autrement reproduits sans son
autorisation.
Abstract
Object-oriented database management systems (OODBMS)
attempt to i n t e p t e database
and object-oriented (00)technologies. However. a single data model has not emeiged
from this approach. Radier several research prototypes and commercial products have
been developed using different rnodels. These models reflect the paniculars of their
implementarion. the programmin; language used and the set of applications they are
targeted for. The thesis defines and illustrates a data mûdel named Object Category (OC)
rhat is based on the 00 concepts. The data model is independent of any programming
langage. is suited to an' general application. and is easily derived from an EER
diagam. OC data model introduces the concept of category. which is a collection of
object instances. The use of collections by an OODBMS implies a clear and easy way of
manipulating persistent objects that is consistent with the concept of database and
resembles the operations of insert, reuieve and remove objects.
hcknowledgements
Fint of al1 I would like to thank rny wife, Salem Tewelde, for her suppon and
understanding. This thesis would not have been finished othenuise.
1 would also like to thank my s u p e ~ i s o rProf.
,
Ekow Otoo. for his ideas and assistance
duing the completion of ths thesis.
Finally. 1would like to thank the National Sciences and Enpineenng Research Council
for the partial fundin; of the thesis under the NCE: GEOIDE project, and the s t a f f of the
School of Cornputer Science for their assistance dunng my graduate career.
Contents
vii
List OF Abbreviations
cm
CAM
CASE
CSL
DBMS
ER
E R
Y0
OC
ODBMS
ODM
ODMG
Oid
O0
OODBMS
OQL
RAMI
SQL
Un&
Xbstract data type
American Yational Standards Instinite/Standards Planning and
Requirements Commitree
Cornputer-aided design
Cnmpliter-lided mmvfx ! ~ r i o g
Cornputer aided software engineering
Category specification language
Database management system
Entity-Relationship
Extended-ER
Input/Output
Object category
Object database management system
Object-to-database mappings
Object data management group
Object identity
Object-oriented
Object-oriented database management system
Object query language
Remote method invocation
Smictured query languuage
Unified modelin5 language
List of Figures
Figure 2.1
Figure 3.1
Figure 3.2
Figure 3.3
Figure 3.4
Figure 3.5
Figure 1.1
Figure 5.1
Figure 6.1
The ttiree level ANSUSPARC architecture --------------------------26
Different categories defined over the rame class ---------------- 34
Example categones-----------------------------------------------36
Muluple inheritance --------------------------------------- ----------- 36
A relationship wih additional annbute ------------------------------43
OC database schema
----------- 37
Architecture of an OC data mode1 based DBMS -------------------65
LrML - Cla s Dia m -------------------- -------------------------- 77
EER & a p m for a University's database
80
C
Chapter 1
1 Introduction
Since the earl y dayz of the darahase technnlnpy, the quec!i~ncf ~
Q W
rc
hest r-posp.n! r e d
world objects and their relaùonship has been the dnving force for new data models,
hence new database technologies. The purpose of data models 1s to model the reai world
as closeiy as possible. The data models on which the database management systems
(DBMS) are based upon distinguish hem from each other. The data model used by a
DBMS determines the data structures and operators that are available to the user. It also
detemnes the features available for storage, retnevd and management of the data
independentiy of any particular application. Almost ail database systems that are
cornrnercidly available today are based on one of the following data models: hierarchical
[11.22. 301, network [M.2230.331, relational [S. 14. 22. 30, 321 and object-oriented [5,
31.35].
Cntil the introduction of object-oriented (00)concepts, the relational approach attracred
the vast majority of database research and it represented the dominant trend in the market
place. In fact. the relational model is considered. by many. as the single most important
developrnent in the history of the database field. However, the introduction of more
powerful machines encouraged their use for new and complex applications that required
Chapter l - Introduction
-7
the services of a DBMS.The use of the relational model to satisfy the database
requirernents of these new applications is testing the model's capability to its limits.
Object-oriented database management systems (OODBiMS). which are the inregration of
concepts from 00 paradi-gm and DBMS, have been proposed as the solution to satisfy
the requirements of the "new" applications and hence to overcome the limitations of the
relational model. The "new" applications include cornputer-aided design (CAD).
compurer-aided manufactunng (CAM),computer-aided software engineering (CASE),
geographc information system (GIS),and office automation. However, unlike the
relational systems in which the data model preceded their implementation, OODBhlS
lacks an official standard data model. The proposed standard [6] published by the Object
Database Management Group (ODMG') attempts to fil1 the sap. The following statement
in [6] explaîns the lack of a generally agreed standard model better: "With respect to the
specificarion of the system, we are taking a Daminian approach. We hope that, out of the
set of experimental prototypes k i n g built. a fit model will emerge. We also hope that
viable implementation rechnology for that model will evolve simultaneously".
Current implementations of OODBMS and data models proposed so far do not include
collections as the logical view of the database. Funhemore. 00 programmin; laquages
do not support the notion of class extent explicitly. Uniike relational systems, the lack of
L
ODMG is a consortium of OODBMS vendors.
Chapter 1 - introduction
3
a simple collection based conceptuai view makes OODBMSs hard to learn and difficult
to apply for many application areas. The thesis defines and illustrates a new data model
for OODBMS named Object Category data model, which uses collections as an i n t e p l
part of 00 databases. The data model is based on the concept of category [15]. A
category is a typed collection of instance objects. The use of collections implies a clear
and easy way of making objects persistent that is consistent with the concept of database
and resembles the operations of insert. retrieve and remove objects. Unlike current data
models. the OC data model makes a clear distinction between the concept of class as a
data type and the concept of category as a collection of instance objects in the database.
..\database based on the OC data mode1 is seen as a set of interreiated categories. ï h e
objects in the database are oqanized as members of the different categones. A category's
definition includes the type of objects it is supposed to maintain, and the set of integnty
consuaints its member objects must satisfy. including their relationship to other objects.
The OC data model makes a clear distinction between class definitions and integnty
constraints. Integnty constraints are properties of categones. and not classes. At least.
four kinds of integrity constraints are supported: referential or relationship integnty, keys.
NOT N L . constraints and triggen. Relationships are defined between categones. The
data model supports binary relationship that may be one-to-one. one-to-man y, man y-toone and rnany-to-many. htegrity constraints are added andor removed from the
categories dynarnically. This approach of separating constraints from class definitions
Chapter 1 - Introduction
4
makes class design very flexible. It also prevents class definitions from being changed
and recompiled due to every rninor change in the business rules, and makes maintenance
of business rules much easier. A DBMS based on the OC model maintains the intepty of
a database by subjecting the objecrs in the database to different inteb@ty checks
depending on their category membenhip.
The OC data mode1 also provides a category/subcate_ooryrelationship between
categories. The relationship defines the set inclusion semantics for categones. By
definirion. a category is a subset of its supercategory. Furthemore. ifs member objects
are constrained by the inregrit? consuaints defined over irs supercategory. Csers interact
with the DBbIS through the facilities provided by rhe Catejory interface. The interface
includes dl the methods that are required for insertion, retrieval and deletion of a singie
object as well as a collection of objects. Objects are made persistent and later removed
from the database through the various insert and remove methods of the interface.
A framework for a DBMS based on the OC data model takes into consideration several
issues related to the traditional DBMS aspects like transaction and concurrency conuol,
as well as issues related to the complex structure of the objecrs and their organization in
the database. DBMSs are based on clienVsenrer mode1 architecture. The server side is
Qvided into two big modules, storap manager and object manager, which at the same
time is divided into several submodules. Each submodule is responsible for a portion of
Chapter 1 - Introduction
5
the object manager's responsibiliry like transaction. concurrency control, caching, etc.
Objects in a database are uniquely idenrified by their identity. Object identities could be
pointers to physical addresses or logicai identifien that are independent of the objects'
storage location. The object manager maps the objects from their intemal representation
to their in-memory representation. Furthemore. programming languages provide
collection constnicts that are equivalent to categones proposed for the OC data model.
Therefore. a seamless intepration of the progamming environrnenr and the DBMS would
be one that "ties" the user specified memory resident containers with corresponding
persistent containers on secondary storage that are defined as categories. Such
mechanism would allow the user to access categones in the database as if they were m
extension of the memory resident containers. To allow such functionality a number of
issues. including buffenng and transactional access, need to be addressed. Although a
user accesses the data as if he/she has an exclusive control of it. objects in the persistent
categories are subject to concurrent access by multiple usen. As such a concumncy
conuol mechanism thar takes into consideration the complex stmcture of objects and the
database's organization as a set of categones ne& to be incorporated. Cornplex objects
include attributes that reference other objects. However, propagating a complex object's
lock to al1 the objects it references significantly reduces the system's ability to run
concurrent processes. Therefore. objects are locked only when the users access them.
Chapter I - Introduction
6
1.1 Motivation
This thesis g e w out of an interest in currenr database research. mainly OODBMS.and
the well-known fact chat their implementaLions were not based on a well-formulated
standard data model: ln particular. a data model that i ç defined hased nn the 00 concepts.
that is independenr of any programming laquage. and is suited to any application and
not just to some. It is our hope that the data model proposed herein would help the
ongoing effort to define a standard and pave the way for a new generation of database
systems that combine the benefirs of a DBMS in a uuly 00 environment.
1.2 Goals
The main objective of the thesis is to define and illustrate a new data model that better
inregrates 00 concepts, as defined by 00 programming languages, with database
technology concepts. The data model hlly adheres to the concepts of 00 paradiam, is
independent of any specific programming lanpuage, and is applicable for any general
application. It is also simple to understand and use, and provides data independence of
the application from the database. The p a l includes outiining the different issues that
need to be considered for an implementation of a DBMS based on the data model.
C h a ~ t e r1 - Introduction
7
1.3 Main contributions
We have proposed a new data model for OODBMSs that rneets the above stated goals.
More specifically we have defined the OC data model. which introduces the concept of
category as a collection of obiects. The data model makes a distinction between classes as
a data type definition mechanism and categories as collections of objects in the database.
It provides class design flexibility and easy rule maintenance mechanisrn by separating
class definition from constraint specification. It also provides data independence by
establishing a clear distinction between the responsibilities of the DBMS and the
applications that use it. The thesis outlines the different problems that are found in
current implementauons of OODBMSs and how the OC data model solves them. It also
discusses several issues that need to be taken into consideration when implementing a
DBMS that is based on the OC data model. We have also proposed a query languaze that
c m be used to select objects the same way SQL is used by relational systems. Finally, we
have presented an example application that illustrates the various facets of the data
model. The example utilizes a prototype implementation package that is based on the OC
data model.
1.1 Thesis Organization
The thesis is divided into different logcal groups. Fint. it starts by descnbing the concept
of data model, followed by a shon review of relational model. its limitations and
Chapter I - Introduction
8
approaches taken to solve those problems. It then covers object-orienred concepts and the
problems with current implementations of OODBMSs. Next. it defines the OC data
model. the Category interface, and the category specification language. It then follows
with a description of the architecture for a DBMS that is based on the OC data model. It
dsu rcviews [ne VIUMG data model by
compmng some aspects of it with the OC data
model. Finally. it illustrates the OC data model by using an application that uses an
implementation of the data model. and outlines directions for further future works.
Chapter 2
2 Background
practices of the 00 p a r a d i p and the limitations of the relational model. It is also
attributed ro the need of 00 progamming languages to store and handle large volumes of
data using a system that is more sophisticated than a simple file management system. The
aim of this section is to g v e the background concepts that are important in order to
understand the motivation of rhe thesis. the origin and current status of OODBMSs. and
the OC data model. Particular attention is @en to the concepts of the 00 paradip and
their use by current implernentations of OODBMS.
2.1 Data Mode1
A database is a self-descnbing collection of data elernents that together with the
relationships among those elements. presents a uniform service interface [18]. It is a
logically organized and stnictured collection of interrelated data stored together. In order
to describe the structure of a database, we need to first define the data model that it is
based upon. Unfortunately, the notion of data model as it is now used in database
technology and progamrning languages has been misused from its original definition
[BI.
Chapter 2 - Background
10
In general. a data model is defined as a set of conceptuai tools for describing the
representation of information in ternis of data [12.3 11. It is comprised of data types and
suuctures. operations. and (consistency) consuaints. In other words, it is a pattern
according to which data are logcally organized. It consisu of named logicai units of data
and expresses the relationships among the data as detemiined by the interpretation of a
mode1 of the real world [XI. In order for a DBMS to understand the data model. it is
essential that it is farniliar with the concepts used to build that model. This is where the
notion of database mode1 emerges. Database models take into consideration the
representation of real world objects as well as their organization and interrelationships
w i h n a database system. A database model is a specification of the concepts of the real
world domain and eiements of a particular application in a form undentandable by a
DB-MS. h database model is specific to a particular application.
Chapter 2 - Background
2.2
11
The Relational Mode1
Currently, the rnost widely used DBMSs are based on the relational model. The relational
model i s hased on a tirnple and u n i f n m data structure, the re!a!ion. a d h s 2 selid
mathematical foundation. The relational data structure is based on the mathematical
notion of a relation. In relational systems, the user perceives the database as a collection
of relations. The SQL standard that defines the relationai database specification uses the
term table in place of relation. Each table has columns, and each column has a narne and
defined data type. The finr normal form. imposed on the relational model, requires the
values of each column to be atomic. The. can not contain sets of any iund. Ironically the
concept of what is atomic was never defined, but was pnerally taken relative to the
smallest unit of information that can be accessed in a query. Each table contains zero or
more rows. The content of each column in each row is represenred as explicit data values.
In particular. there are no pointers connecting one row to another. The relational model
[8. 14,31, 30.321 is formally and precisely defined usine the following tems:
2.2.1
Relation Schema
A relation schema R,denoted by R (.AI, At,
..., A.) is made up of a relation name R and
a list of attributes Al. AZ, ..., An. A relation schema is used ro descnbe a relation. It
defines what attributes are involved and the roles played by each amibute. For example:
Chapter 2 - Background
12
the relation schema Penon (SSN,Name, City) defines a penon as some one with a social
security number (SSN). who has a name (Name) and lives in a city (City). A relation
schema is also called a relation intention.
Each an'bute
Ai is associated with a domain. dom (Ai),and it represents the role played
by its domain in the relation schema. In the above relation schema, the domain "Narnes"
could be associated with the attnbute "Name: dom (Narne)=Narnes".A domain is a set of
atomic values.
2.23 Tuple
.
A tuple t of the relation schema R (Al. Al, . . . An) is a set of (attribute:value) pairs
(Ai:vi],where vi is a value from dom (Ai) for l<=ic=n. The tuple (SSN: 111 111 111.
Xarne:Joe. CityOttawa) is a niple in the context of the above defined Peson relation
schema. There exists a penon with social security number 111 111 111, who has the
name Joe, and Iives in a city named Ottawa.
Chapter 2 - Background
2.2.4
13
Relation
A relation r of a relation schema R (Al, A2, ... , An), r(R), is a set of n tuples of R. In
mathematical terms, a relation is defined as a subset of the cartesian product of dom (Ai).
dom (A2). .... and dom (A,). Addino a ruple to a relation or deletine- a tuple from a
relation results in a new relation. A relation is aiso called relation extension.
For database management systerns that are based on the relational model, a database is a
collection of relation variables. It describes the compiete state of an information model
through its relation variables and c m answer questions about its srate. Sirnilariy, a
database has a schema and state. The schema describes the database. The data in the
database at a particular moment in time defines the database's state.
2.2.6 Derived Relations
Denved relations are calculated from other relations known to the database. They are
most comrnonly the result of requests to the database through relational expressions and
quenes. The requests can be permanent1y remembered (and recalculated) through views.
Chapter 2 - Background
14
Herein after, unless a more precise definition is required. we will be using the rems table.
row and coiumn, and relation, tupie and attribue interchangeably.
2.2.7
Advantages and Limitations of the Relational Mode1
The relational model has its own advantags that made it very popular arnong the
database communi ty. These are:
The underlying concept is based on a strong mathematical foundation.
The simple tabular schernes and the uncomplicated relationship representation
schema provide an easy to leam and consistent user interface.
The comparative1y simple and standard access language (SQL) shonens the leaming
curve.
It provides data independence.
Despite al1 its advantages, the relationai model has its weaknesses. The bizgest problem
with relational database systems. at least as they are implemented commercially, is the
lack of mechanisms to define new domains or abstract data types (MIT) [9].They are
lirnited to data types implemented by the system: char. byte. string, integer. etc., and
comparative operaton on these types. These were assurned to be the types of atomic
values. Some of the points that have been mentioned as shortcornings of the relational
Chapter 2 - Background
15
systems in meeting the requiremenü of the "new" applications are given in [5,7, 12.2 11.
A summary of these major shoncomings is:
Relational systems deal with a single object type: a relation. Furthemore, the
attributes of a relation may corne only from simple and fixed data type domains. Nontraditional applications require more complex object suuctures with nested objects.
The relational mode1 captures the factual data about applications, but not the
"behavioral knowledge" or "domain-specific generic knowledge".
Impedance mismatch between progamming languages and DBMS.Applications that
are written in a conventional proCiOJamminglanguage and that use relational systems
retrieve data from a database usine SQL. Since SQL is a declarative languap and
since data types used by programming languages are different from those used by
relational systems. the data needs to be mapped from one data type to another.
The above can be sumrnarized as the need for type level extensibility through the addition
of new abstract data types to the database. Therefore, what is really needed is a way to
extend the data type known to the database. The organization of the database as a set of
containers (tables) is not the problem. If the relational mode1 is not good enough to
represent complex objects it is because of the limitations imposed on the definition of its
relation schema. 00 constructs allow us to define real-world objects, thus the relation
schema, similarly but differently. The main problem with relationai systems is not with
how the objects are k i n g organized (as members of a table) but how the objects are
Chapter 2 - Background
16
defined. It is possible to overcome the problem by introducing a new way of defining
objects, w h c h is what classes provide. It is important to note that we are not trying to
extend the relational model to solve the above mentioned problems. We just want to
ciarify the roles the table-iike organization of the data p l a y in the data management. A
table groups together a set of tuples and it defines the relationships and constraints its
tuples musr satisfy.
7.3.8
Approaches Taken to Overcome the Limitations
Two approaches are being taken to overcorne the problems of relational model and
develop OODBMSs [ 5 , 1 1 ] :
1. Evolutionary: Since DBMSs based on relationai model are the dominant product in
the market place. this approach extends those systems with 00 like constnicts. It is
being pursued by vendon of relational systems and is upward-compatible extension
to the relationai approach. They are called object-relational database systems.
2. Revolutionary: The other approach is to introduce database capabilities to already
existing 00 progamming languages. or to develop an entirely new 00 database
languap and DBMS with 00 capabilities.
Cha~ter2 - Backoround
17
The first approach still does not solve the so called "impedance mismatch". ïhe second
approach suffers from the lack of standard database model for OODBMSs and mostly
neglects the needs of the traditional business database applications. Herein after, we will
use the term OODBMS to refer the ones that follow the second approach. Our proposed
model. Object Category data mode1 (OC data model) takes a new approach. It is
evolutionary in the sense that it retains some of the concepts of the relational model.
mainly the Iogical view of the database as a collection of containers. It d s o is
revolutionaq. because. although it is independent of any progarnming language's
implementation, it fully supports 00 concepts as they are used by progamming
langages. By doing so. we satisfy the requirements of both applications. traditional as
we!l the new ones. and overcome the limtations of the relauonal model.
Chapter 2 - Background
18
2.3 Object-Oriented Concepts
Object-orientation was first introduced in the context of programming languages. It
provides practical benefits for the prototypinp, modeiing and progamming of advanced
applications. including hgh degree of code reuse. Object onentation allows a more
natural representation of real world entities as well as abstract concepts. Most of the
applications that currently use 00 progamrning languages require the manipulation of
complex and highly interrelated objects and most imponantiy b e y need to make use of
database management systems. Some of the most fundamental concepts of the 00
paradigm 1131 a.re class. object. inhentance. encapsulation. and polymorphism. hlthough
there is no a clear cut and agreed upon definition of those concepts [XI, the next section
attempts to give a general account of what those terms mean.
2.3.1
Class
Class is the main consuuct used by 00 proCoramming languages to define new types of
objects that have the same structure and the same behavior. A class has a name and it
defines the structurai (set of propenies or variables) and behavioral (set of methods)
Chapter 2 - Background
19
aspects of its instances called objects. The data type of a propeny might be a clasç or a
literal. For example: Penon class could be defined. in 1ava2 [17,27], as follows:
public Class Person {
static String
weightMeasurement;
lasmame;
private S t r h g
private String
firstName;
private Date
dateofBirth;
ci ty;
private City
private Double weight;
gubiic P e r s o n (String iastName, S t r i r q f i r s t N a r n e ,
Date dob, City city} {
this . iastNane = 1astNarne;
this.firstName = firstName;
this.dateOfBirth = do^;
this-city = city;
1
public String getlasthlme ( ) < r e t u m t h i s .1astName; 1
public void setLastName (String 1astNane) {
this . lastName = 1astNarne;
1
public String get?irstNameO { return this.firstName; )
g u ~ l i cString toString() {
retürn getLastName ( 1 - " , " + get3irstName ( ) ;
The above Penon class has six variables (weigh~Measurement.lasName. fin~Narne,
dateofBirth, livesh, and weight). a constructor (Peson()). and four methods
(getLastName() and setlastilTame(), setFirsd\lame() and toString()). A constructor is a
special method used to create instances of the class. Distinction is made berween instance
variables and class variables (weightMeasurement). Changes made to a class variable
'Java is a registered irademark of Sun Microsytems
Chapter 3 - Background
20
affect al1 instance objects of the class, while changes made to an instance variable affect
only the instance object that is making the changes.
2.3.2 Object
A11 objects belonging to the sarne class have the sarne structural and behavioral aspects as
defined by rheir class. Objects have states. The values ancilor states of its properties
determine the state of an object.
2.3.3 Inheritance
The concept of inhentance allows us to specialize and facronze definiuons of classes.
Therefore, the class design consists of groupinj the most general information into classes.
which are then specialized into subclasses. specifyin; more specific behaviors with each
sep. Subclasses could inherit behavior as well as structure. For example, the Penon ciass
c m be specialized inro the Employee class as follows:
p ~ x b l i cc l a s s Employee extends Person {
String
mp1oyeeNo ;
double
sala-q;
-.
p r i b l i c Persor? (String lasrName, String rirstXame,
Date dob, City city, S t r i ~ gemployeeNo,
double salary) {
super(lastName, firstName, dob, c i t y ) ;
this .employeevo = employeeNo ;
zhis.salary = salary;
Chapter 2 - Background
21
... 1
public String toString() {
r e t u r n super.toString0 + " , " + this.annualIncome();
p h l i c double annualIncorne() {
1
The Employee subclass inherits dl variables and methods of the Person class.
2.3.4 Encapsulation
Encapsulation provides a mechanism for objects to hde their implementation details
from their usen. Clients interact with an object through its public interfaces. For
example, the instance variable name of the Penon class can be read or updared through
the public interfaces ge~Vame()and setVarne() only.
23.5
Polymorphism
Polynorphism refers to the use of the same message signature to address different
methods in different classes. For example, a toSuing() message to a Penon object prints
the penon's last name and first nane. When the same message is sent to an Employee
objecr, the printout includes the employees salary.
Chapter 2 - Background
2.3.6
22
Object Identity
Object identity has long, existed in 00 prograrnming languaiages. The concept is even
more cntical for OODBMSs. Each object in a database is distinguished from al1 others by
its identity. which is independent of the state of the ob!ect. The identity of an object
remains the same during the object's lifetime within a database.
2.3.7
Advantages of 00 Modeling
The 00 paradiam has many advantages. Some of which are:
It provides for more naturalness of the abstract representation of red world
information than the relationai mode1.
It supports type extensibility through classes. The class structure encapsulates
behavior as well as the traditional static attributes.
The inhentance mechanism allows us to create new classes by subclassing, and thus
reusing existing ones.
2.3.8
Disadvantages of 00 paradigm
It lacks a standard data model.
The rich and extensible nature of the 00 data model makes implementing
OODBMSs more complex and quite challenging.
Chapter 2 - Background
23
The dynamic binding that is required by 00 paradigm makes the prograrns slower to
run.
Data mininp is harder because of the difficulty to discover new relationships between
objects.
Chapter 2 - Background
24
2.4 Object-Oriented Database Management Systems
.A DBMS is a collection of p r o g m s that enables usen to create and maintain a database
for various applications. Ir allows users to define and create the database. and populste it
with data that is later retrieved and manipulated most probably concurrently by multiple
users. A DBMS is usually divided into different software modules that act on the data and
perform diiferent functions on different levels of the DBMS architecture. The
ANSUSP.UK architecture. illustrated in figure 2.1. dwides database systems into three
different levels calied internai level. conceptual level and extemal level. The interna1
levei deals with storing and reuieving data to and from the storage media. The sofiware
modules at the conceptual level are responsible for organizing the whole database
according to a defined logical data model. They hide the physical charactenstics of the
database from higher levels. They ais0 include program for data consistency, sechty.
etc. The highest level of the architecture directly cornmunicates with users. It provides
the usen with different views of the database that address the specific needs of the user or
a group of uses. A DBMS includes software that maps data from the external Ievel to the
conceptual level, from conceptual to physical. and vice versa.
Chapter 2 - Background
25
The need for 00 pro_oramming langage usen to store their data without suffering from
the "impedance rnismatch" and the lack of expressiveness in current data models when
applied to the new generation of applications are two of the main factors that motivared
development of OODBMSs.OODBMSs try to provide an 00 image of die stored data
that c m be modified and used nearly as if it were in transient memory. An early solution
to the problem was to extend the programming languages with simple persistence
facilities allowing objects to penist between application sessions. Since then. much effon
has ;one into developing DBMSs that store objects. and into defining 00 data models.
Object-oriented modeling provides constructs for more "naturalness" of the abstract
representation of real-world information. However. OODBbISs in their current
implementations are application-onented extensions of 00 progamming languages.
They do not directly address the problems faced by the integration of the two
technoloses: 00 design methodology and DBMS.From the utilization of terms to data
organization they have been heavily infiuenced by:
The progamrning language used to develop the DBLMS.
The parricular application the designers of the DBMS were aiming at.
Database management systems are used for managing the repositories of objects that are
used in different applications. The database mode1 of a database does not necessarily
have to be similar (identical) to the database mode1 of a specific application. 00 data
Chapter 3 - Background
26
models proposed so far do not include collections as the logcal view of the database. The
use of collections b y a DBMS implies a clear and easy way of making objects persistent
1
Extemal
View 1
I
Conceptual
Level
Internal
Level
...
External
View 1
1
Conceptual Schema
1
Internal Schema
1
Stored Database
Figure 2.1 :
The Three Level ANSi/SPMC Architecture
thar is consistent with the concept of database and resembles the operations of insert,
retrieve and remove objects. Current OODBMSs provide "roots" as database entry
points [6. 14: 231. Other persistent objects are accessed throua navigation that stans
from one of the root objects. The question is how many root objects do we need to
logically represent the database's scherna In addition. most of them use garbage
1
Chapter 2 - Background
27
collection methods that remove objects that are no longer referenced from one of the root
objects. This forces usen to maintain explicit collections. For this reason OODBMSs
provide constructors for collections (set, list. etc.). However. the y leave the responsibility
of their maintenance to the progarnmer. By doing so they place the burden on the
programmer to insure the correct suucturing of the database. This circumvents one of the
primary objects of a DBMS, which is to facilitate the management of object repositones.
2.1.1
Advanîages of OODBMSs
The integration of 00 concepts and DBMS technology offers the following advantages:
Al1 the strenghs of 00 modeiing are available: inheritance. polymorphisrn,
encapsulation, etc.
Type extensibîlity through classes. which encapsulate behavior as well as the
traditional static attributes.
A simple relationshp mechanism through logical inclusion (direct object reference).
Simplicity of development through aimost direct conespondence between the
application's objects and the database's objects.
1.4.2
Prob lems With Current Implementations of OODBMSs
What are the probiems with OODBMSs as they are implemented currently?
Chapter 2 - Background
28
Unlike the relational model, which has a good theoretical basis and is well defined.
OODBMSs lack a comrnon standardized database model and formal foundations.
Constnicts used by OODBMSs are direct copies of the consmcts used by the
progamming languages that influenced them. However. the notion of 00 data model
in database systems is much broader dian that found in programming languages.
Progamming languages do not have such notions as relationshp and constraint. In
addition, there is no single 00 paradip. and therefore there are varieties of 00 data
models ( 5 ) .
One of the differences berween the 00 approach and that taken by the relational data
model is that the relational model explicitly maintains the collection of tuples.
Collections are a natural way of represenung groups of objects from the real world.
OODBMS cm not be made to work for the general database case unless the user
maintains collections of hisher own. Doing so makes applications more complex,
since they have to take some of the responsibilities that previously were under the
DBMS.
Object-oriented database manasement systems must take into account not only the
new applications. but also the traditional business data processing applications.
However. existing OODBMSs seem to ignore the needs of the traditional and focus
more on the "new" applications. In fact rnost of them are targeted at "new"
applications (CADKAM, CASE, Office automation, etc.), and are more application
oriented than technology oriented [ 2 ] .In the long nin there is a need for a single
Chapter 2 - Background
29
database system that satisfy al1 lunds of database requirements. Few applications fit
neatly into just one category [l].In addition. a Company might have al1 hnds of usen,
thus would require a database systern that could provide al1 the requirements [j].
.A class is the constnict used by 00 progarnming languages to define absvact data
types. Cnfonunately. the influence of 00 programming languages has led to a
confusing and contradictory use of the same term [2 11. Does a class represent the set
of all possible instances (intention) or just the vanable containing the instances we
happen to be interested in at the moment (extension)? Almost al1 OODBMSs treat
classes as extensions instead of (or as well as) treating them as data types.
Class definitions are used as black boxes that contain aspects of the application
progams as well as that of the database. TNsmeans that relationships. constraints.
etc. are al1 part of the class defini~on.This idea of putting every thng in one place
makes class definitions very susceptible to unforeseen errors or changes in the
business rule.
Object-oriented data models try to model real world objects. However, adding an
additional construct to the database model. namel y catepry, defines bener the logical
view of objects in a database and their organization. A database based on the OC data
model is seen as a collection of categories as opposed to a collection of objects.
Chapter 2 - Background
30
2.4.3 How Does the OC Data Mode1 Solve the Above Problems?
The data mode1 is independent of any progaxming language, and it includes the
notions that are found only in the context of a DBMS.
The use of cateoory adds more expressiveness to the data modei without the
additionai burden placed on the programmer.
By making collections integral parts of the database the OC data mode1 sarisfies the
needs of the uadi tional as well the "new" applications.
It makes a distinction between class as a mechanism to define absuact data types
(domain) and the structure used to maintain collection of objects. category. A class
represents a definition of a real-world object and as a definiuon it "represents" al1
possible occurrences (instances) of the real world object. .A category is a collection of
actual instances in the database.
The constraints. including relationships, the objects must satisfy are defined at the
category level. Objects are checked against those constraints depending on their
category membership. This approach provides data independence, and class design
flexibility without sacrificing the nearly transparent handling of persistent objects.
Chapter 3
3 Object Category Data Mode1
A
. ,.
ET!?:CC&
bd~::,
me ûbj:jcSi~c
ûf 1hk ù h i k
~ iû i i i i 2 g ~ ~
CÛiIiZpü.
rij
defincd
by 00 programmin; languages, with database technology. The approach followed is to
make the database 00 by retaining al1 the concepts of the 00 paradigm, and making
collections an integral part of the logical view of the database. The OC data model
descnbed is independent of any progamming language implementation. and it can be
applied to systems with single inheritance, multiple inheritance. typed or untyped. The
data model adheres to the basic properties of 00 paradtgm explained above.
The chapter is divided into four sections that describe the different aspects of the data
model. Section 3.1 defines the data model and its components. The Category interface
and its functionality for object insertion and retrieval are described in section 3.2. Section
3.3 lists the BNF for a category specification language whle section 3.4 explains aspects
of a query language for the OC data model.
3.1 The OC Data Mode1
The notion of a collection is very important to the concept of database management. A
single design project rnight not need all the hinctionality of a DBMS.However, a
Chapter 3 - OC Data Mode1
2
reference to a database implies a reference to a collection of whatever information of an
enterpxise we would want to manage, includin; collections of desips. The OC data
model is based on the concept of category. A category groups together a collection of
objects of the same type hierarchy. A database based on the OC data model is conceived
as a collection of categories. The organizaùon of objects in the database through the use
of categories allows us to separate most of the situations that arise only on the context of
DBMS from class definitions.
Categones are to OODBMSs based on the OC data model. what relations are for
relationai systems. They form the logical view of the database. Categones are the only
enwy poinr to the database. The informauon content in the database. at any given tirne, is
perceived in tenns of objects in catesories. Objects do not exist outside the categories.
And the operaton available ro the user for deaiing with the database are mainly operators
that manipulate objects in categories.
3.1.1 Categories and Classes
One of the main functions of a DBMS is to process a large number of interrelated objects.
None of the most popular 00 progiiITlTning languages supports the notion of a type or
class extent explicitiy. This leads to an interesting contrast between DBMSs and
propramming languages with respect to the use of types and classes 1211. The OC data
Chapter 3 - OC Data Mode1
33
model makes distinction between a class, which is the set of al1 possible instances, and a
category. that is a collection of a finite set of actual instances of a class in the database. A
class is a type and not its extension. Gnlike a class. a category is time-variant.
Under the OC data model, ciasses define data types. A category is analogous to a relation
variable of the relational model. whch is a time varying collection of objects. For
example. the above Person class defines the attributes and behaviors that are cornmon to
al1 pesons. A category defined over the Person class groups together instances of the
Person class that are known to the database. It also defines rheir relationship to other
objects in the database. and it captures their collective propenies and atmbutes. or any
integnty constraints that need to be satisfied by the collection.
A Class addresses generai properties of objects while a category has knowledge of
individual instances of objects. The class c m answer requests about the general
charactenstics of its instances. The category answers questions about the set of individual
objects it contains at a specific time. Classes are defined by the application's
progamming language for a modular development of applications, whle categories are
defined by the DBMS for an easy oganization and maintenance of the database.
Categories are typed. A category maintains a coiIection of instance objects that are of the
sarne class or type hierarchy. If class B is a subclass of class A, then objects that are
Chapter 3 - OC Data Mode1
34
Emplo yees
Figure 3.1 :
Three categories (Employees. Managers and Non-Managers) could
have been defined over the sarne class (Employee). They are related
to the Depmments category, whch is defined over the Department
class. through two different relationships: WorksFor and Manages.
instances of class B c m be inserted into a category defined over class A. Objects are
uouped into categones according to their type and their relationship to other objects.
Ci
Under the OC data model. objects do not exist outside categones. A persistent object is at
least a member of some category. The OC data model provides a large degree of
flexibility in its concept of category membenhip. In particular, objects c m be members
of more than one category ar the same time. .4 category in a database is uniquely
identified by its name. Furthemore, several categories can be defined over the sarne
class. For example, we could define three categories for the Employee class: a category
of managers, a category for non-managers, and a third one that contains al1 employees.
Each one rnight have iü own set of constraints and relationships.
Cha~ter3 - OC Data Mode1
3.1.2
35
Inheritance
Like the 00 paradigm introduced in chapter 2, the OC data mode1 includes inhentancebased categorylsubcategory or categoryhupercategory relationships between categories.
The relationship defines the set inclusion semantics for categories. A category is a subset
of its supercategory. Therefore al1 its objects are considered to be members of the
supercategory too. In figure 3.1. objects in the Managers and Non-Managers categories
are members of the Employees category roo. Therefore. @en
figure 3.1 and their
contents in figure 3.2. Employees.select(lastName="Mark") would retum al1 the three
employees whose lasr?iame equals Mark. A category inherits d l the charactenstics of its
supercategory. Characteristics of a category include its relationship with other categories
and al1 other constraints. Therefore, objects in the Managers and Non-Managers
categones are constrained by constraints defined over the Employees category.
Category/supercategory relationships are defined explicitly. That is the system does not
infer the categorylsubcategory relationship by Iooking at the signatures of the types or
class definitions. The user must declare rhs fact which asserts that the subcategory
collection is a subset of the supercategory collection.
Chapter 3 - OC Data Mode1
1
r
EMPLOYEES
Last name
First name
MA,?JAGERS
j, Fint narne
NON-MANAGERS
, Last name
First narne
Smuel
Georoe
Mark
1
1 h
t name
Mark
1
36
1 Frank
Solomon
Figure 3.2
--
I Bahta
Shows the logical grouping of persistent objects in three categories that
are related through the category/subcategory relationshp.
The OC data mode1 allows multiple inhentance between categories. A category could be
a subcategory of one or more categories. For instance, a category for teaching assistants
could be declared as inhenting from the categoq defined for students and another one
Studen ts
Sections
Figure 3.3:
A partial EER diajram for a school database with multiple inhentance
defined for employees. In addition to the charactenstics inherited from its supercategones
a category could also define characreristics that are unique to the instance objects it
I
Chapter 3 - OC Data Mode1
37
maintains. The category for teaching assistants is complemented with a relationship that
reflects the fact that a teaching assistant assists one or more sections.
3.1.3 Intemal Representation
The internal representation of a category could be a set. a list. an array. or any other
container class. The type of collection to use could be determined by the DBMS
depending on the user's need for soning or other characteristics. or the user could
explicitly specify it. Methods that conven the internal representation of a category from
one type to another could be provided. Objects are selected from a container either by
pointer (i teration), or associative retneval (query).
3.1.4
Indexes
Collections are usuall y supported by indexes. Indexes [Il improve a collection's ability to
find objects given atuibute values for those that form the key. Collections are an integral
part of a database based on the OC data model, therefore it is very important b a t indexes
are made part of the integral pan of the database too. Indexes understand the category
hierarch y. For instance. an index for the Employees category, figure 3.1, would include
references to al1 objects in the Employees. Managers and Non-Managers categories.
Several indexes can be defined for the same category.
Chapter 3 - OC Data Mode1
3.1.5
38
Constraints
The choice of appropriate data structures together with the related operations of the data
model will often be too coane to exactly represent miniworld sernantics. In this case.
additional consnaints (generally called consistency constraints or semantic inregrit'
constraints) have ro be specified. and a data model is required to provide appropriate
support (111. The OC data model separates constraints from class definitions. The
technique of separating design concems into behavior and constram designs makes the
design process easier and less prone to unforeseen errors. Because of the flexibility of
00 prograrnming. it is possible to prevent integrity violations by coding the controlling
logc as part of the applications. However. the approach does not allow separation of
algonthms (application codes) from constraints. and places a heavy burden on the
programmer.
In a real application environment. support for accommodating changes to type structures
is necessary. It is often not feasible to adjust the application code as type definitions
evolve [16]. Making changes to design in 00 systems can be expensive. OODBMSs try
to create a seamless integration berween the applications and the database. However. one
of the main objectives of any DBMS should be to minimize the effects that chanses to the
database will have on the applications using it. Therefore, it is very important to achieve
the fint objective without neglecting the second one. In OC data model constraints are
Cha~ter3 - OC Data Mode1
39
defined over categories. The data model suppons type change transparency by isolating
constraint specification from the core definition of the class. Constraints may be added
andfor removed dynamicaily. ALthough there are situations in which conversion ûf the
existing data and re-compilation of ail the applications is necessary. the approach
followed by OC data mode1 minimizes such situations. Key business rules c m be coded
as integrity constraints, and if a change takes place in the business rules. a single point of
change updates the integnty rules for al1 applications. and ensures that rules are applied
unifonnly and consistently for ail applications. Existing constraints c m change and new
ones c m be inserted. An object's constrainü have a dynamic nature that changes as the
object moves in and out of categories. For emnple. the same employee object mght be
subject to different constraint checks depending on its membership to the Managers
category or to the Non-Managers category. The separarion of actual objects from the
constraints that jovem their participation in a category has the following advantages:
Greater application independence: We define application independence as a degree of
measuring the irnmunity of application to funue changes in the business d e s . The
OC data model separates the actual objects fromthe rules governing their existence in
the database. thus avoiding recompilation of al1 applications using the database due to
changes in constraints. The constraints are plugged-in or unplugpd dpamically.
It captures better the inter-relationship between objects, which is oniy defined by the
object's membenhip to one or more categones. Objects can be migated from one
Chapter 3 - OC Data Mode1
40
category to another. For example, an employee instance object could be removed
from the Non-Managers category and inserted into the Managers category and vice
versa.
Makes rule maintenance rnuch easier.
Consuaints are predicates such that if not satisfied the system automatically raises
exceptions for the user to handle. There are a nurnber of integnty constraints that could
be enforced on a database. The more integnty niles are enforced automatically, the better
the system is. However. ir is alrnost impossible to cover al1 of rhem [l. 211. The integnty
constraints discussed in this section include referential intepty constraints or
relationships, unique or key constraints, Not Nu11 consuaints and triggen. A category is
associated with a set of constraints.
3.1.5.1
Referential Integrity Constraints (Relationships)
Referential integnty for the relational mode1 is a consrraint requiring that a foreip key
value must either (1) be nul1 or (2) contain a value that actually exists in the referenced
table. It implies that a tuple can not be deleted if its pnmary key is a foreign key for
another tuple. 00DBMSs should also handle referential integrity checks in a sirnilar
manner to avoid dangling pointers. A dangling pointer is one that is referencing a deleted
object. Relationships in OC data mode1 define the connection that exists between
Chapter 3 - OC Data Mode1
41
categories. For example. the relationship WorksFor in figure 3.1 defines the connection
between the Employees category and the Depamnents category.
It specifiea the fact that each object in the category Employee works for some object in
the Depamnents category. It is important to note that relationships are defined between
categones. A relationship defined over a caregory applies only to its member objects.
Since it is possible to have different categones defined over the same class. instances of
the same class might or not be subject to a specific integnty check, depending on their
cstegory membership. For example. employees in the Managers category are related to
Departments through the Manages relationship. which is not tme when applied to
members of the Son-Manasers category.
A relationship defined over the not necessarily distinct categories has propenies that
govem the way objects in the category participate in the relationship. We cal1 these
properties cardinality ratio of the relationship. The cardinality ratio specifies the
minimum and maximum number of objects an object in a category can be related to. The
most cornmon types of relationship are one-to-one, one-to-many, many-to-one and manyto-many. The OC data mode1 supports dl four iunds of relationship.
The cardinaliry ratio of the relationship defined over the category Ci in its relationship
with category Ctcould be more precisely specified by a pair of numben (ij) where
Chapter 3 - OC Data Mode1
-42
Oc=ic=j and j>O. It means that objects in category CIcan be related to at least i and at
most j number of objects in category C?.The cardinality ratio of the relationship
effectively defines referentiai as well as existential constraints on the objects that are
members of the panicipatinj categories. The cardinality ratio of the WorksFor
relationship between Employees and Departments could be specified as (1,l) and (0,n).
The first one (1.1) means thnt an ernployee c m only work for at least one and at most one
depanment. while the cardinality for Depanments (0.n) specifies that a department c m
have none or maximum of n number of employees working for it.
The (1.1) cardinality ratio effectively resmcts the employees that can be members of the
Employees catepry to those that work for deparunents in the Depamnents category. It
also imposes some constraints on the rernove operation for Depanments. A department
cm not be removed from the category as long as there 1s at least one employee working
for it. Or. if it is removed, then it should be propagated to the employees working for it. It
rneans that removing a department implies the removai of al1 its employees. It is also
possible to define relationships between objects in the sarne category. For example, the
relationship between an employee and its supervisor can be defined over the same
Employees category.
Relationships are not objects. Objects in categones are directly linked through their
member attributes. For example, employees and departments could be linked through
Chapter 3 - OC Data Mode1
43
deparnent and employees attributes respective1y. In [20] relationships are suggested to
be objects by rhemselves, and to be maintained in their own category. The advantaje of
this approach is that it eliminates the need for a new class when the relationship has
0
Grade
Sections
Figure 3.1:
'
A relationship with an additional attribute
additional attnbutes. figure 3.1.The disadvantages of doing so are:
It rnakes the system slower. since it would require a join operation even for the
simplest select operation.
In OC data model. relationships are defined between categones. Objects in categories are
directly linked through their member atuibutes. A DBMS based on the OC data model
provides mechanism for specifying relationships between categories.
Keys are used to uniquely identify an object aven one or more of its atuibute values.
They can also be used as a hint to provide faster searches when key values are specified.
Chapter 3 - OC Data Model
44
For instance, employee number could be used as a key for employees working for a
Company. Keys that consist of more than one amibute are called composite keys. Object
identities are intemally defined and used by the DBMS to uniquely identify objects in the
database. For a human being, key attributes are what object identities are to the DBMS.
Arguments have been made against the need of keys for OODBMSs. The user-defined
keys, known from conventional databases. are unnecessary [24]. However more people
believe that keys are essentiai ingredients of database query processing [ 6 ] .Without a key
it would be very hard. although not impossible. to enforce the nile that specifies the fact
that employee numben should be unique within a Company. In addition to object
identities, objects in a caregory can be uniquely identified by the values of one or more of
their attribues. 4 DBMS based on the OC data mode1 provides a mechanism to define
keys.
Speciai case of domain integity constraint is the YOT NELL constraint. h % U
represents a missing attribute value. In many situations we want the value of an attribute
to be neither empty nor W.For exarnple, every person must have a name, therefore
name should aiways be different from nul1 and empty. The OC data mode1 supports NOT
NLLL constraints.
Chapter 3 - OC Data Mode1
45
3.1.5.1 Triggen
In practice there are different types of constraints that could be defined over a database.
However, it is nor practical to have a special integrity constraint type for each one of
them. We need a genenl mechanism whereby usen can express integrity rules and
eniorce them. The general mechanism should allow us to define almost al1 possible types
of constraints. and should provide the constnicts for the following actions: defining the
integrity constra.int and specifying the actions to be taken when an inte-gity rule is
violated. The more general the mechanism is the more types of constraints it
accommodates.
Triggers are special mechanisms for enforcing integrity constraints. In most cases when
an integty constraint is violated. the system will raise an exception that will probably
end up intempting the process that caused the violation. Tnggen are a way to avoid such
situation and correct the situation automatically. They are a combination of two things: a
condition and an action. The condition is associated with the operations that a user can
invoke on categories: insert object. remove object, modify object, and reuieve object. The
condition c m also be more precisely specified as before operation or after operation. For
example, if we define that a department's manager saiary should be the sarne or higher
than the maximum of the other employees' salary. then modifying an employee's s a l q
Chapter 3 - OC Data Model
16
should automatically fire a trigger that checks the managers' sdary appropnately. The
OC data model provides a mechanism for specifying triggers that are fired upon the
invocation of operations that insert. modify andor remove objecrs.
In addition to the above mentioned explicit user defined consuaints. there are other
constraints that are implicitly and automatically enforced by the OC data model. For
instance, the intemal representation of a category could be a set, a list or an array. The
type of collection used irnplicitly defines some constraints on the category. For example,
if a set is used ir irnplies that objects can not be duplicated on the s m e category.
Chapter 3 - OC Data Mode1
47
3.1.6 Schema
For each database created. the DBMS stores and maintains a metadata or schema. The
schema describes the database's stmcture and i c uced hy the DBMS !o perf~rrr!ils Z
S ~ .
The information stored in the schema. figure 3.5, of a database based on the OC data
mode1 contains descriptions of the categories defined. the classes whose instances are
ç'
Keys
m
Not-Sul1
m
A
Indexes
1
1
Triggers
Fiyre 3.5:
1
+
7
-
rr
Categoties
Relationsttips
The Partial EER Diagram for the Schema of a Database Based on the
OC Data Model
persistent. and the relationships between the categones. It also includes information on
keys,constraints, and uiggrs. the indexes defined on the categories as well as other
Chapter 3 - OC Data Mode1
48
information used to determine the physical and logical structures of objects. Security and
user authorization information is also recorded. The schema can be stored in a collection
of categories and maintained using the facilities provided for object manipulation.
3.1.7 Advantages of the OC Data Model
The OC data model adheres to the basic properties of the 00 paradiam. Therefore al1
the advantages of OODBMS.as menuoned above. are available in an OODBMS
based on the OC data model.
The model can be easily derived from the extended entity relationship dia-.
Ir provides a framework for unifyîng value-based and identity-based access to objects.
Offers a more natural. logical and consistent view of the database.
By isolating consuaint specification from the core definition of the class. it provides
increased data independence. and flexible design approach.
Satisfies the requirements of databases that combine the new applications
(C.W/CAM, CASE. GIS,office automation, etc.) with the traditional business data
processing applications.
Reduces the overhead of worlung with collections, whch are the basic components of
any database.
Chapter 3 - OC Data Mode1
39
3.2 Object Manipulation using the C a t e g o ~Interface
A database based on the OC data mode1 is a collection of interrelated categories with a
simple interface. The logical view of the database is composed by the cateoories
- it
contains. Applications interact with the database through the categories and the
operations defined in them. Objects are added to a category by using one of the insen
methods. Once inserted they are explicidy removed from the category using the remove
operation. The Category interface includes operations that allow usen to insen. revieve
and remove objects. These operations c m be divided into single object operations and
collection type operations. Collection type operations allow a collection of objects to be
inserted. retrieved or removed in a single method call.
3.2.1 Attributes of Categories
Categories have two kinds of attributes: attributes defined by the class being maintained
and attributes defined by the category itself. For example. the Employee class defines the
attributes of each object, like narne, birthday. etc., while the Employees caregory defines
azgregate attributes like the number of objects in the category. For the purpose of
queryng. a category's attribute set includes only those attributes defined by the class it
maintains.
Chapter 3 - OC Data Mode1
50
32.2 Making Objects Persistent
Instances of a class can be persistent or transient. A DBMS based on the OC data mode1
provides different mechanisms for objects to becorne persistent. Two of the possible
mechanisms are explicit insert and object reachabilicy. T h r o u ~ hexplicit insen, an object
becomes persistent when it is explicitly insened into a category through one of the
different insen methods. .4t least two insert methods are provided: insen (Object O ) , and
insert (Collection c ) .
3.23 Retrieving Persistent Objects
Access to persistenr objects is done through categones. h y object in the database can be
reached through one or more of the categones. The interface provides different ways of
retrieving objects from a category. We can ask for a collection of objects that satisfy
certain predicate or we can ask for a specific object. The number and type of access
operaùons pmvided varies dependmg on the category's interna1 representation. For
example, if a list is used, then it is possible to retrieve objects by their position in the list.
Another way of retrieving objects is through quenes. Query is an important aspect of any
DBMS. Usudly a database stores and manages a large number of interrelated objects
organized in a certain way. Quenes are invoked against collections which categories are.
Query is a mechanism that allows retrieval of objects by their value.
Chapter 3 - OC Data Mode1
51
The Category interface provides operations that accept a predicate as an araoument, like
selecr (Predicate p) and get(Predicare p). A predicate is a boolean expression that is
evaluated against each object in the category. The result of invoiung these methods on a
category could be a collecrion of objects or a singe object. By allowing value-based
expressions to select objects. the OC data mode1 provides a framework for unifyng
value-based and identity-based access.
3.2.1 Removing Objects
The lifeume of a persistent object spans from the moment it is created until it is
completely removed from the database. Objects. once inserted into a category, are
explicitly removed from the category using the remove operation. The set of remove
operations includes operations that remove an object aven iü id. remove (Objecr obj).
and operations that remove objects aven a predicate. remove (Predicare p). An object
continues being persistent until it is removed from every one of the categories it has been
explicitly insened into. Removing an object from the only category it is a member of
autornatically removes the object fYom the database.
C h a ~ t e3r - OC Data Mode1
52
33.5 Modifying Objects
The Category interface does not define an update method. To achieve a nearly transparent
manipulation of persistent and transient objects, the preferred way for handling updares
of obiects is for the DBMS to automatically propagate the modifications ra the datahase
widiout the user havinj to cal1 an update method.
3.2.6 Other Operations
In addition to the above-mentioned minimal functionality. the Category interface could
be enhanced with operations that dynarnicall y change a catepry 's configuration.
Confi_ourationof a category includes its internai representation. i ts relationship with O ther
categones. and other constraints defined over the category.
Chapter 3 - OC Data Mode1
53
3.3 Category Specification Language
From the user's point of view, there are two aspects to the definition of an application's
schema for an OODBMS based on the OC data mode1 class d e f i n i t h a d c 2 w g x y
specification. Class definition is the declaration of classes whose instance objects will be
persistently stored in the database. Class definition cm be written in the progamming
language's class definition language. or it can be wntten in an object definition language
rhat is independent of any pro-oraniming language. as in [6].Class definitions are subject
to the features and limitations of the host progamming language used to write the
application. The OC data mode1 does not define a class definition language. The
approach to be used is lefi for implementers of OODBHS.
Caregory specification languap (CSL) is a language to be used for the declaration of
categories. Two different approaches could be used for category declaration: through a
specification language. or through low-level calls provided by the DBMS. The use of a
specification langage would require the use of a pre-processor that would accept
category specifications and add hem to the database's schema. The second approach
avoids the need for a specification language and a pre-processor.
Chapter 3 - OC Data Mode1
54
The CSL's p t a x includes semantics for the specification of the following aspects:
category name, class name, intemal representation. relationships, key consaaints, NOT
1 N L . L constraints,
and uiggers. The top-level BW for CSL is as follows:
ccategoryheadem
.._
..-
category ccategory-name>
[extends ecategory-name- lis^]
The category-header specifies the category name that is unique within a database and the
caregories from w hich it inhents. The body part. w hich stans with ( and ends with ) is
composed of five parts. For the complete B N F of CSL see Appendix A.
3.3.1 Extent Declaration
.4s mentioned above, different collection types cm be used as an intemal representation
of a category. In addition. a category is typed to a specific class. The BNF for extent
declaracion is as follows:
cextent-declaration> ::=
<set-dedaration> 1
ciist-dechration> 1
< a m y-dec larati on>
Chapter 3 - OC Data Mode1
55
It specifies the intemal represenration of the category as a set. list or array. The type of
collection used detennines the additional functionality of the category. For instance, the
list declararion would require the specification of the attributes by which the category
will be sorted out and the order of sorting. The BNF for list declaration is as follows:
d i st-dechrations
::=
list <class-name> [ corder-dedaration> ]
corder-declararion>
::=
orderedBy corder- lis^
corder-lisu
.._
<attribue-name> [ <order> ] [, corder- lis^ ]
corder>
.._
ASC (DESC
3.3.2
Relationship Declaraüon
The specification of a relationship between two categones includes the related categories
and the anributes used for the relationship. Ir should aiso include the cardinality of the
relationship. X category c m be related to one or more categories. The BNF of
relationship is as follows:
uelationship-cieclaratiom
::=
refationship <cardinalitp
crelated-category-name>
iink canri bute-name> inverse
uelated-atmbute-name>
ccardi naiity>
3.33 Key Declaration
Objecü in a category are uniquely identified by the values of one or more of their
attributes. The BNF of key specification is as follows:
Cha~ter3 - OC Data Mode1
56
dey-declaratio~
::=
key <anribute-liso
cattribute-lis-
..-
cattnbute-name> [, <ambute-lisu]
3.3.4 Yot Nul1 Declaration
One or more of the amibutes of the objects in a category mav he cnnstrained rn he 'Q!
null. The BlNF for Not Sul1 declaration is as follows:
aot-null-dedaration>
...--
notnuii <attribue-lisu
3.3.5 Trigger Declaration
A trigger is an action that is fired every time an operation is invoked on a category. A
trigger could be fired as a consequence of the insert, remove. modify or retrieve
operation. It can also be exactly specified when it should be fired: before the operation or
after the operation. The BM: for triggen is as follows:
<uiger-decl aration>
..._
-
trigger con-dechration>
ctrigger-name> [ <when> ]
<w hen>
....--
before 1 after
Chapter 3 - OC Data Model
3.4
57
Query Laquage
Object Category data model organizes objects as memben of categories? which is very
cimi lar to rhe way tuplec are orgmized ir! re!zfi~cl! syrtemr. Bec--se of t!is s:~i!i+~
J
the query language used for relational systems. SQL [IO], can easily be adapted to fit the
OC data model. However. there are one major issue thar needs to be addressed when
trying to adapt SQL to the OC data model: retum objects type. When a select query that
gets its attributes' values from more than one category is invoked, it retums objects of a
specific type that are dynarnically consuucted by the query processor. We use the
application described in chapter 5 to illusmte the proposed que.
language with
examples.
3.4.1 Return Objects Type
Relational systems are based on only one data stnicture, i.e. relation. The result of a
select query is dways a relation. Cnlike relational systems. 00 systems provide
mechanisms to define new data types based on the concept of class. 00 databases,
including OC data model, store and manage objects that are instances of classes. Most
OODBMSs provide query facilities that span a single class andfor a singie collection of
objects
[j].As
illlustrated in section 3.2. since a catesory is a collection of objects of the
same type. a query langage that spans a single category would only require the
Chapter 3 - OC Data Mode1
specification of the predicate. However. to achieve the objectives of SQL in relational
models, we need to provide a mechanism for the execution of queries that freely combine
attxibutes from objects in different categones, andlor different classes.
.A select query in 00 databases returns objects that are instances of an existing class. The
values for the attributes of the objects rnijht be extracted from one or more classes.
However. SQL's select statement does not specify the hnd of objects to be returned.
Therefore, the new select statement for 00DBMSs should state the attributes to be
retumed as well as the type of objects to be created. For instance. let us Say that @en
the
Students category and the Professon category we are interested in findin; students whose
last name is sorne professor's lasr name. However, we are not interested in retrieving
neither student objects nor professor objecü. We only want to retneve some attributes
from students (last narne and section) and sorne amibutes from professon namely
education and section. SQL-likeselect statement to retneve the information we are
interested in would be:
Select s.lastVarne. s.sections. psections, peducation
From Students S. Professon p
Where s.lastName = p.lastName
The OC data mode1 and dl 00 data models work at object level. However by readinp the
above statement it is not clear what kind of objecü will be returned. We should be able to
include in the statement an indication of what kind f objects we want to be created. We
Cha~ter3 - OC Data Mode1
59
should d s o be able to specify how the participaring anributes (s.las~Name,s-sections.
p.sections and peducation) should be combined to constnict objects. Our proposal is to
define a query consmctor that accepts three arguments: the select statement, the object
type and the collection type. We define a Query class that is provided with the facilities
needed to parse the select statement, execute it and retum the objects in a specific format.
Let us first define the Std-Prf class that we use to create the objects ro be returned.
p u b l i c class Std-Prf {
String
IastName ;
Sections
Sections
Scring
stdsections;
prf Sections ;
education;
public Std-3rf (String lastKame, Sections stdSections,
Sectiozs prfsectiocs, Scring education) {
this.lasiName = lastName;
this.stdSections = stdsections;
this.prfSections = prfsections;
education = education;
}
public String t o S t r h g ( ) {
r e t u r n lastName + " , " + stdsections.toString ( ) + " , "
+ p r f . sections. coScring ( ) + " , " + education;
Now we can create a que.
constmctor as follows:
and pass the above class name as an argument to the que.
Chapter 3 - OC Data Model
public class TestQuery
{
..m
S ~ r i n gqry = "Select s.lastName, s.sections s t d S e c t i o r . s ,
p.sections prfsections, p . e d u c a t i o n
Frorn Students s, Professors p
Where s.lastName = p.lastNamen
Que-ry q = n e w Query(qry, S td-Prf , Queiry.vec tor ) ;
Vector r s l t = ( V e c t o r ) q . e x e c u t e ( ) ;
f o r (i=l; i<rslt.size(); i-+) (
System. out . p r i n t l n ( ( (StÙ-Prf)
(rslt.elementAt(i))).toStri~gO)
The query statement (qry) is a statement very close to the SQL's select statement. The
space between "s.sectionsWand "stdSectionsWtells the query consmctor that values from
"s.sectionsVare to be srored in the anribute "stdSections". If both, the o r i p and
destination. attributes have the same narne, then the second amibute name may be
omitted. The second argument specifies the type of complex objects to be created. The
last argument. "Query.vector". indicates the collection type to be retumed. The Query
class could be provided with capabilities to retum any kind of collection or iterator. In
conuast to JDBC's SQL mechanism [19], the above query clearly States the amibutes and
the type of objects to return. Every retumed tuple forms an object and is manipulated
through the interface provided by sorne class, in this case by the Std-Prf class. The class
defines the structure and behavior of the objects renimed. Therefore. there is no need for
JDBC like getStnng, getlnt. etc. methods to renieve the atmbutes from the result set.
Chapter 3 - OC Data Mode1
61
p u b l i c class TestJDSC {
-.String qry = "Select s.lastXame, ~ . s e c t i o n sas
stdsectlons, p-sections as prfsections, 2.education
From Stucents s, P r o f essors p
Where s.lastName = p.las=Namen
Statement s=m = c o r i n e c t i o n . c r e a t e S t a t e r n e r , t ( ) ;
ResultSet r s i t = stm.executeQuery(qry);
while (rs7t.next()) (
String str += rslt.getString(\*lastNmel')+ *' *' +
r s l t . getObject (\'stdSectio~sJ*)
i "
t
rslc.get0bject ("prfSectiozsn) + "
+
r s k .getstring ( "educa"iiontr) ;
System.out . p r i r i t l n ( s t r ) ;
\*
\*
Str
=
1'"
.
t
It is obvious from the above JDBC example that the returned attributes are treated as
independent and not as pan of an object. Furthemore. using JDBC we c m not specify
the behavior of the retumed objects. nor the collection type. Therefore, whatever we want
to do with the result (the behavior) has to be hard coded as part of the application.
defeating the notion of encapsulation and 00. The only requirement for the proposed
query mechanism would be that dl attnbures and methods that participate in the que.
must be publiciy accessible. In addition. the remm type class, in this case Std-Prf, must
provide either a zero argument constructor. or a consmictor whose arguments are similar
to the one specified in the altribute list. Following SQL's select-from-where foxmat, the
general syntau for select statement codd be defined as follows:
Chaprer 3 - OC Data Model
62
Select <expression> [<amibuteparne>] [{ ,<expression> <anribute-name> }]
From ccategorp [( ccategorp } ]
[Where <predicate>]
.
<expression> could be any expression that yields a value of type that is compatible wi th
the tw
- - of <amibuteaname>,In particular. it could be an amibuteTcname or a methnd
d l . The Where part might be omiaed in which case al1 objects will be reuieved.
4 Framework for a DBMS Based on the OC Data Mode1
A DBMS that is based on the OC data model is used to manage datahases rhat are
collections of interrelated caregories. which at the same time are collections of objects
that are concurrently accessed by multiple users. To allow an efficient and concurrent use
of the database, and at the same time maintain the consistency of the database, several
issues need to be addressed. This section discusses the issues that aise when
implemenring the conceptual level of a DBMS based on the OC data model. The
impiementation takes into consideration aspects related to the traditional DBMS
functionality like transaction and concurrency control, and others that are unique to the
OC data model and its 00 nature.
4.1 Architecture
The architecture. illus~atedin figure 4.1. is based on cliendserver model and is divided
into three levels according to the AVSVSPARC standard: storage level, object level and
application level. The storage level software is responsible for low level disk VO
operations. while the application level deais with a single user's requests. In between is
the object manager: which at the same time is divided into different submodules related
to transaction. concurrent y control, recovery, security, caching, clustering, object
Chapter 4 - Framework for a DBMS Based on the OC Data Model
64
manipulation and schema management. Since each submodule could by itself be a subject
of a thesis, it is not possible to cover d l issues and implementation alternatives available
for the different components.
1.2 Implementation Issues
As mentioned in the OC data mode1 definition. objects in a database are uniquely
identified by their identities. Because of this, persistent objects have two lunds of
representation: in memory and in disk storage. The object manager handles users' request
by transparent1y trançforming the object's representation from in-memory to oid or vice
versa. A table hashed by oid can be used to access an object in memory given its identity.
Object identifiers can be pointers to physical addresses or logcal ones. Using physical
pointers makes object access much faster since the systern aiready knows the physical
address. However, the system has to be provided with additional funcrionality to allow
object relocation. Using logical pointers has the addirional overhead of maintaining a
table that maps the logicd pointers to physical addresses. Therefore, reading an object
might imply two readings. one to j e t the object's physical address and the second one to
retrieve the object itself.
Chapter 4 - Framework for a DBMS Based on the OC Data Model
65
Objects in a database based on the OC data mode1 are orgnited as members of persistent
categories. Furthemore. categones are the on1y entry points to the database, and an
objecr in the database cm be accessed through at least one of the categories. This fact c m
be exploited by the DBMS by fint caching the categories into the usen' main memory,
Applications
I
i
Object
manager
1
1
Storage
manager
Figure 4.1:
Objcct manager
Clustering
1
Cache
1
1
I
c
Disk Manager
Cache
A Three Level Architecture for a DBMS Based on the OC
Data Model
and then transparently redirecting object requests through them. Such rnechanism would
provide an easy and transparent way of moving objects from and to the database.
Chapter 4 - Framework for a DBMS Based on the OC Data Mode1
66
Furthemore progamrning langages provide container classes that are similar to the
persistent categories used by the OC data model. What is required and to be provided by
a DBYS is a mechanism that extends the memory resident containers in a way that
allows them to span the structures of persistent categories. This mechanism of "tying" a
memory resident container class with a penistent category would dlow the user to
traverse the data in the database as if it were in memory. To allow this seamless
inteqation of memory resident container classes and persistent categories, issues like
buffenng rnechanism and transactional access need to be addressed.
Databases are used to manase a huge number of interrelated objects. It is almost
impossible to Ioad a database's content into the main memory. Therefore we need a
buffering mechanism that transparently sends and brings data to and from the secondary
storage. Such buffenng mechanism would use a cache to control the flow of data from
and to the penistent categories. The first tirne a category is accessed the user is given a
handle to the category. Alternatively. the category could be "tied" with an existing
memory resident container object. The container object is then used to traverse the
persistent catepory it is "tied" with as though the categoq was in memory. To achieve the
transparent traversai of persistent categories, a buffering mechanism process c m be
running that manages the cache and controls the flow of data. sending data from and to
the semer as required. The other important issue that needs to be addressed is a
mechanism for a transactional access of the objects in the persistent categories. It shouid
Chapter 4 - Framework for a DBMS Based on the OC Data Mode1
67
be recognized that while an individual progamming environment accesses the data as if
it has exclusive access to the data, the persistent collection of objects in the categories are
shared resources and are subject to concurrent access (reading and writing) by multiple
users. When uncontrolled this could create consistency problems to the database. Thus a
concurrency control mechanism that prevents such problems from happening needs to be
included. Such mechanism would need to take into consideration several issues.
Categories are collections of objects with complex nature. As such. an objecr c m have
attnbutes that reference other objects. Ropagating an object's lock request to al1 the other
objecü that can navigationally be reached from it would significantly reduce the system's
ability to handie concurrent requests. A rnechanism that locks objecrs only when the user
accesses them is difficult to implement and is prone ro deadlocks. However. it
significantly increases the number of processes that can run concurrently. Furdiemore.
concurrency control mechanisms require a constant request-reply interaction between the
user and the server. Dependmg on the way users interact with the server, the mechanism
could create a network traffk overhead. One solution proposed in [3] uses a "semioprimistic" technique and attempts to reduce the overhead by rninimizing the number of
messases that are exchanged between the two processes. In a "semi-optimistic"
interaction, the user sends a lock request to the server. However, the server does not send
a reply to the user unless the request cm not be satisfied.
Chapter 4 - Framework for a DBMS Based on the OC Data Mode1
68
Related to the buffering mechanism and transactional access discussed above is the
problem of obsolete cache. As mentioned above objects in persistent categories are
subject to concurrent access by multiple users. This means that an object in a user's cache
can be modified by another concurrently mnning user making the object in the fint user's
cache obsolete. The solution io this problem requires a callback mechanism that allows
the system to notify the user of the changes to the object so that the cache is updated.
Chapter 5
5
Related Work
5.1 ODMG 2.0 Standard
ODMG 1.0 is a srandard for object database management systems (ODBMS)proposed
by Object Data Management Group (ODMG). The p u p is composed of representatives
of the major vendors of ODBMS/ODM products. The standard [6] defines fiom the
simplest aspects. object and literal. to the most complicated aspect of a DBMS that m u t
be satisfied by products that comply with the standard. The major components of the
standard are:
Objecr model
Object specification language
Object query language
C t t binding
Smalltalk binding
Java binding
The object model defines the common data model, including the metadata, to be
supponed by d l implementations. The object specification language includes an object
definition language (ODL)and object interchange format (OF).Object query language is
Chapter 5 - Related Work
70
a declarative language that is used for queryin; and updating database objects. The last
three components define the object model's binding to three prograrnming languages:
C u , Smalltalk, and Java-
A data model for DBMSs should be characterized by organization structure. valid
operations and constraints that must be enforced by the DBMS. The anempt by ODMG
to define a standard for ODBMSs is a big step towards the fast development and
acceptability of the technology. However, as important as it is, the standard is plagued by
the same problems that are found in curent implementations of OODBMSs. The
documenr States that "We have picked and combined the best features of irnplementations
we had
available to us". Current OODBMS'implementations are application oriented. As
such, they address only aspects that are relevant in the context of the specific set of
applications they are targeted for. Instead of attempting to integrate the different
implementations, a better approach would have been to corne up with a new database
model that bener inte-gates 00 concepts into the DBMS technology. A new data mode1
for new jeneration of OODBMSs that cm be used for any kind of application.
The OC data mode1 does not define what an object is. It adheres to the generally agreed
use of 00 tems by proCgamminglanguages. In this section. we describe some aspects of
the ODMG data rnodel and their counterpart in the OC data model. The standard by
ODMG is still a continuing work and as such it will be revised and enhanced.
Chapter 5 - Related Work
5.1.1
71
Logical View
The OC data model includes collections as the logicd view of a database. A database
based on the OC data model is seen as a collection of cateeories. which are the oril y entry
points to the database. The ODMG 1.0 states that "the application's object model is the
database's (lo@cal)schema".
5.1.2
Categories vs. Implicit Extents
The ODMG document states that "Many people believe that extents are essential
ingredient of database query processing. Implicit extents and keys would be preferable to
explicit mechanisms involving narned collections. yet there are challenging engineering
issues that must be faced to rationalize these capabilities with the notions of transitive
persistence and dynamic storage management herein presented.
It first completely agrees with Our belief that collections are essential part of a DBMS.
However, it diffen from our use of categories. There are, of coune. challenging issues
that must be faced by OODBMS implementen. However, this is not a reason to shy away
fiom their use. The use of categories, as descnbed in rhis document, has advantaps over
the implicit extents. Some of the advantages are:
Chapter 5 - Related Work
72
Categories are more than a collection of objects. They define the relationshps
between member objects, and offer operations for object manipulation and intercategory communication.
Implicit extents do not give the user the freedom to organize the database as he/she
sees i t fit.
OC data model allows objects to be memben of more than one category. which
allows h e m ro be subject to different consuaint checks. Ths approach offen some
support for object mi-gation. which is not availahle if we use implicit extents.
5.1.3 Attribute or Relationships
According to the standard 'Two kinds of propenies are defined in the ODMG Object
Model: atuibute and relationship. An atmbute is of one type. X relationship is defined
between two types. each of which must have instances that are referenceable by object
identifiers". It also States that "Relationships are not directly supponed by C++. Instead.
they are supponed in ODMG by including instances of specific template classes that
provide maintenance of the relationship. The relation iüelf is implemented as a reference
(one-to-one relation) or as a collection (one-to-rnany) embedded in the objects." An
attnbute might be used by the DBMS to enforce referential inte-gity, but it is still a
normal attribue. The OC data model defines relationshps as properties of categones and
not objects. As such. an application's data definition does not have to change to
Chapter 5 - Related Work
73
accommodate the DBMS's requirements. Furthemore, embedding the relationship in the
class definition prevents the user from using that particular attribute the same way as
hejshe uses any other amibute. Relationships are more than direct references between
objects. They are integnty constraints that must be enforced by the DBMS. Progamming
languages do not support the notion of relationship. 4 standard for persistency of 00
progamming 1angua;e objects in databases should accept an application's objects as they
are defined by the progamming language used. and complement them with the minimum
possible extension without alterin; the way they are usually used.
5.1.3
Constraints
The document says nothing about constraints that are neither relationship nor keys. It is
the class designer's responsibility to include every constraint check as part of the class
definition. This means that every simple rule change would require the recoding of the
class definition, recompiling the application, and chanpng the schema in the database.
Doing so is a very hi& pnce to pay because of the fact that changes to 00 systems, in
fact to any sptem by that matter. are very expensive. A data model for OODBMS should
make a clear distinction between the static and volatile parts of object definition. The OC
data model associates constraints widi categones and not class definitions.
Chanter 5 - Related Work
73
The ODMG 2.0 standard defines an object query language. In general quenes are rnainly
used to select objects from collections, which categories are. Relational systems use SQL
to access any object in a database. The language is relatively easv because of the uniform
orgnization of the database. Tables are the only entry points to a relational darabase.
Similarly. the OC data mode1 defines a database as a collection of categories, w h c h are
collections of objects. Therefore. it lends itself perfectly to the use of a query laquage in
the manner SQL is used by the relational mode]. The same can not be said about
ODBMSs based on the ODMG 2.0. .-ln 00 select statement has five parts and is of the
following form:
(collecrionType<class>) (CI,
C2,C3,.... C,).select (atmbuteList. predicate)
The "collectionType" and "class" specify the type of collection used as a container and
the type of objects to be r e m e d respectively. C, , l<=i<=n, indicate the categories that
participate in the query. The "attributeList" is a list of attribütes that togeiher will f o m
objects of type "class". The "predicate" is used to filter the objects to be retumed.
ODMG's OQL is defined to "query denotable objects starting from their narnes, w h c h
act as entry points into a database. A name may denote any kind of object, Le., atornic,
structure. collection. or literal". The lack of uniformity of input objects makes the use of
OQL in ODMG 2.0 Iess intuitive.
Chapter 5 - Related Work
75
5.1.6 Keys
Keys are used to uniquely identify objects from a collection of objects. In the OC data
mode1 keys are declared against categones, which by definition are collections of objects.
The ODMG standard States that 'The scope of uniqueness is the extent of the t
type must have an extent to have a key". Unlike ODMG 2.0. in OC data mode1
collections and keys are an integral part of the database.
p . thus
a
Cha~ter5 - Related Work
76
5.2 Unified Modeling Language (UML)
UML[16] is a modeling language to express the results of an 00 analysis and design. It
Inc!-des dbgrzxs t~ rtpresmr c!sses, ;sr cases, actP.5:~ diapïïs,
... ce.Li c s i i r r ~1t6
the OC data model and the ODMG 2.0 standard. UML is not concemed on how to design
and develop an OODBMS.However. as a general purpose 00 modeling language, it can
be used to draw the dtagams of an 00 database model. Specifically class diagrams.
which are used to illustrate class models, are cornfortably similar to database models. In
this section we will illustrate how UML notations. instead of EER diagram, could have
been used to express the design of most of our examples.
A class d i a C mdescribes a system in terms of objects and the relationships among them.
As mentioned before, a database is a logically organized and stnicnired collection of
intenelated data objects stored together. The class d i a a m modeling technique includes
notations to express the objects design (atuibutes and operations) and the relationships
arnong them. The two principal h n d s of relationships that can be established between
objects are associations and subtypes. Associations are used to express referential
integnty constraints, including cardinafity ratio (multiplicity), between participating
objects. Subtypes specify the IS-A relationship between objects. For example, the one to
many worksFor relationship (figure 3.1) between employees and departments c m be
Cha~ter5 - Related Work
77
represented as an association between objecu of type Employee and Department. (figure
Multipiicity
Depanment
- id
- name
- description
- name
- daceOtBirth
- totalEmployees(j
Subrype
Operations
1 Manager
1
1
on- Manager
- bonus
- mnuaiBudget
performance
{ if 3lanager.performancc is "poor",
then Manager-bonus m u t be zero 1
Constraint
The above example also illustrates the notations to express subrype relationships and
consaaints. As with EER,the OC data mode1 cm also be easily denved from a database's
class dia_=.
Chapter 6
6
Illustration of an Example Application using OCS
T k iilfûrrîlâüûii in L?S
xctiùn prcseriü
exaïpie àppEcatiun ihit iiiustrates Liic vuious
facets of the OC data model. and describes the implementation aspects of the OCS.OCS
is a package based on the OC data model that provides higher level abstractions for
manipulation of typed persistent categones. and for stable storage of objects. It uses Java
as the progamrning langage and 0bjectstore3 as the persistent store. Since the objective
of the thesis is rather to define a data model and prove that it is realizable, we used
ObjectStore as the repository manager. The public interface of OCS consists of a set of
operations rnostly oriented towards inserting and reuieving of objecü from categories.
The basic operations are operations that add. select, and rernove a single object. In
addition. we have included collection-oriented operations that do the sarne. It also
includes operations needed for creation and removal of categones. The system has also
implemented operations to dynamicaily add and/or remove relationships and other
consuaints from catepries. The nvo main classes of the OCS package are
ObjectCategory and Category. The ObjectCategory class is used to create and manipulate
categones, while the Category class is basicaily used to insert, retrieve and remove
objects. The system maintains references to al1 categones that are created.
-
-
-
ObjectStore is a registmd nademark of ObjstDerign Inc.
78
Chapter 6 - illustration with Example
79
6.1 The Application
Let us imagine we are developing a database for a University. The main players in a
University are the snidentr, ~ h profersors.
e
o
k s t ~ f memhers
f
znd the cclAnles cffe:eC
by the University. Usuaily courses have requirements. and they are divided into sections
and taught by different professors. Funhermore, some of the students work as teaching
assistants helping students and marking p d e s . The EER diagram for the database.
illustrated in figure 6.1. is composed of seven entities (Course, Section, Student. TA.
Staff. Professor and Employee). The relationships defined between the entities are:
a course has one or more required courses
a section belongs to a course. and a coune has many sections
a student takes one or more sections
a TA assists in only one section. and a section may have many TAS
a TA is a student as well as a staff
a professor teaches one or more sections
a professor is an employee
a staff is an employee
staff and professor are disjoint (not overlapping)
Chapter 6 - illustration with Example
80
requires
c
Course
Figure 6.1:
Partiai EER Diagram for a University Database
Ones we define the EER dia*-,
we need to decide and define the classes
and categories
to be created and maintained by the database. For this application. we define a class
(Course. Section, Student, TA, Professor, Staff, Employee) per entity. The Professor class
and the Staff class would be defined as subtypes of the Employee class. The TA class
would inherit from the Student class and the Employee class. For instance, using the Java
Chapter 6 - IlIusuation with Examde
progarnming language the definitions for Empioyee and Professor classes would look
like the following:
public class Employee
Scring
String
String
String
double
{
firstName;
las tNa,.ne ;
no ;
phone ;
salary;
Ehnployee (String no, String firstName,
S t r i n g lastName) {
tnis .no = no;
this.firstName = firstName;
this.7astNarne = 1astName;
p i b l i c void setphone (String phone) {
this.phone = phone; )
public String getPhone O { return phone; )
public void setsala-ry (StrLng salary) {
this.salary = salary; }
aublic double getsalary O { return salary;
a.
public class
String
String
Vector
Professor extends Employee
education;
tenure ;
sections ;
3rofessor (String no, String IastName,
String firstName) {
super (no, lasrName, f irstxane) ;
this-section = aew VectorO ;
{
}
Chapter 6 - Dlustration with Example
82
public void setEducation (String education) {
this-education= education; }
public String getEducation ( ) { return education;
gublic void setTenure (String tenure) {
this.tenure = tenure; )
public String getTenure ( ) { return tenure; }
public boolean addsection (Section section) {
sections.add (section); )
public boolean removeSectio3 (Secion section) {
sections.remove ( section) 1
}
The next step is to define the categones that will contain the objects. For this application.
we create one catepry
(Courses,Sections. Students, TAS, Professors, Staff. Employees)
for every class defined. The category hierarchy would resemble the subtyping hierarchy
between the classes. Therefore. the category for teactung assistants will be a subcategory
of the Studenü category and the Staffs category. In addition. the categories for staff and
professon will be subcategories of the Employees category. Using the category
specification langage listed in appendix A. for instance, the Employees category and the
Rofesson category are specified as follows:
category Employees {
extent s e t Ernpioyee indexekey employeeNo;
ernp loyeeNo;
category Prof e s s o r s extends m l o y e e s
:
extent s e t Professor;
relationshig one2Many Sections link sections inverse
professor;
1
Chapter 6 - nlustration with Example
83
The Employees category is defined as the container for objects of type Employee. The
collection will be indexed by employeeNo, which should be unique within the category.
The Professors category is defined as extending the Employees category. Therefore, al1
objects in the Professors category will automatically be members of the Employees
catepry, and the key constraint, employeeNo. defined on Employees category would also
apply to Professors category. Furthermore, the Professors category defines a relationship
with the Sections category through the sections and professor attributes found in the
Section and Rofessor class respective1y.
6.2 Defining Categories Using ObjectCategory Class
The OCS package provides the ObjectCategory class. which defines operations that are
not specific to any category. The operations are used to manage categories. They include
methods that add. get and remove categories. All the methods are s t a ~ cThe
. class
provides creureCategory(), getCarego-l) and removeCaregory() operations to create, get
and remove a category respectively. Since a Category instance is an object by itself it can
be stored in the database like any other object. The createCaregory operation requires
two arguments: category name and class type. An overloaded createCaregory operation
requires a third argument, an array of category names, that specifies the category's
supercategones. The operation raises a Catego~NumeAZrea&Exisrsexception if there
exists a category with the same name. The other two operations only require the
Chapter 6 - Dlustration with Example
84
category's name as ar-miment. They both raise the CategoryNameNatFound exception if a
carepry by that name could not be located. The class aiso defines static constants that are
used by the system. The removal of a category implies two rhings: removal of al1 objects
from the category and iü subcategories. and removal of the category and its subcategories
from the database's schema. For instance, using the ObjectCategory class we c m easily
define Employees. Sections and Professors categories as follows:
F u b l i c class Tes;CreateCacegory
{
..i / create zhe Empioyees category
C a t e g o r y ec = ObjectCategory.createCatego~(db,
"FmpIoyeesn, "Em-ployee")
;
create the P r o f e s s o r s category
Category pe = ObjectCategory.createCatego~(db,
"Professors", nProfessorn, "Emplyees");
/i
;/ create the Courses category
Category cc = ObjectCategory.createCategory(db,
"Coursesn, "Course");
The createCategoq(db. categor\;Name. className) method and its overloaded version
createCatego~(db.caregoryNnme, className. superCaregorieshiame create a persistent
category namzd caregoryName in the db database. The category is typed to c1acsNume
and inherits from the categories specified in superCategoriesName. Only instances of the
cl~ssiiiarneclass or its subclasses may be inserted into the category. A category groups
Chapter 6 - Illustration with Exarn~le
85
objecü of the same type (in the sense of the isInstanceOf() method of java.lang). The
method throws a Carego~NameAlreadyEristsErceprionif a category by the narne
categoryNmne already exists in the database. The argument db is a reference to the
database where the category is ro be created. The signatures of the methods
crearelalegory gel Caregory and deleteCategoy are as follow s: :
public static Category createCategory(Database db, String
categoryName, String className) throws
CotegoryNarneAlreadyExistsException
public static Category createCategory(Database db, String
categoryName, String classNarne, String
superCategoriesName) throws
CategoryNameAlreadyExistsExceptFon
public static Category getCategorv(Database &, String
categoryName) throws CategoryNotfou,??dException
public static void deleteCategory(Database db, String
categoryName) throws CategoryNotFoundExcepcion,
ConstraintViolationException
6.3 Data Manipulation
The Category class is the most important class of the sytem. It provides most of the
functionality required for &ta manipulation, including maintenance of the integnty
Chapter 6 - ïllustrauon with Example
6.3.1
86
Inserthg Objects
The Category class implements operations that are used to add objects to a category. Two
rnerhods are implemented: add (Object obj). which inserts a single object to the category.
and add(C01lecrion c) that adds a collection of objects.
public void add (Object obj ) tiirows
WrongObjectTypeException, ConstraintVio~a~ionException
public void add (Collection c ) throws
WrongObjectTypeException, ConstraintVio~ationExceptioc
Both methods check whether the object or objects in question are instances of an
acceptable class, and raise WrongObjectTypeExceprion if not. For instance. to insen a
new Rofessor object to the database we first get a reference to the category and cd1 the
add metfiod as follows:
public c l a s s TestAdd
{
*.
/ / Get a
Catego-T
handle to the %ofessors
category
pc = ObjectCategory.getCategory(db,
"Professors");
/ / C r e a t e a new Professor object
2 r o f e s s o r prf = new Profes~or(~Mark","Rider",~Phd");
/ / P.dd t h e o b j e c t to t h e Professors c a t e g o r y
pc .ad6 ( p r f 1 ;
Chapter 6 - Illustration with Example
87
63.2 Retrieving Object.
The system provides a mechanism for reuieving objects through queries or iterators.
Query is performed by passing a predicate expression as an argument to the selecr
operation of a category object.
p h l i c Set select (String predicate)
A category applies the predicate expression (an expression that evaluates to a boolean
result) to ail elements it contains. including objects in its subcategones. and returns a
collection of al1 objects for which the expression results m e . For instance. the following
example retrieves d l employees whose lasr narne is "Mark". Since Staff and Rofesson
are subcategories of Employees. the query would search in al1 three categories.
public class Testselect
{
a..
Category e m p = Ob j ectcategory . g e t c a t e g o r y (a,
"Employees") ;
Set marks = emp.select ("lastName == \"Mark\"")
;
If the sarne method were sent to the Professors category, it would search in the Professors
category only. The only requirement is that the attribue lasrName must be public. Ail
attributes and rnethods refened to in a predicate's expression must be public. If a method
is specified, then it rnust r e m something. The select rnethod returns a Ser thar contains
the objects that satisfy the predicate. If the category does not find any matchmg object, it
Chapter 6 - Illustration with Example
88
r e m s an empty Set. An equivalent get operation retrieves the first object thar satisfies
the predicate expression. If no object in the category satisfies the predicate. the method
returns null.
p u b l i c Object get (String predicate)
Objects can also be retrieved through the search operation. Search allows die user to find
an object without pnor knowledge of the its caregory membenhip. Cnlike the selecr and
ger operations, which retneve objects from the category receiving the message, the result
of search operation is the union of al1 objects of type classType that satisfy the predicate.
Al1 categories that store objects of type classType are searched.
public Set search (Class classType, String predicate)
The clussType pararnerer provides the context in which the predicate should be evahated.
The message c m be sent to any one of the categones in the database. For instance. the
following instruction retrieves al1 employees in the database whose last name is "Mark".
Public c l a s s TestSearch
{
...
Category std = Objec=Category.getCategory(db,
'Studencs" ) ;
Sec narks = siC.s e a r c h ( c l a s s . for?Jane ( "Enployee" ) ,
"lastName == \"Mark\"");
Chapter 6 - Illustration with E x m l e
89
It gets the sarne result as the above select instruction. However, it is not as fast as the
above one since it has to f i t determine the search strategy. To eliminate duplicates and
minimize processing, the progam first srarts anaiyzing the most specialized categories.
An alternative way of accessing objects in a category is dirough the Iterator ciass, which
helps navigate through the category's objects. The iteratorf)method of the Category ciass
retums a hande to an Iterator instance. The retumed Iterator object is an instance of the
OCIterator class thar is an irnplementation of the java.uti1.Iterator interface. Iteraton can
be used ro traverse categories as well as to remove objects from categories. The signature
is as follows:
For instance, the following code retrieves ail objects in the Employees category and
prints them to the standard output.
public class TestIterator <
p & l i c s t a t i c void main{String argv[j) {
*..
Iterator i t r = 0bjectCategory.getCatego-~(db,
"Employees") . iterator ( ) ;
w h i l e (itr.hasNext()){
Employee emp = (Employee) itr.nexc();
Syscem.out.println(emp.toString()) ;
1
Chapter 6 - Illustration with Example
90
6.3.3 Removing Objects
Removing objects is done through the operations of remove and removeA11. In both cases,
if the object being removed is not a member of any other category, it will automatically
be removed from the database. The operation removeAlU l removes al1 elements from the
category. However, it does not remove the category from the database. It only removes
the objects from the category. If the removal of an object violates a consrra.int. the
rnethods throw a ConstraintViolarionErceprionexception. The signatures of the remove
and removeAl1 methods are:
p u ~ l i c~ o o l e a nremove (Object obj) throws
ConstraintViolationException
public nooiean remove (Coliection c ) throws
Cons t r a i n W i o l a t i o n E x c e p t l o n
public 'Doolean removeAl1 ( ) throws
ConstraintViolationException
6.3.1
Modifying Objects
The system maintains the database's integrïty automatically as objects are added andfor
removed from categories. However, it is the user's responsibility to cal1 the update
method when a persistent object's memben are modified. The update method is needed
because OCS being a Library has no way to automatically detect when changes are made
ro an object. Furthemore, objects c m be members of more then one category. This
Chapter 6 - Illustration with E x m l e
91
means, whenever an object is modified, dl consuainü defined on al1 categories the object
is member of must be checked. OCS handles thîs by keeping. with each persistent object,
a list of the categories the object is member of. Whenever an object is inserted, modified
or deleted the list is consulted to make sure that al1 constraints are enforced. For example,
suppose professor Mark adds "~~95.501"
ro its list of courses. To make sure that the
database's consistency is rnaintained the application should cail the updare method as
follows:
P ~ b l i cclass Test'Jpdate
{
..a
P r o f e s s o r p r f = ( P r o f essor)
Obj e c t c a t e g o r y . g e t c a t e g o r y (db,n?rofessors'' ) .get ( last
Name == \ " M a r k i , " " );
Course crs = (Course)
ObjectCategory.getCategory(db, n C o u r ~ e ~ *get
l ' ) ("courseN
O == \"cs95.101\"");
p r f .addCourse ( c r s );
/ /cal1 update on the rnodif ied oDject
prf .update();
The updare method is defined in the OCPenistent class descnbed in section 6.5.
There are different mechanisms to enforce integrity constraints on a database. Some
special integrity consaaints could be supported automaticaily by the system whereas
Chapter 6 - Illustration with Example
92
othen can be added to the database through a mechanism that dlows users to express and
enforce new integnty rules. Constraints could be violated only by operations that modify
the state of the database (updates, inserts and deletes). An object's operation is said to
satisfy its constraints if its insertion, modification or removal does not violate the
integnty of the database. Such operation is said to be le& OCS provides facilities to
specify and enforce referential integnties. keys. domain integnty constraints and tri,,ouers.
6.4.1 Defining Relationships
Relationships are a special case of constraints cdled referential integnty constraints.
Referential integnty constraints are one of the most imponant and most frequently used
rnechanisms for maintaining a database's integnty. The purpose of referential integnty
constraints is to indicate that a reference to an objecr is legai only if the referenced object
exists in a particular collection. For example, a referential integnty constra.int between the
Sections category and the Professon category could be that, the professor attribute for a
coune object should be limited to one of the professors in Professors catepry. The
inverse is, that any section in the S
~ C ~ attribute
U ~ S of
a professor object must be a
member of the Sections category.
Referentiai integrity constraints are enforced by the system with a liale input from the
user. The user's responsibility is limited to specify the nlated categories and the
Chapter 6 - Illustration with Exam~le
93
attributes through which they are related. Relationships are defined between categories.
Only binary relationships are supponed. The amibute on the many side of a relationship
should always be of type Collection or one of its subclasses. Four classes that represent
the four types of relationships that are commonly used are implemented: one-to-one, one
to-many. many-to-one. and many-to-many. The following is a panial listing of the
Relationship class.
public class Relationshig {
orivate String name;
grivate int type;
private String attribuceName;
private string relatedCategoryName;
private String inverseAttributeName;
Relationshio (String nm, i n t type, String atrrun,
String rcn, Strlng i n v - a t m ) {
this.name = nm;
A category can be related to more than one category. One instance of the Relationship
class is maintained for each of the relationships the category is involved in. The
relationship type is consuained to be OneIOne, OneZMany, ManyîOne or iMany2Many.
The constants are defined in the ObjectCategory class. The components are passed as
arguments to the addRelationship method.
public void addRelatioaship (String relationshipName, i n t
relationshipType, String ~ t t r i b u t ~ a m eString
,
Chapter 6 - Illusmtion with Example
94
relatedCategoryName, String inverseAttributeName)
throws, RelationshipNameAlreadyExistsException,
RelationshipAlreadyExistsException
For instance, the following statement declares a one-to-many relationshp named R S e c
between the Professors category and the Sections category through the inverse atrributes
of sections and professor.
public c l a s s Tes tRelationship
{
a..
/ / Get a handle to tne Professors category
Category pc = ObjectCategory.gecCategory(db,
" Prof essors.') ;
/ / EstanLisi., relationship
with the Seccions catego-ry
pc . addPeLationship ( " Pr-Sec" , Objectcateçory .OrieSMany,
"seczions", "Sections", "professor");
Relationships need to be specified only once. The system inserts and/or removes die
inverse pan of the relationshp autornatically. For instance, the relationship between
Sections and Professors categories need be specified only once. either through the
Sections category or the Professon category. Relationships are uniquely identified by
their names, which is used as the only argument to the removeRelarionship method.
public void removeRelationship (String relationshipName)
throws RelationshipNotFouridException
The above inserted relationship is removed from the database with the following
staternent:
Chapter 6 - Illustration with Example
95
...
0bjectCategory.getCatego-ry (db,
" P r o f essors " ) . removeRelationship ( " Pr-Crs
)
There are other four relahonship-related classes irnplemented by the system:
Relationship 131, Relationshipl2M. RelationshipMZ 1 and RelationshipM2M. Thev
correspond to the four types of relationship the system supports. They ail implement the
Relationshiphterface interface. Whenever required, the system dynarnically creates an
instance object of the right relationship class and calls the object's validate method.
6.42 Defining Keys
Keys are relevant for any DBMS that uses collections. They allow objects to be uniqueiy
identified given the values andor States of one or more of their attributes. OODBMSs use
object identities to uniquely identify objects. However. those identities are usually hidden
from the user. OCS offen a mechanism to add and remove keys From categones. Keys in
a category are uniquely identified by their narnes. They can consist of one or more
attributes. The addKey method is used to add a key consuaint to a category.
public void addKey (String keyName, String[]
atrributrnames
chrows KeyNarneAlreadyExistsException
The method takes as arguments the narne of the key, which shouid be unique within a
category, and an array of attribute names. Only attributes that are defined by the
Chapter 6 - Illustration with Example
96
contained class are accepted. Attributes that are part of the key should al1 be publicly
accessible. The removeKey method is used to remove a key from a category.
public v o l 6 removeKey (Stricg keyName) zhrows
KeyNo tCouncIExc ep tion
For instance. to make sure that the ernployees' no is unique through the database we
define a key on the Employees category with the attribue employeeNo thar is defined in
the Employee class.
public c l a s s T e s t K e y
{
.*
String!] keyAttributes = {"employeeNou};
0bjectCategory.getCategory (db,
" b ~ l o y e e s ".acdKey("BnployeeNumber",
)
keyAttributes);
From now on. the system makes sure thar that the employeehio is always unique when an
employee is inserted to Employees, Staff or Professors categories. or when an employee
object is updated. The system uses Java's reflection API to dynarnically retrieve amibute
values.
6.4.3
Generai Purpose Constraint Definition
Keeping faith with the objective of the thesis, a new and general mechanism of defining
constraints has k e n implemented. A consaaint is implemented as a class definition that
implements the Constrainhterface interface. The interface defines the only method that
Cha~ter6 - Uustration with E x a m ~ k
97
has to be implemented by conscra.int classes, validare (object, when). The parameter
objecr is a reference to the object in question. The parameter when contains a value that
specifies the current phase in the object's processing. The current phase could be
Before-Insen, rifre-sen,
Before-Remove, etc. The constants are defined in the
ObjectCatgory class.
public void validate (Obj ect ob j ect, i n t when) throws
ConstraintViolationException.
X consuaint is a predicate that has to be complied with by di objects in the category. A
constraint could range from a simple domain check. like the fact that an employee's
salary has to be above or equd to some minimum salary, to a more complicated one, like
conditional constraint. Because a constraint is a full-fledged object by itself, its definition
is not lirnited by the expression construction rules of the DBMS.The special case of NOT
hWLL consuaint cm easily be enforced using dus general mechanism.For each
consuaint. a class that implements the Constrainthterface interface should be defined.
Once it is defined. the oddConsrrainr method should be invoked against the category
where the constraint is to be enforced.
p a b l i c void addCons traint ( S t r h g constName, S t r i n g
className, i n t when) throws
Cor,strainiNameAlreadyExistsExceptior,
The parameten are the constraint's name, the name of the class that defines the constraint
and timing. The method raises a ConsnaintNameAlre~EristsErcep~n
exception if die
Chapter 6 - Illustration with Example
98
constraint set of the category aiready includes a constraint by the name specified. Every
tirne an object is added to the category, or whenever an object that is already in the
category is modified or removed, the system, at run time, creates a new instance of the
consuaint class and calls its validate method. The validate rnethod of a consuaint object
should raise a ConstrainfViolarionExceptionto notify the system that a constraint has
been violated. For instance, to enforce the constraint that an employee's salary should not
be less than the minimum salary. let us say $7.00 an hour, we first define a class that
implements the ConstraintIncerface interface.
public ciass MinSalaryConstraint implemenis
ConstraintInterface {
S.
i,/ implement the validate rnethod tnat will
/ / autonatical& be calieo by the system
p u ~ l i cvalidate (Object obj , int timing) throws
ConstraintViolationException {
. - (((Emp1oyee)obj)
ï
.getSalary() < 7 . 0 )
throw n e w ConstraintViolaïionE~cep~ion(~~Salary
can
n o t 'De less than sevenn)
1
.%€ter compiling the above class. we register the b i n q file with a specific category by
calling the addconsuaint. For instance, if we want to apply the consuaint to ail
employees then we send the message to the Employees category as follows:
Chapter 6 - Illustration with Example
99
The system stores the constraint's name, the constraint's class name and the timing
information only. Ones the constraint is added to the category. whenever needed the
system dynamically creates an instance of the class MinSalaryConstraint and calls its
validare method passing the object to be checked as an argument.It also traps the
ConstraintViolationE~ceptzonthrown by the MinSalaryConsuaint object, which it passes
to the user's process. The sarne constraint can be insened into different categories. or
added to the same category with different name and timing.The only restriction is that
the constraint's narne within a category should be unique. The rernoveConsrrainr method
removes a constraint from a category. if the constraint in question is not found. the
method raises a ConstraintNotFoundException exceprion.
p b l i c void removeConstraint (String consrname) throws
ConstraintNotFoundException
Triggen. like constraints. are objects by themseives. Therefore, they allow us to enforce
integrity rules that are not automatically enforced by the system. A trigger is always
associated with a constraint in a category, and it is fired whenever the constraint
evaiuates to tme. A constraint is said to evaiuate to true if it raises a
Chapter 6 - illustration with E x m l e
100
ConstraintVioZarionLrception exception. The TriggerInterface defines the only method
that has to be implemented by trigger classes:
p u b l i c void fire (Object o b j ) throws
ObjectCategoryExcepcio~
The operations addTrigger and removelrigger are used to add and remove a trigger
respectively. A tngger can be associared with a constraint that has already been added to
a category. Xltematively, the tngger and the consuaint can be inserted to a category at
the same tirne. The uigger execution mechanism is basically the same to the one used for
constraints. However. before the tngger is fired the system makes sure that the constraint
anached to it raises a ConstraintVioiationException.Triggers within a category are
uniquely identified by heir name. Assuming that we have already defined a uigger class
called SetMinimumSaIary, the following instruction attaches the above-definedconstraint
MinSalaryConsaaint with the SetMmimumSalary uigger, and registers it with the
Ernployees categoq.
O b j ecrcategory .getcategory (db,
"Zmployees") .addTrigger ( " R e c t i f y M i n i m m % h r y n
"SetMi,?imumSalaryN, "MinSalary",
0bjectCategory.Before-t'pdate)
Chapter 6 - illustration with Exam~le
6.5
101
-
Defining Persistent Classes OCPersistent Class
As rnentioned above, OCS has no way to automatically detect when changes are made to
an object. The OCPenistent class defines the annbutes and methods that are required by
the system for penistent objecr manipulation. Ai1 penistent classes must inherit from the
OCPersistent class. The class defines an atuibute. mernbershp. and a set of methods.
From the user's point of view the two important methods are the no-argument consmictor
and the updare method. The updare method is used by the user to notsfy the system of
modifications made to persistent objects. The following is a partid listing of the
OCPersistent class.
public abstzacc class OC?ersisten=
private OSVector x ~ ~ b e r s h i p
public OCPersistent()
rhis.menbership = new OSVectox();
1
public final void update ) throws
ConstraintViolationException (
Chapter 7
7 Conclusion
OODBMSs have corne a long way fwni a simple mechlnism fer ~ h estrr-gt
r e ~ ~ c ~ d
of penistenr objects to a DBMS with many of the facilities that are required by an
OODBMS. However, their development and acceptance have been hindered by many
factors. The lack of a standard data model which makes them harder to leam and use. and
the fact that they are targeted towards a specific set of applications have been two of the
major limitations of OODBMSs.Their target area. the "new" applications. excludes the
larpst usen of databases: traditionai business applicauons. However. in the long mn
there is a need for single database systems that satisfy al1 kinds of a company's database
requirements. Few applications fit neatly into just one category [l].
Current implementations of OODBMS are based on the concept of the 00 data model.
The 00 data model is not characterized by niles that define the structure, vdid
operations and constraints on the context of databases. Therefore. curent OODBMSs are
rather characterized by the underlying 00 progamming langage upon which their
implementation is based and by the target application. A new data model is required for
new kind of DBMS: A DBMS that is not application-oriented, and inregrates the best
features of DBMS technology with the 00 concepts.
Cha~ter7 - Conclusion
103
This thesis attempted to achieve the above objectives by defining a new data model,
Object Category data rnodel. that is independent of progamming languages and adheres
to the 00 concepts alrnost al1 OODBMSs agee on. The main characteristics of the data
model are:
It introduces a new concept, category, and it distinguishes it from the concept of
class. A class represents the set of al1 possible instances. while a category is a
collection of actual instances of a class in a database. It also defines operations on
categories.
It is fully 00. because it suppons the 00 concepts as they are used by 00
progarnrning ianguaps.
It can easily be denved from the EER data model.
Ir makes a clear distinction between class definition and integnty constraints.
Integrity consuaints, including relationships, are defined against categories.
This layered approach, separation of application aspects from database aspects, provides
increased data independence and flexible design approach. The seamless integration of
pro,oramming languages with DBMSs. as preferable as it is, should not corne at the
expense of core advantaps that are usudly expected from a DBMS:data independence.
progamming language independence, etc. Different programming languaps support
àifferent type construction facilities. Therefore. the tighter a DBMS is to a progamming
Chapter 7 - Conclusion
104
language the further it is from the other propmming languages. Databases based on the
same data model should provide the same interface independently of their
implementation programming language and independendy of the programming language
used to develop the application. Objects in a database that is based on the OC data model
are organized as memben of categories. The use of category by the OC data model
provides the usen with a clear and consistent view of the databases. It also lends itself to
the use of a query language much similar to the way SQL is used by relational systems.
Categories are the only entry points to the darabase. Funhermore, the Category interface
is provided with operations that are used for insertion. retrievai and removal of objects as
well as inte-gity consuaints.
The thesis defined a new way of executing queries that is in sink with the 00 nature of
the data modei. It also outlined a framework for a DBMS that is based on the OC data
mode1 and addressed the issues that need to be taken into consideration for its
impiementation. The architecture uses the client/server paradigm. and it divides the
server side of the system into two major parts: object manager and storag manager. The
storage manager deals with low Ievel disk Il0 operations. The object manager is
composed of different submodules that perfom specific tasks iike transaction,
concurrency control, etc. Objects in a dalabase based on the OC data model are uniquely
identified by their identities. The object manager translates the objects' representation
fiom in-memory address to oid and vice versa. A mechanism for a transparent access of
Chapter 7 - Conclusion
105
penistent categories as if they were in the main memory was also addressed. Two major
issues were discussed: buffering mechanism and transactional access of objects in the
database. The buffenng mechanism deals with the uansparent flow of data from
persistent categories to memory based container classes and vice versa. It was also noted
that although usen access objects in penistent categories as if they were the only uses
and as if rhey have an exclusive access to it, objects in categories are subject to
concurrent access by multiple usen. As such, a concurrency conml mechanism is
required to prevent consistency probiems. The mechanisrn takes into consideration the
complex nature of objects and the problem of obsolete cache.
We also discussed some aspects of the ODMG data mode1 in contrast to the OC data
model. Finally we illusuated the OC data model by describing an example application
that uses the OCS package. OCS is a Java implementation package of the OC data model.
The package includes the ObjectCategory class that provides facilities to create, get and
remove categones from databases. A Category class rhat implements the
Categoryhrerface interface is also provided. The interface defines the operations that
allow usen to insen, retrieve and delete objects. It also provides methods that are used to
specify constraints. whch are automatically maintained by the system. Four kinds of
constraints are supported by the system. Constraints and triggen are defined as classes
allowing the user to specify and enforce almost dl kinds of constrainü. The system aiso
Chapter 7 - Conclusion
106
suppons the four kinds of relaûonshps: one-to-one, one-to-many-, many-to-one. and
many-to-man y, and key constraints.
7.1 Future Work
OODBMS technology is a relatively new entrant to the DBMS field. As a new area, it is
almost impossible ro list d l aspects of OODBMS that need further research. There is not
even a univenally agreed and uniform use of the term OODBMS. In fact. there is very
little m e consensus and much disagreement. even at the most basic level [8].Therefore,
we will list only those aspects that are very important to the completeness and
improvement of the OC data model.
7.1.1
Query Optîmization
Because of the way relationships between objects in categones are maintained, dirough
direct pointers, andor because different users rnay have different points of view when
looking at a database's schema, queries can be specified in different ways. For example,
to retrieve employees who work for a certain depamnent we could send the request to:
1. Employees category. This would require a traversal through al1 the employees. unless
the Employees category maintains an index on depamnent attnbute.
2. Departments category. This would require fint locating the depamnent, which is
faster, then retrieving the employees following its links.
Chapter 7 - Conclusion
The question is how could a que.
107
optimizer rransform the inefficient form of a query
into the correspondmg efficient one. Unlike the relational model. in which relationships
are rnaintained dirough key and foreign key attribue values. relationships between
objects are established and maintained through direct pointers between participating
objects. The user or the DBMS can exploit t h s aspect of the relationships for query
optimization. It is Our belief that, because of the organization of objects through
categones (as tables are used in relational systerns) query optimization methods used by
relational systems could easily be adapted and used by DBMSs based on the OC data
model. In addition. pnor knowledge of the schema and the way the database is organized
can be used to optimize queries.
7.12
Object Migration
An object in OODBMSs is an instance of a certain ciass that is defined by the application
program. .-Zn object has identity that stays the same through the object's lifeùrne.
However. in the real-world applications, objects do noi always belong to the sarne goup
of objects. For instance, in a company's organirational hierarchy a secretary could, in the
future. becorne a manager. 00 d a ~ amodel does not allow such change of type. The
mikgration of an object from one group to another without changing its identity, is an
important aspect that should be supported by OODBMSs. The OC data mode1 inherently
Chapter 7 - Conclusion
108
supports some level of object migration by virtue of separaion of object definition from
constraints. Most of the times object migration is required to accommodate changes on
constraints that must be enforced to one goup but not to others. For instance. a
distinction between an employee object and a manager object might be, that the manager
object should be related to a department through the attribute manages. The OC data
model supports a Iimited object migration capability without type change. However,
because of its importance. there is a need for an in-depth research on this area. The
research could focus on object migration in p e r d and in particular in the context of OC
data model.
7.1.3 Views
Views are a very essential part of DBMSs based on relational model. Views. in addition
to data independence, 'provide different applications with different views of the same
database. The tight integration of programming languages and DBMSs,as useful and
attractive as it is, raises some important questions. In particular. an application program
(by definition) is intended to solve some specific problem, whereas a database (by
definition) is intended to solve a variety of different problems, some of w h c h rnight not
even be known at the time the database is established [8]. Views are the result of
requesü to the database ihrough predicate expressions and quefies that are permanently
remembered. îhey allow us to define different extemal views for different usen, and
Chapter 7 - Conclusion
109
lirnit their access to the database. An enhancement to the application level interface could
be to complement it with a view definition and manipulation mechanism.
Category Specification Language (CSL)
category <category_name>
extends ecategory-narne- lis^
set cclass-name> [ eaccess-mode> ]
the name of one of the indexing methods provided
by the DBMS
Annex A - CSL
111
the oame of one of the hashing functions provided
by the DB-MS
dist-declaration>
<clas-name>
corder-decl aration>
corder-lis<attri bute-name>
corder>
ASC ) DESC
array-dec laration>
array eclass-name> cattri bute-list>
uelationship-declaration~
relationship aelationship-type>
aelated-category-name>
link <atmbute-name> inverse
erelated-attri bute-nanie>
< relationship-type >
key cattribute-lis>
Annex A - CSL
dgger-name>
aarne>
cwhen>
before 1 after
<name>
<alpha> [ <string> ]
<string>
Ccharacten [ smng ]
cc haracter>
c a i p h ~1 <&@D 1 csymbols>
<alpha>
apper-case-lettep 1 clowe-case-letten
cupper-case-letter,
upper case leeter from A to Z
dower-case-letters>
lower case letters frorn a to z
<di@
decimal digits from O to 9
<sysmbol>
my other symbol rhat could be part of a name
OCS Code Source
i ne
LC1
ûbjec tCacegory impiemencs [ne s w i c meriiocis thar creare, remeve and remove
categories from a database. It also defines some constants that are used throughout the
package.
package ocs .oc ;
corn. odi.*;
static
static
static
static
güjlic static
public static
sublic
sublic
public
public
public
public
puhiic
public
static
static
static
static
final rn: Jefore-Izsert = I;
f 3 a l ixc Afser-fnsert = 2;
fizal in= Before-Xodify = 3;
finai iat After-Modify = 4;
final int Jefore-Reiove = 5;
final ia= Afcer-3emove = 6 ;
fical
fical
fical
fxal
i2= One20ne = I;
13= One2Mafiy = 2 ;
i3= Many20ne = 3 ;
int Many2Many = 4;
i : tke variable tka= contaics al:
stacic Cacegories ca=eçcries;
the categories in the dacabase
/ / creates ~ h root
e
ectry to the database
s t a c i c Caïegoriss InitiaLite (DataDase db) <
E
gets =Re r o o c o ~ j e c tof al1 :Be categorles
categories = (Cacegories) db.get3oot("Category0fCa=e~oriesn);
retc,r, cazegories;
1
catch (Databasei3ootNo~Fo~dZxception
e) {
/ / creates the root a b j e c c if it doesn't exisc
:'/
Annex B - Code Source
114
categories = new Categories ( ) ;
db.createRoot(nCategoryOfCategories". categories);
retu-m caregories;
," roiUrEs a l 1 ca=egories Ln =he database
scaric Categories getcacegories (3atabase db) {
try !
categories = {Categor~es)
cb.get300t("Ca:egoryOfCategoriesn);
retz-Tn cateçories;
1
cacck ( 3 a c a ~ a s e R o o t ~ o t ~ o ~ ~ d E x c ee p) t{i o ~
ret2rn initialize( & ) ;
: / creaces a new category and returns i
:
public scaiic Category createCa~egory(Da=aDase
65, StrLxg
categoryNarte, String ciassName1 throws
CategoryNarneAlreadyExistsExceptioc (
Category ct = new Cacegory (categoryName, className);
getca~ecories(db).add(ct);
recurr, cc;
i
public static Carego-y createCatego,-y(3a:ajase
db, Strizg catego-zyXane,
Stricg className , Stricg s~~erCa=egoriesNaiie)
ïhrows
CategoryNam~~lreadyExistsExcep=ion
[
Caiego-y ct = new Cateçory (ca=egoryName,className,
superCacegoriesName ;
geccategories ( d 3 ).ado(c=);
retrrrr. ct;
a category Dy zarie ar.a retwms a hacàle to it
Category geicategory (Database
Stri2g categoryNm.e)
zhrows Ca~egoryNocSoundExce~ion(
r e t x r c getcazeçories (db). get (cacego~yName)
;
*,
.
/ / rernoves a catego-y from t h e &tabase
public static voiâ âeleceCategory(Database db, String categoryName)
tkrows ConstraintViola~ionZxcegtion~
~eferentialIr,tegri~yVi01ationExceptior,,Catego-ryNotFom&Bcception {
getCateçories(33).deIete(categoryName);
1
Annex B - Code Source
115
The Categoryhterface interface specifies the methods that are to be implemented by the
Category class.
package
public interface CategoryI~terface
/ / Accessory netnoàs
Scring getName ( ;
v o i d setName(Sïring name) ;
S -,
V,
;,ng getClassEame ( ) ;
C l a s s getClassType ( ) chrows
:! acXs é a o b j e c c O
:
~ h ecategory
gublic 3ooleaiz add (Objecz o8j )
EYrows WrongODjectTypeSxception, C o n s ~ r a i n t V i o l a z i o n & c e p t i o n ;
:!,
acCs a collecclon of objects = O :he categorf
gcblic boolean ad6 (Collecrior. c) throws W r o ~ g Q b j e c t ? ~ ~ e Z ~ c e p c i o c ,
ConstraintViolatio~Zxception;
/ / re3oves ar o ~ j e c t from :ne category
guDlic 3oolean rkqove (08j e c t on3 ) throws
Co~szraiztViolationException;
/ i renoves :rom the category, 211 objeczs in c (airference)
9ublic joolean renove (Coilection c ) = k o w s
Cocs~raictVio7atio~Exception;
:/ removes a l 1 objeccs from :ne category
public void removeAl10 throws CozstraintVioiation%ceptioc;
/ / r e t a i ~ so n l y elenents i n c ( I n t e r s e c t i o n )
public joolean retairrAll (Collection c chrows
Constzai~tViolatioc~ception;
;/ retrieves the f i r s t o ~ j e c tchat s a t ~ s f i e stke precicate
gunlic Object geï(String predicate);
:.' retrieves al1 the oDiects tkat sacisfy tke preCicate
gublic Set select ( S t r i c g greaicate);
/ / retu--ns ar, iterator for t3e ~~~~~~~zy
gxbiic Iteraîor irerator0 ;
Annex B - Code Source
//
/!
s&lic
wnen )
methods to add and remove incegrity constraints
aads a coascraict
void addconstraict (String cozstName, String className,
t h r o w s Cons t r a i n t N a m e i S 1 r e a d y 3 I s i s E x c e p ioc
~ ;
/: adds a k e y
public vois adciKey (String keySame, Stricg[: aztrikctesj
throws KeyNameAlreaay~istsExceptiorr;
puDlic void rm.oveXey
(
Stricg KeyName ) chrows XeyNorFo~~dZxcept
io3;
/ / adas a relacionsnip between two categories
public void aC?dRelationship (String relationskipName, int r e l m e ,
String attzName, String caïNaiie, Strizg irxAcrNa,~ce) Ehrows
3elatiocshipN~~~ireadyExistçExcepcio~,
RelationshipAlreaàyFxistsException;
, t removes a
catego-ry * /
/
relationship from a c a t e g o r y a2B f r o ~cke zeiazoc
~ Ü S l i cvoid rernoveReiationshlp (Scrirg reiaiiocskipNme) throws
3elatiocs~ipNot?ou1:~Fxceptior:;
/ / addç a new trigger and a zew assoc~atedconstrainc
gublic voie acdTrigger (Srring criggerWasne, String trClossName, S ~ r i z g
cClassNane, int whez) =hrows Tri~gerNmeAlreaay~istsZxcsption;
! * adds a new trigger and associates it with a_r? exisiizg
cmstraint * /
p ~ i i cvoid a4dTrigger (String x i g g e r N m e , String trClassName, S t r m g
c o n s c r a i ~ ~ X a m ethrows C o ~ s t r a i ~ ~ N u t ~ o ~ ~ ~ d E x ,c e p t i o z
TriggerNmeAireacyFxistsException;
/
rerncves a t r i g g e r
public void removeTrigger (String triggerNaine) tkrowç
Tr l g g e r N o ~ F o u n ~ c e p t i o n ;
/
cnecks if the categorf incluCes the o ~ j e c t
public boolear, contains(0bject o b j ) ;
!/ r e t u m s the nümbsr 05 o ~ j e c t sin the category
gublic int s l z e 0 ;
hnex
B - Code Source
117
The Key class specifies the amibutes that make up a key object. It uses the methods of
java.1ang.reflect to dynamically mate the predicate WC!
evaluate the query.
package ocs.oc;
import
pablic class K e y
{
:: t h e c o n s c r x t o r acce9:s Che s e y ' s n m e acc izs a = = r i ~ c t e s
Key (String name, S = r l n g [ ; ai:ribütes)
(
this.name = zane;
t h i s . a ~ t r i 8 ~ ~=e sattri8uces;
/ / u t i l i t y rne~hoas
String getNa.ne0 E r e t u r n =kis.mme; i
String: 1 ç e t A t t r i ~ ~ t (e) s { retu-zn zhis. attri5utes;
}
/ : checks f o r d ~ p l i c a s ekey
void checkKey ( C a t e g o q c l Object o ~ ,j irx w h e ~ i t h r o w s
ConstraFntViolarionExceptior?, OnjectCategoryExceptior? {
String predicate =
java.lmg. ref l e c t .F i e l d fld;
O b j e c t atrvalue;
FreeVariables vars = new ? r e e V a r i a D l e s ( ) ; ;
FreeVariaDleBindings 5inùicgs = new FreeVariableBindiags();
for ( i n t i = O ; i<attributes.length-1; i-+) {
greâicate = predicate
"(*
a t t r i ~ u t e s [ i ] " == "
fv-* +atrr;
,,,butes Li] + " ) && " ;
-
-
-
7
'cry I
E l 6 = ( c . getClassType ( ) 1 . g e t ? i e l d ( a t t r i b u ~ eCi]
s )
vars . p u t ( " fv-" -at=ziDutes;ij, f ld.geïType ( ) ) ;
;
,
catch (NoS~chFieldZxceptio~
e) {
Enrow new ObjectCatego,-y%cepti~n(~Unexpectea e x c e p t i o n i n key:
toString( +
+ e. t o S t r F c g 0 ) ;
1
tw
-
Annex B - Code Source
atrValue = f ld. gec (obj ) ;
Sindings.putInfv-"tattribctes[il, atrvalue) ;
1
catch (IllegaiAccessException el i
+
zhrow new Objec~Catego~y~ception(~Unexpecteci
exceprio2 ic key:
roString0 + " \ r i n + e . z o S t r i z q 0 ) ;
1
1
precicate = predicate
" ("
attribu:es[at=ribute~.1engtf=-1I
" ==
n
n,~to
f a *-* --; -----k~itac
' e - r r - à - ' -.
'
m i n .
-R , a- t-r--r i '-----c .- -***a
,
,
=-Y C
-..
= l a = (c.getClass~eO).getFie1d(attributes~aztrib~tes.~eng~h-~~!;
vars.put("fv-"-actri5utes~atzribute~.lengt-,fld.getrype0);
-
7
"fy7
-
-*-
-
-
P
c a x h (XoSxhFieldException e ) {
throw zew ObjectCatego~~Fxception~"Ur?expec~ec
exception I n Key:
=zy ':
aczValue = flS.get(obj);
bindi~g~.put(*fv-~-at~ri5~tes~tributes.~e~gth-~~,
1
catch (IllegalAccesslxception el C
t h r o w r s w Objec~CategoryExceptlon(~'Jnexpec=ed
exception ix key:
i
/ / check if there is a duplicate
Guery q = new Q u e r y ( c . g e ï C l a s s m e 0 , precicate, vars
Set resclc = q.select(c.ge~lli),b i n d i n g s ) ;
Dooleon rsunique = t r - ~ e ;
switch(whea) 1
case ObjectCatego-y.3efore-Insert:
if (result.size(! > O )
isUniwe = f a i s e ;
3reak;
;
case Obj e c t c a t e g o r .~A f ter-XoCify :
if ( r e ç u l ï .size ( ) >l)
isUnique = false;
break;
1
if ( ! i s u n i q d e l I
String nsg = "Key violaziox Excepcion 13 k e y :
vicïazed by: *
o~j.toS=ringO) ;
z k o w xew C o r i s t r a i n = V L o i a t i o r , ~ c e p t i o n ( m s q ) ;
1
1
:
-
coStrlcg0
Annex B - Code Source
119
A Constraint objects specifies the constraint's narne, the name of the class that defines it,
and when to check. The Constraint class dynarnically instantiates an object of type
"constClassName", w h c h implements the Constrainthterface interface, and invokes the
object's validnre method.
package ocs.oc;
import com.odi.*;
gcblic class Constraint
{
private String 2arr.e;
private Stri2g co~stClassName;
private int whec;
.', the conscxczor
Constzaiac (String cane, S t r i n s className, i n = wnen) E
=his.name = nane:
this.constClassName = classNarr,e;
ç
r
.when = wker.;
r.
b
i / rzility mechoas
Striag getNalie ( ) { returr? zhis .name; )
ict get*.en( ) ( retu,~. this.wnes; )
String gecClassName ( ) C recurn z h i s .constClassKa.lie;
i* icstaztiates d'? object of cype "constClassNameR and invokes
its v a i i d a t e nethoci * /
vois check(0bject obj, i n t when) throws ConstraintViolationException,
O5jec tCaïego,yExcep t ~ O I I {
Class cc;
ConstraintInterface ci;
cc = Class.forName(t3is.getClassNameO ) ;
J
catck (ClassNotFou,r:dZxceptior, e ) {
String msg = "Unexpeccec5 exception in c o n s c r a i z t : "
"\zn+ e . ïoString(1 ;
t k r o w zew 38jectCategorry~ceptio~(msgi;
toStrinç0
+
Annex B - Code Source
120
catch ( I l l e g a U c c e s s ~ c e p t i o ne) {
String m g = "Unexpecced exception in cocstraint: "
" \ n n + e.ïoString0;
tkirow new Ob jectCategoryException(nsg) ;
catch ( C ~ s t m t i a t i o n ~ c e p t i oel~ .{
Siring m g = "Unexpected exception in conscraint: "
" \ n w + e. toString ( 1 ;
throw new Obj ectCacego,ryExcep'cio~~
( m g );
+
-
ioString0 +
:oString() +
t
ci.vali&ate(obj, when);
1
The Consuainthterface defines the only method that is to be impiemented by user
defined Constra.int classes.
gac kage ocs .oc ;
public i z t e r f a c e Cons=raint:nterface
{
/ / the netnod accepts and validates =he oDjec:
p u l i c void validate(0bjec: obj, int when) throws
ConstraintViola~ionException;
1
A Relationship object defines the attributes through whch two catejones are! related. It
also indicates the type of the relationship ro be created.
irnport cor.. odi . * ;
pzblic ciass Rela~ionsnis {
private
private
pzrvate
prlvate
prlvate
S ~ r i n g= m e ;
ict type;
Scring attriButeName;
Szring reiatedCategoryNane;
String FnverseAtsrFbute!Ya,me;
:/ i~verserelat i o n s h i p tyge
Annex B - Code Source
121
static I n t inverseTyps(inc type) {
swicch (type) {
case ObjeccCatego-ry.One2One:
return ObjectCaîegory.O~e20ne;
case ObjecKacegory.One2Many:
return Objectcaiegory .Muy20r.e;
case ObjectCategory .Many20ne:
r e t u r n Objectcatego-y. One2Maqy;
case ObjeccCaïego,ry.Na,ny2Many:
return O b j e c t C a c e a o ~ . X a ~ y 2 M a ~ y :
;'/ the constrictor
!telationship(Stringname, rnï type, String atrNa,-elString catNa,?r.e,
String invAtrXame) C
this.mme = name;
this-tyye = t m e ;
this .relatedCategoryNaiie = catNarne ;
this .lnverseActribiteName = icvAtrNane;
1
;/ x t i l i ~ yrnethods
Strizg getNme( 1 { returc this .name; i
in= getType( : recürn tkis.=ype; :
String gecAccributeNaie0 iretu? chis.ac=ribuceName; 1
Stricg getReiatedCategoryName0 : r e t q x n tkis.rela~eàCa:egoryName; 1
Strixg getI~vers~~:trLbuteNmeO{returc this.ir,verseAttributeNm.e;
=he aecnod chec~sthe :me of relatior-ship, instantla=es a2
o~jectof the XelationshipInterface type, aza icvokes i t s
v a l i d a c s metnod.
void validateInverse (Objecc obj , i n t * k e n ) :hrows
C o n s t r a i n t V i o l a t i o n ~ c e p t i o ci
Relationshi?Interface ri;
s w i ~ c h (type) {
case 0BjectCacegory.OneSOne:
ri = new 3elatFonsniplSl(oOj, whec,
break;
case ObjectCategory.3ne2Many:
ri = new XelationshiplSM (onj, wnec,
1'
*./
break;
case ObjeccCatego-zy.Yany20ce:
ri = new 3elationshipM2l(o~j,
wnec,
8reak;
case Ob j ec Kacego-ry .Macy2Yany:
ri = new Xelacior~hipM2MIobj,
when,
break;
1
}
Annex B - Code Source
122
The Relationshiphterface interface defines the only method that is implemented by the
different implementations.
package ocs.oc;
i n c e r f ace RelationshipIr-ter face
E
: zhe nethod checks =ne zef erencial integrity
voi6 validaze0 t h o w s Constraiz=ViolationExcepcio~;
:'
1
A Trigger object specifies the txigger's name, the user-defined class that implements it
and the Constraint object it is associared with. The class dynamically creates an instance
of "classhne" and invokes its fire method.
sackage ocs .oc ;
public ciass Trigger
{
private String name;
private Strinç classN&,lie;
grlvate ConstraLz= constraint;
/ / cke c o n s t - ~ c = o r
Trigçer(Str2ng name, S t r i ~ gclassName, Constraint constraint)
this.name = came;
tkis.className = className;
this.coastrainz = constraint ;
:
/! utilizy nethods
String getName0 { r e c u r n this-3arr.e; )
S t r l c g getClassName0 ( r e t a - n this-classNme; )
Constraiat getConstrair,tO { returr. =his.constrair,t;
{
Annex B - Code Source
/*
-.
123
the method instantiates an object of type "classNamem and
rires
it * /
void fize(0b:ect oDj) t k r o w s 0Bjec:Catego-ryExcepcion
Class cc;
TriggerInterface trigger;
<
tl?/ (
cc = C ~ ~ S forNa,ne
S.
(getCIassName( 1 1
;
1
c a t c h iClassNn+=nl~ridZ~coprinr?
o!
throw ziew ObjectCategoryCxceptior. lV5zexpected exceptloc: 21ass
getClassName0 + " not f o t m d n ) ;
"
1
try
E
trigger = (TriggerInterface)
?
catch (Z~~egalAccessException
String nsg = "?nexpected exception ic zrigger:
e.=oString();
t h r o w new ObjeccCatego-zyExceptio~!(nsg);
?P
catcn ( I n s ~ ~ t i a = i o n ~ c e p t ie o) ni
String msg = "Jnexpected exceptio~ i?. x i g g e r :
e . =oStriz.ç ( 1 ;
chrow new Obj ec~Catego~ryExcep~ioz
(rnsç);
The TriggerInterface interface defines the only method that is implemented by userdefined uiggen.
package ocs .oc;
pünlic i~terface
/,J' an erit,'y metnod
public void tire(0bject
i
O) throws
-
Annex B - Code Source
124
The OCPersistent class defines the attributes and methods the system needs for manaping
persistent objects.
import
import
import
impor:
java.utFl.*;
corn-odi.+ ;
corn.odi.l~til..~;
..
corn.odi . ztl-.que-?
;
gublic absxact class OCPersis~enc(
!* the artribute coctains r e f e r e n c e s
ae-rnher of *!
=O
zhe categories the onjecz 2s
;/ initializes ~ h OSVector
e
public OCPerslstent ( 1 {
chis.rriexrbership = aew OSVeczor();
OSVector çetMembership ( )
retu,?.
tthis .membership;
1
{
vo19 adâYembership (Category c = ) {
geîMembership ( ) .aC&1eme,?z ( c c ) ;
voici zernoveMemberskip (Catego-zy c t )
getXm4ezsnip ( 1 . removeElenect ( c t ) ;
{
i
int membershipWLimi3er ( ) {
return getMembership ( .size ( 1 ;
I
!* the >se= caLls this mechoz afzer the 09ject1s contencs are nodifiee.
1
: allows OCS = O check f o r i==egrity c o n s x a i n t s c h a t are eeficeà over
the categories the oDject is nemjer of * /
pwlic final voici updace0 t h r o w s Constraln=ViolatiocExceptio~:E
OSVector rn = qetMenbership ( 1 ;
for ( k t i = O ; I<r,.sizeO ; i-+) {
Catego-y c = (Categozyi n.elenen0At (il ;
c.checkObjec~(this,0bjectCa~egory.Sefore~MoCify)
;
1 1 )
References
[il
hdleigh. P. R. and Gretzinger. R. M. Distributed Object-Orienred Data-
Systems Design. PTR Prentice-Hall. hc., 1997.
14
Athnson. M., DeWitt. D.. klaier, D.. Bancilhon, F.. Dituich, K. and
Zdoni k. S . The Objecr-Oriented Database System Mon ifesto. In
proceedings to the Fint International Conference on Deductive and
Object-Oriented Databases (DOOS89). Kim. W., Nicolas, J.-M. and
Nishio S. (Editon). Kyoto, Japan, 1989.
Pl
Bancilhon. F. Delobel C. and Kanellaius P . (Eds.). Building an Object-
Morgan Kaufmann
Oriented Dutubase Syrems. The Story of 02.
Publishers. Inc. San Mateo. CA, 1992.
141
Bertino, E.. Catania. B. and Shdovsky, B. Inde-ring Techniques for
Advanced Database Sytems. Kluwer Academic Publishen, L997.
Pl
Canell, R. G. G. Object Dora Management. Object-Onented and Eirended
Relational Database $stems. Addison-Wesley, 1994.
References
El
126
Canell, R. G.G.and Barry, K . D. (Eds.) The Object Darubase Standard:
ODMG 2.0. Morgan Kaufmann Publishen, Inc., San Francisco,
California, USA, 1997.
171
Claude, D., Christopher. L. and Philipps R. Darabases: From Relarional ro
Object-Oriented Systems. International Thomson Cornputer Press, 1995.
Pl
Date. C . J. An Introduction tu Database Sytems. 6" edirion. hddisonWesley. 1995.
[91
Date. C. J. and Danven H. Foundations for Objecr Relarionnl Databases.
The Third Manifesro. Addison-Wesley Loqman. Inc., 1991.
[ 101
Date. C. J. and Danven, H. A Guide To The SQL Standard. Inird Edition.
Addison-Wesley Publishiq Company, 1991.
Dittrich. R. K. Object-Orienred Dala Model Concepts. Univenitat Zurich.
Institut fur Informatik, Zurich. Switzerland. in proceedings to Advances in
Object-Oriented Database S ystems. NASO Ansi Series, Spring-Verlag.
1992.
References
[ 121
127
Dogac, A. Advances in Object-Oriented Darabme Sysrems. NASO Ansi
Senes, S pring-Verlag, 1992.
Lw
Ellis, A. M. and Suoustrup. B. AT&T Laboratories. 7'he Annotated C++
Reference lktanual. .WSI Base Document, Addison-Wesley Publishing
Company, 1990.
[ 141
Elmasri, R. and Navathe, S . B. Fundamentals of Database Systems.
second edirion. The BenjaminICummings Publishing Company, Inc..
Redwood City, CA, USA. 1994.
[15]
Elmasri. R., Weeldreyer. J. and Hevner, A. The Category Concept: An
Eaension ro the Entiy-Relationship Model. Data and Knowledge
Engineering 1. 1983.
[ w
Fowler, M. and Scott. K . UML Distilled Second Edirion. A Brief Guide to
the Standard Objecr Modeling Lunguage: Object Technology Series,
Addison-Wesley,2000.
[171
Jawonki, J. lova 1.2 Unleashed, T7ze Comprehensive Solution. S A M S ,
USA, 1998.
References
[la
128
Johnson, J. L. Dotabase. Models. Languuges. Design. Oxford University
Press, Oxford, NY, 1997.
[19]
Joshi, 1. D..Runoifson. R. and Chandak. R. The Comprehensive Guide ro
the JDBC SQL MI. Ventana Communications Group. Inc. 1997
Po]
Khanna. L. EER-Schema Mupping Toolsfor lnreroperable Database
Represenratzons. 1997.
[w
Khoshafian. S . Object-OnentedDarabases. Wiley Professional
Computing, 1993.
f 221
Korth. F. H.and Silbenchau, A. Cniversity of Texas at Austin. Dambase
S w e m Concepts. McGraw-Hill Book Company, 1986.
[23 1
ObjecrSrore Java MI User Guide. Release 6.0. ObjectDesign Inc.. March,
1999.
[W
Peuos, J. Modeling and lmplementation in an Object-Onented Database
Management System. 1993.
References
129
Rao, R. B. Objecr-Oriented Databases. Technology, Applications and
Products. McGraw-Hill, Inc., 1994.
Skarra. A. H.and Zdonik, B . S . Type Evolution in Objecr-Onented
Darabase. In Research Foundations in Object-Oriented and Semantic
Database Systems. Cardenas. A. F. and McLeod. D. (Eds.), Prentice Hall.
1990.
Sndharan. P. Advanced Java ivenvorking. Prentice Hall PTR. Upper Sadle
River. New Jersey, 1997.
Tsichntzis. C. D. and Lochovsky. H.F. University of Toronto. Databuse
Managernenr Sytems. Academic Press. New York, New York. 1977.
Tsichritzis. D. and Lochovsky. F. Dara Models. Prentice-Hall. 1982.
L'llman. J. Stanford Univenity. Principles of Darabase Systems. Cornputer
Science Press. Rockville, Maryland. 1982.
References
1311
130
Lllrnan.J. Stanford University. Principles of Database and Knowledgebase Sytems, Volume 1. Computer Science Press, Rockville, Maryland,
1988.
1321
Yang, C. C.Relational Databases. Prenuce-Hall. Englewood Cliffs. NJ.
USA, 1986.
[33]
Yannakoudakis, J. E. and Chang, P . C . Standard Relational and Network
Database Languages. Springer-Verlag, 1988.