例如，我有一个存储类的表和一个存储类属性的表。 class_attributes 有一个 class_attribute_id 和一个 class_id，而 classes 有一个 class_id。
我猜如果一个数据集是“一个单独的孩子”或“单独属于”或“单独拥有”，那么我需要一个 FK 来识别父级。如果没有 class_attributes 表中的 class_id，我永远无法找出该属性属于哪个类。
也许有一个有用的答案矩阵？
【问题讨论】：
标签： database database-design normalization database-normalization
【讨论】：
不要关心关系的类型——它更多地与关系的基数有关。
如果您有一对多的关系，那么您希望将主键分配给较小的表，并将其作为外键存储在较大的表中。
你也可以在一对一的关系中这样做，但有些人认为你应该避免它们。
在多对多关系的情况下，您需要创建一个连接表，然后让每个原始表都有一个连接表的外键。
【讨论】：
我会说，情况正好相反。首先，你设计你需要什么样的对象。对于那些将创建一个表。
此阶段的一部分是设计键，即唯一标识对象的属性（列）组合。出于方便或性能原因，您可能会也可能不会添加人工密钥或代理密钥。从这些键中，您通常会选择一个规范键，即主键，您尝试一致地使用它来识别该表中的对象（您也保留其他键，它们用于确保作为业务规则的唯一性，而不是用于识别目的。）
然后，您认为对象之间存在哪些关系。由另一个对象“拥有”的对象或引用另一个对象的对象需要某种方式来标识其相关对象。在相应的表（子表）中添加列以使外键指向被引用表的主键。
这会处理所有一对多关系。
有时，一个对象可以与另一个对象多次关联。例如，一个订单可用于订购多个产品，但一个产品也可以出现在多个订单上。对于这些关系，您需要设计一个单独的表（交叉表 - 在本例中为 order_items）。该表将具有从两个外键创建的唯一键：一个指向一个父级（订单），一个指向另一个父级（产品）。再次，您将列添加到创建这些外键所需的交集表中。
简而言之，您首先设计键和外键，然后才开始添加列来实现它们。
【讨论】：