关系规范化理论与数据库设计

第8章关系标准化理论与数据库设计8.1函数依赖8.2标准化和范式8.3数据库设计概述 8.4需求分析8.5概念结构设计8.6逻辑结构设计8.7物理结构设计8.8数据库的实施和维护习题8.1函数依赖建立一个关系数据库系统，首先要考虑怎样建立数据模式，即应该构造几个关系模式，每个关系模式中需要包含哪些属性等，这是数据库设计的问题。关系标准化主要讨论的就是建立关系模式的指导原那么，所以有人把标准化理论称为设计数据库的理论。数据依赖是通过一个关系中属性间值的依赖与否表达出来的数据间的相互关系，它是现实世界属性间相互联系的抽象，是数据内在的性质，是语义的表达。现在人们已经提出了许多种类型的数据依赖，其中最重要的是函数依赖(FD，FunctionalDependency)和多值依赖(MVD，MultivaluedDependency)。这里只讨论函数依赖，有关多值依赖的概念，有兴趣的读者可以参阅有关书籍。函数依赖极为普遍地存在于现实生活中。比方描述一个学生的关系，可以有学号(SNO)，姓名(SNAME)和系名(SDEPT)等几个属性。由于一个学号只对应一个学生，一个学生只在一个系学习，因而当“学号〞值确定以后，姓名和该生所在系的值也就被惟一确实定了。就象自变量x确定以后，相应的函数值f(x)也就惟一地确定了一样，称SNO函数决定SNAME和SDEPT，或者说SNAME和SDEPT函数依赖于SNO，记为SNO→SNAME SNO→SDEPT用形式化的方式表示，关系模式R可以记为R<U，F>其中U表示一组属性的集合，F表示属性组U上的一组数据依赖集合。对于上述的学生关系，可有U={SNO，SNAME，SDEPT}F={SNO→SNAME，SNO→SDEPT}对于关系模式R<U，F>，当且仅当U上的一个关系r满足F时，称r为关系模式R<U，F>的一个关系。定义8-1设R(U)是属性集U上的关系模式，X，Y是U的子集。假设对于R(U)的任意一个可能的关系r，r中不可能存在两个元组在X上的属性值相等，而在Y上的属性值不等，那么称X函数确定Y或Y函数依赖于X，记为X→Y。注意，函数依赖不是指关系模式R的某个或某些关系满足的约束条件，而是指R的一切关系均需要满足的约束条件。函数依赖是语义范畴的概念，我们只能根据语义来确定函数依赖。例如在没有同名的情况下，NAME→AGE，而在有同名的情况下，这个函数依赖就不成立了。下面介绍一些术语和记号：①假设X→Y，那么X叫做决定因素。②假设X→Y，Y→X，那么记为X←→Y。③假设Y不函数依赖于X，那么记为XY。④假设X→Y，但YX，那么称X→Y是平凡的函数依赖。⑤假设X→Y，但YX，那么称X→Y是非平凡的函数依赖。假设不特别声明，下面总是指非平凡的函数依赖。函数依赖可分为三类：完全函数依赖，局部函数依赖和传递函数依赖。这三类函数依赖定义如下：(1)完全函数依赖。定义8-2在R(U)中，如果X→Y，并且对于X的任何一个真子集X' ，都有X'Y，那么称Y对X完全函数依赖，记为XY。可简写为→。例8-1在关系S(SNO，SNAME，SDEPT)中，SNO→SNAME，SNO→SDEPT。用图解表示如图8-1所示。假设关系中没有同姓名的学生，那么用SNO可以惟一确定SNAME，用SNAME也可惟一确定SNO，形成了两者的相互依赖关系，可以记作SNO←→SNAME。图8-1(2)局部函数依赖。定义8-3在R(U)中，如果X→Y，并且对于X的某个真子集X'，有X'→Y，那么称Y对X局部函数依赖，记为XY。只有当X为属性组时，才有可能发生局部函数依赖的情况。因为如果X为单个属性，其子集X'就是X本身。例8-2假设在关系SC(SNO，CNO，GRADE)中增加一个属性CLASS(学生所在班级)，那么在新关系SCNEW(SNO，CNO，GRADE，CLASS)中有(SNO，CNO)→GRADESNO→CLASS(SNO，CNO)CLASS用图解表示，如图8-2所示。请读者注意图中两个箭头的不同出发点。图8-2(3)传递函数依赖。定义8-4在R(U)中，如果X→Y，(YX)，Y→Z，但YX，那么称Z对X传递函数依赖，记为XZ。请注意上述定义中的条件YX。如果不加上这一限制，当X→Y时允许Y→X，那么X←→Y，而在X←→Y的条件下，Y→Z就等于X→Z，这样X就直接决定Z，而不是通过Y的“传递〞决定Z了。例8-3在关系S(SNO，SNAME，SDEPT)中，增加一个属性SDMN(系主任)，那么在新关系 SNEW(SNO，SNAME，SDEPT，SDMN)中有 SNO→SNAME，SNO→SDEPT又因为 SDEPT→SDMN所以 SNOSDMN图8-3是它的图解，图中的虚线箭头表示传递依赖。图8-38.2标准化和范式8.2.1引例在定义各种范式之前，先看一个例子。例8-4假设现有学生关系S(SNO，SN，CLS，MON，CNO，GRD)，其中SNO是学号，SN是学生姓名，CLS是学生所在班级，MON是班主任，CNO是学生所选的课程号，GRD是学生选课的成绩等级。图8-4表示了这个关系的现有元组。不难看出，如果把这一关系付诸实用，会有较多的问题。例如：(1)插入异常。所谓异常，就是说“不好办〞。例如当某学生尚未选课前，虽然他的学号、姓名与班级，仍无法将他的信息插入关系S，这是因为S的主码是(SNO，CNO)，CNO为“空〞值时，插入是禁止的。(2)删除异常。假定学生周明不再选修C1课程了，本应删去C1，但C1是主码的一局部，要删，必须将整个元组一起删去，这样，有关周明的其它信息就丧失了。假设想保存周明的其它信息，就只好不删。(3)冗余量大。一个学生通常要选多门课，SNO，SN，CLS与MON都重复屡次，占用存储空间多。图8-4关系S(4)修改复杂。如果学生更改了姓名，他的所有元组都要修改SN。又如某班改换了班主任，属于该班的学生都要修改MON的内容。一不小心就可能此改彼漏，破坏数据的完整性(即造成数据不一致)。产生上述问题的原因，直观的说，是因为关系中“包罗万象〞，内容太杂了。附属性间函数依赖的关系看，由于关系中除完全函数依赖外，还存在着局部函数依赖和传递函数依赖。下面从消除后两种函数依赖关系入手，尝试解决上述问题。(1)将原关系分解成两个新关系，以消除SN，CLS和MON对主码(SNO，CNO)的局部依赖。新产生的关系是S1(SNO，SN，CLS，MON)SC(SNO，CNO，GRD)图8-5是从图8-4中导出的两个新关系的内容。图8-5(a)S1；(b)SC与原关系比较，消除了许多冗余信息，减少了修改量，同时也减少了插入和删除异常。但新关系S1仍然存在以下问题：(1)班主任的姓名要重复存储(有冗余数据)，类似“更换班主任〞这样的修改，仍需改动较多的元组。(2)仍有插入、删除、修改等异常。例如，假设学生丁芳转到计算机班，如果修改她的CLS、MON两项，便会失去“机械班主任为方方〞的信息，造成修改异常。又如，新增加一个电子班，班主任也已确定，但在该班招收学生之前，这些信息不能插入S1。为了解决上述问题，可再作一次分解。(2)第二次分解，消除MON对SNO的传递函数依赖。此时关系SC不变，仅将S1分解成以下两个关系：S2(SNO，SN，CLS)CL(CLS，MON)图8-6是根据图8-5(a)导出的S2与CL的内容。图8-6(a)S2；(b)CL8.2.2第一范式(1NF)及标准化标准化的理论是E.F.Codd首先提出的。他认为，一个关系数据库中的关系，都应满足一定的标准，才能构造出好的数据模式，Codd把应满足的标准分成几级，每一级称为一个范式(NormalForm)。例如满足最低要求，叫第一范式(1NF)；在1NF根底上又满足一些要求的叫第二范式(2NF)；第二范式中，有些关系能满足更多的要求，就属于第三范式(3NF)。后来Codd和Boyce又共同提出了一个新范式：BC范式(BCNF)。以后又有人提出第四范式(4NF)和第五范式(5NF)。范式的等级越高，应满足的条件也越严。图8-7各种范式之间的关系所谓“第几范式〞，是表示关系的某一种级别，所以经常称某一关系模式R为第几范式。但现在人们把范式这个概念理解成符合某一种级别的关系模式的集合，那么R为第几范式就可以写成R∈xNF。对于各种范式之间的联系有5NF4NFBCNF3NF2NF1NF成立，如图8-7所示。一个低一级范式的关系模式，通过模式分解可以转换为假设干个高一级范式的关系模式的集合，这个过程就叫标准化。关系，作为一张二维表，对它有一个最起码的要求：每一个分量必须是不可分的数据项。满足了这个条件的关系模式就属于第一范式(1NF)。这一限制是在关系的根本性质中提出的，任何关系都必须遵守。第一范式是对关系的最低要求，由于第一范式和第二范式在应用中有许多缺点，实际的数据库系统一般都使用第三范式以上的关系，但也不是范式等级越高越好。下面分别讨论这些范式。8.2.3第二范式(2NF)与第三范式(3NF)定义8-5假设关系模式R∈1NF，且它的每一个非主属性都完全函数依赖于码，那么R∈2NF。2NF就是不允许关系模式的属性之间有这样的函数依赖X→Y，其中X是码的真子集，Y是非主属性。即不允许有非主属性对码的局部函数依赖。定义8-6假设关系模式R∈2NF，且它的每一个非主属性都不传递函数依赖于码，那么R∈3NF。3NF就是不允许关系模式的属性之间有这样的函数依赖X→Y，其中X不包含码，Y是非主属性。X不包含码有两种情况，一种情况X是码的真子集，这是2NF所不允许的；另一种情况X不是码的真子集，这是3NF所不允许的。即3NF不允许有非主属性对码的局部函数依赖和传递函数依赖。从以上定义可知，2NF关系可从1NF关系中消除非主属性对码的局部函数依赖后获得，3NF关系可从2NF关系中消除非主属性对码的传递函数依赖后获得。现在按照上述定义来考察引例中的几个关系，了解它们各属于哪一种范式。例8-5求关系S(SNO，SN，CLS，MON，CNO，GRD)的范式等级。为了分析方便，写出关系的表示式后，可以在主属性下方划一横线，并用箭头标出属性之间的依赖关系。分析：S(SNO，CNO，SN，CLS，MON，GRD)

