Re: A Normalization Question

Neo wrote:

> No, the above is an example of carrying out the wrong steps to achieve
> the desired goal.

ANY anomalies can be prevented by always carrying out the right steps to achieve the desired goal. For example, take the following table which is in 2NF but not 3NF:

create table person (
  id numeric(5) not null,
  birthdate date not null,
  age int not null,
  primary key (id)
)

And the tuple (123, '1/1/1980', 24)

This is not in 3NF because of the transitive dependency birthdate --> age. An update anomaly will occur if one is updated without a corresponding update to the other. But it is true that by always carrying out the 'right' steps to achieve the goal, you avoid an update anomaly.

IE, the fact that you CAN work around anomalies is unrelated to the existence of those anomalies.

> In your example above, you are not demonstrating
> that the string 'brown' is not redundant.

Of course not. As I and everybody else have repeated ad nauseam, the physical duplication of a string in an unrelated fact is unimportant in a logical model. And to head off the other assertion you constantly and incorrectly make, I'm not refering to any specific logical model, like the relational model, here.

And even if it did matter, as we've also said, tokenizing strings does nothing to remove the duplication.

> You are demonstrating an
> incorrect method of renaming somethings that are named by the same
> string initially.
>
> Suppose we have:
> X isa person.
> Y isa color.
> Z isa street.
> 'brown' isa string.
> Let X, Y, Z be named by the same string 'brown'.
>
> If we desire to only rename person X to 'browne', the process is to
> see if 'browne' already exists, if not, create 'browne', then unrelate
> X from 'brown' and re-relate to 'browne'. (XDb1 does this when user
> edits the person named 'brown')

You're describing a system where you have potential update anomalies, and software that requires extra logic, code and overhead to work around them as though they were a good thing.

Larry Coon
University of California Received on Tue Jul 13 2004 - 20:23:28 CEST