9.2.6数据库设计过程

数据库设计工作量大而且过程比较复杂，是一项数据库工程也是一项庞大的软件工程。数据库设计包括结构特性的设计和行为特性的设计两方面的内容。结构特性的设计是指确定数据库的数据模型。数据模型反映了现实世界的数据及数据间的联系，要求在满足应用需求的前提下，尽可能减少冗余，实现数据共享。行为特性的设计是指确定数据库应用的行为和动作，应用的行为体现在应用程序中，所以行为特性的设计主要是应用程序的设计。

可将数据库设计分为6个阶段：需求分析，概念结构设计，逻辑结构设计，物理结构设计，数据库实施，数据库运行和维护。数据库设计的各阶段可以和软件工程的各阶段对应起来，软件工程的某些方法和工具同样可以适用于数据库工程。数据库工程和传统的软件工程的区别在于：软件工程中比较强调行为特性的设计；在数据库工程中，由于数据库模型是一个相对稳定的并为所有用户共享的数据基础，所以数据库工程中更强调对于结构特性的设计，并与行为特性的设计结合起来。

下面对数据库设计各个阶段的任务和方法做一个简单介绍。

1.需求分析

需求分析阶段的任务是：对现实世界要处理的对象（组织、部门、企业等）进行详细调查，在了解现行系统的概况、确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。需求分析是在用户调查的基础上，通过分析逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务处理需求。

调查的重点是"数据"和"处理".通过调查要从用户中获得对数据库的下列需求：

·信息需求。信息需求定义未来信息系统用到的所有信息，弄清用户将向数据库输入什么样的数据，从数据库中要求获得什么样的内容，将要输出什么样的信息。即在数据库中需存储哪些数据、对这些数据将作如何处理等。要能描述数据间本质上和概念上的联系，描述信息的内容和结构，以及信息之间的联系等性质。

·处理需求。处理需求定义未来系统数据处理的操作功能，描述操作的优先次序，包括操作执行的频率和场合，操作与数据之间的联系。处理需求还包括弄清用户要完成什么样的处理功能、每种处理的执行频度、用户要求的响应时间，以及处理的方式是联机处理还是批处理等等。同时也定义了安全性和完整性的约束。

在需求分析中，通过自顶向下、逐步分解的方法分析系统。分析的结果用数据流图DFD（dataflowdiagram）进行图形化的描述。通过数据流图，可以清晰地表达系统中的功能要求和数据流向。而且，数据流图可以是分层次的，系统的整体功能要求可以分解为系统的若干子功能要求，通过逐步分解的方法，一直可以分解到将系统的工作过程表达清楚为止。在功能分解的同时，每个功能在处理中所用的数据存储也在逐步分解，从而形成若干层次的数据流图。

除数据流图外，还采用一些规范表格对于数据分析的结果描述做补充描述。一般有数据清单（数据元素表），业务活动清单（事务处理表），完整性及一致性要求，响应时间要求，预期变化的影响等。它们是数据字典的雏形，具体内容主要包括：

·数据项。它是数据的最小单位，包括项名、含义、别名、类型、长度、取值范围及与其他项的逻辑联系等；

·数据结构。是若干数据项的有序集合，包括数据结构名、含义、组成的成分等。

·数据流说明。可以是数据项，也可以是数据结构。表示某一加工的输入输出数据；包括数据流名、说明、流人的加工名、流出的加工名、组成的成分等。

·数据存储说明。加工中需要存储的数据，包括数据存储名、说明、输入数据流、输出数据流、组成的成分、数据量、存储方式、操作方式等。

·加工过程。包括加工名、加工的简要说明、输入输出数据流等。

需求分析的阶段成果是产生系统需求说明书，系统需求说明书主要包括数据流图、数据字典的雏形表格、各类数据的统计表格、系统功能结构图等。

2.概念结构设计

数据库概念结构设计的任务是产生反映企业信息需求的数据库概念结构，即概念模型。概念模型是不依赖于计算机系统和具体的DBMS的。

概念模型应具备以下特点：

·有丰富的语义表达能力。能表达用户的各种需求，包括描述现实世界中各种事物及事物之间的联系，能满足及用户对数据的处理要求。

·易于交流和理解。概念模型是DBA,应用系统开发人员和用户之间的主要交流工具。·易于变动。概念模型要能灵活地加以改变，以反映用户需求和环境的变化。

·易于向各种数据模型转换，易于从概念模型导出与DBMS有关的逻辑模型。

设计概念结构的策略有如下几种：

·自顶向下。首先定义全局概念结构的框架，再作逐步细化。

·自底向上。首先定义每一局部应用的概念结构，然后按一定的规则把它们集成，从而得到全局概念结构。

