A General Model for Version Management in Databases

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

in and

this paper .

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-