Re: A Normalization Question

Neo wrote:

> Having duplicate/redundant 'brown' is a setup for update anomalies.
> Not having duplicate/redundant 'brown' is not.

Nope. Due to your continuing confusion of values with facts, it's exactly the opposite. Consider your "brown" example, with name, street, and color:

create table person (
  person_id numeric(5) not null,
  last_name varchar(30) not null,
  street varchar(30) not null,
  house_color varchar(10) not null,
  primary key (person_id)
)

And the tuple: (123, "brown", "brown", "brown")

Suppose Ms. Brown gets married and her last name is now "Smith." If you change the value representing the last name from brown to Smith, you have created no update anomaly. The facts that the street name is brown and the house color is brown were not inadvertently changed by this update.

But with your schema (which I won't bother to repeat, given that you've posted it ad infinitum), when you change brown to Smith, you've inadvertently changed all three facts represented by this tuple. That's an update anomaly.

The fact that you can work around the anomaly isn't the point. As I said and as you agreed, the fact that anomalies can be worked around is beside the point, since ANY anomaly can be avoided by careful coding. The point is, by combining separate and distinct facts into single values, you intruduce an additional potential for update anomalies which did not exist in the correctly normalized relational implementation.

Larry Coon
University of California Received on Mon Jul 19 2004 - 19:25:23 CEST