Re: Normalization by Composing, not just Decomposing

Dawn,

You can go the other way. Let's just agree not to call it normalization.

Let's say your start from a body of data items. I don't care whether these items are pulled off a report, or a screen, or out of data files or whatever. Let's say you've decided to group the items into columns, and the columns into tables, and the tables into a schema.

Let me skip over the question of whether to put two data items in the same column or not. It's an important question, and in the real world, it should be addressed before the question of whether two columns belong in the same table.

But let's say we have composed the data items into useful columns.

Now, when we ask, "shall we join these columns together", we can really look at it three ways:

The two columns are unrelated. Putting the two columns in the same table will put two items next to each other that have no relationship to each other. Leave them apart.

Go ahead and put them together in the base tables. In other words, "materialize the join".

The third choice is, use the foreign key mechanism to mark the relationship, but leave the columns in separate tables. Anyone who knows the foreign keys, and what they represent, and knows how to do an equijoin can paste them together whenever necessary.

Which of these three choices is better?

Well, when you decide on composition, you can use normal forms and knowledge of the FD's to determine what normal form the materialized join will be in, and you can use that knowledge, along with other knowledge, to decide whether the composition buys you more than it costs you.

There's more than one way to skin a cat, but some ways are better than others. Received on Tue Apr 13 2004 - 14:48:22 CEST