Integrity control based on object behaviour

Integrity control based on object behaviour

Mark W.W. Vermeer

Peter M.G. Apers

Dept. of Computer Science University of Twente fvermeer, [email protected] Abstract

As databases are meant to describe real-world situations, the ultimate goal of database integrity control is to ensure that at any moment, the database state corresponds exactly to the current state of the real world. Currently, the speci cation of database integrity is usually based on the formulation of integrity constraints { conditions on database states describing those states considered to correspond to possible real-world states. We observe that constraint-based integrity control can be successful only if considerable knowledge of the real world is available. For many complex application domains, however, this is not the case. We describe how in these contexts, integrity can be de ned by means of a set of trusted basic facts, and procedures which are believed to generate reliable new facts. We then show that the object-oriented data model is well-suited to support this alternative database integrity paradigm. We use an example from the oil industry to illustrate our ideas. A reverse engineering eort of database applications in this industry indicated that the form of integrity control we are addressing is currently coped with within such applications. We discuss the applicability of existing speci cation techniques as a target formalism in this context.

1 Introduction An essential property of databases is that they contain models of phenomena occurring in some application domain. Every state the application domain can be in, is modelled by a corresponding state of the database. Database integrity control is then the task of ensuring that at any time, the state of the database is in accordance with the actual state of the application domain. Work on database integrity control has traditionally focused on rather lucid application domains, with complete information on the state of the real world. In such an environment, data integrity can be de ned by means of rst order logic statements called integrity constraints, describing database states or sequences of database states which are known to correspond to possible states of the application domain. In this paper, however, we focus on application domains for which such statements are not easily de ned. Database integrity constraints can be seen as a form of domain knowledge about the world described by the database. Traditional database application 1

domains are relatively lucid, allowing for the formulation of a powerful set of integrity constraints. More recently however, databases have been used in more complex application domains such as science and design. As discussed in this paper, in such elds the notion of data integrity is usually not expressible using constraints only, due to lack of domain knowledge or the inherent complexity of the real world. The ideas expressed in this paper stem from a reverse engineering eort concerned with extracting database constraints encoded in application software for relational databases employed in oil industry. Due to the complexity of the application domain and the modelling restrictions imposed by the relational model, much of the semantics of the data in such databases is hidden in the application software. Our research is concerned with achieving interoperability for such databases. As explained in [14], the rst step in making such databases interoperable might be to build an object-oriented view on each component database. To incorporate as much semantics as possible, such views should include methods and constraints derived from application software. It turned out, however, that the notion of data integrity as de ned in this application code was not concerned with the traditional notion of de ning integrity constraints on the data itself. Rather, application code insuring data integrity imposed the use of certain quality procedures that should be followed to generate quality data. We thus found that reverse engineering of such applications should be aimed at extracting object behaviour speci cations much like the ones used in work ow management [3] rather than logic predicates describing valid database states. In this paper, we explain why the traditional paradigm of constraint-based integrity control [7,11] is insucient for complex application domains. In such environments, data quality control is often based on a set of basic facts which are assumed to be true, and the designation of a set of quality procedures which may be used to generate new data based on these basic facts. Hence integrity control in such environments cannot be based on database states only, but should also take into account the way data is generated. We show that the object-oriented data model is well suited to support this data integrity paradigm. As an illustration, a simpli ed oil industry example is used, concerning a database containing information on subsurface geological structures. Such databases are used by oil companies to predict the location of oil and gas elds. As will be shown, lack of knowledge on the real world phenomenon described by the database prohibits the de nition of data integrity in terms of constraints here. Note that we focus on application domains where knowledge of the real world is incomplete or hardly formalizable. Existing work on incomplete information in integrity control focuses either on checking constraints using partial information on the current database state [8] or on enforcing constraints that are themselves incompletely speci ed (`fuzzy') [12]. The remainder of this paper is organised as follows. In Section 2 we present a discussion of constraint-based data integrity speci cation. In Section 3, we discuss the limitation of this formalism in the context of complex application 2

domains. Section 4 presents an alternative way of regarding data integrity in such environments. Section 5 discusses the applicability of this notion of integrity in the object-oriented data model, and the relationship between the our paradigm and the constraint-based one. Finally, in Section 6 we discuss practical consequences of our ideas. Section 7 presents our conclusion.

2 Data Integrity Theory In this section, we elaborate on the notion of data integrity based on the correspondence between database states and real-world states. In particular, we describe how integrity constraints can be used to support this notion. We illustrate our discussion with the following example. Example Consider a relational database Res used to record reservations of meeting rooms by employees of a certain company. Res has a schema S consisting of the following three relations: EMP(emp-nr, name, tel-nr) ROOM(room-nr, room-type, nr-pers) RESERV(res-nr, start-time, end-time, emp-nr, room-nr)



2.1 Terminology

Let S be the database schema for a database DB. S de nes a set of types fT1 ; T2 ; :::; Tn g. Note that we abstract from the data model here. Thus, S determines the vocabulary used in expressing facts about the world in DB. A database instance D is a set fD1 ; D2 ; :::; Dn g, where each Di is a set of instances of Ti . 1 A database instance corresponds to a particular description of the real world. An element t 2 Di is called a fact. Facts describe situations which may or may not occur in the real world described by DB. If a fact t describes a situation occurring in the real world, t is called true; t is called false otherwise. Example For our example database Res, a database instance D corresponds to a particular set of employees, a particular set of meeting rooms and a particular reservation schedule for these rooms. An example fact of type RESERV is h 39, 0312941300, 0312941400, 1234, 5 i; describing a situation possibly occurring in the real world, viz. "Employee 1234 reserved meeting room 5 from Jan 3 1994 13:00h until Jan 3 1994 14:00h". If this is indeed the case, the basic fact is true, otherwise it is false.  For database instances D and D we write D  D i Di  Di ; 1  i  n. The set of all possible database instances is called the database universe U . We also 0

0

0

1 In general, there may exist a one-to-many relationship between types and extensions. For simplicity, we assume here that each type has exactly one extension.

3

introduce the notion of a universe of discourse U , the set of all facts about the world that can be recorded in DB. Thus,

U = ffD1 ; D2 ; :::; Dn gjDi  Ti ; 1  i  ng and U is the database instance satisfying

U 2 U ^ 8D 2 U : D  U Let M be the following database instance: M = fM1 ; M2 ; :::; Mn g, where Mi = ft : Ti j t represents a true situation in the real worldg. Thus, M represents the `ideal' database state, fully corresponding to the state of the real world. M is called a model for S . Note that M changes with time, as the state of the real world changes. For the moment, however, we assume that M is xed. Example For our example database Res, U corresponds to the database state describing a rather chaotic world with a maximal number of employees, each having all name/telephone combinations one can think of, and reserving all of the millions of multi-type rooms available at all time-intervals. Obviously, such a situation can never occur in the real world. The database state M contains of all the basic facts recorded in U exactly those that are true in the current real world situation. Thus, M describes the actual set of employees, each with their own unique name, reserving rooms owned by the company, forming a coherent schedule. Both U and M are part of the set of all possible database states U .



2.2 Validity and completeness

In [11], Motro distinguishes two aspects of integrity: validity and completeness. We discuss these concepts in the context of our example application domain. A particular instance D of S is called valid i D  M . A valid database instance does not contain any false facts. D is called complete i M  D. If D is both valid and complete, then D = M and D is said to have integrity. To control the integrity of a database, a mechanism to determine whether a given database state is valid and complete is needed. Integrity constraints have been proposed to this end. Consider a function I of type U ! bool. For a database instance D, we say that I is true for D i I (D) = true. I is called a (static) validity constraint i

8D 2 U : (D  M ) I (D))

Example Example validity constraints for Res would be

8 2 RESERV : 8 2 RESERV : ( 6= , res-nr 6= res-nr) : 8 2 RESERV : ( start-time end-time) : 8 2 RESERV :6 9 2 RESERV : room-nr = room-nr ^ start-time start-time end-time) I1

