目录
一、键与相关属性的概念
1.超键：候选键与其他属性的组合。
2.候选键：候选键是最小的超键，能唯一一个标识元组。
3.主键：候选键可以有多个，选择一个作为主键。
4.主属性：包含在候选码中的属性称为主属性。
5.非主属性：不包含在任何候选码中的属性是主属性。
6.外键：是当前关系中的属性，也是另一个关系中的码（候选码）。
例子：
在这两张表中
超键：对于球员表，超键就是包括球员编号或身份证号的任意组合，如（球员编号）（球员编号、姓名）（身份证号，年龄）
候选键：就是最小超键，对于球员表就是球员编号或身份证号。
主键：就是从候选键中选择一个，对于球员表，可以是球员编号作为主键。
外键：球员表中的球队编号。
主属性：包含在候选键中的属性，对于球员表，球员编号、身份证号就是主属性；姓名、年龄、球队编号就是非主属性。
二、数据库第一范式
1.定义：表的每一个属性必须是原子性的，不可再拆分的。
2.例子：用户表的用户信息
改进为：
三、数据库第二范式
定义： 若关系是第一范式，且每一个非主属性完全函数依赖于任何一个候选码，该关系就满足第二范式，即消除非主属性对码的部分依赖。
例子：
1.（学号、课程号、成绩）学生成绩表中，学号和课程号是主键，成绩是完全依赖于它们的，因为学号不能决定成绩、课程号也不能决定成绩。
2.（球员编号、姓名、年龄、比赛编号、比赛时间、比赛场地）比赛表中，、候选码和主键都是(球员编号、比赛编号)， 但存在以下关系：
（球员编号） => （姓名、年龄）
（比赛编号） => 姓名、年龄）
四、数据库第三范式
定义：关系满足第二范式，且关系的非主属性之间不存在依赖，是独立的。即消除非主属性对码的传递依赖。
例子:
商品名称依赖于商品类别，不符合第三范式 。
应该拆成两张符合第三范式的表：
五、数据库BCNF范式
定义：任何主属性对于任何候选码不存在部分依赖。即消除主属性对候选码的部分依赖。
例子：
候选码：（仓库名、管理员） （仓库名、物品名）。
非主属性：数量。
显然满足第一、第二、第三范式。
但存在以下问题：
插入一个仓库，但没有商品、根据数据库实体完整性，表的主键不能为空，所以插入移仓。
更新仓库的管理员会更新多条数据。
如果仓库里的商品都卖空了，那么此时仓库名称和相应的管理员名称也会随之被删除。
问题在于：管理员只有仓库名决定，所以对候选码（仓库名、物品名）就是部分依赖。
那么拆表：
仓库表（仓库名，管理员）
库存表 (仓库名，物品名，数量）
六、数据库反范式
合理的增加表的冗余，达到尽可能少的表连接操作。
例子1：
商品表：
例子二:
此时我们想显示课程评论的学生姓名，那么我们必须连表查询，但数据量很大时，表连接操作十分耗时，所以我们可以在评论表中也加入学生昵称字段。（打破3BNF）。
反范式出现的问题：
反范式的适用场景
七、总结
在数据库表设计时，应该先遵守范式规则，如果设计出来的表存在性能问题再进行反范式化的设计。
先清楚规则再打破规则与不讲规则是两回事。
482
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
