A GENERAL MODEL FOR VERSION
Peter
Klahold,
University
Postfach
Gunter
Schlageter
and
of Hagen,
Praktische
940, D-5800
Hagen,
Abstract
Wolfgang
Introduction
areas
now
or in
future
Many application
cannot
be
supported
by
database
systems
a
sufficient
modelled
in
way
by
representing
only
the present
state
of the
must
world.
Instead
it
be
possible
to
well
as
model past
and future
states
as
parallel
to
each
other.
states
existing
These requirements
led to the development
models
tailored
to
of
various
version
areas.
Thereby
new
specific
application
introduced
or
taken
from
concepts
were
time
(for
instance
application
areas
version,
alternative,
variant,
etch,
which
some
facets
of
a general
all
describe
version
concept.
In
a
this
paper
version
2.
Version
I
base into
data
models
and,
kernel
by
support
a version
of the dbms.
we introduce
the
concept
of
environment.
A
version
models
complex
version
environment
which
are
based
on
some
structures,
primitive
mechanisms.
To motivate
these
first
we
sketch
some
mechanisms,
at
version
concepts
known from literature.
In
a survey
of our model,
chapter
3 we give
chapter
4 is described
more in
which
in
means
of an example
in the area
detail
by
how
our
5 we show,
of CAD.
In chapter
model can
be extended
by an
operational
which
defines
the operations
on
component,
structures
of
a version
the
version
environment.
Finally,
we model some of the
of chapter
2 in terms
of
version
concepts
our model.
Concepts:
Some Approaches
We try
to develop
a uniform
version
model
based on elementary
structuring
mechanisms
existing
version
concepts.
extracted
from
In this
chapter
we describe
some version
concepts
known from literature.
2.1
Commercial
Applications
applications
old states
are
In commercial
accordance
with
a
time
ordered
in
allow
controlling
of
attribute
to
their
transactions
and
(commercial)
results
(auditing).
However,
it turned
out
several
dimensions
of
that
there
are
‘time’
in
this
environment.
Example:
order
to
support
these
different
application
areas
with
their
specific
by databases,
we have to
version
concepts
find
a common
base
for
these
different
concepts.
We then can attempt
to integrate
Wilkes
Informatik
West-Germany
this
common
possibly,
to
lower
levels
In this
paper
we introduce
a general
model
for version
the
management
expressed
by
concept
of version
environments.
A version
two
environment
offers
mechanisms
for
version
sets
of objects:
structuring
the
the
use
of
graphs
and
partitions.
By
views,
constraints
and
transactions
the
version
environment
may
be
tailored
to
requirements.
The embedding
specific
user
tools
into
the
version
of
application
environment
provides
the users
with
their
environment
which
specific
application
objects,
their
version
consists
of
the
the
tools
operating
on
structures
and
them.
The proposed
concept
is more general
than
the
concepts
and
more
powerful
far;
it
is shown,
how well
published
so
concepts
can be implemented
known version
by means of version
environments.
1.
MANAGEMENT IN DATABASES
Queries
on salary
histories
In
This
supported
work
was
IBM
Forschungsgemeinschaft,
BMFT, contract
no. NT 2823 4.
employee
get
What
salary
did
an
month m?
21 What
was the salary
of an employee
his work done in month m?
in
1)
To answer
query
date of
payment.
period
for which
of
payment
is
by
Deutsche
Germany
and
we have
to know
1,
For
query
2 we need
salary
was paid;
the
not
of
interest.
for
the
the
time
Permission to copy wifhout fee all or part o this material is granted provided fhat the copies are not made or distributed for direct commercial
aduontage, the VLDR copyright notice an d the Me of the publication arcd its date appear, and notice is given that copying is by permission of
the Very Large Data Base Endowment. 7’0 cop otherwise, or to republish, requires a fee and/or special permission from the Endowment.
ProceedingsoftheTwelfthlnternationalCon
I erenceonvery
LargeDataBases
m-319-
Kyoto,August.1986
A
subsequent
adjustment
to different
results
/Hard/
distinguishes
to
represent
as
possible:
-
-
of salary
will
lead
of the two queries.
three
aspects
of time
much
semantics
as
realization,
i.e.
of
when
occurrence
of an event
is recognised
a future
event
is specified.
time
of storage
into
the database
time
of validity
time
According
to
there
are
relationships
2.2
CAD/CAM
the
or
the three
time,
points
of
three
different
ordering
on the set of objects.
applications
In CAD/CAM,
the notion
of version
is of
great
importance.
Versions
are
used
for
different
purposes,
e.g.
to illustrate
the
life-cycle
of a design
object,
to document
the
process
of
development,
or
to
represent
variants
in
This
production.
shall
be examplified
in the following.
/MiiSt/
decribes
a time
version
model
for
CAM databases
which
allows
the versions
to
be ordered
with
respect
to the beginning
of production.
For this
reason
the model
offers
operations
to
move
versions
the
along
the future
part
of the time
axis.
/Lock/
scheme:
introduces
the
following
version
obiect
rep
revison
1 . . . revison
/
\
1 ... ... .
rep
n
k
Representations
are
different
views
of an
object
(e.g.
logical
design
and layout
of
a VLSI
circuit).
Variants,
often
called
alternatives,
are
different
approaches
to
a problem,
they
are
developed
in
the
respective
revisions.
/KaLe/
introduces
a version
model defining
the
life-cycle
of
objects
(and
consequently
the process
of design).
Every
version
adopts
a certain
state.
There
are
operations
- to transfer
a version
from one
another(e.g.
ARCHIVE:
released
-> archived
version)
- to
derive
a new version
v2 in
from an existing
version
vl in
ALTERNATIVE:
in
(e.g.
CREATE
version
-> alternative).
state
to
version
state
s2
state
sl
progress
-320-
This
allows
to represent
the
production
well
as
phases
as
the development
stages
of an
object
in one concept.
The state
of
a version
indicates
its
meaning.
of these
approaches
is
A generalisation
/DiLo/.
described
in
Instead
of the fixed
version
structures,
version
clusters
are
allow
to
introduced.
They
group
versions
at will.
Thus,
the
version
structure
can
to the
application.
Clusters
be adapted
structures
on
are implemented
by pointer
top of the extended
SQL database.
design
In
/KSUW/
the
documentation
of
rather
history
is
emphasized.
Design
trial
and
in a
progresses
by
error
than
linear
way.
This
leads
the authors
to the
which
has
concept
of
a version
graph
meanwhile
been
used by other
authors,
too
The
allows
to
/KACh/.
version
graph
represent
flexible
order
relationships
by
and
describing
parallel
alternatives
Version
linear
versions
in one
concept.
the
graphs
are
one
element
of
general
paper.
version
concept
introduced
in this
3.
A survey
of
the
general
version
model
In the
following
we
introduce
a general
version
model.
At first
we sketch
our idea
of versions
and objects.
Then we define
the basic
version
structures,
which
are
model the
used to
applications
described
above.
Finally,
we
introduce
'version
environments'
as
a means
of defining
and
manipulating
version
structures.
from
an
We start
intuitive
notion
of
versions.
objects
and
The user thinks
in
terms
of
objects
where
an
object
or
constitutes
a unit
an entity
for him.
is not static,
An object
it develops
over
time.
Therefore
the notion
of object
is
twofold:
the
user
(at least)
Sometimes
total
of
considers
the
all
states
as his
object,
sometimes
he regards
a particular
state
as the unit
he is interested
in.
state
of
the user's
entity
is
A single
'version'.
called
We use the term
'object'
when we talk
about
the set of all
versions
of this
entity.
The
actual
(or states)
information
is stored
in the versions,
the
object
is
only
a unit
which
comprises
all
versions
(and
what. they
have in common).
This
general
structure
is
similar
to the
version
concept
of /BaKi/
and /KiBa/.
Versions
are,
for
instance,
represented
by
(sets
of)
tuples
in
a database.
They
the
information
comprise
total
of
describe
a state
of
an
necessary
to
regarded
as
object,
i.e.
they
can
be
copies.
This
not
exclude
updated
does
techniques
to
save space at lower
levels.
simplicity,
objects
and
For reasons
of
versions
unique
are
identified
identifiers
<aid>
in
and
this
paper
<vid>.
by
In
the
models
sketched
in
chapter
related
to
versions
are
each
other
different
ways.
Two main
structures
can
distinguished:
1.
2.
2,
in
be
Versions
are
ordered
(not
necessarily
totally)
by various
relationships
(time
relations,
development
history).
To
model these
orders
the general
version
model offers
version
graphs.
Versions
are
classified
according
to
specific
properties
(valid/invalid,
in
progress/alternative/effective/etc.).
The set
of
versions
is
partitioned,
with
every
version
belonging
to
a
certain
class.
A class
determine
may
the
operations
applicable
to
the
versions
in it.
In this
paper
we propose
a concept
combining
these
means of structuring
versions.
up to
now we distinguish
two main levels:
on the
one hand,
the objects
as a set of
versions,
on
the other,
the relationships
between
versions.
The concept
of version
environment
integrates
these
two levels:
A
version
environment
consists
of
a set of
objects
and
a set
of version
structures;
the version
structures
are
the
based on
two
structuring
mechanisms
and
graph
partition.
Every
object
inherits
the
version
structures
of
its
environment.
Thus,
all
objects
of
an environment
have
common version
version
structures.
Many
environments
can be managed by the system;
in principle,
every
object
may possess
its
own version
environment.
The model
is organized
in four
levels.
The
lowest
level
1 realizes
notion
of
the
versions
and
Levels
2 and
3
objects.
realize
the
concept
of
version
environments.
The
fourth
level
allows
to
adapt
the model
to the
application
environment
by importing
tools
as transactions.
Every
level
offers
a functional
interface
the
operations
of
which
may be used by higher
levels.
The model
looks
as follows:
The lowest
1) offers
level
(level
basic
operations
on
versions
and
objects:
Objects
may
be created
and deleted,
and
there
inserting,
are
operations
for
deleting
and selecting
qualified
updating,
versions
of
an object.
At this
level
all
versions
of
considered
an
object
are
separately;
no
relations
between
them are
known.
Level
2 manages
the
graphs
and
version
partitions.
There
are operations
(11
to
define
and
delete
version
graphs,
as well
as partitions
and their
classes,
(2)
to
structures
manipulate
version
the
(creating
and
deleting
of
edges
between
versions,
shifting
versions
between
clasretrieve
versions
ses) and
(31 to
using
the structures
(predecessor,
successor
in
version
graphs,
membership
in classes).
Level
3 provides
a mechanism
to
define
the
version
environments
to
views
adapting
specific
individual
requirements
of
views
form
(groups
of)
users.
These
new
their
own
(virtual)
objects
with
environments.
To control
integrity,
rules
may be specified
which
disallow
operations
on
versions
version
structures
at
and
certain
data
states.
Moreover,
we allow
to
define
complex
operations
as a sequence
of
basic
operations,
e.g.
to insert
versions
corresponding
into
the
object
and
the
structures
at one time.
Level
4 expands
the
version
model
by an
embedding
important
feature:
BY
application
into
version
tools
environments
it
for
provides
a mechanism
the operational
adaptation
of the version
model to specific
application
areas.
Thus,
the
guarantee
the
system
can
correct
access
to data.
The version
environment
is
managed by an
He defines
the
environment
administrator.
version
structures
of the environments
and
provides
users
operations
with
specific
user
works
on
existing
and views.
The
objects
with
predefined
version
structures
only.
4.
+--------------------~~~~~~+
! application
environments
+--------------------------f
+------------------------------~~~~~~~+
!
version
environments
! view,
constraint,
complex
+-------------------------------------+
+---------------------------------+
!
structures
! version
graph
+----------------------------~~~~~~~~~+
+---------------------+
!
versions
+---------------------+
!
1
We
consider
environment
!
!
partition
version
environments
this
chapter
the
most
important
In
the general
version
concept
operations
of
are illustrated
by means of an example
of
the
CAD environment.
The complete
list
of
operations
can be found
in the appendix.
!
operation
Using
1.
!
-321-
Chip
keep
for
objects
former
the
chip
have
states
following
objects:
design
to supply
versions
of the design.
to
2. The versions
are arranged
in a historygraph to
retain
the development
of the
object.
The edges of the graph have the
meaning
'is derived
from'.
3.
The time of
creation
of versions
must
be documented.
The versions
have
to be
ordered
in a linear
way with respect
to
their
time of creation.
4.
The
versions
are
grouped into certain
according
to
the
tests
performed
successfully
(e.g.
by
simulation
programs).
The classes
are:
unchecked,
test-a,
test-b
and
consistency
classes
consistent.
4.1
Basic
To
version
represent
After
defining
'chip-design'
this
the
version
structures
commands of
version
are defined
level
2
by the
DEPINR-PARTITION
WR chip-design: consistency
definition
the
partition
a default
class
'null'
which
not
explicitly
versions
all
to a certain
class.
of
comprises
assigned
The additional
classes
are
introduced
end of the
time-list
by
time-list(Y))
Flioncpu
WRBRE
id = 'versl'
by
DEFINE-CLASS
FORconsistencyOFchip-design: (unchecked,
test-a, test-b, cons)
The insertion
(level
1) of a certain
object
(e.g.
for designing
a CPU)
this environment
is done by
at the
CONWECT-VERS
IN time-list OFcpu
Y
SOORCK : SELECT-VERS
PROllcpuY
IlRERENOTEXISTS(succin
DESTINATION
: SELECT-VERS
’
the
consists
FROH
cpu
MEREdesigner
= Wller' ANDtine = 'l-Xl-86
DESTINATION:
SELECT-VERS
’
PROIIcpo
MEREid = ‘vernl’
The insertion
is accomplished
DEFINE-GRAPB PORchip-design:
historY_graph,
tine-list
After
CONNECT-VERS
In history-graph OFcpu
SELECT-VERS
’
SOORCE
:
DESTINATION
determine
the
SOURCE and
versions
which
are connected.
In general
SOURCE and
DESTINATION
are
sets
of
versions,
and for every element of SOURCE
the
DESTINATION
elements
is
set
of
computed and connected
to it.
environment
by
DEFINEERVIRONHENT
chip-design
following
Now let
us assume that the newly inserted
has to succeed the version
version
'versl'
designed
by author
'Miller'
at
l-28-86
in
graph,
i.e.
'versl'
was
the
history
designed
at
derived
from
Millers
version
l-28-86.
handling
specific
design
environment
two
version
graphs
and one
version
partition
which
have
to
are used
be adapted
in
correspondence
with
the
requirements.
To
retain
the
time
of
creation,
chip
objects
must
have
the
attribute
'time'.
the
X
denotes
the
version
created
by the
designer.
Its version-id
is set to 'versl'
user.
The INSERT-VERS
command
by the
inserts
the
(level
1)
version
into
the
of the
object.
At the
version
set
same
time it is linked
to the structures
of the
object
defined
by its
environment
as
constitutes
an independent
follows:
it
component
in
all graphs
(i.e.
it
is not
other versions)
and is
a
connected
with
member of class
'null'
in all partitions.
is assigned
Finally
'versl'
'unchecked'
by the command
chip
into
to the
class
SAIPT-VERS
consistencyIN cpa
POOR
TOunchecked
WRRRE
id = ‘versl’
DEPINE-OBJECT
cpu
IN chip-design
When
the
structures
chip-design
this
cpu
A version
object
is
inserted
existing
in
the
automatically
are
the
Instead
of
more complex
provided
at
above series
of commands a
INSERT command
be
can
level
3 of
the
general
This enables
the
user
to
version
concept.
version
into all structures
of
insert
the
the object
simultaneously.
the
version
environment
created
for
object.
is
inserted
into
the
database
by
INSERT-VERS
versl
INTOcpu : (1)
-322-
The structure
of
repeated
insertions
follows:
the
object
ceu
of new versions
after
is as
Fig.
1
: The
object
DEFINE-VIEW
oy-cpu
ONchip-designC
WITSeleaents : SELECT-VERS
V
FROM
C
NAERE
class IN consistencyIV1 = 'cons'
derivation-graph
WITHCRAPS
SOURCE : SELECT-VERS
V_pred
PROH
C
WEREV-pred in elements
DESTINATION:
SELECT-VERS
V-succ
PROH
C
WHERE
V-WCCin elements
ANDV-predIN pred' in history-graph(V-succl
ANDNOTEXISTS(SELECT-VERS
V-between
PROIIC
MEREV-betweenin elements
4ND V-betweenIN
cpu
may not
only
select
versions
by
The user
qualification
but
also
by
attribute
exploiting
the
version
structures.
Direct
versions
predecessors
and
successors
of
found
in
means of
can be
graphs
by
the
operations
succ
and pred,
succ*
and pred*
corresponding
transitive
closure
are the
membership
operations.
In
partitions
the
in
class
can
be
of a version
a certain
checked.
pred' in history-graphfV_succl
AND V-betweenIN
WCC'in history-graphiV_predl
view object
'my-cpu'
versions
Within
the
connected
to
each
V-pred
and
V-succ
are
V--pred
is
the
predecessor
of
other
if
V succ
in
the
history-graph
and
there
consistent
version
between
them
exists
no
(V-between).
the following
complex
query
might
be
Thus,
formulated:
Find
all
consistent
versions
'Miller'
which
of designer
were
created
'vers-xy'
and
have
not
been
later
than
developed
to newer versions
yet.
In
environment
object
of
Note:
SELECT-VERS
8
this
example
variable
'c'
the environment.
PROII
cpuz
WAERE
class Ill consistencyiI1 =‘cont’
AND Z.designer: 'Hiller
use
we
representing
an
any
n
AND (SELECT-VERS
*
PROH
cpu
MEREid = ‘vers-xy’l IN ipred’ IN tine-list(ZlI
ANDNOTEXISTS(succIN history-graph(Zll
4.2
Advanced
mechanisms
for
Fig.
2:
View with
and their
all
consistent
versions
derivation
history
adaptation
Constraints
version
above
proposed
model
The
graphs
and partitions
provides
supporting
possibilities
to represent
various
version
concepts
needed
in practice.
But not every
individual
user
needs to see all
resulting
version
structures,
and
sometimes
the
general
model
provides
more
than
the
requires
to
represent
application
its
Therefore,
level
3
specific
environment.
version
offers
operations
to
adapt
the
model to the demands of the environment.
Views
operations
constraints
on
BY imposing
there
are
further
possibilities
to define
Any command
concepts.
specialized
version
model
the
general
version
may
be
of
DISALLOW for all
restricted
by
a command
version
environments
in the system
as well
individual
environments
only.
as
for
Operations
may either
be prevented
totally
apply
to specific
restriction
may
or the
DISALLOW is a
states
of
data only.
Thus,
define
integrity
constraints
for
means to
version
sets
and their
structures.
instance,
no
partitions
are used
for
If,
operations
for
in
an
environment,
all
partitions
will
be disallowed.
Thus,
three
simple
commands establish
a graph
oriented
version
concept.
assume,
a user wants
to work only
Let us
he
is
consistent
versions,
and
with
interested
in the derivation
history
only.
version
structures
Thus,
two
of the chip
design
environment
are useless
to him.
It
is convenient
to define
a view
on
the
version
and
its
version
basic
set
which
structures
corresponds
to
his
understanding
of
the object.
Fig.
2 shows
view
resulting
from
the
following
the
command:
environment
it would
be convenient
In our
the graph
structure
time-list
to restrict
of a new
list.
The creation
to a linear
the source
version
prevented
if
edge is
-323-
has
has
a successor
a predecessor:
or
the
destination
version
DEFINE-TRANSACTION
chip-design-insert (new-version)
WITAvers id
INM obj_id APTERpred-vera
DISALLOW
FORchip-design
CONNECT-VERS
INSERT-VERS
vers-id
PORtine-list IN chip-design X
SOIJRCE : SELECT-VERS
Y
PROIIx
MEREEXISTS lsucc in time-list
INTOobj id : (new version)
(YII
CONNECT-VERS
IN history-graph OFobj-id
SOURCE : pred ver6
DESTINATION : SELECT-VERS9J
PROHx
MERE EXISTSlpred in time-list
1211
DESTINATION : SELE6T-VERS’
PROHohj-id
operation
DISALLOW
can also
enforce
a
certain
discipline
on
the
handling
of
partitions.
In
our example
we assume that
the
design
process
allows
moving
of
versions
between
classes
only
in
the
sequence
unchecked
-> test
a -> test-b
->
cons,
or
from any
class
into
unchecked.
The
This
is
formulated
MEREid : vers-id
CONNECT-VERS
IN tine-livt OFobj-id
SOURCE : SELECT-VERSY
PROHobj-id Y
MERENOTEXISTSlsucc in tine-list(Yl1
by
DESTINATION : SELECT-VERS’
FRONohj-id
DISALLOW
WAERE
id = vers-id
SAIPT-VERSION
POR
consistencyIN chip-design
TOtest-a PUERE
class in consistency : test-b
SHIFT-VERS
FORconsistency IN obj-id
TO unchecked
WERE id = vers id
or cons
TO test-b WAEREclass in consistency = unchecked or cons
TOcons !#iEREclass in consistency = unchecked or test-a
Any
allowable
sequence
of
transitions
may
way. In the following
chapter
we
mechanisms
which,
in
addition,
allow
to control
which
program
a database
update.
Thus,
it can be
causes
guaranteed
that
the transitions
are
caused
and
not.
by
only
by
the
respective
tools
users
at
their
will.
This
enables
the
system
to ensure
operational
integrity.
be
in this
introduce
defined
Complex
operations
As illustrated
by our
example
it
is often
necessary
to
of several
apply
a sequence
basic
operations
in order
to insert
a new
version
into
all
existing
structures.
To
make this
series
of
operations
available
as one
unit,
the single
operations
can be
hidden
in
a complex
operation
called
transaction.
To provide
we
can
a high-level
define
CHIP-DESIGN-INSERT,
The call
of
insert
the
as
shown
Fig.
3.
CHIP DESIGNINSERT (I)
WITH ‘ver& ’
INTO cpu
APTER
(SELECT-VERS
'
PROM
cpu
WHEREdesigner = ‘Hiller’
corresponds
chapter
4.
linked
by
definer
of
INTO,
AFTER)
Transactions
may
call
basic
operations
as
Thus,
the
well
as
other
transactions.
regarded
as
the
basic
operations
can be
are
also
most
simple
transactions
and
visible
at the
user
interface.
In order
to
the
provide
the
user
with
very
transactions
he
is allowed
to use,
access
rights
are
imposed
on transactions.
In our
example
no
user
might,
for instance,
be
allowed
to
use the basic
operation
INSERT
that
new
are
to
ensure
CPU versions
version
structures
inserted
into
all
inserted
only
correctly.
Versions
may be
command
CHIP-DESIGN-INSERT.
by the complex
5.
Embedding
application
tools
Another
aim
of the
general
version
model
guarantee
what we call
'operational
is to
that
for
instance,
integrity'.
Assume,
newly
designed
circuits
must be checked
by
simulation
programs
sim-a,
the
three
in this
order.
Success
or
sim b, sim cons,
a simulation
is expressed
by a
failure
ofversion
corresponding
transition
of
the
within
the partition
'consistency'.
operation,
transaction
in
Pig. 3: Definition of transaction ‘CLIIP~DESIGN~INSERT’
________________________________________--------------------
not
only
to
Operational
integrity
has
transitions
but
has to
guarantee
correct
caused
ensure
that
the
transitions
are
the
results
of
the
exclusively
by
requires
the
simulation
packages.
This
system
to control
the programs
causing
the
the
transitions
between
classes,
i.e.
programs
must be part
of the transactions.
AND tine = ‘1-28-86’1
to the sequence
of commands
in
Parameters
of transactions
are
keywords
determined
by
the
transaction
the
(here
WITH,
to show its
semantics.
-324-
6.
definition
of
In
principle,
the
these
transactions
demands
a tool
as powerful
as
usual
programming
languages,
which
structures
as
provides
control
branches,
subroutines,
authors
etc.
Several
loops,
these
mechanisms
explicitly
offer
with
their
data
models
/BrRi/,
/KiMc/
/MyBW/
/AlCO/.
programs
the
repres.
into
our
following
variants
revisions
FORchip-design
IMPORTSOURFRO!!
(file-nameI)
code PROH
(file_nane2)
dot FRO!!
(file-nane3)
and
commands import
simulate-c.
by
object
DEPINE-TRANSACTION
simulate-a
Corresponding
simulate-b
models
The version
structure
defined
in
/Lock/
one version
may be
realized
with
graph.
The figures
4a and 4b show two alternative
structures
of
with
the
the graph
second
one more
explicitly
expressing
the
time
sequence
of
versions.
In
both
graph
representations,
alternatives
and
revisions
are
characterized
by respective
classes
of
a partition.
Constraints
(by
used
to
describe
the
DISALLOW)
are
specific
appearance
of the graph.
The application
programs
stored
as
are
in the
database.
Further
string
objects
information,
e.g.
documentation,
source,
Imported
application
etc,
may
be added.
the status
of a transaction,
programs
get
that
they may contain
other
which
implies
transactions.
the simulation
environment,
are necessary:
version
After
description
of
the
the
general
version
model,
we now briefly
show how the
specific
version
concepts
of chapter
2 can
be implemented
by
version
environments.
Obviously
the
time
relationships
used in
commercial
and
e.g.
applications,
/Must/,
can
be modeled
by using
versiii
graphs
restricted
to linear
lists.
For many
practical
objects,
however,
the
idea
lead
to
following
simple
may
results:
version
satisfactory
A
informed
about
application
environment
is
treats
them as transactions.
programs
and
operations
of the environment
Thereby
the
expanded
by
the
applicable
design
are
tools.
This
that
allows
to
ensure
the
database
may
only
be
modified
via
these
tools.
To import
example
commands
Representing
some
version
environments
(a)
Fig.
the
(b)
4:
Graph structure
model
in /Lock/
to
represent
the
programs
To model the version
structures
of /KaLe/,
environment
is
defined,
a version
which
for
has a partition
with
classes
every
Moreover,
there
version
state.
exists
a
version
graph
in form of a linear
list.
It
versions
with
respect
to their
orders
all
the
creation
time
to
record
state
transitions
and
to
support
the
time
related
queries
specified
in
/KaLe/.
the graph
and the partition
Operations
on
the
allowable
are
restricted
as
to
the derivation
transitions.
For
instance,
inpermitted
from
of
alternatives
is
only;
progress-versions
and
alternatives
into
class
versions
be
moved
can
'released'
from class
'effective'
only.
summarize,
transactions
look
as
To
follows:
Transactions
consist
of
basic
operations,
subtransactions
imported
and
environment
application
programs.
The
selection
administrator
places
a certain
of transactions
at the users'
disposal
by
means of granting
access
rights.
Access
to
the data
is exclusively
allowed
by these
transactions.
application
programs
serves
two
Import
of
aims:
On the one hand,
control
structures
of programming
languages
may
be used
in
transactions,
on
the definition
of
the
other,
the
tools
of
the application
are
the version
environment.
This
may
tied
to
version
be
regarded
as
a
from
step
environments'
environments
to 'application
which
presents
themselves
as
a set
of
versioned
objects
with
the
version
same
structures
and
the operations
and
tools
manipulating
Thus,
for
them.
an
application
environment
may be
seen as a
system
class
of
an
object
oriented
defining
structure
and
operations
which
are inherited
by its
instances.
is proposed
in
flexible
concept
The most
is the only
model known to the
/DiLo/.
It
allows
the
adaptation
of
authors,
which
the version
management
to the application.
clusters
can
be
The
structure
of
the general
version
model
represented
in
by one or more partitions.
By indirections
structures
it
is
obtain
possible
to
similiar
to version
graphs
in /DiLo/,
too.
But the explicit
representation
of version
graphs
in our general
version
model allows
-325-
the
user
to
express
the
ordering
relationships
of
his
versions
more
directly
and
to deal
easier
with
them.
Furthermore
the distinction
between
graphs
and partitions
seems to
be
advantageous
with
respect
to the
implementation
since
specific
structuring
mechanisms
can
be
supported
more efficiently
at lower
levels
of the system
architecture.
build
up
by
versions
identified
by
denoting
the
class
to
which
they
belong.
For instance,
an object
may be composed
of
the
valid
versions
of
its
subobjects.
Thus,
objects
may
be
composed
of
subobjects
in a very
flexible
way by using
the possibilities
of the
general
version
concept.
Literature
7.
Conclusion
In this
paper
we have introduced
a general
version
model
expressed
by the concept
of
version
environments.
A
version
environment
offers
two
mechanisms
for
structuring
the
version
sets
of objects:
graphs
and
partitions.
By
the
use
of
views,
constraints
and
transactions
the
version
environment
may
be
tailored
to
specific
user
requirements.
The embedding
of
application
tools
into
version
the
environment
provides
the users
with
their
specific
application
environment
which
consists
of
the
objects,
version
their
structures
and
the
tools
operating
on
them.
The proposed
concept
is more general
and
more
powerful
than
the
concepts
published
so
far;
it
has been shown,
how
known
well
version
concepts
can
be
implemented
by
means
version
of
environments.
The
general
version
concept
is
to
be
implemented
in
connection
with
the
AIMproject
(/Dada/,
/Lum/)
at IBM Scientific
Center,
Heidelberg.
Their
NF2
relations
together
with
a basic
time version
concept
/DaLW/
seem
to
be
a good
basis
for
efficient
implementation.
The
main
problems
currently
are
physical
the
representation
of
versions
and mechanisms
to support
graphs
and partitions
at lower
levels
of
the database
system
by storage
structures
and access
paths.
The version
model proposed
in this
paper
cannot
alone.
It
stand
has
to
be
integrated
into
a broader
context
which
considers
that
objects
are
very
complex,
composed
of
other
objects
and can be seen
different
points
of
view
from
for
(representations,
see
instance
/Neum/).
This
leads
to a three-dimensional
concept
of
(composed)
objects,
representations,
and versions
(for
objects
and representations).
versions
composed
To
integrate
and
instance,
the
objects,
for
basic
idea
is
have
(part-of-)relationships
between
to
versions.
objects,
i.e.
sets
of
To
the
specific
versions
bound
identify
together
the structuring
mechanisms
of the
introduced
version
concept
are used.
Thus,
an object
may be
composed
of
specified
versions
of other
'abstract
objects'
or is
-326
/AlCO/
Albano,
A.,
Cardelli,
C.
Orsini,
R.:
Galileo:
A Strongly-Typed,
Interactive
Conceptual
Language.
TODS 10, June 1985
/BaKi/
Batory,
D.S. and Kim, W.:
Concepts
for
VLSI CAD Objects.
10, Sept.
1985
and
ACM
Modelling
ACM TODS
/BrRi/
Brodie,
M.L. and Ridjanovic,
D.: On
the Design
and Specification
of Database
Transactions.
On Conceptual
Modelling,
Springer
1984
/Dada/
Dadam,
to support
integrated
hierachies.
1986
P., et.al.:
A dbms prototype
extended
NFZ-relations:
An
view
on
flat
tables
and
ACM-SIGMOD,
Washington
Proc.
Lum, V. and Werner,
/DaLW/ Dadam, P.,
versions
D .: Integration
of time
relational
database
systems.
Proc.
VLDB, Singapore
1984
/DiLo/
Dittrich,
K.R.
Lorie,
and
Version
support
for
engineering
base systems.
IBM Research
Report
(50628),
San Jose 1985
/Hard/
Harder,
T.:
Considerations
time
modelling
and
integrating
temporal
database
systems.
University
Kaiserslautern,
Rep.
No.
19/84
German)
/KACh/
Katz,R.H.,
E . : A Version
Design
Data.
University
of
H.into
10th
R.A.:
data
RJ4769
on
into
of
(in
Anwaruddin,M.
and Chang,
Server
fo r Computer-Aided
Report
No. UCB/CSD 86/266,
California
1985
, Berkeley
Lehmann
/KaLe/
Katz,R.H.;
Support
for
Versions
and
Large
Design
Files,
IEEE
Software
Engineering
10
T.J.:
Database
Alternatives
of
Transactions
on
March 1984)
/KiBa/
Kim, W. and Batory,
D.S.:
A Model
Technique
for
Versions
of
and Storage
VLSI CAD Objects.
Proc.
"Foundations
of
Data Organization",
Kyoto
1985
/KiMc/
King,
and
Model
Database
Modelling,
and McLeod,
D.: A Unified
R.
Methodology
for
Conceptual
Design.
On
Conceptual
Springer
1984
/KSUW/ Klahold,P.,Schlageter,G.,
Unland,R.
and
Wilkes,W.:
A transaction
model
supporting
complex
applications
in
integrated
information
systems.
Proc.
ACM-SIGMOD 1985
DELETE-CRAPA
PROH
(eid) : (gid) .
CONNECT-VERS
FOR(gid) IN (oid)
SODRCE: Iversion-setof toid))
DESTINATION:
(version-setof (oid)l
/Lock/
Lockemann,
P.C.,
et.al.:
Requirements
of
technical
applications
to
database
systems.
Proc.
"Database
office,
engineering
systems
for
and
sciencell,
Springer
1985 (in German)
/Lum/
Lum,V.:
to
support
"Foundations
1985
DISCONNECT-VERS
FOR(gid) IN (oid)
SODRCE
:
(version-setof (oid)l
DESTINATION
:(version-set of (oid)l
Design
of an integrated
DBMS
advanced
applications.
of Data Organization"
Kyoto
/MiiSt/
Miiller,
Th.
and Steinbauer,
D.: A
language
interface
for
version
control
CAM
in
databases.
Proc.
"GIJahrestagung,
Sprachen
fiir
Datenbanken",
Springer
1983 (in German)
/MyBW/ Mylopoulos,
Wang, H.K.T.:
Designing
Applications.
J.,
Berstein,
P.A.
A Language
Facility
Database-Intensive
ACM TODS 5, June 1980
and
for
Operations
of
version
concept
the
(gid)
(gid)
(gid)
(gid)
(version-setof
(version-setof
(version-setof
(version-setof
(oid)l
(oid)l
(oid)l
(oid)l
level 1: Operationafor partitioov
DEFINE-PARTITIOR
FOR(eid) : (pid)
DELETK-PART
PROH
(eid) : (pid)
DEPINE-CLASS
FOR(pid) IN (eid) : hid,....)
/Neum/ Neumann,
T.:
On representing
the
design
information
in a common database.
Engineering
Design
Applications,
Database
Week, SIGMOD 1983
Appendix:
pred in
pred’ in
GUCCin
IUCC’in
SAIPT-VERS
FOR(pid) IN (oid)
10 hid)
MERE(qualification)
DELRTE-CLASS
RON(pid) IN (eid) : (cid)
general
Classin (pid) Iversiowset of oidl
DRFINE-ENVIROMENT
(eid)
DELETE-ENVIKORHEIII
(eid)
Level 3:
Level 1:
DEPINK-VIeW
hale)
ON(eid) (obj-var)
WITRelewnts : (version-setof (obj-var)l
WITRPartition (pid) lclass:(cidl),,(cidn)l
WBERR
tcidl = (version-setof elemental
DBPINI-Okl
(aid) IN (eid)
DELETE-OBJ
(oid)
INSERT-VRRS
hid)
INTO(oid) : (11
cidn - (version-setof elements11
WITR
Graph(gid)
SODRCE : (version-setof eleaentsl
DRSTINATION
: (version-setof eleaent8I
SELECT-VERS
’
FROH
(oid)
WAERE
lqualificationl
DISALLOW
(operation)
DELBTE-VW
PROH
(oid)
PARWE
(qualification1
DEFINE-TRANSACTION
(tid) Ikeyuordt(par)..
FOR(eid) : sequence
of transactionsandbasic operations
DPDATE-VERS
FROH
(oid)
SET(11
WAERE
(qualification1
Level I:
DEPINE-TRANSACTIOR
(tid)
FOR(eid)
IllPORT
SODRCE
FRDII
(file-name)
CODKPROI!
(file-name)
(file-name)
WC PROU
Level 2: Operationsfor graph
DEFINE-GRAPR
POOR
(eid) : (gid)
--327-