MySQL-数据库设计规范
1、范式
1.1、概述
- 在关系型数据库中，关于数据表设计的基本原则、规则就称为范式
- 常见六种范式，按照范式级别由低到高如下所示：
- 第一范式
- 第二范式
- 第三范式
- 巴斯范式
- 第四范式
- 第五范式
1.2、键和相关属性
- 范式的定义会用法主键和候选键，数据库中的key由一个或者多个属性组成。
- 常用键和属性定义如下：
- 超键：能唯一标识元组的属性集
- 候选键：如果超键不包括多余的属性，则超键就为候选键
- 主键：用户可以从候选键中选择一个作为主键
- 外键：父子关系表中存在
- 主属性：包含在任意候选键中的属性
- 非主属性：与主键相对，指的是不包含在任何一个候选键中的属性
2、三范式
2.1、第一范式
- 主要是确保数据表中每个字段的值必须具有原子性，每个字段的值为不可再次拆分的最小数据单元
- 属性的原子性是
主观的
2.2、第二范式
- 在满足第一范式的基础上，还要满足数据表中的每条记录都是可唯一标识的。
- 所有非主键字段必须完全依赖主键，不能只依赖主键的一部分
2.3、第三范式
- 建立在第二范式的基础上，确保数据表中的每一个非字段主键和主键字段直接相关
- 要求数据表中的所有非主键字段不能依赖于其他非主键字段，非主键属性直接必须相互独立
3、BCNF（巴斯范式）
- BCNF是对第三范式（3NF）的进一步规范， 旨在消除数据依赖性问题，确保数据的一致性。
- 在BCNF中，除了满足第三范式的所有条件外，还要求：对于关系模式R中的每个非平凡的函数依赖X→Y，X必须是R的超键。这意味着，如果在关系R中存在一个属性（X），它决定了另一个属性（Y），那么X必须是R的候选键，而不仅仅是超键。
- 候选键是可以唯一标识关系中元组的最小属性集合。超键是可以唯一标识元组的属性集合，而不一定是最小的。
- BCNF的要求确保了数据结构的高度规范化，减少了数据冗余和更新异常的可能性
- 达到BCNF可能会导致关系模式的进一步分解，从而增加了数据库设计的复杂性。
- 在实际设计中，需要权衡范式化和性能之间的关系，并根据具体情况进行设计决策。
4、第四范式
- 多值依赖
- 多值依赖： 即属性之间的一对多的关系，记为K→→A
- 函数依赖 ：事实上是单值依赖，所以不能表达属性值之间的一对多关系
- 平凡的多值依赖：全集U= K+A，一个K可以对应于多个A，即K→→A。此时整张表就是一组一对多的关系
- 非平凡的多值依赖：全集U=K+A+B，一个K可以对应于多个A，也可以对应多个B，A与B是相互独立的，即K→→A，K→→B，整张表由多组一对多的关系
5、第五范式、域键范式
- 在满足第四范式的基础上，消除了不是由候选键所蕴含的连接依赖
- 如果关系模式R中的每一个连接依赖均由R的候选键所隐含，则称此关系模式符合第五范式。