1.6 数据库设计

1.6.1 数据库设计的步骤

数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据。数据库系统设计基本步骤如图1.10所示。

（1）需求分析阶段：用户需求的收集和分析。

（2）概念设计阶段：对用户需求综合归纳与抽象，形成概念模型，用E-R图表示。

（3）逻辑设计阶段：将概念结构转换为某个DBMS所支持的数据模型。

（4）物理设计阶段：为逻辑数据模型选取一个最适合应用环境的物理结构。

（5）数据库实施阶段：建立数据库，编写调试应用程序，组织数据入库，程序试运行。

（6）运行和维护阶段：对数据库系统进行评价、调整与修改。

1.6.2 需求分析阶段

根据实际项目的需求，依照一定的方法、规则或模式对用户要求进行收集，并做详细的分析，最终形成需求分析文档。

1. 系统需求常用的分析方法

（1）自顶向下的设计方法。先定义全局概念结构的框架，然后逐步细化为完整的全局概念结构。

（2）自底向上的设计方法。先定义各局部应用的概念结构，后将它们集成，得到全局概念结构。

（3）逐步扩张的设计方法。先定义最重要的核心部分，后向外扩充，生成其他概念结构。

（4）混合策略设计的方法。即采用自顶向下与自底向上相结合的方法。

2. 系统需求调查的方法

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

（2）设计调查表请用户填写。数据库设计人员可以提前设计一个合理的、详细的业务活动及数据要求调查表，并将此表发给相关的用户。

（3）查阅现实世界的数据记录。查阅与原系统有关的数据记录，包括账本、档案或文献等。

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

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

（6）跟班作业。数据库设计人员亲身参加业务工作。

3. 系统需求的调查步骤

（1）了解现实世界的组织机构情况。弄清所设计的数据库系统与哪些部门相关，以及部门下属各个单位的联系和职责是什么。

（2）了解相关部门的业务活动情况。各部门需要输入和使用什么数据，在部门中是如何加工处理这些数据的，各部门需要输出什么信息，输出到什么部门，输出数据的格式是什么。

（3）确定新系统的边界。哪些功能现在就由计算机完成，哪些功能将来准备让计算机完成，哪些功能或活动由人工完成。由计算机完成的功能就是新系统应该实现的功能。

4. 系统需求调查的内容

（1）数据库中的信息内容。数据库中需存储哪些数据，包括用户将从数据库直接或间接获得的信息内容和性质。

（2）数据处理内容。用户要完成什么数据处理功能，用户对数据处理响应时间的要求，数据处理的工作方式。

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

1.6.3 概念结构的设计

数据库概念结构设计通常采用E-R方法。这种方法不包括深的理论，但提供了一个简便、有效的方法。

使用E-R模型来进行概念模型的设计通常分两步进行，首先是建立局部概念模型，然后综合局部概念模型，成为全局概念模型。

1. 设计分E-R图

概念结构设计是利用抽象机制对需求分析阶段收集到的数据分类、组织（聚集），形成实体集、属性和码，确定实体集之间的联系类型（一对一、一对多或多对多的联系），进而设计分E-R图。常用数据抽象的三种方法如下。

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

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

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

2. 合并分E-R图，生成初步E-R图（实例请参考“本章1.4.3”中的相关内容）

合并时主要在以下三个方面进行概念的统一。

（1）属性冲突

① 属性域冲突，即属性值的类型、取值范围或取值集合不同。

② 属性取值单位冲突。

（2）命名冲突

① 同名异义冲突，即不同意义的对象在不同的局部应用中具有相同的名字。

② 异名同义冲突，即意义相同的对象在不同的局部应用中有不同的名字。

（3）结构冲突

① 同一对象在不同的应用中具有不同的抽象。

② 同一实体在不同分E-R图中的属性组成不一致。

③ 实体之间的联系在不同的分E-R图中呈现不同的类型。

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

1.6.4 逻辑结构的设计

