Database 当字段依赖于非候选键，但使用建议不拆分表时，重新规范化

我将用一个来自金融部门的简单例子来说明这个问题。具体而言，该表仅描述了股票、期货和期权等金融工具

我将简化表格，使示例尽可能小和简单，即它不现实

“Table v1.0”列：名称、术语、类型

“名称”是指股票、期货或期权

“期限”是一个日期。这对于股票总是空的，因为它实际上只适用于其他两种股票

“类型”是期权的卖出或买入，其他为空

请注意，“名称”不是一个候选关键字，它将用于股票，但不用于期货和期权术语“取决于”名称“股票为空，'类型”取决于“名称”和“术语”，因为它仅适用于期权

据我所知，这绝对不是3rdN

“表v2.0”列：名称、术语

“名称”可以是股票、期货、买入或卖出

“术语”与1.0中的相同

这尊重1stN，只是因为我缩短了“看涨期权”和“看跌期权”，并且在“期限”上仍然存在3rdN问题

显然，这些仪器的规格是不兼容的，我应该为每个仪器都准备一个表格，即使库存的仪器只有一个条目。这会很烦人，因为其他表会使用此表中的行id作为外键来链接有关（例如）交易的信息。如果我分成3个表，我需要第4个表来检测3个表中的哪一个可以访问链接交易和工具

---

考虑到在插入之前已经保证了该表的数据正确性，坚持使用design 1.0会有那么糟糕吗？在这些情况下，是否有一种模式可以避免为每种仪器设置一个表格？

规范化并不专门处理NULL。但SQL确实如此。它的自然连接、=&和其他运算符不是与关系理论或算术同名的运算符。另外，它对其他术语的使用也不同，比如PK主键和UNIQUE。当一个SQL表的所有CKs候选键都具有可为NULL的列时，它可以通过来自组件的自然连接进行分解和重构，但在SQL中，这意味着通过内部连接进行重组，其中一个ON涉及的共享列为=或NULL。另外，PK&UNIQUE约束以一种无法强制执行正常意义上的CKs、superkey或惟一性的方式专门处理null。与FKs外键和引用完整性类似

您正在使用术语，但不清楚它们的含义&似乎没有正确地应用它们。如果您通过引用定义完成所有步骤来证明您关于FDs功能依赖项、CKs和NFs标准表单的声明，您可能会看到这一点。你说依赖于，但它不是在规范化的意义上，它在功能上依赖于

理想情况下，不使用空值进行设计，然后通过左连接在无空CKs上组合表以引入空值

信息建模方法倾向于产生不存在这种零问题的设计。是时候学习已出版的关于信息建模、关系模型和数据库设计与查询的学术教科书了

无论如何，你特别有一个子类型的例子。这种普遍概念的例子被称为子类型、继承和多态性。这方面有很多数据库习惯用法。当然，它们涉及适当的明智的表、CK、不可CK为null的列以及通过左连接重构超类型表

您可能不恰当地使用了EAV实体属性值设计。这是表示子类型的常见反模式。例如，您说一个表在这里只有一个条目，这表明它实际上是元数据&由于声明了适当的表和约束，它很可能属于DBMS管理的元数据。但您没有提供足够的详细信息，让我们了解您的应用程序或设计

---

回答得很好，坦斯克。该表只是一组元数据，有效地表示了“个人全名”，但在其组件中进行拆分非常有用，因为有时我会对这些内容进行筛选。没有继承，只是他们的字段有点像是匹配的。如果我按照继承链接进行拆分，我主要关心的是“方便性”，因为其他表的条目可以是“股票”、“未来”或“期权”，因此如果我想要“全名”，我可能必须将3行子集中的每一行都连接到不同的表中，这些链接的继承只是子类型，就像在你的乐器子类型中一样。但我真的不知道它们如何适合您的应用程序/设计。您称之为元数据，但我怀疑它实际上只是数据：元数据是独立于当前内容和应用程序的表的正确数据；颜色是汽车的一种属性/属性，可以用来暗示存在不同类型的汽车 ne每种颜色，但颜色仍然只是汽车数据，但当1:1与表格时，它就像元数据&逻辑上是冗余的。在下一篇文章中，可能会问你一些小的设计，只是你的类型的实体。