关系型数据库设计

§3.3　关系型数据库设计

数据库系统设计是建立数据库及其应用系统的核心和基础，它要求对于指定的应用环境，构造出数据库模式，建立数据库及其应用，使系统能有效地存储数据，并满足用户的各种应用需求。

数据库建模的重点是逻辑数据模型和物理数据模型的建立，一个逻辑数据模型是由实体、属性及实体之间的关系构成。物理数据模型同样需要映射到逻辑数据模型中去。

当数据库建模把重点放在描绘数据库的时候，数据库设计着眼于从整个需求的产生、业务过程、逻辑分析、物理数据库构建到数据库的开发的全过程。在数据库设计中，物理数据模型包含在建模过程不仅仅包括表和列，而且还包括表空间、分隔、硬件以及整个数据库系统的组织。

一般按照规范化数据库的设计方法，常将数据库设计分为项目计划，需求分析，结构设计（包括概念设计，逻辑设计，物理设计）和系统实施几个阶段。

一、项目计划

1．项目计划的任务

为使项目的研发和管理工作顺利进行而制定合理的行动纲领（即项目计划），以便所有相关人员按照该计划有条不紊地开展工作。

其任务是进行问题定义、可行性分析、制订项目计划，项目是否值得开发，需要多长时间和多少投资，在项目计划阶段都要预先研究。

2．项目计划的内容

（1）问题定义

问题定义目的是弄清用户需要解决的问题是什么，以及项目所需的资源和经费。系统分析员深入现场，了解用户单位各层次人员对系统的要求，调查开发背景，经过调查分析，系统分析员用较短的时间对问题的一个总结，要求写出系统目标与范围的说明。

阶段成果是系统分析员提出关于问题性质、工程目标和规模的书面报告。并简要说明对问题的理解和初步设想，并在用户和项目经理的会议上认真讨论修改，最后得到一个双方都满意的文档。

（2）可行性分析

可行性分析的目的是用最小的代价在尽可能短的时间内确定问题是否能够解决，对研究中任何一种解决方案，均需要从经济、技术、运行和法律等方面来研究。在正式开发项目之前，必须根据客户可能提供的时间和资源条件进行可行性分析。这样可以避免人力、物力和财力的浪费。

可行性分析的根本任务是为项目开发推荐可以实施方案的建议。

可行性分析可分为技术可行性、经济可行性、运行可行性及法律可行性四个方面。

①技术可行性　需要根据用户的要求在系统的功能、性能及实现系统的约束条件几个方面，从技术实现的角度分析系统的可行性，考察实现系统是否存在技术难题？是否采用最先进的技术？技术风险有多大？实现系统的技术人员具备相关素质吗？在技术可行性分析方面关键是分析当前的技术是否支持系统开发的要求。

②经济可行性　成本-效益分析是实现计算机系统的重要内容，分析系统实现的经济合理性，提出开发的成本论证，估算成本与预期利润的对比，系统的实施程度和完成规模与项目的投入有密切的关系，精确的成本-效益分析是保证项目顺利实施的关键。项目实施的成本主要包括购置并安装软硬件及有关设备的费用，系统开发费用，系统安装、运行和维护费用及人员培训费用。

③运行可行性　由于系统使用时的范围与精度，系统执行时间，系统安全性，低成本和高可靠性的折中等因素的存在，而且这些因素均是彼此关联和制约的，因此运行的可行性也是可行性分析的范畴。

④法律可行性　现在系统的开发还必须考虑合同责任、法律责任、专利、版权、社会可接受性等责任，避免在社会上或经济上引起侵权、破坏或其他责任问题。

可行性分析的步骤包括：

①复查系统规模和目标　为确保分析员正在解决的问题的准确性，必须清晰地描述目标系统的一切限制和约束。

②研究现时系统　现时使用的系统是开发信息的重要来源，应该使用系统流程图的方式描述，仔细了解现时系统的优缺点、使用方式、文档、手册、代价和接口。

③导出目标系统的抽象模型　从现有的物理模型出发，使用数据流图和数据字典描述目标系统的逻辑模型。

④对新系统的逻辑模型分析　反复检查问题定义、工程规模和目标，与用户一道分析逻辑模型的每一个细节，避免系统对问题的遗漏和错误。

⑤评价可能解决方案，选择行动方案

⑥书写可行性报告，提交审查　将上述研究和讨论的结果以书面形式写成清晰的文档，提请项目负责人和用户仔细审查。

