数据库范式

数据库范式数据库范式•关系型数据库设计时是要遵循一定的规则的，尤其是数据库的设计范式。现简单介绍一下1NF（第一范式）、2NF（第二范式）、3NF（第三范式），另有第四范式和第五范式（第四范式和第五范式属于范式中的较高要求的范式）。1NF（第一范式）2NF（第二范式）3NF（第三范式）4NF（第四范式）5NF（第五范式）5NF4NFBCNF3NF2NF1NF各范式关系图第一范式（1NF）•在关系模式R中的每一个具体关系，如果每个属性值都是由不可分割的最小数据单位组成或者说每个属性的值必须是唯一的，则称R属于第一范式，换一句话说是指：在关系每个元组的所有属性上的值都必须是原子值，相反的凡具有集合属性或嵌套子关系的关系都不是第一范式；•例如：由“职工号”、“姓名”、“电话号码”组成的表（一个人可能有一个办公室电话和一个家庭电话号码），这时将其规范成为1NF有三种方法：•重复存储“职工号”和“姓名”。此时，关键字只能是“电话号码”。•“职工号”为关键字，“电话号码”分为“单位电话”和“住宅电话”两个属性。•“职工号”为关键字，但强制每条记录只能有一个电话号码。以上三个方法，第一种方法最不可取，按实际情况选取后面两种情况。非第一范式表姓名系书本书名编号价格张三计算机数据结构0000345物理0000134“书本”属性不是一个不可再分的原子属性，即他是由3个部分组成第二范式（2NF）•如果关系模式R为第一范式，并且R中每一个非主键属性完全依赖于R的某个候选关键字（通常为主键），即所有非主键列的值都完全信赖于主键列，则称关系R属于第二范式。•例如：在选课关系表SCI（SNO，CNO，GRADE，CREDIT）中，SNO为学号，CNO为课程号，GRADE为成绩，CREDIT为学分。由以上条件可知，关键字为组合关键字（SNO，CNO）。•在应用中使用以上关系模式有以下问题：•（1）数据冗余即数据重复，假设同一门课有40个学生选修，学分就重复40次。•（2）更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，否则会出现同一门课程学分不同的情况。•（3）插入异常，如计划开新课，由于没人选修，因此就没有学号关键字，只有学生选修后才能把课程和学分存入。•（4）删除异常，若学生已结业，从当前数据库删除选修记录。若某些课程新生尚未选修，则此门课程及学分记录将无法保存。•原因：非关键字属性CREDIT仅依赖于CNO，也就是说CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。解决方法：分成两个关系模式SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，在需要时再进行联接。解决方法：姓名编号读者类型书本编号编号书名书本类型日期张三0111教师0011物理TP2008张三0111教师4536英语YY2007李四0223学生9713企业管理CP2009…………………如上表，存在非主属性对关键字的部分依赖。那如何解决呢？如下：1.完全依赖于主关键字的非主属性：日期。2.不完全依赖的非主属性：姓名、读者类型依赖于编号；书名、书本类型依赖书本编号；根据这个分类，将上表关系拆分成以下三个表：姓名、读者类型、编号（表一）编号、书本编号、日期（表二）书本编号、书名、书本类型（表三）第三范式（3NF）属于第二范式，且表中的任何一个非主属性都不传递函数依赖于任何关键字，则为第3范式；如果关系模式R中的所有非主属性对于任何候选关键字都不存在传递依赖，则称关系R属于第三范式。即如果一个表中的任意三列A、B、C，存在着A决定B，且B决定C的情况，那么这个表就不属于第三范式，因为A可以通过传递依赖决定C，这时应该将传递依赖分解到两个表中。同时上表中的3个表都属于第3范式；所谓传递函数依赖，指的是如果存在“A—B—C”的决定关系，则C传递函数依赖于A。因此，满足第三范式的数据库表应该不存在如下依赖关系：关键字段—非主键字段x—非主键字段y假如学生关系表为Student（学号，姓名，年龄，所在学院，学院地点，学院电话），关键字为单一关键字“学号”，因为存在如下决定关系：（学号）—（姓名，年龄，所在学院，学院地点，学院电话）这个数据库表是符合2NF，但是不符合3NF，因为存在如下决定关系：（学号）—（所在学院）—（学院地点，学院电话）即存在非关键字段学院地点，学院电话对关键字段学号的传递函数依赖它会存在数据冗余，更新异常，插入异常，删除异常。将学生关系表分为如下两个表：学生：（学号，姓名，年龄，所在学院）学院：（学院，学院地点，学院电话）这样的数据库表是符合3NF，消除了数据冗余，更新异常，插入异常，删除异常。设有以下关系模式SNC（SNO，SN，CNO，SCORE），其中SNO：学生学号SN：学生姓名（无重名）SCORE：成绩我们可以判定该表有两个候选键（SNO，CNO）和（SN，CNO）则其函数依赖如下：SNO←→SN（SNO，CNO）→SCORE（SN，CNO）→SCORE唯一的非主属性SCORE对键不存在部分依赖，也不存在传递依赖，所以SNC属于第3范式；从另一个角度来说存在主属性对键的部分函数依赖，这样将造成关系SNC中存在较大的数据冗余，学生姓名的存储次数等于该生所选的课程数，从而引起修改异常。BCNF•若关系模式R是第一范式，且每个属性都不传递依赖于R的候选键。这种关系模式就是BCNF模式。即在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合鲍依斯-科得范式。•假设仓库管理关系表为StorehouseManage(仓库ID,存储物品ID,管理员ID,数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：•(仓库ID,存储物品ID)→(管理员ID,数量)•(管理员ID,存储物品ID)→(仓库ID,数量)•所以，(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：•(仓库ID)→(管理员ID)•(管理员ID)→(仓库ID)•即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。它会出现如下异常情况：(1)删除异常：当仓库被清空后，所有存储物品ID和数量信息被删除的同时，仓库ID和管理员ID信息也被删除了。(2)插入异常：当仓库没有存储任何物品时，无法给仓库分配管理员。(3)更新异常：如果仓库换了管理员，则表中所有行的管理员ID都要修改。把仓库管理关系表分解为二个关系表：仓库管理：StorehouseManage(仓库ID,管理员ID)；仓库：Storehouse(仓库ID,存储物品ID,数量)。这样的数据库表是符合BCNF范式的，消除了删除异常、插入异常和更新异常。四种范式之间的关系第四范式（4NF）•第四范式首先要求是第三范式，且在关系模式中，至多只有一个多值事实。所谓多值事实，就是指某个属性有若干个值，这些值由另一个属性的一个值决定。•例如，职工表（职工编号，职工孩子姓名，职工选修课程），在这个表中同一个职工可能会有多个职工孩子姓名。类似地，同一个职工也可能会有多个职工选修课程，即这里存在着两个多值事实，即不符合第四范式。如果要符合第四范式，则只需要将这个表分为两个表，使它们最多只有一个多值事实。职工表1（职工编号，职工孩子姓名），职工表2（职工编号，职工选修课程），此时职工表1和职工表2都只有一个多值事实，所以这是符合第四范式的。第五范式（5NF）•第五范式，如果在保证信息正确的前提下，每个表都不能拆分成两个或多个表（每个表都有一个主键，且是原表主键的真子集），则称此表属于第五范式。•例如，销售关系表（销售代理、制造公司、产品名称）就不符合第五范式，因为这此表可以分解成以下三个表：关系表1（销售代理、制造公司），关系表2（销售代理、产品名称），关系表3（制造公司，产品名称）。•第五范式的好处是可以减少数据重复，而且数据库中的数据量越大，其作用就越显著。