Re: Database design, Keys and some other things

JOG wrote:
> Gene Wirchenko wrote:
> > >P = { <feature: sky>, <colour: blue>, <period: daytime> }
> >
> > >The extra information I specified in the previous post however, is
> > >absolutely not part of this statement about the world. Rather it is
> >
> > Of course it is. If nothing else, it is bibliographic, but I
> > would restructure the statement to:
> > [Gene's P =] James says that [James's] P.
>
> If you are saying there is a distinction between the observer of the
> proposition and the creator of the tuple, just as there is a
> distinction between the time of the observation and the time of the
> tuples creation in the db, well, yes I agree. This was the intention of
> the example, although it may have become obfuscated along the way. But
> there is a distinction, and if Gene were the person who observed the
> the fact that the sky is blue in the day, we have:
>
> P = { <feature: sky>, <colour: blue>, <period: day>, <observer: Gene>}
>

Instead:
  P = {< feature: sky>, <colour: blue>, <period: day>, <observer: Gene>}

James creates:
P = {< feature: ocean>, <colour: blue>, <period: day>, <observer: Gene>}

In fact James here avoids the truth.

The DB Designer should to solve some bizarre situations especially if he decides to allow input of the facts related to attribute. Besides the cheating a data entry person also can enter the fact, no fact (he believe that it is a fact but it isn't) as well as thing for which he doesn't know is it a fact or not. You can have the VIN88 in your database and the car in the Real World with the VIN88.
But it can happen that an operator entered the wrong value for some attribute. For example, he entered VIN88 instead VIN89. Only difference between these two cars is that VIN88 has "light silver" and VIN89 has "dark silver" for the InteriorColor attribute. Now you can "identify" the Real World entity using VIN88 number, but this is not it (because of the colour). People usually solve this kind of the problems even if it is an intelligent crime. But mapping between the entities from the Real World (and also from the Conceptual Model) and your database is not a 1-1. So some keys are meaningless. You can have many things in your database.

> M = { <creator: James>, <created: 1127871055>, <statement: P> }
>
>
> P is just a finite partial mapping, and as such my (granted often
> unreliable) spider-sense is still telling me that like any function,
> there may exist relationships that do not belong as part of P's
> extensional representation (orderings, set membership, etc). Easy
> employment and manipulation of these would utilise an implicit
> conceptual reference (as I would use the letter P in the mathematical
> notation - but instead I have to hack in and manage an explicit
> artificial key, or specify "on update cascade"s all over the shop to
> maintain integrity.)
>
>
> On a side note, it has of course been pissing it down in the UK, and
> the sky is absolutely, categorically and unequivicably, not blue :)
Received on Thu Sep 29 2005 - 19:29:10 CEST