可行性分析的根本任务是为项目开发推荐可以实施方案的，其结果是让部门负责人做出是否继续进行工程的决定的重要依据。如果结果可行，应该立即开展制订项目计划的工作。

（3）制订项目计划

制订的项目计划是一种管理文档，供项目经理及小组负责人使用，在开发过程中，可以根据项目计划的要求安排和检查开发工作，并根据项目进展情况定期调整。

制订项目计划的内容包括：

①系统概述　内容包括项目目标、主要功能、系统特点以及关于开发工作的安排。

②系统资源　包括开发和运行该软件系统所需要的各种资源：硬件、软件、人员和组织机构等。

③费用预算　分阶段的人员费用、机时费用及其他费用。

④进度安排　各阶段起止时间、完成文档及验证方式。

⑤要交付的产品清单等文档。

（4）系统规划文档

系统规划文档也是一种需要在项目计划阶段完成的文档，它是描述基于计算机系统的功能、性能和支配系统开发的各种约束条件。它指明了各子系统在整个系统中的地位和作用，并描述了系统的输入/输出数据和控制信息。

系统规划文档应符合以下8条原则：

①从实现中抽出功能；

②要求一个面向过程的系统规划文档语言；

③一个规划文档必须围绕整个系统，而软件只是它的一个组成部分；

④一个规划文档必须围绕系统的操作环境；

⑤一个系统的规划文档必须是一个可认知的模型；

⑥一个规划文档必须是可操作的；

⑦系统的规划文档必须容许不完整的和可扩展的；

⑧一个规划文档必须容许是局部化的和松散耦合的。

二、需求分析

在项目确立以后，然后需要做的一个重要步骤就是需求分析，它是软件开发期的第一个阶段，也是关系到软件开发成败的关键步骤。它包括组织，部门，企业等进行详细调查，在了解现场系统的概况，确定新系统功能的过程中，收集支持系统目标的基础数据及其处理方法。需求分析是在用户调查的基础上，通过分析，逐步明确用户对系统的需求，包括数据需求和围绕这些数据的业务需求。

需求分析的过程就是系统分析员与用户共同协商，明确系统的全部功能、性能以及运行规格，并且使用软件开发人员与用户具有一致理解的语言准确表达出来。需求分析的结果是软件需求规格说明书。

通过需求分析，使得要求实现的用户功能、性能应满足以下各项：

①完整性　没有遗漏用户每个必要的需求；

②一致性　所有需求不相互矛盾；

③无二义性　用户与开发人员对于需求的理解是完全一致的；

④现实性　所有需求在项目资源保证下是现实的；

⑤可验证性　已经定义的用户需求可以确切地进行验证，性能指标是否达到具有客观的可度量准则；

⑥可跟踪性　定义的每个功能、性能可以追溯用户原始的需求。

需求规格说明书应包括详细的数据流图、数据字典、主要功能的逻辑处理描述。

1．需求分析的要求

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

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

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

在需求分析中，通过自顶向下，逐步分解的方法分析系统。任何一个系统都可以抽象为如图3.8所示的数据流图（Data Flow Diagram，DFD）形式。

数据流图是从“数据”和“处理”两方面来表达数据处理过程的一种图形化的表示方法。在数据流图中，用方框表示数据处理（加工）；用箭头的线段表示数据的流动及流动方向，即数据的来源和去向；用“书行框”表示要求在系统中存储的数据。在系统分析阶段，不必确定数据的具体存储方式。在此后的实现中，这些数据的存储形式可能是数据库中的关系，也可能是操作系统的文件。

数据流图中的“处理”抽象表达了系统的功能要求，系统的整体功能要求可以分解为系统的若干子功能要求，通过逐步分解的方法，一直可以分解到系统的工作过程表达清楚为止，在功能分解的同时，每个自功能在处理时所用的数据存储也被逐步分解，从而形成若干层次的数据流图。

图3.8　数据流图

（3）需求分析的步骤

①调查需求，获得现时系统的具体模型

征集需求收集是指收集数据，发生时间，频率，发生规则，约束条件，相互关系，计划控制及决策过程等。注意不仅要注重收集弄清处理流程还要注重规约。收集方法可以采用面谈，书面填表，开会调查，查看和分析业务记录，实地考察或资料分析法等，并用一个具体模型反映自己对现时系统的理解。

②对具体模型进行分析，抽象出现时系统的逻辑模型

去掉一些非本质的因素，完善本质内容，即可获得系统本质的逻辑模型。一般有包括对数据清单（数据元素表），业务活动清单（事物处理表），完整性及一致性要求，响应时间要求，预期变化的影响等的分析。它们是数据字典的雏形，主要包括：