(1)各分量都是原子的。(2)存在局部函数依赖，如(SNO，CNO)SN。结论：S∈1NF。结论：S∈1NF。例8-6求关系S1(SNO，SN，CLS，MON)的范式等级。分析：S1(SNO，SN，CLS，MON)

(1)分量全是原子的。(2)主关键字为单个属性，不可能存在局部函数依赖。(3)存在传递函数依赖，如SNOMON(因为SNO→CLS，CLS→MON)。例8-7求关系S2，CL与SC的范式等级。(1) S2(SNO，SN，CLS)

(2) CL(CLS，MON)

(3) SC(SNO，CNO，GRD)8.2.4BC范式(BCNF)BCNF(BoyceCoddNormalForm)是由Boyce和Codd提出的，该范式比上述的3NF又进了一步，通常认为BCNF是修正的第三范式，有时也称为扩充的第三范式。定义8-7假设关系模式R∈1NF，且对于每一个非平凡的函数依赖X→Y，X必包含码，那么R∈BCNF。

也就是说，关系模式R(U)中，假设每一个决定因素都包含码，那么R(U)∈BCNF。由BCNF的定义可以得到结论，一个满足BCNF的关系模式有：(1)所有非主属性对每一个码都是完全函数依赖。(2)所有主属性对每一个不包含它的码，也是完全函数依赖。(3)没有任何属性完全函数依赖于非码的任何一组属性。BCNF是第三范式的进一步标准化，即限制条件更严格。3NF不允许有X不包含码，Y是非主属性的非平凡函数依赖X→Y。BCNF那么不管Y是主属性还是非主属性，只要X不包含码，就不允许有X→Y这样的非平凡函数依赖。因此，假设R∈BCNF，那么必然R∈3NF，假设R∈3NF，未必R属于BCNF。然而，BCNF又是概念上更加简单的一种范式，判断一个关系模式是否属于BCNF，只要考察每个非平凡函数依赖X→Y的决定因素X是否包含码就行了。例如我们在前面见过的关系模式S2(SNO，SN，CLS)CL(CLS，MON)SC(SNO，CNO，GRD)它们都属于3NF，并且每一个决定因素都是码，所以它们也都属于BCNF。但并不是每一个属于3NF的关系模式都属于BCNF。例8-8有一关系模式CSZ(CITY，ST，ZIP)，CITY是城市，ST是街道，ZIP是邮政编码，其属性组上的函数依赖集为 F={(CITY，ST)→ZIP，ZIP→CITY}即城市、街道决定邮政编码，邮政编码决定城市。可用图8-8表示如下。容易看出，(CITY，ST)和(ST，ZIP)是两个候选码，CITY，ST，ZIP都是主属性，没有非主属性，自然CSZ∈3NF。但函数依赖ZIP→CITY的决定因素ZIP不包含码，所以CSZBCNF。图8-8CSZ中的函数依赖对于不是BCNF的关系模式，仍然存在不适宜的地方。关系模式CSZ就存在着种种“毛病〞，例如，假设无街道信息，那么一个邮政编码是哪个城市中的邮政编码的信息无法存在数据库中。假设将CSZ分解为两个关系模式： ZC(ZIP，CITY) SZ(ST，ZIP)就没有在非平凡的函数依赖的决定因素中不包含码的情况，两者都是BCNF的关系模式。从以上讨论和例8-4的引例可以看出，关系模式的标准化过程，就是通过关系的投影分解逐步提高关系范式等级的过程。从1NF到BCNF，其过程如图8-9所示。图8-9各种范式及标准化过程3NF和BCNF是在函数依赖的条件下对模式分解所能到达的别离程度的测度。一个模式中的关系模式如果都属于BCNF，那么在函数依赖范畴内，它已实现了彻底的别离，已消除了插入和删除的异常。3NF的“不彻底〞性表现在可能存在主属性对码的局部依赖和传递依赖。把低一级的关系模式分解为假设干个高一级的关系模式，这种分解不是惟一的。下面进一步讨论关系模式的分解，即分解后的关系模式与原关系模式的等价问题。8.2.5关系模式的分解分解可以使各关系模式到达某种程度的别离，让一个关系模式描述一个概念、一个实体或者实体间的一种联系，即所谓“一事一地〞的设计原那么，假设多于一个概念就把它“别离〞出去。分解是提高关系范式等级的重要方法。从例8-4的引例中，读者已看到分解所起的作用。那么，如何对关系模式进行分解呢？在这一小节中，我们将通过一个实例说明模式分解的一般方法和对分解质量的要求。例8-9关系S(SNO，CLS，MON)∈2NF，图8-10(a)显示了它包含的内容，图8-10(b)给出了属性间的依赖关系。试将S分解为两个3NF的新关系。

