彻底理解数据库ER建模中的扇子陷阱与裂口陷阱：追根到底

写在最前

在课堂上，我们学习了扇子陷阱与裂口陷阱这两类建模陷阱。显然，“扇子”和“裂口”都是很形象的比方，关于这两类陷阱，我初学时有一些困惑。

如果你正在为这两类陷阱困扰，那么请看这篇文章，这篇文章会帮你彻底理解它们。如果你从没有听说过这两类陷阱，但有一些ER建模的经历，那么静下心来，这篇文章会从0开始，教会你。

关于两类陷阱的困惑

• 这两类陷阱具体是什么？
• 两类建模陷阱之间是否存在联系？
• 两类建模陷阱在什么情况下会出现？
• 如何避免这两类建模陷阱？

如果你也有这些困惑，或者你想弄清楚这是什么，请往下读。

什么是扇子陷阱

下图所示，即为一个典型的扇子陷阱。

你可能会有疑问，这不就是一个简单的ER模型（CDM）吗，“陷阱”从何谈起？

我们先来分析一下这个ER模型具体在表示什么场景。如果给你这三个实体，分别是部门、员工、项目，你会怎么建模？显然，一个部门有多个员工、多个项目，这就是两个一对多关系，因此你大概率会像上图一样建立ER模型。问题在于，你忽略了员工和项目的关系。

你可能会想，部门与员工、项目都有关系，那么能否在上图所示的ER模型中，经由“部门”这一实体，复原出员工和项目的关系呢？这就是扇子陷阱的本质所在了。如果你想要找到一名员工参加的项目，那么你可以通过部门与员工之间的关系，找到该员工所在的部门，下一步，再通过部门与项目的关系，找到的却不是预期的“员工所参加的项目”，而是“员工所在部门的所有项目”！仔细体会，这二者显然是不同的。

同样地，如果寻找一个项目的所有参与者，也会出现这一问题。

言外之意，看似正确的建模方式，所表示的关系可能是不完整的。这就是“陷阱”的含义。

什么是裂口陷阱

下图既是一个典型的裂口陷阱。

有了前面的基础，我们直接来分析，这样一个ER模型是否忽略了它不应该忽略的一些关系。该模型表示的是，一个部门有多个项目，一个项目有多个员工，感觉还是挺完美的。那么问题是，你能找到指定员工的所在部门吗？

你可能会想，先找到该员工参加的项目，再根据该项目找到部门，岂不是很完美吗？但问题在于，你找到的不是“该员工的所在部门”，而是“该员工参加的项目的所在部门”。在不能保证二者一定一致的情况下这样设计数据库，无疑会留下隐患。此外，如果某一员工没有参加任何项目，这在ER模型中是被允许的，那么就永远也找不到该员工和部门的联系了，感觉上像是关系传递着就中断了。这就是裂口陷阱。

同样地，如果需要寻找某一部门的所有员工，也会出现这一问题。

看似正确的建模方式，所表示的关系可能是不完整的，在这里又体现了一次。

扇子陷阱与裂口陷阱的联系

在本质上，这两类陷阱都是在“试图由正确的若干个关系传递得到直接关系”。具体地：

• 扇子陷阱：多对一 → 一对多
• 裂口陷阱：一对多 → 一对多

扇子陷阱与裂口陷阱的正确性

我们已经弄清楚了两类陷阱的本质都是“试图由正确的若干个关系传递得到直接关系”，但这样的话结果一定错误吗？

• 扇子陷阱试图基于外键与外键进行“自然联结”，因此一定是错误的、不安全的。
• 裂口陷阱比较特殊，这是因为，在大多数情况下，它不会出现任何问题。对于公司、部门、员工表，一个公司对应多个部门、一个部门对应多个员工，则正确。对于部门、项目、员工表，如果规定员工只能参加所在部门的项目，那么也正确。但警惕这一类陷阱的原因在于，即便它只会在1%的情况下出现，我们也要100%重视。

写在最后

这两类陷阱给我们的启发在于，在建立ER模型时，一定要注意检查这种传递后的关系的正确性。“多对一 → 一对多”一定是错误的、“一对多 → 一对多”可能是错误的，这为我们建立正确的ER模型提供了更为完备的理论基础。知道在哪儿更容易出现问题，我们就更有可能避开它们。

如果这篇文章对你有帮助，请点赞鼓励一下吧！