Re: Nulls, integrity, the closed world assumption and events

"David" <davidbl_at_iinet.net.au> wrote in message news:1168221939.497022.53490_at_11g2000cwr.googlegroups.com...
> Consider the following relation
>
> person(P,M,F) :- person P has mother M, father F.
>
> 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
>

When talking about NULLS, the less said, the better! Received on Mon Jan 08 2007 - 20:02:11 CET