Now as you can imagine, 6th Normal Form can lead to table proliferation.

Absence of a record for a given key indicates non-existence. Where id is a foreign key and value captures that attribute (e.g. This involves creating a table specific to the attribute: create table attributeName ( Two ways of accomplishing this, 6th Normal Form (6NF) or an Entity Attribute Value (EAV) model. In that case, you would simply make the bank account number nullable in the table.īased on your question and subsequent comments on answer my understanding is you want a solution for storing optional attributes, of which there are many, while avoiding NULLs. In other words, a classic 1:0/1 case as you put it. Now the bank account of someone is dependent entirely on the chosen key but not everyone may possess one (they may be paid in cash). In those cases, I would simply keep the attributes in the main table and make them nullable to indicate whether or not they're appropriate for the row.īy way of (contrived) example, you may have a SocialSecurityNumber attribute as your primary key (I won't go into the arguments as to whether this is a good idea here or whether you should use a surrogate key since it's irrelevant to the question).įurther assume that you have a distinct BankAccount attribute for paying their wage into, and that you're not one of those nice employers that can distribute a wage to multiple bank accounts for the purpose of dodging taxes :-) If you have an attribute which is either there or not there, that attribute itself may still follow the rules. Third normal form basically means that an attribute (or column) depends on the key, the whole key and nothing but the key (so help me, Codd).

Dbschema one to one relationship