:

x

y

I2

x

x:

y:

y

x:

I3

(

x

x:

y:

< x:

x

y

x:

< y:

4

< x:

Every correct reservation has a unique reservation number, its start time before its end time, and correct reservations do not overlap. Thus, if a database instance D contains only true facts, these constraints will hold for D.  A validity constraint is thus an assertion that holds for any valid database state. Ideally, a set of validity constraints by which the validity of a given database state can be determined, should be identi ed. Let TV be a set of validity constraints TV is called a validity theory for M i

8D 2 U : (D  M , 8I 2 TV : I (D)) Thus, we can determine the validity of any database state D by evaluating TV on D. Analogously, I is called a (static) completeness constraint i

8D 2 U : (M  D ) I (D)) and a set TC of completeness constraints is called a completeness theory i

8D 2 U : (M  D , 8I 2 TC : I (D))

Example A typical example of a completeness constraint is a referential integrity constraint, for example

I4 : 8x 2 RESERV.emp-nr : (x 2 EMP.emp-nr) A complete database instance necessarily contains data on each employee that makes a reservation.  Fully constraint-based integrity control requires the de nition of a (full) theory T for M , by which both validity and completeness of any database instance can be determined: 8D 2 U : (M = D , 8I 2 T : I (D))

2.3 Data custody

