1.7 数据库设计_MySQL数据库技术与应用-QQ阅读男生轻小说网

上QQ阅读APP看书，第一时间看更新

1.7 数据库设计

1.7.1 数据库设计概述

数据库设计是建立数据库及其应用系统的技术，是信息系统开发过程中的关键技术。数据库设计的主要任务是对于一个给定的应用环境，根据用户的各种需求，构造出最优的数据库模式，建立数据库及其应用系统，使之能够有效地对数据进行管理。数据库设计的内容主要有两个方面，分别是结构特性设计和行为特性设计。结构特性设计是指确定数据库的数据模型，在满足要求的前提下尽可能地减少冗余，实现数据共享。行为特性设计是指确定数据库应用的行为和动作，应用的行为由应用程序体现，所以行为特性的设计主要是应用程序的设计。在数据库领域中，通常会把使用数据库的各类系统称为数据库应用系统。因此，在进行数据库设计时，要和应用系统的设计紧密联系起来，也就是把结构特性设计和行为特性设计紧密结合起来。

针对数据库的设计，人们不断地研究与探索，在不同阶段从不同角度提出了各种数据库设计方法，这些方法运用软件工程的思想，提出了各种设计准则和规程，都属于规范设计法。依据规范设计的方法，考虑数据库及其应用系统开发的全过程，人们将数据库系统设计分为六个阶段：需求分析、概念结构设计、逻辑结构设计、数据库物理设计、数据库实施、数据库运行和维护，如图1-16所示。

图1-16　数据库设计步骤

1.7.2 需求分析

需求分析就是分析用户的各种需求。进行数据库设计首先必须充分地了解和分析用户需求（包括数据与处理）。作为整个设计过程的起点，需求分析是否充分和准确，决定了在其上构建数据库的速度与质量。需求分析没做好，会导致整个数据库设计不合理、不实用，必须重新再设计。

需求分析的任务，就是对现实世界要处理的对象进行详细调查，充分了解现有系统的工作情况或手工处理工作中存在的问题，尽可能多地收集数据，明确用户的各种实际需求，然后在此基础上确定新的系统功能，新系统还得充分考虑今后可能的扩充与改变，不能仅按当前应用需求来设计。

调查用户实际需求通常按以下步骤进行。

（1）调查现实世界的组织机构情况。确定数据库设计与组织机构中的哪些部门相关，了解这些部门的组成情况及职责，为分析信息流程做准备。

（2）调查相关部门的业务活动情况。要调查相关部门需要输入和使用什么数据，这些数据该如何加工与处理，各部门需要输出哪些信息，这些信息输出到哪些部门，输出信息的格式是什么，这些都是调查的重点。

（3）在熟悉了业务活动的基础上，协助用户明确对新系统的各种实际需求，包括信息要求、处理要求、安全性与完整性要求，这也是调查过程中非常重要的一点。

（4）确定新系统的边界。对前面的调查结果进行初步分析，确定哪些功能现在就由计算机完成，哪些功能将来准备让计算机完成，哪些功能由人工完成。由计算机完成的功能就是新系统应该实现的功能。

在调查过程中根据不同的问题与条件，可以采用不同的调查方法。

（1）开调查会。通过与用户座谈的方式来了解业务活动情况及用户需求。

（2）设计调查表请用户填写。提前设计一个合理的针对业务活动的调查表，并将此表发给相关的用户进行针对性调查。

（3）查阅记录。查阅与原系统有关的数据记录。

（4）询问。对某些调查中的问题，可以找专人询问。

（5）请专人介绍。请业务活动过程中的用户或对业务熟练的专家介绍业务相关知识和活动情况，设计人员从中了解并询问相关问题。

（6）跟班作业。通过亲自参与各部门业务活动来了解用户的具体需求，但是这种方法比较耗时。

调查过程中的重点在于“数据”与“处理”。通过调查、收集与分析，获得用户对数据库的如下要求。

（1）信息需求。指用户需要从数据库中获得信息的内容与实质。也就是将来要往系统中输入什么信息及从系统中得到什么信息，由用户对信息的要求就可以导出对数据的要求，即在数据库中需存储哪些数据。

