Nulls, integrity, the closed world assumption and events

Suppose M,F are non-nullable foreign keys with enforced referential integrity back into the person relation. By induction a non-empty database would have to be infinite.

One possible solution is to allow M,F to be null. This proposal is at odds with the purity of the predicate calculus.

Another solution is to drop the enforced referential integrity constraint. However it seems rather suspicious to pretend that some parent is not a person (in the DB) even though they are mentioned in the DB.

A third solution is to regard the above person relation as bad because it is at odds with the closed world assumption. Instead, it is better to limit a person relation to something like

    person(P) :- P is a person

and use other relations to represent the family tree, such as

    mother(M,C) :- M is the mother of child C     father(F,C) :- F is the father of child C

Note that as it stands we have quite weak integrity constraints because a person may have any number of mothers and fathers.

Alternatively we could represent birth events

    birth(L,T,P,M,F) :- Person P was born to M,F at location L at time T

This could be keyed on attribute P, ensuring that each person can be born at most once and therefore have at most one mother, one father, one birthplace and one age.

Interestingly (and IMO not surprisingly), representing the underlying events that occur in space and time offers a good trade-off in terms of integrity constraints, and fits in well with the closed world assumption.

Another perspective on this: relations represent facts not entities. The whole idea of RM is to represent information *about* entities using predicates. The idea that a record in a table represents an object has more to do with the OO approach.

Consider that we store marriage information in a person relation

    Person(P,S) :-Person P has spouse S.

Clearly the spouse attribute would need to be nullable. It would be better to store marriages in a separate relation, such as

    married(P1,P2) :- P1 and P2 are married

But people can get married and divorced multiple times. To represent this it may be better to store the information using events. Eg

    wedding(L,T,P1,P2) :- P1 married P2 at location L at time T.

There are some nice features about using events for relational models.

1. Events are immutable.
2. Events give us history
3. The relationships between entities can vary over time.
4. Events occur in space and time and therefore align well with some form of closed world assumption that is localized in space/time.

However there is an increased computational burden if the current set of relationships have to be calculated from the events. This is a caching issue, such as when a bank caches an account balance.

David Barrett-Lennard Received on Mon Jan 08 2007 - 03:05:39 CET