·由里向外。首先定义最重要的那些核心结构，再逐渐向外扩充。

·混合策略。把自顶向下和自底向上结合起来。自顶向下设计一个概念结构的框架，然后以它为骨架再自底向上设计局部概念结构，并把它们集成。

最常用的设计策略是自底向上设计策略。

设计数据库概念模型的最着名、最常用的方法是P.P.S.chen于1996一年提出的"实体一联系方法"（Entity-RelationshipApproach），简称E-R方法。它采用E-R模型将现实世界的信息结构统一用实体、属性以及实体之间的联系来描述。

实体是客观存在并可互相区分的"事物".实体必须有一组表征其特征的"属性"来描述。

属性与实体无截然划分的界限，描述另一事物的某一特征的、而且其本身在一定意义上说是不再需要描述的事物一般归为属性。在设计时可以归为属性的事物尽可能归为属性，以简化E-R图的处理，但也要根据需求而定。

例如，工种通常为职工的属性，但要涉及劳保部门时，它就成为一个实体，可用一些属性来描述，

工种：工种号，工种名，工种类型，工种补贴，保健费…

联系是指实体之间存在的对应关系，一般可分为一对一的联系（1:1），一对多的联系（1:n）和多对多的联系（m:n）。

联系也可以有属性，例如学生选修课程的联系，可以有属性"成绩".

在实体一联系方法中用E-R图直观地表示E-R模型。在E-R图中，用长方形表示实体，用椭圆形表示属性，用菱形表示联系。在图形内标识它们的名字，它们之间用无向线段相连，表示联系的线段上标明是哪种联系。

采用E-R方法的数据库概念结构设计可分为三步进行。

（1）设计局部E-R模型。局部E-R模型的设计内容包括确定局部E-R结构的范围、定义属性、定义实体、定义联系等。

（2）设计全局E-R模型。这一步是将所有局部的E-R图集成为全局的E-R图，即全局的概念模型。

把局部E-R图集成为全局E-R图时，可以采用一次将所有的局部E-R图集成在一起的方式，也可以采用逐步集成进行累加的方式，一次只集成两个局部E-R图，这样复杂度较低。

当将局部的E-R图集成为全局的E-R图时，可能存在3类冲突。

·属性冲突：包括类型、取值范围、取值单位的冲突。

·结构冲突：例如同一对象在一个局部E-R图中作为实体，而在另一个局部E-R图中作为属性，同一实体在不同的E-R图中属性个数和类型不同等。

·命名冲突：包括实体类型名、联系类型名之间异名同义，或同名异义等。

属性冲突和命名冲突通常用讨论、协商等行政手段解决；结构冲突则要认真分析后用技术手段解决，例如把实体变换为属性或属性变换为实体，使同一对象具有相同的抽象；又如，取同一实体在各局部E-R图中属性的并作为集成后该实体的属性集，并对属性的取值类型进行协调统一。

（3）全局E-R模型的优化。一个好的全局ER模式除能反映用户功能需求外，还应满足下列条件：实体类型个数尽可能少，实体类型所含属性尽可能少，实体类型间联系无冗余。优化就是要达到这3个目的，即相关实体类型的合并，一般把具有相同码的实体类型进行合并，还可以考虑将1:1联系的两个实体类型合并为一个实体类型；冗余属性的消除；冗余联系的消除。但要注意效率，根据具体情况可存在适当冗余。图9.13是两个局部的E-R图集成的全局E-R图的举例。

3.逻辑结构设计

逻辑结构设计的目的是从概念模型导出特定的DBMS可以处理的数据库的逻辑结构（数据库的模式和外模式），这些模式在功能、性能、完整性和一致性约束及数据库可扩充性等方面均应满足用户提出的要求。

特定的DBMS可以支持的数据模型包括层次模型、网状模型、关系模型、面向对象模型等。下面我们仅对概念模型向关系模型的转换进行讨论。

E-R模型向关系模型转换的规则是：

·一个实体类型转换成一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。对于实体之间联系的转换则有以下不同的情况（（2）一（5））：

·一个1,1联系可以转换为一个独立的关系模式，也可以与联系的任意一端实体所对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，每个实体的码均是该关系的候选码。如果与联系的任意一端实体所对应的关系模式合并，则需要在该关系模式的属性中加入另一个实体的码和联系本身的属性。

·一个1:n联系可以转换为一个独立的关系模式，也可以与联系的n端实体所对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而联系的码为n端实体的码。如果与联系的n端实体所对应的关系模式合并，则需要在该关系模式的属性中加入1端实体的码和联系本身的属性。

·一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。

·3个或3个以上的实体间的多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为各实体码的组合。

