专业的短链接生成工具
链接域名
短网址有效期
产品经理的技术进阶：数据库逻辑设计
更新时间：2025-6-1 11:44:44 作者：爱短链
本文基于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图表示。
简易版可以作为初稿在纸上画出来: 输出图例规范如下： 矩形表示实体集，菱形表示联系集，椭圆表示实体属性，线段表示两者之间的连接。
具体表格采用数据库范式设计： 数据库的范式有很多种，包括第一范式、第二范式、第三范式等。
这些设计范式的晦涩术语定义不会出现在本文中。
直接用相关案例来描述，相信人理解。
第一范式： 采用此范式设计的是二维表，该二维表的字段不能继续重新划分。
例如，联系信息字段不能分为电子邮件和电话字段。
这也是最简单、最容易遵守的范式。
例如，下表符合第一范式。
第二范式： 该范式是在第一范式的基础上定义的，下表结合了组织结构和人员管理的属性。
因此，符合第二范式的表如下： 【人员管理表】 组织结构表 【关联表】 第三范式： 该范式是在第二范式的基础上定义的，下表包括组织结构、人员管理和角色管理。
如你所见，一个组织结构下会有很多用户，一个用户也会有很多角色。
因此，按照第三范式设计的表如下： 【人员管理表】 组织结构表 【角色表】 【关联表】 总结:第一范式和第二范式的区别在于是否有两个表，第二范式是一个表包含多种不同的物理属性，所以必须分为多个表， 第三个范式是要求已经分成多个表，所以一个表中只能有另一个表中的主键，而不能有任何其他信息(其他信息是用主键在另一个表中查询)。
事实上，除了上述三种范式外，还有第四、第五和第五BC还有反范式设计，这里不做扩展，有兴趣的可以自己查询了解。
综上所述，结合范式和ER图输出的表结构如下： 为了便于理解，我把表中的属性字段命名为中文，但实际上在数据库中都是英文，比如用户id可以命名为UserId,命名工作在物理设计中进行，一般由架构师处理。
(3)物理设计 第三步是物理设计，一般是架构师做的，产品经理可以简单了解，也不做扩展说明。
选择合适的数据库管理系统 定义数据库、表和字段的命名规范 根据所选数据库管理系统选择合适的字段类型。
结尾 了解以上知识并不能让你精通数据库，尤其是像这样的底层东西，仅仅依靠一篇文章是很难完全掌握的。
例如，在业务需求、性能和数据冗余之间实现平衡需要深入的数据库技能。
然而，通过本文，我们可以了解如何进行最基本的数据库逻辑设计，并对业务系统的技术实现有更深入的了解。
SQL基础更容易理解。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
当我即将成为一名正式员工时，我需要评估的一点是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基础更容易理解。
特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。
本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。
如有侵权行为，请联系网站管理员删除，。
