Re: Key attributes with list values was Re: What are the differences ...KEY

"Marshall Spight" <marshall.spight_at_gmail.com> wrote in message news:1140928800.027615.223480_at_i39g2000cwa.googlegroups.com...
> Brian Selzer wrote:
>> What I'm trying to convey is that from one point of view, a list
>> has identity, regardless of its contents.
>
> I reject this point of view. The system I am building has values
> and variables only. There are no pointers, there are no addresses,
> and there is no concept of identity. There is only value.
>

What about the list of operations and materials that are required to produce a part? That certainly has identity.

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

I disagree. It is a necessary concept, not only externally but also 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.

>
> 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.
>
>
> Marshall
>
Received on Sun Feb 26 2006 - 18:09:43 CET