主数据和关系数据-业务系统建模系列

数据库建模能力在传统企业业务系统开发中是重要技能之一，相比互联网公司，编程技术虽然不会有太大门槛，但是，业务建模过程中建立好数据关系表，代码实现中写好每一个逻辑细节，对思维能力的方面还是有一定要求的。

本文以供应链系统背景为例子介绍

复杂关系数据：多个基本业务单元混杂在一起的表

（图1）

物料ID	采购商ID	品类ID	组织机构ID
m01	buyer01	c01	org01
m02	buyer01	c02	org02
m03	buyer02	c03	org03

试想想，你能从这个表看出什么意思？

首先，上面每个字段都是供应链系统里的基本业务单元，其分别应该对应一个表。例如，物料的基本业务单元表如下图2

其次，每个业务单元的组合就构成一种关系，根据数学组合知识，这4个业务基本单元至少可以建立10个表代表10种关系。例如（物料+采购商），（物料+品类），… 等等。

那么，究竟哪个关系表是正确，哪个关系表不正确，哪些关系表会造成数据不一致？纯技术角度回答，是没有绝对的。衡量的标准是业务当中实际需要反映哪种关系。一定要结合业务思考！

---

数据不一致的例子

例如，假设有下面3个关系配置信息表。

采购商分配物料：图a

物料ID	采购商ID
m01	buyer01

采购商分配品类：图b

品类ID	采购商ID
c01	buyer01

创建物料时候物料被归属某品类（平台级配置，与任何采购商无关）： 图c

物料ID	品类ID
m01	c04

然后下订单, 界面里下拉列表有采购商,物料。如果校验条件做不好，产生如下数据：图d

采购商ID	物料ID
buyer01	m01

即采购商buyer01购买了m01物料。问题来了，m01属于品类c04，但是c04没有授权分配给buyer01。

如何避免上面问题？

订单下单界面做好校验。例如，选择采购商buyer01后，对物料下拉框列表进行筛查。具体是找那些物料被分配给采购商buyer01（表a）并且该物料对应的品类(表c)也分配给采购商buyer01(表a)。

为什么有上面的问题？

上面提及的问题产生原因在于图c的画蛇添足，图c反映的是平台级别物料被归属某品类的情况。业务上，这样做不合理的地方有两点，一是每家采购商公司的物料都不一样，系统不可能提前配置所有公司需要的物料；二是每家采购商公司可能把某相同的物料归类到不同的品类。

有简单点方案吗？

在图c的表取消后，如果系统配置时候对于某采购商添加一个物料，业务规定从采购商品类表选择任意一个品类分配给该物料，则把品类字段归并到图a，于是物料和品类的关系是建立是基于某采购商公司的维度下的。

物料ID	品类ID	采购商ID
m01	c01	buyer01

这样，就减少了前面校验的麻烦性，订单界面直接选择物料即可 （该物料在表a存在）。
即采购商buyer01购买了m01物料。m01属于品类c01。

---

主数据：不能再切分的基本业务单元

（图2）

品类ID（主键ID）	品类code（业务唯一）	品类name	属性attr
m01	code01	name01	attr01
m02	code02	name02	attr02
m03	code03	name03	attr03

以上的品类表可以理解为该品类定义是无组织无机构的独立于任何外界关系的基本单元，给出品类ID或者品类code都能找到代表该品类的唯一一条记录，记录里有关于该品类的所有属性信息。

为什么有品类的平台级配置？

既然上文提及图c的多余（物料不需要平台级别的设计），为什么品类却可以有图2的平台级别的设计呢？
个人认为有三点：
1. 品类信息相比物料更容易抽象出通用情况，大部分公司都适用
2. 基于产品设计出发定位，因为产品的设计是公有云系统，目标让所有采购商都使用，大部分的采购商可能不会梳理品类的信息，系统默认提供品类信息方便使用
3. 产品的定位希望能做到品类层级的管控

---