这种数据库设计模式叫什么？

Question

外键一般有以下形式：

A <━━ X

（表示X引用A，一对多关系）

但是现在，有一个新东西也可以有一个 X。

一个 nieve 表示可能看起来像这样：

A <━┳━ X
B <━┛ 

在这种情况下，X 将有两个外键，其中一个为空。我个人讨厌空值（每个人都应该如此？），所以这对我来说是不可接受的。

下一个最好的东西可能看起来像这样：

       X
       ^
       ┣━━━━━━┓
       ┃      ┃
       ┃????    ┃
A <━━ AX      ┃
              ┃????
B <━━━━━━━━━ BX

因此在这种情况下，AX 和 BX 是两个关联表（IMO 应该通过键引用 X，以使它们与 X 具有一对一的关系，以帮助实施与以前相同的约束）

虽然这很好用，但当我添加也有 X 的表 C 和 D 时，它变得过于复杂。

所以我想出的下一个模型看起来像这样：

hX <━━ X
 ^
 ┃
 ┣━━━━━┳━━━━━┓
 ┃     ┃     ┃
 ┃????    ┃????   ┃????
 A      B    C

所以我真的很喜欢这个模型，但我真的不知道该怎么称呼它。这是标准模式吗？是否有另一种更好的模式来解决这个问题？我可以在哪里阅读更多关于此类内容的信息？

如果不是标准模式，我应该如何称呼“hX”表？关联表通常只是将两个表名连接在一起，但在这种情况下它不是关联表，部分原因是有 3 个不同的引用。

我可以称它为“CanHaveX”，但这有点啰嗦

“XAnchor”似乎有点接近，但我真正想要的是“XAnchorPoint”？

我个人喜欢“XCleat”（因为人们将cleat 放在他们想让其他东西留在它上面的东西上），因为这允许表 A 有一个 X 引用它，但这个术语有点奇怪.

Answer 1

TL;DR您没有说明为什么 FK（外键）保持不变，但 A、B 和 C 值/实体类型似乎是 hX 的子类型。谷歌 SQL/数据库子类型/继承/多态。多个可为空的 FK 是一种常见的反模式，通常也被描述为多个表的 FK [原文如此]。它的一个名称是Class Table Inheritance。另一方面，我们可以定义这样一种子类型每当一个 FK 持有，所以在业务/应用程序术语中不一定有任何重要的事情发生，仅仅因为你看到一棵树FK。目前尚不清楚您认为“过于复杂”的理由是什么。表格代表 n 元业务/应用程序关系（船舶）/关联，在您的情况下，某些值/实体是 As、Bs 和/或 Cs，并且每个 X 都与其他值/实体相关。

---

这个答案的其余部分解释了如何从像原始反模式这样的设计转变为具有可为空 FK 的设计，而不是一般情况下的设计。

SQL FK（外键）是一组列，其中非空子行值在其他地方显示为 PK/UNIQUE。每个 FK 都应该声明或遵循声明的 FK 和其他约束。 （通常未声明的 FK 通过传递性跟随已声明的 FK。）

如果您不想要包含可为空列的表，那么您需要多个表。这与您的 FK 是正交的。一个表就像原始表一样，删除了列，保留了原始表在所有其他列上的投影。其他表有一些原始表 CK（候选键）列以及一些您不希望为空的列，保留原始列不为空的子行。请注意，第二个中的 CK 是引用第一个 CK 的 FK。并且那个 CK FK 在原始表中不是可以为空的。

约束遵循表含义以及可能出现的业务/应用情况。碰巧两个具有相同 CK 值的表可以被它们的连接替换，反之亦然。此外，如果第一个具有第二个 CK 值的超集，那么您可以用它们的左连接替换它们，反之亦然。这恰好发生在从第二个到第一个的 CK 上有一个 FK 时。这与上面的空消除相反。它与第二个获得空值的列本身是否是 FK 无关。当我们应该或不应该或可以或不能使用多个表时，它们的连接是标准化到更高 NFs（正常形式）的主题。

没有通过专门消除可为空的 FK 强加的任何特定设计模式。只需使用适当的信息建模和数据库设计原则，包括规范化，包括识别相关约束，即可找到记录您想要的表/含义。然后确定进一步的约束。然后写声明。

What to do with null values when modeling and normalizing?
What is the difference between an entity relationship model and a relational model?