Databases Reference
In-Depth Information
constraints in a nonsatisfiable schema are ill-designed because any facts
entered to the DB would give rise to constraint violations.
Example 4.13
Consider the following schema:
Some_Emp
¬
Emp(e,d)
Has_Mgr(d)
Mgr(d,m)
Works_For(e,m)
¬
¬
Emp(e,d)
Ù
Mgr(d,m)
IC1
¯
Some_Emp
IC2
¬
Emp(e,d)
ÙØ
Has_Mgr(d)
IC3
¬
Mgr(d,m)
ÙØ
Emp(m,d)
IC4
¯
Works_For(e,e)
This schema is unsatisfiable in any state. IC1 requires the DB to have at least
one employee working in a department, but IC2 enforces all departments to
have managers, while IC3 obliges managers of a department to be employees
of the same department. Since IC4 impedes nobody to work for himself or
herself (i.e., to manage a department where he or she works), it is impossible
to find a state of the DB that satisfies all four constraints.
Satisfiability checking is different from integrity constraint enforce-
ment, because the former is independent of any state and any update, while
the latter is not. Moreover, an unsatisfiable schema is repaired by changing
the definition of views and/or integrity constraints, while an inconsistent DB
is repaired by adding or removing facts that return the DB to a consistent
state.
View Liveliness
A derived predicate P is lively if there is a consistent state of the DB schema
in which at least one fact about P is true. Predicates that are not lively corre-
spond to relations that are empty in each consistent state. Such predicates
clearly are not useful and possibly ill-specified. As an example, neither the
predicate Q nor S is lively in a DB {Q(x)
S(x)}
because IC1 prevents any fact about them to be true. This definition of live-
liness essentially coincides with the definition of satisfiable in [66].
¬
R(x,y)
Ù
S(y), IC1(x)
¬
Redundancy of Integrity Constraints
Intuitively, a constraint is redundant if integrity does not depend on it.
Such a redundancy should be detected by schema validation and then be
