当字段依赖于非候选键时重新规范化，但使用建议不要拆分 table
Renormalizing when fields depend on non candidate keys but usage would suggest to not split the table
我将用金融领域的一个简单例子来说明这个问题。具体来说，描述金融工具（仅股票、期货和期权）的 table。
我将简化 table 以使示例尽可能小和简单（即不现实）。
'Table v1.0' 列：名称、术语、类型。
'name' 将是股票、期货或期权之一。
'term' 是一个日期。对于股票，这始终为 Null，因为它实际上仅适用于其他两个。
'type' 是看跌期权或看涨期权，其他期权为空。
请注意，'name' 不是候选键（它适用于股票，但不适用于期货和期权）。 'term' 取决于 'name'（股票为 Null），'type' 取决于 'name' 和 'term'（因为它仅适用于期权）。
据我所知，这绝对不是 3rdN。
'Table v2.0' 列：姓名，术语。
'name' 将是股票、期货、看涨期权或看跌期权之一。
'term' 与 1.0 相同。
这尊重 1stN 只是因为我缩短了 'Call Option' 和 'Put Option'，并且在 'term' 上仍然有 3rdN 问题。
显然这些仪器的规格不兼容，我应该为每个仪器准备一个 table（即使库存仪器只有 1 个条目）。这会很烦人，因为其他 table 会使用来自此 table 的行 ID 作为外键 link 关于交易的信息。如果我分成 3 tables，我需要第 4 个来检测 3 个中的哪一个可以访问 link 交易和工具。
坚持使用设计 1.0 会不会很糟糕（考虑到此 table 的数据正确性在插入之前已经得到保证）？在这些情况下是否有一种模式可以避免为每种乐器设置 table？
规范化不会特殊对待 NULL。但是 SQL 确实如此。它的NATURAL JOIN、=&等运算符不是关系论或算术中的同名运算符。它对其他术语的使用也不同，例如 PK（主键）和 UNIQUE。当 SQL table 具有所有带有可为空列的 CK（候选键）时，它可能是可分解的——通过组件的自然连接重新构造 table——但在 SQL 中表示通过 INNER JOIN 与涉及共享列为 = 或 NULL 的 ON 重新组合。此外，PK 和 UNIQUE 约束以一种无法在正常意义上强制执行 CK、超级键或唯一性的方式特殊处理 NULL。 FK（外键）和参照完整性也是如此。
您正在使用术语，但您不清楚它们的含义并且似乎没有正确应用它们。如果您通过所有步骤通过引用定义来证明您关于 FD（函数依赖）、CK 和 NF（范式）的声明，您可能会看到这一点。例如，您说 "depends on" 但它不在 "is functionally dependent on".
的规范化相关意义上
What to do with null values when modeling and normalizing?
Does an empty SQL table have a superkey? Does every SQL table?
理想情况下，设计没有空值，然后通过 LEFT JOIN 在无空值的 CK 上组合 table 以引入空值。
信息建模方法倾向于生成没有此类空问题的设计。是时候学习一本已出版的关于信息建模、关系模型和数据库设计与查询的学术教科书了。
不管怎样，你有一个子类型化的例子。这种一般概念的情况被称为子类型化、继承和多态性。有一些数据库习惯用法。当然，它们涉及适当的明智 tables、CK、非 CK 可空列和通过 LEFT JOIN 重建超类型 table。
How can you represent inheritance in a database?
How do you effectively model inheritance in a database?
您可能不恰当地使用了 EAV（实体属性值）设计。这是表示子类型的常见反模式。例如，您在这里说 table "would have only 1 entry"，这表明它实际上是元数据并且可能属于 DBMS 管理的元数据，因为已经声明了适当的 tables 和约束。 （但是您没有提供足够的详细信息来让我们了解您的应用程序或设计。）
Designing an EAV database correctly for historical data
我将用金融领域的一个简单例子来说明这个问题。具体来说，描述金融工具（仅股票、期货和期权）的 table。
我将简化 table 以使示例尽可能小和简单（即不现实）。
'Table v1.0' 列：名称、术语、类型。
'name' 将是股票、期货或期权之一。
'term' 是一个日期。对于股票，这始终为 Null，因为它实际上仅适用于其他两个。
'type' 是看跌期权或看涨期权，其他期权为空。
请注意，'name' 不是候选键（它适用于股票，但不适用于期货和期权）。 'term' 取决于 'name'（股票为 Null），'type' 取决于 'name' 和 'term'（因为它仅适用于期权）。
据我所知，这绝对不是 3rdN。
'Table v2.0' 列：姓名，术语。
'name' 将是股票、期货、看涨期权或看跌期权之一。
'term' 与 1.0 相同。
这尊重 1stN 只是因为我缩短了 'Call Option' 和 'Put Option'，并且在 'term' 上仍然有 3rdN 问题。
显然这些仪器的规格不兼容，我应该为每个仪器准备一个 table（即使库存仪器只有 1 个条目）。这会很烦人，因为其他 table 会使用来自此 table 的行 ID 作为外键 link 关于交易的信息。如果我分成 3 tables，我需要第 4 个来检测 3 个中的哪一个可以访问 link 交易和工具。
坚持使用设计 1.0 会不会很糟糕（考虑到此 table 的数据正确性在插入之前已经得到保证）？在这些情况下是否有一种模式可以避免为每种乐器设置 table？
规范化不会特殊对待 NULL。但是 SQL 确实如此。它的NATURAL JOIN、=&等运算符不是关系论或算术中的同名运算符。它对其他术语的使用也不同，例如 PK（主键）和 UNIQUE。当 SQL table 具有所有带有可为空列的 CK（候选键）时，它可能是可分解的——通过组件的自然连接重新构造 table——但在 SQL 中表示通过 INNER JOIN 与涉及共享列为 = 或 NULL 的 ON 重新组合。此外，PK 和 UNIQUE 约束以一种无法在正常意义上强制执行 CK、超级键或唯一性的方式特殊处理 NULL。 FK（外键）和参照完整性也是如此。
您正在使用术语，但您不清楚它们的含义并且似乎没有正确应用它们。如果您通过所有步骤通过引用定义来证明您关于 FD（函数依赖）、CK 和 NF（范式）的声明，您可能会看到这一点。例如，您说 "depends on" 但它不在 "is functionally dependent on".
的规范化相关意义上What to do with null values when modeling and normalizing?
Does an empty SQL table have a superkey? Does every SQL table?
理想情况下，设计没有空值，然后通过 LEFT JOIN 在无空值的 CK 上组合 table 以引入空值。
信息建模方法倾向于生成没有此类空问题的设计。是时候学习一本已出版的关于信息建模、关系模型和数据库设计与查询的学术教科书了。
不管怎样，你有一个子类型化的例子。这种一般概念的情况被称为子类型化、继承和多态性。有一些数据库习惯用法。当然，它们涉及适当的明智 tables、CK、非 CK 可空列和通过 LEFT JOIN 重建超类型 table。
How can you represent inheritance in a database?
How do you effectively model inheritance in a database?
您可能不恰当地使用了 EAV（实体属性值）设计。这是表示子类型的常见反模式。例如，您在这里说 table "would have only 1 entry"，这表明它实际上是元数据并且可能属于 DBMS 管理的元数据，因为已经声明了适当的 tables 和约束。 （但是您没有提供足够的详细信息来让我们了解您的应用程序或设计。）
Designing an EAV database correctly for historical data