数据项：它是数据的最小单位，包括项名、含义、别名、类型、长度、取值范围等；

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

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

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

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

③数据分析统计，建立目标系统的逻辑模型

目标系统是一个使用计算机的系统，它将完全实现现时系统的功能，并在性能和功能方面优于现时系统。

④完善和补充目标系统，写出完整的需求说明

分析围绕数据的各种业务处理功能，并修改和补充新的目标系统，使之符合系统功能、性能、运行及扩展的要求。

⑤需求说明的复审

确认文档齐全，符合用户全部需求。

需求分析过程如图3.9所示。

（4）需求分析说明书内容

需求分析说明书是用户、分析人员和软件设计人员交流的产物，也是编程人员和测试人员工作的基础和目标，更是用户验收的重要依据。

需求分析文档包括：

①引言　对软件的简要说明；

②数据描述　这是需要分析文档的重要内容，包括数据字典和数据流图两部分，分析描述系统中使用的一切数据的定义及表示系统的逻辑模型；

③功能描述　对软件功能要求的说明；

④性能描述　对软件将达到的性能的描述，如处理速度、响应时间、安全限制等；

⑤质量保证　说明软件交付使用前需要进行的功能测试和性能测试，并且规定源程序和文档应该遵守的各种标准；

⑥其他项目。

图3.9　需求分析过程

五、结构设计

经过详细的需求分析，项目的实施进入结构设计阶段，针对数据库设计，我们可以分概念模型设计、逻辑模型设计和物理模型设计三个子过程进行。

（一）概念模型设计

基于对目的应用或数据库的需求，产生适合信息需求的数据库概念结构，即概念模型。概念模型不依赖与计算机系统和具体的DBMS。

1．概念模型

此阶段产生的概念模型应具备：

（1）丰富的语义表达能力，能表达用户的各种需求，包括描述现实世界中各种对象及其复杂的联系，及用户对数据库对象的处理要求等。

（2）易于交流和理解。概念模型是数据库管理员（DBA），应用系统开发人员和用户之间的主要交流工具；

（3）易于更改。概念模型要能灵活地加以改变，以反映用户需求和环境的变化；

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

2．概念设计方法

概念设计方法最著名，最实用的是1976年提出的“实体-联系法”（Entity-Relationship Approach，E-R方法）。这种方法将现实世界的信息结构统一用属性，实体以及实体之间的联系，即E-R图来描述。

（1）E-R方法的基本术语

实体（entity）与属性（attribute）：实体与属性都是客观存在并可相互区分的事物。而属性是用以描述实体的某一特征的，而且其本身在一顶意义中，是不再需要描述事物。实体必须采用一组表征其特征的属性来描述。

属性与实体无一定的界限，在设计时可以归为属性是事物尽可能归为属性，以简化E-R图的处理，但也要根据需求而定。

联系（relationship）：联系是指实体之间存在的对应关系（它也具有属性）。一般可分为：一对一的联系（1：1）；一对多的联系（1：n）；多对多的联系（n：n）。

（2）E-R图中的表示：

在E-R图中，用长方形表示实体，用椭圆表示属性，用菱形表示联系。在图形内表示它们的名字，它们之间用无向相联系，表示联系时在线上表明是哪种对应关系的联系。

3．概念设计的策略和主要步骤

设计概念结构的策略有以下集中：

（1）自顶向下：首先定义全局概念结构框架，再做逐步细化。

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

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

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

这里对常用的自底向上设计策略给出的数据库概念设计的主要步骤：

（1）进行数据抽象，设计局部概念模式；

（2）将局部概念模式综合成全局概念模式；

（3）进行评审，改进。

4．采用E-R方法的数据库概念设计的步骤

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

（1）设计局部E-R模型：对系统相对独立的局部进行E-R模型设计，如图3.10所示。

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

把局部E-R图集成为全局E-R图时，一般采用两两集成的方法，即：先将具有相同实体的E-R两个图，以该相同实体为基准进行进程，如果还有相同实体的E-R图，再次集成，这样一直下去，直到所有的具有相同实体的局部E-R图都被集成，从而得到全局的E-R图。

（3）全局E-R图模型的优化：一个好的全局E-R图能反映用户功能需求外，还应满足下列条件：实体类型个数尽可能少，实体类型所含属性尽可能少，实体类型间联系无冗余，优化就是要达到这三个目的。为此，要合并相关实体类型，一般把1：1联系的两个实体类型合并，合并具有相同键的实体类型，消除冗余属性，消除冗余联系。但有时为提高效率，根据具体情况可存在适当冗余。

