标签：一个 info 科学 属性集 不能 不可 遵从 ali ima
1、关系数据库规范化理论
为使数据库设计的合理可靠、简单实用，长期以来，形成了关系数据库设计理论，即规范化理论。
完全函数依赖：在一个关系中，若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。
比如：有一个表，有如下属性：学生ID，学生姓名，所修课程ID，课程名称，成绩
完全依赖：(学生ID，所修课程ID)→成绩
成绩既不能单独依赖于学生ID，也不能单独依赖于所修课程ID，因此成绩完全函数依赖于关键字。
(学生ID，所修课程ID)→学生姓名
部分依赖：学生ID→学生姓名
学生姓名可以依赖于关键字的一个主属性——学生ID，因此学生姓名部分函数依赖于(学生ID，所修课程ID)。
2）平凡函数依赖和非平凡函数依赖
平凡函数依赖：当关系中属性集合Y是属性集合X的子集时，存在函数依赖X→Y，即一组属性函数决定它的所有子集，这种函数依赖称为平凡函数依赖。
例如：在在关系学生课程表SC(学生号Sno,课程号 Cno,成绩 Grade)中，
(Sno, Cno) → Sno ，(Sno, Cno) → Cno
非平凡函数依赖：当关系中属性集合Y不是属性集合X的子集时，存在函数依赖X→Y，则称这种函数依赖为非平凡函数依赖。
例如：(Sno, Cno) → Grade
3）传递函数依赖
传递函数依赖：设X,Y,Z是关系R中互不相同的属性集合，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。
例：关系S1(学号，系名，系主任)
学号 → 系名，系名 → 系主任，并且 系名 -\→ 学号，所以 学号 → 系主任 为传递函数依赖
范式是数据库设计中一个重要的过程，通过它可以优化数据库设计，避免一些问题，可以减少数据冗余，可以改进数据库整体组织，可以增强数据的一致性，可以增加数据库设计的灵活性。因此，在确定设计数据库之前，还需对数据库中的表进行范式处理，以确保数据库遵从适当的范式，从而使设计的数据库更加规范。
目前关系数据库有6种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。满足最低要求的是第一范式（1NF）。在第一范式的基础上满足更多要求的范式称为第二范式（2NF），其余的范式以此类推。一般来说，数据库只需要满足第三范式（3NF）即可。
如果关系模式R的每个关系r的属性都是不可分的数据项，那么就称R是第一范式的模式。第一范式是设计数据库表的最低要求，其最主要的特点是实体的属性不能再分，映射到表中，就是列（或字段）不能再分。
即：一个表中的列是不可再分的（即列的原子性）。
如表1.2，联系范式，对于学号‘1001’学生来说，‘联系方式’列包含电话和邮箱，可以再分，不符合第一范式要求。
如表1.3，列不可再分，符合了第一范式要求。
如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。
如表1.3，姓名和选修课有对于关系，但是姓名和教材没有对应关系，选修课程和教材有对对应关系，从而该表不符合第二范式标准。
将表修改后如表1.4和1.5，符合第二范式标准。
如果关系模式R是2NF，且关系模式R（U，F）中的所有非主属性对任何候选键都不存在传递依赖，则成关系R是属于第三范式的模式。
如表1.6满足2NF，但是知道班级后必然能知道该学生 属于哪个系，所以存在传递依赖，不符合3NF规范，所以讲班级和系别属性拆分如表1.7,和1.8，从而符合3NF标准。
| 学号 | 姓名 | 班级 | 系别 |
| 1001 | 张三 | 计算机科学与技术1班 | 计算机系 |
| 1002 | 李四 | 会计1班 | 经管系 |
| 学号 | 姓名 | 班级 |
| 1001 | 张三 | 计算机科学与技术1班 |
| 1002 | 李四 | 会计1班 |
| 班级 | 系别 |
| 计算机科学与技术1班 | 计算机系 |
| 会计1班 | 经管系 |
三大范式只是一般设计数据库的基本理念，可以建立冗余较小、结构合理的数据库。如果有特殊情况，当然要特殊对待，数据库设计最重要的是看需求跟性能，需求>性能>表结构。所以不能一味的去追求范式建立数据库。
标签：一个 info 科学 属性集 不能 不可 遵从 ali ima
原文地址：https://www.cnblogs.com/xhbJava/p/11080405.html
