很多分析师会以为数据关系很简单，其实这正是分析师成为高级分析师的难点。在数据库的世界中，每一个知识点都有相应的业务意义，分析师既要关注那些看得见的要素，更要关注那些往往看不见的要素。
本文从发货交付，简要介绍数据关系及其基数、引用完整性。
一、发货的基本业务流程
1、从业务流程到数据表关系
生产厂家的发货是建立在客户订单（customerOrder）基础之上的，也就是说，每一笔发货必须有相应的订单与之对应——这句话稍后将转化为关系表中的约束条件。
同时，发货一旦发出，自动就会创建财务单据与之对应，严格的说，任意一笔发货都必须有财务单据与之对应，从而确保货物流与财务流的一致性——这个对应关系稍后也将转化为数据表之间的约束条件。
上述两段话分别描述了发货与订单、发货与发票之间的对应关系，它们的关系会体现在三个数据表之间的关系上。
这就是最粗粒度的业务流程关系，及其倒影到数据世界的数据表关系。
2、业务关系细节
如果我们把上述的数据表关系告诉对业务不了解的技术顾问，对方一定会有很多问题，比如一个订单可以发几次？一次发票是否可以包含多次发货行？为了让数据表之间的关系尽可能细致地反映业务世界的关系，数据科学家设计了E-R关系模型和UML的符号语言。
比如，一个订单可以分为多次发货交付，可以用1：n表示订单和发货之间的关系；同理，多个发货行可以合并开票，可以用N：1 表示发货和发票之间的关系。为了更形象的表示彼此的关系，可以在数据表连接线两侧用“单竖线”表示1，而用八爪形状表示多。如下所示：
在数据库模型设计中，上述的一对多、多对一的关系称之为“基数“（granularity）。对于初学者而言，哪怕不知道这个专业术语，也可以借助于图示快速了解业务之间的关系。
不过，业务的奥秘不止如此，还有一个更隐含的侧面：关系是否是必然有对应的。
比如，一个订单刚刚创建之始，需要一定的时间才会有发货交付行为，因此，订单到发货的关系不是必然的。发货和发票则不然，只要有交货行为发生，就必须有发票与之对应（哪怕客户还没有申请开发票，也必须创建发票号并标记状态），因此，发货明细到开票明细的关系是必然的。
在数据库模型设计中，就必须预先考虑不同业务之间关系的这种必然和或然属性，并作为约束条件加以控制。在前面介绍嗲E_R关系模型中，可以额外增加两个标记表示：1代表必然、0代表非必然。如下所示：
在数据库模型设计中，这种必然、非必然关系称之为“引用完整性“（reference integrity），和基数构成了最重要的两个关系约束。它们通过“键（key）”之间的关系而起作用。
二、用关系快速了解业务
有了上述的工具，哪怕我们不去现场，就能快速了解业务的运行逻辑。
比如，下图左侧表示发票信息和拣货单的关系，它们的匹配关系可以解释如下：
- 任何一个发票行，必然有拣货单与之对应（必然性），且只能有一行对应（1）
- 存在拣货单，没有发票与之对应（不必然），且可能有多行对应（n）
第一句比较好理解，第二句需要补充说明。
在实际业务过程中，拣货单是发货交付的前置环节，这个环节可能出现终止，比如做好的拣货单因质量问题被驳回没有发出去，比如拣货单刚刚创建还没有进入拣货流程等。所以说，并非每个拣货单id（PickingList.id）在发票明细表中都有对应的键（Invoice.PickingListId），也就没有发票与之对应。
同时，每一张发票必然有发货交付对应，也就必然有拣货单；同时，一个发票可以对应多次拣货单（PcikingList.Id）。
对于初学者而言，从业务到技术的转变是一件困难的事情，但是只要迈过这个门槛，就能体会到业务与数据合一的境界。、
喜乐君 2024-04-12