What are the differences between the terms, CANDIDATE KEY, PRIMARY KEY, SUPER KEY, COMPOSITE KEY?

#**141**

Jon Heggland wrote:

Quote:

As long as the type of a bunch of values is well-defined, there is
indeed no problem---indeed, that makes the two alternatives I outlined
equivalent. However, if any attribute is a set (or list), you probably
want (for convenience) to treat it as a single value of its constituent
type when it contains only one value, I.e. "Jon" = { "Jon" }. A language
that does this may exhibit undesirable behaviour in other places; I
believe SQL has trouble with table literals because of this.

Can you say more about this? What kind of trouble?

Marshall

#**142**

In article <MPG.1e720e3f9f7c590398977e (AT) news (DOT) ntnu.no>,
heggland (AT) idi (DOT) ntnu.no says...

Quote:

In article <1141372781.078243.197630 (AT) e56g2000cwe (DOT) googlegroups.com>,
marshall.spight (AT) gmail (DOT) com says...
Jon Heggland wrote:

As long as the type of a bunch of values is well-defined, there is
indeed no problem---indeed, that makes the two alternatives I outlined
equivalent. However, if any attribute is a set (or list), you probably
want (for convenience) to treat it as a single value of its constituent
type when it contains only one value, I.e. "Jon" = { "Jon" }. A language
that does this may exhibit undesirable behaviour in other places; I
believe SQL has trouble with table literals because of this.

Can you say more about this? What kind of trouble?

I think Hugh Darwen has written a piece on this. I'll try to dig it up.

http://www.dbdebunk.com/page/page/2928212.htm discusses this, among
other things (row types and user-defined types are also mentioned, in
connection with the main point: NULLs). It's quite amusing, in a scary
(for SQL users) way. It's mostly Darwen; Pascal-boycotters need not
fear. The point I was referring to is in #3 in the list of SQL mistakes
in Darwen's second reply; it may not be all that significant in our
current discussion, though.
--
Jon

#**143**

"Jon Heggland" <heggland (AT) idi (DOT) ntnu.no> wrote

Quote:

In article <GHgNf.26120$_S7.24277 (AT) newssvr14 (DOT) news.prodigy.com>,
brian (AT) selzer-software (DOT) com says...
Doesn't the determination of whether a type is scalar or not depend upon
the
universe of discourse?

