也许您意识到了这一点,但这只是为了设置舞台:在关系数据库术语中,我们通常谈论的关系是 1:1、1:M 或 M:M。它们的工作方式存在根本差异。1:1 关系需要将外键发布到另一个表中的一个表。它可以在任一表中。1:M 需要在“多”表中发布一个指向外键的外键。AM:M 需要创建一个新表,关系表中的每条记录都有一个指向每个“主”表的指针。
所以:例如,如果您说我们的公寓大楼中每间套房总是正好有 4 个房间,我们可能会说这不是一般的 1:M 关系,而是更具体的 1:4。但就我们如何将数据存储在 RDB 中而言,我们将其存储为 1:M。每个“房间记录”都有一个指向“套房记录”的指针。就DB结构而言,仍然是1:M。我们可以在 DB 触发器或代码中添加约束以强制数字必须始终为 4,但这不会影响 DB 结构。
在 ERD 上,这种约束很重要,一些 DB 设计人员在附加到 DB 实体的“许多”符号旁边写下数字。如果必须正好是 4,就像写“4”一样。
请注意,强制执行确切的数字或最小值可能会很棘手。说在现实生活中每个人都有两个父母是一回事。将其作为我们数据库设计的要求是另一回事。这意味着我们不能添加“人”记录,除非我们同时添加他的父母。因此,要么数据输入屏幕必须包含有关此人及其父母的所有数据的字段,要么我们必须添加某种虚拟记录,直到我们开始填写父数据。在这个例子中,如果父母与人的记录类型相同——比如说,如果我们正在制作一个家谱数据库——那么我们不能在不添加父母的父母和父母的父母的父母的情况下添加父母,和...它会停在哪里?必须有一些规定可以说我们'
我应该承认,在某些情况下,如果不仅有特定数量的相关记录,而且它们在某些方面也不同,我们可能会为每个记录创建单独的指针。例如,与其说每个人有两个父母,即 M=2 的 1:M 关系,我们可以说每个人都有一个母亲和一个父亲,即两个 1:1 的关系。我个人很少这样做,因为它通常会使查询和索引变得更加困难。我们必须同时检查mother_id 和father_id,而不是通过查看parent_id 来获取双亲。如果我们想要索引一个,我们可能想要索引另一个。如果数字大于 2 或 3,因此查询必须检查许多指针字段,程序员很容易错过你,例如检查指针 1、2、3、5 和 6 但忘记包含 4 .
顺便说一句,诸如“房间数量必须等于所有者拥有的孩子数量”之类的约束条件很棘手。我猜这是一个你随便编造的例子,但当你设置特定数字时,这是一种很容易掉入的陷阱。也许在您的家庭中,每个孩子都有自己的卧室,但在许多家庭中,孩子必须共用一个房间。或者在另一个方向,许多家庭都有备用卧室供客人使用。我记得几年前在医疗保险系统上工作,他们为每个家庭建立了 8 个孩子的限制,因为有人想,谁会有超过 8 个孩子?但是当然也有超过 8 个孩子的家庭,当我们有一个时,系统就失效了。