数据库设计

1、数据库设计概述

数据库设计。广义地讲，是数据库及其应用系统的设计，即设计整个数据库应用系统；狭义地讲，是设计数据库本身，即设计数据库的各级模式并建立数据库，这是数据库应用系统设计的一部分。

数据库设计是指对于一个给定的应用环境，设计一个优良的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据处理要求：①信息管理要求：在数据库中存储和管理需要的数据对象；②数据处理要求：对数据对象需要进行的处理，如查询、增删改、统计和分析等。

（1.1）数据库设计的特点

（1）数据库建设的基本规律

① 三分技术，七分管理，十二分基础数据；

② 管理：数据库建设项目管理、企业（即应用部门）的业务管理；

③ 基础数据：数据的收集、整理、组织和不断更新。

（2）结构（数据）设计和行为（处理）设计相结合

① 将数据库结构设计和数据处理设计密切结合

② 传统的软件工程：重行为设计

忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计。

③ 早期的数据库设计：重结构设计

致力于数据模型和数据库建模方法研究，忽视了行为设计对结构设计的影响。

结构和行为分离的设计

（1.2）数据库设计方法

大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。要求多方面的知识和技术。主要包括：计算机的基础知识、软件工程的原理和方法、程序设计的方法和技巧、数据库的基本知识、数据库设计技术、应用领域的知识。

数据库设计工具：

① SYBASE PowerDesigner

        数据库建模－UML 工具；

② Rational Rose

        UML 工具－数据库建模；

③ CA ERWin

         ERwin 全称是 ERwin Data Modele 功能强大、易于使用的数据建模、数据库设计与开发工具。

数据库设计方法：

（1）手工设计法

        ① 设计质量与设计人员的经验和水平有直接关系；

        ② 缺乏科学理论和工程方法的支持，工程的质量难以保证；

        ③ 数据库运行一段时间后常常又不同程度的发现各种问题，增加了维护代价。

（2）规范设计法

        典型方法 —— 新奥尔良（New Orleans）方法

        ① 将数据库设计分为若干阶段和步骤；

        ② 采用辅助手段实现每一过程；

        ③ 按设计规程用工程化方法设计数据库。

（3）基于 E-R 模型的设计方法

        概念设计阶段广泛采用。

（4）3NF 的设计方法

        逻辑阶段可采用的有效方法。

（5）ODL（Object Definition Language）方法

        面向对象的数据库设计方法。

（6）UML（Unified Modeling Language）方法

        面向对象的建模方法。

（1.3）数据库设计的基本步骤

数据库设计分为 6 个阶段：

（1）需求分析；

（2）概念结构设计；

（3）逻辑结构设计

（4）物理结构设计；

（5）数据库实施；

（6）数据库运行和维护。

在数据库设计过程中，需求分析和概念结构设计可以独立于任何数据库管理系统进行，但是逻辑结构设计和物理结构设计与选用的数据库管理系统密切相关。

如下图所示：

各阶段设计说明：

（1）需求分析阶段：是否做得充分与准确，决定构建数据库的速度和质量。

（2）概念设计阶段：对用户需求进行综合、归纳与抽象，形成独立于具体 DBMS 的概念模型。

（3）逻辑设计阶段：将概念结构转换成某个 DBMS 所支持的数据模型，并对其进行优化。

（4）物理设计阶段：为逻辑数据结构选取一个最适合应用环境的物理结构，包括存储结构和存取方法。

（5）数据库实施阶段：根据逻辑设计和物理设计的结构构建数据库，编写与调试应用程序，组织数据入库并进行试运行。

（6）数据库运行和维护阶段：经过试运行后即可投入正式运行。在运行过程中必须不断对数据库设计进行评估、调整和修改。

设计一个完善的数据库应用系统往往是上述 6 个阶段的不断反复。这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程。把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计。

参加数据库设计的人员：

① 系统分析人员和数据库设计人员

        自始至终参与数据库设计；

② 数据库管理员和用户代表

        主要参加需求分析与数据库的运行和维护；

③ 应用开发人员

        包括程序员和操作员，在实施阶段参与进来，分别负责编制程序和准备软硬件环境。

数据库设计各个阶段产生的设计文档/设计说明：

（1.4）数据库设计过程中的各级模式

如图所示：

（1）需求分析阶段：综合各个用户的应用需求。

（2）概念设计阶段：形成独立于机器特点，独立于各个 DBMS 产品的概念模式（E-R图）。

（3）逻辑设计阶段：

① 首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；

② 然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图（View），形成数据的外模式。

（4）物理设计阶段：根据数据库管理系统特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式。

2、需求分析

需求分析 —— 分析用户的要求，是设计数据库的起点。

需求分析的重要性：结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。

