说说数据库范式

1数据库设计范式（范式-数据库设计范式-数据库的设计规范）是符合某一种级别的关系模式的集合。他是数据库逻辑模型设计的基本理论。构造数据库必须遵循一定的规则。在关系数据库中，这种规则就是范式。关系数据库中的关系必须满足一定的要求，即满足不同的范式。
通过分解把属于低级范式的关系模式转换为几个属于高级范式的关系模式的集合。这一过程称为规范化(范式化：Normalize)。

1.相关概念： 
•实体（entity）：就是实际应用中要用数据描述的事物，一般是名词。 
•字段（fields）：就是一项数据，也就是我们平常所说的“列”。

•记录（record）：一个实体的一个实例所特有的相关数据项的集合，也就是我们平 常所说的“行”。

•键（key）：可唯一标识一条记录的一个字段或字段集，有时翻译为“码”。

•主键（primary key）：用于唯一标识一个表中的一条记录的键。每个主键应该具有下列特征： 1. 唯一的。 2.最小的（尽量选择最少键的组合）。 3.非空。 4.不可更新的（不能随时更改） 
•外键（foreign keys）：对连接父表和子表的相关记录的主键字段的复制。

•依赖表（dependent table）：也称为弱实体（weak entity）是需要用父表标识的子表。

•关联表（associative table）：是多对多关系中两个父表的子表。

•实体完整性：每个表必须有一个有效的主键。

•参照完整性：没有不相匹配的外键值。

•真子集:如果A是B的子集，并且B中至少有一个元素不属于A，那么集合A叫做集合B的真子集。

•函数依赖：设R(U)是一个属性集U上的关系模式，X和Y是U的子集。若对于R(U)的任意两个可能的关系r1、r2，若r1[x]=r2[x],则r1[y]=r2[y]，或者若r1[x]不等于r2[x],则r1[y]不等于r2[y]，称X决定Y，或者Y依赖X。即：在一个关系模型中一个或一组属性的值可以决定其它属性的值，则“其他”属性依赖于该（一个或一组）属性。
例子：描述一个学生的关系，可以有学号(SNO),姓名(SNAME),系名(SDEPT)等几个属性。由于 一个学号只对应一个学生，一个学生只在一个系学习。因此当学号确定之后，姓名和该学生所在系的值也就唯一被确定了，称SNO 函数决定SNAME 和SDEPT，或者说SNAME，SDEPT 函数依赖于 SNO，记为：SNO -> SNAME， SNO -> SDEPT。

•完全函数依赖：在R(U)中，如果Y函数依赖于X（X->Y）,并且对于X的任何一个真子集X'，都有Y不函数依赖于X'(X'!->Y)， 则称Y对X完全函数依赖。否则称Y 对X 部分函数依赖。
即：在一个关系中，若某个非主属性数据项(Y)依赖于全部关键字(X)称之为完全函数依赖。 否则称Y对X部分函数依赖。
例子：假设一个学生有几个属性 SNO 学号 SNAME 姓名 SDEPT 系 SAGE 年龄 CNO 班级号 G 成绩 对于(SNO,SNAME,SDEPT,SAGE,CNO,G)来说，G 完全依赖于(SNO, CNO), 因为 (SNO,CNO)可以决定G，而SNO 和CNO 都不能单独决定G。 而SAGE部分函数依赖于(SNO,CNO),因为(SNO,CNO)可以决定SAGE，而单独的SNO 也可以决定SAGE。

•传递函数依赖： 在R(U)中，如果X->Y, Y->Z, 则称Z对X传递函数依赖。

•候选键 (又称：候选主键,候选码，候选关键字,码，candidate key)： 设K是一个R(U)中的属性或属性集合(注意可以是属性集合，也即多个属性的组合)，若K完全函数确定U，则K为R的候选键(Candidate key)。即：能够确定全部属性的某个属性或某组属性（每一行数据里的值都不相同，就像自动增长的id一样），称为候选键。

•主属性：包含在任何一个候选键中的属性，叫做主属性(Prime attribute),不包含在任何候选键中的属性称为非主属性或非键属性或非关键字段。
例子： 在(SNO, CNO, G)中，SNO 和CNO 这俩合起来就是一个候选键，因为每个元组只要确定了SNO和CNO，则其它所有属性都可以根据SNO和CNO来确定。而SNO和CNO就都是“主属性”，G 是“非主属性”，并且只能选择(SNO, CNO) 作为主键。 在(SNO,SDEPT, SNAME)中，SNO 是一个候选键，因为只要SNO 确定了，其它所有属 性也都确定了，如果保证没有重名的话，则SNAME 也是一个候选键，于是可以选SNO 或 者SNAME 之一作为候选键。如果不能保证没有重名，就不能把SNAME 当成候选键，于是就只有SNO能够做主键。

2.数据库设计范式： 
在数据仓库的模型设计中目前有：第一范式（1NF），第二范式（2NF），第三范式（3NF），BC范式（BCNF），第四范式（4NF），第五范式（5NF），6个范式之间的关系式递阶，即：如果只满足第一个条件,则称为第一范式;如果满足前面两个条件,则称为第二范式,依此类推。因此,各级范式是向下兼容的。 
在目前的数据库设计中一般采用第三范式。

•第一范式（1NF）：
定义：一个关系模式R的所有属性都是不可分的基本数据项（具有原子性，列不可分割)。 
目的：消除组中的重复，也就是说列中是否存储了其他列中的信息。
消除：拆分字段。
事例：学生(姓名,性别,地址)    ----(因为地址可以再拆分为“省,市,县”)