具有相同码的关系模式可合并。

转换得到的关系模式需要根据规范化理论进行规范化处理。规范化过程实际上是一个关系模式分解的过程，对于转换得到的规范化程度较低的关系模式进行分解，以达到所要求的更高的规范化程度。关于数据库设计过程中规范化理论的应用在9.2.7节还要进行讨论。

4.物理结构设计

数据库的物理设计是对已确定的逻辑数据库结构，利用DBMS所提供的方法、技术，以较优的存储结构和数据存取路径、合理的数据存放位置以及存储分配，设计出一个高效的、可实现的物理数据库结构。

物理设计常常包括某些操作约束，如响应时间与存储要求等。

由于不同的DBMS所提供的硬件环境和存储结构、存取方法不同，提供给数据库设计人员的系统参数及其变化范围不同，因此物理结构设计没有一个放之四海而皆准的原则，只能提供一些技术和方法供参考。

（1）存储记录的格式设计。

对数据项类型特征作分析，对存储记录进行格式化，决定如何进行数据压缩或代码化。使用"记录的垂直分割"方法，对含有较多属性的关系，按其中属性的使用频率不同进行分割；或使用"记录的水平分割"方法，对含有较多记录的关系，按某些条件进行分割。并把它们定义在相同或不同类型的物理设备上，或在同一设备的不同区域上，从而使访问数据库的代价最小，提高数据库的性能。

（2）存储方法设计。

物理设计中最重要的一个考虑是把存储记录在全范围内进行物理安排。包括：

·顺序存放，平均查询次数为关系的记录个数的二分之一。

·散列存放，查询次数由散列算法决定。

·聚簇（cluster）存放，"记录聚簇"是指将不同类型的记录分配到相同的物理区域中去，充分利用物理顺序性优点，提高访问速度。使经常在一起使用的记录聚簇在一起，以减少物理I/O次数。

（3）存取方法设计。

存取方法设计为存储在物理设备上的数据提供数据访问的路径。索引是数据库中一种非常重要的数据存取路径。在存取方法设计中要确定建立何种索引，以及在哪些表和属性上建立索引。

通常情况下，对于数据量很大，又需要做频繁的查询的表建立索引，并且选择将索引建立在经常用做查询条件的属性或属性组，以及经常用做连接属性的属性或属性组上。

5.数据库实施

数据库实施阶段指的是基于数据库逻辑结构设计和物理结构设计的结果，在计算机上建立起实际数据库结构，装人数据，并进行测试和试运行的过程。该阶段的主要工作如下：

·建立实际的数据库结构。

·装人试验数据对应用程序进行测试，以确认其功能和性能是否满足设计要求，并检查对空间的占有情况。

·装人实际数据，即数据库加载，建立起实际的数据库。

在这个阶段中还要进行一些其他工作，包括加强数据库的安全性、完整性控制，及保证一致性、可恢复性等。这些总是以牺牲效率为代价的，设计人员的任务就是要在实现代价和尽可能多的功能之间进行合理平衡。

6.数据库运行和维护

数据库投入正式运行，标志着数据库设计和应用开发工作的结束和运行维护阶段的开始。在数据库运行阶段，对数据库经常性的维护工作主要由DBA负责，主要工作包括：

·数据库的转储和恢复。DBA要针对不同的应用要求制定不同的转储计划，以保证一旦发生故障能尽快将数据库恢复到某种一致状态，并尽可能减少对数据库的破坏。

·数据库的安全性、完整性控制。DBA要根据数据库系统运行过程中实际情况的变化修改安全性控制，及时调整授权和密码等。在数据库系统运行的过程中，数据完整性约束条件也会发生变化，也需要DBA不断修正，以满足用户要求。

·数据库性能的监督、分析和改造。目前有些DBMS产品提供了监测系统性能参数的工具，DBA可以利用这些工具方便地得到系统运行过程中一系列性能参数的值。通过分析这些数据DBA可以判断当前系统运行状况是否最佳，并作出相应的参数调整。

·数据库的重组织和重构造。数据库系统运行一段时间之后，由于记录不断增、删、改，会使数据库的物理存储情况变化，数据库性能下降。这时需进行数据库重组织，按数据库的原设计要求重新安排存储位置，回收垃圾，减少指针链等，以提高系统性能。

由于数据库应用环境发生变化、增加了新的应用或新的实体、取消了某些应用、某些实体与实体间的联系发生了变化等原因，使原来的数据库设计不能满足新的需求，这时就需进行数据库重构造，调整数据库的逻辑结构和物理结构，以满足新的应用需求。

章节目录：系统分析师考试教材第9章数据库与数据仓库 

返回全书目录：系统分析师章节辅导教程