（2）处理要求。用户要实现哪些处理功能，对数据处理响应时间有什么样的要求及要采用什么样的数据处理方式。

（3）安全性和完整性要求。数据的安全性措施和存取控制要求，数据自身的或数据间的约束限制。

了解了用户的实际需求以后，还需要进一步分析和表达用户的需求。在众多的分析方法中，结构化分析方法（Structured Analysis，简称SA方法）是一种简单实用的方法。SA方法从最上层的系统组织结构入手，采用自顶向下、逐层分解的方式分析系统。

经过需求分析阶段后会形成系统需求说明书，说明书中要包含数据流图、数据字典、各类数据的统计表格、系统功能结构图和必要的说明。该说明书在数据库设计的全过程中非常重要，是各阶段设计所依据的文档。

1.7.3 概念结构设计

概念结构设计是整个数据库设计的关键，是将需求分析阶段得到的用户需求进行总结、归纳，并抽象成信息结构即概念模型的过程。

概念结构设计通常有四类方法：

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

（2）自底向上。首先定义各局部应用的概念结构，再按一定规则将它们集成起来，最后得到全局概念结构。

（3）逐步扩张。首先定义最重要的核心概念结构，然后向外扩张，以滚雪球的方式逐步生成其他概念结构，直至全局概念结构。

（4）混合策略。将自顶向下和自底向上相结合，先用自顶向下方法设计一个全局概念结构的框架，然后再以它为框架集成由自底向上方法设计的各局部概念结构。

在设计过程中通常先自顶向下进行需求分析，然后再自底向上设计概念结构。其方法如图1-17所示。

图1-17　自顶向下需求分析与自底向上概念结构设计

概念结构设计主要应用E-R图（Entity Relationship Diagram，实体-联系图）来完成。按照图1-17所示的自顶向下进行需求分析与自底向上进行概念结构设计的方法，概念结构的设计可以按照以下步骤进行。

1. 对数据进行抽象并设计局部E-R图

概念结构是对现实世界的一种抽象。抽象就是对客观的人、事、物和概念进行处理，把所需要的共同特性抽取出来而忽略非本质的内容，并把这些共同特性用概念精准地描述出来，组成模型。抽象通常有三种方法。

（1）分类（Classification）：定义某一类概念作为现实世界中一组对象的类型，这些对象具有某些共同的特性和行为。在E-R模型中，实体型就是这种抽象。例如，张三丰是学生，具有学生们共同的特性和行为。

（2）聚集（Aggregation）：定义某一类型的组成成分。在E-R模型中若干属性的聚集组成了实体型。例如学生有学号、姓名、系别、专业、班级等属性。有时某一类型的组成成分也可能是一个聚集，例如部门有部门名称、位置及经理等属性，而经理又有姓名、年龄、性别等属性。

（3）概括（Generalization）：定义类型之间的一种子集联系。例如学生是一个实体型，小学生、本科生也是实体型。但小学生和本科生均是学生的子集。

概念结构设计首先就是要利用上面的抽象机制对需求分析阶段收集到的数据分类、组织（聚集），形成实体型、属性和码，确定实体型之间的联系类型（一对一、一对多或多对多），进而设计E-R图。在设计的过程中应该遵循这样一个原则：现实世界中的事物能作为属性对待的，尽量作为属性对待。这点可以按以下两条准则来考虑。

（1）作为属性，不能再具有需要描述的性质，也就是属性是不可分的数据项。

（2）属性不能与其他实体型有联系，即E-R图所表示的联系是实体型之间的联系。

只要满足了以上两条准则，通常可作为属性对待。例如，职工是一个实体型，可以包括职工号、姓名、年龄等属性，如果职称没有与工资、福利挂钩就可以将其作为该实体型的属性，但如果不同的职称有不同的工资和住房标准等，则职称作为一个实体型会更合适，它的属性可以包括职称代码、工资、住房标准等。

2. 将各局部E-R图进行合并，形成初步E-R图

各局部E-R图设计完成后，还需要对它们进行合并，集成为系统整体的E-R图，当然，形成的这个E-R图只是一个初步的E-R图。局部E-R图的集成有两种方法。

（1）一次集成法，就是一次性地将所有局部E-R图合并为全局E-R图。此方法操作比较复杂，不易实现。

