范式，第一，第二，第三，第四，第五范式，BC范式

规范化的程度（如先前的博客所述）不同，因此存在许多范例. 范例是设计必不可少的知识. 如果不了解该范式，就不可能设计出高效而优雅的，甚至是错误的. 教科书中的定义相对抽象，不是很直观，也不容易理解. 绝对不值得回味.

关系是已知的，让我们再次了解范式. 范式是关系关系模型的标准化，从规范化的松散到严格，分为不同的范式，通常使用第一个范式. 第二范式，第三范式和BC范式. 该范例基于功能依赖性.

如果表中某个字段Y的值由另一个字段或一组字段X的值确定，则说Y函数取决于X.

让X和Y为关系R的两个属性集. 当R中任意两个元组的X属性值随时相同时，它们的Y属性值也相同，则X函数确定Y，或者Y函数取决于X.

3. 普通功能依赖项

当关系中的属性集Y是属性集X的子集（Y⊆X）时，存在函数依存关系X→Y，即，一组属性函数确定了其所有子集. 这种函数依赖称为琐碎的函数依赖.

4. 非平凡的功能依赖性

当关系中的属性集Y不是属性集X的子集时，存在功能依赖关系X→Y，则此功能依赖关系称为非平凡功能依赖关系.

5. 完全的功能依赖性

让X和Y是关系R的两个属性集，X'是X的真正子集，存在X→Y，但是对于每个X'，都有X'！→Y，那么说Y是完全依赖于功能的X.

6. 一些功能依赖性

让X和Y是关系R中的两组属性，其中X→Y存在，并且如果X'是X的真子集，并且X'→Y存在，则函数的Y部分取决于X.

7. 传递函数依赖性

让X，Y，Z是关系R中的不同属性集. 如果存在X→Y（Y！→X），Y→Z，则Z的传递函数就取决于X.

属性之间存在三个关系，但并非每个关系在功能上都是相关的. 假设R（U）是属性集U上的关系模式，而X和Y是U的子集:

●如果X与Y之间存在1: 1关系（关系），例如学校与校长之间是1: 1关系，则存在功能依赖关系X→Y和Y→ X.

●如果X和Y之间存在1: n关系（一对多关系），例如年龄和姓名之间是1: n关系，则存在Y→X的功能依赖性.

●如果X和Y之间存在m: n关系（多对多关系），例如学生和课程之间的m: n关系，则X和Y之间没有功能依赖性.

编辑

例如: 学生（Sno，Sname，Ssex，Sage，Septept）

假设不允许重复的名称，则有:

Sno→Ssex，Sno→Sage，Sno→Sept，

Sno←→Sname，Sname→Ssex，Sname→贤哲

名称→部门

但是Ssex-\→圣人

如果X→Y，并且Y→X，则记录为X←→Y.

如果Y不依赖于X，则记录为X － \→Y.

在关系模型R（U）中，对于U的子集X和Y，

1. 如果X→Y，但Y不是X的子集，则X→Y是非平凡的函数依赖项

示例: 在关系SC（Sno，Cno，Grad）中，

非平凡的功能依赖性: （Sno，Cno）→等级.

2. 如果X→Y，但是Y是X的子集，那么X→Y是一个琐碎的功能依赖项

普通功能依赖项: （Sno，Cno）→Sno，（Sno，Cno）→Cno.

3. 如果x→y并且存在x的真实子集x1使得x1→y，则y部分取决于x.

示例: 在学生表之间的关系（学生人数，姓名，性别，班级，年龄），

部分功能依赖性: （学生编号，姓名）→性别，学生编号→性别，因此（学生编号，姓名）→性别是部分功能依赖性.

4. 如果x→y并且x的任何真子集x1没有x1→y范式，则说y完全取决于x.

示例: 在成绩表的关系中（学生人数，课程编号，成绩），

完全的功能依赖性: （学生编号，课程编号）→等级，学生编号-\→等级，课程编号-\→等级，因此（学生编号，课程编号）→等级完全是功能依赖性.

5. 如果x→y和y→z，且y- \→x，则存在x→z，这种功能依赖性称为传递函数依赖性.

示例: 关系S1（学生编号，部门名称，部门主管），

学生编号→部门名称，部门名称→部门负责人和部门名称-\→学生编号，部门负责人-\→部门名称，因此学生编号→部门负责人取决于转移函数.

应通过了解公司的数据项和内部规则（在不同公司之间有所不同）来确定特定的功能依赖性，并且基于表内容的功能依赖性可能不正确.

关系有六种类型，一，二，三，四，五和BC. 满足最低要求的范例是第一个范例. 在第一个范式的基础上范式，那些进一步满足更多要求的人称为第二个范式，其余的范式通过类推推导. 通常，只需要满足第三范式.

如果关系模式R是第一个普通模式，则R的每个关系r的属性都是原子项，并且是不可分的.

1NF是关系模型应具有的最低条件. 如果设计不能满足第一个范式，则不能将其称为关系. 关系设计研究的关系归一化是在1NF上进行的.

如果关系模式R为1NF，并且每个非主要属性完全取决于候选构造，则R被称为第二范式.

第二范式所要满足的条件: 首先，必须满足第一范式，其次，每个非主属性必须在功能上完全依赖于候选键或主键. 也就是说，每个非主属性都由整个主键功能确定，而不能由部分主键确定.

第二范式（2NF）: 符合1NF，并且非主要属性完全取决于代码. （候选代码中的主要属性也可能是多个. 如果不能将主属性单独用作候选代码，那么它就无法确定任何非主要属性.

什么样的例子不适合第二范式？

以教育管理系统为例.

如果学生任命一名老师，一本教科书，一间教室，一个时间，然后学生上课，该如何设计？

已建立以下关系:

（学生，课程）->教室；

（学生，课程）->老师；

（学生，课程）->教师头衔；

（学生，课程）->教科书；

（学生，课程）->上课时间；

可以得出结论，（学生，课程）是一个代码.

另一个: 课程->教科书；

发生这种情况时，第二个范式不满足.

解决方案: 分解. 执行投影分解:

如果关系模式R为2NF，并且关系模式R中的所有非主要属性（U，F）对任何候选关键字都不具有传递依赖关系，则关系R被称为属于第三范式.

第三范式（3NF）;满足2NF，并消除了传递依赖.

上面的图片与2NF一致，但是存在传递依赖（老师->老师的职位. 老师必须能够确定老师的职位）.

解决方案: 分解. 投影分解:

第四范式: 必须删除同一表中的多对多关系.

第五范式: 从最终结构重新建立原始结构.

BC范式（BCNF）: 符合3NF，并且main属性不依赖于main属性. 如果关系模式R属于第一范式，并且每个属性未通过键码，则R属于BC范式.

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/jisuanjixue/article-240506-1.html