解析范式(1NF-4NF)

标签：col   模式   aaa   复合   表数   strong   定义   上海   ext   

一、1NF

1.1 1NF的定义：

　　关系数据库中的关系是要满足一定要求的，满足不同程度要求的为不同的范式。满足最低要求是第一范式(1NF)，1NF的定义如下：

　　　　1NF：关系中的每一个分量必须是一个不可分的数据项。

　　通俗地说，第一范式就是表中不允许有小表的存在。比如，对于如下的员工表，就不属于第一范式：

员工表

　　上表中，出现了属性薪资又被分为基本工资和补贴两个子属性，就好像表中有分割了一个小表，这就不属于第一范式。如果将基本工资和补贴合并，那么该表符合1NF。

1.2 1NF存在的问题；

　　1NF是最低一级的范式，范式程度不高，存在很多的问题。比如用一个单一的关系模式学生来描述学校的教务系统：

　　学生(学号,学生姓名,所在系,系主任姓名,课程号,成绩)

学生表

　　假如选定学号为主键，这个表满足第一范式，但是存在如下问题：

　　·数据冗余：

　　　　一个系有很多的学生，同一个系的学生的系主任是相同的，所以系主任名会重复出现。

　　·更新复杂：

　　　　当一个系换了一个系主任后，对应的这个表必须修改与该系学生有关的每个元组。

　　·插入异常：

　　　　如果一个系刚成立，没有任何学生，那么这个无法把这个系的信息插入表中。

　　·删除异常：

　　　　如果一个系的学生都毕业了，那么在删除该系学生信息时，这个系的信息也丢了。

二、2NF

2.1 2NF的定义：

　　2NF的定义如下：

　　　　如果关系R属于1NF，且每一个非主属性完全函数依赖于任何一个候选码，则R属于2NF。

　　通俗地说，2NF就是在1NF的基础上，表中的每一个非主属性不会依赖复合主键中的某一个列。

　　按照定义，上面的学生表就不满足2NF，因为学号不能完全确定课程号和成绩(每个学生可以选多门课)。将学生表分解为：学生(学号,学生姓名,系编号)，系(系编号,系名,系主任)，选课(学号,课程号,成绩)。每张表均属于2NF。

　　新定义一张表：销售表(产品id,地区id,价格,产品名)，同一个产品在不同地区价格不同。这个表就不属于2NF，因为非主属性产品名不是完全函数依赖于主键，而是完全依赖于产品id，即表中存在非主属性对主键的部分依赖。将销售表分解：产品(产品id,产品名)，销售表(产品id,地区id,价格)。每张表均属于2NF。

2.2 2NF存在的问题：

　　下面举例说明2NF存在的相应问题。

　　对于公司里的员工管理，每个员工只能属于一个部门，每个部门可以有多个员工，定义如下关系模式：

　　员工管理表(员工id,员工名,所属部门id,部门经理);

　　对应的表：

　　存在的问题：

　　1、删除异常：

　　　　如果某个部门的人都跳槽了，那么在删除这些员工的同时也丢失了这个部门的信息。

　　2、修改复杂：

　　　　如果一个员工换了一个部门，不但要修改所属部门，还要修改部门经理这个属性列。

　　3、插入异常：

　　　　如果公司新成立了一个部门，但是目前没有招收员工，那么这个部门信息也无法插入到这个表中，因为没有主键。

三、3NF

3.1 3NF的定义：

　　3NF的定义：在满足1NF的基础上，表中不存在非主属性对码的传递依赖。也就是说表中非主属性不会间接地依赖于码。

　　如上面的员工管理表就不属于3NF，因为非主属性部门经理依赖于所属部门，所属部门依赖于员工id，即部门经理传递依赖于员工id。将员工管理表分解：员工管理(员工id,员工名,部门名)，部门(部门名,部门经理)。则每张表均属于3NF。

3.2 3NF存在的问题：

