数据库设计范式
什么是范式：简言之就是，数据库设计对数据的存储性能，还有开发人员对数据的操作都有莫大的关系。所以建立科学的，规范的的数据库是需要满足一些规范的来优化数据数据存储方式。在关系型数据库中这些规范就可以称为范式。
目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。
而通常我们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”
什么是三大范式：
第一范式：当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。
第二范式：如果关系模式R满足第一范式，并且R得所有非主属性都完全依赖于R的每一个候选关键属性，称R满足第二范式，简记为2NF。
第三范式：设R是一个满足第一范式条件的关系模式，X是R的任意属性集，如果X非传递依赖于R的任意一个候选关键字，称R满足第三范式，简记为3NF.
注：关系实质上是一张二维表，其中每一行是一个元组，每一列是一个属性
第一范式（1NF）：要求数据库表的每一列都是不可分割的原子数据项
举例说明：
在上面的表中，“家庭信息”和“学校信息”列均不满足原子性的要求，故不满足第一范式，调整如下：
可见，调整后的每一列都是不可再分的，因此满足第一范式（1NF）；
第二范式（2NF）：在1NF的基础上，非码属性必须完全依赖于候选码（在1NF基础上消除非主属性对主码的部分函数依赖）
第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关（主要针对联合主键而言）。
举例说明：
在上图所示的情况中，同一个订单中可能包含不同的产品，因此主键必须是“订单号”和“产品号”联合组成，
但可以发现，产品数量、产品折扣、产品价格与“订单号”和“产品号”都相关，但是订单金额和订单时间仅与“订单号”相关，与“产品号”无关，
这样就不满足第二范式的要求，调整如下，需分成两个表：
第三范式（3NF）：在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关。
举例说明
上表中，所有属性都完全依赖于学号，所以满足第二范式，但是“班主任性别”和“班主任年龄”直接依赖的是“班主任姓名”，
而不是主键“学号”，所以需做如下调整：
关系完整性约束
关系模型中有三类完整性约束：实体完整性、参照完整性、用户自定义完整性。
其中实体完整性和参照完整性是关系模型必须满足的完整性约束条件，被称为关系的两个不变性，应该由关系系统自动支持。
用户定义的完整性约束条件是应用领域需要遵循的约束条件，体现了具体领域中的语义约束。
实体完整性
若属性（指一个或者一组属性）A是基本关系R的主属性，则A不能取空值。
规则说明：
- 实体完整性规则是针对基本关系而言的。
- 现实世界中的实体是可区分的，即他们具有某种唯一性标识。
- 相应地，关系模型中以主码作为唯一标识。
- 主码中的属性即主属性不能取空值。如果主属性取空值，就说明存在某个不可标识的实体，即存在不可区分的实体，与第二条相互矛盾，因此，这个规则称为实体完整性规则。
参照完整性
外码：设F是基本关系R的一个或者一组属性，但不是关系R的码，K(S)是基本关系S的主码。如果F与K(S)相对应，则称F是R的外码，并称基本关系R为参照关系，基本关系S为被参照关系或是目标关系。
外码不一定要与相应的主码同名。
例：
学生（学号，姓名，性别，专业号，年龄）
专业（专业号，专业名)
若属性（或者属性组）F是基本关系R的外码，他与基本关系S的主码K(S)相对应，则对于R中每个元组在F上的取值要么取空值，要么等于S中某个元组的主码值。
用户自定义完整性
任何关系型数据库系统都应该支持实体完整性和参照完整性。这是关系模型所要求的。
除此之外，不同的关系数据库系统根据其应用环境的不同，往往还需要一些特殊的约束条件。用户定义的约束条件就是针对某一具体关系数据库的约束条件，它反映了某一具体应用所涉及的数据必须满足的语义要求。
例如：在学生关系中，要求学生不能没有姓名，学生课程成绩关系中要求成绩必须在0到100之间。
参考资料：
https://www.cnblogs.com/knowledgesea/p/3667395.html
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
