Re: MV Keys

From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 07 Mar 2006 03:20:44 GMT
Message-ID: <g_6Pf.43111$F_3.27902_at_newssvr29.news.prodigy.net>


"Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message news:MPG.1e765d711930178098978c_at_news.ntnu.no...
> In article <AcWOf.44985$H71.27027_at_newssvr13.news.prodigy.com>,
> brian_at_selzer-software.com says...
>> That's my point. Blue has identity within the universe of discourse. To
>> me
>> it seems more logical to talk about blue, not blue that can be the first
>> element in a list, blue that can be the second element in a list, blue
>> that
>> can appear in a list more than once, blue that can be the only element in
>> a
>> list, blue that can be in the same list as yellow, blue that can come
>> after
>> yellow, etc.
>
> Um... yes. There is only one blue; that it can be used in different
> context with different meanings doesn't change that, and doesn't cause
> any redundancy.
>

I think it does. If widgits is defined as a domain and lists of widgits is defined as a domain, and the same list of widgits can be arrived at through the use of the combinatorial rules of the universe, then the explicit domain definition is redundant. If you define constraints on the widgit list domain, but construct some widgit lists in a database without referencing that domain, then those constraints cannot be enforced for every list of widgits. On the other hand, you can limit the production of widgit lists with a single set of constraints that can be enforced for every list of widgits.

>> If the list (1, 1, 2) has been stated in a database, they're indeed
>> different, because the position in a list augments the meaning of each
>> element in the list.
>
> The interpretation of the number might be different, but the number
> remains the same. If I have three cats and three aunts, do I have the
> same number of cats and aunts? Yes. With no redundancy. Whether I store
> cat-and-aunt-counts in two columns, or in a single list-valued column
> (constrained to lists of size 2) makes no difference redundancywise.
>

>> >> This problem becomes more immediate if you consider
>> >> active objects. Assuming you have a domain for widgit objects, and a
>> >> domain
>> >> for lists of widgit objects, how can you discern which widgit you're
>> >> talking
>> >> about? Are they the same widgit, or are they separate instances with
>> >> the
>> >> same property values?
>> >
>> > Now you are talking about variables, not values.
>> >
>>
>> No, I'm talking about redundancy and the problems caused by it.
>
> No, variables. You talk about something that can be changed (isn't that
> what you mean by "active"?), and still retain its "identity". That's a
> variable, not a value. Values can't change.
>

Without First Normal Form, there's no limitation on the complexity of an attribute. Nor is there a requirement that domain elements remain static. All that is required is the ability to differentiate between elements, and the introduction of lists impairs that ability.

>> Once you discard First Normal Form, all bets are off.
>
> What bets? Are you saying a database not in 1NF is logically
> unsound/inconsistent? 1NF is orthogonal to the other usual NFs, except
> if you arbitrarily define the others to include 1NF.
>

I can't be sure, and that's enough for me to avoid applying NFNF like the plague.

>> > If there can be more than one (as it seems there can be, assuming a
>> > person can only have two parents), it is not a good idea to use the
>> > name
>> > to identify her. In that case, you have a list of names, not a list of
>> > children---and there is only one "Mary Smith" name. But this also has
>> > nothing to do with list attributes.
>>
>> It certainly has something to do with how list attributes can be abused.
>
> But you were trying to demonstrate the inherent redundancy introduced by
> list attributes, not redundancy caused by bad DB design. Anything can be
> abused; list attributes perhaps more so than other things---but they are
> not fundamentally harmful.
>

I think they are.

>> >> Assuming that you can determine Mary Smith has Bob
>> >> Smith as a parent, don't you have to also update the list associated
>> >> with
>> >> Jane Smith?
>> >
>> > I'm not sure what you mean here, since (a) Mary Smith is already
>> > present
>> > as a child of both Bob and Jane. But (depending on you definition of
>> > "having children", of course) I'd say you wouldn't necessarily have to.
>>
>> Are you related to Slick Willie? "Depends on the meaning of the word
>> 'is'"
>> sounds suspiciously like "depending on your definition of 'having
>> children'"
>> to me.
>
> Please. If Bob has a child, does Jane have the same child? You seem to
> assume so; I guess because in your mind, Bob and Jane are a couple, and
> wouldn't dream of having a child with someone else---alternatively, that
> since they are a couple, any child one of them has, the other also has
> in some legal sense. I tried to question your definition of "having a
> child": does it mean being the biological parent? Or the legal guardian
> (or whatever the term is; English is not my first language)? Or married
> to a biological parent? How do you know what the relationship between
> Bob and Jane is anyway? All this is crucially important for how your
> database should behave, so it makes little sense to talk about update
> anomalies and redundancy before this is clear. It may be clear in your
> mind, but you haven't communicated it.
> --

> Jon
Received on Tue Mar 07 2006 - 04:20:44 CET

Original text of this message