Re: 4 the FAQ: Are Commercial DBMS Truly Relational?
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