Re: Relation Schemata vs. Relation Variables

From: Jon Heggland <jon.heggland_at_idi.ntnu.no>
Date: Sun, 03 Sep 2006 12:55:41 +0200
Message-ID: <edecf7$diu$1_at_orkan.itea.ntnu.no>


Brian Selzer wrote:
> "Jon Heggland" <jon.heggland_at_idi.ntnu.no> wrote in message
> news:edc6eq$507$1_at_orkan.itea.ntnu.no...

>> Huh? On the contrary, relvar-based TCs make that no problem at all. It
>> is only (what I call) tuple-based TCs that suffer from this problem. I
>> think you are confused by thinking in terms of entities instead of
>> propositions.

>
> No. I'm thinking in terms of sets. You can pair the elements of two tuples
> from successive database states for comparison because those elements are
> named values, and the names don't change. You can't pair the elements of
> two relations from successive database states for comparison because the
> elements of a relation are NOT named--at least not with a name that *always*
> survives a change. (You CAN use tuple identifiers to work around this,
> however.)

You can pair them in any way that makes sense for the constraint at hand, by specifying how the pairing is to be performed. Tuple identity is a red herring; it is neither needed nor wanted.

> From the standpoint of propositions. If ANY attribute value is different
> between tuples, then the tuples are not identical. You can't go any further
> than that without additional information.

And there's no need to.

> R JOIN R' assumes that the
> meaning of a candidate key value will remain the same throughout the change.
> In a closed world, if you can't prove that it's true, then it's not.

I don't know what you mean by this. Firstly: I cannot see that relvar-based TCs make any assumptions at all. Secondly: a (candidate key) value by itself has no intrinsic meaning. It is only when it occurs as part of a tuple in a relvar that it makes sense to talk about "meaning".

>> This is nonsense. Within the confines of an atomic statement, there is
>> no logical difference between "changing a tuple" and "removing a tuple
>> and adding another". All that matters is that some propositions cease to
>> be true, while others begin.

>
> There most certainly is! If you define a transition constraint that states:
> you can't delete a tuple if quantity is greater than 0, then splitting such
> an update into delete...insert must necessarily fail if any tuple has
> quantity greater than zero!

Only if you check the constraint *between* performing the delete and the insert. And that would be a logical mistake.

> In order to choose which transition constraints
> to enforce, the system must know what kind of transition is occuring.
> Consider a line of people waiting to be served at the bank, and a transition
> constraint that says that people can't jump in line. So, if you start out
> with (Bob, Brian, Lynn) in line, and then after a transition, you have (Bob,
> Brian, Sue, Lynn), do you reject the transition? Or did Lynn leave the line
> and then reenter after Sue? By only using R and R', you can't tell. But
> with Rd, Ru, Ri, you can. For example, Given the schema [...]

The database cannot enforce truth, only consistency.

The transition should be rejected (of course depending on the actual TC formulation, which you unfortunately don't provide). If you want the database to know that Lynn left the line and then reentered, you must tell it so by performing two updates: a DELETE first, and an INSERT afterwards (or the equivalent relational assignments, of course). The hypothetical TCs would permit this.

You do have a small point: that there may be multiple "paths" between two database states, and some of these paths may violate TCs and others not. Thus, you may need to tell the database which path corresponds to reality (or whatever it is you're representing). But as I show above, that is possible---even simple---without resorting to your transition sets. Your scheme adds complexity, but no power.

-- 
Jon
Received on Sun Sep 03 2006 - 12:55:41 CEST

Original text of this message