•第二范式（2NF）：
定义：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码(完全依赖所有主键，没有部分依赖)。 
目的：消除部分依赖列，也就是说是否有依赖于一部分主键的列。
事例：学生(姓名,性别,年龄,语文老师姓名)  --(因为“语文老师姓名”列不是完全函数依赖于键码)
•第三范式（3NF）：
定义：关系模式R属于第二范式，且每个非关键属性不能依赖于任一候选关键属性的传递函数依赖(没有传递依赖)。 
目的：消除非主属性对主属性的传递依赖，是否有依赖于非主键的列。
事例：订单详情表(订单id,下单时间,商品编号，商品名称)   --(因为“商品名称”通过“商品编号”传递依赖)。

•BC范式（BCNF）：
定义：关系模式R属于第三范式，关系模型中所有的属性（包括主属性和非主属性）都不传递依赖于任何候选关键字。
目的：消除任何属性对码的传递依赖与部分依赖
事例：订单详情表(订单id,下单时间,商品编号，供应商编号)   --(因为“供应商编号”通过“商品编号”传递依赖)。

•第四范式（4NF）：
定义：设R(U)是属性集U上的一个关系。X、Y、Z是U的子集，且Z=U-X-Y。关系R(U)中多值依赖X→→Y成立，当且仅当对R(U)的任一元组r，给定一对(x,z)值，有一组y的值，这组值仅仅取决于x值（记为X→→Y)，而与z值无关。
说明：关系模式R属于第三范式，且表中不能包含一个实体的两个或多个互相独立的多值因子(非主属性不应该有多值)。
目的：消除相互独立的多值情况（不允许冗余的多对多关系）。
消除：建立模型，将实际情况下需要多值的属性存储为单一值。
事例：关系表{系名、教师名、学生名}，  --(因为存在多值依赖即：系名→→教师名；系名→→学生名，应拆分为:关系表1{系名、教师名};关系表2{系名、学生名})。

•第五范式（5NF）：
定义：关系模式R属于第三范式，且表必须可以分解为较小的表，除非那些表在逻辑上拥有与原始表相同的主键。
目的：消除由于多值依赖而造成的更新异常问题。
消除：将所有的三元关系都分解为二元关系
事例：R={A,B,C}   如果表的各列是两两之间多对多的关系，则按照第五范式的思想，应该建立三张表，每张表有之前表的两列信息。即R={A,B} ；R={B,C} ；R={A,C}

3.范式的优缺点：

使用范式的主要目的是为了减少数据冗余，消除插入异常，更新异常，删除异常，另外从程序设计的角度范式把数据模式做到了高内聚低耦合让数据组织的更加和谐。在数据库设计中应尽量满足最高范式，但是应用的范式登记越高，查询时需要连接的表就越多，这样会增加了查询的复杂度，降低了数据库查询性能，为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到空间换时间的目的。