需求分析常常被忽视。原因：设计人员认为这是软任务，急于进行具体的设计；用户嫌麻烦；领导不重视。

（2.1）需求分析的任务

需求分析的任务是通过详细调查要开发应用系统的组织（部门、企业等），充分了解原系统的工作概括，明确用户的各种需求，最后确认新系统的功能。

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

（1）信息要求

用户需要从数据库中获得信息的内容和性质；由信息要求可以导出数据要求，即在数据库中需要存储哪些数据。

（2）处理要求

用户要什么处理功能、对处理性能、处理方式、处理周期等的要求。

（3）安全性和完整性要求

确定用户需求的难点：用户缺少计算机知识，不能准确地表达自己的需求，提出的需求往往不断地变化。设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。

解决方法：设计人员必须不断深入地与用户进行交流，才能逐步确定用户的实际需求。

（2.2）需求分析的方法

在调查过程中，可以根据不同的问题和条件使用不同的调查方法。常用的调查方法有：

（1）跟班作业。通过亲身参加业务工作来了解业务活动的情况。

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

（3）请专人介绍。

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

（5）设计调查表请用户填写。如果调查表设计得合理，这种方法是很有效的。

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

调查了解用户需求以后，还需要进一步分析和表达用户的需求。在众多分析方法中，结构化分析（Structured Analysis，SA）方法是一种简单实用的方法。SA 方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。对用户需求进行分析与表达后，需求分析报告必须提交给用户，征得用户的认可。

（2.3）数据字典

数据字典是关于数据库中数据的描述，称为元数据，它不是数据本身，而是数据的数据。数据字典在需求分析阶段建立，在数据库设计过程中不断修改、充实、完善。数据字典是进行详细的数据收集和分析所获得的主要结果。

数据字典的内容：

（1）数据项；

（2）数据结构；

（3）数据流；

（4）数据存储；

（5）处理过程。

其中，数据项是数据的最小组成单位。若干个数据项可以组成一个数据结构。通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

（1）数据项

数据项是不可再分的数据单位。

数据项描述 = { 数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系 }

关系规范化理论为指导，用数据依赖的概念分析和抽象数据项之间的联系 —— 函数依赖。

“ 取值范围 ”、“ 与其他数据项的逻辑关系 ” 定义了数据的完整性约束条件，是模式设计、完整性检查条件、触发器、存储过程的依据。

【例】学生学籍管理子系统的数据字典。

数据项，以学号为例。

数据项：学号；

含义说明：唯一标识每个学生；

别名：学生编号；

类型：字符型；

长度： 9；

取值范围：0 至 99999999；

取值含义：前 4 位标别该学生入学年份，第 5 第 6 位所在专业系编号，后 3 位按顺序编号，例如 201615008；

与其他数据项的逻辑关系：学号的值确定了其他数据项的值。

（2）数据结构

数据结构反映了数据之间的组合关系。一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。

数据结构描述 = { 数据结构名，含义说明，组成：{ 数据项或数据结构 } }

【例】以 “ 学生 ” 为例，“ 学生 ” 是该系统中的一个核心数据结构。

数据结构：学生；

含义说明：学籍管理子系统的主体数据结构，定义了一个学生的有关信息；

组成：学号，姓名，性别，年龄，所在系，年级。

（3）数据流

数据流是数据结构在系统内部传输的路径。

数据流描述 = { 数据流名，说明，数据流来源，数据流去向，组成：{ 数据结构 }，平均流量，高峰期流量 }

数据流来源：说明该数据流来自哪个处理过程 / 数据存储；

数据流去向：说明该数据流将到哪个处理过程 / 数据存储去；

平均流量：在单位时间里的传输次数；

高峰期流量：在高峰期间的数据流量。

【例】数据流 “ 体检结果 ” 可描述为：

数据流：体检结果；

说明：学生参加体格检查的最终报告；

数据流来源：体检（处理过程）；

数据流去向：批准（处理过程）；

组成：{ 学号，{血常规}，{尿常规}，...... {其他体检} }；

平均流量：每天 200；

高峰期流量：每天 400。

（4）数据存储

数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。

数据存储描述 = { 数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{ 数据结构 }，数据量，存取频度，存取方式 }

存取频度：每小时、每天或每周存取次数，每次存取的数据量等信息；

存取方法：批处理 / 联机处理；检索 / 更新；顺序检索 / 随机检索；

输入的数据流：数据来源；

输出的数据流：数据去向。

【例】数据存储 “ 学生登记表 ” 可描述为：

数据存储：学生登记表；

说明：记录学生的基本情况；

输入数据流：每学期 5000 ；

输出数据流：每学期 5000 ；

组成：{ 学号，姓名，性别，年龄，所在系，年级，{学生成绩}，{体检结果}，...... }；

