Re: Relation Schemata vs. Relation Variables

JOG wrote:
> brian_at_selzer-software.com wrote:
> > [snip]
> > As has been made clear in earlier posts, keys can change, so unless you
> > introduce object identifiers or immutable surrogates, you cannot
> > *always* enforce transition constraints based only on key values.
>
> oids are clearly no use as they are not observable identifiers.
>
> However, you are correct - surrogates /can/ be used. The problem is
> your use of the term 'immutable' - it is the wrong perspective,
> starting from a db schema viewpoint, as opposed to correctly starting
> from the necesseties of real world identification. Its consistency of
> identification that matters there rather than some notion of
> immutability.
>

You may indeed be right. It's difficult to enforce an immutability constraint because it's also a transition constraint, and if you take your eyes off the ball, someone may have switched it with another while you weren't looking. So a surrogate will work, provided the meaning injected into the surrogate is independent of time--that is, the values have never been used before will never change and will never be used again.

I tend to look at things from more of a practical standpoint than a theoretical one, so when I think about constraints, I think more in terms of how they can be enforced rather than what they do, probably because over the years I've had to work around so many implementation limitations. My perspective is therefore more pessimistic than optimistic. I tend to focus on whether or not a constraint can be circumvented rather than which is the best way to declare one.

> > (I percieve other problems with relations that have more than one
> > candidate key, but I haven't drawn any conclusions.) My main objection
> > is the injection of irrelevant information when it's not necessary.
>
> A surrogate is not irrelevant. It may be vital information.
>

If it's not required to get the job done, then it's not relevant and thus shouldn't be defined in the schema; if it's defined in the schema, then it's relevant. For that matter, if a proposition about something appears in the database, then the proposition is true and the thing both exists and is relevant. If a proposition about something doesn't appear in the database, then either the proposition is false or the thing is either not relevant or does not exist.

> > If a change can be observed, then it doesn't matter if keys change, you're
> > still looking at the same thing. That's why I think that the update
> > semantics of the model should be augmented to allow the user to specify
> > how facts correlate if needed. This does not break the model, it just
> > makes it possible to enforce transition constraints when keys can
> > change.
Received on Wed Aug 23 2006 - 20:06:53 CEST