Once a theory for a model is known, testing the integrity of a database instance

D reduces to testing the truth of T on D. In practice, however, it is often next to impossible to specify a complete theory for a given model M . This aspect is

given little attention in literature. However, it occurs even in simple application domains such as the one in our running example. Example Again consider the Res database. Although the concept of a correct reservation can be rather sharply de ned, there are certain facts whose truth value cannot be determined by a computable function. For example, whether either h 37, Smith, 1438 i or h 37, Smith, 1439 i is a correct EMP-value in a given real-world situation cannot be determined automatically.  In practice, a subset consisting of what might be called basic facts is therefore identi ed, the integrity of which is guarded by a data custodian. Other facts 5

might be called constrained facts, and their integrity is de ned by a theory as above. Thus the role of integrity constraints is reduced from identifying the unique database state M , to the identi cation of a set of database states A  U called admissible states, where M 2 A. Let the universe of discourse U be partitioned into sets Ubas and Uconstr , where Ubas \ Uconstr = ;. Ubas and Uconstr contain all possible basic and constrained facts, respectively. For any database state D, de ne Dbas = D \ Ubas and Dconstr = D \ Uconstr . We model the data custodian as an oracle O for the model M , a function of type Ubas ! bool, where given a model M , O(t) =true i t 2 M . A set of integrity constraints T is then called a theory for A i

8D 2 U : (D 2 A , 8I 2 T : I (D)) Moreover,

8D 2 U : ((8I 2 T : I (D)) ^ (8t 2 Dbas : O(t)) , D = M ) Whether a database containing an admissible state (a state that might occur in the real world) corresponds to M (the state of the real world that actually occurs) depends on the value of the basic facts.

2.4 Changing worlds

With the de nition of multiple admissible states, changes in M caused by a changing real-world state can be accounted for as well. Moreover, restrictions on possible changes in the real world can be de ned using dynamic constraints. Let Md  A  A be a set of database state transitions that correspond to state transitions that might occur in the real world. Consider a function Id of type U  U ! bool. Id is called a dynamic constraint i

8(D; D ) 2 U  U : ((D; D ) 2 Md ) I (D; D )) 0

0

0

Note that Id concerns single-step state transitions. In general, dynamic constraints can restrict multi-step transitions as well. We do not elaborate on this here.

3 Complex application domains The constraint-based approach to integrity control described in the previous section is quite applicable in traditional application domains with simple and known models. However, setbacks of this approach become apparent when more complex application domains are involved. This will be illustrated in this section using the following highly simpli ed example. Example We consider databases containing information on subsurface geological structures, as used by oil company researchers to predict the location of oil and gas elds. Let P be a very simple relational database used to record data on the permeability of the subsurface. P has a schema de ning a single type 6

PERM(x,y,z,perm),

