产品经理的技术进阶：数据库逻辑设计( 二 )

举一个我以前做的RBAC权限管理功能为例子，这个功能包括组织架构模块、角色模块、菜单权限模块、人员管理模块这四个核心模块，复杂一点的还会有其他模块，在这里不做说明。
我们设计好原型图之后，可以梳理出各个模块实体的主键、外键以及其他的属性。其中主键是唯一标识一条记录的，比如每个学生的学号是唯一的，学号就是一个主键。外键是用来和其他表建立联系用的， A表的外键往往是B表的主键。
组织架构模块：

包含的属性：组织id（一般不在前端展示）、组织机构类型、机构名称、单位类型、联系人、邮箱、电话等等
可选唯一标识的属性（又称主键）：组织id或机构名称
存储特点：永久存储

角色模块：

包含的属性：角色id、角色分类、角色名称、角色描述、角色排序id、创建人、创建时间等等
可选唯一标识的属性：角色id或角色名称
存储特点：永久存储

菜单权限模块：

包含的属性：菜单id、菜单排序id、菜单名称、菜单路径url等等
可选唯一标识的属性：菜单id或菜单名称
存储特点：永久存储

人员管理模块：

包含的属性：用户id、姓名、单位职务、级别、手机号、登录名等等
可选唯一标识的属性：人员id
存储特点：永久存储

（2）逻辑设计
第二步是逻辑设计，也是产品经理要重点学习的。
我们将上述模块的需求转化为数据库的逻辑模型，一般用ER图表示。
简易版可以在纸上画出来，作为初稿：

本文插图
输出的图例规范如下：
矩形表示实体集，菱形表示联系集，椭圆表示实体的属性，线段表示两者之间的连接。

本文插图
运用数据库范式设计具体的表：
数据库的范式有很多种，包括第一范式、第二范式、第三范式等等，这些设计范式的晦涩的术语定义不会出现在本文中。直接用相关的案例将它们描述出来，相信能够被更多人看懂。
第一范式：
采用这种范式设计出来的是一张二维表，且这种二维表的字段是不可以继续再分的，比如“联系方式”字段下面不能再拆分为“邮箱”和“电话”两个字段。这也是最简单且最容易遵守的一种范式。举个例子，下面的表格就是符合第一范式的。

本文插图
第二范式：
这种范式是在第一范式的基础上定义的，下面的表中结合了组织架构和人员管理两张表的属性。
所以符合第二范式的表如下：
【人员管理表】

本文插图
【组织架构表】

本文插图
【关联表】

本文插图
第三范式：
这种范式是在第二范式的基础上定义的，下面这张表包含了组织架构、人员管理和角色管理这三张表的属性。
大家可以看到，一个组织架构下面会有很多用户，一个用户也会有很多角色。所以按照第三范式设计的表如下：
【人员管理表】