图8-10关系S及属性间的联系这里有三种不同的分解法，即S-C(SNO，CLS)(1)SC-M(CLS，MON)S-C(SNO，CLS)(2)SS-M(SNO，MON)S-M(SNO，MON)(3)SC-M(CLS，MON)三种方案得出的新关系，全是BCNF，但分解的质量却大有差异。以下结合对分解质量的要求，对这三种方案作一比较。(1)分解必须是无损的，既不应在分解中丧失信息。在上例中，第(3)种方案就不能保证无损分解。图8-11显示了这一方案得出的两个关系。由于计算机班和电子班的班主任是同一个人，分解后将无法分辩S1～S4各属于哪一个班。图8-11第(3)种方案得出的关系S-M和C-M(a) S-M；(b)C-M(2)分解后的新关系应相互独立，对一个关系内容的更改，不会影响另一个关系。试比较以上的(1)、(2)两种方案。设S4从电子班转到机械班。按第(1)种方案，仅修改S-C就可以了；而按第(2)种方案，就要同时修改S-C与S-M两个关系。在插入的时候，(1)、(2)两种方案的情况也不相同。假定增加了一个新班，并有了班主任。按第(1)种方案，可以直接在C-M中插入一个新元组；而按第(2)种方案，那么必须等这个班已有了学生，才能将CLS与MON的信息分别插入S-C与S-M两个关系。产生以上这些差异的原因，可以结合图8-10(b)来说明。在图中的三个属性之间，SNO→CLS，CLS→MON都是完全函数依赖，而SNO→MON那么为传递函数依赖。方案(1)建立的两个新关系分别使用了两个原有的完全函数依赖关系，方案(2)和方案(3)都只有一个新关系使用了完全函数依赖，另一个新关系使用的传递函数依赖，对于未用到的那个完全函数依赖关系，只能靠推导才能得到。这就是方案(1)优于其它方案的原因。可见，借助于图8-10(b)的属性依赖图解，可以帮助选择正确的分解方案。从上例可知，对关系模式的分解，不能仅着眼于提高它的范式等级，还应遵守无损分解和分解后的新关系相互独立等原那么。只有兼顾到各方面的要求，才能保证分解的质量。还需要注意的是，有些模式在理论中存在冗余或异常，实际应用中不一定有多少影响。例如有些关系模式在运行中只有查询操作，没有插入和删除等操作，就不必担忧发生“异常〞。总之，处理模式分解必须从实际出发，并不是范式等级越高越好。分解得过细，即使对消除更新异常有些好处，但查询时需要更多的连接操作，很可能是得不偿失的。8.3数据库设计概述数据库设计是指数据库应用系统的设计，数据库应用系统是含有数据库的信息系统的通称。数据库应用系统的设计是对于一个给定的应用环境(包括硬件环境和软件环境)，如何来表达用户的要求，构造最优的数据库模式，建立数据库及围绕数据库展开的应用系统，使之能够有效地收集、存储、操作和管理数据，满足各类用户的应用需求(信息需求和处理需求)。对一般的用户来说，数据库管理系统(DBMS)已经随机器配置，不需要自行设计。所谓应用系统的设计，实际上就是“数据库+应用程序〞的设计，而中心问题那么是数据库的设计。具体地说，数据库设计包括结构特性的设计和行为特性的设计两方面的内容。结构特性的设计是指确定数据库的数据模型。数据模型反映了现实世界的数据及数据间的联系，要求在满足应用需求的前提下，尽可能减少冗余，实现数据共享。行为特性的设计是指确定数据库应用的行为和动作，应用的行为表达在应用程序中，所以行为特性的设计主要是应用程序的设计。数据库设计工作量大而且过程比较复杂，既是一项数据库工程，也是一项庞大的软件工程，数据库设计的各阶段可以和软件工程的各阶段对应起来，软件工程的某些方法和工具同样可以适用于数据库工程。数据库工程与传统的软件工程的区别在于：软件工程中比较强调行为特性的设计；在数据库工程中，由于数据库模型是一个相对稳定的并为所有用户共享的数据根底，所以在数据库工程中更强调对于结构特性的设计，并与行为特性的设计结合起来。为了使数据库设计更合理更有效，需要有效的指导原那么，这种指导原那么称做数据库设计方法学。数据库标准设计方法中比较著名的有新奥尔良(NewOrleans)方法，它将数据库设计过程分为4个阶段：需求分析(分析用户要求)、概念结构设计(信息分析与定义)、逻辑结构设计(设计实现)和物理结构设计(物理数据库设计)。其后，S.B.Yao等人又将数据库设计分为5个步骤。又有等人主张把数据库设计当成一步接一步的过程，并采用一些辅助手段实现每一过程。按照标准设计的方法，考虑数据库及其应用系统开发全过程，将数据库设计分为以下6个阶段(如图8-12所示)。l

