Re: Multiple keys and transition constraints

"Keith H Duggar" <duggar_at_alum.mit.edu> wrote in message news:1158370459.256735.186160_at_i3g2000cwc.googlegroups.com...
> Brian Selzer wrote:
>> Given a relation schema R {A, B, C}, where A and B are
>> each candidate keys.
>>
>> If the current extension is
>>
>> r {{A:1, B:9, C:3}
>> {A:2, B:8, C:4}}
>>
>> and the proposed extension is
>>
>> r' {{A:1, B:8, C:4}
>> {A:2, B:9, C:3}}
>>
>> is only A different? Or are both B and C different? From
>> one perspective, both B and C remain constant but A is
>> different. From another perspective, A remains constant
>> but both B and C are different.
>
> What is A? What is B? What is C? When you say "is only A
> different", what if I respond "no, A is A"? Is A a symbol
> denoting a set? If so then A denotes {1,2} in extension r
> and A denotes {1,2} in extension r'. Thus that which A
> denotes remains unchanged in r and r'; and in that sense
> "A is not different". And neither are B nor C different.
> Or does A denote a domain {0,1,2,...} for example? If so
> then perhaps A, B, and C never become "different".
>
> Or look at it this way. A, B, and C do not become different
> any more than 1, 2, 3, 4, 8, and 9 become different. Has 1
> changed? Or is only 4 different?
>
> What is different are the two extensions r and r'; what is
> different are the tuples that compose r and r'; what is not
> different are the ever constant /values/ that compose those
> tuples.
>
> This is the semantic gulf in which many of your arguments
> have drowned. When you say "is only A different?", it seems
> that you have in mind some implicit thing, other than A,
> that you hold /is/ A. Some physical storage perhaps?
>
> It is the view you have, that A /is/ a thing other than a
> symbol denoting either a domain, extension, or property that
> separates you from many against whom you have butted heads
> recently. Because your notion seems rather physical. Ie that
> by A you mean some storage space or memory location. If it
> is not physical, then it's up to you to provide a clear
> (and concise) explanation of what you mean by A.
>

A, B and C are attributes belonging to the relation schema R. Their values belong to N, that is, the domain of natural numbers. r and r' are the current and proposed extensions (or instances, or values) for R.

r {{A:1, B:9, C:3}

    {A:2, B:8, C:4}}

r' {{A:1, B:8, C:4}

    {A:2, B:9, C:3}}

Now, in order to compare a value for C from a tuple in r with a value for C from a tuple in r', the tuples must be paired.

In a pairing achieved by joining r and r' on A:

p1 {({A:1, B:9, C:3},{A:1, B:8, C:4}),

       ({A:2, B:8, C:4},{A:2, B:9, C:3})}

it is clear that the value for C in each tuple from r is different from the value for C in the corresponding tuple from r'.

In a pairing achieved by joining r and r' on B:

p2 {({A:1, B:9, C:3},{A:2, B:9, C:3}),

       ({A:2, B:8, C:4},{A:1, B:8, C:4})}

it is clear that the value for C in each tuple from r is identical to the value for C in the corresponding tuple from r'.

The pairing achieved by joining r and r' on the superkey AB:

p3 {}

is empty.

So, which key do you use to pair up the tuples for comparison? Must a transition constraint always be specified in terms of the determinant and the dependent of a functional dependency? In other words, is what is being specified the allowable associations between values from two or more attributes, given the current association? Or is it the allowable values for a single attribute of the schema given the current value?

What bothers me most is the disparity between what is presented for comparison, that is r and r', and the stated intent of the user. Information is lost when an update is transformed into an assignment.

Here's another example. Assume you need to enforce a business rule that says that all parts must pass through inspection prior to being shipped. So, given a relation schema

INV {WHSE, BIN, PART, QTY} where {WHSE, BIN, PART} is the only candidate key, and the following extensions:

inv {{WHSE:1, BIN:A101, PART:123, QTY:20},

       {WHSE:1, BIN:INSP, PART:123, QTY:30}} inv' {{WHSE:1, BIN:SHIP, PART:123, QTY:20},

        {WHSE:1, BIN:INSP, PART:123, QTY:30}} If QTY was not targeted by the update, then it's clear that the modification should be rejected. Similarly, if the tuple {WHSE:1, BIN:INSP, PART:123, QTY:30} was not targeted by the update, then it's clear that the modification should be rejected. Of course, that information isn't available given only inv and inv' because the stated target of the update was obscured in order to mold the update into an assignment. Also, because a prime attribute was affected, the stated correlation between tuples in inv and tuples in inv' was projected away in order to mold the update into an assignment.

> -- Keith -- Fraud 6
>
Received on Sat Sep 16 2006 - 22:14:34 CEST