本文基于RBAC权限管理模块为例子，以产品经理的视角，一步步完成数据库逻辑设计实践，希望能给大家带来一点启发！
我毕业后进入了一家B端公司做产品，在临近转正的时候，要考核的一点是SQL查询语言的运用能力，因为工作中需要经常查询数据来辅助分析，而以往呆过的公司都不需要产品经理很懂数据库，只要会基本的SQL查询即可，就一直没有进一步了解它。
但现在随着公司对产品经理的要求越来越高，尤其是B端产品经理，懂基本的数据库设计是个很好的加分项。最近看到招聘网站上一家知名的B端公司jd里，对产品经理岗位的其中一条要求是：“了解主流数据库的原理，具备较强的数据库设计能力”。这种能力我们可以理解为基础的数据库逻辑设计能力。
而数据库分为关系型数据库和非关系型数据库，本文主要讨论的是关系型数据库。
基本原理弄清楚了，接下来就要思考，怎么去设计了。
1.什么是数据库设计？
简单来说，数据库设计是根据业务系统的具体需要，结合我们所选用的数据库管理系统，为这个业务系统构造出最优的数据存储模型。并建立好数据库中的表结构以及表与表之间的关联联系的过程。使之能有效的对应系统中的数据进行存储，并可以高效的对已经存储的数据进行访问。
2.为什么要进行数据库设计？
数据库相当于一个大楼的地基，如果地基打好了，大楼就会稳固，否则就很容易轰然倒塌。
那么好的数据库设计和糟糕的数据库设计有什么特点呢？
3.数据库设计的步骤是什么？
（1）需求分析
第一步要进行需求分析，梳理出系统中所要存储的数据属性、存储特点和生命周期。
举一个我以前做的RBAC权限管理功能为例子，这个功能包括组织架构模块、角色模块、菜单权限模块、人员管理模块这四个核心模块，复杂一点的还会有其他模块，在这里不做说明。
我们设计好原型图之后，可以梳理出各个模块实体的主键、外键以及其他的属性。其中主键是唯一标识一条记录的，比如每个学生的学号是唯一的，学号就是一个主键。外键是用来和其他表建立联系用的，A表的外键往往是B表的主键。
组织架构模块：
角色模块：
菜单权限模块：
人员管理模块：
（2）逻辑设计
第二步是逻辑设计，也是产品经理要重点学习的。
我们将上述模块的需求转化为数据库的逻辑模型，一般用ER图表示。
简易版可以在纸上画出来，作为初稿：
输出的图例规范如下：
矩形表示实体集，菱形表示联系集，椭圆表示实体的属性，线段表示两者之间的连接。
运用数据库范式设计具体的表：
第一范式：
第二范式：
这种范式是在第一范式的基础上定义的，下面的表中结合了组织架构和人员管理两张表的属性。
所以符合第二范式的表如下：
【人员管理表】
【组织架构表】
【关联表】
第三范式：
这种范式是在第二范式的基础上定义的，下面这张表包含了组织架构、人员管理和角色管理这三张表的属性。
大家可以看到，一个组织架构下面会有很多用户，一个用户也会有很多角色。所以按照第三范式设计的表如下：
【角色表】
小结：第一范式和第二范式的区别在于有没有分出两张表，第二范式是说一张表中包含了多种不同的实体属性，那么必须要分成多张表，第三范式是要求已经分成了多张表，那么一张表中只能有另一张表中的主键，而不能有其他的任何信息（其他的信息一律用主键在另一表中查询）。
其实除了以上三个范式，还有第四、第五、BC以及反范式化设计，这里不做扩展，有兴趣的可以自行查询了解。
综上，结合范式和ER图输出的表结构如下：
为了方便理解，表中的属性字段命名我写成了中文，实际上在数据库里都是英文，比如用户id可以命名为UserId,命名的工作在物理设计中进行，一般是架构师去处理。
（3）物理设计
第三步是物理设计，一般是架构师做的事，产品经理简单了解下即可，同样也不做扩展说明。
结尾
但通过本文可以了解最基础的数据库逻辑设计应该怎么做，会对业务系统的技术实现有更深刻的认识，若有SQL基础则能更容易理解。
本文由@葩说产品原创发布于人人都是产品经理。未经许可，禁止转载