需求分析；l

概念结构设计；l

逻辑结构设计；l

物理结构设计；l

数据库实施；l

数据库运行与维护。图8-12数据库设计步骤数据库设计开始之前，首先必须选定参加设计的人员，包括系统分析人员、数据库设计人员和程序员、用户和数据库管理员。系统分析和数据库设计人员是数据库设计的核心人员，他们将自始至终参与数据库设计，他们的水平决定了数据库系统的质量。用户和数据库管理员在数据库设计中也是举足轻重的，他们主要参加需求分析和数据库的运行维护，他们的积极参与不但能加快数据库设计，而且也是决定数据库设计的质量的重要因素。程序员那么在系统实施阶段参与进来，分别负责编制程序和准备软硬件环境。1．需求分析阶段在进行数据库设计时，首先必须准确了解与分析用户需求(包括数据与处理)。需求分析是整个设计过程的根底，作为地基的需求分析是否做得充分与准确，决定了在其上构建数据库大厦的速度与质量，需求分析做得不好，甚至会导致整个数据库设计返工重做。该阶段的工作是收集和分析用户对系统的要求，确定系统的工作范围，并产生“数据流图〞和“数据字典〞。2．概念结构设计阶段根据对系统的要求，提出能够反映各个用户要求的局部概念模型，然后将局部概念模型综合为总的概念模型。应该指出，概念模型仅是用户活动的客观反映，并不涉及用什么样的数据模型来实现它的问题，即概念模型独立于具体的DBMS。因此在这一阶段，应该把注意力集中在弄清系统要求上面，暂不要考虑怎样去实现，以免分散精力。实体—联系方法是设计概念模型的主要方法，在该阶段结束时应该产生系统的根本E–R图。3．逻辑结构设计阶段这一阶段首先要选择一种适当的数据模型，然后将系统的概念模型转换为所需的数据模型。通常一种DBMS只支持某一种数据模型(如关系、网状或层次模型)，所以DBMS一旦确定，数据模型的类型也就定了。此时逻辑设计的任务，仅是把概念模型转换为系统的DBMS所支持的数据模型。逻辑结构设计一般分为初始设计和优化设计两步。优化设计要用到标准化理论和LRA方法。4．物理结构设计阶段该设计阶段内容包括：确定存储结构；建立存取路径；分配存储空间等。这些工作主要由DBMS在操作系统支持下自动完成，只有少量工作可由用户选择或干预。例如，有些DBMS允许用户在一定范围内选择主文件和索引文件的结构，决定在哪些属性码上建立索引，建什么样的(单码或组合码)索引等。在存储分配上，用户可以指定存储介质，如磁盘、磁带等。5．数据库实施阶段在数据库实施阶段，设计人员运用DBMS提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制和调试应用程序，组织数据入库，并进行试运行。应用程序须按照不同用户的要求分别考虑和设计，需要时可以先在逻辑模式上定义适合于用户需要的外模式。6．数据库运行和维护阶段数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。设计一个完善的数据库应用系统是不可能一蹴而就的，它往往是上述六个阶段的不断反复。需要指出的是，这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计。下面就以图8-12的设计过程为主线，讨论数据库设计各个阶段的设计内容、设计方法和工具。8.4需

