Re: MV Keys

In article <g_6Pf.43111$F_3.27902_at_newssvr29.news.prodigy.net>, brian_at_selzer-software.com says...
> > 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.

Why? And what do you mean by "arriving at a list of widgits through the use of the combinatorial rules of the universe"?

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

So what? If you want domain constraints, you have to create a domain--- which is then distinct from other domains. I can create a domain of integers between 42 and 5286; that does not preclude using integers outside that range elsewhere in my database.

> > 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 *with* 1NF---but that might of course depend on you definition of both "complex" and "1NF". How complex is a BLOB? An image? A fingerprint? A video? I say any of these can be used as an attribute value, and doing so doesn't affect 1NF.

> Nor is there a requirement that domain elements remain static.

If you by "domain elements" mean "values", yes there is. I'm sure you agree that if you define an integer variable, assign it the value 1, and later change it to 2, you have changed the variable, not the value. The number 1 and 2 are unaffected by your operation; they exist independently of your variable.

It is important, but obviously difficult, to realise that this holds for *all* domains, including lists. You can define a list variable, assign it the value [1, 2], and later change it to [1, 3]. You have changed the variable, but not the two list values; they exist independently of your variable (regardless of whether they are represented anywhere in your computer's memory).

What makes this difficult to understand is that common programming languages (e.g. Java) confuses this by using pointers/references to variables---which leads to all the confusion about identity versus equality, and updates with side effects when several reference variables points to the same list variable. Try to imagine C# with just structs, not classes.

Or consider the relational algebra: A selection/restriction does not change a relation value, it produces a new one. Of course, you can take advantage of this to alter a relation variable, effectively performing (say) a delete. Likewise, a list removeAt() does not change a list value; it produces a new one. You can use this to change a list variable, and this is indeed done automatically for you in many programming languages---but not necessarily.

> All that is required is the ability to differentiate between elements, and
> the introduction of lists impairs that ability.

You have not shown that yet.

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

What aspects of FOPL and set theory are affected?

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

I know you do, but I won't take it on faith.

-- 
Jon