编辑导语：我们在日常工作中经常会遇到各种各样的逻辑关系，逻辑可以让我们的工作提高效率；作者在前一篇介绍了逻辑中的“业务逻辑”表达方式，本篇文章作者继续介绍“数据逻辑”的表达方式，我们一起来看一下。

多数没有开发背景的需求工程师对数据面层的分析、设计是比较生疏的，面对比较复杂的数据关系时或多或少都有一些畏惧，不太愿意深究，尽量交给后续的程序员去处理。

这个做法是不对的，数据逻辑来源于业务逻辑，需求分析师能够向程序员说明数据逻辑关系，那么后者的工作效率会提升很多（否则、不熟悉业务的后者还要花费很多时间去研究业务逻辑）；同时是否能够清楚地表达数据逻辑关系也说明了需求分析师具有的能力和水平。

一、数据逻辑的概念

数据逻辑：表达的是数据层数据之间的逻辑关系，这个层的要素是数据。

为了理解数据逻辑，要先理解为什么存在着业务逻辑和数据逻辑二种不同的表达形式呢？这首先是因为两者存在于不同的层面上、且要素不同。

1. 业务逻辑

表达的是以客户“活动、规则”等内容为要素的逻辑关系。

业务逻辑表达的是业务活动之间的关系，是以客户的业务知识、业务事理为基础的。

举例说明，图1是一个生产过程的业务架构图（流程图），我们对客户业务的理解首先是从业务架构图获得的，从图的表面上只看到业务活动之间的关系，如：活动“4.采购”完成后下一个活动是“5.物流”。

图1 生产流程图

在表面上虽然直接看不到数据的存在，但是在两个活动之间的关联线中流动着如下的数据：采购物品名称、数量、单价、交付日期等。

2. 数据逻辑

表达的是以“数据”为要素的逻辑关系。

数据逻辑是数据间的关系。数据架构层在业务架构层的下面，图2是一个业务逻辑与数据逻辑关系的示意图。

从业务架构图上是不能直接看到数据逻辑的，数据是业务活动产生的结果（沉淀），数据逻辑的获取是依赖于业务逻辑的，但在数据获取后，数据间的引用关系要远多于业务活动间的关联关系，如图2所示。

数据逻辑虽然来源于业务逻辑，反过来数据逻辑又是业务逻辑合理存在的内在支撑。

图2 业务逻辑与数据逻辑关系的示意图

确认了存在着数据之间的逻辑关系，那么这个逻辑表达形式是什么样的呢？数据逻辑的表现形式有很多，本篇的目的是支持业务需求的分析工作，因此从“业务的视角”给出数据逻辑的表达方法（而不是从技术视角）。

3. 数据逻辑的表达形式

这里介绍业务分析用的三种数据逻辑表达形式：线、表、图，参见图3，其中：

• 图（a）线：是用数据表的业务编号，作为连接数据表、数据之间的关系（主/外键）；
• 图（b）表：指的是数据表，用表格结构表达出数据之间的上下、父子、从属等的关系；
• 图（c）图：用图的形式，给出数据之间的关联关系，如：算式图、数据线、勾稽图；

图3 数据逻辑的表达方式

二、数据逻辑表达的简介

1. 用线表达数据逻辑（主/外键）

以下面的合同书的数据表为例，说明主键和外键的定义和关系，参见图4。

主键，是本数据表的代表名称，一个数据表里只能有一个主键，它只能是唯一地标识表中的每一行，通过它可强制数据表的完整性；它用于与其他表的关联，以及本记录的修改与删除等。

外键，当一个表中除了本表的主键外，还保存了其它数据表的主键时，那么在本表中其它数据表的主键就被称之为“外键”；根据参照外部数据表的数量多少，一个数据表中可以有复数的外键。

图4 数据表之间的主外键关系示意图

2. 用表表达数据逻辑

数据表，是按照一定的结构形式排列的数据格式，任何数据的载体都是数据表。用“格式”描述数据表的形式，格式包括了数据结构、数字分类、数据状态等三类内容，参见图5。

• 数据结构：列表结构、树表结构等；
• 数字分类：数值、货币、文本、日期、分数等；
• 数据状态：表达在导入上游功能的数据时，该功能所处的状态，比如：编辑期限已过、功能被锁定、审批已完成、数据已被引用等。

图5 数据表格式示意图

3. 用图表达数据逻辑