求

分

析需求分析简单地说就是分析用户的要求。需求分析是设计数据库的起点，需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。所以，准确而无遗漏地弄清用户对系统的要求，是系统设计取得成功的重要前提。8.4.1需求分析的任务需求分析的任务是对现实世界要处理的对象(组织、部门、企业等)进行详细调查，在了解现行系统的概况，确定新系统功能的过程中，收集支持系统目标的根底数据及其处理方法。需求分析是在用户调查的根底上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。调查的重点是“数据〞和“处理〞，通过调查、收集与分析，获得用户对数据库的如下要求：(1)信息要求。指用户需要从数据库中获得信息的内容与性质。由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。(2)处理要求。指用户要完成什么处理功能，对处理的响应时间有什么要求，处理方式是批处理还是联机处理。(3)平安性与完整性要求。确定用户的最终需求是一件很困难的事，这是因为一方面用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因而往往不能准确地表达自己的需求，所提出的需求往往不断地变化。另一方面，设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。因此设计人员必须不断深入地与用户交流，才能逐步确定用户的实际需求。8.4.2需求分析的方法进行需求分析首先是调查清楚用户的实际要求，与用户达成共识，然后分析与表达这些需求。调查用户需求的具体步骤是：(1)调查组织机构情况。包括了解该组织的部门组成情况、各部门的职责等，为分析信息流程做准备。

