关于表的规范化(doc 17页).doc

规范化：满足第一范式是表的最低要求，不满足第一范式要求的数据库（表）就不能称之为关系数据库。在此基础上满足更高要求的称为第二范式，简记为2NF，其余依此类推，还有第三范式（3NF）、BC范式（BCNF）、第四范式（4NF）、第五范式（5NF）。BCNF可以看作是修正了的第三范式。把表从低范式，通过投影运算转换成若干高一级范式的过程，叫做表的规范化。一般地说，表满足的范式级别越高，设计的表越是规范，表的质量越高，数据的冗余度越小，共享性越高，所占的存储空间越少，并将数据的不一致性减少到最低程度，这也是对表进行规范化的目的。但是，高范式的数据库查询起来比较复杂。所以，不应一味追求高范式，一般满足第三范式或BC范式就可以了二、表的规范化1、第一范式（1NF）如前所述，第一范式要求表的每一个字段都是不可再分的最小单位。例1：学生（学号，姓名，学院，地址，选修课程成绩（课程号，课程名，成绩）表数据如下：学号姓名学院地址选修课程成绩（课程号，课程名，成绩）9901张丽管理管201C001，高等数学，909901张丽管理管201C002，英语，809901张丽管理管201C003，计算机，669902李锋电子电101C004，法律，78表一 不满足第一范式的表显然，这样的表是不满足第一范式的。因为选修课程成绩字段还可分为3个字段即（课程号，课程名，成绩）。如果不把它进行规范化，即转换成满足第一范式的表，将会产生很多问题，如：删除异常，即本来只想删除成绩的，不得不把课程号和课程名也删除了！转换的方法就是把可以拆分的字段进行拆分，即把选修课程成绩分解成3个字段：课程号，课程名，成绩。变成下面满足第一范式的表：学号姓名学院地址课程号课程名成绩9901张丽管理管201C001高等数学909901张丽管理管201C002英语809901张丽管理管201C003计算机669902李锋电子电101C004法律78表二 满足第一范式的表2、第二范式（2NF）一个关系应满足1NF是最起码的条件。但是，仅满足1NF的关系还可能存在一些问题。例2：表二中存在以下的问题：l 问题1：数据冗余度大。张丽选几门课程，都必须输入所有几个她的相关信息，同时，如果有几千个人选修高等数学课，就得输入几千个“高等数学”。如果要修改“高等数学”这个课程名称，对于几千个课程名中，只要漏改一个，将造成数据的不一致性。l 问题2：删除异常。我们知道，这个表中的关键字为学号和课程号，它们不能为空值，而当李锋退学时，不可能只删除李锋的学号和姓名，只能删除了李锋的整条记录，这时相应的课程号为C004的法律也被删除，如果这个表中只有李锋一人选法律课，该记录删除后，下次将无法查询法律课的课程号。l 问题3：插入记录异常。与删除异常相似，如果李锋刚入学，还没有选修任何一门课程，无法知道他选修的课程号，而课程号为关键字，不能为空，因此，李锋这个记录也不能输入。造成出现这些问题的原因是因为这个表不满足第二范式。l 如何判断一个表是否满足第二范式呢，判断方法是：（1）、找出表的关键字。（2）、如果只有一个关键字，若每一个非关键字都依赖于这个关键字，则表满足第二范式，否则不是。什么是依赖（关系）呢？例：某表中有两个字段：学号、姓名，对于每一个学号，只有一个姓名与之对应，则称姓名依赖于学号，或称学号唯一确定姓名，记作：学号姓名。例3：学生（学号，姓名，学院）表是否满足第二范式？答：满足。因为，这个表中只有一个关键字即学号，而其他字段（即非关键字）都依赖于学号，也就是说每一个学号只有一个姓名，一个学院与之对应。例4：学生（学号，姓名，学院，成绩）表是否满足第二范式？答：不满足。因为，一个学生可能不只选一门课程，不止一个成绩，也就是说每一个学号不只有一个成绩与之对应，或者说，有一个非关键字段（即成绩）不依赖于学号。（3）、如果有两个或两个以上的关键字，那么，把这些关键字看成是一个组合关键字，若每一个非关键字都能完全依赖于组合关键字，则表满足第二范式，否则不是。例5：成绩（学号，课程，成绩）表是否满足第二范式？满足。因为，非关键字（成绩）完全依赖于组合关键字（学号+课程），即只有一个成绩与（学号+课程）对应，或者说，一个学生选修一门课程，就只能有一个成绩。称为部分依赖。l 定义：如果一个表满足1NF，且每一个非关键字都完全依赖于关键字，则这个表满足第二范式。l 第一范式转换成第二范式的方法：找出依赖关系，将能完全依赖于主键的字段从表中提取出来，同主键一起组成一个新的关系。 例7：表二(学号，姓名，学院，地址，课程号，课程名，成绩）的依赖关系如下：显然，不满足2NF。院、地址）绩）转换的过程就是拆分的过程，也是一个消除部分依赖的过程。但是，要注意，拆分的结果应该包含原表的所有字段！（即无损分解）3、第三范式（3NF）通过分析，发现表A仍然在一定程度上存在上面提及的三个问题，要消除和减少它们，还得把它分解成满足更高范式（即3NF）的表.l 满足第三范式的判断方法：判断表在满足第二范式的基础上是否有传递依赖的情况，如果有，不是第三范式，否则是。l 将非第三范式规范为第三范式的方法：把产生传递依赖关系的非关键字段抽出来，同关键字一起建立新的表。例8：表A(学号，姓名，学院，地址)中，存在地址传递依赖于学号的关系，即：学号学院，学院地址。把地址从原表中分出来，同关键字一起建立新的表形成表A1（学院、地址）,原表就可消除了传递依赖关系。表A分解为：表A1 （学院、地址） 表A2（学号、姓名、学院） 小结：表的规范化中，1NF是要满足每个字段都是不可再分的；2NF是在1NF的基础上消除部分依赖关系（只保留完全依赖），3NF是在2NF的基础上进一步消除传递依赖关系。二：在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是数据库规范化。数据冗余数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中， 因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。规范化实例为了说明方便，我们在本文中将使用一个SAMPLE数据表，来一步一步分析规范化的过程。首先，我们先来生成一个的最初始的表。CREATE TABLE SAMPLE ( PRJNUM INTEGER NOT NULL, PRJNAME VARCHAR(200), EMYNUM INTEGER NOT NULL, EMYNAME VARCHAR(200), SALCATEGORY CHAR(1), SALPACKAGE INTEGER) IN USERSPACE1;ALTER TABLE SAMPLE ADD PRIMARY KEY(PRJNUM, EMYNUM);Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE)values(100001, TPMS, 200001, Johnson, A, 2000), (100001, TPMS, 200002,Christine, B, 3000), (100001, TPMS, 200003, Kevin, C, 4000), (100002,TCT, 200001, Johnson, A, 2000), (100002, TCT, 200004, Apple, B,3000);表1-1考察表1-1，我们可以看到，这张表一共有六个字段，分析每个字段都有重复的值出现，也就是说，存在数据冗余问题。这将潜在地造成数据操作（比如删除、更新等操作）时的异常情况，因此，需要进行规范化。第一范式参照范式的定义，考察上表，我们发现，这张表已经满足了第一范式的要求。（1NF:字段具有原子性，不可再分； 比如说籍贯这个字段，里面是“湖北武汉”的话，它就违反了原子性，因为湖北武汉还可以再分的更具体，分为“湖北”和“武汉” ）1、因为这张表中字段都是单一属性的，不可再分；2、而且每一行的记录都是没有重复的；3、存在主属性，而且所有的属性都是依赖于主属性；4、所有的主属性都已经定义事实上在当前所有的关系数据库管理系统（DBMS）中，都已经在建表的时候强制满足第一范式。因此，这张SAMPLE表已经是一张满足第一范式要求的表。考察表1-1，我们首先要找出主键。可以看到，属性对是主键，其他所有的属性都依赖于该主键。从一范式转化到二范式根据第二范式的定义，转化为二范式就是消除部分依赖。（2NF:组合关键字的表，不存在组合关键字中的任意字段决定其它非关键字段（也就是说不能有两个组合键组成一个主键）考察表1-1，我们可以发现，非主属性部分依赖于主键中的; 非主属性，和都部分依赖于主键中的；表1-1的形式，存在着以下潜在问题：1 数据冗余：每一个字段都有值重复；2 更新异常：比如字段的值，比如对值TPMS了修改，那么就要一次更新该字段的多个值；3 插入异常：如果新建了一个Project，名字为TPT, 但是还没有Employee加入，那么将会空缺，而该字段是主键的一部分，因此将无法插入记录；Insert into SAMPLE(PRJNUM, PRJNAME, EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(100003, TPT, NULL, NULL, NULL, NULL)4 删除异常：如果一个员工 200003, Kevin 离职了，要将该员工的记录从表中删除，而此时相关的Salary信息 C 也将丢失, 因为再没有别的行纪录下 Salary C的信息。Delete from sample where EMYNUM = 200003Select distinct SALCATEGORY, SALPACKAGE from SAMPLE因此，我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来，形成一张新的表，而新表和旧表之间是一对多的关系。由此，我们得到：CREATE TABLE PROJECT ( PRJNUM INTEGER NOT NULL, PRJNAME VARCHAR(200) IN USERSPACE1;ALTER TABLE PROJECT ADD PRIMARY KEY(PRJNUM);Insert into PROJECT(PRJNUM, PRJNAME) values(100001, TPMS), (100002, TCT);表1-2表 1-3EMYNUMEMYNAMESALCATEGORYSALPACKAGE200001Johnson A 2000200003Kevin C 4000200004Apple B 3000CREATE TABLE EMPLOYEE ( EMYNUM INTEGER NOT NULL, EMYNAME VARCHAR(200), SALCATEGORY CHAR(1), SALPACKAGE INTEGER) IN USERSPACE1;ALTER TABLE EMPLOYEEADD PRIMARY KEY(EMYNUM);Insert into EMPLOYEE(EMYNUM, EMYNAME, SALCATEGORY, SALPACKAGE) values(200001,Johnson, A, 2000), (200002, Christine, B, 3000), (200003, Kevin, C,4000), (200004, Apple, B, 3000);CREATE TABLE PRJ_EMY ( PRJNUM INTEGER NOT NULL, EMYNUM INTEGER NOT NULL) IN USERSPACE1;ALTER TABLE PRJ_EMY ADD PRIMARY KEY(PRJNUM, EMYNUM);Insert into PRJ_EMY(PRJNUM, EMYNUM) values(100001, 200001), (100001, 200002),(100001, 200003), (100002, 200001), (100002, 200004);同时，我们把表1-1的主键，也就是表1-2和表1-3的各自的主键提取出来，单独形成一张表，来表明表1-2和表1-3之间的关联关系：表 1-4这时候我们仔细观察一下表1-2, 1-3, 1-4, 我们发现插入异常已经不存在了，当我们引入一个新的项目 TPT 的时候，我们只需要向表1-2 中插入一条数据就可以了， 当有新人加入项目 TPT 的时候，我们需要向表1-3, 1-4 中各插入一条数据就可以了。虽然我们解决了一个大问题，但是仔细观察我们还是发现有问题存在。从二范式转化到三范式考察表前面生成的三张表，我们发现，表1-3存在传递依赖关系，即：关键字段 - 非关键字段 -非关键字段。而这是不满足三范式的规则的，存在以下的不足：1、 数据冗余：和的值有重复；2、 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况；3、 删除异常：同样的，如果员工 200003 Kevin 离开了公司，会直接导致 Salary C 的信息的丢失。Delete from EMPLOYEE where EMYNUM = 200003Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE因此，我们需要继续进行规范化的过程，把表1-3拆开，我们得到：表 1-5和表 1-6这时候如果 200003 Kevin 离开公司，我们只需要从表 1-5 中删除他就可以了， 存在于表1-6中的Salary C信息并不会丢失。但是我们要注意到除了表 1-5 中存在 Kevin 的信息之外， 表1-4中也存在 Kevin 的信息， 这很容易理解， 因为 Kevin 参与了项目 100001， TPMS， 所以当然也要从中删除。 至此，我们将表1-1经过规范化步骤，得到四张表，满足了三范式的约束要求，数据冗余、更新异常、插入异常和删除异常。在三范式之上，还存在着更为严格约束的BC范式和四范式，但是这两种形式在商业应用中很少用到，在绝大多数情况下，三范式已经满足了数据库表规范化的要求，有效地解决了数据冗余和维护操作的异常问题。（3NF:在2NF的基础上，数据表中如果不存在非关键字段对任一候选字段的传递函数依赖则符合第三范式（也就是说违反了数据冗余） 帐号 身份证号 姓名 密码 1001 410101001 李梅 100001 身份证号和姓名共同决定了密码，姓名是依赖于身份证号的，这样就违反了第三范式）.第四范式(4NF)(1)第四范式(4NF)的定义 在4.3.5中我们曾分析了关系CTB虽然属于BCNF，但还存在着数据冗余、插入异常和删除异常的弊端，究其原因就是CTB中存在非平凡的的多值依赖，而决定因素不是关键字。因而必须将CTB继续分解，如果分解成两个关系模式CTB1(C，T)和CTB2(C，B)，则它们的冗余度会明显下降。从多值依赖的定义分析CTB1和CTB2，它们的属性间各有一个多值依赖CT，CB，都是平凡的多值依赖。因此，含有多值依赖的关系模式中，减少数据冗余和操作异常的常用方法是将关系模式分解为仅有平凡的多值依赖的关系模式。 定义4.9 设有一关系模式R(U)，U是其属性全集，X、Y是U的子集，D是R上的数据依赖集。如果对于任一多值依赖XY，此多值依赖是平凡的，或者X包含了R的一个候选关键字，则称R是第四范式的关系模式，记为R4NF。由此定义可知：关系模式CTB分解后产生的CTB1(C，T)和CTB2(C，B)中，因为CT，CB均是平凡的多值依