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

数据库设计之规范化案例讲解
规范化
数据冗余
规范化案例
更多实例
1
规范化
在设计和操作维护数据库时,关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构,不仅便于对数据库进行相应的存取操作,而且可以极大地简化应用程序的其他内容(查询、窗体、报表、代码等)。正确进行表设计的正式名称就是"数据库规范化"。
2
数据冗余
数据应该尽可能少地冗余,这意味着重复数据应该减少到最少。比如说,一个部门雇员的电话不应该被存储在不同的表中, 因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据,这就意味着要占用了更多的物理空间,同时也对数据的维护和一致性检查带来了问题,当这个员工的电话号码变化时,冗余数据会导致对多个表的更新动作,如果有一个表不幸被忽略了,那么就可能导致数据的不一致性。
3
规范化实例之初始表
考察表1-1,我们可以看到,这张表一共有六个字段,分析每个字段都有重复的值出现,也就是说,存在数据冗余问题。这将潜在地造成数据操作(比如删除、更新等操作)时的异常情况,因此,需要进行规范化。
表 1-1
4
规范化实例之1NF
参照范式的定义,考察上表,我们发现,这张表已经满足了第一范式的要求。
1、因为这张表中字段都是单一属性的,不可再分;
2、而且每一行的记录都是没有重复的;
3、存在主属性,而且所有的属性都是依赖于主属性;
4、所有的主属性都已经定义
事实上在当前所有的关系数据库管理系统(DBMS)中,都已经在建表的时候强制满足第一范式。因此,这张SAMPLE表已经是一张满足第一范式要求的表。考察表1-1,我们首先要找出主键。可以看到,属性对<Project Number, Employee Number>是主键,其他所有的属性都依赖于该主键。
5
规范化实例之:1NF -> 2NF
根据第二范式的定义,转化为二范式就是消除部分依赖。
考察表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的信息。
因此,我们需要将存在部分依赖关系的主属性和非主属性从满足第一范式的表中分离出来,形成一张新的表,而新表和旧表之间是一对多的关系。由此,我们得到:
6
1NF -> 2NF
表 1-2
表 1-3
表 1-4
这时候我们仔细观察一下表1-2, 1-3, 1-4, 我们发现插入异常已经不存在了,当我们引入一个新的项目 TPT 的时候,我们只需要向表1-2 中插入一条数据就可以了, 当有新人加入项目 TPT 的时候,我们需要向表1-3, 1-4 中各插入一条数据就可以了。虽然我们解决了一个大问题,但是仔细观察我们还是发现有问题存在。
7
2NF -> 3NF
考察表前面生成的三张表,我们发现,表1-3存在传递依赖关系,即:关键字段< Employee Number > --> 非关键字段< Salary Category > -->非关键字段< Salary Package >。而这是不满足三范式的规则的,存在以下的不足:
1、数据冗余:<Salary Category>和<Salary Package>的值有重复;
2、更新异常:有重复的冗余信息,修改时需要同时修改多条记录,否则会出现数据不一致的情况;
3、删除异常:同样的,如果员工 200003 Kevin 离开了公司,会直接导致 Salary C 的信息的丢失。
Delete from EMPLOYEE where EMYNUM = 200003Select distinct SALCATEGORY, SALPACKAGE from EMPLOYEE
因此,我们需要继续进行规范化的过程,把表1-3拆开,我们得到:
表 1-3
8
2NF -> 3NF
表 1-5
表 1-6
这时候如果 200003 Kevi