图3.10　局部E-R模型设计

图3.11　全局E-R模型的设计

（二）逻辑模型设计

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

1．E-R图的实体和联系类型，转换成选定的DBMS支持的数据类型。

（1）模式设计：子模式是应用程序与数据库的接口，允许有效访问数据库而不破坏数据库的安全性。

（2）模式评价：根据定量分析和性能测算，对逻辑数据库结构（模型）作出评价，定量分析是指处理频率和数据容量及其增长情况。性能测算是指逻辑记录访问是指逻辑记录访问的数目，一个应用程序传输的总字节数和数据库的总字节数等。

（3）优化模式：为使模式适应信息的不同表示，可利用DBMS功能，如建索引，散列功能等，但不修改数据库信息。

2．E-R图模型向关系数据库模型的转换。

E-R模型可以向现有的各种数据库模型转换，对不同的数据库模型有不同的转换规则。向关系模型转换的规则是：

（1）一个实体类型转化成一个关系模式，实体的属性就是关系的属性。

（2）一个联系类型转换成一个关系模式，参与该联系类型的各种实体的键的属性转换成关系的属性，该关系的键有三种可能情况。

①若联系为1：1联系，则每个实体的键均是该关系的辅键(或选键)；

②若联系为1：n联系，则关系的键是为n端实体的键；

③若联系为n：n联系，则关系的键为诸相关实体的键的组合。

3．关系数据库逻辑设计过程。

如图3.12所示。

图3.12　逻辑设计

（1）导出初始关系模式：将E-R图按规则转换成关系模式。

（2）规范化处理：消除异常，改善完整性，一致性和存储效率，一般达到3NF就行。规范化过程实际上就是单一化的过程，即让一个关系描述一个概念，若多余一个概念的就把它分离出来。

（3）模式评价：模式评价的目的是检查数据库模式是否满足用户的要求，它包括功能评价和性能评价。

（4）优化模式：如模式有疏漏要新增关系或模式，如模式的性能不好则要采用合并，分解或选用另外结构等。

①合并：对具有相同关键字的关系模式，如它们的处理主要是查询操作，切常在一起使用，可将这类关系模式合并。

②分解：虽已达到规范化，但因某些属性过多时，可将它分解成两个或多个关系模式。这种属性分解称为垂直分解。要注意的是，垂直分解所得到的每一关系模式。这种属性组分解称为垂直分解。要注意的是，垂直分解所得到的每一关系都应包含主键。

（5）形成逻辑设计说明书，内容包括：

①应用设计指南：反问方式、查询路径、处理要求、约束条件等。

②物理设计指南：数据访问量、传输量、存储量、递增量等。

③模式及子模式的集合。模式和子模式可用DBMS语言描述，也可列表描述。

（三）物理设计

逻辑设计完成后，设计者应该开始考虑数据库的物理实现问题，即物理设计，数据库的物理设计的主要任务是：对数据库中数据在物理设备上的存放结构和存取方法进行设计。数据库的物理设计要考虑数据库大小，数据库运行环境，数据的划分，所选择的DBMS的特性及应用程序如何与数据库通信几个关键问题。

1．物理设计的步骤

物理设计可分为五步，前三步为结构设计，后两步为约束和程序设计，如图3.13所示。

图3.13　物理设计

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

（2）存储方法设计：物理设计中最重要的一个考虑，是把存储记录在全范围内进行物理安排，存储的方式有4种：顺序存储，平均查询次数为记录个数的二分之一 ；散列存储，查询次数由散列算法决定；索引存储，要确定建何种索引，及建立索引的表的属性；聚簇存储（cluster），聚簇是指将不同类型的记录分配到相同的物理区域中去，以充分利用物理顺序性的优点，从而提高访问速度，即把经常在一起使用的记录聚簇在一起，以减少物理I/O次数。

（3）访问方法设计：访问方法设计为存储在物理设备上的对数据提供存储结构和查询路径，这与数据库管理系统有很大关系。

（4）完整性和安全性考虑：根据逻辑设计说明书中提供的对数据库的约束条件，具体的操作系统及数据库管理系统的性能特征和硬件环境，设计数据库的完整性和安全措施。

（5）应用设计：包括人机接口设计，如菜单、屏幕设计、I/O格式设计、代码设计、处理加工设计等。

（6）形成物理设计说明书：在物理设计中，应充分注意物理数据的独立性。所谓物理数据的独立性，是指消除由于物理数据结构设计变动而引起对应用程序的修改。