where x, y, and z are coordinates describing a subsurface location, and perm is the permeability value of the subsurface at that particular location.  In context such as these, three fundamental problems with the constraint-based approach to integrity control arise, viz. 1. Completeness is an inherently unachievable goal for some application domains. 2. Even given a known model M , nding a theory for M may require considerable domain knowledge. 3. Sometimes M is only partially known, due to incomplete information on the real world state. Below we elaborate on each of these points.

3.1 Completeness

Many application domains have inherently in nite models. As database instances are inherently nite, the formulation of a completeness theory is infeasible in such contexts. Example The universe of discourse U of the permeability database consists of all possible basic facts about subsurface permeability we might record in P. M here consists of all basic facts describing correct permeability values for each of the locations addressable by the coordinates. We cannot expect the database to contain all facts occurring in M . However, we do expect facts recorded in P to represent correct permeability values. Thus, ensuring data integrity for P boils down to guarding validity for P. 

3.2 Finding theories

In the constraint-based approach, we need to de ne a theory describing a set of admissible database states. The impossibility of de ning such a set is most obvious in a research context. Example The permeability database was set up to develop a theory for subsurface structures in the rst place. Obviously, we cannot beforehand de ne a set of rules that will de ne integrity for P. This implies that the set of admissible database states is very large, leaving the burden of integrity control to the data custodian.  The problem of nding a set of integrity constraints for a database, or nding a theory for a model, is quite similar to a scientist performing a set of experiments and then trying to nd a theory to account for his results. That is, the formulation of a set of powerful integrity constraints requires considerable domain knowledge, and is thus infeasible for more complex domains. 7

3.3 Incomplete information

An additional complication arises if M is only partially known. That is, there is incomplete information on the real world state modelled by the database. Thus, we even have problems with establishing validity (D  M ) in these contexts. Example As the permeability database describes subsurface structures, the truth value for each fact is not easily perceivable. Obtaining facts for M requires performing experiments, which are costly and can never be complete. Even if some set of admissible states could be de ned, e.g. using general geological knowledge, it is impossible to determine the validity of any given database state D.  Obviously, if the model is unknown, the de nition of a theory for the model is infeasible. Therefore, data integrity in these contexts must be de ned by means other than integrity constraints. This is the subject of the next section.

4 Data integrity in complex application domains How can data integrity be de ned and controlled when the formulation of a meaningful set of integrity constraints is not possible? In this section an alternative paradigm for data integrity, which in this context is often rather called data quality, is described. It will be argued that Sometimes the integrity of data is inherently dependent on the procedure that generated it. Below a realistic description is given of the way data quality is controlled in the context of the example permeability database, where integrity constraint de nition is prohibited by each of the three factors listed in the previous section. Example To obtain facts about the real world for our permeability database P, experiments are conducted. However, experimental data is inherently inaccurate. Moreover, experiments may con ict; dierent experimental methods may result in diering opinions on the same phenomenon. As there is no easy way to verify the truth value of facts in the real world, it is the responsibility of an expert data custodian to determine which particular experimental result is believed to represent an observable fact. Experts are also capable of interpreting experiments, thus arriving at reliable predictions for permeability values at locations for which no observed values exist. The interpretation is supported by software performing certain aspects of the interpretation process for which formal methods exist. As it is next to impossible to develop formal criteria for the quality of data itself, attention shifts to developing criteria for the procedures used when generating data. To ensure data integrity for P, it must be ensured that a quality procedure is used for judging or interpreting experiment data. Data generated using such procedures is considered of a certain quality, due to the quality of the procedure that generated the data.  8

4.1 An alternative integrity paradigm

Formally, the approach adopted in the example can be de ned as follows. Again, the universe of discourse U is partitioned into two disjunct set of facts, which might appropriately be called observable facts (Uo ) and derived facts (Ud ) here. We assume the existence of an oracle O, a function of type Uo ! bool where O(t) = true i t 2 M . Note that the oracle models an expert data custodian. Let Mo be the subset of M which can be perceived using the oracle. Thus, Mo = ft 2 Uo jO(t)g. Let Do be a database instance consisting of such true observable facts only. Thus, Do  Mo is valid. Consider a database operation R of type U  Input ! U that we might apply to Do to generate new data. R is called valid i

