数据库设计范式学习

一、三大范式
1NF:要有主键、列不可分
错误案例：person(personId,personInfo)
(1,11岁的女孩)
符合1nf:person(personId,age,gender)
(1,11,女)
总结：很直观的规范，第一要有主键，唯一的标识一条数据（数据都不能唯一标识，如何找到？如何使用？无法使用那就没有价值了）；
第二列不可分，个人觉得没有绝对的列不可分，必要时一列我还是要同时储存多种信息的（慎用）

2NF:满足1NF情况下，存在组合主键情况下，非主键字段不能部分依赖主键
错误案例：studentCourse(studentId,courseId,studentName,courseName)
(1001,40001,”zpeng”)
正确案例: studentCourse(studentId,courseId)
student(studentId,studentName)，course(courseId,courseName)
总结：错误案例中studentName,courseName大量重复存储，数据冗余。对于studentName,courseName这样的部分依赖字段信息，是否单独另起表更好呢？绝大数都是这样的。

3NF:（面煮好了，先吃起- -）
满足2NF的前提下，不存在传递依赖
错误案例：student(studentId,studentName,schoolId,schoolName)
正确案例：student(studentId,studentName,schoolId)
school(schoolId,schoolName)
总结：上面的错误例子，schoolName明显依赖于schoolId，这样设计schoollName信息大量冗余。大部分情况满足3NF都是好的，但物极必反，一切都要结合实际才是最适合的。

BCNF：在3NF的基础上，库表中任何字段对任一候选关键字段的传递函数依赖都不存在
错误案例：StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且管理员1—1仓库；仓库1—n物品。这个数据库表中存在如下决定关系：
　　(仓库ID, 存储物品ID) →(管理员ID, 数量)
　　(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)
即存在关键字段决定关键字段的情况，所以其不符合BCNF范式
正确案例：把仓库管理关系表分解为二个关系表：
　　仓库管理：StorehouseManage(仓库ID, 管理员ID)
仓库：Storehouse(仓库ID, 存储物品ID, 数量)