数据量：每年 100000 张；

存取方式：随机存取 + 按专业系 / 班级打印。

（5）处理过程

处理过程：具体处理逻辑一般用判定表或判定树来描述、数据字典中只需要描述处理过程的说明性信息。

处理过程描述 = { 处理说明名，说明，输入：{输入流} ，输出：{输出流}，处理：{简要说明} }

简要说明：说明该处理过程的功能及处理要求。

【例】处理过程 “ 分配寝室 ” 可描述为：

处理过程：分配寝室；

说明：为所有新生分配学生寝室；

输入：学生，寝室；

输出：寝室安排；

处理：在新生报到后，为所有新生分配学生寝室。要求同一间寝室只能安排同一年级同一性别的学生，一个学生只能安排在一个寝室，每个学生的居住面积不小于 6 平方米，安排新生寝室的处理时间应不超过 15 分钟。

3、概念结构设计

将需求分析得到的用户需求抽象为信息结构即概念模型的过程就是概念结构设计。概念结构是现实世界的一个真实模型，是各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。概论结构设计是数据库设计的关键。

（3.1）概论模型

见《1.数据模型》。

（3.2）E-R 模型

（1）实体之间的联系

两个实体之间的联系可以分为三种：一对一联系（1:1）；一对多联系（1：n）；多对多联系（m：n）。如下图所示：

① 一对一联系（1:1）

        如果对于实体集 A 中的每一个实体，实体集 B 中最多有一个（也可以没有）实体与之联系，反之亦然。则称实体集 A 和实体集 B 具有一对一联系，即为 1:1。

        【例如】学校里一个班级只有一个正班长，而一个班长只在一个班中任职，则班级与班长之间具有一对一联系。

② 一对多联系（1：n）

        如果对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体与之联系，反之，对于实体集 B 中的每一个实体，实体集 A 中至多只有一个实体与之联系，则称实体集 A 和实体集 B 有一对多联系，即为 1：n。

        【例如】一个班级有若干名学生，而每个学生只在一个班级中学习，则班级和学生之间具有一对多联系。

③ 多对多联系（m:n）

        如果对于实体集 A 中的每一个实体，实体集 B 中有 n 个实体与之联系，反之，对于实体集 B 中的每一个实体，实体集 A 中也有 m 个实体与之联系，则称实体集 A 与实体集 B 具有多对多联系，即为 m:n。

        【例如】一门课程同时有很多名学生选修，而一个学生可以同时选修多门课程，则课程与学生之间具有多对多联系。

两个以上的实体型之间的联系：也存在一对一、一对多、多对多联系。

【例1】对于课程、教师与参考书，如果一门课程可以有若干个教师讲授，使用若干本参考书，而每一个教师只讲授一门课程，每一本参考书只供一门课程使用。则课程与教师、参考书之间的联系是一对多的。

【例2】对于供应商、项目、零件，一个供应商可以供给多个项目多种零件，而每个项目可以使用多个供应商供应的零件，每种零件可由不同供应商供给。可以看出供应商、项目、零件三者之间是多对多的联系。

单个实体型内的联系：也存在一对一、一对多、多对多的联系。

【例如】职工实体型内部具有领导与被领导的联系，即某一职工（干部）“领导” 若干名职工，而一个职工仅被另外一个职工直接领导，因此这是一对多的联系。

把参与联系的实体型的数目称为联系的度：

① 两个实体型之间的联系度为 2，也称为二元联系；

② 三个实体型之间的联系度为 3，也称为三元联系；

③ N 个实体型之间的联系度为 N，也称为 N 元联系。

（2）E-R 图

E-R 图提供了表示实体型、属性和联系的方法。实体型：用矩形表示，矩形框内写明实体名；属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来；联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1、1:n、m:n）。其中，联系可以具有属性。

【例1】某工厂生产若干产品，每种产品由不同的零件组成，有的零件可用在不同的产品。这些零件由不同的原材料制成，不同零件所用的材料可以相同。有的零件可用在不同的产品，这些零件按照所属的不同产品分别放在仓库中，原材料按照类别放在若干仓库中。请用 E-R图画出此工厂产品、零件、材料、仓库的概念模型。

【答案】

E-R 图

【例2】画出某个工厂物资管理的概念模型。

物资管理涉及的实体有：

        仓库：属性有仓库号、面积、电话号码；

        零件：属性有零件号、名称、规格、单价、描述；

        供应商：属性有供应商号、姓名、地址、电话号码、账号；

        项目：属性有项目号、预算、开工日期；

        职工：属性有职工号、姓名、年龄、职称。

