Re: abnormal forms

From: paul c <>
Date: Thu, 20 Apr 2006 18:04:08 GMT
Message-ID: <s2Q1g.48207$7a.9444_at_pd7tw1no>

Bob Badour wrote:

> ...
> Asssuming that sva means an attribute with any type not a relation, an 
> rva and an sva have different types. One is a relation and the other 
> isn't. Thus one can never express an rva as an sva, and cardinality is 
> meaningless for a generic sva.

I can't argue against black and white but I'll try to give a bit of a case for a kind of pragmatic gray, even though it might be taken as triviality. Going back years, I've managed to read much of the RM's intents wrong. This has usually not bothered me as I could see I had plenty of company. Codd fastened on the table intuition and he and others didn't say much about rva's, mostly just that they were theoretically allowed, but over and over the experts talk about the logic and set-based motivation. This always seems slightly contrary or bass-ackwards to me, suggesting that they are something of an extention or appendage rather than being a central part of the underlying invention. I'm not saying that they have to be 'presented' in a UI, just that they seem to always 'be there'.

If you have relation

  1. SP{{S},P} with value

{S} P

---- -
{1,2} 1

is this relationally comparable to

2. SP{{S},P} with value

{S} P

----     -

{1} 1
{2} 1


and is it relationally comparable to

3. SP{S,P} with value

S         P
=         -         (where the '=' underscore means S is a 'key')
1         1
2         1


By 'relationally comparable' I guess I mean logically equivalent in a narrow sense of being susceptible to the relops without inferring any more from whatever predicate is chosen on a tuple-by-tuple basis. For example, unknown to a RDBMS, in the mind of a user, a predicate might have disjunctive connectors, such as "or". And it might not.

I'd like to be able to say that #2 and #3 are equivalent in this sense even though #2 is talking about S being sets and #3 is talking about S being single values. For sure, #3 is in a kind of canonical form as far as Codd was concerned. Also would like to say that #1 and #2 are equivalent in this sense even though it could mean saying that the 'the supplier set of 1 and 2 ships part 1' is the same as 'supplier 1 ships part 1 and supplier 2 ships part 1'.

By contrast I would say

4. SP{{S},{P}} with value

{S} {P}

---- ----
{1,2} {1}
{2,3} {1,2}

is not comparable to

5. SP{S,P} with value

S         P
-         -
1         1
2         1
2         2
3         1
3         2

My reason for saying this is that the presence of supplier 2 in two of #4's tuples seems to cause a kind of distortion of whatever the envisaged predicate is. For example, suppose the predicate of #4 is "the set of S suppliers are capable of shipping only the set of P parts combinations". If one were to delete the {2,1} tuple in #5, it wouldn't be clear as to which underlying tuple in #4 are logically deleted or updated - I'm trying to figure out if this is a phony reason or not.

The reason I think it might not be phony seems to need another example, say with a predicate that goes "these combinations of P parts have been shipped":

7. PS{{P}} with value



meaning at some time there was a shipment consisting only of part 1 and at another time there was a shipment consisting of part 1 and part 2. I can't seem to "single-out" the tuples in the rva tuples and get a comparable sva-ed relation without introducing another attribute (btw, to me this would be a 'surrogate attribute' and might help put the lie to the argument that surrogate keys are nonsense). The cause seems to sit around the overlapping subsets and makes me think that the above exercise is not quite phony, at least not just playing with notations.

One perhaps quirky fascination of mine is trying to avoid words like 'key'. It seems that I could express a key constraint with a notation that equates #2 and #3, something like "SP{{S},P} = = SP{S,P}", assuming one or a couple of axioms that allowed the singling-out of set elements when overlaps aren't present.

p Received on Thu Apr 20 2006 - 20:04:08 CEST

Original text of this message