Re: ID field as logical address

"Bernard Peek" <bap_at_shrdlu.com> wrote in message news:fyzsOLNXFpJKFwr4_at_shrdlu.com...
> In message
> <688c5bfa-d377-40c4-b5f7-6a254e2ce314_at_k8g2000yqn.googlegroups.com>,
> robur.6_at_gmail.com writes
>
>
>>
>>Now, while the database is consistent, the information does not
>>reflect reality. But it is not system's fault, it is ours because we
>>made a mistake by not deleting the information from Departments. A
>>database reflects what was told. It just records the statements we
>>made if they conform to some constraints. It is our job to make sure
>>that we tell it the truth.
>
> As database designers we have an additional responsibility. We are
> supposed to build enough intelligence into the system that it can detect
> at least some of the lies people might tell it. We understand that the
> name "Mary Smith" is not sufficient to identify an individual so we design
> systems that can cope with holding data on two people with the same name.
>

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.

>
>
> --
> Bernard Peek
Received on Wed Jun 03 2009 - 18:04:00 CEST