这些实体之间的联系如下：
        （1）一个仓库可以存放多种零件，一种零件可以存放在多个仓库中，因此仓库和零件具有多对多的联系。用库存量来表示某种零件在某个仓库中的数量。
        （2）一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作，因此仓库和职工之间是一对多的联系。
        （3）职工之间具有领导与被领导关系，即仓库主任领导若干保管员，因此职工实体型中具有一对多的联系。
        （4）供应商、项目和零件三者之间具有多对多的联系，即一个供应商可以供给若干项目多种零件，每个项目可以使用不同供应商供应的零件，每种零件可由不同供应商供给。

【答案】

完整的 E-R 图

（3.3）扩展的 E-R 模型

对 E-R 模型进行扩展的原因：为了增强和丰富基本 E-R 模型的表达能力。主要的三种扩展：ISA 联系、基数约束、PART-OF 联系。

（1）ISA 联系

有的实体型是某个实体型的子类型，这种父类 - 子类联系称为 ISA 联系，表示 “ is a ” 语义，用 $\bigtriangleup$ 表示。ISA 联系的性质：子类继承了父类的所有属性，子类也可以由自己的属性。

例如：学生的两个子类。

ISA 联系描述了对一个实体型中实体的一种分类方法，下面对分类方法做进一步说明。

（1）分类属性

        分类属性是父实体型的一个属性；分类属性的值把父实体型中的实体分配到子实体型中。

学生的分类属性

（2）不相交约束和可重叠约束

        不相交约束：描述父类中的一个实体不能同时属于多个子类中的实体集，即一个父类中的实体最多属于一个子类实体集。用 ISA 联系符号三角形的一个叉号 “ X ” 来表示。

        可重叠约束：父类中的一个实体同时属于多个子类中的实体集；子类符号中没有叉号表示是可以重叠的。

子类的不相交约束

（3）完备性约束

        描述父类中的一个实体是否必须是某一个子类的实体，如果是，则叫完全特化；否则叫做部分特化。

完全特化用父类到子类的双线连接来表示；部分特化用父类到子类的单线连接来表示。

完备性约束

（2）基数约束

基数约束是对实体之间一对一、一对多和多对多联系的细化。参与联系的每个实体型用基数约束来说明实体型中的任何一个实体可以在联系中出现的最少次数和最多次数。

约束用一个数对 min..max 表示，0 <= min <= max。例如：0..1、1..3、1..*（*代表无穷大）。

其中，min = 1 的约束叫做强制参与约束，即被施加基数约束的实体型中的每个实体都要参与联系；min = 0 的约束叫做非强制参与约束，即被施加基数约束的实体型中的实体可以出现在联系中，也可以不出现联系中。

【例1】在学生和学生证的联系中，一个学生必须拥有一本学生证，一本学生证只能属于一个学生，因此都是 1..1。

学生和学生证的联系

【例2】在学生和课程的联系中，是多对多关系。

学生和课程的联系

① 学生实体型的基数约束是 20..30，表示每个学生必须选修 20~30 门课程；

② 课程的一个合理的基数约束是 0..*，即一门课程一般会被很多同学选修，但是有的课程可能还没有任何一位同学选修，如新开课。

【例3】在班级和学生的联系中。

班级和学生的联系

① 一个学生必须参加一个班级，并只能参加一个班级，因此是 1..1，标在参与联系的班级实体一边。

② 一个班级最少30个学生，最多40个学生，因此是 30..40，标在参与联系的学生实体一边。

③ 采用这种方式，一是可以方便地读出约束的类型（一对一、一对多、多对多)，如班级和学生是一对多的联系；二是一些 E-R 辅助绘图工具也是采用这样的表现形式。

（3）PART-OF 联系

PART-OF 联系描述某个实体型是另外一个实体型的一部分。分为两种情况：

① 非独占的 PART-OF 联系，简称非独占联系

整体实体如果被破坏，另外一部分实体仍然可以独立存在。

② 独占的PART-OF 联系，简称独占联系

整体实体如果被破坏，部分实体不能存在。

PART-OF 联系的表示：

① 用非强制参与联系表示非独占联系；

② 用弱实体类型和识别联系表示独占联系。

如果一个实体型的存在依赖于其它实体型的存在，则这个实体型叫做弱实体型，否则叫做强实体型。用弱实体类型和识别联系来表示独占联系；双矩形表示弱实体型，双菱形表示识别联系。

【举例说明】

（3.4）UML

UML 称为统一建模语言，是对象管理组织的一个标准。UML 是为软件开发的各个阶段提供模型化和可视化支持的规范语言，从需求规格描述到系统完成后的测试和维护。UML 可以用来数据建模、业务建模、对象建模、组件建模等等，还提供了多种类型的模型描述图，借助这些图可以使得应用程序更加容易理解。

UML 中的类大致对应 E-R 图中的实体。用 UML 的类图表示 E-R 图。

