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

　　本文主要针对答主在平时工作中获取、分析需求用到的建模知识进行梳理，希望对部分童鞋有用。
　　一、写在前面
　　产品经理的日常工作中，获取需求是一个项目的始点，这是我们和用户对系统功能最开始、最直接的沟通。
　　实体联系即为ER图，这其实是在数据库建模时候，也就是数据库设计的阶段才用到的，但是我会在需求分析、梳理、设计都会用到。
　　本节主要简述实体及实体之间的3种联系，帮助我们从正、反两方面来分析问题，便于我们更清晰业务需求。
　　二、实体
　　世界由人、物、联系组成，其中人和物都是实体，并且他们都有各自的属性。
　　2。1实体分类
　　官方解释：客观存在并相互区别的事物称为实体。实体是一个抽象名词，是指一个独立的事物个体，自然界的一切具体存在的事物都可以看做一个实体。一个人是一个实体，一个组织也可以看做一个实体。实体不是某一个具体事物，而是自然界所有事物的统称。实体可以是有形的，也可以是无形的，实体也可以是抽象的事物或联系
　　理解点：1、客观存在的人（机构，下同）、物，有形的、无形的；2、独立的个体；
　　角色实体
　　人在系统中可以定义为角色实体，即为参与系统的“干系人”，他们可以是后台的系统管理员、负责审批的审批员，还是前端的促销员，普通的用户，又或者是某个渠道经销商；他是独立的个体，且在系统中是可以模拟、抽象出来的。
　　他们是否主动参与系统；
　　是否与其他已经定义的角色有重合；
　　他们参与系统主要是想达到什么目的（即角色权限）；
　　物实体
　　实体中，除去人，剩下的就是物，我们定义为物实体。角色实体可以通过系统达到什么目的，即系统中的功能，这就是物实体；在面对对象的解释中，物实体其实就对象的概念；
　　举个栗子：项目管理系统，经销商可以发起项目，由后台管理员审核后即可生成项目；
　　这其中涉及到的角色实体：经销商、后台管理员；物实体：项目、审核；
　　2。2实体属性
　　实体属性，即记录实体的基本属性、特性的信息，在产品的线框图中的页面元素，在数据库表中对应某个具体的字段。
　　属性是构成实体的组成部分，每个实体都有属性，哪怕是一个编码也是其属性，一个没有属性的实体是不存在的。
　　其次要说说属性中的用于区分同一实体不同对象的关键属性，建模中我们称之为主键，主键具有唯一性，无论是数据库自增长的序列还是根据特定规则生成的具有识别功能的编码，或者也有可能是多个字段为主键（如N：N的关系表中），我们都可以定义为主键。
　　日常中我们也常会遇到，注册其他网站时，首先让我们输入手机号，如果手机号已经注册，会提示不能再注册，该手机号已经注册了。其中，这个手机号就是用于区分用户的唯一识别码，具有唯一性。
　　三、联系
　　联系，即实体之间的联系，他们可以是角色实体物实体，物实体物实体、角色实体角色实体。分为3种关系，即11，1N，NN；判断关系应从正、反两方面去看，正向即从AB，反向即BA；其中AB时，默认A为某一个固定实体，看他对应几个B；同理BA；
　　11，关系比较简单，确定一个，另一个也随之确定，转化成数据表基本上用一张表来记录就可以；
　　举例：比如部门经理与部门的关系（暂不考虑特殊情况，纯举例），正向：一个部门经理管理一个部门；反向：一个部门只有一个部门经理；一张“部门部门经理”，记录部门与部门经理的对应关系即可（视实际情况而定）；
　　问题围绕
　　正向提问，答案是否是唯一；
　　反向提问，答案是否唯一；
　　1N，即一对多，一般为隶属、管理、父子这种关系发展而来，转化成数据表是将“1”实体作为“N”实体的一个属性来记录这种关系。
　　举例：如部门与员工的关系，正向：一个部门有多个员工，确定员工是N；反向：一个员工只隶属于一个部门，确定部门是1，所以部门员工为1：N；
　　实体表为“部门表”“人员表”，在人员表中增加“隶属部门”，这种“部门员工”的关系就可以记录，共2张表。
　　问题围绕
　　正向提问，确定1：N中的N对应哪个实体；
　　反向提问，确认1：N中的1对应哪个实体；
　　N：N，即多对多，正向、反向都是多的情况，这种转化成数据表的时候是3张表，2张实体表1张关系表，关系表记录的是2个实体的对应关系，关系表是以2个实体的主键作为主键。
　　举例：大学期间的学生课程的关系，正向：一个学生可以上多门课程；反向：一门课程允许多个学生来学习，关系确定为N：N；转化成数据表，即实体表“学生表”“课程表”，还有“学生课程”关系表。
　　举例：张三报了3门课程，分别是高等数学、英语和思想政治；关系表就会生成3条记录，分别为“张三、高等数学”“张三、英语”、“张三、思想政治”，是以“人员课程”作为主键；
　　四、写在后面
　　对于产品来说，了解ER建模其实是培养思维方式，将需求可视化。我们需要做的是多从这个角度去思考问题，尽可能的考虑到所有场景，这样在需求交接到开发的时候，他们看到的需求是全面且清晰的，而不会出现他们在建模阶段发现我们遗漏了一些问题而导致需求不明确。我们最了解的是业务和需求，如果我们再懂一些建模知识，这其实可以避免技术、开发少走不少弯路。因为像一般的软件公司，根本就没有数据库建模这一说，所以数据库表结构的设计能否最大程度的贴合需求，是很难说的事情。
　　一般情况下，我在做获取、梳理、设计时，都会从这个方式去思考问题；需求交接到开发时，我会提醒他们哪些需要着重梳理，但是不会干涉数据库的设计。
　　本文到这里，关于建模知识在梳理流程、设计线框图等后续的应用，这个后面再开章节继续写；
　　注1：我们这里所说的实体、实体之间的联系，只是从产品的角度去度量、思考、表达系统功能，帮助我们更好的了解、梳理系统功能，不要求专业性的产物，一般通过Axure、visio，甚至系统自带的画图都可以完成；
　　注2：文中内容是笔者在日常工作中获取、分析、设计需求时需考虑的必不可少的一个环节，也是有了这些关系之后才会产生后面的流程梳理、原型线框图；对于业务复杂的B端产品更为试用，发表此文仅限交流，不喜勿喷。