Re: More on identifiers

From: Joe Thurbon <>
Date: Tue, 09 Jun 2009 02:22:15 GMT
Message-ID: <op.uu8jjdt7q7k8pw_at_imac.local>

On Sat, 06 Jun 2009 20:24:17 +1000, David BL <> wrote:
> On Jun 6, 12:19 pm, "Joe Thurbon" <> wrote:
>> On Fri, 05 Jun 2009 14:52:27 +1000, David BL <>
>> wrote:
>> [...]
>> > Due to the projection, all the abstract identifiers have disappeared
>> > from every relation. In a way, it's like seeing a database within a
>> > database! The value of the "inner" database records all the facts in
>> > the /context/ of just one of the items, and therefore has no need for
>> > abstract identifiers to glue things together.
>> I may have misunderstood, but haven't you just moved the 'problem'?
> I don't understand what you mean.

I think I might have misunderstood your motivation. More below.

>> That
>> is, each abstract identifier that you want to get rid of ends up with
>> 'its
>> own database'.
> Yes, the intention is to eliminate the abstract identifiers from the
> logical model, by instead using a database /value/ as a descriptor for
> each item. This value is only a function of the recorded visible
> properties of the item.

O.K. I had understoon that correctly.

>> Two database values that came from entities that differed
>> only by their abstract identifier will not be distinguishable.
> That is a good thing! It means that two items that are
> indistinguishable in terms of the /recorded/ visible properties have
> the same descriptor value.

Good, I had understood that bit too.

>> So to
>> distinguish between them, the abstract identifiers and up being arbitary
>> names of databases.
> The idea is not to distinguish them. That's an advantage of
> completely eliminating the abstract identifiers from the logical model
> by using DVAs. If there are duplicates then the "outer" database can
> record the number of duplicates.

O.K. This is where you lost me. I had thought that in your example:

(1) some client of a database wanted to distinguish between two things that don't have distinguishing features
(2) the RM makes them use abstract identifiers to achieve it (3) your solution 'lifts' the abstract identifiers out of the relations, and 'into' variables.

If the idea is not to distinguish them, then why were there abstract identifiers in the first place?

> Of course more generally the
> descriptors could take part in all sorts of relations in the "outer"
> database.

If so, we seems to be back where we started, apart from now having N databases instead of one. (Where N is the number of abstract identifiers that got 'lifted').

I'm pretty sure I'm missing something. (I wonder how embarrassing it will be when you point it out).

> A binding between a name and a value can be regarded as a variable
> (something that "holds" or "encodes" a value). The elimination of
> abstract identifiers can be regarded as the elimination of variables
> from the logical model.

So, if the "inner" databases now comprise the logical model, what do you call the "outer database"?


P.S. I'm pretty time-constrained at the moment, sorry about the time-lag between responses. Received on Tue Jun 09 2009 - 04:22:15 CEST

Original text of this message