文接上篇《数据库建模知识：在需求获取与分析中的应用（上）》，本文详述如何将建模知识应用到需求梳理和需求设计中。

1. 模型建立后如何呈现

想要将脑海中的实体-联系表达、呈现出来，能让开发、测试、客户看的明白，我一般会使用实体-联系图和角色权限矩阵来表达。

1.1 实体-联系图

（1）业余画法

专业性要求不高的情况下，一般的画图软件都可以实现，比如Axure、Visio、word、ppt，就连系统自带的画图软件都可以。虽然这种画法比较随意，也会忽略在数据库阶段建模要考虑的其他属性，但对于产品来说，这个业余画法也够用了。

以下是方法：

1. 确定实体A和B，用长方形的方框表示，方框内填入实体名称。
2. 用一条直线将两个实体连接起来。
3. 确定两个实体之间的联系，插入文本，填入联系，注意方向性，不要搞反了。

如下图，以word示例：

注：建议每个实体-联系都加上解释，避免查看的人因为不懂而出现二次解释场景。

（2）专业绘制

专业绘制，是指技术/开发人员在进行数据库设计之前会根据系统业务需求而进行的建模工作，一般会使用专业的数据库建模工具，这样的话，后面的表结构是可以直接由这个模型进行转化的。

注：对于产品来说，可以稍作了解，无需太深入研究。感兴趣而且有时间那另算。答主本人是学软件工程出身，所以这块还是略有接触，但由于实习+工作都是关于需求方面的工作，所以专业程度仅限于大学老师讲的基础（摊手）。

1.2  角色权限矩阵

角色权限矩阵，顾名思义，就是看系统中有哪些角色，这些角色有哪些权限。这个是一定要去思考并表达出来的，一个系统在被提出来时，就应该考虑系统的若干 “干系人”，就是将来使用这个系统的人员角色定义。

在与用户详细沟通需求后，这个系统是以什么方式去做，我们大概是清楚的，即使不清楚，在整理需求时，我们也会去思考适合的方式。

问题围绕：

1. 系统基于什么方案、平台实现，后台+前端；
2. 前端的角色实体有哪些，后端的角色实体有哪些；
3. 前端各角色通过系统想要实现什么，即对物实体的操作；
4. 后端角色需要做哪些模块来配合前端完成这件事情；
5. 各角色对实体的管理有何限制（包括操作和实体属性），如增、删、改、查，再加上系统特有的功能。

一个系统对应抽离出角色实体、物实体后，这个基本就可以归纳出来。

以下内容由Excel绘制，X轴（横轴）代表角色实体，Y轴（纵轴）代表物实体，其中1级为功能模块，2级为功能，3级为对该功能的操作，有差异请以实际情况为准。

下图为例：

角色权限矩阵不像UML中的用例图那样，一千个人眼中有一千个哈姆雷特，粒度随心。角色权限矩阵建议尽量细化，有时候甚至可以细化到具体的某个字段，这样做的好处是，在设计阶段，我们可以不用再文字累述哪些人员可见哪些人员不可见。

2. 如何将模型转化为流程，流程梳理

主要介绍系统主流程及实体状态图转化的画法。

2.1 系统主流程

角色权限矩阵确定后，基本上系统的主流程是可以确定下来；

我一般使用Axure或者Visio来绘制流程图，如只是业务较简单的图，我会用Axure直接画；如查看的人对美观度要求比较高且业务较复杂的，建议用Visio的跨职能流程，方便阅览系统-人员，人员-人员的流程扭转和关键步骤的衔接。

跨职能流程图，绘制要点如下，后续会持续追加；

1. 跨职能流程图的泳道，一般是系统（平台涉及到的系统，包括对接平台）、系统角色（即上篇中说的角色实体），要根据流程图的侧重点来选取不同的角度；
2. 跨职能流程图的分隔符，一般是系统模块，或者自定义的一个流程范围；
3. 从人员数据、基础数据的初始化开始，再到后面的业务；
4. 务必做到每个环节的衔接、贯通，如做不到，尝试从实体的状态或增加规则逻辑来实现；
5. 如果暂时没有办法将应该串联起来的环节衔接，先把有问题的环节填充为红色，尝试从状态图入手；

下图为例，主流程中的一小部分：

2.2 实体状态图

系统中涉及到的实体，包括物实体、角色实体都可以有状态的，只是有时候可能系统用不到，就不会设置状态；我一般在业务较复杂，或者主流程梳理出现卡壳、断掉的情况下，会来重新设计下这块业务涉及到的实体的状态转化图；

状态图3要素介绍：

1. 实体：并非所有的实体都要考虑，而是针对此状态图涉及到的关键实体；如上图中的两个状态OFF和ON，其实是基于烧水壶这个实体的；
2. 状态：描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的事件做出反应；如上图中的OFF和ON；
3. 转化操作：即刺激状态转化的事件；如上图中的turnOn和turnOff。

实体状态图，绘制要点如下，后续会持续追加；

1. 列出该状图涉及到的实体以及实体的初始状态；如涉及到的实体超过1个，应标明状态是属于哪个实体，如下面的示例图，橘色是报备的状态，蓝色是价格申请的状态，绿色是合同的状态；
2. 归纳出刺激实体状态转化的事件，分类归纳，即有可能这两类事件对状态的转化是一致的，那他们就是属于一类事件，但记得要将两类事件都标注出来；
3. 检查当前实体的状态是否满足业务流程，如状态缺失满足不了，增加状态或限制条件；说的过于笼统，但只要只要有实际案例的经验，应该都能了解我说的是个啥，摊手；
4. 当状态图梳理完成，贴合业务后，再去适当的调整系统流程图；

先写到这，后面会再开一篇写写建模知识在实际设计中的应用。

【未完待续】

相关阅读

数据库建模知识：在需求获取与分析中的应用（上）

作者：Andy。放松玩，专注思考的B端产品经理。

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