当遇到了非常复杂的计算，比如：数据来源多、计算公式复杂且需要进行多重计算等，需求分析师如何才能做到准确、快速地向程序员说明计算公式和数据呢？

此时仅靠用文字说明就非常困难了，即麻烦、又不准确，使用逻辑图是一个非常好的方法，这里简单地介绍一下算式关联图的用法。

算式关联图的应用场景是：在某个“节点”上有多个数据来源的汇总、计算；这个计算式可以是存在于活动功能、看板功能或报表功能中的某个处理步骤，这个计算式涉及到了复杂的数据来源、引用、关联及多重的计算。

算式关联图的模型包括了两大部分：数据的来源和数据的处理，见图6。

假定在图a.的“L-021采购流程”的B节点①上有一个计算处理，这个计算需要用到A、B、Q节点、以及其他数据库的数据，表达B节点计算过程的方式如下。

图6 算式关联图

下面分别对算式关联图的各个部分进行详细说明。

1）数据来源

数据来源图部分，是用来说明包含有计算功能的位置、以及其它参与计算的数据来源：

• 绘制采购流程L-021，该流程上节点A和节点B中的数据参与了计算，另外，不在流程上的独立活动Q中的数据也参与了计算；
• 标注出发生了“成本核算”处理的活动B在该流程上的位置（可以采用不同的颜色）；
• 标注出每个活动上参与计算的数据表名称，比如：活动A/表a（在流程上的功能）、活动Q/表q（非流程上的功能）；

至此，标示出了计算公式的位置和3个数据的来源，完成了数据来源的说明。

2）数据处理

数据处理图，是建立数据表b的计算处理模型，其中：

图6的②表b：因为计算公式在发生在功能B上，因此将功能B的数据表b放到处理图的左上角。

图6的③其它的数据来源分列在处理图的两侧（布局的要求仅作为参考），比如：

• 数据源1：将来源于活动类的数据，如：表a、表q，置于处理图的左侧，表b的下方；
• 数据源2：将来源于数据库的数据，如：基础数据、过程数据库，置于处理图的右侧；

图6的④计算数据：在表内写入参与计算的变量名称、数值，并用箭头线将数据表指向处理器；

图6的⑤计算名称：计算处理器⑤的上面要标明算式的名称，如：成本核算；

图6的⑥计算过程：将各数据来源的具体数值带入到计算过程⑥的公式中，格式必须要给出分步计算的过程，必须要让程序员可以读出来每一步的计算公式与对应的计算结果；

图6的⑦计算结果：将最终的计算结果填入计算结果栏⑦，到此完成全部的计算过程；

图6的⑧如果某个步骤的内容比较复杂，可以在实体、或是数据旁边，加入一些说明文；

可以看出来，算式关联图实际上就是一个为解决某个特定问题而建立的用例图。

扩展说明：

由谁来规划数据和建立数据标准？

在软件企业中有不少人认为：只要是数据相关的设计就是程序员的工作，其实不然，业务层面与技术层面对数据的设计方法是不同的，技术层面的数据设计不能替代业务层面的数据设计；相反，没有很好的业务层面的数据设计做支持，技术层面的数据设计缺乏依据、容易发生重复调研、分析和设计的现象，工作效率低。

与技术层面的数据设计不同，业务层面重点做的不是数据“库”的设计，而是业务数据的逻辑设计，由于业务和技术的视角不同，数据关系图的表达内容和方式也不同，参见图7中的两张图就可以看出它们之间的区别，区别的关键点还是在于业务逻辑的有无。

• 业务视角的数据关系图（a）：有业务流程，带有清晰的业务逻辑关系；
• 技术视角的数据关系图（b）：用“键”的形式替代了业务逻辑的表达形式，但是要注意，这个“键”的设计依据或直接、或间接地参考了业务逻辑。

图7 数据关系图

只有从业务设计的视角，充分地理解业务数据的内容、用途、业务数据之间的逻辑关系、以及未来可能的变动规律等，才能保证不论业务如何变化数据的结构都是稳定的。

消除企业信息孤岛现象，首先是业务设计师要解决的问题，因为这个问题的本质不是数据库问题，也不是技术开发工程师单独能够解决的问题。

本系列下一篇博文：李鸿君：如何绘制逻辑图 — 9.模型的分类

作者：李鸿君；《大话软件工程—需求分析与软件设计》一书作者。

本文由 @李鸿君 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议