8D 2 U : 8i 2 Input : (D  M ) R(D; i)  M ) R is a `quality procedure', an operation that preserves database validity. Note that in the absence of complete domain knowledge the validity of a procedure is often a matter of belief rather than proof. As each database state Dj is the result of applying a series of operations R0 ; R1 ; :::; Rj to an initial database state D0, database validity can be de ned by determining the validity of each Ri . That is, it must be taken care of that manipulation of the database DB is performed exclusively by a set of operations fR0 ; R1; :::; Rk g, where each Ri is considered valid. Thus, in application domains where the model is only partially known, integrity control boils down to ensuring that for each basic fact t of a given database instance D, one of the following conditions holds:

 t 2 Mo  t was derived from Mo using valid database operations Ri To compensate for the lack of information on the real world, the quality of operations generating new data is relied on.

4.2 Comparable notions

There is some similarity between this integrity paradigm and the concept of production rules in expert systems. Production rules are valid operations to generate new data. However, in this context any database operation, perhaps including \ask the (expert) user to enter new data" may be considered valid. In fact, specifying database integrity boils down to assigning validity to an exclusive set of trusted operations here. In areas other than database integrity theory, the relation between operation quality and data quality has long been identi ed. For example, in the context of oce automation, work ow management systems [3] are concerned with specifying business procedures that must be followed to generate correct output. Regarding this output as data to be entered in a database, the validity of data generated by such procedures typically cannot be determined by its state only. For example, banking data on loan granting contracts is considered valid 9

only if certain loan granting decision procedures have been followed. Thus data validity can only be established using knowledge of the procedure followed to generate the data. In the real world, this problem is solved by attaching such knowledge to the document (data) by having each employee that performed a certain operation indicate this on the document itself (e.g. using a stamp). Work ow management systems often follow a comparable approach. As will be discussed in the next section, modern DBMSs provide more sophisticated functionality to achieve this.

4.3 Aspects of data integrity

In conclusion, the following three aspects to data integrity can be identi ed: 1. De ning integrity constraints 2. Data custody 3. The validity of operations

5 Integrity control and the object-oriented data model The present focus of integrity theory on validating integrity constraints can partially be explained from the prevalence of data models such as the relational and the network model as the basis of current DBMSs, which allow the modelling of data structures rather than behaviour, where data behaviour is de ned as the set of operations that may be applied to the data. In such DBMSs, behaviour of data objects is implemented by applications accessing the database. The speci cation of these applications is outside the scope of the DBMS. In such environments, integrity control supported by the DBMS is necessarily based on database state constraints; quality of procedures generating data cannot be considered. Moreover, as many commercial DBMSs support only limited types of integrity constraints, the enforcement of more complex constraints is often taken care of by application software as well. `Data quality control' modules are seen frequently in application software for RDBMSs used in complex application domains. Object-oriented data models, however, oer the possibility of encapsulation of objects with exclusively assigned operations. As discussed in the previous section, this is exactly what our notion of integrity is based on. Example Again consider the subsurface permeability database P. Suppose P is managed by an OODBMS and has a schema of the following form (syntax is borrowed from the TM object-oriented database speci cation language; see Section 6):

10

class Perm object attributes

x: real; y: real; z: real; perm: real;

class update methods Experiment(in: e: Perm, ....)= if JudgeExperiment(e, ...) then self = self union e Interprete()=.... end Perm The exclusive assignment of the update rights of class Perm to the operations Experiment and Interprete, supporting the expert tasks of judging the quality of incoming experiment data and interpreting existing permeability data, respectively, prohibits updates of the database using uncerti ed procedures. Thus the integrity condition that each object in the database either represents an observable fact or is derived from it using a valid operation is enforced.  Note that some object-oriented models, such as TM, still allow the de nition of general rst-order constraints. We do not claim that encapsulation should replace constraint speci cation, nor that in the absence of a constraint speci cation language constraints should be enforced by methods. It is our argument that encapsulation can be used as an integrity control mechanism complementary to integrity constraint enforcement.