　　现在有这样的一个场景：对于一个工程(ENO)的实施，每个工程需要多个零件，每个供应商(SNO)只生产一个零件(PNO)且受工厂规模所限只能同时供应一个工程，每个工程使用的同一个零件都来自同一个生产商。

　　定义关系模式：SPE(SNO,PNO,ENO)。

SPE表

　　上表中存在如下函数依赖：

　　　　(ENO,PNO)→SNO

　　　　(ENO,SNO)→PNO

　　　　SNO→PNO

　　SPE是属于3NF的，因为根据定义，表中不存在非主属性对码的传递依赖和部分依赖。但是这张表存在如下的问题：

　　1、插入异常：

　　　　如果有一个新的工厂建立了，但是这家工厂还没有接到任何订单，那么无法将这个工厂信息插入到SPE中，因为缺少了主属性ENO。

　　2、删除异常：

　　　　如果某个供应商只给一个工程提供零件，现在这个工程不再需要这个零件了。那么PNO就要删除，而PNO是主属性，整个元组都被删除了，这样就丢失了一个供应商信息。

四、BCNF

4.1 BCNF的定义：

　　BCNF比3NF更进一步，可以认为是扩充的3NF，其定义如下：

　　　　在第一范式的基础上，若关系R中的每一个决定因素都必含有码，则关系R属于BCNF。

　　很显然，上面的SPE表不属于BCNF，因为SPE中存在一个决定因素SNO，SNO不含有码。将SPE表分解：SP(SNO,PNO)，SE(SNO,ENO)。则每张表均属于BCNF。

4.2 BCNF存在的问题：

　　仍以上面的工程实施场景为例：假设每个供应商可以生产多个零件，可以供应给多个工程，一个工程需要多个零件，但同一个工程的同一个零件必须来自同一个供应商。

　　那么关系SPE(SNO,PNO,ENO)对应的表数据可能是如下：

SPE表

　　此时表SPE存在如下的函数依赖：

　　　　(PNO,ENO)→SNO

　　根据BCNF的定义，此时表SPE属于BCNF。但是这样的关系模式仍具有不好的地方：数据冗余度太大。假如供应商S3生产了n个零件，每个零件供应给m个工程，那么显然S3要在表中重复m*n次。

五、4NF

5.1 4NF的定义：

　　关系模式R属于1NF，对于R中的每一个非平凡多值依赖X→→Y，X都含有码，则R属于4NF。

　　通俗地说，对于有三个属性的表，给定属性A一个值，剩余两个列之间不存在多对多的关系。例如，在上面的SPE表中，给定SNO=S1，PNO和ENO之间很明显存在多对多的关系，故上表是不属于4NF的。

　　根据4NF的定义可知，4NF所允许的非平凡的多值依赖实际上就是函数依赖，4NF就是消除表中的非平凡多值依赖关系。

5.2 4NF存在的问题：

　　一般地，4NF属于规范程度比较高的范式了。但是考虑到连接依赖的话，4NF中也仍存在数据冗余，插入、修改、删除异常等问题。如果消除了4NF中的连接依赖，则达到了5NF的关系模式。

六、对范式的学习总结：

　　如果只考虑函数依赖，那么BCNF范式最彻底，已消除插入和删除的异常。对比3NF，其不彻底性表现在表中可能存在主属性对码的部分依赖和传递依赖。

　　如果考虑到多值依赖，那么4NF范式是规范程度最高的。但4NF中可能存在连接依赖的关系，而5NF可以消除连接依赖。

　　在数据库中，有时并不是规范化程度越高越好。因为范式越高，产生的表就越多，一个简单的查询就可能涉及到多张表的关联。一般地，数据库中的表都在3NF。

解析范式(1NF-4NF)

标签：col   模式   aaa   复合   表数   strong   定义   上海   ext   

原文地址：http://www.cnblogs.com/jiang-jt/p/7680625.html