我将使用金融部门的一个简单示例来说明问题。具体来说，是一张描述金融工具的表格（仅股票，期货和期权）。
我将简化表格以使示例尽可能小和容易（即不现实）。
''Table v1.0'列：名称，术语，类型。
'名称'将是股票，期货或期权之一。
'term'是日期。对于股票而言，始终为Null，因为它实际上仅适用于其他两个股票。
'type'是看跌期权或看涨期权，其他则为Null。
请注意，“名称”不是候选关键字（用于股票，而不用于期货和期权）。 '期限'取决于'名称'（股票为空），'类型'取决于'名称'和'期限'（因为它仅适用于期权）。
据我所知，这绝对不是3rdN。
'表v2.0'列：名称，术语。
'名称'将是股票，期货，看涨期权或看跌期权之一。
'term'与1.0中的相同。
这是尊重1stN的原因，因为我缩短了'Call Option'和'Put Option'，而在'term'上仍然存在3rdN问题。
显然，这些工具的规格不兼容，我应该为它们中的每一个都有一张表（即使库存中只有1个条目）。这将很烦人，因为其他表将使用该表中的行ID作为外键来链接有关交易的信息。如果我分成3个表，则我需要第4个表才能检测出要访问链接交易和工具的3个表中的哪一个。
坚持设计1.0是否会很糟糕（考虑到该表的数据正确性在插入之前已经得到保证）？在这种情况下，是否有一种避免使用每种仪器都有表格的模式？
规范化不专门处理NULL。但是SQL确实如此。它的NATURAL JOIN，=＆其他运算符不是与关系理论或算术同名的运算符。它对其他术语的使用也有所不同，例如PK（主键）和UNIQUE。当一个SQL表的所有CKs（候选关键字）的列都可以为空时，它可能是可分解的-可通过组件的自然连接来重构–但是在SQL中，这意味着INNER JOIN可以将共享列=或NULL与ON进行重组。同样，PK和UNIQUE约束以一种通常无法强制执行CK，超键或唯一性的方式特别对待NULL。对于FK（外键）和参照完整性也是如此。
您正在使用术语，但是您不清楚它们的含义，而且似乎没有正确应用它们。如果您通过所有步骤来通过引用定义来证明您对FD（功能依赖项），CK和NF（标准形式）的主张的合理性，您可能会看到这一点。例如，您说“依赖于”，但它在规范化意义上不是“在功能上依赖于”。
What to do with null values when modeling and normalizing?Does an empty SQL table have a superkey? Does every SQL table?"1NF" has no single meaning.
理想情况下，设计时不使用空值，然后通过LEFT JOIN组合无空CK上的表以引入空值。
信息建模方法往往会产生没有此类空问题的设计。现在该关注出版的有关信息建模，关系模型以及数据库设计和查询的学术教科书了。
无论如何，您具体都有子类型化的情况。这种一般概念的案例称为子类型化，继承和多态。有数据库的成语。当然，它们涉及适当的明智表，CK，非CK可为空的列以及通过LEFT JOIN重建超类型表。
How can you represent inheritance in a database?How do you effectively model inheritance in a database?
您可能不适当地使用了EAV（实体-属性-值）设计。这是代表子类型化的常见反模式。例如，您在这里说一个表“将只有1个条目”，这表明它实际上是元数据，并且由于已经声明了适当的表和约束，因此可能属于DBMS管理的元数据。 （但是您没有为我们提供有关应用程序或设计的足够详细的信息。）