Re: Key attributes with list values was Re: What are the differences ...KEY - 02-25-2006 , 10:27 PM
Brian Selzer wrote:
I change one value in the list, does that make it a new key? I would
The team with people whose ID's are 112233 and 123456 has a best run of
38 seconds in the potato sack race.
Most data modelers would choose to provide a team identifier rather
than implement a multivalued ID (even MV developers).
Re: Key attributes with list values was Re: What are the differences ...KEY - 02-25-2006 , 10:40 PM
Brian Selzer wrote:
and variables only. There are no pointers, there are no addresses,
and there is no concept of identity. There is only value.
This is not to say that the concept of identity is not consistent.
It certainly is, and useful programming languages have been
built on top of it. It is foundational to OOP. However, useful
systems have been built without it as well; it is not a necessary
I don't think identity is a concept with much useful life left in it.
Identity only makes sense relative to some address space,
and the world is shifting to distributed computing. There are
those who think that we can shift to a global distributed
address space, but I believe such efforts are doomed to failure.
Re: Key attributes with list values was Re: What are the differences ...KEY - 02-25-2006 , 10:57 PM
"What does it mean that an int is a key? If I change one bit in the
that make it a new key? I would think so."
I agree with both the list and the int version of the sentence. After
why should the particular type of the key change the way key values
But again, in my view it's not generally a language designer's job to
to dictate best practice. I instead like the idea of orthogonal
and recursive definitions. I like to make as many things as possible
first class status in the language. (Although I draw the line at first
variables a la SML, since that introduces identity.) If I decide that
shouldn't be keys, I'm going to have to put special purpose code in
to check for that, or else build a more complicated, more rigid model
that simply can't express the idea. Neither appeals to me.
MV Keys (was: Key attributes with list values) - 02-26-2006 , 04:43 AM
does that make it a new key? I would think so. (See below)
38 seconds in the potato sack race.
Would be the same proposition, right?
So, in this example we have a set-key, not a list-key.
Re: MV Keys (was: Key attributes with list values) - 02-26-2006 , 08:21 AM
model, which has only list attributes in which conceptual sets & lists
are both implemented.
-- perhaps that person is the lead person, the one we want to contact,
the one whose left leg is in the sack, the parent...
Re: MV Keys - 02-26-2006 , 09:48 AM
Really? Are sets implemented as well? I thought it was more like this:
When you have a model only supporting lists (e.g. XML) you have
no choice but to implement any multi-value thingy as a list - wether
you initially thought of it as a set or not.
Re: MV Keys (was: Key attributes with list values) - 02-26-2006 , 10:19 AM
that makes it a new key as well.
If you make a logical change to the value, it's a different value.
(Likewise, if the logical value stays the same but something
else changes, it's the same value.)
Re: Key attributes with list values was Re: What are the differences ...KEY - 02-26-2006 , 11:09 AM
"Marshall Spight" <marshall.spight (AT) gmail (DOT) com> wrote
a part? That certainly has identity.
internally. An entity must have identity, otherwise there's no way for the
database, or users, for that matter, to distinguish between them. That's
the whole point of keys. Because a key value determines all other attribute
values, it identifies an entity. But a there's a problem: a key value may
change over time, so any given key value's ability to determine what was or
is known about an entity is limited to a specific interval, bounded by the
time that its value became known by the database and the time that a new
value became known. This imposes limitations on the types of updates that
can be performed or the types of constraints that can be enforced. If all
keys can change, then either updates must be singular, that is, must affect
only one entity of any given type at a time, or no temporal constraint (a
constraint that involves the state of the database at more than one point in
time) can be enforced. This is a significant limitation of the Relational
Model with which I am most familiar, but I suspect that the concept applies
to all other data models, which may have means to overcome it. In the
Relational Model, all updates are set-based, and if all keys are subject to
change during an update and if the cardinality of the update is greater than
one, then there's no way to determine which tuple in a new relation value
corresponds to any given tuple in the original relation value. It should be
obvious that correlation is necessary to enforce a constraint that involves
more than one database state. Therefore, the only mechanisms available in
the Relational Model to enforce a temporal constraint are either to limit
updates so that they can only affect a single tuple in each affected
relation, or to prevent updates that do not hold at least one candidate key
constant in each affected relation.
This limitation is overcome by revealing as an attribute the identity that
is intrinsic to every proposition in the database. Every proposition must
necessarily be different from every other proposition, because either
something is known, or it isn't: the knowledge contained in a database is a
set of propositions, not a collection. Thus every proposition has identity
with respect to the state of the database at any specific point in time, and
that identity can be revealed as an attribute. In order to avoid losing
information over time, every new proposition must have a new identity value.
By that I mean that new values exist only for propositions that are
completely new to the database rather than to propositions that have been
changed. In other words, something can become known by the database, and
something that is already known can change. The distinction is subtle, I
know, but necessary--especially in a temporal database, but also in one that
only requires that transitions be constrained.
Re: Key attributes with list values was Re: What are the differences ...KEY - 02-26-2006 , 12:32 PM
Brian Selzer wrote:
that don't have any concept of identity in them. Mercury, for
example. (And in the non-general-purpose category, SQL.)
So I don't see how you could describe the concept as "necessary."
Useful, arguable, but not necessary. A turing machine doesn't
have any notion of identity. The lamba calculus has no notion
of identity. Come to that, the lambda calculus has no concept
of equality, either. Huh. So I guess neither one is necessary.
I'm not sure we're using the terms in the same way, though.
Do you speak Java?
Integer i = new Integer(1);
Integer j = new Integer(1);
System.out.println(i==j); // tests for identity
System.out.println(i.equals(j)); // tests for equality
Is that how you're using the terms?
In Java, == on a reference type tests for reference equality,
which is to say identity. If there were no reference types,
as in Prolog or SQL or whatever, then there is no identity.
are equal, they are the same value. If they are not equal,
they are not the same value. This is true for key values as
well as nonkey values.
Keys work because one can compare values, not because
one can compare identies. That is the fundamental difference
between keys and pointers.
Members of a set don't have identity.
on the data, then that might constain how you allow the data to be
updated. But that is true of any constraint. Constraints are semantic
things; values are logical things. 240 is a perfectly legal int, but it
might not be an allowed age for a person.
terminology. And anyway, if your domain wants keys that don't change,
just apply a constraint that enforces that.
what you appear to consider the ability to update too much.
Assuming you add code to reject these updates you don't
like, would you say that you had "removed a limitation"?
Also, I think you somewhat overstate the case. If I have
a relation of customers with customerid in the range 1 - 1000,
and I decide I want customer ids to start at 1,000,000, I can
"UPDATE Customers set CustomerId = CustomerId + 1000000;"
and there's an update that changes keys and has
cardinality greater than one, and I can still determine
which tuple in the new relation value corresponds to any
given tuple in the original relation value.
If you want a system that supports identity, you don't want to
be using set theory. There are plenty to choose from, and
they are well-supported and popular!
then I agree. If that's not what you're saying, then I don't
"identity value" as a synonym for key. Is that correct?
Re: MV Keys (was: Key attributes with list values) - 02-26-2006 , 01:04 PM
"mAsterdam" <mAsterdam (AT) vrijdag (DOT) org> wrote
Here we go again.