产品经理的技术进阶：数据库逻辑设计
我毕业后进入了一家B端公司做产品，在临近转正的时候，要考核的一点是SQL查询语言的运用能力，因为工作中需要经常查询数据来辅助分析，而以往呆过的公司都不需要产品经理很懂数据库，只要会基本的SQL查询即可，就一直没有进一步了解它。
但现在随着公司对产品经理的要求越来越高，尤其是B端产品经理，懂基本的数据库设计是个很好的加分项。最近看到招聘网站上一家知名的B端公司jd里，对产品经理岗位的其中一条要求是：“了解主流数据库的原理，具备较强的数据库设计能力”。这种能力我们可以理解为基础的数据库逻辑设计能力。
而数据库分为关系型数据库和非关系型数据库，本文主要讨论的是关系型数据库。
- 关系型数据库是依据关系模型来创建的数据库，所谓关系模型就是“一对一、一对多、多对多”等关系模型，比如一个学号对应一个学生，一个班级对应多个学生，多个老师对应多个学生。一个关系型数据库是由二维表及其之间的联系组成的一个数据组织。
- 非关系型数据库是一种相对松散且可以不按照严格的结构规范进行存储的数据库。最常见的是键值对模型：存储的数据是一个个“键值对”，比如age:18，那么age这个键里面存的值就是18。
拿知识星球来说，用户发了一条动态，数据库会建立一个索引，并将此动态存入数据区中。如果用户删掉此动态，数据库首先会删掉索引区的索引，数据区中的动态根据数据库的存储性能和容量可能会保留一段时间，保留的那段时间的状态是假删除，也叫逻辑删除。如果用户再新发布一条新的动态，新的索引和动态会直接覆盖上一条假删除的数据，此时就是真删除了，也叫物理删除。
为了防止覆盖数据后变真删除，还能这么设计：即把用户假删除的数据打上标记，存在另一个数据库表中，当要恢复数据的时候再修改标记。
基本原理弄清楚了，接下来就要思考，怎么去设计了。
1. 什么是数据库设计？
简单来说，数据库设计是根据业务系统的具体需要，结合我们所选用的数据库管理系统，为这个业务系统构造出最优的数据存储模型。并建立好数据库中的表结构以及表与表之间的关联联系的过程。使之能有效的对应系统中的数据进行存储，并可以高效的对已经存储的数据进行访问。
2. 为什么要进行数据库设计？
数据库相当于一个大楼的地基，如果地基打好了，大楼就会稳固，否则就很容易轰然倒塌。
那么好的数据库设计和糟糕的数据库设计有什么特点呢？
3. 数据库设计的步骤是什么？
（1）需求分析
第一步要进行需求分析，梳理出系统中所要存储的数据属性、存储特点和生命周期。
比如有的数据有时效性，有的数据无时效性。有实效性的数据可以采取过期清理的方式来进行存储，比如小米云服务里的用户主动删除的照片、视频、便签等数据会进入回收站保留一定期限，到期后回收站自动清空。
还有的数据增长很快数据量也很大，但不是核心数据，那就可以采用分库分表的方式进行存储，也叫数据库表的水平拆分。
比如我前公司的一个大客户给他们的用户发了大量的邮件，系统会不断的返回相关的状态信息数据，这些数据都在一张表里，当这些数据达到百万甚至千万级别时，用户查询数据的效率和速度都会降低，在界面上的体现是会发现搜索或跳转页面的时候特别卡，这个时候对数据库进行分库分表就是个不错的方案。
举一个我以前做的RBAC权限管理功能为例子，这个功能包括组织架构模块、角色模块、菜单权限模块、人员管理模块这四个核心模块，复杂一点的还会有其他模块，在这里不做说明。
我们设计好原型图之后，可以梳理出各个模块实体的主键、外键以及其他的属性。其中主键是唯一标识一条记录的，比如每个学生的学号是唯一的，学号就是一个主键。外键是用来和其他表建立联系用的，A表的外键往往是B表的主键。
组织架构模块：
- 包含的属性：组织id（一般不在前端展示）、组织机构类型、机构名称、单位类型、联系人、邮箱、电话等等
- 可选唯一标识的属性（又称主键）：组织id或机构名称
- 存储特点：永久存储
角色模块：
- 包含的属性：角色id、角色分类、角色名称、角色描述、角色排序id、创建人、创建时间等等
- 可选唯一标识的属性：角色id或角色名称
- 存储特点：永久存储
菜单权限模块：
- 包含的属性：菜单id、菜单排序id、菜单名称、菜单路径url等等
- 可选唯一标识的属性：菜单id或菜单名称
- 存储特点：永久存储
人员管理模块：
- 包含的属性：用户id、姓名、单位职务、级别、手机号、登录名等等
- 可选唯一标识的属性：人员id
- 存储特点：永久存储
（2）逻辑设计
第二步是逻辑设计，也是产品经理要重点学习的。
我们将上述模块的需求转化为数据库的逻辑模型，一般用ER图表示。
简易版可以在纸上画出来，作为初稿：
输出的图例规范如下：
矩形表示实体集，菱形表示联系集，椭圆表示实体的属性，线段表示两者之间的连接。
运用数据库范式设计具体的表：
数据库的范式有很多种，包括第一范式、第二范式、第三范式等等，这些设计范式的晦涩的术语定义不会出现在本文中。直接用相关的案例将它们描述出来，相信能够被更多人看懂。
第一范式：
采用这种范式设计出来的是一张二维表，且这种二维表的字段是不可以继续再分的，比如“联系方式”字段下面不能再拆分为“邮箱”和“电话”两个字段。这也是最简单且最容易遵守的一种范式。举个例子，下面的表格就是符合第一范式的。
第二范式：
这种范式是在第一范式的基础上定义的，下面的表中结合了组织架构和人员管理两张表的属性。
所以符合第二范式的表如下：
【人员管理表】
【组织架构表】
【关联表】
第三范式：
这种范式是在第二范式的基础上定义的，下面这张表包含了组织架构、人员管理和角色管理这三张表的属性。
大家可以看到，一个组织架构下面会有很多用户，一个用户也会有很多角色。所以按照第三范式设计的表如下：
【人员管理表】
【组织架构表】
【角色表】
【关联表】
小结：第一范式和第二范式的区别在于有没有分出两张表，第二范式是说一张表中包含了多种不同的实体属性，那么必须要分成多张表， 第三范式是要求已经分成了多张表，那么一张表中只能有另一张表中的主键，而不能有其他的任何信息（其他的信息一律用主键在另一表中查询）。
其实除了以上三个范式，还有第四、第五、BC以及反范式化设计，这里不做扩展，有兴趣的可以自行查询了解。
综上，结合范式和ER图输出的表结构如下：
为了方便理解，表中的属性字段命名我写成了中文，实际上在数据库里都是英文，比如用户id可以命名为UserId,命名的工作在物理设计中进行，一般是架构师去处理。
（3）物理设计
第三步是物理设计，一般是架构师做的事，产品经理简单了解下即可，同样也不做扩展说明。
- 选择合适的数据库管理系统
- 定义数据库、表及字段的命名规范
- 根据所选的数据库管理系统选择合适的字段类型。
结尾
了解了以上的知识并不能使你精通数据库，尤其是像这种底层的东西，仅靠一篇文章是很难完全掌握的。比如在业务需求、性能和数据冗余之间达到一个平衡就需要深厚的数据库功底。
但通过本文可以了解最基础的数据库逻辑设计应该怎么做，会对业务系统的技术实现有更深刻的认识，若有SQL基础则能更容易理解。
本文作者 @葩说产品
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