逻辑结构阶段设计的任务是将基本E-R图转换为与选用DBMS产品所支持的数据模型相符合的逻辑结构。其过程为将概念结构转换为现有DBMS支持的关系、网状或层次模型中的某一种数据模型；从功能和性能要求上对转换的模型进行评价，看它是否满足用户要求；对数据模型进行优化。概念模型向关系模型转换的规则如下。

1. 实体集的转换规则

概念模型中的一个实体集转换为关系模型中的一个关系，实体的属性就是关系的属性，实体的码就是关系的码，关系的结构是关系模式。

2. 实体集间联系的转换规则

（1）1:1联系的转换方法

① 将1:1联系转换为一个独立的关系：与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，且每个实体的码均是该关系的候选码。

② 将1:1联系与某一端实体集所对应的关系合并，则需要在被合并关系中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体集的码。

【例1-1】将图1.11中的E-R图转换为关系模型。

方案1：联系形成的关系独立存在。

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

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

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

方案2：“负责”与“职工”两关系合并。

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

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

方案3：“负责”与“产品”两关系合并。

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

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

（2）1:n联系的转换方法

一种方法是将联系转换为一个独立的关系，其关系的属性由与该联系相连的各实体集的码以及联系本身的属性组成，而该关系的码为n端实体集的码；另一种方法是在n端实体集中增加新属性，新属性由联系对应的1端实体集的码和联系自身的属性构成，新增属性后原关系的码不变。

【例1-2】将图1.12含有1:n联系的E-R图转换为关系模型。

方案1：联系形成的关系独立存在。

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

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

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

方案2：联系形成的关系与n端对象合并。

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

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

（3）m：n联系的转换方法

在向关系模型转换时，一个m：n联系转换为一个关系。转换方法为与该联系相连的各实体集的码以及联系本身的属性均转换为关系的属性，新关系的码为两个相连实体码的组合（该码为多属性构成的组合码）。

【例1-3】将图1.13中含有m：n联系的E-R图转换为关系模型。

图1.13转换后的关系模型为：

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

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

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

（4）三个或三个以上实体集间的多元联系的转换方法

① 对于一对多的多元联系，转换为关系模型的方法是修改1端实体集对应的关系，即将与联系相关的其他实体集的码和联系自身的属性作为新属性加入1端实体集中。

② 对于多对多的多元联系，转换为关系模型的方法是新建一个独立的关系，该关系的属性为多元联系相连的各实体的码以及联系本身的属性，码为各实体码的组合。

【例1-4】将图1.14中含有多实体集间的多对多联系的E-R图转换为关系模型。

图1.14转换后的关系模型为：

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

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

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

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

1.6.5 物理结构设计

系统的物理结构设计是在逻辑设计完成后进行的。物理设计是在计算机的物理设备上确定应采取的数据存储结构和存取方法，以及如何分配存储空间等问题。当确定之后，应用系统所选用的DBMS提供的数据定义语言把逻辑设计的结果（数据库结构）描述出来，并将源模式变成目标模式。由于目前使用的DBMS基本上是关系型的，物理设计的主要工作是由系统自动完成的，用户只要关心索引文件的创建即可。尤其是对微机关系数据库用户来说，用户可做的事情很少，用户只需用DBMS提供的数据定义语句建立数据库结构。

1.6.6 数据库的实施、运行和维护

完成数据库的物理设计之后，设计人员就要用DBMS提供的数据定义语言和其他实用程序将数据库逻辑设计和物理设计结果严格描述出来，成为DBMS可以接受的源代码，再经过调试产生目标模式。然后就可以组织数据入库了，这就是数据库的实施阶段。在数据部分入库后就可以对数据库系统进行联合调试，即数据库的试运行。试运行合格后，数据库的开发工作基本完成，就可以投入正式运行。此后，根据各方面因素的变化，需要不断地对数据库本身做经常性的维护工作，该工作交由DBA来完成，主要包含：数据库的转储和恢复，数据库的安全性、完整性控制，数据库性能的监督、分析和改造，数据库的重组织和重构造四个方面。