Re: MV Keys

Brian Selzer wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in message
> news:1141706092.790613.114350_at_p10g2000cwp.googlegroups.com...
> >
> > 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.
> >
>
> But we're not talking about a specific dbms,

OK, yes if you permit yourself to think outside the relation, the possibilities are endless. There is no limit to the features you can give and the complexity you can introduce. It makes the discipline broader than some might like to define it.

> and wouldn't that eliminate
> whatever benefits you perceive exist?

Nope, it doesn't. Both what can and what cannot be done with any given DBMS product can be seen as features. Restricting data to values of attributes in relations is a feature (whether appreciated or not). Similarly, if you can have one level of nested lists (which is all I ever use), you have both the feature of nested lists and the feature of restricting that to attributes within relations, not permitting lists within lists. The sweet spot might align with cognition or language or some visual, or it might align, as the RM suggests, with the simplest mathematics we can use to model such data. I think the latter is not the case if we define "sweet spot" to correspond to the cost of a solution over time.

> >> 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.
> >
> But that's not proof. In a system that processes tens of thousands of
> transactions per day, if you only have one anomaly per million transactions,
> the database will be corrupt in a month.

Exactly. Such systems have been around since before the RM, are used by large and profitable organizations, and have been in production sometimes for more than twenty years. This is not a proof, but at least some good emperical data could be gleaned from the facts. If you are concerned about any particular language that works with NF2 data, then I'm sure that could be evaluated too. Cheers! --dawn Received on Tue Mar 07 2006 - 15:25:23 CET