(2)调查各部门的业务活动情况。包括了解各个部门输入和使用什么数据，如何加工处理这些数据，输出什么信息，输出到什么部门，输出结果的格式是什么，这是调查的重点。(3)在熟悉了业务活动的根底上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、平安性与完整性要求，这是调查的又一个重点。(4)确定新系统的边界。对前面调查的结果进行初步分析，确定哪些功能由计算机完成或将来准备让计算机完成，哪些活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。在调查过程中，可以根据不同的问题和条件，使用不同的调查方法。常用的调查方法有：(1)跟班作业。通过亲身参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较消耗时间。(2)开调查会。通过与用户座谈来了解业务活动情况及用户需求。(3)请专人介绍。

(4)询问。对某些调查中的问题，可以找专人询问。(5)设计调查表请用户填写。如果调查表设计得合理，这种方法很有效，也易于为用户接受。(6)查阅记录。查阅与原系统有关的数据记录。做需求调查时，往往需要同时采用上述多种方法。但无论使用何种调查方法，都必须有用户的积极参与和配合。调查了解了用户的需求以后，还需要进一步分析和表达用户的需求。在众多的分析方法中，结构化分析(SA，StructuredAnalysis)方法是一种简单实用的方法。SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。SA方法把任何一个系统都可以抽象为图8-13那样的数据流图(DFD，DataFlowDiagram)形式。图8-13系统高层的数据流图图8-13给出的只是最高层次抽象的数据流图，要反映更详细的内容，可将处理功能分解为假设干子功能，每个子功能还可以继续分解，直到把系统工作过程表示清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成假设干层次的数据流图。数据流图表达了数据和处理过程的关系。在SA方法中，处理过程的处理逻辑常常借助判定表或判定树来描述。系统中的数据那么借助数据字典(DD，DataDictionary)来描述。数据字典是系统中各类数据描述的集合，是进行详细的数据收集和数据分析所获得的主要成果。数据字典在数据库设计中占有很重要的地位。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五种成分的描述。其中数据项是数据的最小组成单位，假设干个数据项可以组成一个数据结构，数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。数据字典是在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善。需求分析阶段的文档是系统需求说明书，系统需求说明书主要包括数据流图、数据字典的雏形、各类数据的统计表格、系统功能结构图，并加以必要的说明编辑而成。系统需求说明书将作为数据库设计全过程的重要依据文件。8.5概念结构设计8.5.1概念结构在需求分析阶段所得到的应用需求应该首先抽象为信息世界的结构，才能更好地、更准确地用某一DBMS实现这些需求。概念结构的主要特点是：(1)能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。概念结构是对现实世界的一个真实模型。(2)易于理解。从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库设计成功的关键。(3)易于更改。当应用环境和应用要求改变时，容易对概念模型修改和扩充。(4)易于向关系、网状、层次等各种数据模型转换。概念结构是各种数据模型的共同根底，它比数据模型更独立于机器、更抽象，从而更加稳定。描述概念模型的有力工具是E–R模型。有关E–R模型的根本概念已在前面介绍。下面将用E–R模型来描述概念结构。8.5.2概念结构设计的方法和步骤设计概念结构通常采用的策略是自底向上的方法，即首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构，如图8-14所示。自底向上设计概念结构通常分为两步：第一步是设计各局部应用的局部视图；第二步是集成各局部视图，得到全局的概念结构。图8-14自底向上策略1．局部E–R模型的设计概念结构设计的第一步就是对需求分析阶段收集到的数据进行分类、组织，形成实体、实体的属性、标识实体的码，确定实体之间的联系类型(1∶1，1∶n，m∶n)，设计分E–R图。具体做法是：(1)选择局部应用。根据某个系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，作为设计分E–R图的出发点。让这组图中每一局部对应一个局部应用。由于高层的数据流图只能反映系统的概貌，而中层的数据流图能较好地反映系统中各局部应用的子系统组成，因此人们往往以中层的数据流图作为设计分E–R图的依据。(2)逐一设计分E–R图。选择好局部应用之后，就要对每个局部应用逐一设计分E–R图，亦称局部E–R图。在前面选好的某一层次的数据流图中，每个局部应用都对应了一组数据流图，局部应用涉及的数据都已经收集在数据字典中了。现在就是要将这些数据从数据字典中抽取出来，参照数据流图，标定局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型。这里最关键的步骤是确定实体和属性。就是说，首先要决定在每一个应用中包含哪些实体，这些实体又包含哪些属性。事实上，在现实世界中具体的应用环境常常对实体和属性已经作了大体的自然的划分。在数据字典中，“数据结构〞、“数据流〞和“数据存储〞都是假设干属性有意义的聚合，就可以作为实体对待。实体确定后，再确定实体之间的联系。这样就可建立起对应于每一个应用的局部E–R模型，然后再进行必要的调整。假设某工厂要设计一个查询系统。主管生产的部门要掌握产品的性能、各种零件的用料和每种产品的零件组成情况，并需据此编制工厂的生产方案；主管供给的部门需要了解产品的价格、各种产品的用料情况以及这些材料的价格与库存量，并需根据这些资料提出材料的订购方案。下面以供给部门的供给查询为例，可以把“产品〞、“材料〞确定为实体，前者应有“产品名〞和“价格〞两个属性，后者有“材料名〞、“价格〞和“库存量〞三个属性。实体确定后，再确定实体之间的联系。在本例中，“产品〞与“材料〞是通过“使用〞互相联系的，故可把“使用〞定为联系，而“用量〞是它的属性。把这些用E–R图来表示，就可得到供给部门的局部E–R模型，如图8-15所示。图8-15供给部门的局部E-R模型用类似的方法，可以建立生产部门的E–R模型，如图8-16所示。图8-16生产部门的局部E–R模型应该说明，实体和属性的划分并无绝对的标准。一般说来，凡不需要对它进行再描述的事物，均作为属性对待。举例说，假定材料不只存放在一个仓库，只须在图8-15的“材料〞实体下再增加一个属性“仓库号〞就可以了，这时的库存量也相应的改成每一仓库所拥有的材料数量。但如果需要把仓库本身的信息(例如“仓库号〞、“面积〞、“地点〞等)也存入数据库以备查询，就应将“仓库〞作为一个新的实体参加图中，把图8-15修改成如图8-17的样子。图8-17更改后的供给部门局部E–R模型局部E–R模型建立后，应对照每一个应用进行检查，确保模型能满足数据流图对数据处理的需要。2．全局E–R模型的设计各子系统的分E–R模型设计好以后，下一步就是要将各个应用的分E–R模型综合成系统总的概念模型(总E–R模型)。一般说来，综合可以有两种方式：(1)多个分E–R图一次集成；(2)逐步集成，用累加的方式一次集成两个分E–R图。第一种方式比较复杂，做起来难度较大；第二种方式每次只集成两个分E–R图，可以降低复杂度。无论采用哪种方式，每次集成局部E–R图时都需要分两步走：第一步合并，解决各分E–R图之间的冲突，将各分E–R图合并起来生成初步E–R图；第二步修改和重构，消除不必要的冗余，生成根本E–R图。1)合并分E–R图，生成初步E–R图各个局部应用所面向的问题不同，且通常是由不同的设计人员进行局部E–R图设计，这就导致各个分E–R图之间必定会存在许多不一致的地方，称之为冲突。因此合并分E–R图时并不能简单地将各个分E–R图画到一起，而是必须着力消除各个分E–R图中的不一致，以形成一个能为全系统中所有用户共同理解和接受的统一的概念模型。合理消除各分E–R图的冲突是合并分E–R图的主要工作与关键所在。各分E–R图之间的冲突主要有三类：属性冲突、命名冲突和结构冲突。(1)属性冲突：包括属性值的类型、取值范围、取值单位的不同。(2)命名冲突：包括实体名、联系名、属性名之间异名同义，或同名异义等。(3)结构冲突：例如同一对象在一个局部E–R图中作为实体，而在另一个局部E–R图中作为属性，同一实体在不同的E–R图中属性个数和类型不同等。属性冲突和命名冲突通常用讨论、协商等行政手段解决；结构冲突那么要认真分析后用技术手段解决，例如把实体变换为属性或属性变换为实体，使同一对象具有相同的抽象，又如，取同一实体在各局部E–R图中属性的并作为集成后该实体的属性集，并对属性的取值类型进行协调统一。在进行综合时，除相同的实体应该合并外，还可在属于不同分E–R图的实体间添加新的联系。图8-18显示了将图8-15和图8-16综合得到的E–R图。图中“材料〞与“零件〞两个实体之间的联系(“消耗〞)，就是综合后添加的。产品的属性也从分E–R图中的两项增加为三项。图8-18综合后的初步E–R图但是，这样综合得出的E–R图仅是初步的，很可能存在冗余的数据和实体间的冗余联系，需要进一步的修改。2)消除不必要的冗余，设计根本E–R图在初步E–R图中，可能存在一些冗余的数据和实体间冗余的联系。所谓冗余的数据是指可由根本数据导出的数据，冗余的联系是指可由其它联系导出的联系。冗余数据和冗余联系的存在，不仅将占用更多的存储空间，而且会增加数据维护工作，甚至可能在修改数据时破坏数据的完整性，应当予以消除。消除了冗余后的初步E–R图称为根本E–R图。仍以图8-18为例，产品对各种材料的“用量〞，实际上是根据产品包含的“零件数量〞和零件的材料消耗“定额〞推导出来的。也就是说，与“用量〞相比，“零件数量〞与“定额〞是更根本的数据，因为“用量〞可以由它们推导求得。如果保存“零件数量〞与“定额〞，就可以消除“用量〞。进一步说，“用量〞又是产品与材料间的联系(“使用〞)的属性，“用量〞省去了，“使用〞这个联系也可随之取消。这样，图8-18就可改进为图8-19，这就是包括生产和供给两个部门在内的系统的根本概念模型，或称为系统的根本E–R图。图8-19系统的根本E–R图8.6逻辑结构设计逻辑结构设计的任务就是把概念结构设计阶段设计好的根本E–R图转换为与选用的DBMS产品所支持的数据模型相符合的逻辑结构。逻辑结构设计包括初步设计和优化设计两个步骤。所谓初步设计就是按照E–R图向数据模型转换的规那么，将已经建立的概念模型转换为DBMS所支持的数据模型，这里只介绍E–R图向关系数据模型的转换原那么与方法；优化设计是对初步设计所得到的逻辑模型做进一步的调整和改进，如图8-20所示。图8-20逻辑结构设计的过程8.6.1E–R图向关系模型的转换E–R图向关系模型转换要解决的问题是如何将实体和实体间的联系转换为关系模式，以及如何确定这些关系模式的属性和码。关系模型的逻辑结构是一组关系模式的集合。E–R图那么是由实体、实体的属性和实体之间的联系三个要素组成的。所以将E–R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转换为关系模式，这种转换一般遵循如下原那么：(1)一个实体转换为一个关系模式。实体的属性就是关系的属性，实体的码就是关系的码。(2)一个1∶1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。如果转换为一个独立的关系模式，那么与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与某一端实体对应的关系模式合并，那么需要在该关系模式的属性中参加另一个关系模式的码和联系本身的属性。(3)一个1∶n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，那么与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。(4)一个m∶n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。(5)三个或三个以上实体间的一个多元联系可以转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。(6)具有相同码的关系模式可合并。下面结合图8-19的E–R图，把它转换为关系模型。关系的码用下横线标出。实体名：产品对应的关系模式：产品(产品名，价格，主要性能)实体名：零件对应的关系模式：零件(零件号，零件名)实体名：材料对应的关系模式：材料(材料名，价格，库存量)联系名：组成所联系的实体及其主码：产品(主码为“产品名〞)和零件(主码为“零件号〞)对应的关系模式：产品零件一览表(产品名，零件名，零件数量)联系名：消耗所联系的实体及其主码： 零件(主码为“零件号〞)和材料(主码为“材料名〞)对应的关系模式：零件用料表(零件号，材料名，定额)8.6.2数据模型的优化数据库逻辑设计的结果不是惟一的。为了进一步提高数据库应用系统的性能，还应该根据应用需要适当地修改、调整数据模型的结构，这就是数据模型的优化。关系数据模型的优化通常以标准化理论为指导，具体方法为(1)确定数据依赖。(2)对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。(3)按照数据依赖的理论对关系模式逐一进行分析，考察是否存在局部函数依赖、传递函数依赖等，确定各关系模式分别属于第几范式。(4)按照需求分析阶段得到的处理要求，分析这些模式对于这样的应用环境是否适宜，确定是否要对某些模式进行合并或分解。必须注意的是，并不是标准化程度越高的关系就越优。例如，当查询经常涉及到两个或多个关系模式的属性时，系统经常进行连接运算。连接运算的代价是相当高的，可以说关系模型低效的主要原因就是连接运算引起的。这时可以考虑将这几个关系合并成一个关系。因此在这种情况下，第二范式甚至第一范式也许是适宜的。对于一个具体的应用来说，到底标准化到什么程度，需要权衡响应时间和潜在问题两者的利弊决定。(5)对关系模式进行必要的分解，提高数据操作的效率和存储空间的利用率。常用的两种分解方法是水平分解和垂直分解。例如，某大学记载学生情况的关系，包括大专生、本科生与研究生三大类学生。如果多数查询一次只涉及其中的一类学生，就应把整个学生关系“水平分割〞为大专生、本科生、研究生三个关系，以便提高系统的查询效率。再如，设有记载职工情况的关系：EMP(工号，姓名，性别，年龄，职务，工资，工龄，住址，)如果经常查询的仅是前六项，后三项使用较少，就可将该关系“垂直分割〞为两个关系，即EMP1(工号，姓名，性别，年龄，职务，工资)和EMP2(工号，工龄，住址，)以便减少访问时传送的数据量，提高查询的效率。8.7物理结构设计数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。数据库的物理设计通常分为两步：(1)确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构；(2)对物理结构进行评价，评价的重点是时间和空间效率。如果评价结果满足原设计要求，那么可进入到物理实施阶段，否那么，就需要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。1．物理设计的内容和方法不同的数据库产品所提供的物理环境、存取方法和存储结构有很大差异，能供设计人员使用的设计变量、参数范围也很不相同，因此没有通用的物理设计方法可遵循，只能给出一般的设计内容和原那么。通常，关系数据库物理设计的内容主要包括：1)存储结构的设计确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、日志、备份等的存储安排和存储结构，确定系统配置等。确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，因此需要进行权衡，选择一个折中方案。2)存取方法的设计存取方法设计为存储在物理设备上的数据提供数据访问的路径。数据库系统是多用户共享的系统，对同一个关系要建立多条存取路径才能满足多用户的多种应用要求。物理设计的任务之一就是要确定选择哪些存取方法，即建立哪些存取路径。索引是数据库中一种非常重要的数据存取路径，在存取方法设计中要确定建立何种索引，以及在哪些表和属性上建立索引。通常情况下，对数据量很大，又需要做频繁查询的表建立索引，并且选择将索引建立在经常用做查询条件的属性或属性组，以及经常用做连接属性的属性或属性组上。物理设计的结果是物理设计说明书，包括存储记录格式、存储记录位置分布及存取方法，并给出对硬件和软件系统的约束。2．物理设计的评价数据库