物理设计的结果是物理设计说明书，其内容包括存储记录格式、存储记录位置分布及访问方法，能满足的操作需求，并给出对硬件和软件系统的约束。

2．物理设计的性能

设计者能够灵活地对初始设计过程和未来的变化作出决策。假设数据库性能用“开销(cost)”，即时间、空间及可能的费用来衡量，对于应用系统，总的开销则包括规划开销、设计开销、实施和测试开销、操作开销和运行维护开销。

对物理设计者来说，主要考虑操作开销，即为使用户获得及时响应而需要的开销和计算机资源的开销。可分为如下几类：

（1）查询和响应时间：响应时间定义为从查询开始到查询结果开始显示之间所经历的时间，它包括CPU服务时间，CPU队列等待时间，I/O队列等待时间，封锁延迟时间和通信延迟时间。一个好的应用程序设计可以减少CPU服务时间和I/O服务时间，例如，如果有效地使用数据压缩技术，选择好访问路径和合理安排记录的存储等，都可以减少服务时间。

（2）更新事务的开销：主要包括修改索引，重写物理块或文件，写校验等方面的开销。

（3）报告生成的开销：主要包括检索、重组、排序和结果显示方面的开销。

（4）主存储空间开销：包括程序和数据所占有的空间的开销。一般对数据库设计者来说，可以对缓冲区分配（包括缓冲区个数和大小）做适当的调整，以减少空间开销。

（5）辅助存储空间：分为数据块和索引块两种空间。设计者可以控制索引快的大小、装载因子、指针选择项和数据冗余度等。

实际上，数据块设计者能有效控制I/O服务和辅助空间；有限地控制封锁延迟，CPU时间和主存空间；而完全不能控制CPU和I/O队列等待时间，数据通信延迟时间。

六、系统实施

1．数据库的实现

（1）根据逻辑设计和物理设计的结果，在计算机上建立起实际数据库结构，装入数据，测试和运行的过程称为数据库的实现。这个阶段的主要工作如图3.14所示。

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

（3）装入实际数据，即数据库加载，建立起实际的数据库。

图3.14　数据库实施

2．其他设计

其他设计工作包括数据库的安全性，完整性，一致性和可恢复性等的设计。这些设计总是以牺牲效率为代价的。设计人员的任务就是要在效率和尽可能多的功能之间进行合理权衡。

（1）数据库的再组织：设计对数据库的概念，逻辑和物理结构的改变称为再组织（reorganization），改变概念或物理结构又称“再构造”（restructuring），物理结构改变称“为再格式化”（reformating）。再组织通常是由于环境需求的变化或性能原因而引起的。一般DBMS特别是RDBMS都提供数据库的再组织实用程序。

（2）故障恢复方案设计：数据库设计中考虑的故障恢复方案，一般都是基于DBMS系统提供的故障恢复手段。如果DBMS已提供了完善的软硬件故障恢复和存储介质的故障恢复手段，那么设计阶段的任务就简化为确定系统登录的物理参数、无缓冲区个数、大小、逻辑块的长度、物理设备等；否则，就要指定人工备份方案。

（3）安全性考虑：许多DBMS都有描述各种对象（如记录、数据项）的存取权限的成分，在设计时，根据对用户需求分析，规定相应的存取权限。子模式是实现安全性要求的一个重要手段。也可以在应用程序中设置密码，对不同的使用者给予一定的密码，以密码控制使用级别。

（4）事务控制：大多数DBMS都支持事务概念，以保证多用户环境下的数据完整性和一致性。有人工和系统两种控制办法，系统控制以数据操作语句为单位，人工控制则由程序员以事物的开始和结束语句显示实现。大多数DBMS提供封锁粒度的选择，封锁粒度一般有表级，页面级记录和数据项级。粒度越大控制越简单，但并未发生性能差，这些在设计中都要运筹考虑。

3．运行与维护

数据库投入正式运行，标志着数据库设计和应用开发工作的结束和维护阶段的开始。本阶段的主要工作是：

（1）维护数据库的安全性和完整性：即调整授权和密码，转储及恢复数据库。

（2）检测并改善数据库性能：分析评估存储空间和响应时间，必要时进行再组织。

（3）增加新的功能：对现有功能按用户需要进行扩充。

（4）修改错误：包括程序和数据。

目前，随着DBMS功能和性能的提高，特别是在关系型DBMS中，物理设计的大部分功能和性能可由DBMS来承担，所以选择一个合适的DBMS能使数据库物理设计变得十分简单。