Re: MV Keys

In article <NTXNf.62440$PL5.60906_at_newssvr11.news.prodigy.com>, brian_at_selzer-software.com says...
> "Jon Heggland" <heggland_at_idi.ntnu.no> wrote in message
> > What universe? A concrete example: I can use a varchar as a string
> > (where, for the sake of the argument, I postulate that the individual
> > characters "have no meaning"), or as an array of characters (where they
> > do). The DBMS doesn't know (or care) what meaning I apply to either
> > varchar---so what is the point of the distinction? Just to say that one
> > design (the one using varchar as an array) is probably bad, and the
> > other is not?
>
> I take issue with stuffing nonscalar values into attributes. The universe
> of discourse is (at least for relational databases) the set of all possible
> values for all relevant domains and a set of rules that describe how those
> values can be combined.

I don't really understand. What kind of rules?

> It is clearly redundant to have the same value in a
> scalar domain and a domain of lists, because undoubtedly, there's an
> operator available that can extract that value from the list so that it can
> be discussed.

Why is this redundant? It is not very clear to me. Can you show an example of such redundancy? Is it redundant to have both Strings and chars?

Is this only an issue with (variable-length) collection types? What about a phone number with an area code part? Or a location with latitude and longitude?

> I think that redundancy in the universe of discourse is worse
> than redundancy in the database, because it undermines the logical
> foundation of the database.

How so?

> How can you know if you're talking about the
> same thing if it values in the universe of discourse don't have identity
> with respect to that universe?

Why wouldn't they have?

> A database is a logical thing, so it is not relevant what the DBMS knows or
> cares.

Then how can it have any practical significance? Can you give any examples of anomalies or redundancy caused by "stuffing nonscalar values into attributes"?

> > My point is that you can't say that a type (e.g. varchar) is scalar or
> > not a priori; you have to say "the way varchar is used by this operation
> > in this particular database means it's not a scalar here". Hence,
> > scalar-ness is a property of some use of some variable of a type, not of
> > the type as such. I think we actually agree; you do say "scalar /with
> > respect to the universe of discourse/" (my emphasis).
> >
>
> Whether something is scalar is a logical concept, not a physical one. Also,
> it's not the operation in a particular database, but rather the definition
> of a domain in the logical universe that determines whether or not something
> is scalar.
>
> I think we do agree. Something is scalar with respect to the universe, or
> less precisely, with respect to the context in which it is used.

I don't think your "universe" concept is very precise, but ymmv.

> > Or the other way around. Are substrings of strings components or
> > transformations? What about subranges, or individual values, of arrays
> > or lists? What is the difference?
>
> If a string is atomic within the universe, then a substring must be a
> transformation. If it's not, then both the string and the substring are
> compound entities subject to the rules of combination that are defined in
> the universe. I'm using the term entity deliberately here, because such
> instances have identity with respect to the database. They're propositions,
> not values.

So basically, it is whatever we define it to be? Anyway, whenever the term "entity" enters a discussion, I leave it to its misery. :)

-- 
Jon