关系型数据库中的关系是如何建立起来的？

在之前的文章中《五分钟迅速了解关系型数据库》，我为大家简单地介绍了关系型数据库，本篇内容将重点讨论数据库中各表之间的关系。

1.实体和属性

数据库是由实体（也叫做表）组成的，例如“SKU”、“供应商”和“采购订单”是实体。

每个表里有一些属性，例如“件号”、“供应商编号”等是属性。假设我们有3个实体，其中各有一些属性，如下图。

图 实体和属性

我简略地解释一下其中的主要内容。在“SKU”表里存储的是每个最小的库存单位（Stock Keeping Unit，缩写SKU）的关键信息，SKU有一个唯一的号码，也就是件号，这就像是人的身份证一样，是一一对应的，一般来说，1个SKU不会有2个件号。假设SKU是从外部采购的，因此需要供应商的信息。

某个SKU可能存在多个供应商同时供货的情况，“SKU”表中的“配额”属性定义了每个供应商的采购比例。如果SKU是独家供应的，配额当然是100%，如果有超过1个的供应商可供货，我们需要根据采购制定的策略进行分配，累计数量必须是100%。

供应商表中的属性有供应商编号，一家供应商可能提供多个SKU，所以需要一个序号，另外还有件号和对应的价格。

在采购订单表中，重要的属性包括了订单号、行号、件号、供应商编号和名称、价格、数量和到货日期等。

在这3个实体中，我们发现有一些重复出现的属性，例如件号、供应商编号和名称，这说明实体之间应该是有一些关系的，我们需要一种工具把这种关系描述出来，它就是实体关系图（Entity Relationship Diagram, 缩写ERD）。

2.实体关系图

实体关系图是数据库的一个示意图，描述了所有不同的实体或表，以及它们之间的关系。在ERD中，实体被画成了一个个盒子，它们之间用线条连接，表示实体之间是有关系的。

在数据库的语言中，使用基数（Cardinality）这个词描述了两个实体和关系之间相关发生的预期数量，这个概念很抽象，我就不详细介绍了。我们可以简单地把关系理解为三种情况，分别是：

一对一：

例如一个人只有一个身份证号码，一个SKU只对应一个件号。

一对多：

一个供应商可以对应多个采购订单，相反地，一个采购订单只能对应一个供应商，我们不能在同一个采购订单里出现2家以上的供应商，这可能会泄露商业机密。即使这些供应商之间没有直接竞争关系，但我们还是要有所顾虑，避免不必要的麻烦，所以它们是一对多的关系。

多对多：

一个采购订单里可以有多个SKU，就像是我们去大型超市一样，通常会采购多项的商品，很容易理解。反过来，一个SKU可以出现在多个采购订单里，以前买过了，现在来复购，这是很正常的，所以它们是多对多的关系。

如何用简单的方式来描绘出以上3种的关系呢？可以使用鸦爪图（Crow's foot notation），它看上去有点像乌鸦的爪子，因此得名。

3.鸦爪图

以“供应商”和“采购订单”为例，让我们看一下它们的ERD是什么样子的。

图 供应商”和“采购订单”关系和鸦爪图

在上图中，“供应商”和“采购订单”实体之间被一条线连接在一起，这代表它们是有关系的。

图 放大后的线条

在线条的左侧是两条垂直的短线，它的意思是关系是“1个，且仅有1个”。在右侧的符号是一个圈，外加了3条短线，它代表“0或多个”。

这种关系是含义是什么呢？一家供应商可以有多个采购订单，只要不是一锤子的买卖，客户很可能是会重复购买的。为什么会有0个订单的情况？可能供应商刚刚被加入到备选清单中，还没来得及下订单，或者是供应商出了产品质量问题，采购被通知暂停购买，这些都是有可能出现的情况，所以这个关系是“0或多个”。为什么一个采购订单对应的供应商数量是“1个，且仅有1个”？首先，一张订单不能出现多个供应商，原因之前已经解释过了。其次，仅有1个的意思是它不能是0个，这样说有点拗口，我们换个角度来理解一下这句话的含义。当采购员在做订单时，他必须把订单发给某一个供应商，这就是“1”的关系，他如果选择了“0”，意味着不知道供应商是谁，这样的订单是无效的，采购东西的时候至少要知道该向谁买吧，所以是采购订单对应供应商的数量是1，且仅是1。

再来举一个例子，来看一下“SKU”和“供应商”实体之间的关系，如下图。

图 “SKU”和“供应商”关系和鸦爪图

两个实体之间被一条线连接在一起，这代表它们是有关系的。

图 放大后的线条

右侧的图形表示“0或多个”，刚才已经介绍过了。左侧的图形是一个圈加上一条竖线，代表是“0或1个”。1个SKU可能有多个供应商能够供货，除非是垄断的资源或是技术，许多供应商都可以制造出类似的产品。

如果某个特殊的SKU在市场上找不到货源，那么供应商数量为零，这也是可能的，例如有些年代久远的产品配件在市场上难觅踪迹。因此，SKU与供应商数量的关系是 “0或多个”。

反过来看，1个供应商理论上只有对应1个SKU，因为后者是最小库存单位，即便是同样的产品，更换了外包装或是包装数量，它就是另一个SKU了。供应商也没有理由去对应多个一模一样的SKU。

当然，供应商可以在现阶段不提供任何的产品或服务，但是以后说不准会有购买行为，所以关系会是“0“。这就是SKU这边是“0或1个”的原因。

图 鸦爪图中的4种基数

4.业务规则

数据库中实体之间的关系，加上这些关系中的基数（一对一、一对多、多对多）构成了业务规则的基础。

我们只需要看ERD，就能理解业务的规则，例如1个供应商对应着0或多个采购订单，如果更改了关系和基数，意味着业务规则也变动了。

假设采购有新的规定，供应商这边至少要有1个SKU在供货，否则就要从采购名单中撤下来，不能在数据库中出现，那么供应商对着SKU的关系就变成了1个，不能再出现0了。

再比如说，采购认为那些找不到供应渠道的SKU必须从数据库中拿掉，那么SKU对应供应商的关系成为了“1或多个“。

现在我们可以理解了，一个数据模型可能会有多个解决方案，用于描述不同的基础业务流程或规则。企业的实际业务需求和流程决定了数据库的业务规则。

当我们看到一个实体关系图，或者一个数据模型，通过实体或表之间的关系和基数，就可以理解业务流程和规则。

---