《数据库设计之规范化案例讲解》由会员分享，可在线阅读，更多相关《数据库设计之规范化案例讲解（19页珍藏版）》请在金锄头文库上搜索。
1、数据库设计之规范化案例讲解Stillwatersrundeep.流静水深流静水深,人静心深人静心深Wherethereislife,thereishope。有生命必有希望。有生命必有希望规范化n在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是数据库规范化。数据冗余n数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中， 因为这里的电话号码是雇员的一个属性。如果存在过
2、多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。规范化实例之初始表考察表1-1，我们可以看到，这张表一共有六个字段，分析每个字段都有重复的值出现，也就是说，存在数据冗余问题。这将潜在地造成数据操作（比如删除、更新等操作）时的异常情况，因此，需要进行规范化。表 1-1规范化实例之1NFn参照范式的定义，考察上表，我们发现，这张表已经满足了第一范式的要求。n1、因为这张表中字段都是单一属性的，不可再分；n2、而且每一行的记录都是没有重复的；
3、n3、存在主属性，而且所有的属性都是依赖于主属性；n4、所有的主属性都已经定义n事实上在当前所有的关系数据库管理系统（DBMS）中，都已经在建表的时候强制满足第一范式。因此，这张SAMPLE表已经是一张满足第一范式要求的表。考察表1-1，我们首先要找出主键。可以看到，属性对是主键，其他所有的属性都依赖于该主键。规范化实例之：1NF - 2NF根据第二范式的定义，转化为二范式就是消除部分依赖。考察表1-1，我们可以发现，非主属性部分依赖于主键中的; 非主属性，和都部分依赖于主键中的；表1-1的形式，存在着以下潜在问题：1 数据冗余：每一个字段都有值重复；2 更新异常：比如字段的值，比如对值TPM
4、S了修改，那么就要一次更新该字段的多个值；3 插入异常：如果新建了一个Project，名字为TPT, 但是还没有Employee加入，那么将会空缺，而该字段是主键的一部分，因此将无法插入记录；4 删除异常：如果一个员工 200003, Kevin 离职了，要将该员工的记录从表中删除，而此时相关的Salary信息 C 也将丢失, 因为再没有别的行纪录下 Salary C的信息。因此，我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来，形成一张新的表，而新表和旧表之间是一对多的关系。由此，我们得到：1NF - 2NF表 1-2表 1-3表 1-4这时候我们仔细观察一下表1-2
5、, 1-3, 1-4, 我们发现插入异常已经不存在了，当我们引入一个新的项目 TPT 的时候，我们只需要向表1-2 中插入一条数据就可以了， 当有新人加入项目 TPT 的时候，我们需要向表1-3, 1-4 中各插入一条数据就可以了。虽然我们解决了一个大问题，但是仔细观察我们还是发现有问题存在。 2NF - 3NF考察表前面生成的三张表，我们发现，表1-3存在传递依赖关系，即：关键字段 - 非关键字段 -非关键字段。而这是不满足三范式的规则的，存在以下的不足：1、 数据冗余：和的值有重复；2、 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况；3、 删除异常：同
6、样的，如果员工 200003 Kevin 离开了公司，会直接导致 Salary C 的信息的丢失。Delete from EMPLOYEE where EMYNUM = 200003Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE因此，我们需要继续进行规范化的过程，把表1-3拆开，我们得到：表 1-32NF - 3NF表 1-5表 1-6这时候如果 200003 Kevin 离开公司，我们只需要从表 1-5 中删除他就可以了， 存在于表1-6中的Salary C信息并不会丢失。但是我们要注意到除了表 1-5 中存在 Kevin 的信息之
7、外， 表1-4中也存在 Kevin 的信息， 这很容易理解， 因为 Kevin 参与了项目 100001， TPMS， 所以当然也要从中删除。Over至此，我们将表1-1经过规范化步骤，得到四张表，满足了三范式的约束要求，数据冗余、更新异常、插入异常和删除异常。在三范式之上，还存在着更为严格约束的BC范式和四范式，但是这两种形式在商业应用中很少用到，在绝大多数情况下，三范式已经满足了数据库表规范化的要求，有效地解决了数据冗余和维护操作的异常问题。更多实例n1NF 1 NF在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式第一范式的关系。例：如职工号，
8、姓名，电话号码组成一个表（一个人可能有一个办公室电话和一个家里电话号码）规范成为1NF有三种方法：1、一是重复存储职工号和姓名。这样，关键字只能是电话号码。2、二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性3、三是职工号为关键字，但强制每条记录只能有一个电话号码。以上三个方法，第一种方法最不可取，按实际情况选取后两种情况2NF如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式第二范式的。例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。由以
9、上条件，关键字为组合关键字（SNO，CNO），在应用中使用以上关系模式有以下问题：a.数据冗余，假设同一门课由40个学生选修，学分就重复40次。b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。2NFn原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。n解决方法：分成两个关系
10、模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系。3NF如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。例：如S1（SNO，SNAME，DNO，DNAME，LOCATION）各属性分别代表学号，姓名，所在系，系名称，系地址。关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改
11、时也将产生类似以上例的情况。3NFn原因：关系中存在传递依赖造成的。即SNO - DNO。而DNO - SNO却不存在，DNO - LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO - LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。n解决目地：每个关系模式中不能留有传递依赖。n解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）n注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。数据库设计范式之小结n目地：目地：规范化目的是使结构更合理，消除存储异常，使数据
12、冗余尽量小，便于插入、删除和更新n原则：原则：遵从概念单一化 一事一地原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。n方法：方法：将关系模式投影分解成两个或两个以上的关系模式。n要求：要求：分解后的关系模式集合应当与原关系模式等价，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。注意一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达
13、到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。各位朋友，你看过后有何感想，其实，任何一本数据库基础理论的书都会讲这些东西，考虑到很多网友是半途出家，来做数据库。特找一本书大抄特抄一把，各位有什么问题，也别问我了，自已去找一本关系数据库理论的书去看吧，说不定，对各位大有帮助。注意（续）说是说以上是基础理论的东西，请大家想想，你在做数据库设计的时候有没有考虑过遵过以上几个范式呢，有没有在数据库设计做得不好之时，想一想，对比以上所讲，到底是违反了第几个范式呢？我见过的数据库设计，很少有人做到很符合以上几个范式的，一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少，而且会破坏完整性，你可以在做设计之时不考虑它，当然在ORACLE中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个数据库设计范式。
