Database
Schema
Chien-Tsai
Evolution
Liu
Shi-Kuo
using
Chang
EVER
Diagrams
Panos K. Chrysanthid
Department
of Computer
Science
University
of Pittsburgh,
Pittsburgh,
PA 15260
Abstract
changes
to the ER schema
constructs
We present
through
an approach
to schema
changes to the ER diagram
ing the schema
facilitate
of a database.
changes
constructs
for specifying
lationships
In order
we en-
the derivation
for
maintaining
views of programs.
In
this paper, we demonstrate
EVER
diagram
into
schema
versions.
the mapping
an underlying
and the construction
to an ER diagram
the application
the database
tion programs.
as a front-end
1
interface
while
accessible
The EVER
all objects
to
in
system
for object-oriented
changes
an approach
ing the schema of a database
*This material
Science Foundation
changes
databases.
represent-
database.
objects
123
the application
resentation
proposed,
particularly
graphs
rep(VDGS)
visual
of
interface
schema
is
in
the
evolution
context
into three categories
representation
(object
and interactive
of the structure
of
schema)
to application
in the underlying
approaches
and a single
based
of the
users, and the internal
of the objects
for each object.
The
[3, 4, 7, 2, 13, 15, 161. Theses
can be divided
port one single schema
aid that
schema.
schema evolution.
to database
databases
(1) Schema modification
tation
diagram.
into the structures
A powerful
approaches
in the database
programs
The user
the EVER
derivation
mapped
for database
on the external
Permission to copy without fee all or part of this material is
granted provided that the copies are not made or distributed for
direct commercial advantage, the ACM copyright notice and the
title of the publication and its date appear, and notice is given
that copying is by permission of the Association of Computing
Machinery. To copy otherwise, or to republish, requires a fee
and/or specific permission.
AVI 94- 6194 Bari Italy
0 1994 ACM O-89791 -733~2/94/0010..$3.50
allows
1.
to an intermediate
version
thus provided
been
accessi-
serves as the visualization
an underlying
approaches
is partially
supported
by the National
under grant IRI-9210588.
system
are subsequently
object-oriented
[5]. In order to facilitate
in Figure
transformed
called
pro-
programs.
diagram
have
to schema evo-
remain
conveys changes to a database
which
of views
to an ER dia-
in the database
is illustrated
is then
views for
to the application
to create and modify
resentation
can serve
to the ER diagram
reorganization,
The EVER
Various
we present
through
of database
graphically
diagram
to the applica-
an underly-
the reconstruction
of the EVER
programmer
into
Through
Our approach
relationfor main-
We also describe
diagram
and the construction
ble to the application
for
versions,
views of programs.
grams while all objects
Introduction
In this paper
lution
programs
schema
EVER,
the deriva-
and the conditions
of the EVER
database
the graphical
and develop
for specifying
gram can be made transparent
changes
can be made transparent
remain
after
the reconstruction
of views after database reorganization,
consistent
schema versions.
of the
views
between
attributes,
ing database
database
of database
Through
taining
relation-
and the conditions
relationships
the mapping
re-
ships among attributes,
ER diagram,
ships among
an EVolutionary
between schema versions,
consistent
tion
to
used in ER di-
and develop EVER,
ER diagram
an Evolutionary
represent-
to the ER schema
hance the graphical
agrams,
evolution
we enhance
used in ER diagrams,
rep-
database:
[2, 161 always supinternal
Hence, all objects
represen-
must be con-
verted
to conform
the schema
to the new schema.
modification
the transparency
approach
programs
schema may need to be modified.
ing approaches
multiple
[l,
internal
The instantiation
formed
this approach,
the schema of the objects
a common
internal
object
of whether
objects
are created
allow
specified
and,
and a common
make
with
Figure 1: The overview
evolution
schema
derivation,
3 introduces
several
outline
it can
2
out that the ER dia-
graphical
In
for the transforma-
to be relational
that
and
diagrams.
into the underlying
we argue
the future
of EVER
a methodology
used as a front-end
mainly
the extended
changes to ER diagrams,
examples
diagrams
which are assumed
ER
language
The
new concepts.
databases
[8]. In the conclud-
the EVER
system
for object-oriented
can be
databases,
and
work.
Schema Evolution
to ER Diagrams
(EER)
model that
application
[9, 141 and the Con-
that
suppo:rts
the attribute
proposed
of changes
programs
of new applications.
multilevel
through
as follows.
When
relationships
the schema is then created.
In Sec-
interface
among
a
the need for EVER
124
for programs
in this
Changes
paper
to a schema
while facilitates
type (or schema for short)
and discuss the issues in maintaining
which motivate
approach
transparency
[lo].
database
System for schema
in the past as we do here with
the E&ended
tion 2, we will analyze
for expressing
ing section,
other two schema evolution
be pointed
constructs
tion of EVER
schema ver-
is designed
Section
Section 4 we describe
referred
to th.e up-to-date
EVER
the class hierarchy
structures
of the EVER
diagra:ms.
then present
versions
in our approach
in order to incorporated
include
schema versions
of schema deriva-
previous
The rest of the paper is organized
consistent
to
can be
representation,
for schema
to support
It should
cept D, a graphical
concept
of an object
multiple
changes
Although
an approach
diagrams
Examples
Databases
derivation
consistency
However,
conflicts
grams have been extended
incorporates
representa-
existing
version
object
object.
can only
also be extended
EVER
7
schema
across schema versions derived
internal
sions are avoided.
approaches.
different
belongs to the family
Therefore,
to support
Database schema translator
to a schema version
how object
as such, supports
a designer
and
Irrespective
to the common
any schema
to as the complete
schema.
approaches
paths.
Our approach
tion
under
Although
and maintained
from different
VDG constructor
if
to, be updated
derivation
of objects
it ,is not clear
of a
augmented,
representation.
at run-time.
approaches
evolve,
In
Therefore,
schemas for an object
they are converted
is performed
to a version
version.
(3) Schema
The instantiation
is per-
with a later version without
multiple
versions,
and
of the objects.
for the objects
associated
[3, 4, 7, 151 support
tion.
schemas
is subsequently
not be possible
version-
for an object.
belonging
stay in that
loss of information.
use the old
to a schema version
the objects
by the programs
multiple
of the creation
schema must always
it would
that
representations
of objects
at the time
application
(2) Schema
131 support
object
User Interface: EVER diagrams
does not support
of change for the existing
The application
programs.
Because of this,
an entity
is changed,
sup:ports
the
for the existing
the requirements
or rel.ationship
a new version
Each schema version
to access the database.
of
is the
A. Analysis
of Attributes
Schema-Versions
in Different
When a schema evolves, the most important
ship between
tionships
vide the crucial
objects
attributes.
information
in the underlying
ject consistency.
for reorganization
database
We classify the attributes
of the old schema, it is called
of the
defined.
between
is an attribute
Derived
guished
attribute.
and dependent
attributes
into four groups
depending
If (Al,
Aa,. . . , Ak}
Common
attributes:
common
to the two schemas,
An
main of the attribute
Domain-changed
attribute
the forward
B is classified
{AI, A2r
B is the attribute
is said to be
tributes
if the name and do-
be domain-changed
An attribute
of the old schema,
the two schemas is exactly
attributes:
named if the attribute
ferent
l
Resumed attributes:
sumed if the attribute
schema
version
but
schema version.
it is added
A resumed
from
back
attribute
l
Derived
attributes:
An attribute
attribute
of the old schema, then B is in reverse
their
is said to be decan be derived
from the values of other attributes
not necessarily
said to be dependent
is affected
tributes,
let say {Al,
the dependent
to the values
AZ,. . . , Ak},
attribute
cannot
the values of the same attributes
of other
{Al,
by using
functions.
a and b are common,
by using an
(1) such that a = I(b),
function.
If attribute
attributes
or a E b.
a can be derived
bl, b2, . . . bk, the relationship
using a derivation
function
(F) such that
b2,. . . bk).
function.
If
attribute
a depends
on
bl, b2, . . . bk but it cannot be derived
bl, b2,. . . bk (e.g.,
information),
it
may
the relationship
need
at-
solely
additional
of a to attributes
by using a prompt
h, bz, . . - bk can be represented
finction
(VF) such that
a = Q(bl, b2, “.bk, a),
at-
but the value of
be derived
com-
bl, b2, . . . bk can be represented
Prompt
let say B, is
can be expressed
can be represented
function
a = F(bl,
if the value of the attribute
by changes
into
if B is an
of Attribute
If attributes
relationship
tributes
An attribute,
However,
of a to attributes
from
attributes:
four general
from only
attribute.
rived if the value of the attribute
Dependent
then B is classified
group.
relationships
function.
Derivation
to a latter
of the same schema-version.
l
B
group.
identity
an early
can be han-
dled in the same way as a common
of the new schema,
complementary
Identity
is said to be re-
was deleted
attribute
the following
same domains.
An attribute
then attribute
AZ,. . . , Ak} can be at-
forward
The attribute
is said to be re-
in the two schemas has dif-
names but exactly
If (Al,
B. Explicit
Specification
Relationships
the same but its domain
An attribute
If
in
is different.
w Renamed
group.
group.
of the new schema, and
in the new schema or old schemas, and B is an
plementary
is said to
if the name of the attribute
into
. . . , AL} are attributes
in the two schemas is identi-
attributes:
of the old
two
cal.
l
are attributes
of the new schema, then
lines as in [7].
attribute
distin-
schema, and B is the attribute
is in the reverse
l
are further
on where they are
ob-
of their values, their
and their names along similar
tribute
pro-
and maintaining
schemas based on the relationships
domains
relation-
These relationships
On the other hand, if the at-
an eliminated
the old and the new schemas is the rela-
of their
called new attribute.
where @ represents
from
is possibly
AZ,. . . , Ak}.
the additional
an interactive
the database
that
information.
query against
is not involved
9
the rest of
in the particular
schema changes.
l
Independent
attributes:
independent
if its value neither
fected
attribute
by the values
is an attribute
An attribute
of other
is said to be
affects,
Default
nor is af-
attributes.
of the new schema,
function.
ject is unspecified
If the
program,
it is
125
If the attribute
value of a of an ob-
but the value is required
then the default value can be acquired
by a
by
(de fault).
using a default function
default
value to a unspecified
need of the application
di.fferent
By assigning
attribute
programs
schema versions
value,
associated
of the key attributes
a
the
schema.
The maintenance
not be performed
with
tion,
\ve can prefix
tion.
Forward
the mapping
the forward
indicates
to new schema version,
ping
is from
the mapping
attributes,
attribute
of a schema version
in another
any schema version
Vj in between
may exist between
are not necessarily
consecutive.
allows for capturing
Invaria.nt
programs
be resumed
with
The resumed
attribute
the previous
at any time,
the result
our framework
pletely
two observers
based on ER schema evolution,
by ensuring
a consistent
database
sions: object consistency,
program
views.
Object
Consistency.
of application
The maintenance
siste:ncy can be accomplished
discussed
along
key consistency,
in the previous
through
section.
of an object
attributes
on the updated
also updated
of an attribute
update
to the affected
dimen-
of object
Consistency.
schemas.
That
must
the evolution
l
the relationships
the
l
those
attribute
are
fimctions.
An
We call this diagram
diagram,
l
relationship
the relationship
the invariant
The evolution
as a
a designer
be uniquely
specifies
the
irrespective
of
of attributes
between
views of programs
relationship
by using
the new
(i.e.,
e:dges) to
to the database.
indicates
The attribute
from where the
relationships
by functions.
edge between
and a relationship
an entity
of the entity
ship type needs to be established
sequently,
the values
126
the relationship
spec-
on the others,
and can be represented
that the participation
by the old or new schema,
identified
EVER
can. express
of the new schema,
of a new schema
new schema evolves.
across the old and new
is, each object,
it is created
of
of schemas
the other schemas, and
of the
are executed
The key consistency
of the objects
constructs
the relationships
ify the effect of changes to an attribute
uniqueness
whether
of changes to ER
schema and the old schema,
transaction.
Key
consistent
relationships:
l
the functions
and the propagation
attributes
under
for Specifying
the basic graphical
to present
In an EVER
the following
con-
is updated,
based on the specified
update
three
their
to
database.
before and after a change.
diagram.
facilities
and invariant
Whenever
value of an attribute
depending
we comprograms,
the
In ou:r frame-
the conditions
the specification
we extend
ER diagrams
How-
asisociated
we provide
can maintain
EVER Diagrams
Schema Evolution
diagrams,
In
for the
may not preserve
by the programs
to specify
the programs
In order to support
schema versions
must agree on each other.
avoid the modification
of
program
version.
schema versions.
views to the evolved
3
invariant
of a database
database
made
allow the designer
if and only if for
different
when a
the mapping
with a schema
work of schema evolution,
C. ‘I’he Maintenance
of Database
Consistency
Across Schema-‘Versions
view the same state through
The
the semantics
associated
interpretations
Vi and V, which
in the database,
in our ap-
condition
between the new and old schema3
ever, the evolved
in
these types of relationships.
of an object
Therefore,
Views.
views specify
An
V; and Vi. Thus, at-
A d.ata.base is said to be consistent
in the
changes the key attribute:
Program
which
each state
may be different
must be one-to-one.
can only
is no such attribute
tribute
alone
versions.
the key attributes
can-
constraints
Except
schema versions.
V; can only
of key consistency
we enforce the following
designer
the map-
version.
schema
proach,
the old
relationships
Vl, i < I, if there
relationships
is from
and reverse indicates
exist in two consecutive
attribute
of a func-
or reverse to the func-
the new to old schema
for resumed
explicitly
direction
in the old a:nd new
by the integrity
bec.ause the key attribute
can be resolved.
different
In order to indicate
defined
The change to an
type implies
type in the relationor dropped.
.And con-
type needs to be evolved
by
I
I Old(Schema) 1
-----I
Al
-----J
(4
version
B2
deriv;ition
g1
-----_
RI
Al
------I
(4
Figure
adding
2: The icons for EVER
to or deleting
attribute
maintenance
programs
entity
of invariant
type.
program
database
for maintenance
in Figure
graphical
constructs
2. We will use examples
of the icons.
ure 3(a).
Let us begin
The
with
new schema,
from the old schema,
the new programs,
Thus,
Old(Schema)
gle. Similar
version
attributes
with
of
attribute.
The forward
function
the end close to the attribute
and the reverse
function
the end close to the attribute
As shown in Figure
in the
is asso-
in the old
3(c), the domain
B1 in the new schema is different from that
B1 in the old schema. Therefore, the for-
of attribute
of attribute
(f,,s) is associated
ward function
be seen by
with
the end close to
attribute
B1 in the new schema.
Similarly,
rectan-
function
(jvI)
the end close to the
schema, the resumed schema
attribute
in the old schema.
it as a defunct
is represented
by a dotted
which consists of the resumed
of the old schema version
attributes
and all
and dependent
the pointed
The icons, from Glo to Gm, are used for representarelationships.
Gro indicates
is associated
with
the reverse
Grz and Gls are used for representation
can be represented
using icon G14.
tion of the attribute
changed
as
G11 is used for representation
schema.
we consider
to the defunct
B1 in the old schema is renamed
of a domain
schema version.
is derived
using icon Gs (a parallel
Since the old schema cannot
attribute
with
as the other.
Al in the new
attribute
Al in the old schema are common.
is associated
ciated
the one shown in FigThe derivation
3(b),
new schema version,
the uses
New(Schema),
Old(Schema).
the new schema is represented
line).
(icons) are shown
to illustrate
or one is renamed
in Figure
dia-
at the two ends
For example,
Bz in the new schema.
can access the evolved
the EVER
of the icon are common
However,
program
of a schema
of the two attributes
schema and attribute
consistently.
The extended
directed
for
consistently.
of invariant
views ensure that the programs
database
The conditions
3: The derivation
the relationship
type the key
views ensure that the
can access the evolved
The conditions
diagrams
from the relationship
of the affected
Figure
gram
that
127
attribute,
respectively.
end is derived
tributes
in the other
end.
function
for the attribute
of a derived
The attribute
from or dependent
The derivation
is associated
at
on the ator prompt
with
the at-
that of New(MPG).
In this EVER
common
diagram,
to both
schema versions.
are represented
changed
tween
New( MPG)
attribute.
Thus,
close to attributes
tively.
Figure 4: An example of EVER
ification of domain change
tribute
close to the pointed
3(d).
Al
function
fi
in the old schema.
is associated
icon close to attribute
&
is dependent
is associated
with
the attribute
Bz.
Thus
EVER.
the pointed
diagrams
we will illustrate
We assume that
The first
and the consistent
example,
to the domain
of attribute,
of schema
The
per gallon,
is changed
All
string[lO].
Car.
from
MPG:
other
attributes
schema versions
remain
functions,
unchanged.
itoa()
and atoi(),
system.
Functions
atoi()
a string
into an integer
spectively.
Therefore,
represented
tion function
(fvi)
functions.
tion func.tion,
(fvl),
to a string,
a company.
The reverse
deriva-
of attribute
MPG
maps the domain
in a new single schema.
Company
Since Maker
Regld,
with
and Dealer
the new entity
from
have
type,
and gains an addi-
to distinguish
CompanyType
respect
is derived
the type of
is new because it
to the schemas
value of the attribute
Maker
and
can be de-
CompanyType
=
deriva-
of Old(MPG)
Attribute
an EVER
two schemas
fined as:
of the attribute
and the forward
to the p:rograms
5) in which
the key attribute,
CompanyType
The default
Dealer.
and can be rep-
re-
can be
to that
and Dealer.
attribute
is independent
by the
relationships
maps the domain
in the old schema (Old(MPG)),
tional
resulting
key attribute
inherits
Company,
new and old
and
(Gc) and edge (Gs),
let us demonstrate
in the diagram,
the common
the old
Old(Car),
the new schema any more.
together
schemas Maker
are used to convert
and an integer
in the ne’w schema (New(MPG))
mileage
by
goes from
are not visible
(as shown in Figure
As indicated
can be supported
and itoa()
diagram
of attribute
which are supported
with
are merged
be-
which
rectangle
In the second example,
consis-
The mapping
the attribute
by derived
must satisfy
. . 99991 to MPG:
in the
to
using a solid rectangle
to it are defunct,
and they
associated
4, illustrates
domain
line (Gs)
by the dotted
respectively,
to an ER
MPG,
integer[O
tween the new and old domains
resented
database.
as shown in Figure
parallel
the edge connecting
involved
the structurally
and edge that connects
New(Car),
schema to the new one. The old schema,
the diagrammatical
all the changes
, respec-
as follows.
The derivation
of the
(Gl) and edge (G), respectively.
new schema from the old one can be depicted by using
(gi)
In the follow-
of changes
in maintaining
tent ER diagrams
a change
all the aspects
of a specification
the constraints
function
schema.
and Old(MPG)
it can be created and represented
how the icons used in
of a database
functions
with t.he ends
fuz and fvi can be specified
The new schema,
end of the
end of the ic:on close to
can capture
ing two examples,
diagram.
from
a directed
in the evolution
MPG
Thus, the prompt
beusing
FUNCTIONS
{
(New(MPG)
= f.z(Old(MPG);
WITH
IMPLEMENTATION
New(MPG)
= itoa(Old(MPG)));
(Old(MPG)
= f.l(New(MPG))
WITH
IMPLEMENTATION
OId(MPG)
= itoa(New(MPG)))};
On the other hand, Attribute
AZ.
the relationship
derivation
the pointed
far, we have discussed
representation
is derived
The forward
with
on Bi.
for the spec-
end. Let us refer to Figure
AZ in the new schema
Attribute
attribute
diagrams
are
MPG
is represented
are associated
New(MPG)
Functions
relationships
and reverse derivation
(fv2 and fvr, respectively)
are
Color
Attribute
and Old(MPG)
The forward
Regld,
Their
by using icon Gio.
domain
icon Gri.
attributes
Function
and returns
to
128
dealer
if Schema type(~)
= Dealer
maker
if Schema &x)
= Maker
schema
type() takes an object
as its input,
the name of the schema to which
the ob-
sentation
called the version
and then maps the VDGs
\
Year
C&r
CarId
A VDG captures
\
It consists
tribute
/
/
in an EVER
I-----d
belongs.
of EVER
diagrams
The programs
that
for merging
A directed
lationship
among
currently
designed
the programs
that
refer to entity
may just need to access the objects
is equal to maker.
panyType
conditions
associated
type
the VDG
For
Maker
sistency
the invariant
when
views of
to support
the efficient
FUNCTIONS
{
((companyType
= default)
WITH
IMPLEMENTATION
of the old schema version.
then companyType
else companyType
which is derived
= Dealer
= dealer
where
= makes))
base attribute
};
conditions
VIEWS
{
ACCESS
WITH
CONDITIONS
(acl : CompanyType = maker));
Dealer ACCESS
WITH
CONDITIONS
= dealer))};
(UC2 : CompanyType
in
of all the versions
among
of object con-
schema
versions,
is reorganized
objects
share the storage
after
are allocated
a
ad-
(the base atwith attributes
Let E,, be a schema version
from schema versions
n Q {l..m).
it is
represented
for only those attributes
that cannot
is
schema).
database
ified as follows.
Schematype
storage
re-
a VDG
representation.
maintenance
and use of storage
ditional
(ij
object
is conceptually
as the union of attributes
the underlying
tributes)
Since,
schema derivation,
new schema version is created,
with a schema version are spec-
the derivation
versions.
a single internal
In considering
values and the
in the correspond-
edge represents
schema
ob-
is spec-
a new node representing
of the schema (or the complete
whose value of Com-
The default
used for maintaining
the programs
database.
toward
the at-
for maintaining
in added
The schema of an object
use the old schema
may need to access a part of the evolved
example,
diagram,
Each
and the following
a new schema version
version
ing VDG.
geared
ject
When
schema.
edges.
recording
to the previous
and the conditions
the new schema
Figure 5: An example
two schemas
database
of a particular
to a schema version
schema versions
ified
the evolution
relationships
ject consistency.
------
KegId
into the underlying
of a set of nodes and directed
node corresponds
CLU
/
graphs (VDGs),
model.
\
/
derivaiion
Attribute
El, Ea,. . . , E,,,,
ai E E,, is said to be a
of E,, if and only if one of the following
are satisfied.
INVARIANT
(Maker
l
group(ai)
E (
new,
forward-complementary-dependent
l
3ak
E Ej A j
attribute
are associated
conditions
schema
the default
functions
with the attribute,
version.
The resultant
In order to support
instead
with that
diagram
where dam-size(a)
shown
storage
different
the EVER
Diagrams
implementation
translating
database
diagram
A (dom-size(ak)
c
used to compute
a; domain-changed(a)
that
whose domain
has been changed.
base attributes
is derived
from
of schema versions
schema of schemas (El,
the
returns
attribute
a, but
Let B; be a set of
Ei, i E {l..n}.
Ez, . . . , En}
The
(SC) can
as: S, = Uy=‘=, B;. Let us refer to the ob-
jects correspond
dia-
to the complete
schema as the complete
o bjecta.
model, our approach
into a conceptual
for an attribute
be expressed
database
an EVER
is a function
the attributes
complete
of directly
gram into the underlying
transforms
of EVER
that
dom-size(a;)).
5.
Transformation
into Databases
models,
EVER
for an
such
and the view
for a schema version are associated
in Figure
4
diagram,
}
E {l,...,m),
a; = domain-changed(ak)
In the EVER
forward-dependent,
repre-
In order to indicate
129
whether
the objects
created
un-
der a schema version need additional
two kinds of nodes:
A non-virtual
virtual
and non-virtual
node corresponds
the initial
the attributes
that cannot
schema.
is, a non-virtual
shares
nodes.
to an schema
whic:h is either
That
stora.ge, we define
version
one or is augmented
be derived
created
non-virtual
scribed
lying
to a schema which does not
under
node cannot
database
that
versions.
hand, the objects
created
schema.
On the other
version
stored in the underly-
ing VDGs
provides
ing database
the independence
model.
mation
of VDGs
which,
we assume
database
port
of changes to an ER diagram
to an implementation
to be relational.
is “objectified”
,this, mapping
of database
the different
of entity
or relationship
temwide
unique
into
the mapping
the relational
is derived
Maker
database,
from schemas
are initial
Maker
r1 whose schema
Address,
Oid).
Name,
Dealer
which
is a new attribute
shares
with
Maker
to Company,
and
Maker,
Dealer,
Since
example,
relation
Name,
of
used to store the com-
is mapped
version.
under
Company
under
the objects
must be stored
In this
into the schema of
created
maps to VDG
Maker
created
the objects
are
under
created
into all three relations
r2 and rg.
Step
which
schema
which
objects.
130
5.
schema of the VDG.
into
CompanyType
of the ,views for
in Figure
CompanyType}.
the objects
Similarly,
Let us
schema (SC) of schema
are stored into rz. However,
schema
diagram.
by each schema
Maker
Thus,
rl.
Address,
the relations
created
schema
rl.
the complete
above, the complete
Car is {Regld,
into a
make use
Dealer
Address
of S;. Let
the schema version
in the EVER
stored
Regld
with
and the
and Company
Dealer
1: Determine
Step
As indicated
rl,
has three attributes:
associated
of the base attributes
Oid:
r2 with
ob-
on the complete
step by step the construction
schemas
Oid).
Schema Company
both
illustrate
node, N1 and Nz, respec-
Similarly,
or non-virtual
on the attributes
through
2: Determine
identifier
schemas
schelma, irre-
Thus, the view of a schema
as a selection
specified
objects
node Nz, and then maps to a relation
Tz(Regld,
viewed
Step
the object
with
as a view on the com:plete
The conversion
Com-
all attributes
In this
it maps onto a virtual
(S;) is defined
plete
Tl contains
objects.
associated
based on the access conditions
of the functions
base
into two VDGs.
node, N1 is mapped
plus one extra attribute,
Tl(Reglcl,
They contain
schema
Each object
version
Each
and thus are mapped
Eleing a non-virtual
relation
Maker and Dealer.
objects
each
is the union of the
objects
attributes
diagram
in the diagram,
schemas.
consists of a single non-virtual
tively.
an EVER
objects
and Company.
of whether
with
first to complete
node, is expressed
object.
a sys-
let us use the example
5. As indicated
and Dealer
attributes,
from
as a view on
JQTW)
b e a P rocedure that converts an object associated with a particular
schema version to a complete
not vis-
(Oid)
associated
Si, and then a projection
and use
programs.
shown in Figure
pany
identifier
sup-
with
Com-
each view in terms of the complete
jects stored in the relations.
i.e. instance
is associated.
and immutable
ible to application
To illustrate
type,
VDG
schema ver-
sions. That is, we assume that each object,
~3 with schema
define a view for each schema
the set of complete
Dealer
spective
Th.e relational
as well as the construction
views representing
us-
schema
so that it can effectively
and
Dealer
CompanyType}.
is represented
is, objects
are expanded
Maker,
the transfor-
database
Address,
a new relation
Company
set of the expanded
from the underly-
We will demonstrate
That
example,
ing databases.
The representation
of Maker,
to store the base attribute
Oid)
version,, we construct
from a schema that map onto
nodes can be completely
nodes N1, NZ and N3
Name,
In order to uniformly
de-
Thus., the under-
need to be re-organized.
complete
nodes N1 and Nz, being a non-
node, N3 requires
Thus,
is
Company
The
~1, r2 and rg.
maps onto a
be stored in the databases
with
of base attributes
S, = (Regld,
panytype.
a schema
by the old schema
virtual
(SC) of the VDG
Ts(ComlpanyType,
any base attribute.
Objects
N3.
virtual
node corresponds
contain
schema
As in the case of VDG
attributes.
A vir;lual
is a base attribute,
node,
Since
Dealer.
a non-virtual
Company:
base
with
Name
CompanyType
is the union
from the old
and
Maker,
mapped1 into
schema
with
node contains
with
3: Identify
version,
the objects
and expand
The objects
created
created
them
under
under
into
a specific
the complete
a schema
version
may be stored in different
tified by joining
shown in the following
schema version
The objects
the objects
created
under
created
be one-to-one.
as
a schema
under
mapped
~1,
the objects
are selected
Dealer
created
by removing
from relation
created
the objects
viewed
created
The functions
.
un-
used for representation
relationships
indicate
view update
into the updates
Dealer
O2
= cOidE(IIoi..+(
This paper
presented
O1
= ~OidE(~o;d(rl)-noid(OS))(T1)
to support
schema
a view for a schema version.
Relationship
(ER)
the specified
condi&ns
grams.
are n schema
version
where
Conditionss,
Therefore,
for
Viewc
=
this approach
U:zT
describes
of a
ondly,
as belows:
Ezpand(0;)))’
u for selection
and
based
than to the logical
how data
one type
relationship
to avoid
model
that
approach
reasons.
supporting
Oriented
the mapping
types of relation-
models
which
primarily
sup-
is similar
[6].
to the
Thirdly,
we
Object-Oriented
more types
of relationships
in making
[12] and hence,
the ER
effectively
of ER schema into any Objectsup-
of the current-state-of-the-commercial-
art of database
)
of
Sec-
in the database.
many
ori-
schema which
At th e same time, our approach
one [ll].
ports evolution
(
Firstly,
perception
database
we are more interested
Object-Oriented
We
of being graphic
yet another
support
Entity-
modeling.
of changes in the con-
in the ER model
to define
would
[4]. Instead,
(
supports
of relationship,
the view of each schema ver-
(
are stored
the ER model
language
on the
for data
the semantics
Object-Oriented
“ISA”
= n(Reyld,Addzess,Nome)
specification
evolution
app roach
port
want
against
a graphic
ships whereas
Si.
specified
CUZ Eapand(Oi)))
Ezpnd(Oi)
the
the underly-
ented and of being closer to the designer’s
mpanyType=dea~ar)
CUiZf-f%and(Q)))
cnnnpany
against
has the advantages
data, rather
Si.
as:
n(Regld,Name)
of attribute
a unique way to translate
text of the ER model for the following
ver-
satisfy
the view
uniformly
for the conditions
~(cmpany~ype=mnker)
ff(C
then,
projection,
= n(Regld,Addreas)
ViewDenfer
chose to examine
the view of the pro-
versions,
in the example,
cannot
the view for schema
can be defined
sion can be expressed
ViewMaker
the schema
that
= IIs;(CT Conditionss,(u~~~
II stands
Con-
under a schema ver-
through
represent
ob-
Conclusion
5
r1
r.)-noi4Os))(r2)
out from
If there
Viewi
r2 wO;d
screen the objects
Let View;
schema
objects
viewed
(view
ing database.
Maker
sion, and then
version
of the complete
database.
= rg wO;d
sion to the objects
be
in the
under
rl.
created
objects
into the unique complete
03
objects
from
can always
a schema
a subset
in the underlying
Company
vert the complete
must
objects
the created
4: Construct
objects)
complete
from
are always
schema
Step
(view
the unique
them
viewed
jects, and can be mapped
under Company
the objects
among
the objects
database.
objects)
are se-
(02)
version
The objects
0
procedure.
Therefore,
into
underlying
under both
Ezpand()
version
~2. Similarly,
der Company
created
(03) are selected by joining
the corresponding
from relation
must be same or the mapping
can be iden-
For example,
are stored in ~2, we must separate
lected by discarding
Maker
table,
Since the objects
and Company
them to apply
They
based on Oid.
Company
rr and 73 on Oid.
Dealer
relations.
relations
systems,
that is, relational
database
sys-
a prototype
for
tems.
Each view is stored in the corresponding
and it may need to be reconstructed
VDG
node
The follow up of this work is to build
after each database
the exploration
re-organization.
In our approach,
against
l
The
we can guarantee
a view can be correctly
quence of updates
derlying
matic
database
that
translated
on the complete
key attributes
of different
ning of the paper
into the se-
objects
based on the following
the update
the graphic
in the un-
reasons.
schema
of schema
access of databases.
versions
131
evolution
and illustrated
user interface
changes
in multiparadig-
As presented
in the begin-
by Figure
and mapping
1, through
schemes
to an ER diagram
for
EVER
diagrams,
made
transparent
programs
and inter-
active
users. In other words, the application
programs
to application
can be
and users can access all objects
in the database
using
[14] T.J. Teorey, D. Yang, and J.P Fry. A Logical Design
Methodology
for Relational
Databases
Using the Extended Entity-Relationship
Model.
ACM Computing
Survey, 18(2), June. 1986.
their schemas.
References
[1] M. Ahlscn and et. al. Making Type Changes Transparent. In Proceedinga of IEEE Workshop on .Language for
Automation,
1983.
[15] S. B. Zdonik. Object-Oriented
Type Evolution
vances in Database Programming
Languages.
Wesley, 1990.
[2], J. Banerjee,
W. Kim, H. Kim, and H.F. Korth.
Semantics
and Implementation
of Schema :Evolution
in
Object-Oriented
Databases.
In Proc. of ACM SIGMOD, 1987.
[16] R. Zicari.
A Framework
Object-Oriented
Database
ence on Data Engineering,
[3] E. Bertino.
A View Mechanism
for Object-Oriented
Databases.
In Proc. of 3rd international
Conference
Extending
Database
Technology,
Mar., 1992.
[4] S. E. Bratsberg.
Oriented
Views.
tional
Conference
1992.
on
Unified
Class Evolution
by ObjectIn Proceedings
of the 1 .I th Internalon Entity-Relationship
Approach,
[5] P. Chen.
The Entity
Unified View of Data.
Systems, l(l),
March
Relationship
Model
ACM Transactions
1976.
[6] P. Chen.
ER vs. 00.
Internaltional
Conference
proach, 1992.
- Toward a
on Database
In Proceedings
of the 11th
on Entity-Relationship
Ap-
[i’] S. M. Clamen.
Schema Evolution
and Integration.
Distributed
and Parallel
Databases:
An International
Journal,
2( l):lOl-126,
January
1994.
[8] E. F. Codd.
Shared Data
A Relational
Model
Banks.
CACM, 13(6),
of Data
1970.
[9] R. Elmasri
and S. B. Navathe.
of Database
Syatems,
2nd edition.
jamin./Cummings
Publishing
Company,
City, California,
1992.
for
Large
Fundamentaia
The
BenInc., Redwood
[lo]
H. Kangassaio.
Concept D: A Graphical
Language for
Conceptual
Modeling
and Data Base use. In Proceedings of the IEEE Workshop
on Visual Languages, October 1988.
[ll]
C. T. Liu, P. K. Chrysanthis,
and S. K. Chang.
Database
Schema Evolution
through
the !Specification
and Maintenance
of Changes on Entities
and Rclationsh.ips. Technical report, TR-94-14,
Department
of Computer Science, University
of Pittsburgh,
January
1994.
[12] S. B. Navathe and M. K. Pillalamarri.
OOER: Toward
Making
the E-R Approach
Object-Oriented.
In Proceedings of the 8th Internaltional
Conference
on EntityRelationahip
Approach,
1989.
[13] H. A. Skarra and S. B. Zdonik.
Type Evolution
in
an O’bject-Oriented
Database.
In Researc:h in ObjectOriented
Databasea.
Addison-Wesley,
1987.
132
. In AdAddison-
for Schema Updates
In an
System. In Proc. of Confer1991.