数据库范式那些事

范式: 规范方式(表达式), Normal Format(NF), 是离散数学中一套数据的管理模式: 主要的目标是为了去除数据冗余, 实现数据的查询.

关系型数据库: 高效的存储和处理数据, 关系型数据库比较浪费空间.

所以关系型数据库引入了范式的概念: 能够尽可能的提升空间的利用率.

范式: 是一种类似W3C的一种既定规范, 但是不是强制要求.

范式: 就目前来说一共有6层: 从第一层到第六层,逐层严格: 若要满足下一层,必须满足上一层(想要满足第二层: 前提是第一层满足)

数据库中只需要遵循3层范式即可: 不需要严格到6层(效率相当低)

第一范式

第一范式: 1NF: 如果一张表的某个字段的数据, 在从表中取出来之后还需要进行额外的加工(查分)才能使用的话: 说明当前数据的存储不合理, 应该进行拆分后再分别存储. 将这种数据需要拆分才能使用的设计方式, 违背了第一范式: 数据字段必须具有原子性(不可再分)

讲师带课表

以上设计: 假设需要知道一个讲师的代课起始时间: 需要将代课时间字段数据取出来再进行拆分才能使用: 违背了第一范式

解决方案: 将代课时间进行拆分: 拆成开始和结束两个部分

第二范式

第二范式: 2NF, 如果一张表存在复合主键(多个字段构成), 但是表中的其他字段并不是完全依赖整个主键, 而只是依赖主键的部分(某个字段) , 这种时候, 该字段对主键的依赖就存在了部分依赖: 第二范式: 取消部分依赖.

讲师带课表

其中: 两个带P的组成了主键(复合主键)
但是: 性别不依赖主键, 只受讲师限制(只依赖讲师); 同样的教室依赖班级: 以上两种, 有字段依赖复合主键中的部分字段, 形成了部分依赖: 不满足第二范式.

解决方案: 取消复合主键, 就不再满足第二范式的基本需求, 不再可能出现部分依赖. 增加逻辑主键解决.

第三范式

第三范式: 3NF, 如果一张表中有一个字段,是依赖主键的, 但是又有另外一个字段不是直接依赖主键, 而是通过某个非主键字段依赖主键: 把这种通过非主键字段依赖主键的形式称之为传递依赖. 第三范式: 取消传递依赖.

讲师带课表

以上表中: 讲师和班级,代课时间,开始和结束时间都依赖主键ID(ID代表的是讲师和班级的复合主键): 性别是通过讲师依赖id, 教室是通过班级依赖id: 形成了传递依赖.

解决方案: 将这种存在传递依赖的字段全部单独取出形成一个新表,然后在需要使用的地方,使用新表的主键字段.

如果在考虑磁盘空间使用的情况下还要去保证效率: 有时候会为了选择效率, 而故意增加磁盘数据冗余.

逆规范化

逆规范化: 明明知道数据可以被查出来, 但是还是不采用查询方式,而是直接将数据写入到对应的表中.

在需要通过id进行查询的位置: 不使用ID而是直接使用对应的需要的字段数据(讲师名字)

虽然存储空间多了(数据冗余), 但是查询的时候可以直接查一张表就可以(效率提高)

数据库的合理设计: 在进行一效率和空间使用率的博弈.