写在最前
在课堂上,我们学习了扇子陷阱与裂口陷阱这两类建模陷阱。显然,“扇子”和“裂口”都是很形象的比方,关于这两类陷阱,我初学时有一些困惑。
如果你正在为这两类陷阱困扰,那么请看这篇文章,这篇文章会帮你彻底理解它们。如果你从没有听说过这两类陷阱,但有一些ER建模的经历,那么静下心来,这篇文章会从0开始,教会你。
关于两类陷阱的困惑
- 这两类陷阱具体是什么?
- 两类建模陷阱之间是否存在联系?
- 两类建模陷阱在什么情况下会出现?
- 如何避免这两类建模陷阱?
如果你也有这些困惑,或者你想弄清楚这是什么,请往下读。
什么是扇子陷阱
下图所示,即为一个典型的扇子陷阱。
你可能会有疑问,这不就是一个简单的ER模型(CDM)吗,“陷阱”从何谈起?
我们先来分析一下这个ER模型具体在表示什么场景。如果给你这三个实体,分别是部门、员工、项目,你会怎么建模?显然,一个部门有多个员工、多个项目,这就是两个一对多关系,因此你大概率会像上图一样建立ER模型。问题在于,你忽略了员工和项目的关系。
你可能会想,部门与员工、项目都有关系,那么能否在上图所示的ER模型中,经由“部门”这一实体,复原出员工和项目的关系呢?这就是扇子陷阱的本质所在了。如果你想要找到一名员工参加的项目,那么你可以通过部门与员工之间的关系,找到该员工所在的部门,下一步,再通过部门与项目的关系,找到的却不是预期的“员工所参加的项目”,而是“员工所在部门的所有项目”!仔细体会,这二者显然是不同的。
同样地,如果寻找一个项目的所有参与者,也会出现这一问题。
言外之意,看似正确的建模方式,所表示的关系可能是不完整的。这就是“陷阱”的含义。
什么是裂口陷阱
下图既是一个典型的裂口陷阱。
有了前面的基础,我们直接来分析,这样一个ER模型是否忽略了它不应该忽略的一些关系。该模型表示的是,一个部门有多个项目,一个项目有多个员工,感觉还是挺完美的。那么问题是,你能找到指定员工的所在部门吗?
你可能会想,先找到该员工参加的项目,再根据该项目找到部门,岂不是很完美吗?但问题在于,你找到的不是“该员工的所在部门”,而是“该员工参加的项目的所在部门”。在不能保证二者一定一致的情况下这样设计数据库,无疑会留下隐患。此外,如果某一员工没有参加任何项目,这在ER模型中是被允许的,那么就永远也找不到该员工和部门的联系了,感觉上像是关系传递着就中断了。这就是裂口陷阱。
同样地,如果需要寻找某一部门的所有员工,也会出现这一问题。
看似正确的建模方式,所表示的关系可能是不完整的,在这里又体现了一次。
扇子陷阱与裂口陷阱的联系
在本质上,这两类陷阱都是在“试图由正确的若干个关系传递得到直接关系”。具体地:
- 扇子陷阱:多对一 → 一对多
- 裂口陷阱:一对多 → 一对多
扇子陷阱与裂口陷阱的正确性
我们已经弄清楚了两类陷阱的本质都是“试图由正确的若干个关系传递得到直接关系”,但这样的话结果一定错误吗?
- 扇子陷阱试图基于外键与外键进行“自然联结”,因此一定是错误的、不安全的。
- 裂口陷阱比较特殊,这是因为,在大多数情况下,它不会出现任何问题。对于公司、部门、员工表,一个公司对应多个部门、一个部门对应多个员工,则正确。对于部门、项目、员工表,如果规定员工只能参加所在部门的项目,那么也正确。但警惕这一类陷阱的原因在于,即便它只会在1%的情况下出现,我们也要100%重视。
写在最后
这两类陷阱给我们的启发在于,在建立ER模型时,一定要注意检查这种传递后的关系的正确性。“多对一 → 一对多”一定是错误的、“一对多 → 一对多”可能是错误的,这为我们建立正确的ER模型提供了更为完备的理论基础。知道在哪儿更容易出现问题,我们就更有可能避开它们。
如果这篇文章对你有帮助,请点赞鼓励一下吧!