A Model of Integrity for Object-Oriented Database Systems James M. Slack and Elizabeth A. Unger Kansas State University Abstract This paper develops a model of integrity for object- oriented database management systems based on first order predicate calculus. The object-oriented model in [13, 14] is extended with standard operators; the integrity system is layered over this extended model. The result- ing model is shown to handle common state integrity con- straints, including domain, key, and structural constraints. This model can enforce value-based functional dependen- cies from the relational model, both within an object and across object classes. Introduction There are two major types of undesirable changes to data in a database: malicious and nonmalicious. Malicious changes fall under the realm of database security: keeping unauthorized users from accessing and changing the data. It is the second type of undesirable change that we ad- dress here: how to keep authorized users from accidentally corrupting the data. Some authors use the term system integrity to encompass both security and integrity (e.g., [3]). Semantic integrity is concerned with the correctness of the data in the database during updates by users. In this paper, we will call semantic integrity simply integrity. The word integrity does not have a generally accepted meaning in the context of databases [11, 10]. [10] defines integrity as having one of two meanings: 1. The state that exists when computerized data is the same as that in the source documents and has not been exposed to accidental or malicious alteration or destruction. Permission to copy without fee all or part of this material is granted provided that tha copias are not made or distributed for direct commercial advantage, tha ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. 01992 ACM Q.8979J.~Q2-~/92 /0Q02jQ234,., $~ .5Q 2. The state that exists when the quality of stored in- formation is protected from contamination or degra- dation by information of lower quality. Sandhu and Jajodia [11] define integrity as concern with improper change of data, and give reasons to put integrity checks in the DBMS rather than at the operating sys- tem or application level. Integrity checks don’t belong in the operating system because the OS cannot address application-specific concerns. These checks do not belong in applications for several rea90ns: 4 ● ● Replication of code in applications can lead to main- tenance problems, It is hard to check constraints for correctness if they are spread over several applications. An application can follow its own integrity rules, but cannot force other programs to abide by these rules. According to Metro, data has integrity if it is both com- plete and valid [8]. Data is complete if it includes all real- world entities. Data is valid if the data contains no information that is not in the real world. Usually, check- ing for completeness is difficult if not impossible. Typical database systems have no independent means for verifying whether all real-world entities have been entered into the database. Checking for validity, although difficult to do fully, is possible to do partially. For example, the database system can eaaily reject an employee entity whose age is 200 years. Some of the work on integrity in object-orienttd databases (e.g., [6, 7, 5]) is a by-product of research in the area of security. In [6], Lunt discusses a multilevel secure object- oriented model in which an object’s jacets (methods, at- tributes, and constraints) may have different access lev- els. Jajodia suggested in [5] that multilevel secure object- oriented systems can be implemented using a single level model. An integrity constraint may be classified as implicit, ex- plicit, or inherent [2]. An implicit constraint can be spec- ified and represented in the database scheme of a model, 234 Figure 1: Restricting the domain of the database (W: real world entities, D: database domain, R(D): restricted database domain). e.g., key and referential integrity in the relational model. An explicit constraint is one which the user must specify explicitly, e.g., that an employee works in the same de- partment ss his or her manager. An inherent constraint is one which is part of the data model; these do not need to be specified by the user. For example, each data item must be atomic in the relational model. An integrity constraint may also be a state or transi- tion constraint [2J. A staie constraint is a restriction on the state of the database, where state is the data in the database at a point in time. The database is consistent if it satisfies all state constraints. State constraints shouid hold when database is not in transition, and should be checkedat each update. A transition constraint is a re- striction on transitions from one state to another, e.g., that a person’s age cannot decrease. In this paper, an integrity constraint is a restriction on the domain of states of the database. Let W be the set of real world entities, D the database domain and R(D) the database domain after restriction by a set of integrity constraints (see Figure 1). Note that R(D) is necessarily a subset of D. The idealsituationis when W = R(D); how- ever, this usually requires that all real world information be encoded in the integrity constraints. The trick is to specify enough constraints to restrict the database domain so all real-world entities are allowed in the database, while excluding as much false information as possible. That is, we would like W ~ R(D) and R(D)-W to be as small w possible. Object-oriented databases offer a unique opportunity for ensuring integrity of data: [1] [I]t can be argued that the object-oriented paradigm provides a framework where con- straints on the defined operations can be enforced and managed. This will avoid all the problems that arise when extensible systems allow uncon- trolled operational specifications. We are interested in explicit constraints that restrict the domain of an object-oriented database so the data is more likely to be valid. The presentation is organized in the following manner. The first section reviews the model of object-oriented databases presented in [13, 14]. Following that, we present our formal model of integrity in object- oriented database systems. The last section concludes the discussion with some ideaa for further research. Object-Oriented Database Model This section briefly reviews the relevant parts of the object-oriented data model presented in [13, 14]. The model incorporates objects, classes, methods, multiple in- heritance, and encapsulation. Each clam and attribute is an object in its own right, but methods are not objects. Classes are defined at the same “level” as other objects and use a simple multiple inheritance scheme. In this model, objects cannot change their structure (e.g., object instances cannot change classes). Also, the only way to ac- cess an attribute in an object is through a method of that object. Since attributes are themselves objects, they must be accessed using their own methods, The model assumes that if two methods inherited from an object’s parent(s) have the same name, then they represent the same method (i.e., they are derived from the same object). The primitive set D consists of the union of Z, the set of integer numerals; R, the set of real numerals (computer reals); S, the set of strings; B, the set {true, false}; the set of domain names: {nil, integer, real, string, boolean}; and the empty domain name base. We also assume the existence of A, the countably infinite set of symbols for attributes and Z, the countably infinite set of identifiers. Informally, an object si is a triple (i, t,m), where i is an identifier, t is the type of the object, and m is a set of methods. We illustrate an object as a rectangular box with three compartments (see Figure 2). The topmost compartment cent sins the object identifier; the middle compartment contains the type; the bottom box contains the set of methods for the object. A class is an object si = (i, t,m) where tis a set-structure, a tuple-structure, or the empty domain name base. At- tributes of a set-structured type are unnamed. Attributes of a tuple-structured type may be named or unnamed. Unnamed attributes are parent class identifiers. Named attributes are inst ante identifiers; they are used to store 235 non-state-changing method or a junctional method. w I m (methods) I Figure 2: Parts of an object si = (i, t, m). values. An instance of a class is an object (i, t, m) where t is an object class identifier and m is the empty set. The set of direci instance identifiers of a class object si consists of all object instance identifiers jk which have the identifier i as their type. The set of all instance identifiers 1* onsists of the direct instance identifiers of si, denoted Si , c of si as well as all instance identifiers of the descendant ClaSSeS of 81. The structure of an object si consists of the attributes and methods in si as well as those attributes and methods in- herited from parent(s) of si. An attribute can be accessed only by methods in the same object. The state of a set of objects S is the set U$i~In8t(~)[i, state($i )1where InSt(S) denotes the instance objects m S. A method M is acceaaible to an object si = (i, t, m) if $i can invoke method M. Object si may be able to invoke M directly, i.e., by using the name of the method. In this case, Al is an unqualified method. The object si may also be able to invoke severdl qualified methods. A qualified method AC is formed by prepending a named attribute to a method name. For example, if Advisor is a named at- tribute and GetName is a method, then Advisor. GetName is a qualified method. An object si = (i, t,m) uses unqualified method namea to invoke methods in m and methods from ancestors of Si, Qualified method names are used to invoke methods of named attributea. Unlike attributes, methods may be accessible to several object claases and object instances. Informally, a method A4 is accessible to si if M is in an ancestor of si or M is in the class object of a named attribute of si. Methods are the operations that access and manipulate at- tributes within objects. The set of methods encapsulated in an object defines the behavior of that object. Infor- mally, a method is a function that takes the state of the object database, an object identifier, and a list of parame- ters as input, and results in a new state of the database and a message. If the method fails, the return message is nil. We make a distinction between those methods that change the state of the database and those that do not. A method which never changes the state of the database is called a We assume the existence of an identifier comparison op- eration, ==, which tests for the equality of two object identifiers, Thus == (cl, Cz) is true only if c1 and Cz are the same object identifier. We ssaume the existence 6f three operators which operate on sets of object identifiers: subset, set union, and set difference. Integrity Constraints In this section, we incorporate integrity constraints into the object-oriented data model. The first issue is to decide where to put constraints. There are several possibilities: within object instances, within object classes, or global to a set of objects. We associate a set of integrity constraints globally with a set of objects. This approach has several important advantages over as- sociating constraints with classes or individual object in- stances. First, this approach is layered over the data model, so different data models may be used with the same integrity constraint technique. A second advantage of the approach is that because the integrity constraints are sep- arate from the data model, they can easily be separated from the database system in an implementation. For ex- ample, they might be placed into a separate, secure kernel. A third advantage is that this approach is more transac- tion oriented, A single transaction may invoke the same method several times before it finishes. The transaction may put the database in an inconsistent state during its processing; as long as it leaves the database in a consi~ tent state, integrity constraints should be satisfied. This is more difficult to allow if integrity constraints are tied tightly to object instances or classes. A fourth advantage is that separati constraints are simpler to implement, es- pecially for constraints which involve objects from more than one class. Finally, keeping the integrity constraints separate is more amenable to optimization and other anal- ysis. There is one aspect of keeping integrity constraints sep- arate from the object-oriented data model which appears to be a disadvantage. That is, integrity constraints do not seem to be inherited from parent classes to subclasses ES are methods and attributea. However, this is not really true, since the domain of an object includes the domain of each of its ancestors. Therefore, the set of integrity constraints that apply to an object includes all integrity constraints that apply to ancestors of that object. Let us formalize these ideaa. First, we layer an inheritance mechanism over the object-oriented data model, resulting in a constrained object set: 236 /-’ ( integrity system layer ) Transaction Figure 3: A transaction is a method invocation from out- side the constrained object set. Definition 1 A constrained object set C is a pair (S, 1), where S is a set of objects {s1, s2, , ~ s}and~is aset of integrity constraints {cl, cx, . . . ,Cffl}. Each integrity constraint is a first order predicate logic ex- pression. Eachtransactioninto a constrainedobject set is constrainedin its actionsby the integrityconstraints.In- formally,a transaction is a method invocationthat comes fromsomewhere“outside”the constrainedobject set (see Figure3). We definethis formally: Definition 2 Let C = (S, 1) be a constrained object set. A transaction T is the invocation of a method M of some object in S from an agent or object which is not in S. The transaction T fails if, when M finishes, any integrity constraint cj E 1 is not satisfied. A consequence of this definition is that methods in an ob- ject set may not invoke transactions directly. Transactions may invoke other transact ions, however. Integrity Constraint Expressions Ideally, integrity constraints should constrain the at- tributes of objects in a database, because the attributes define the domain of the database. For example, suppose we wish to restrict the Age attribute in the class employee to integers greater than O and less than 120. A formal statement of this constraint might be the following: Ve E emp/oyee(e.Age >0 A e. Age < 120) (1) An appealing feature of this approach is that constraints are easy to read and understand. However, the approach has two major problems. The most severe problem is that constraints violate the encapsulation of attributes within objects. An attribute is accessible only by the methods of the object containing the attribute. Since the constraint system is layered over the object set, it cannot access at- tributes directly. The other problem is that the comparison operators (e.g., <, >, =, . . . ) apply only to primitive types. A constraint cannot compare more complex objects such as tuples or nested data structures, nor can it perform other operations on such objects. Our goal is to design a formal system of constraints with the simplicity of equation 1 along with the ability to use the operations of the classes in the object set, but with- out accessing attributes directly. We will accomplish this task by constraining the results of functional methods in- stead of attributes. This is one step away from constrain- ing attributes, but with this approach constraints are less dependent on the internal structure of objects. Instead, constraints apply to the external behavior of objects. The external behavior of an object is what is ultimately important to transactions and other objects. Consider the restriction on a person’s age in equation 1. Many appli- cations do not store Age as an attribute; they calculate age from the current date and a stored birth date. In such an application, a constraint on age must be written in terms of birth date if constraints apply to attributes. It is more natural and direct to restrict the result of the method GetAge than to go through a translation process. All comparison and other operators in constraint expres- sions are methods from the object set. The following con- straint restricts the result of the method GetAge of each instance of employee to an integer greater than O and less than 120: Ve(ernployee(e) ~ Vu(GetAge(e, a) (2) ~ (Leas(e, O,a) A Less(e, a, 120)))) The constraint model is based on first-order predicate cal- culus, which unfortunately makes constraints rather un- wieldy. To solve this problem, we will define a set of nota- tional conveniences which will make constraints far more palatable. The resulting constraint is as follows: Ve E employee(e.GetAge >0 A e.GetAge < 120) (Note the similarity of this constraint with equation (3) 1) We begin by describing expressions in the integrity model, based on first order predicate calculus. The primitive sym- bols in the language of constraint expressions include vari- ables, constants, functions, predicates, logical connective (A, V,+, -I), quantifiers (V, 3), and parenthesis. A term is either a constant or f(al, az, , an ) where ~ is an n- ary function and al, a2, . . an are terms. A fownula is P(tl, t2, <, tn) where P is an n-ary predicate symbol and tl, tz, , tn are terms. If A and B are formulas, then 237 AAB, AVB, A h B, 7A, VXA, 3xA are formulas. A closed formula is one for which each variable is quantified. Integrity constraint expressions are restricted to be closed formulas aa well as safe formulas. Intuitively, a safe for- mula is one in which the variablea range over the extension of the database. The idea is similar to range restricted for- mulas in [9] and safe formulas in [16]. Definition 3 Let # be a formula where Z1, Z-J, , Z. are free, and let P be a unary predicate. Then a safe guan-hjication is a formula of one of the following forms: ● VX1VX2. . .VZ.(P(Z1) A P(z2) A . . . A P(zn) -+ #(Zl,Z~, . . .,2”)) Q 3x13x2 . . .3zn(P(zl) A I’(zz) A . . . A P(zn) A ~(iZl, Z2, . . . . Z“)) Definition 4 A safe formula is a formula in which every quantification is a safe quantification. Constraints may only use functional methods, and may ignore the possibility y that a method may fail. A failing method in a constraint is a run-time error. Given a constrained object set C = (S, 1), an interpret tion for the set of integrity expressions I over the set of objects S consists of the following: ● ● ● ● ● Each constant symbol a is aasigned a value in dom(si) for some claas object si = (i, t, m) in S where t is a primitive data type. Each class object si G S is associated with a unique unary predicate symbol P, which is assigned a rela- tion P(z) such that P(z) is true only if object z is an instance ofs~. For each class si E S, each functional n-ary method M with non-boolean result is associated with a func- tion symbol f. Function symbol f is assigned a func- tionf :s~’xs~~x xs~; + s~* where 8j1, . ! Sjm I Sk are object classes in S. For each class si E S, each functional n-ary method M with boolean result is associated with a predicate symbol P. Predicate symbol P is aasigned a relation P(i, zl,. . ., Zn) such that P(i, Zl, , Zn) is true only if e.M(~l, . . . ,z~) = true. The set operations U and - are associated with bi- nary function symbols U and –, respectively. Func- tion symbol u is assigned a function U : Z x Z + Z where U(A, B) returns the union of the sets of iden- tifiers in set-structured objects A and B. Function symbol – is assigned a function - : Z ~ Z - Z where -(A, B) returns the identifiers in set-structured ob- ject A that are not in set-structured object B. c The set operation ~ and the pointer operation === are associated with binary predicate symbols ~ and ==, respectively. Predicate symbol ~ is assigned relation ~ (A, B) such that ~ (A, B) is true only if the set of identifiers in set-structured object A is a subset of the identifiers in set-structured object B. Predicate symbol == is assigned relation == (A, B) such that == (A, B) is true only if the identifier A is equal to the identifier B, Let us express the constraint that the method GetAge of each object in the employee class returns a number greater than Oand less than 120 (this is the same as constraint 2): Ve(ernployee(e) + Va(GetAge(e, a) (4) -t (Less(e, O, a) A Less(e, a, 120)))) In this constraint, GetAge is a predicate which is true if a is returned from the method e. Get Age, i.e., the GetAge method is accessible to object e. The predicate Less is also associated with a method in e; Less(e, O,a) is true if e. Less(O, a) = true. This is the most general way to write a constraint: all operations must use methods of the objects. Constraint 4 may use the integer method Less instead of the method Less from e (assuming that integer is in the object set ). This means that e does not have to export a Less method. Here is the resulting constraint: Ve(employee(e) + Vu(GetAge(e, a) (5) + (integer. Less(O, a) A integer. Less(a, 120)))) We take advantage of several notational conveniences to make constraints easier to read, in a way similar to [17]: 1. Methods of primitive chases may be used without naming the classes explicitly, assuming the classes are in the object set. We can rewrite constraint 5 as fol- lows: Ve(ernployee(e) ~ Va(GetAge(e, a) (6) ~ (Less(O, a) A Less(a, 120)))) 2. For values z and y of primitive data type ~, the fol- lowing substitutions may be used: ~=Y = =Less(z, y) A lLess(y, Z) z#y s Less(z, y) V Les8(y, z) Z<y S Less(z, v) X>y S Less(y, z) X>y z =Le8s(z, y) Z<y z =Less(y, z) 238 3. 4. 5. 6. Thus we can write constraint 6 as follows: Ve(errqdoyee(e) - Va(GetAge(e, a) (7) +(a>OAa <120))) Other binary operatora of primitive data types may be written in infix form, with the usual precedence rules. Several infix operators may be written as abbrevia- tions of system defined operatora: == (q, 4 - == (q, q) ~ (A, B) u(A, B) -(A, B) G (B, A) -(A, -(A, B)) ~ (A, B)A g (B, A) =(~ (A, B)A ~ (B, A)) ~ ({a}, B) Let #(zl, z2,. Zm) be a safe formula where zl, z~, , Zn are free. Then Vzl, zz, ,z~ c X(4( ZI, Z2, . . ., %)) is equivalent to VZ1VZ2. . .VZn(X(ZI) A X(X2) . AX(z~) + !4(21}22!. . ., %)) This rule provides a shorthand way to write universal quantifications and makes range restriction more ob- vious. The rule also handles multiple quantifications. We can rewrite constraint 7 as foIlows: Ve E employee(Vu(GetAge(e, a) ~ (a > OAa < 120))) (8) Let 9J(Z1)ZZ, , zn ) be a safe formula where 31,22, .,., Zn are free. Then 3z1, zz,. z~ G X(@(zl, zz, . . . . Zn)) is equivalent to 3Z13Z2 . . .32!nx(zl) A x(z2) . . . A X(Zn) A@(zl, 22, , Zn)) This rule is similar to the previous one, but appliea to existential quantification. 7. 8. 9. Let ~ = Vz E X(q$(z)) constraint expression Z.A2(y1a, . . .! YP2)}. . . . be a subformula of an integrity such that z. A1(YI, ,. Vpl), ~. An(Yl.l . . . . yp~) occurs in 4 where each z .Ai corresponds to a method Mj in class X with parameters IJ1,, , VP,. Then ~ is equiva- lent to the following subformula (the notation z[y/z] means to syntactically replace all occurrences of z by g in z): VZ(X(z) + Val’v’az. . .Van (Al(c, vi,, , Yp,, ul)A A2(C, Y12, . . .,yp,, a2) A . . . A An(z, vi.,. . ., VP.,%) - @(Z)[al/Z.Al(yl,, , ypi), a2/Z.&{yl~, ,YP,), . . . . am/~. An(gl-~ , Ypn)l)) This rule lets us use results of methods directly in con- straints. For example, constraint 8 can be rewritten as follows: Ve E ernployee(e.GetAge >0 A e.GetAge < 120) (9) (This is the same as constraint 3 from the beginning of this section.) Let ~ = 3Z E X(4(Z)) be a subformula of an integrity constraint expression such that Z.AI(VI,, . . . . Yp,)1 ZJ42(Y12 , . . ., YP,), , z. An(Yl~, . . .)YP”) occurs in 4 where each z .Ai corresponds to a method Mi in ClSSS X with parameters VI,, . . . . yp,. Then y is equivalent to the following subformula: ~z(X(z)A 3a13az .3an (AI(z, Y1,, .,vp,, al) A A2(z, Y12, . . .,yp~,az) A . . . A An(Z,~l_, ,vpm,an)A i#(z)[allz.Al(yl,, , Up,), a2/~.A2(yl,,. . . . Vp,), . . . 1 an/z. &(~ls, . . ., YPn)l)) This rule is similar to the previous one, but applies to existential quantification. Let a be a predicate involving constants and methods from class X and primitive classes, and let y = Vz E X=(4(Z)) be a subformula of an integrity constraint expression such that A1(yl,,. yPl)t A2(y1,,. JyPz)l), An(~lnl~1nl. ,~p~) occurs in a where each Ai corresponds to a method Mi in class X with parameters yl,, . . . . yp,. Then ~ 239 is equivalent to the following subformula: VZ(X(Z) + ValVa2 . . .Van (A~(~,y~,, ,y~,,a~)A A2(Z, Y1,, . . . ,Vpa, a2)A . . . A An(~,yl., ,YP~,an)A o[al/&(wl, . . . ,~p, ),a2/A2(w, ., Ypz), , an/&(~lnj . . . ! !/Pm)l+ 4($))) This rule allows a constraint to apply to a subset of a class. We call this restricting the class. For example, we can make constraint 9 apply only to employees with ID greater than 1000 as follows: Ve E ernpfoVeeGetID> looo (lo) (e. GetAge >0 A e.GetAge < 120) 10. Let cr be a predicate involving constants and methods from class X and primitive classes, and let ~ = 3Z c Xa(#(Z)) be a subformula of an integrity constraint expression such that Al(vl,, . . . ,Ypl),A2(Y1a,. ,~p~), .t&(~ln, ,yP~) occurs in a where each Ai corresponds to a method itl~ in class X with parameters Y1,,. yPi. Then 7 is equivalent to the following subformula: %(x(z)+ ValVa2 . . .Van (Al(Z,yl,, ,up,,al)A A2(z,yl., ,yP~,a2)A . . . A An(~,yln, ,YPw,an)A ~(~)[al/Al(yll, . . .,ypl), a2/A2(ylZ$. . .~up~)! , an/&(Yl~~ . . ., VP.)] A +(z))) This rule is similar to the previous one, but applies to existential quantification. This model of integrity can enforce the relevant types of state constraints listed in [2], including key, null value, relationship, and domain constraints. Domain Constraints A domain constraint restricts the domain of a method re- sult within an object. In the relational model, three types of attribute domain constraints have been identified in [4]: intratuple, intertuple, and aggregate-type constraints. An intratuple constraint on attribute A in tuple t depends on values of attributes in tuple t. An intertuple constraint on attribute A in tuple t depends on values of attributes in a tuple or tuples other than t.An aggregate type constraint on attribute A in tuple t depends on some aggregate (av- erage, sum, etc.) of a relation. We can apply this classification of attribute. domain con- straints to the object-oriented model. First, a cent ezt in- dependent constraint requires one or more invocations of the same functional method. An intraob~ect constraint on method A in object instance si depends on the re- sults more than one functional method in object si. An interobject domain constraint on method A in object in- stance Si depends on the results of methods in object in- stances Sjl, Sjn, where n is fixed in the constraint and is at least 1. An aggregate-restricted domain constraint on method A in object instances~ depends on one or more ag- gregates, each over all instances of a class or restriction of a class. Finally, an aggregate domain constraint restricts the domain of an aggregate result. Context independent domain constraints are usually eaay to express as integrity constraints. For example, con- straint 9 is a context independent constraint. As another example, suppose we wish to limit the result of method GetGrade to ‘A’, ‘B’, ‘C’, ‘D’ or ‘F’: Vc c course(c.GetGrade c {’A’,’B’,’C’,’D’,’F’}) (11) An example of an intraobject domain constraint is, “Each employee’s year of birt h must be leas than or equal to their year of hire less 18.” The constraint depends only on the methods within one object. (We don’t count the methods from the primitive class in this case, ) We can express the constraint as follows: Ve E ernployee(e.GetBirthyear ~ e.GetHireyear – 18) (12) Note that in constraint 12 the subtraction and comparison operators are both methods in the integer class. There are two major groups of interobject attribute do- main constraints. One group consists of those used with reference relationships. Briefly, a reference relationship is a relationship from instances of class X to instances of class Y in which an attribute A in X stores one or more object identifiers for inst antes of Y. (Reference relation- ships are defined more formally in [12, 15].) For example, suppose one of the named attributes of an employee ob- ject is the object identifier for an employee’s manager, and that Get Manager returns this identifier. The constraint, “The salary of each employee must be Ieas than or equal to the salary of the manager of that employee” can be expressed as follows: Ve E employee(e.GetSalary s e.GetManager.GetSalary) (13) Note that this constraint uses the notational “shortcut” of qualification to obtain the salary of the manager’s ob- ject. This notation is shorter and more intuitive than the 240 equivalent conventional form: Ve(ernployee(e) e VmV8,V8m (GetManager(e, m) A GetSalary(e, se) A GetSalary(m, s~) ~ leq(integer, s=,sin))) The other major group of interobject attribute domain constraints are for value based relationships. In the relw tional model, referential integrity is a value baaed intertu- ple constraint. Referential integrity can also be expressed as an interobject domain constraint in the object-oriented model. For example, suppose an employee’s integer job code is stored in the emplogee object, and there is a aepe- rate class jot which contains a job name for each valid job code, The referential constraint is: “For each employee, the job code matches a job code in the job class,” This constraint can be expreaaed as follows: Ve c enap/oyee(3j 6 job(e.GetJobCode = j. GetJobCode)) (14) For some methods in a class, it may be important to en- force certain relationships with other classes. Two exam- ples are the use of keys and disallowing null values. The integrity model can also enforce these relationship con- straints; see [15]. [15] also extends the data model to allow aggregate operators; the integrity model can then enforce aggregate-t ype constraints. Simulating Functional Dependencies Domain constraints can model valu~based functional de- pendencies from relational database theory. Given a rela- tion R with attribute Al , , An, a ftinctional dependency (FD) from Ai to Aj, (denoted Ai + Aj ) means that each value of Ai is associated with a single value of Aj. If we treat a relation as a claes, and a tuple of a rela- tion as an instance of a claaa, we can use a simple domain constraint to model a fictional dependency within an in- stance. Let class X contain functional methods GetE and GetF. We can enforce the dependency GetE-GetF within each object instance with the following domain constraint: VZ1, Z2 E X(zl.GetE =22 .GetE ~ Z1.GetF = z2.GetF) (15) Constraint 15 makes sure there is one value of F for each value of E. Note that an equality method = must be de fined for the result classes of GetE and GetF. Thus, integrity constraint exprewions can model the trw ditional functional dependency within instances, In addi- tion, they can model a notion of functional dependency between instances, where these instances may be from dif- ferent classes. Suppose we wish to enforce a functional dependency GetE-GetF, where GetE and GetY are methods in class X and GetF is a method in class Y. The following con- straint enforces this dependency: VZ1,Z2Ex (zl.GetE = z2.GetE -+ Z1.GetY.GetF = z2.GetY.GetF) Conclusion This paper has introduced an integrity constraint enforce ment model for the object-oriented data model. The in- tegrity model is layered over the data model, and does not access the internal structure of the data model. Therefore, it can be adapted to other data models, e.g., the relational model. In the relational model, we would assume a func- tional method MA exists for each attribute A in a relation. Given a tuple t, MA(t) would return the value of attribute A in that tuple. The integrity model described in this paper will handle many practical constraints, as illustrated in the examples. However, this model lacks the ability to describe all con- straints. One limitation of the integrity model is the lack of computation over an entire class, i.e., aggregation con- straints. For instance, suppose we have the object class fleet, where each instance in the’ class is an automobile in a fleet, and MilesPerGallon is an attribute of the class. We may want to express the constraint that the average miles per gallon for the fleet must be 27 or more. Thk constraint cannot be expressed with an integrity constraint expres- sion. Integrity constraint expressions can check predicate in each object in a class, but cannot perform aggregate cal- culations over the class. An extended version of the data model which handles aggregation is in [15]; the integrity model is alao extended to allow aggregate-type integrity constraints. Another limitation of this model is that it is strictly static in nature; it can only enforce constraints which deal with a single state of the database. It cannot handle dynamic constraints such as transition constraints or coordination and synchronization of transactions between different ob- jects. For example, a distributed multiuser system can send messages to an object in an order other than chron~ logical time. It is often desirable to ensure that transac- tions are applied in a well-defined order. Future work includes developing a prototype constrained data base system to teat these ideas. Object-oriented, logic-based, and functional approaches are being consid- 241 ered. Thechoice will probably beconstrained bythe avail- [9] ability occurrent products. Wearealso working on asecu- rity layer over the constrained data model, At this point, it seems likely that the security model will use the same framework as the integrity model. [10] Acknowledgments [11] The work of both authors was partially supported by De partment of Defense grant #5-30296. The authors wish to thank John Campbell and Howard Stainer for their sup- port and encouragement. This work is our own, however, and does not necessarily reflect the views of these other [12] people. References [11 [2] [3] [4] [5] [6] [7] [8] [13] Philip Bernstein, Umeshwar Dayal, David DeWitt, Dieter Gawlick, Jim Gray, Matthiaa Jarke, Bruce Lindsay, Peter Lockermann, David Maier, Erich Neuhold, Andreas Reuter, Lawrence Rowe, Hans Schek, Joachim Schmidt, Michael Schreff, and [14] Michael Stonebraker. The Laguna Beach report: Fu- ture directions in DBMS research. SIGMOD Record, 18(1):17-26, March 1989. Ramez Elmasri and Shamkant B. Navathe. Funda- mentals of Database Systems. Benjamin/Cummings Publishing Company, Inc., 1989. [15] Eduardo B. Fernandez, Rita C. Summers, and Christopher Wood. Database Security and Integrity. Addison-Wesley, 1981. Y.C. Hong and Stanley Y.W. Su. Associative hard- [16] ware and soft ware techniques for integrity control. ACM Transactions on Database Sgstems, 6(3):416- 440, September 1981. [17] Sushi] Jajodia and Boris Kogan. Integrating and object-oriented data model with multilevel security. In Proceedings of IEEE Symposium on Research in Security and Privacy, Oakland, CA, May 1990. IEEE. Teresa Lunt. Multilevel security for object-oriented database systems. In Proceedings of the Third IFIP WC 11.3 Workshop on Database Security, Monterey, CA, September 1989. Teresa Lunt and Jonathon Millen. Secure knowledge- based systems. Technical Report SRI-CSL-90-04, SRI International, Menlo Park, CA, August 1989. Amihai Metro. Integrity = validity + completeness. ACM Transactions on Database Systems, 14(4):480- 502, December 1989. Jean-Marie Nicholas. Logic for improving integrity checking in relational data bases. Acts Informatica, 18, 1982. J. Eric Roskos, Stephen WeIke, John Boone, and Terry Mayfield. A taxonomy of integrity models, im- plementations and mechanisms. In Proceedings of the l$th National Computer Security Conference, Wash- ington, D.C., October 1990. Ravi Sandhu and Sushi] Jajodia. Integrity mecha- nisms in database management systems. In Proceed- ings of the l$th National Computer Security Confer- ence, Washington, D.C., October 1990. James M. Slack and Elizabeth A. Unger. Reference relationship constraints: A new kind of integrity con- straint for object-oriented databases. Submitted for publication. James M. Slack and Elizabeth A. Unger. A for- mal model of object structure and inheritance for object-oriented database systems. In Proceedings of Great Lakes Computer Science Conference, Kalama- zoo, Michigan, October 1991. James M. Slack and Elizabeth A. Unger. A for- mal model of object structure, inheritance, and method invocation for object-oriented database sys- tems. Technical Report TR-CS-91-11, Kansas State University Department of Computer and Information Sciences, 1991. James M. Slack and Elizabeth A. Unger A model of integrity for object-oriented database systems. Tech- nical Report TR-CS-91-13, Kansas State University Department of Computer and Information Sciences, 1991. Jeffrey Unman. Principles of Database Systems. Computer Science Press, second edition, 1982. Susan Darling Urban. Alice: An aiwertion lan- guage for integrity constraint expression. In Proceed- ings of I%h Annual International Computer Software and Applications Conference, Orlando, Florida, 1989. IEEE. 242 . object-oriented data model. The in- tegrity model is layered over the data model, and does not access the internal structure of the data model. Therefore, it can be adapted to other data models, e.g.,. are formulas, then 237 AAB, AVB, A h B, 7A, VXA, 3xA are formulas. A closed formula is one for which each variable is quantified. Integrity constraint expressions are restricted to be closed formulas. integrity con- straint for object-oriented databases. Submitted for publication. James M. Slack and Elizabeth A. Unger. A for- mal model of object structure and inheritance for object-oriented database