Re: 4 the FAQ: Are Commercial DBMS Truly Relational?

From: Gene Wirchenko <genew_at_mail.ocis.net>
Date: Sun, 10 Oct 2004 14:57:29 -0700
Message-ID: <oobjm05kivdsvo938hd3qtcrrikmiqta62_at_4ax.com>


Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net> wrote:

[snip]

>But what if I mistype the last name when entering the second row? Now I
>have "John Smith" and "John Smyth", with all other columns identical. The
>rows are unique but wrong. So then we add a unique constraint on SSN, but
>to every constraint we add I have a user who is going to put in a typo and
>give a unique but incorrect answer.
>
>What body of theory do we depend upon to deal with this next level of error?
>
>Practical experience seems to be that the Employee_ID column is the answer.
>By requiring that single unique column, I can eventually trace anomalies in
>the payroll system back to the presence of two "John Smith" rows that have
>different IDs. Great! Having discovered this human error after the fact,

     That single, unique column is also a constrained (PK). What happens when a key for that column is entered wrong? Why would it be any different for another key for another unique column, say SSN?

>I use the Employee_ID to merge the records together and delete or
>inactivate one row. But what body of theory describes this practice?

     "data cleaning"?

>Could it be back to the RDM? The Employee_ID column establishes the system
>as truly relational by brute force, every row is unique because that column
>will be unique.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:

     I have preferences.
     You have biases.
     He/She has prejudices.
Received on Sun Oct 10 2004 - 23:57:29 CEST

Original text of this message