It's been a long time since I studied relational design, but I had a vague memory that it encourages not splitting a table unnecessarily. For instance, given the functional dependencies
K -> A
K -> B
K -> C
my assumption was that the "best" schema is just {KABC}
and not something like {KAB, KC}
or even {KA, KB, KC}
. At least in practice that is how I've seen database designers implement the table.
However, a quick refresher on Wikipedia indicates that the normalization formalism
- doesn't make any statement in the direction of obtaining a "minimal schema",
- 6NF would even require
{KA, KB, KC}
. Since 6NF implies the other normal forms, it implies that it is even impossible for them to make such a minimal requirement.
I'm a bit confused that I got this wrong all the time. Does the notion of "obtaining a minimal number of tables" really play no role in formal relational design, and it is just common practice?
User
, there is no compelling reason from a design perspective to break it up intoUserAddress
,UserBirthday
,UserContactInformation
, etc. (from theoretical perspective of course, ignoring practical performance implications).User
'sBirthday
is relatively static; theirAddress
changes from time to time; theirContactInformation
might change relatively often. Furthermore in real business (as opposed to in textbooks) an organisation will want to keep a history of such changes.