Database normalization: Table design smells

Question

The way a part of my database is designed I have three tables:

Partners

• PartnerId

XYZPrograms

• XYZProgramId

PartnerXYZPrograms

• PartnerId
• XYZProgramId

Each Partner can have zero or one XYZProgram. The PartnerXYZPrograms table relates the partner with a XYZProgram. So I have the following relationships/constraints in PartnerXYZPrograms table:

PartnerId and XYZProgramId are foreign keys; PartnerId is unique and also the XYZProgramId is unique.

Now this seems to smell. I am getting back to DB design after 6 years so I can't immediately say what rule of normalization this is breaking but I suspect it is breaking something. PartnerXYZPrograms table is most likely redundant and XYZPrograms table should probably contain the PartnerId.

So my question is what are the smells when designing tables that suggest database normalization is likely screwed up.

Answer 1

The easiest way to spot these smells is to visualize how the dataset will look when active. The obvious and most fundamental smells that relate to normalization:

• A table has the same redundant data in a column, the values of which are not keys (or part of a composite key) to another table. This one should set off an alarm bell. If you have an entity called Job Listing and one of the columns "Category" contains values like "Management", "Management", "Engineering", "Management", this should immediately tell you that there is an additional concept worth representing.

  • A table has redundant data in a column that is sometimes populated similar to the previous smell and sometimes null. This seems a bit like the one above, but there is a distinction. This means that there is a separate idea that needs to be represented, but it is part of a composition relationship. Ex. Employee entity called ManagerInfoID that has a key to a record in the manager table with some info. It is null for all non managers. (I've seen this one more often than I would have liked.

  • Another possible smell is a Merge Table that just doesn't look right. More often than not, people gravitate a link or merge table (like ManagerEmployee) by default. While this is in fact an optimal solution to dealing with many to many relationships, sometimes complicated relationships like the one you noted above have characteristics that just don't seem right in a merge table. The better (perhaps?) solution is to model the zero to many or one to many relationship similar to what you have mentioned above (by putting the PartnerId in the XYZPrograms table).

In my honest opinion, I think that forgetting normalization rules and sticking to smells is a really good thing. It prevents things like #3 from happening, where a chaotic struggle to conjure up rules from a class you barely remember years ago usually results in a theory/practice mismatch and has you applying principles wrong.

The good thing about relational databases is that your data looks really ugly when you see it if it hasn't been modeled properly. This is something that comes from getting bit by de-normalized databases (or worse having to clean up the aftermath).

What other smells can you think of?