Re: Lucid statement of the MV vs RM position?
Date: Thu, 04 May 2006 13:48:33 GMT
Message-ID: <RCn6g.3129$A26.80916_at_ursa-nb00s0.nbnet.nb.ca>
Jon Heggland wrote:
> Bob Badour wrote:
>
>>Jon Heggland wrote: >> >>>Bob Badour wrote: >>> >>>>I said it brushes up against it. It doesn't violate it in the sense that >>>>one can still refer to a set {P#} by the value of the entire set. But >>>>that's an awkward way to refer to it -- especially when the value can >>>>change with time. >>> >>>I'd say that's exactly how you do refer to a value---by the value >>>itself. If the "value" has a name, and can change with time, it seems >>>more like a variable, not a value. >> >>I am not sure what your point is. {P#} is a component of a variable, >>which means it can change with time.
>
> The same goes for any value appearing in a relvar, simple or no. My
> point is that to refer to a certain set as "{ 2, 6 }" does not "brush up
> against" the IP any more than referring to a certain integer as "7", or
> a certain date as "2006-05-04". And the set as such does not change with
> time (any more than "simple" values do); it is replaced by other sets
> (values).
>
> But maybe we talk past each other.
We must be because I thought I was very clear and explicit that using the set value does not violate the information principle, per se.
The notation "SP { S#, {P#} }" is
> lacking in that it (as I understand it) doesn't mention attribute names,
> only attribute types. The attribute whose type is "set of P#" ought to
> have a name, and that's how you refer to it.
Of course, and that is an important point for an actual dmbs. The example also left out any indication of the candidate keys. I assumed Paul omitted these things for brevity and to focus attention on the issue that most interested him.
> However, I interpreted you as lamenting the lack of a mechanism for
> referring to each particular set value (in each tuple) by something
> other than the set value itself -- i.e. a name or surrogate key of some
> sort, that is kept constant even when the set value is replaced. That
> may be a good idea, but that depends on the system requirements, not the
> IP.
I agree. If your only quibble is I did not mention requirements explicitly in my reply, then granted. I only suggested them by contrasting potential problems with actual problems.
(And if you do use such an identifier, there probably won't be any
> point in using a set-valued attribute anyway.)
>
> I realise that I'm putting far too many words in your mouth now, so I'll
> shut up soon. I just object to the notions that a set is anything more
> (or less) than "the value of the entire set", and that values can change
> with time.
Then, as near as I can tell, you and I agree completely. Received on Thu May 04 2006 - 15:48:33 CEST