实体型：用类表示，矩形框上部为实体名，下部为属性名；

实体的码：在类图中在属性后面加 “ PK ” 来表示码属性；

联系：用类图之间的 “ 关联 ” 来表示。

例：

基数约束：UML 中关联类之间的基数约束和 E-R 图中的基数约束的概念类似。UML 中的子类：面向对象技术支持超类 - 子类概念，子类可以继承超类的属性，也可以有自己的属性。这些概念和 E-R 图的父类 - 子类联系（ISA联系）是一致的。

（3.5）概念结构设计

现实世界的事物能作为属性对待的，尽量作为属性对待，这样可以简化 E-R 图的处置。

（1）实体与属性的划分原则

划分实体和属性的两条准则：

① 作为属性，不能再具有需要描述的性质。

属性必须是不可分的数据项，不能包含其它属性。

② 属性不能与其它实体具有联系。

E-R 图中所表示的是联系是实体之间的联系。

【例】销售管理子系统 E-R 图的设计。

        某工厂开发信息系统，经过可行性分析，详细调查确定了该系统由物资管理、销售管理、劳动人事管理等子系统组成。

        该子系统的主要功能是：

        ① 处理顾客和销售员送来的订单

        ② 工厂是根据订货安排生产的

        ③ 交出货物同时开出发票

        ④ 收到顾客付款后，根据发票存根和信贷情况进行应收款处理

（1）通过需求分析，知道销售子系统功能围绕 “ 订单 ” 和 “ 应收账款 ” 的处理来实现。

（2）先设计该 E-R 图的草图：数据结构中订单、顾客、顾客应收账目、产品是许多子功能、数据流共享的数据，因此设计为实体。如下图所示：

分 E-R 图的框架

（3）再对E-R图进行详细设计和调整：参照需求分析和数据字典中的详尽描述，遵循前面给出的两个准则。

（4）具体做法：

        ① 每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照准则，订单细节就应该上升为实体。一张订单可以订若干产品，订单与订单细节两个实体之间是 1∶n 的联系。

        ② 原订单和产品的联系实际上是订单细节和产品的联系，增加了一个联系 — 参照2。产品描述，进一步细化，包括当前单价、产品重量等信息。

        ③ 工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应增加一个实体 —“ 折扣规则 ” 存放这些信息。

（5）最后得到销售管理子系统 E-R 图。如下图所示：

销售管理子系统的 E-R 图

（6）对每个实体定义的属性如下：

        顾客：{ 顾客号，顾客名，地址，电话，信贷状况，账目余额 }

        订单：{ 订单号，顾客号，订货项数，订货日期，交货日期，工种号，生产地点 }

        订单细则：{ 订单号，细则号，零件号，订货数，金额 }

        应收账款：{ 顾客号，订单号，发票号，应收金额，支付日期，支付金额，当前余额，货款限额 }

        产品：{ 产品号，产品名，单价，重量 }

        折扣规则：{ 产品号，订货量，折扣 }

这里省略了实体属性图，实体的码用下划线划出。

（2）E-R 图的集成

在开发一个大型信息系统时，最经常采用的策略是自顶向下地进行需求分析，然后再自底向上地设计概念结构。即首先设计各子系统的分 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 图中为不多的类型。

例如实体 E1 和 E2 在一个 E-R 图中是多对多联系，在另一个E-R 图中是一对多联系。

解决方法：根据应用的语义对实体联系的类型进行综合或调整。

【例】图 (a) 中零件与产品之间存在多对多的联系 “ 构成 ”，图 (b) 中产品、零件与供应商三者之间还存在多对多的联系 “ 供应 ”，这两个联系互相不能包含，则在合并两个 E-R 图时就应把它们综合起来，如图 (c)。

合并两个 E-R 图时的综合

（2）消除不必要的冗余，设计生成基本 E-R 图

① 冗余的数据是指：可由基本数据导出的数据；

② 冗余的联系是指：可由其它联系导出的联系；

③ 冗余带来的问题：破坏数据库的完整性，数据库维护困难，应该消除；

④ 消除冗余的方法：

分析方法；
规范化理论的方法。

采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。

【例】Q3 = Q1×Q2，Q4 = ∑Q5 所以 Q3 和 Q4 是冗余数据，可以消去。由于 Q3 消去，产品与材料间 m:n 的冗余联系也应消去。

消除冗余

并不是所有的冗余数据与冗余联系都必须加以消除，有时为了提高效率，不得不以冗余信息作为代价。

用规范化理论来消除冗余

① 确定分 E-R 图实体之间的数据依赖。

实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。于是有了函数依赖集 $F_{L}^{}$ 。

② 求 $F_{L}^{}$ 的最小覆盖 $G_{L}^{}$ ，差集为 D = $F_{L}^{}$ - $G_{L}^{}$

