数据库表结构设计规范
演讲人：
日期:
CATALOGUE
目录
02
概念结构设计
01
需求分析阶段
03
逻辑结构设计
04
物理结构优化
05
安全与性能保障
06
文档与版本管理
01
PART
需求分析阶段
业务场景建模方法
业务流程梳理
通过业务流程梳理，了解业务流程及其数据流转情况。
01
根据业务流程，抽象出业务场景，并绘制业务场景图。
02
场景描述
详细描述每个业务场景，包括场景名称、参与者、前置条件、后置条件、主流程、分支流程等。
03
场景建模
数据实体关系梳理
实体识别
识别业务中的关键数据实体，包括人、物、事件等。
实体关系分析
实体属性定义
分析各实体之间的关联关系，如一对一、一对多、多对多等，并绘制实体关系图。
根据业务需求和实体关系，定义每个实体的属性，包括唯一标识、名称、类型、长度、是否允许为空等。
1
2
3
根据命名规则和约定，对字段进行命名，确保字段名称唯一、简洁、易懂。
根据字段的值类型和范围，选择合适的数据类型，如字符串、整数、日期等。
根据业务规则，为字段添加约束条件，如唯一性、非空、长度限制、值范围等。
对涉及个人隐私或业务敏感的字段进行特殊处理，如加密存储、访问控制等。
关键字段属性确认
字段命名规范
字段类型选择
字段约束条件
敏感字段处理
02
PART
概念结构设计
实体-联系图构建原则
实体间关系清晰
每个实体应具有清晰、明确的属性，且属性应尽可能全面、准确地描述实体的特征。
层次结构合理
实体属性明确
不同实体之间的关系应明确、稳定，尽量避免模糊、冗余的关系。
实体间的层次关系应清晰、合理，避免出现复杂的网状结构，有助于数据的高效访问和管理。
数据字典标准化定义
数据项命名规范
数据项的名称应简洁、明了，具有描述性，且应遵循统一的命名规则。
01
对于相同类型的数据项，其数据类型和格式应保持一致，以便于数据的存储、处理和交换。
02
数据值域限制
对每个数据项的值域进行明确限制，避免数据的有效性和准确性受到影响。
03
数据类型及格式统一
在数据表设计中，应尽量避免重复存储相同的数据，以减少数据的冗余和存储空间的浪费。
冗余控制策略制定
避免重复存储
对于多个实体或属性共用的数据，应通过合理的表结构设计实现数据的共享，以提高数据的利用效率和一致性。
数据共享原则
对于已经存在的冗余数据，应及时进行清理和消除，以保证数据的准确性和整洁性。
冗余数据消除
03
PART
逻辑结构设计
确保每列保持原子性，即列中的值不可再分割。
第一范式
在满足第一范式的基础上，确保表中的所有非主键列完全依赖于主键，消除部分依赖。
第二范式
在满足第二范式的基础上，确保非主键列不传递依赖于主键，消除传递依赖。
第三范式
表结构范式化设计
主键与外键约束规则
外键
唯一标识表中的一行记录，通常使用自增ID或UUID。
约束规则
主键
用于建立表与表之间的关联关系，确保数据的完整性和一致性。
主键不能为空且唯一，外键必须对应参照表中的有效值。
索引建立场景分析
索引建立场景分析
频繁查询的列
多表连接时作为连接条件的列
排序和分组操作的列
避免对频繁更新的列建立索引
对于经常需要查询的列，建立索引可以大大提高查询效率。
对于经常需要排序或分组的列，建立索引可以加速这些操作。
在多表连接时，对连接条件中的列建立索引可以加快连接速度。
对于经常更新的列，建立索引可能会导致性能下降，因为每次更新都需要同时更新索引。
04
PART
物理结构优化
存储引擎选型标准
InnoDB
支持事务，具有行级锁定和外键约束，适用于高并发、数据完整性要求高的场景。
01
MyISAM
不支持事务和外键，具有较高的查询速度，适用于读多写少的场景。
02
NDB
支持高可用性和数据分布，适用于需要分布式存储和高可用性的场景。
03
根据数据范围选择合适的整数类型，如TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT。
根据实际需求选择CHAR、VARCHAR、TEXT、BLOB等类型，避免使用过长的字段。
选择DATE、TIME、DATETIME、TIMESTAMP等类型，确保日期和时间的准确存储。
使用ENUM类型可以限制字段的取值范围，提高查询效率。
字段类型与长度规范
整数类型
字符串类型
日期与时间类型
枚举类型
垂直分区
将表按字段分成多表，将热点字段、冷热数据分离，提高查询效率。
水平分区
将表按行分成多表，降低单表的数据量，提高查询性能。
复合分区
结合垂直和水平分区，将数据分到更多的表中，进一步提高查询效率。
分库分表
将数据分散到多个数据库和表中，降低单一数据库和表的压力，提高系统可扩展性。
分区与分表策略
05
PART
安全与性能保障
敏感数据加密机制
加密算法选择
选