INFORMATION SYSTEM ENGINEERING THE RUBIS SYSTEM C. CAUVET *, C. ROLLAND *. J.Y. LINGAT ** * Unive~site Pa~is 1 UFR 06 17, Rue de la So~bonne 75231 PARIS Cedex 5 FRANCE ** THOM'6 33, ~ue Vouille 75015 PARIS FRANCE ABSTRACT: The pape~aims to p~esent a CASE system which is an integ~ated compute~ aided tool so-called RUBIS, fo~ designing and p~ototyping Info~mation Systems. RUBIS is o~ganized a~ound the R-schema (RUBIS-schema), which is a decla~ative specification of the Info~mation System (IS) content, based on a conceptual model which emphasizes equally the IS st~uctu~e and behaviou~. Afte~ a b~ief ove~view of the RUBIS a~chitectu~e, we p~esent th~ough examples how to const~uct the R-schema using PROQUEL: the fo~mal specification language of RUBIS. Then, we concent~ate on two diffe~ent aspects of RUBIS: the expe~t design tool, which helps the designe~ to p~oduce the R-schema fo~ a given application domain, and the p~ototyping tool, which allows the execution of specifications on test case data. l 1. INTRODUCTION The pape~ aims to p~esent an integ~ated compute~ aided tool so-called RUBIS [33], fo~ designing and p~ototyping Info~mation Systems (IS). RUBIS wo~ks on a R-schema (RUBIS-schema) which is a decla~ative specification of the IS, made using the fo~mal specification language called PROQUEL (PROg~amming QUE~y Language) [34]. The R-schema p~ovides a conceptual desc~iption of both the static and dynamic aspects of the IS to be built. It is based on the REMORA model [1]. The static IS aspects a~e modelled by ~elations while ope~ations (elementa~y actions on an object) and events (elementa~y state changes t~igge~ing one o~ seve~al ope~ations) allow the modelling of the dynamic aspects of objects. Thus, the R-schema is a collection of ~elations, ope~ations and events specifications. In this schema the tempo~al aspects of the application a~e also taken into account; they ( a~e modelled by using the time types and functions p~ovided by the RUBIS Time Model. { RUBIS includes th~ee diffe~ent inte~faces as compute~ aided design tools: a G~aphic Inte~face using an icon-based ~ep~esentation of the R-schema concepts. - an Expe~t Design Tool wo~king on a semantic network, and helping the designe~ to cr-eate, validate and imp~ove the conceptual schema. - a Menu Inte~face based on the PROQUEL language. The G~aphic and Menu based inte~faces a~e both devoted to expe~ienced designe~s while the Expe~t Design Inte~face can be used by ~elatively unexpe~ienced analysts o~ designe~s. P~ototyping in RUBIS is achieved by the Tempo~al P~ocesso~ which manages tempo~al aspects of the specification and by the Event Processor which manages event recognition and synchronization. 80th P~ocesso~s use the PROQUEL inte~p~eter. Thus the PROQUEL Inte~preter, the Event P~ocessor and the Tempo~al Processo~ are the key tools for prototyping information systems with RUBIS. They have been implemented as extensions of a Relational DBMS [2] • The paper is organized as follows: The global architecture of RUBIS is given in section 2 with a brief desc~iption of the diffe~ent RUBIS system modules. Section 3 p~esents how to specify the R-schema using the PROQUEL language. Then, the pape~ focusses in section 4 on one of the th~ee inte~faces, namely the Expe~t Design Inte~face. The Event P~ocessor is detailed in section 5. 2 2. RUBIS ·ARCHITECTURE The architecture of the RUBIS system is presented in figure 2.1. This displays the three major aspects of the system, which arel 1. The (meta) data mananagement tools which handle the prototype database and the specification database (containing the R schema) . 2. The R-Schema design interfaces and the Validation Module. 3. The proto typing tools - the Application Monitor, the Event Processor and the Temporal Pr-ocessor-. Each of these three aspects is introduced in turn. o ( specification ,,, 1 experi7 ·,entation I .. ·APt:'~!9ATlqN . . :... . MONITOR· : . . ....EVENT ....... ·.TEMPORAL;: .. . . PRotEssqR gr-ouping edge ( AC ) operation node 9 gener-alization ) edge / EV / event node CL> tex t node 4.3.1 Semantic meaning of nodes - A domain node r-epr-esents a data type. It is used for- the r-epr-esentation of entity pr-oper-ties, oper-ation par-ameter-s and event contexts. A book number, a subscriber name are examples of domains. - An entity node modelizes an entity type of the application domain, such as a book, a request, a subscriber . . . - An operation node represents an action type. The action of a given type modify entities belonging to the same type. For- example a request analysis, a new book insertion are described in the semantic networ-k with oper-ation nodes. - An event node descr-ibes state changes of the r-eal wor-Id that tr-igger- executions of similar- oper-ations. A book is just ar-r-ived, instance of book becomes available, ar-e examples of event types. 13 - A text node is a predicate declaration that completes the description either of an operation (triggering condition of an operation for instance) or of an event (event predicate) or of an entity (entity constraint). If the real situation is that a copy can be loaned only if (a) "the copy is available and the subscriber is in good standing", the condition (a) should be described in the semantic network using a text type node. 4.3.2 Semantic meaning of edges The aggregation, grouping generalization abstraction forms are and respectively represented by the "a", "r" and g " edges. "a", "r" and Il "g" edges apply to domain, entity, operation and event nodes. - An aggregation edge (edge a) may be defined either between two nodes of the same type or between two nodes of distinct types. ( On example 1, subscribers are described as aggregate objects with 3 components: SUBSC#, NAME and ADDRESS. I I SUBSCRIBER ~(a,id) a ~ NAM Aggregate components can be domain nodes or entity nodes. The "id" label precises the aggregate identifier (SUBSC# in the example). - A grouping edge (edge r) is defined between two nodes of the same type. In the example below, a book is defined as a complex object; one of its components (STOCK) is a collection object. Every member of the collection is a copy. This means that a book in a library has usually several copies. (a,id) a I BO~K# I - A generalization edge (edge g) is used for the representation of a "i s-a" re I a tionshi p. An edge of type g is def ined between two nodes of the same type. For example a copy can have three possible states; used, available and reserved described as 3 object nodes related to 14 the copy node by three "g" edges. COpy g gt g COpy I COpy , COPY USED AVAILABLE I RESERVEC J NOTE: In order to reach a good conceptual schema (criteria for "good" schema are presented in [30]), we have associated constraints (or norms) to nodes and edges of the semantic network which are part of their definition. We illustrate some of the norms with examples. N1: Object identification We consider as a good design discipline to identify each object of a conceptual schema. Thus, any entity node must have an in-going "id" ( labelled edge (see example 1). N2: Operation atomicity Operation atomicity (one operation is defined as acting on one and only one entity type) is required in the semantic network. Operation atomicity avoids ~edundancy in p~ocess desc~iption and thus inconsistency in process execution. Consequently an operation node is always origine of one "a" edge with an entity node as target node. N3: Node I edge types compatibility norms These norms avoid inconsistencies in the object constructions. The following figure represents the autorized edge types between two node types. DOMAIN ENTITY OPERATI . EVENT TEXT DOMAIN a r g a ( ENTITY a r g a a OPERATION a r g a EVENT a r g TEXT a a a a Figure 4.3 15 , N4: Cardinality norms Cardinality norms are based on an extended notion of cardinality as introduced in the E/R Model [31]. Let f be a function coupled with a "a" or "r type edge. For two ll entity nodes (called A and B in the following), the f and f-1 functions can be characterized by the three following properties. - totalness. A function f is total (t) if and only if each instance of A is associated with at least one instance of B at any point of time, else the function is partial (p). - valuation. A function f is single (s) if and only if each instance of A is associated with at most one instance of B at any point of time, else the function is multiple (m). .:... permanency. The function is permanent (p) if and only if the set of instances of B associated to an instance a of A, at a time t is included in the set of instances of B associated to a at a time t' ( t ' > t ), else the function is variable (v). All combinations of properties are not allowed. The matrix on figure 4.4 summarized valid combinations of cardinalities. For instance the couple of cardinalities for a "r" edge is allowed. Let us take an example, the function between the nodes STOCK and BOOK is total ( t ) , multiple (m) and permanent (p), its opposite is total (t), simple (s) and permanent (p). This function can be associated with an "r lt edge in the network. tsp tsv tmp tmv psp psv pmp pmv tsp a a a a tsv a a a a tmp r tmv psp psv pmp pmv Figure 4.4 4.4 The transformer base of rules In order to help the designer to progressively improve the content of the semantic network during the design stage, the semantic network transformer uses essentially three classes of rules: diagnosis rules, improvement rules, mapping rules. 16 Let us concent~ate and examplify the two fi~st classes (mapping ~ules a~e used to map nodes and edges of the semantic netwo~k onto R-schema elements and a~e quite usual). 4.4.1 Diagnosis ~ules Diagnosis ~ules playa double ~ole; they automatically detect e~~o~s in the semantic netwo~k and p~opose one (o~ seve~al) solution(s) to co~~ect each type of e~~o~. Thus, using diagnosis ~ules, the t~anfo~me~ is both a p~eventive and a c~eative tool. E~~o~ detection is based on six design aspects, to which we have associated six g~oups of diagnosis ~ules. - (a) object identification, (b) entity st~uctu~ation, - (c) event and ope~ation st~uctu~ation, (d) semantic netwo~k consistency, - (e) semantic netwo~k completeness, (f) semantic netwo~k co~~ectness. Rules of type (a) and (b) a~e illust~ated by examples. Figu~e (1) desc~ibes pa~t of a semantic netwo~k which will be detected as inco~~ect because of the non-identification of the AUTHOR enti ty node (the object identification no~m N1 is violated). (a,id) (a,id) BOOK rJo~i1 8 AUT~OR ~€g (a,id) a a (3 ) (1 ) tB~KiJ Thus, the SNT will p~opose two alte~native acceptable solutions: - Eithe~ to t~ansfo~m AUTHOR into a domain node (2), - o~ to leave AUTHOR as an entity node, but necessa~ily I identified by a domain node (AUTHII) (3). The diagnosis / co~~ection p~ocess is an inte~active one. The SNT I 17 will instance fo~ in the p~evious case, explain to the designe~ (if ~equi~ed) that in the fi~st solution autho~s will be conside~ed only as p~ope~ty of books and not as independant entities. In the following example the semantic netwo~k content illust~ated in ( I ), means: 6 a copy may be used by any subsc~ibe~, a copy may be used at most one subsc~ibe~, a copy may be used by distinct subsc~ibe~s at distinct times. - a subsc~ibe~ may bo~~ow any book, a subscriber may borrow several books, a subsc~ibe~ may bo~~ow diffe~ent books. This content is detected as inco~~ect (the type of the a~c is not valid acco~ding the cardinality no~ms). Thus the SNT proposes an alte~native description (2). The new entity LOAN is introduced as an aggregate entity with the two COPY and SUBSCRIBER entity nodes as components. The cardinalities of the two new edges are ; that is acceptable according to entity structuration rules. Of cou~se the interactive process will be activated in orde~ to complete the description of the new node LOAN. 4.4.2 Improvement ~ules These rules aim at giving facilities to improve the semantic netwo~k content. Cont~a~ily to diagnostic ~ules, imp~ovement rules apply on valid parts of the semantic network. Basically these rules are formalization of design expert heuristics infered from the designer practical experience. They are based on pattern recognition and suggest for each initial pattern of the semantic network a more sophisticated one (or several alternative ones) according to some specific design discipline. For instance as we will illustrate later the SNT can try to sophisticate the representation of enti ty classes using 18 specialization; or it can suggest a more complete representation of entities based on temporal reasoning; or even combine these two aspects. Improvement rules relate to: historization of entities and relationships, specialization (of entity, event and operation types), behaviour completion, - domain structuration. Similarly to diagnosis rules, improvement rules identify a specific pattern in the semantic network and propose to the designer one or several improved representations pointing out some, may be; forbidden or undertaken design problem. Let us give two examples of semantic network transformations. ( Situation (1) corresponds to a pattern identified with a <:,...,--------< \ "./ OPn Rk b----- OPn The notation used to represent an induction is EVi--)EVj 5.2 The Induction Graph construction The Induction Graph uses the above notation. It contains - nodes representing R-schema events, directed edges representing inductions, weights on the edges, which represent operations and are used as " induction condi tion-s". The Induction Graph construction is accomplished in two steps: - an automatic step, producing the Maximal Induction Graph, a manual step transforming the Maximal Induction Graph into the Induction Graph. 22 1st STEP The Maximal Induction Graph can be automatically deduced from the R- schema - "a priori possible chainings" are obtained by analysing the ON, TYPE and TRIGGER parts of event and operation specifications. For a given event EVi, the chain is composed of all those events ascertaining relations modified by the operations triggered by EVi, in order to keep only "structurally possible chainings", the occurrence of each operation's TYPE (INSERT, DELETE, UPDATE) is checked within the ON part (i.e the category) of the internal event(s) it seems to induce. So, impossible chainings like "a product deletion produces a new availability" will be removed from the graph. ( Figure 5.1 presents the induction graph corresponding to our case study. ( Figure 5.1 A Maximal Induction Graph 2nd STEP The designer then manually modifies the Maximal Induction Graph, until he obtains the final Induction Graph. During this step, the designer removes all the chainings that seem impossible to him from the graph. For example, EV4 ("loan request") seems to induce EVe ("copy availability"). This is because EV4 triggers a modify operation on COpy (ope) and EVe recognizes insertions or modifications of the COPY status. In reality, an EV4 occurrence will never generate an EVe occurrence since ope always put the COPY status to "LOANED", and EVe only recognizes modifications setting a COPY status to "AVAILABLE". This kind of "false induction" cannot be detected automatically since it involves a semantical interpretation of predicates, conditions, factors and operations. The final Induction Graph is an optimized and generally non-connected graph, which contains only "semantically possible chainings". Figure 5.2 presents the Induction Graph corresponding to the Maximal Induction Graph of figure 5.1. If there are cycles in the Induction Graph, they are detected automatically, and the designer is asked to a confirm an "impossible endless loopll. 23 EV1 ~ ~2 EV3 ~EV4 OP5l~ ~P8 EV6 EV8 EV7 Figure 5.2 Induction Graph 5.3 Internal event chaining strategy Given an exte~nal or temporal event to be processed, the chosen strategy is based on a llbreadth-first" traversa I of the even t Induction sub-graph. ** The induction sub-graph of an event is the maximal connected component, whose root is the event concerned. 8y using this kind of sub-graph when an external or temporal event EVi occurs, the Event Processor can lear"n immediately what "the set of internal events it will probably have to process" is. This set of internal events is called the EVi Induction Class and is written C(EVi). For example, referring to figure 5.2, the EV1 Induction Class is : C(EV1) = { EV3, EV4, EV6, EV7, EV8 ) ** The internal event sequence construction is based on a breadth- first traversal of the Induction sub-graph. ( EV1 ) 1st cycle ~ ~ ( EV3"' EV4 ) 2nd cycle OP5/ ~7 op8 ( EV6 'EV8 EV7 ) 3rd cycle Figure 5.3 : Internal event sequence For example, if EV1 occurs, the complete processing cycle will include 1s t c yc Ie: EV 1 2nd cycle: EV3 + EV4 3rd cycle: EV6 + EV7 + EV8 It means that within each cycle, all events from the same level are processed. 24 The "breadth-first" strategy (e.g EV1, EV3+EV4, EV6+EV7+EVSl has a real advantage over a "depth-first" (EV1, EV3, EV6, EV4, EV7) or a "random" strategy (EV1, EV3, EVS, EV4, EV7, EV6). In fact, this strategy permits optimal management of the input/output implicit parameters. Idle time between gener-ation of an "oper-ation output parameter", and its use as input parameter to process the event induced by this operation, is minimal. Internal events are recognized as soon as "noticeable state changes" occur (in fact just after all operations triggered at the same level have been executed); and these events are processed as soon as they are recognized (i.e during the next basic cycle of the event processor). ( In this manner, there is no parameter waiting for use during a complete basic cycle. This is not true with other strategies; for instance, in the "depth-first" strategy, the EV4 input parameters must be kept in memory as long as EV3 and EV6 are still being processed. The purpose of the Induction Graph is an optimization of the Event Processor work. For example, refering to figure 5.2, during the processing of ev2, if OP4 isn't in the list of operations to execute, a whole part of the EV2 Induction sub-graph can be pruned off O~EV~ EV~ EV5 opS \ OP9! ~p~ EV7 EV9 EVI0 So it permits: .. avoidance of useless predicate tests (EV5, EV9, EVIO), - avoidance of useless parameter recording, - an earlier freeing of resources ("read-Iocked" relations for predicate, condition and facto,.- evaluation; "write-locked" relations for ope,.-ation execution). It appears that an external or temporal Induction Class will become smaller and smaller after each basic cycle, and will finally reach the empty state. (another external or temporal event will then be processed. ) At any moment, the Event Processor knows what it is processing and what it must deal with next; so it controls the whole process fully. USING THE PROTOTYPE During the experimentation of the prototype, the Event Processor displays a trace of what it is doing : which events are currently processed or waiting, which conditions are true, which operations 25 have to be executed, and so on. Analysing this t~ace, the designe~ can easily detect if things a~e going w~ong (bad ~esult fo~ a condition, database e~~o~ on a p~edicate evaluation, occu~~ence of a w~ong event, ... ) and immediately co~~ect the e~~o~s, modifying the specifications th~ough one of the design inte~faces. Applying an ite~ative st~ategy, the designe~ will p~og~essively ~efine his specifications until the behaviou~ of the p~ototype is fully co~~ect fo~ him and fo~ the end-users. b. CONCLUSION In this pape~, we have p~esented an integ~ated compute~ aided tool so- ( called RUBIS, fo~ designing and p~ototyping Info~mation Systems. The RUBIS-schema is a decla~ative specification of the IS, made using the fo~mal specification language called PROQUEL (PROg~amming QUE~y Language). The R-schema p~ovides a conceptual desc~iption of both the static and dynamic aspects of the IS to be built. The static IS aspects a~e modelled by ~elations while operations (elementa~y actions on an object) and events (elementa~y state changes t~igge~ing one o~ seve~al ope~ationsJ allow the modelling of the dynamic aspects of objects. Thus, the R-schema is a collection of ~elations, ope~ations and events specifications. In this schema the tempo~al aspects of the application a~e also taken into account; they a~e modelled by using the time types and functions p~ovided by the RUBIS Time Model. RUBIS includes three different interfaces as compute~ aided design tools: a G~aphic Inte~face, an Expe~t Design Tool wo~king on a "complex object" desc~iption of the application domain and a Menu Inte~face based on the PROQUEL language. The G~aphic and Menu based inte~faces a~e both devoted to expe~ienced designe~s while the Expe~t Design Inte~face can be used by ~elatively unexperlenced analysts or designers. P~ototyping inRUBIS is achieved by the Tempo~al P~ocesso~ which manages tempo~alaspects of the specification and by the Event P~ocesso~ which manages event ~ecognition and synch~onization. Both P~ocesso~s use the PROQUEL inte~p~ete~. A fi~st ve~sion of RUBIS is ~unning on SUN Wo~kstation, unde~ the UNIX system. P~ototyping tools a~e w~itten using the C language, and design tools a~e using the X-Windows system. The expe~t design inte~face is pa~tly w~itten in P~olog. Cu~~ent developments a~e leading towa~ds - the development of a functional debugge~ fo~ the p~ototyping aspects; - the extension of PROQUEL to a ~eal pe~sistent language; - the p~ovision fo~ the implementation of code gene~ato~s which will t~anslate the PROQUEL specifications into a ta~get "embedded language" (Pascal/SQL, C/QUEL, ... J; 26 - the development of a graphical interface to manipulate the Semantic Network; - the extention of the expert design interface to include tutorial functionnalities. REFERENCES 1[1J C. ROLLAND, C. RICHARD: The Remora methodology for information 'systems design and management in IFIP WG8.1 working conference on ." Information systems design methodologies: a comparative review" 1982 [2J BOUCHET and al. "Databases for Microcomputers : the PEPIN Approach" ACM SIGMOD/SIGSMALLS, Orlando, Florida, Oct.1981. [3J ROLLAND C, BENCI G, FOUCAUT 0 "Conception de Systemes .d'Information : La Methode REMORA", Eyrolles 1987. [4J BUBENKO J .A. "The temporal dimension in Information Processing" ( in Architecture and Models in Database Management, G.M. NIJSSEN, ed. North-Holland (1977). [5J WIEDERHOLD G., FRIES J.F., WEYL S. "Structured organization of Clinical Databases" Proc. of AFIPS National Computer Conf., Anheim, .1975. ;[6J BOLOUR A., ANDERSON T.L., DEKEYSER L.J. and WONG H.K.T. "The ,role of time in information processing : A survey" ACM SIGMOD RECORD ~ol. 12, nO 3, April 1982. [7) SNODGRASS R. "The temporal query language TQUEL" ACM Transactions On Databases Systems, vol. 12, nO 2, June 1987. [8) NAVATHE S.B., AHMED R. "TSQL: A language interface for history databases" AFCET-IFIP WG8.1 TAIS Conf., Sophia-Antipolis, France, May 1987. [9J CODD E.F. "A Relational Model of Data for Large Shared Data Banks" Communications of the ACM, vol. 13, nO 6, 1970. [10) M.R. GUSTAFSSON, J .A. BUBENKO T. KARLSSON: "A Declarative Approach to Conceptual Information Processing" in IFIP WG8.1 Working Conference on "Information Systems Design Methodologies: a comparative review" 1982. [11) ANDERSON T .L. "Modeling time at the conceptual level" Proc. 2nd International Conf. on Databases, Jerusalem, June 1982. [12) SNODGRASS R., AHN I. "A taxonomy of time in da tabases" Proc. of ACM SIGMOD 85, Mar. 1985. [13) ZLOOF M.M. "Query By Example: a database language" IBM Systems Journal, vol. 16, nO 4,1977. [14) OVERMYER R., STONEBRAKER M. "Implementation of a time-expert in a Database System" ACM SIGMOD RECORDS, vol. 12, nO 3, Apr. 1982. [15J ADIBA M., 8UI QUANG N., PALAZZO J. "Time concepts for generalized data bases" ACM Annual Conference, Denver, Colorado, U. S • A., Dc t. 1985. [16) AHN I . , SNODGRASS R. "Performance evaluation of a Temporal Database Management system" Proc. of ACM SIGMOD Conf., 1986. [17) DADAM P., LUM V., WERNER H.D. "Integration of Time Versions into a Relational Database System" Proc. of 10th VLDB, Singapour, Aug. 1984. [18) ADIBA M., BUI QUANG N. : "Historical multi-media databases" Proc. of 12th VLD8, Kyoto, Japan, Aug. 1986. [19) BARBIC F., PERNICI B. "Time modeling in Office Information· Systems" Proc. of ACM SIGMOD Conf., Austin, Texas, May 1985. [20) CLIFFORD J., RAO A. "A simple general structure for temporal 27 domains" AFCET-IFIP WG8.1 TAIS Conf., Sophia-Antipolis, France, May 1987. [21] BOLOUR A., DEKEYSER L.J. "Abstractions in temporal information" Information Systems, vol. 8, nO 1, 1983 [22] DBE : Data Base Engineering review vol 17, n04, Special issue on data design aids methods and environment, Dec. 84 [23] S. CERI: "Methodologies and Tools for Database Design" ed, North Holland Publ Co 1983. [24] R.P. BRAGGER, A. DUDLER, J. REBSAMEN, C.A. ZEHNDER: "GAMBIT: An interactive Database Design Tool for Data Structures, Integrity Constraints and Transactions" in Database Techniques for Professional Workstations, ETH Zurich 1983. [25] J.M SMITH, C.P. SMITH: Database Abstractions Aggregation. Communications of ACM. June 1977. [26] J.M. SMITH, C.P. SMITH: Database Abstractions Aggregation and Generalization. ACM TRANSACTIONS on Database Systems. June 1977. [27] M.L BRODIE, E. SILVA: Active and Passive Component Modeling: ACM/PCM in IFIP WG8.1 working conference on "Information systems ( design methodologies: a comparative review" 1982. [28] KAHN K., GORRY G. A. : "Mechanizing Temporal Knowledge" Artificial Intelligence, Vol.9, N°l, Aug. 1977. [29] MITTAL S. : "Event-based Organization of temporal Databases" Proc. CSCSI/SCEIO Conf. 82, Saskatoon, Saskatchewan, 17-19 May 1982. [30J CAUVET C. "Un modele et un outil d'aide a la conception des Systemes d'Information" Ph. D. Univ. of Paris 6, Nov. 1988. [31J CHEN P. "The Entity/Relationship model : towards a unified view of data", ACM TODS, Vol 1, nO 1, 1976. [32J NOBECOURT P., ROLLAND C., LINGAT J.Y. : "Temporal management in an extended relational system" 6th British National Conf. on Databases, Cardiff, G.B., July 1988. [33J LINGAT J.Y, NOBECOURT P., ROLLAND C. : "Behaviour management in database applications" VLDB 1987, Brighton, G.B., Sept. 1987. [34J LlNGAT J.Y, COLIGNON P, ROLLAND C. : "Rapid prototyping : the PROQUEL language" VLDB 88, Los Angeles, USA, Sept 88. 2B