Question

I have just read @PerformanceDBA’s arguments re: 6NF and E-A-V. I am intrigued. I had previously been skeptical of 6NF as it was presented as “merely” sticking some timestamp columns on tables.

I have always worked with a data dictionary and do not need to be convinced to use one, or to generate SQL code. So I expect an answer that would require a dictionary (or catalog) that is used to generate code.

So I would like to know how 6NF would deal with an extremely simple example. A table of items, descriptions and prices. The prices change over time.

So anyway, what does the Items table look like when converted to 6NF? What is the “explosion of tables?” that happens here?

If the example does not work with a table this simple, feel free to add what is necessary to get the point across.

Answer 1

In a nutshell, 6NF means that every relation consists of a candidate key plus no more than one other (key or non-key) attribute. To take up your example, if an “item” is identified by a ProductCode and the other attributes are Description and Price then a 6NF schema would consist of two relations (* denotes the key in each):

ItemDesc {ProductCode*, Description}
ItemPrice {ProductCode*, Price}

This is potentially a very flexible approach because it minimises the dependencies. That’s also its main disadvantage however, especially in a SQL database. SQL makes it hard or impossible to enforce many multi-table constraints. Using the above schema, in most cases it will not be possible to enforce a business rule that every product must always have a description AND a price. Similarly, you may not be able to enforce some compound keys that ought to apply (because their attributes could be split over multiple tables).

So in considering 6NF you have to weigh up which dependencies and integrity rules are important to you. In many cases you may find it more practical and useful to stick to 5NF and normalize no further than that.