逐一考察 D 中的函数依赖，确定是否是冗余的联系，如果是，就把它去掉。

注意的问题：

冗余的联系一定在 D 中，而 D 中的联系不一定是冗余的；
当实体之间存在多种联系时，要将实体之间的联系上加以区分。

【例】部门和职工之间一对多的联系

        可表示为：职工号 → 部门号；

职工和产品之间多对多的联系

        可表示为：（职工号，产品号）→ 工作天数；

职工和产品之间一对一的联系

         负责人.职工号→产品号

         产品号 → 负责人.职工号等。

劳动人事管理的分 E-R 图

4、逻辑结构分析

逻辑结构设计的任务：把概念结构设计阶段设计好的基本 E-R 图转换为与选用的 DBMS 产品所支持的逻辑结构。目前主要使用关系模型，关系模型的逻辑结构是一组关系模式的集合。

（4.1）E-R 图向关系模型的转换

转换内容：将 E-R 图转换为关系模型：将实体型、实体属性、实体间的联系转换为关系模式。

（1）实体型的转换：一个实体型转换为一个关系模式

关系模式的属性：实体的属性；关系模式的码：实体的码。

【例】

即为：

学生（学号，姓名，出生日期，所在系，年级，平均成绩）

（2）实体型间的 1:1 联系

① 可以转换为一个独立的关系模式

关系模式的属性：与该联系相连的各实体的码以及联系本身的属性；
关系模式的候选码：每个实体的码均是该关系模式的候选码。

② 也可以与相连的任意一端对应的关系模式合并

关系模式的属性：与某一端关系模式合并，则在该关系模式的属性中加入另一端关系模式的码和联系的属性
合并后关系模式的码：不变

（3）实体型间的 1:n 联系

① 转换为一个独立的关系模式

关系模式的属性：与该联系相连的各实体的码 + 联系本身的属性；
关系模式的码：n 端的实体的码。

② 与 n 端对应的关系模式合并

合并后关系模式的属性：在 n 端关系模式中 + 1端关系的码 + 联系本身的属性；
合并后关系模式的码：不变。可以减少系统模式中的关系个数，一般情况下更倾向于采用这种方法、

（4）实体型间的 m:n 联系

① 一个 m:n 联系转换为一个关系模式

关系的属性：与该联系相连的各实体的码以及联系本身的属性；
关系的码：各实体码的组合。

（5）三个或三个以上实体间的一个多元联系

① 转换为一个关系模式

关系模式的属性：与该多元联系相连的各实体的码 + 联系本身的属性；
关系模式的码：各实体码的组合。

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

① 目的：减少系统中的关系个数

② 合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），稍微适当调整属性的次序即可。

（4.2）数据模型的优化

数据库逻辑设计的结构不是唯一的；得到初步数据库模式后，还应该适当的修改、调整数据库逻辑结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化。关系数据模型的优化通常以规范理论为指导。

优化数据模型的方法：

① 确定数据依赖

按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间的数据依赖。

② 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。

③ 按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖‘传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。

④ 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解。包括水平分解和垂直分解。

注意几点：

① 对于一个具体应用来说，到底规范化进行到什么程度，需要权衡响应时间和潜在问题两者的利弊来决定。

② 当查询经常涉及两个或多个关系模式的属性时，系统必须经常地进行连接运算，连接运算的代价是相当高的。这种情况下，需要降低规范化程度。

③ 非BCNF的关系模式会存在不同程度的更新异常。如果在实际应用中对此关系模式只是查询，并不执行更新操作，就不会产生实际影响。

（4.3）设计用户子模式

数据库模式是全局模式，考虑的是系统全局应用需求、时间效率、空间效率、易维护等。

用户子模式是视图机制，考虑的是局部应用的特殊需求和用户体验。

由于用户外模式和模式是相对独立的，因此在定义用户外模式时要考虑用户的习惯和方便。具体包括以下方面：

（1）使用更符合用户习惯的别名：

① 合并各分 E-R 图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。这在设计数据库整体结构时是非常必要的。

② 在设计用户子模式时可以设计子模式时重新定义某些属性名，使其与用户习惯一致，以方便使用。

（2）针对不同级别的用户定义不同的视图，提高系统的安全性。

（3）简化用户对系统的使用某些局部应用中经常要使用一些很复杂的查询，为了方便用户，可以将这些复杂查询定义为视图。

（4.4）逻辑结构分析小结

5、物理结构分析

为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。数据库在物理设备上的存储结构和存取方法称为数据库的物理结构，它依赖于选定的 DBMS。

数据库的物理设计通常分为两步：第一步：确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构。第二步：对物理结构进行评价，评价的重点是时间和空间效率。

（5.1）数据库物理设计的内容和方法

