Re: Lucid statement of the MV vs RM position?

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.

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. 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.

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. (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.

-- 
Jon