5.1 Integrity constraints and object behaviour

We now determine the formal relationship between traditional integrity constraints and integrity control using object behaviour. Consider a database DB with a schema S inducing a database universe U . A static constraint I s is a boolean function that is evaluated over a database state D 2 U : I s : U ! bool A dynamic constraint is a constraint over a pair of database states:

I d : U  U ! bool Let a database operation be of the following signature:

Oper : U  Input ! U  Output Let Ops be a set of possible database operations. Each database operation has a name. Let N be the set of possible operation names. Names are associated with operations by a bijection

Name : N ! Ops We de ne a database transition as the application of a particular operation with particular input parameter values on a particular database state. A transition t is thus a tuple hn; D; i; D ; oi, where n is an operation name, D is the database state before the application of the operation, i is an input parameter value, D 0

0

11

is the database state resulting from the application of the operation, and o is an output parameter value. Traditionally [7], t is called correct i

I s (D ) ^ I d (D; D ) 0

0

As argued in this paper, in some contexts database integrity is de ned by the de nition of a set of exclusively allowed operations on the database called database encapsulation. I e : N ! bool I e is de ned implicitly by listing all elements of N for which I e evaluates to true. That is, no operations other than the ones listed by I e may be applied to DB. Thus, correctness of a transition can be de ned as follows: a transition t = hn; D; i; D i is called correct i 0

I s(D ) ^ I d (D; D ) ^ I e (n) 0

0

Note that this notion of correctness re nes the traditional one. Note also that the relationship between integrity control based on encapsulation and integrity constraints is twofold: on the one hand, encapsulating operations may support data integrity not expressible by constraints (procedural integrity speci cation); on the other hand, the results of these operations must still satisfy the constraints that can be de ned for the database (declarative integrity speci cation). Procedural and declarative integrity speci cation are complementary techniques; both must be satis ed for a transaction to be correct.

6 Practical consequences Practical consequences of our discussion concern mainly the reverse engineering of existing relational databases for complex application domains. As shown in the previous section, mechanisms needed for integrity control in such application domains are absent in RDBMSs, but can be supported by OODBMSs. Therefore, it is natural to try and migrate to this new technology, if possible re-using concepts of the legacy systems. Although based on a dierent perspective, the claim that object-oriented data models are particularly suited to complex application domains is far from new. The semantic expressiveness of these data models has already stimulated a gradual migration from relational to object-oriented databases in this eld. Another motivation of such a reverse engineering eort might be the requirement of making existing heterogeneous databases interoperable. An object-oriented data model is then often used as a canonical data model, due to its semantic expressiveness (see e.g. [10]). Therefore some interest in reverse engineering of relational database systems has already been raised. For example, several methods to translate a relational schema into an object-oriented one have been proposed (see e.g. [4,5]). However, obtaining a fully object-oriented speci cation requires the reverse engineering of the database application software as 12

well, to discover methods and constraints coded there. In [14], we discussed an algorithm to translate SQL-queries into object-oriented method code. In this context the idea to extract the database constraints from relational applications has been suggested. It follows from our discussion however, that in contexts such as the above, extracting integrity conditions from application software boils down to the extraction of object behaviour speci cations. It is our experience from analysing data quality modules used in oil industry that the majority of code in such modules is concerned with implementing conditions on object behaviour. A target object-oriented speci cation platform for reverse engineering of relational databases should thus include a method speci cation language. Objectoriented design speci cation methods that support object life cycle speci cation, such as OMT [13] and OOAD [2] satisfy this requirement; [9] discusses the organisation of object life cycle speci cations in an inheritance hierarchy. Reverse engineering of relational database software could be targeted at such a speci cation method. A more formal and database-oriented target is formed by the TM objectoriented database speci cation language [1,6]. TM allows the speci cation of data structures in terms of Classes and Sorts (the latter being abstract data types without object identity). Both methods and constraints are included in the speci cation, using a computationally complete, functional data manipulation language, which is also capable of expressing set-oriented queries in a declarative way. The possibility of formally specifying both data structures and methods and constraints in a single formalism makes TM an attractive target for reverse engineering of relational databases. This is the subject of our current research.

