Re: MV Keys

From: Brian Selzer <brian_at_selzer-software.com>
Date: Tue, 07 Mar 2006 14:51:25 GMT
Message-ID: <N5hPf.56961$dW3.6378_at_newssvr21.news.prodigy.com>


"Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message news:MPG.1e77690686affa66989793_at_news.ntnu.no...
> 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"?
>

I think I made my point clear earlier. The universe is the set of all possible values that are relevant to the discussion at hand and a set of rules for combining those values to form composite values, or propositions. Composite values are indeed propositions. If you have values A and B and group them together, then "A is associated with B" is a true statement. If order is important, then either "A comes before B" or "A comes after B" is a true statement. Composite values are certainly relevant to the discussion at hand, so they must also be part of the universe. That's what the combinatorial rules define: every association that can exist between elements, regardless of whether those elements are atomic or composite. Since every composite value is already an element of the universe, it's redundant to explicitly define a specific class of them as a domain.

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

You're missing the point. The whole numbers between 42 and 5286 are the magnitude of some class of values relevant to the discussion. Integers outside of that range must belong to a different domain.

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

Only if they cannot be resolved into components that are part of the universe of discourse. It's important to differentiate between resolution and transformation, at least how I'm using the terms. A composite value can be resolved into component parts, meaning that an association exists between the component parts. A possible representation of a value can be transformed into another possible representation, but the value does not change. For example, a point can be represented using cartesian coordinates or polar coordinates, but it's still the same point: no information is lost.

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

No, there isn't, as long as those aspects that are relevant within the universe remain constant. I'm not saying that creating a domain using active objects is a good thing, but theoretically, the only requirement is that each element have identity with respect to the universe of discourse. Now, as soon as the universe expands due to a change in requirements, you would probably be up the creek.

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

What do you mean by FOPL? First order predicate logic? I'm not a logician, but I think that the introduction of lists or other composite domains requires second order predicate logic because the definition of a list or composite domain depends on the definitions of the component domains. Isn't set theory based on first order logic?

>> > 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
Received on Tue Mar 07 2006 - 15:51:25 CET

Original text of this message