关系型数据库设计的规范化.doc

关系型数据库是当前广泛应用的数据库类型，关系数据库设计是对数据进行组织化和结构化的过程，核心问题是关系模型的设计。对于数据库规模较小的情况，我们可以比较轻松的处理数据库中的表结构。然而，随着项目规模的不断增长，相应的数据库也变得更加复杂，关系模型表结构更为庞杂，这时我们往往会发现我们写出来的SQL语句的是很笨拙并且效率低下的。更糟糕的是，由于表结构定义的不合理，会导致在更新数据时造成数据的不完整。因此，就有必要学习和掌握数据库的规范化流程，以指导我们更好的设计数据库的表结构，减少冗余的数据，借此可以提高数据库的存储效率，数据完整性和可扩展性。本文将结合具体的实例，介绍数据库规范化的流程。规范化在设计和操作维护数据库时，关键的步骤就是要确保数据正确地分布到数据库的表中。使用正确的数据结构，不仅便于对数据库进行相应的存取操作，而且可以极大地简化应用程序的其他内容（查询、窗体、报表、代码等）。正确进行表设计的正式名称就是数据库规范化。后面我们将通过实例来说明具体的规范化的工程。关于什么是范式的定义，请参考附录文章 1.数据冗余数据应该尽可能少地冗余，这意味着重复数据应该减少到最少。比如说，一个部门雇员的电话不应该被存储在不同的表中， 因为这里的电话号码是雇员的一个属性。如果存在过多的冗余数据，这就意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了问题，当这个员工的电话号码变化时，冗余数据会导致对多个表的更新动作，如果有一个表不幸被忽略了，那么就可能导致数据的不一致性。规范化实例为了说明方便，我们在本文中将使用一个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，我们可以看到，这张表一共有六个字段，分析每个字段都有重复的值出现，也就是说，存在数据冗余问题。这将潜在地造成数据操作（比如删除、更新等操作）时的异常情况，因此，需要进行规范化。第一范式参照范式的定义，考察上表，我们发现，这张表已经满足了第一范式的要求。1、因为这张表中字段都是单一属性的，不可再分；2、而且每一行的记录都是没有重复的；3、存在主属性，而且所有的属性都是依赖于主属性；4、所有的主属性都已经定义事实上在当前所有的关系数据库管理系统（DBMS）中，都已经在建表的时候强制满足第一范式。因此，这张SAMPLE表已经是一张满足第一范式要求的表。考察表1-1，我们首先要找出主键。可以看到，属性对是主键，其他所有的属性都依赖于该主键。从一范式转化到二范式根据第二范式的定义，转化为二范式就是消除部分依赖。考察表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-3CREATE TABLE EMPLOYEE ( EMYNUM INTEGER NOT NULL, EMYNAME VARCHAR(200), SALCATEGORY CHAR(1), SALPACKAGE INTEGER) IN USERSPACE1;ALTER TABLE EMPLOYEE ADD 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);Employee NumberEmployee NameSalary CategorySalary Package200001JohnsonA2000200002ChristineB3000200003KevinC4000200004AppleB3000CREATE 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范式和四范式，但是这两种形式在商业应用中很少用到，在绝大多数情况下，三范式已经满足了数据库表规范化的要求，有效地解决了数据冗余和维护操作的异常问题。结束语在本文描述的过程中，我们通过结合实例的方法，通俗地演绎了数据表规范化的过程，并展示了在此过程中数据冗余、数据库操作异常等问题是如何得到解决的。在具体的工程应用中，运用数据库规范化的方法来设计数据库表，将是具有现实意义的。参考资料 Database Normalization Basics：数据库规范化基础原则 Normalization principles：数据库规范化原则和范式定义数据库设计多对多关系的几种形态 数据库设计多对多关系的几种形态 前言：多对多关系至少需要3个表，我们把一个表叫做主表，一个叫做关系表，另外一个叫做字典表或者副表（字典表是纪录比较少，而且基本稳定的，例如：版块名称；副表是内容比较多，内容变化的，例如）。 按照数据库的增删查改操作，多对多关系的查找都可以用inner join或者select * from 主表 where id in (select 主表id from 关系表) 1，角色任命型 特点：关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键，有一个表是字典类型的表。界面特点：显示主表，用checkbox或多选select设置多选关系。例如：任命版主（用户表-关系表-版块名称表），角色权限控制等，用户是5个版块版主，只要关系表5行纪录就可以确立，关系表的两个外键具有联合主键性质。 增加关系：如果没有组合纪录，insert之。 删除关系：如果有组合纪录，删除之。 2，集合分组型 特点：同角色任命型类似，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。区别是主副表都不是字典表，可能都很大不固定。界面特点：显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。例如：歌曲专集（专集表-关系表-歌曲表）。手机分组（分组表-关系表-手机表）。用户圈子（圈子表-关系表-用户表）。文章标签（文章表-关系表-标签表） 增加关系：同版主任命型。 删除关系：同版主任命型。 3，明细帐型 特点：关系表可以有重复纪录，关系表一般有时间字段，有主键，可能还有文字型的字段用来说明每次发生关系的原因（消费）。界面特点：显示关系表，用radio或下拉设置单选关系。例如：现金消费明细帐或订单（用户表-订单表-消费原因表），用户可能多次在同一事情上重复消费。积分变化纪录也属于这类。增加关系：不管有没有组合纪录，insert之，纪录时间。 删除关系：根据关系表PK删除。 4，评论回复型 特点：同明细帐型关系表一般有时间字段，有主键，区别是重点在文字型的字段用来说明每次发生关系的内容（评论回复）。 界面特点：回复文本框。例如：论坛回复（用户表-回复表-帖子表），用户可能多次在不同帖子上评论回复费。 增加关系：不管有没有组合纪录，insert之，纪录时间和文字。删除关系：根据关系表（回复表）PK删除。 5，站内短信型 特点：主副表是同一个，关系表一般有时间字段，有主键，重点在关系表文字型的字段用来说明每次发生关系的内容（消息）或者其他标记位来表示文字已读状态时间等。 界面特点：回复文本框。 例如：站内短信（用户表-短信表-用户表），用户可能给用户群发或者单发，有标记位来表示文字已读状态时间等。增加关系：不管有没有组合纪录，insert之，纪录时间和文字。 删除关系：根据关系表（回复表）PK删除。 6，用户好友型 特点：主副表是同一个，同集合分组型，关系表两外键组合无重复纪录，关系表一般不需要时间字段和主键。界面特点：同集合分组型，显示主表，用搜索代替简单的checkbox或多选select，或者一条一条的添加。例如：下载站点的文件，（文件表-关系表-文件表）可以被软件工具打开，软件工具本身也是一种文件，可以被下载。用户的好友，也是用户（用户表-好友关系表-用户表） 增加关系：同版主任命型。 删除关系：同版主任命型。 7，未知属性型 特点：在设计初期，主表的某些字段类型和名称是不确定的时候，关系表实际上是主表的可扩展字段， 一个主表（ID），一个属性名称表（属性ID.属性名称)， 一个属性值表，包括3个字段： 属性值(属性Value varchar(500) 主表ID 属性ID 这样可以作到最小冗余度。（和常见的多对多关系不同的是：值统一用varchar来存储，因为这类型的值一般不会用来计算）。 比如： 军队的数据库设计中有种物资叫做“战缴物资”，就是打仗的时候缴获的，军队自己都不知道这些物资有什么属性。 比如缴获的化学品有化学名，通用名，是否有辐射，计量单位，包装规格，数量等等，或者不是化学品是其他任何未知的东西。 这样东西就可以 某奇怪东西.属性集合某某奇怪属性名=某某奇怪值； 某变态东西.属性集合某某变态属性名=某某变态值； 这样存储。 再比如： 手机型号有几千种，除了共同属性外还有不同属性有几百个，属性名和值类型都不一样，有的手机有这属性，有的没有。对于这样的“多态”，我们就采用上面的设计结构。 其效果相当于： 某奇怪手机.属性集合某某奇怪属性名=某某奇怪值；某变态手机.属性集合某某变态属性名=某某变态值； 数据库的设计范式是数据库设计所需要满足的规范，满足这些规范的数据库是简洁的、结构明晰的，同时，不会发生插入（insert）、删除（delete）和更新（update）操作异常。反之则是乱七八糟，不仅给数据库的编程人员制造麻烦，而且面目可憎，可能存储了大量不需要的冗余信息。设计范式是不是很