数据库设计之规范化案例讲解.pptVIP

数据库设计之规范化案例讲解 规范化 数据冗余 规范化案例 更多实例 规范化 在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是数据库规范化。 数据冗余 数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中， 因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。 规范化实例之初始表 规范化实例之1NF 参照范式的定义，考察上表，我们发现，这张表已经满足了第一范式的要求。 1、因为这张表中字段都是单一属性的，不可再分； 2、而且每一行的记录都是没有重复的； 3、存在主属性，而且所有的属性都是依赖于主属性； 4、所有的主属性都已经定义 事实上在当前所有的关系数据库管理系统（DBMS）中，都已经在建表的时候强制满足第一范式。因此，这张SAMPLE表已经是一张满足第一范式要求的表。考察表1-1，我们首先要找出主键。可以看到，属性对Project Number, Employee Number是主键，其他所有的属性都依赖于该主键。 规范化实例之：1NF - 2NF 1NF - 2NF 2NF - 3NF 2NF - 3NF Over 更多实例 1NF 1 NF 2NF 2NF 原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。 解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系。 3NF 3NF 原因：关系中存在传递依赖造成的。即SNO - DNO。而DNO - SNO却不存在，DNO - LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO - LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。 解决目地：每个关系模式中不能留有传递依赖。 解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION） 注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。 数据库设计范式之小结 目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新 原则：遵从概念单一化 一事一地原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。 方法：将关系模式投影分解成两个或两个以上的关系模式。 要求：分解后的关系模式集合应当与原关系模式等价，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。 注意 注意（续） * * 考察表1-1，我们可以看到，这张表一共有六个字段，分析每个字段都有重复的值出现，也就是说，存在数据冗余问题。这将潜在地造成数据操作（比如删除、更新等操作）时的异常情况，因此，需要进行规范化。 表 1-1 根据第二范式的定义，转化为二范式就是消除部分依赖。 考察表1-1，我们可以发现，非主属性Project Name部分依赖于主键中的Project Number; 非主属性Employee Name，Salary Category和Salary package都部分依赖于主键中的Employee Number； 表1-1的形式，存在着以下潜在问题： 1． 数据冗余：每一个字段都有值重复； 2． 更新异常：比如Project Name字段的值，比如对值TPMS了修改，那么就要一次更新该字段的多个值； 3． 插入异常：如果新建了一个Project，名字为TPT, 但是还没有Employee加入，那么Employee Number将会空缺，而该字段是主键的一部分，因此将无法插入记录； 4． 删除异常：如果一个员工 200003, Kevin 离职了，要将该员工的记录从表中删除，而此时相关的Salary信息 C 也将丢失, 因为再没有别的行纪录下 Salary C的信息。 因此，我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来，形成一张新的表，而新表和旧表之间是一对多的关系。由此，我们得到： 表 1-2 表 1-3 表 1-4 这时候我们仔细观察一下表1-2, 1-3, 1-4, 我们发现