表的规范化（三大范式与实体完整性和引用完整性）

多表查询
在前面的例子中，每一个查询语句只针对一个表操作。其实在Oracle系统中，您所查询的数据可以来自多个表，即一个查询语句可以对多个表进行操作。
造成这一现象的主要原因是数据库的规范化（对Normalization）

把订单的所有数据放在一个表中：
订单号 商品号 商品名 商品描述 单价 供应商号 供应商名 ...
168268 2560 清凉牌 ... 0.20 234510 ...
2351 龙卷风牌 ... 0.10 ... ...
2354 万里香 ... 1.00 ... ...
168269 2560 清凉牌 ... 0.20 234510 ...
2351 龙卷风牌 ... 0.10 ... ...
上图并不是一个关系数据库的表。因为所有的关系数据库中的每一行都必须有一主键并且要满足实体完整性（Entity Integerity）。关系型数据库是不能含有重复组的。

主键：关系型数据库中某一列或者几列的组合；能唯一的标志关系数据库表中德尔任一行。
实体完整性：主键不包含控制，并且主键必须能唯一的标志任一行
订单号 商品号 商品名 商品描述 单价 供应商号 供应商名 ...
168268 2560 清凉牌 ... 0.20 234510 ... ...
168268 2351 龙卷风牌 ... 0.10 ... ... ...

我们再次发现，假如公司对2351的商品进行1000次订单，就要将2351的商品信息在表中重复1000次，出现错误的可能性大为增加，从而产生相同商品信息在不同行不一致。
数据的不一致性是由于相同数据的重复存放，即冗余造成的。数据的冗余不但会造成数据不一致，还会使得系统的维护更加困难，对系统的效率进行冲击。

如何减少数据的冗余呢？
上面所示的是一个第一范式（INF）的表。任何关系数据库的表都满足第一范式。
第一范式：
所有的键（列）都已定义；
没有任何重复组（Repeating Groups），换句话说，每行和每列的交汇处可以而且只能包含一个值，而不能包含一组值
所有的属性都依赖于主键

消除部分依赖
仔细观察上面的图可以知道，知道了一个商品的商品号就可以知道该商品的全部信息，即商品的其他部分信息只依赖于商品号。因为商品号只是主键的一部分，所以这种依赖关系也叫部分依赖。
部分依赖：只依赖于部分主键的依赖关系
我们可以将存在部分依赖关系的列提取出来重新生成一个表，同时把依赖列作为外键
订单号商品号 供应商号 供应商名 ...... Order表
商品号 商品名 商品描述 单价 ... Product表
现在只需要在Product表中存放一次一个商品的信息，而Product表中只有商品号在Order表中可重复存放多次。因此产生的数据的冗余已经大大地减少

外键（Foreign key）和引用完整性（Referential Integrity）
那么关系型数据库管理系统又是如何从多个表中找到用户所需的信息呢？使关系数据库工作的机制是控制冗余。
控制冗余：数据库中的表通过共享相同的键属性（列）把它们链在了一起。
waijian（Foreign Key）：它是关系数据库表中的某一列或者某几列的组合：它的值或者与另一个表中（有时也可能是同一个表中）的某一列（一般为主键Primary Key）相匹配，或者为空值。
引用完整性（Referential Integrity）：
外键必须或者为空值或者有相匹配的项
外键可以没有相对应的键属性，但不可以有无效的项

第二范式
消除重复组合部分依赖的表为第二范式的表。
第二范式的要求：
1、满足第一范式
2、不包含部分依赖

第三范式：
假设234510号供应商的信息要在Order表中重复上百次.然后在过程中该供应商一步一步发展，供应商的变化却会影响天上人间的Order表，因为表设计的有缺陷。供应商的信息不应该存在大多在本表中，我们观察发现它依赖于供应商号。供应商号不是主键，因此不属于部分依赖，那么它属于什么依赖呢？
传递依赖：一个或者多个属性依赖于非主键的属性。
我们将传递依赖的各个列提取出来，然后通过外键连接。这样表不包含重复组，也不包含部分依赖和传递依赖，这就是我们所说的第三范式
第三范式的要求：
满足第二范式
不包含传递依赖

 

简单总结：

不能重复：主键、实体完整性

去除重复行冗余：部分依赖、第二范式、外键、引用完整性

传递依赖：第三范式