7 Conclusion This paper discussed data integrity in complex application domains. During a reverse engineering eort of extracting integrity constraints from application software to supply semantically richer views for relational databases employed in oil industry, it appeared that the traditional notion of integrity control is often not applicable in such environments. In this paper, we showed that the constraint driven approach is insucient to describe data integrity in contexts where knowledge about the real world is incomplete or hardly formalizable. In these contexts, the integrity of data cannot be determined based on database states only. The quality of data is inherently dependent on the quality of the procedure that was followed to generate the data. Therefore, the focus of integrity control in such environments shifts to controlling the way in which data is inserted into the database. We need to exclusively prescribe update procedures for the database. The object-oriented model is particularly suited to express this kind of integrity conditions through the encapsulation of objects with operations de ning its behaviour. We showed that the notion of a correct database transition following from this point of view re nes the traditional one. 13

Acknowledgement We thank Paul Grefen for his useful commentary on

earlier versions of this paper.

References [1] H. Balsters, R. A. de By & R. Zicari, \Typed sets as a basis for objectoriented database schemas," in Proceedings Seventh European Conference on Object-Oriented Programming, July 26{30, 1993, Kaiserslautern, Germany, LNCS #707, O. M. Nierstrasz, ed., Springer{Verlag, New York{ Heidelberg{Berlin, 1993, 161{184. [2] G. Booch, Object-Oriented Analysis and Design with Applications, Benjamin Cummings, 1994. [3] Y. Breitbart, A. Deacon, H. -J. Schek, A. Sheth & G. Weikum, \Merging application-centric and data-centric approaches to support transactionoriented multi-system work ows," SIGMOD RECORD 22 (September, 1993), 23{30. [4] M. Castellanos, \A methodology for semantically enriching interoperable databases," in Advances in Database - BNCOD 11, Springer-Verlag, New York{Heidelberg{Berlin, 1993, 58{75. [5] R. H. L. Chiang, T. M. Barron & V. C. Storey, \Reverse engineering of relational databases: Extraction of an EER model from a relational database," Data & Knowledge Engineering 12 (March 1994), 107{142. [6] J. Flokstra, M. van Keulen & J. Skowronek, \The IMPRESS DDT: A database design toolbox based on a formal speci cation language," in Proceedings ACM-SIGMOD 1994 International Conference on Management of Data, ACM Press, New York, NY, 1994, 506. [7] P. W. P. J. Grefen & P. M. G. Apers, \Integrity control in relational database systems - An overview," Data & Knowledge Engineering 10 (1993), 187{223. [8] A. Gupta, Y. Sagiv, J. D. Ullman & J. Widom, \Constraint checking with partial information," Stanford University, Stanford, CA, 1994. [9] G. Kappel & M. Schre , \Inheritance of object behavior - consistent extension of object life cycles.," in East-West Conference 1994, Bonn, Germany, 1994. [10] F. Manola, \Applications of object-oriented database technology," in Integration of Information Systems: Bridging Heterogeneous Distributed Databases, A. Gupta, ed., IEEE Press, Montvale, NJ, 1989, 126{134. [11] A. Motro, \Integrity = Validity + Completeness," ACM Transactions on Database Systems 14 (December 1989), 480{502. [12] K. V. S. V. N. Raju & A. K. Majumdar, \Fuzzy functional dependencies and lossless join decompositions of fuzzy relational database systems," ACM Transactions on Database Systems 13 (1988).

14

[13] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy & W. Lorensen, ObjectOriented Modeling and Design, Prentice-Hall International, London, England, 1991. [14] M. W. W. Vermeer & P. M. G. Apers, \Object-oriented views of relational databases incorporating behaviour," in Fourth International Conference on Database Systems for Advanced Applications (DASFAA'95), Singapore, April 10{13 1995, T. W. Ling & Y. Masunaga, eds., World Scienti c Publishing Co., 1995.

15