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

本文主要针对答主在平时工作中获取、分析需求用到的建模知识进行梳理，希望对部分童鞋有用。

一、写在前面

产品经理的日常工作中，获取需求是一个项目的始点，这是我们和用户对系统/功能最开始、最直接的沟通；俗话说的好，好的开始是成功的一半，但我觉得这在整个软件周期中甚至是超过一半的，这其中的重要性就不言而喻了；如果说我们再获取需求的时候就没有理清实体之间的关系，没有对系统有个系统认识，那这个项目的主线其实到后期多半是推翻重做。

之后就是梳理、分析需求，这其实和获取需求是可以同步的，在一些比较有经验的产品中，他们在获取需求的时候，脑海中就已经梳理、分析的差不多了，包括这个功能怎么做、对其他功能带来的影响、涉及到的改动点等。

实体之间的联系，这其实是在数据库建模时候，也就是数据库设计的阶段才用到的，但是我会在需求分析、梳理、设计需求都参考，特别是在获取需求时，这个能帮我们很快从用户嘴里抠出我们想要的东西；对我帮助很大。

二、  实体

官方解释

客观存在并相互区别的事物称为实体。 实体是一个抽象名词，是指一个独立的事物个体，自然界的一切具体存在的事物都可以看做一个实体。一个人是一个实体，一个组织也可以看做一个实体。实体不是某一个具体事物，而是自然界所有事物的统称。实体可以是有形的，也可以是无形的，实体也可以是抽象的事物或联系

理解点

• 客观存在的人（机构，下同）、物，有形的、无形的；
• 独立的个体；

世界由人、物、联系组成，人、物可以定义为实体，将人与物的关联即为联系。我个人更倾向于把人与物，人与人，物与物之间的联系单独拿出来分析，所以实体和联系是分开来写的，先来看看实体。

人在系统中可以定义为角色实体，如后台的系统管理员、负责审批的审批员，还是前端的促销员，普通的用户，又或者是某个渠道经销商。他是独立的个体，且在系统中是可以模拟、抽象出来的。

在需求获取阶段，角色的定义，角色的抽离，角色的权限是我们首先需要通盘考虑的问题。一般情况下，客户会根据他们的实际情况来定义几个不同的角色，分配他们不同的职责权限，但是我们要从客户的口中听到对我们有价值的东西就需要发挥我们不耻下问的精神了。具体的提问点可以围绕：

• 在现实中，是否有对应的这类人
• 是否与其他已经定义的角色有重合
• 他们可以干什么事情
• 他们不可以干什么事情

实体中，除去人，剩下的就是物；“他们可以干什么事情”“他们不可以干什么事情”，这其中的“事情”就是物（或人）。大概分为下面4类：

人–物

比如项目销售可以报备项目，这时候基本就可以断定项目销售-角色实体，项目-实体，报备是把人和物关联起来的联系；区域经理管理多个区域，区域经理-角色实体，区域-系统枚举定义，管理多个即为区域经理与区域的联系；

人–人

店长管理门店店员，店长、店员-角色实体，门店-机构，也可以认为为物；

物–物

一个项目下可以有多个报备，项目、报备-实体；

物–人

一个项目允许多个经销商报备，项目-实体，经销商-角色实体；

角色实体很好区分，其实就是人、机构，那剩下的那个名词基本上就是一个实体。

确认实体可以围绕以下几点：

• 是否存在，包括客观的，抽象的；
• 是否可以作为主语使用。

二、  联系

联系，即人与人，人与物，物与物之间的联系；分为3种关系，即1-1，1-N，N-N；判断关系应从正、反两方面去看，正向即从A-B，反向即B-A；其中A-B时，默认A为某一个固定实体，看他对应几个B，同理B-A。

1-1，关系比较简单，确定一个，另一个也随之确定。

比如部门经理与部门的关系（暂不考虑特殊情况，纯举例），正向：一个部门经理管理一个部门；反向：一个部门只有一个部门经理。如张三是产品部的部门经理，张三管理那个部门？产品部的部门经理是谁？

问题围绕

• 正向提问，答案是否是唯一；
• 反向提问，答案是否唯一；

1-N，即一对多；比较常见的如部门与员工的关系，正向：一个部门有多个员工，确定员工是N；反向：一个员工只隶属于一个部门，确定部门是1，所以部门-员工为1：N。

注意区分哪边是1哪边是N，这个搞混了基本就狗带了。

问题围绕

• 正向提问，确定1：N中的N对应哪个实体；
• 反向提问，确认1：N中的1对应哪个实体。

N：N，即多对多；同上，正向、反向提问，问题，均为多个；问题围绕，同上。

四、  写在后面

根据以上方法确定实体以及实体之间的联系后，基本上什么人能干什么事情、不能干什么什么事情（角色实体与实体的联系），以及实体之间的联系基本可以确定，这对后面的设计，信息架构的组织可是起到至关重要的作用。关于梳理流程以及如何设计、布局信息架构，把整个产品清晰而有条理的串起来，这个后面再开章节继续写。

• 注1：我们这里所说的实体、实体之间的联系，只是从产品的角度去度量、思考、表达系统/功能，帮助我们更好的了解、梳理系统/功能，不要求专业性的产物，一般通过Axure、visio，甚至系统自带的画图都可以完成；
• 注2：文中内容是笔者在日常工作中获取、分析、设计需求时需考虑的必不可少的一个环节，也是有了这些关系之后才会产生后面的流程梳理、原型线框图；对于业务复杂的B端产品更为试用，发表此文仅限交流，不喜勿喷。

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

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

题图来自PEXELS，基于CC0协议