Re: ID field as logical address

On Jun 4, 11:19 am, robu..._at_gmail.com wrote:
> On Jun 3, 7:04 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>
> > This is an example of the noise I referred to in a previous post. The
> > problem exhibited here occurs for /any/ key in which instances of it do not
> > permanently identify something in the Universe. This even includes keys
> > that are supposedly stable, such as part numbers or GL account numbers. If
> > it is possible to issue an update that targets one or more prime attributes,
> > then a join of the relations before and after the update can't be relied
> > upon for defining transition constraints.
>
> I see your point, but the problem has a different and subtle cause.
> You change the value of both the key and dependent attributes in the
> same time. So two logical operations are combined in a single
> relational assignment. This two-in-one approach hides some information
> from the system. The problem can easily be avoided by performing the
> operation in two steps (as shown earlier).

 In the given example you changed both name and state, or it was a different person with the same name. This kind of problems is easily solvable by performing the operation in several steps.

However I have to admit that your point sustains in one case even if you change only the primary key attribute.

If “Mary Smith, divorced” changes his name in “Mary Jones” (for whatever reason not related to marital status), and “Mary Jones, single” changes his name in “Mary Smith” (idem) then the constraint fails even if there are no changes in their states.

Swapping two key values is solvable only by a multiple assignment and an override of the transition constraint. This situation is very unlikely, but we have to admit that there is non-zero probability. Adding a surrogate key might help but I don’t think it should replace the natural keys.

This shows that the transition constraints are different from state constraints and a method for overriding them is sometime required (another example is making corrections). Received on Thu Jun 04 2009 - 12:43:26 CEST