（2）逐步集成法，先集成两个局部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图中呈现不同的类型。例如E1与E2在一个局部E-R图中是一对一联系，而在另一个局部E-R图中是多对多联系；又或者在一个局部E-R图中E1与E2有联系，而在另一个局部E-R图中E1、E2和E3三者之间有联系。解决方法是根据应用语义对实体联系的类型进行整合或调整。

3. 消除不必要的冗余，形成基本E-R图

在合并后的初步E-R图中，可能存在冗余的数据和冗余的联系。所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。冗余的数据和联系容易破坏数据库的完整性，增加数据库维护的难度，应该消除。但是，并不是所有的冗余都要消除，有时为了提高效率是可以允许冗余的存在的。因此在概念结构设计阶段，哪些冗余信息要消除，哪些可以保留，需要根据用户的整体需求来确定。消除了冗余的初步的E-R图称为基本E-R图，它代表了用户的数据要求，决定了下一步的逻辑结构设计，是成功创建数据库的关键。

1.7.4 逻辑结构设计

概念结构设计阶段得到的E-R图是反映了用户需求的模型，它独立于任何一种数据模型，独立于任何一个数据库管理系统。逻辑结构设计阶段的任务就是将上一阶段设计好的基本E-R图转换为与选用的数据库管理系统产品所支持的数据模型相符合的逻辑结构。

目前的数据库应用系统通常采用支持关系模型的关系数据库管理系统，所以这里只讨论关系数据库的逻辑结构设计，也就是只介绍如何将E-R图向关系模型转换的原则与方法。

关系模型的逻辑结构是一组关系模式的集合。概念结构设计阶段得到的E-R图是由实体、实体的属性和实体间的联系三个要素组成的。所以E-R图向关系模型的转换要解决的问题是如何将实体、实体的属性和实体间的联系转换为关系模式。在转换过程中要遵循的原则如下。

（1）一个实体集转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码。

（2）可以将1:1联系转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。若为前者，则与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，且每个实体的码均是该关系的候选码。若为后者，则需要在某一关系模式的属性中加入另一个关系模式的码和联系本身的属性。

【例1-1】将图1-18所示的含有1:1联系的E-R图按上述规则转换为关系模式。

方案1：联系转换为一个独立的关系模式：

职工（职工号，姓名，年龄）；

产品（产品号，产品名，价格）；

负责（职工号，产品号）。

方案2：“负责”与“职工”关系模式合并：

职工（职工号，姓名，年龄，产品号）；

产品（产品号，产品名，价格）。

方案3：“负责”与“产品”关系模式合并：

职工（职工号，姓名，年龄）；

产品（产品号，产品名，价格，职工号）。

（3）可以将1:n联系转换为一个独立的关系模式，也可以与联系n端对应的关系模式合并。如果为前者，则与该联系相连的各实体的码及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码；如果为后者，可以在n端实体中增加由联系对应的1端实体的码和联系的属性构成的新属性，新增属性后原关系的码不变。

【例1-2】将图1-19所示的含有1:n联系的E-R图转换为关系模式。

方案1：联系转换为一个独立的关系模式：

仓库（仓库号，地点，面积）；

产品（产品号，产品名，价格）；

仓储（仓库号，产品号，数量）。

方案2：与n端对应的关系模式合并：

仓库（仓库号，地点，面积）；

产品（产品号，产品名，价格，仓库号，数量）。

图1-18　1:1联系E-R图

图1-19　1:n联系E-R图

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

【例1-3】将图1-20所示的含有m:n联系的E-R图转换为关系模式。

转换后的关系模式为：

学生（学号，姓名，年龄，性别）；

课程（课程号，课程名，学时数）；

选修（学号，课程号，成绩）。

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

图1-20　m:n联系E-R图

【例1-4】将图1-21所示的含有多实体间m:n联系的E-R图转换为关系模式。

图1-21　多实体间m:n联系E-R图

供应商（供应商号，供应商名，地址）；

零件（零件号，零件名，单价）；

产品（产品号，产品名，型号）；

供应（供应商号，零件号，产品号，数量）。

（6）具有相同码的关系模式可以合并。

