Re: Natural keys vs Aritficial Keys

From: David BL <davidbl_at_iinet.net.au>
Date: Mon, 25 May 2009 00:57:53 -0700 (PDT)
Message-ID: <568d6b2b-1961-4649-8fad-080773361a6a_at_b7g2000pre.googlegroups.com>


On May 23, 4:23 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:

>

> Nope, that's still the first blunder: mapping object instances to
> tuples. Derived tuples are still tuples.

Date pointed out the obvious blunder in associating a class (which is a type) with a relvar (which is a variable). Bob is correct in the sense that derived relvars are still relvars.

I think it's worth making it clear that Bob shouldn't be interpreted as stating that tuple-variables are illegal in general (i.e. even when they aren't bound to a tuple in some relvar). There is nothing implicitly evil with tuple-variables! In fact many programming languages support tuple-variables.

I think the best way to understand the blunder is to realise that a relvar (only) introduces a binding between a variable and its current value which is a set of tuple values, and doesn't introduce a set of "subordinate" tuple-variables that individually have bindings to tuple values.

One benefit of thinking of the blunder this way, is that it suggests it needs to be qualified so the restriction doesn't necessarily apply where there are abstract identifiers. Note that an abstract identifier is a very different concept to an artificial identifier.

The blunder normally implies that a tuple in a relvar must not be identified with a variable ("object instance") of some class. However, in the case where the tuple contains an abstract identifier that can be interpreted as the name of a variable and the rest of the tuple defines the current value of the variable, it seems reasonable to define a mapping from tuples to class variables.

I'm actually suspicious of whether the RM is even appropriate when there are abstract identifiers. Received on Mon May 25 2009 - 09:57:53 CEST

Original text of this message