关系数据库物理设计的内容：为关系模式选择存取方法（建立存取路径）；为关系、索引、日志、备份等数据库文件选择物理存储结构。

由于不同的 DBMS 产品的物理环境、存取方法和存储结构有很大差别，能够给设计人员使用的设计变量、参数范围很不相同，所以没有通用的物理设计方法，只能给出一般的设计内容和原则。

设计物理数据库结构的准备工作：

① 充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数。

② 充分了解所用 RDBMS 的内部特征，特别是系统提供的存取方法和存储结构。

有哪些索引（例如B+树索引，HASH索引， BITMAP索引等），如何建立索引；
有哪些存储结构（行存储，列存储，聚簇存储），如何选择。

物理数据库设计参数（部分列选）

① 数据库查询事务

查询所涉及的关系
查询条件所涉及的属性
连接条件所涉及的属性
查询的投影属性

② 数据更新事务

被更新的关系
每个关系上的更新操作条件所涉及的属性
修改操作要改变的属性值

③ 每个事务在各关系上运行的频率和性能要求

（5.2）关系模式存取方法选择

关系模式存取方法：索引方法、聚簇方法。

（5.2.1）索引存取方法的选择

建立索引可以提高存取的效率 —— 查询、插入、删除、更改的效率。

如何选择索引存取方法，根据应用要求确定：对哪些属性列建立索引；对哪些索引要设计为唯一索引、组合索引、；选择合适的索引方法。

创建索引：

CREATE [ UNIQUE ] INDEX 索引名字

ON 表名 [ USING 索引方法 ] ( 列名1，列名2，...[, ] );

RDBMS 提供的索引方法：B-tree（B+树），hash（散列）R-tree 、Bitmap等。如果不指定，缺省一般是 B-tree。

选择索引存取方法的一般规则：

① 如果一个（或一组）属性经常在查询条件中出现，则考虑在这个（这组）属性上建立索引（或组合索引）；

② 如果一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引；

③ 如果一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引。

（1）B+ 树索引简介

B+ 树索引的特点：多分平衡树，存取效率高；既能随机查找、又能顺序查找；增删改操作，保持平衡。

（2）HASH 存取方法的选择

选择 Hash 存取方法的规则：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一：该关系的大小可预知，而且不变；该关系的大小动态改变，但所选用的数据库管理系统提供了动态 Hash 存取方法。

（5.2.2）聚簇存取方法的选择

为了提高某个属性（或属性组）的查询速度，把这个（或这些）属性上具有相同值的元组集中存放在连续的物理块中称为聚簇。该属性（或属性组）称为聚簇码，许多 RDBMS 都提供了聚簇功能。

建立聚簇的方法：

（1）先创建一个聚簇

CREATE CLUSTER <聚簇名> (<聚簇码>) SIZE (<大小>);

（2）在聚簇上建立索引

CREATE INDEX <索引名> ON CLUSTER <聚簇名>;

聚簇的用途：大大提高按聚簇属性进行查询的效率。

【例】假设要查询计算机系的所有学生。

学生数据表随机存放，计算机系的 500 名学生分散存储在 500 个不同的物理块上，则至少要执行 500次 I/O操作。

如果按照专业系名聚簇存放，将同一系的学生元组聚簇在一起存放，则可以显著地减少了访问磁盘的次数。计算机系的 500 名学生聚簇存储在 50 个不同的物理块上，只要执行 50次 I/O操作。

聚簇的适用范围：

① 既适用于单个关系独立聚簇，也适用于多个关系组合聚簇。

【例】假设用户经常要按姓名查询学生成绩单。

SELECT sname, cno, grade

from student, sc

where student.sno = sc.sno

这一查询涉及学生关系和选修关系的连接操作，按学号连接这两个关系。

按照学号把学生表和选修表聚簇在一起，相当于把多个关系按 “ 预连接 ” 的形式存放，大大提高连接操作的效率。

② 当 SQL 语句中包含有与聚簇码有关的 ORDER BY, GROUP BY, UNION, DISTINCT 等子句或短语时，使用聚簇特别有利，可以省去或减少对结果集的排序操作。

聚簇的局限性：

① 在一个基本表上最多只能建立一个聚簇索引；

②聚簇只能提高某些特定应用的性能；

③ 建立与维护聚簇的开销相当大：

对已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原有的索引无效，必须重建。
当一个元组的聚簇码改变时，该元组的存储位置也要相应改变。

聚簇索引的适用条件：很少对基表进行增删操作；很少对其中的变长列进行修改操作。

（5.3）确定数据库的存储结构

确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。

确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。

（1）确定数据的存放位置

为了提高系统性能，应该根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。

