A Model of Integrity for Object-Oriented DatabaseSystems Kansas State University Abstract This paper develops a model of integrity for object-oriented database management systems based
Trang 1A Model of Integrity for Object-Oriented Database
Systems
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 ordistributed 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.
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,
Trang 2Figure 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; thesedo 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 Atransition 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 ideal situation iswhen 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
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 t wo 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 atriple (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 wit h 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 anobject si = (i, t,m) where tis aset-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
Trang 3non-state-changing method or a junctional method.
w
Figure 2: Parts of an object si = (i, t, m)
values An instance of a class is an object (i, t, m) where
tis 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 of81.
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 )1 where 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 sepsep-arated 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:
Trang 4) 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. Each transaction into a constrainedobject set is
constrainedin its actions by the integrity constraints
In-formally,a transaction is a method invocationthat comes
fromsomewhere“outside”the constrainedobject set (see
Figure 3) 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:
~ (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
Trang 5AAB, 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 forfor-mulas 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”))
Q3x13x2 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 isaasigned 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 afunction 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 - Zwhere
-(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 isasubset 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 O and 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:
+ (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:
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)
Trang 64.
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, , %))
isequivalent to
VZ1VZ2 .VZn(X(ZI) A X(X2) A X(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 ~ = VzE 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 ~
Trang 7is 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 tdepends on values of attributes in a
tuple or tuples other than An aggregate type constraint
on attribute A in tuple tdepends 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 obob-ject 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
Trang 8equivalent 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 arelation 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
Trang 9consid-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
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
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,
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 ofthe 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