目录
一、关系数据库设计理论
函数依赖、范式和模式设计是关系数据库设计理论中的主要内容，其中函数依赖起到核心作用，范式用来描述数据库结构的标准化程度，不同的范式对应着不同级别的数据冗余和完整性约束。另外，关系数据库设计的关键是关系模式的设计。
二、关系模式的形式化表示
一个关系模式可以表示为一个五元组：R（U，D，DOM，F），其中R代表关系名称，即对应关系（表），U是属性的集合（列），D是属性的域（取值范围），DOM是属性向域的映射集合，即每个属性与其对应域之间的映射关系，F是属性之间的依赖关系集合（完整性约束条件）。
例如，下面是一个商品订单表的关系模式，对于一件商品相关信息有商品ID、商品名称、商品类别ID、订单价格、库存量和订单日期：
| 关系模式 | 含义 | 备注 |
|---|---|---|
| R | 关系名称 | ProductOrder |
| U | 属性 | ProductID、ProductName、CategoryID、Price、Stocks、OrderDate |
| D | 属性域 | 整数类型、字符串类型、日期类型 |
| DOM | 属性向域的映射集合 | 整数域、字符串域、日期域 |
| F | 属性之间的依赖关系集合 | … |
ProductID、CategoryID、Price、Stocks映射到整数域，ProductName映射到字符串域，OrderDate映射到日期域，属性之间的依赖关系集合中有ProductID为主键，另外还有其他完整性约束条件，例如，可以设置Price订单价格不得低于0元、OrderDate订单日期为有效日期格式等约束条件。
一般来说，五元组也可根据需要简化为R（U），例如，课程关系模式R（CID，CNAME，TID，TG，TO），其中属性分别为课程号、课程名称、教师工号、教师年级、教师办公室。
三、函数依赖
若X和Y都是属性集，X中每个值唯一确定Y中一个值，则称Y函数依赖于X，记为X→Y。若Y不函数依赖X，记为X⇸Y。函数依赖与属性之间的联系如下：
| X和Y之间联系 | 是否存在函数依赖 | 表示 |
|---|---|---|
| 一对一 | 存在 | X↔Y |
| 一对多 | 存在 | X→Y |
| 多对多 | 不存在 |
例如，下面两个表中，CategoryID是两个关系表的主键，同时也是表之间的外键。可知，每一个CategoryID（商品类别）都对应多个ProductID（商品ID），即一对多的关系，两个表存在函数依赖。
四、关系模式规范化
（一）规范化目的
低一级范式的关系模式通过模式分解转换为若干个高一级范式的关系模型的集合，即为规范化。关系模式规范化的目的有：
1、优化数据结构
2、减少数据冗余
3、提高查询性能（消除插入、删除和更新异常）
插入异常是指应该插入的数据未被插入，删除异常是指不该删除的数据被删除，更新异常是指需要更新多行数据才能完成对一个实体实例的完整更新。
（二）范式
范式是符合某一种级别的关系模式，即为不同程度的规范化要求设立不同的标准。各个范式的集合关系可以表示为：5NF⊂4NF⊂BCNF⊂3NF⊂2NF⊂1NF，其中最低的是第一范式（1NF），最高的是第五范式（5NF），依次级别增高。关系模型中的关系模式至少应该满足1NF，其是关系模式设计的基本前提。
1、第一范式和第二范式
1NF规定每个属性具有原子性，若每个属性不可再分，则该关系模型即为1NF；2NF要求每个非主属性完全依赖于主键，而不是主键的某一部分。若满足2NF，则一定满足1NF，但不一定满足3NF。
对于一个学校课程表的关系模式，有CourseID（课程ID）、CourseName（课程名称）、TeacherID（教师ID）以及TeacherName（教师姓名），设CourseID是主键，唯一地标识每门课程。首先，表中每个属性CourseID、CourseName、TeacherID以及TeacherName都是原子，无法再分，所以满足第一范式。另外，CourseName、TeacherID和TeacherName三者都是非主属性，且都完全依赖于CourseID，即每门课程都关联到唯一的课程名称、教师和教师姓名。所以，该关系模式满足第二范式，但不一定满足第三范式。若想满足第三范式，可以将关系模式进行模式分解，将教师信息（TeacherID和TeacherName）放在一个单独的关系中，然后通过外键关联到课程关系。
2、第三范式和BC范式
第三范式要求每个非主属性不依赖于其他非主属性。若满足3NF，则一定满足2NF；BCNF要求每个非主属性完全依赖于主键，而不是主键的某一部分。
对于一个员工工作信息的关系模式，有EmployeeID（员工ID）、DepartmentID（部门ID）以及Posts（职位），设EmployeeID和DepartmentID为主键，即联合主键，两者共同唯一标识每个员工的工作信息。首先，三个属性满足第一范式。非主属性Posts完全依赖于联合主键，而不是其部分，所以满足第二范式。另外，非主属性不能传递依赖于主键，其中Posts只直接依赖于联合主键，并没有传递依赖，所以满足第三范式。最后，Posts也是完全依赖于联合主键，所以满足BC范式。
（三）范式化过程
| 规范化 | 备注 |
|---|---|
| 1NF→2NF | 消除非主属性对码的部分函数依赖 |
| 2NF→3NF | 消除非主属性对码的传递函数依赖 |
| 3NF→BCNF | 消除主属性对码的部分函数依赖和传递函数依赖 |
| BCNF→4NF | 消除非平凡且非函数依赖的多值依赖 |
若只考虑函数依赖，BCNF的关系模式即可；若只考虑多值依赖，4NF的关系模式即可。
标签：关系,依赖,范式,模式,Server,关系数据库,SQL,主键,属性 From： https://blog.csdn.net/qq_43085848/article/details/137174213