In that case, scalar-ness is not a property of a type, but a property of
the use of a type in a certain context. I'd say that severely reduces
the usefulness of the concept (if it *has* any usefulness to begin
with

.

I don't see it that way. If you can talk intelligently about values that
are contained in a list apart from that list within the constraints imposed
by the universe, then the list is not atomic or scalar with respect to the
universe of discourse. The list can be resolved into components that have
meaning with respect to the universe independent of the list.

Quote:

I think that a string is a scalar if any of the
following statements hold: (1) individual character values don't belong
to
the universe of discourse, (2) the meaning of the individual character
values aren't directly augmented by the attribute name, (3) the meaning
of
the individual character values aren't augmented by their position in the
list, or (4) it is only the permutation of character values that has
meaning
with respect to the containing relation. For example, the elements in a
list of birth dates aren't just dates, they're birth dates;

Speaking of dates, is date a scalar type? Its components (year, month,
day) do belong to the universe of discourse in most cases.

Absolutely. Year, month and day are not components, they're
transformations. Time is a continuum, and dates are points along that
continuum. Year, month and day are functions of the number of days that
have passed since a widely accepted point in time.

Quote:

--
Jon

#**144**

In article <wMUNf.17845$rL5.2737 (AT) newssvr27 (DOT) news.prodigy.net>,
brian (AT) selzer-software (DOT) com says...

Quote:

I don't see it that way. If you can talk intelligently about values that
are contained in a list apart from that list within the constraints imposed
by the universe, then the list is not atomic or scalar with respect to the
universe of discourse. The list can be resolved into components that have
meaning with respect to the universe independent of the list.

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?

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

Quote:

Speaking of dates, is date a scalar type? Its components (year, month,
day) do belong to the universe of discourse in most cases.

Absolutely. Year, month and day are not components, they're
transformations. Time is a continuum, and dates are points along that
continuum. Year, month and day are functions of the number of days that
have passed since a widely accepted point in time.

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

#**145**

Brian Selzer wrote:

Quote:

I don't see it that way. If you can talk intelligently about values that
are contained in a list apart from that list within the constraints imposed
by the universe, then the list is not atomic or scalar with respect to the
universe of discourse. The list can be resolved into components that have
meaning with respect to the universe independent of the list.

A crucial point is that this is only true if the system offers a
mechanism to perform the decomposition. If it does not, then to the
system itself your compound datatype is a single value.

This is the reason that nested relations is a valid approach within
traditional RM - a compound datatype with a mechanism for its
manipulation.

#**146**

Jon Heggland wrote:

Quote:

In article <GHgNf.26120$_S7.24277 (AT) newssvr14 (DOT) news.prodigy.com>,
brian (AT) selzer-software (DOT) com says...
Doesn't the determination of whether a type is scalar or not depend upon the
universe of discourse?

In that case, scalar-ness is not a property of a type, but a property of
the use of a type in a certain context. I'd say that severely reduces
the usefulness of the concept (if it *has* any usefulness to begin
with

.

I think that a string is a scalar if any of the
following statements hold: (1) individual character values don't belong to
the universe of discourse, (2) the meaning of the individual character
values aren't directly augmented by the attribute name, (3) the meaning of
the individual character values aren't augmented by their position in the
list, or (4) it is only the permutation of character values that has meaning
with respect to the containing relation. For example, the elements in a
list of birth dates aren't just dates, they're birth dates;

Speaking of dates, is date a scalar type? Its components (year, month,
day) do belong to the universe of discourse in most cases.

Saying that the date is not scalar is akin to claiming that 254 is not
a scalar because it consists of units, tens and hundreds

Quote:

--
Jon

#**147**

Jon Heggland wrote:

Quote:

In article <1141324828.479189.199000 (AT) i40g2000cwc (DOT) googlegroups.com>,
marshall.spight (AT) gmail (DOT) com says...
Jon Heggland wrote:
So it is essentially an arbitrary decision? Why make it, then?

One necessarily makes a decision. The designers of SQL
chose only a single unordered collection. The designers of
Java chose only a single, ordered collection. (I'm referring
to the array; Java has certainly thrown an impressive
assortment of collections into the core API, but in-a-library
is not the same thing as in-the-language; all Java collections
are built on arrays and objects.)

Arrays *or* objects, I think you mean. (And arrays are objects as well.)
I don't really see the significance of how the collections are
implemented internally; half the point of OO is to make this irrelevant
anyway. And is the library/language distinction really that clear cut?
Is the String class in the language or in the library?

In any case, that wasn't really what I meant to ask. It seems you say
that compound types breaks 1NF, but that it doesn't really matter much;
and that the classification of types into compound and simple is
essentially arbitrary. What, then, is the use of talking about 1NF and
simple vs compound types at all?

While I don't think 1NF is a goal, and I am not settled on how scalar
and/or atomic values are best defined, I do think there is some sense
in having such a concept. There is a difference between a logical data
model where a list of e-mail addresses is modeled as a list attribute
of a Person or as a simple/scalar/atomic attribute of a separate
PersonEmail.

Quote:

I am not a mathematician. I am a software engineer.
I have to deal with implementation, so I don't necessarily
want to include everything I can think of. At the same time,
I want to optimize the power:complexity ratio the
programmer has available.

This is the same argument Date uses to espouse the relation type (or
type generator) as the only compound attribute type (generator)---it
introduces minimal extra complexity, since relations and relational
operators have to exist anyway, and it can handle both lists and sets.

This issue of minimizing complexity is confusing. A logical data model
is implemented by developers using an interface to a dbms. There are
trade-offs in any design, of course, and if we are going to build a
house with round walls it will cost additional dollars. But we don't
want dbms tool designers to suggest they will be making design
decisions based on simplifying the design for the computer or for the
dbms developers. The simplicity we need to care about a bit more is
the simplicity for the user of the tools. I think that is where
Marshall's use of the term "power" comes in. Surely you can implement
a list, for example, using the RM, but the tool is not doing much work
for you. It doesn't have enough power. It isn't simple enough from a
user standpoint.

Cheers! --dawn

#**148**

"Jon Heggland" <heggland (AT) idi (DOT) ntnu.no> wrote

Quote:

In article <wMUNf.17845$rL5.2737 (AT) newssvr27 (DOT) news.prodigy.net>,
brian (AT) selzer-software (DOT) com says...

I don't see it that way. If you can talk intelligently about values that
are contained in a list apart from that list within the constraints
imposed
by the universe, then the list is not atomic or scalar with respect to
the
universe of discourse. The list can be resolved into components that
have
meaning with respect to the universe independent of the list.

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. 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. 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 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? In addition, the way I see it, combining
values in a list is an application of one of the rules that belong to the
universe. The association of a value with other values in a set or list
clearly augments the meaning of that value along with all of the other
values in the list. It just doesn't make sense to me to define a domain in
the universe that is an application of one or more of the rules against one
or more scalar domains. It would make more sense to me for that to be part
of the database predicate.

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

Quote:

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.

Quote:

Speaking of dates, is date a scalar type? Its components (year, month,
day) do belong to the universe of discourse in most cases.

Absolutely. Year, month and day are not components, they're
transformations. Time is a continuum, and dates are points along that
continuum. Year, month and day are functions of the number of days that
have passed since a widely accepted point in time.

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.

Quote:

--
Jon

#**149**

Jon Heggland wrote:

Quote:

In article <1141320627.995968.219210 (AT) i40g2000cwc (DOT) googlegroups.com>,
jog (AT) cs (DOT) nott.ac.uk says...
Jon Heggland wrote:
If you instead say that a "cell" can and must contain exactly one value,
*but* that value may very well be a list, or a set, or a relation---then
there are no problems (in theory).

Neither of these. I was referring to a case where specifiying an
attribute-name may map to more than one "cell" as you refer to it. i.e.
not a one-one functional mapping but a generalised one-many mapping.

I don't really understand. You mean several columns/attributes with the
same name?

Join is crucial, and depends on equality between "cells". But with
multiple values, how do you define equality?

Well this has to be specified to the system as with all equality
matches. Is 15.0 equal to 15? Is "HELLO" equal to "Hello"? How is a
date greater or less than another? These subjective equality decisions
are already being made in numerous domains without significant issue..

In a sense this is no different in nature to something such as a C++
sort template where one has to specify a comparison function. Here,
when a type is created one can define how comparisons are made, and I
don't see a problem there.

As long as the type of a bunch of values is well-defined, there is
indeed no problem---indeed, that makes the two alternatives I outlined
equivalent. However, if any attribute is a set (or list), you probably
want (for convenience) to treat it as a single value of its constituent
type when it contains only one value, I.e. "Jon" = { "Jon" }. A language
that does this may exhibit undesirable behaviour in other places; I
believe SQL has trouble with table literals because of this.

I am not sure what all the fuss with types is about. The issue has
been settled in various functional PLs by treating types as [formal]
structures (sets with associated operations). So when it makes sense,
you can treat a bunch of values as an element of some type in which
case you'll get 1NF for free, or when it does not make sense for
whatever reason, you need to normalize.

Quote:

--
Jon

#**150**

Jon Heggland wrote:

Quote:

In article <GHgNf.26120$_S7.24277 (AT) newssvr14 (DOT) news.prodigy.com>,
brian (AT) selzer-software (DOT) com says...
Doesn't the determination of whether a type is scalar or not depend upon the
universe of discourse?

In that case, scalar-ness is not a property of a type, but a property of
the use of a type in a certain context. I'd say that severely reduces
the usefulness of the concept (if it *has* any usefulness to begin
with

.

I think that a string is a scalar if any of the
following statements hold: (1) individual character values don't belong to
the universe of discourse, (2) the meaning of the individual character
values aren't directly augmented by the attribute name, (3) the meaning of
the individual character values aren't augmented by their position in the
list, or (4) it is only the permutation of character values that has meaning
with respect to the containing relation. For example, the elements in a
list of birth dates aren't just dates, they're birth dates;

Speaking of dates, is date a scalar type? Its components (year, month,
day) do belong to the universe of discourse in most cases.

Saying that the date is not scalar is akin to claiming that 254 is not
a scalar because it consists of units, tens and hundreds

Quote:

--
Jon