Re: MV Keys

Brian Selzer wrote:
> "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.

There certainly can be. Even if sounds arbitrary, a dbms vendor can permit lists and not bags; nested lists, but no lists nested within lists; etc.

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

It is not difficult to ask if two values are equal when they are list values. Why do you think it would be?

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

There's plenty of emperical data that should permit you to sleep well even if using NF2.

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

Because...? --dawn Received on Tue Mar 07 2006 - 05:34:52 CET