Re: 3NF question

From: vldm10 <vldm10_at_yahoo.com>
Date: 11 Jan 2005 18:03:10 -0800
Message-ID: <1105495390.844644.17120_at_f14g2000cwb.googlegroups.com>


tore.trollsaas_XATX-xatx-_at_skedsmo.online.no wrote:
> On 9 Jan 2005 16:07:46 -0800, "jonnie" <jsavell_at_gmail.com> wrote:
>
> >
> >DA Morgan wrote:
> >
> >> > I respect what you have said. On the otherhand, I would like to
say
> >> > that I believe ID can be an acceptable attribute for an object,
> >even if
> >> > a sequential identity scheme is deemed unsuitable.
> >>
> >> I disagree. A person table might have a person_id that uniquely
> >> identifies that person within a specific application. But a column
> >named
> >> ID has no place in any set.
> >
> >OK. If that's all I have to do to get off the fire, then fine. I
would
> >like it to be called person_id instead of ID.
> >
> >-jonnie
>
> ... and possibly you would even consider MemberNbr, EmployeeNbr ,
SSN,
> etc. Maybe even ZipCode ;-)
>
> Consider what would happen if they were all named ID ? "ID What?"

Using everyday language, I can tell you that this table has two keys and you will understand this, even though I haven't used their names. In order to implement this into a Relational Model, you will need two different names for each key in this table. Two names "chair" and "mathematics" can have very different levels of meaning. If a person knows ten mathematical theories, then the name "mathematics" means much to him. Similarly, the meaning of a column name "Identifier" can greatly differ from the meaning of a column name "Hair_Color". The name "Identifier" means much in the Relational Model ( provides a tuple-level addressing mechanism; important roles in "join mechanisms ", etc). The name "Identifier" reminds a knowledgeable person of many database details and means much to him. Such a person doesn't need to write the name Identifier_of_PERSON because he knows that this identifier is already in the PERSON table and is the identifier of its tuples.

If we have two tables, USER and LOG, we can create two pairs of names for these tables:

Userid, Logid or Id1, Id2

Both of these are OK.
The names Userid and Logid are more meaningful for less knowledgeable people and users of the database who don't need to know what identifiers are. Since databases are used by a wide range of people, such names are better in this sense. Nothing more.

The above written is for the case in which the keys are created only to be identifiers for tuples of some table
(they have no other meaning).
If you create a key from existing atributes, for example if your key is

firstname+lastname, then your key identifies at least two things: the person in your aplication and one tuple in Person table. This means that the column name Personid is, in fact, a name for two things? Vladimir Odrljin

> mvh Tore
Received on Wed Jan 12 2005 - 03:03:10 CET

Original text of this message