产品经理的技术进阶：数据库逻辑设计 .docVIP

产品经理的技术进阶：数据库逻辑设计 本文基于RBAC权限管理模块为例子，以产品经理的视角，一步步完成数据库逻辑设计实践，希望能给大家带来一点启发！ 我毕业后进入了一家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图表示。 简易版可以在纸上画出来，作为初稿： 输出的图例规范如下： 矩形表示实体集，菱形表