Re: More on identifiers

On Jun 9, 10:22 am, "Joe Thurbon" <use..._at_thurbon.com> wrote:
> On Sat, 06 Jun 2009 20:24:17 +1000, David BL <davi..._at_iinet.net.au> wrote:
> > On Jun 6, 12:19 pm, "Joe Thurbon" <use..._at_thurbon.com> wrote:
> >> On Fri, 05 Jun 2009 14:52:27 +1000, David BL <davi..._at_iinet.net.au>
> >> 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?

I disagree with (1) and (3) and the idea that (1) is the underlying reason for (2). What I'm actually stating is:

(a) The flat RM often forces the use of abstract

     identifiers (irrespective of (1))

(b) It is possible to interpret abstract identifiers as

     names of variables in the logical model

(c) It is possible to eliminate abstract identifiers by

     using DVAs, and this eliminates the variables from the
     logical model.

I think just about everyone agrees there is no point distinguishing what cannot be distinguished by the recorded visible properties. When there are duplicates the general consensus is to instead record types of items and the number of that type. So if we are reducing the problem of duplicates to recording information about the distinct types of items, it is very similar to the case where it can be assumed that there were no duplicates in the first place. What I mean is that this has little bearing on why the flat relational model tends to force one to label things - because a type of thing is still a thing. Putting it another way, not all things have to be so concrete that they are localised in space and time like a specific physical object, and humans deal with that form of abstraction all the time.

The problem is that the flat RM forces one to use abstract identifiers under quite general circumstances. This has nothing to do with whether there are duplicates. Instead it has to do with the need to tie all the propositions about an item (or type of item if there are duplicates) together.

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

When one says "an integer", "a tuple" or "a relation" it is assumed one means a value not a variable. For example, it doesn't make sense to say "update an integer".

In the context of this discussion I would like this terminology to apply similarly when one says "a database". i.e. it means a value which is some set of named relation values. However this is inevitably going to cause a lot of confusion which suggests I need a different word. In normal parlance, a database is actually what I would call a database variable, because a (physical) database records state on physical hardware that exists in space and time. For example, it is common to say something like "update a database" instead of "update a database variable".

In the above you said "now having N databases". If you mean database values then that doesn't make sense, because the number of possible database values is infinite. It's as meaningless as saying how many integers you have.

So assuming you mean database variables, you have indeed misunderstood something, because an "inner database" is treated as a value of an attribute of a tuple within the containing "outer database". The "inner database" doesn't imply the existence of an associated variable. That indeed is the whole point to how they are able to eliminate variables from the logical model.

It is important to understand for example that a variable that holds a set of values is not generally the same as a variable that holds a set of variables.

So to make it clear, I'm suggesting that there is only /one/ database variable in the scenario of recording all the information about the items in a physical database.

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

I would say rather informally that logical models can compose by using DVAs. Received on Tue Jun 09 2009 - 06:50:02 CEST