经过以上步骤后已经将E-R图按规则转换成关系模式，但逻辑结构设计的结果并不是唯一的。为了进一步提高数据库应用系统的性能，还应该根据客观需要对结果进行规范化处理，消除异常，改善完整性、一致性，提高存储效率。除此之外，还要从功能及性能上评价数据库模式是否能满足用户的要求，可以采用增加、合并、分解关系的方法优化数据模型的结构，最后得到规范化的关系模式，形成逻辑结构设计说明书。

1.7.5 数据库物理设计

数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它与给定的计算机系统相关。数据库的物理设计，就是为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程。此阶段是以逻辑结构设计阶段的结果为依据，结合具体的数据库管理系统特点与存储设备特性进行设计，确定数据库在物理设备上的存储结构和存取方法。该阶段分以下两步来进行。

（1）首先确定数据库的物理结构，在关系数据库中主要指的是存储结构与存取方法。

（2）从时间效率和空间效率两个方面来对数据库的物理结构进行评价。

如果评价结果满足原设计要求，就能进入到数据库实施阶段，否则就要修改，甚至重新设计物理结构，如果还不能满足要求甚至要回到逻辑结构设计阶段修改数据模型。

1.7.6 数据库实施

在数据库实施阶段，设计人员运用关系数据库管理系统提供的数据语言及其宿主语言，根据逻辑结构设计和物理设计的结果建立数据库，编制和调试应用程序，组织数据入库，并进行试运行。

1.7.7 数据库运行和维护

数据库应用系统经过试运行后，即可投入正式运行，在数据库系统运行过程中必须不断对其进行评价、调整和修改。在该阶段，对数据库经常性的维护工作是由DBA完成的，主要包括以下几点。

（1）数据库的转储和恢复，它是系统正式运行后最重要的维护工作之一。DBA要针对不同的应用要求制定不同的转储计划，以保证突发故障时能尽快将数据库恢复到某种一致的状态，并将对数据库的破坏降到最低。

（2）数据库的安全性、完整性控制。数据库在运行过程中，安全性要求也会发生变化，此时DBA要根据实际情况修改原有的安全性控制。同样，数据库的完整性约束条件也会发生变化，也需要DBA及时修改，以满足用户要求。

（3）数据库性能的监督、分析和改造。运行过程中，监督系统运行，对监测数据进行分析，找出改进系统性能的方法是DBA的又一重要任务。DBA对这些数据要认真分析，判断当前系统运行状况是否需要改进以达到最佳状态。

（4）数据库的重组织和重构造。数据库运行一段时间后，由于不断的增、删、改操作，会导致数据库的物理存储情况变坏，数据的存取效率降低，数据库的性能下降，这时DBA就需要对数据库进行部分重组织（只针对频繁改动的表进行）。重组织，就是按原设计要求重新安排存储位置、回收垃圾、减少指针链等，使系统性能得以提高。数据库的重组织并不修改原设计的逻辑和物理结构，但数据库的重构造需要部分修改数据库的模式和内模式。

数据库应用系统的设计过程就是以上步骤的不断反复过程。

1.7.8 数据库设计案例

本小节以学生选课管理系统的数据库设计为例。设计时做了一定的简化，忽略了一些异常情况的考虑，旨在重点阐述数据库设计步骤。

1. 基本需求分析

某学校需要开发一套学生选课管理系统。为了收集数据库需要的信息，设计人员与系统使用人员通过交谈、填写调查表等方式进行了系统的需求调研，得出系统要实现的功能有：学生可以通过该系统查看所有选修课程的相关信息，包括课程名、学时、学分，然后选择选修的课程（一个学生可以选修多门课程，一门课程可以由多个学生选修）；学生可以通过该系统查看相关授课老师的信息，包括教师姓名、性别、学历、职称；老师可以通过该系统查看选修自己课程的学生的信息，包括学号、姓名、性别、出生日期、班级（假定本校一个教师可以教授多门课程，一门课程只能由一个教师任教）；在考试结束后，老师可以通过该系统录入学生的考试成绩，学生可以通过该系统查看自己的考试成绩。

2. 概念结构设计

（1）通过分析，得到该系统中的实体以及实体的属性，如图1-22所示。