由于各个系统所能提供的对数据进行物理安排的手段、方法差异很大，因此设计人员应仔细了解给定的关系数据库管理系统提供的方法和参数，针对应用环境的要求对数据进行适当的物理安排。

（2）确定系统配置

关系数据库管理系统产品一般都提供了一些系统配置变量和存储分配参数，供设计人员和数据库管理员对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的默认值。但是这些值不一定适合每一种应用环境，在进行物理设计时需要重新对这些变量赋值，以改善系统的性能。

系统配置变量很多，例如，同时使用数据库的用户数，同时打开的数据库对象数，内存分配参数，缓冲区分配参数（使用的缓冲区长度、个数)，存储分配参数，物理块的大小，物理块装填因子，时间片大小，数据库大小，锁的数目等。这些参数值影响存取时间和存储空间的分配，在物理设计时就要根据应用环境确定这些参数值，以使系统性能最佳。

在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。

（5.4）评价物理结构

对数据库物理设计过程中产生的多种方案进行评价，从中选择一个较优的方案作为数据库的物理结构。评价方法：定量估算各种方案（存储空间、存取时间、维护代价）；对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。最后返回用户、征求意见、修改设计。

6、数据库的实施和维护

（6.1）数据的载入和应用程序的调试

（1）定义数据库结构

用 DBMS 提供的 DDL 来创建数据库结构。RDBMS 产生目标模式，生成数据字典。

创建基本表：

CREATE TABLE 学生

         (学号 CHAR(8),

        ……………

         );

CREATE TABLE 课程

         (

        ……………

        );

……………

在基本表上定义视图：

CREATE VIEW ....

CREATE VIEW ....

………

在基本表上定义索引：

CREATE UNIQUE INDEX

        ……

CREATE INDEX

（2）数据装载

组织数据入库是数据库实施阶段最主要的工作。

数据装载 —— ETL：数据抽取、数据转换、数据载入。

使用 ETL 工具辅助完成。

（3）编制与调试应用程序

数据库应用程序的设计应该与数据设计并行进行，在数据库实施阶段，编制与调试数据库的应用程序。调试应用程序时由于数据入库尚未完成，可先使用模拟数据。

（6.2）数据库的试运行

数据库的试运行：应用程序调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合调试。

主要工作包括：

功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。

性能测试：测量系统性能指标，分析是否符合设计目标。

数据库性能指标的测量：

数据库物理设计阶段，评价数据库结构，估算时间、空间指标时，作了许多简化和假设，必然是近似结果。

数据库试运行则是要实际测量系统的各种性能指标。如果结果不符合设计目标，则需要返回物理设计阶段，调整物理结构，修改参数；有时甚至需要返回逻辑设计阶段，调整逻辑结构。

（1）数据的分期入库

重新设计物理结构甚至逻辑结构，会导致数据重新入库；由于数据入库工作量实在太大，所以可以采用分期输入数据的方法：先输入小批量数据供先期联合调试使用；待试运行基本合格后再输入大批量数据；逐步增加数据量，逐步完成运行评价。

（2）数据库的转储和恢复

在数据库试运行阶段，系统还不稳定，硬、软件故障随时都可能发生，系统的操作人员对新系统还不熟悉，误操作也不可避免，因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏

（6.3）数据库的运行和维护

在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：

（1）数据库的转储和恢复

数据库管理员要针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份。一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态。

（2）数据库的安全性、完整性控制

初始定义：数据库管理员根据用户的实际需要授予不同的操作权限，根据应用环境定义不同的完整性约束条件。

修改定义：当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制。由于应用环境发生变化，数据库的完整性约束条件也会变化，也需要数据库管理员不断修正，以满足用户要求。

（3）数据库性能的监督、分析和改进

在数据库运行过程中，数据库管理员必须监督系统运行，对监测数据进行分析，找出改进系统性能的方法。利用监测工具获取系统运行过程中一系列性能参数的值；通过分析这些数据，判断当前系统是否处于最佳运行状态；如果不是，则需要通过调整某些参数来改进数据库性能。

（4）数据库的重组织与重构造

数据库重组织的原因：数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。

数据库重组织的主要工作：按原设计要求、重新安排存储位置、回收垃圾、减少指针链、数据库的重组织不会改变原设计的数据逻辑结构和物理结构。

数据库管理系统一般都提供了供重组织数据库使用的实用程序，帮助数据库管理员重新组织数据库。

数据库重构造的原因：数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求：增加新的应用或新的实体、取消某些已有应用、改变某些已有应用。

数据库重构造的主要工作：

① 根据新环境调整数据库的模式和内模式

增加或删除某些数据项；
改变数据项的类型；
增加或删除某个表；
改变数据库的容量；
增加或删除某些索引。

② 重构造数据库的程度是有限的

应用需求变化太大，软件硬件发展太快；
无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。