Discussion on:

Database normalization starts with the keys

I'm working on a project where there are a number of tables that can all relate to each other.
ie:
Table A
Table B
Table C
Table D

Table A can relate to Table B, C, or D
Table B can relate to Table C, D, E etc.

What would be an elegant way of handling this matrix?

Please elaborate. You say the tables can relate. Do you mean that the data among the tables needs to be related and that you need to store foreign keys, or what?

The example for first normal form meets the requirements for third normal form. Bad examples leads to confusion. A better example would a person table with child_1, child_2, child_3, child_4... (you get the drift). To solve the repeating group you need a table with person_id and child_id.

The employee table is in third normal form in the example? No, buiding name is dependent on building number, so the table is not in third normal form.

I agree, the first example with building number/building name is pretty much the same as example 3 with job ID/job name. It seems more of an example of column dependencies.

I like the dependent children example you offered for the first normal form. It seems much clearer to me. Thanks.

Overall, it was a good, interesting article, though.

Larry

I am sorry that the example confused you, but I assure you that is a valid example of making a table comply with the first normal form. Specifically, the table contains 3 column that hold building information. Moving the building information into a separate table will make the table comply with the first normal form. Your example is also valid (actually something like that was in an old college text of mine). If you would like to refer to this link, I think that you will see that I am correct.

http://support.microsoft.com/default.aspx?scid=KB;EN-US;q100139&

Believe had the steps in normalization been stressed a bit more with an example it would have become more clear.

Defining A as an entity and B as an entity and identifying the primary identification keys for each is clearly the first 2 steps. Pain must be taken to assure that other dependencies and repeating groups are in fact removed and as necessary, defined as yet another entity and its key.

When this is done you can start bolting all these logical relationships together using the mentioned connector entity and the AB primary keys for A and B.

Good article and sadly, another reason why this used to be several class days with this explanation, examples, and labs. Good job.

Yes, people are still reading this article. It is very well written. Thanks from a guy who has forgotten a lot.