《数据库系统原理》教案

《数据库系统原理》教案

《数据库系统原理》教案

《数据库系统原理》教案

第七章 数据库设计

7.1数据库设计的步骤

1、 需求分析：准确了解与分析用户需求（包括数据与处理）。

是最困难、最耗时的一步。作为地基的需求分析是否做得充分与准确，决定了在其上构建数据库大厦的速度与质量。做得不好，甚至会导致整个数据库设计返工重做。

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

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

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

《数据库系统原理》教案

5、 数据库实施阶段：设计人员运用DBMS提供的数据语言及其宿主语言，根据逻辑设计和

物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。

6、 数据库运行和维护阶段：数据库应用系统经过试运行后即可投入正式运行。运行过程中

必须不断地对其进行评价、调整与修改。

设计一个完善的数据库应用系统是不可能一蹴而就的，往往是上述6个阶段的不断反复过程。

7.2需求分析

一、需求分析的过程

1、 调查组织机构总体情况：调查这个组织由哪些部门组成，各部门的职责是什么等，为分

析信息流程做准备。

2、 熟悉业务活动情况：调查各部门输入和使用的数据，数据的加工和处理，输出信息，输

部门，输出的结果格式等。是调查的重点。

3、 明确用户需求：在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信

息要求、处理要求、安全性与完整性要求。调查重点。

4、 确定系统边界：对调查的结果进行初步分析，确定整个系统中，哪些由计算机完成，哪

些将来由计算机完成，哪些由手工完成。由计算机完成的功能就是新系统应该实现的功能。

*需求分析任务（上述4步概括，也可直接用上述4点回答）：通过详细调查现实世界要处理的对象，充分了解原系统（手工系统或计算机系统）的工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变不能仅仅按当前应用的需求来设计数据库。其重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。

*用户的信息要求：用户要从数据库中得到哪些信息，这些信息的具体内容和性质，从中确定数据库中应存储哪些数据。

*用户的处理要求：用户要完成什么样的处理功能，对某种处理要求的响应时间，涉及的数据，处理方式是联机还是批处理。

二、调查方法

1、 跟班作业：通过亲生参加业务工作来了解业务活动的情况。此法可以比较准确理解

用户的需求，但比较耗费时间。

2、 开调查会：通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间

可以相互启发。

《数据库系统原理》教案

3、 请专人介绍：

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

5、 设计调查表请用户填：如果调查表设计得合理，此方法很有效，也易于为用户接受。

6、 查阅记录：查阅与原系统有关的数据记录

三、用户和设计人员对设计工作的最后结果共同承担责任

让用户积极参与和配合调查，设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念

四、在众多分析和表达用户需求的方法中，结构化分析方法（structured analysis ,SA方法）

是一种最为简单实用的方法。

SA方法用自顶向下，逐步分解的方式分析系统，用数据流图、数据字典描述系统。 即设计人员首先需要把任何一个系统抽象为下图形式，再

将处理功能的具体内容分解为若干子功能，在把每个字功能继续分解，直到把系统的工作过程表达清楚为止。在处理功能分解的同时，他们所用的数据也逐级分解，形成若干层次的数据流图。

数据流图表示数据与处理间的关系。数据字典则详尽描述系统中的数据。对数据库设计来说，数据字典是进行详细的数据收集和数据分析所获得的主要结果。在数据字典中的内容在数据库设计过程中还要不断修改、充实、完善。

五、需求分析举例

例：学校管理系统，经可行性分析和初步需求调查，抽取出该系统的最高层数据流图，共3个子系统教师管理子系统，学生管理子系统，后勤管理子系统。每个子系统分配一个开发小组。

学生管理子系统包括学籍管理和课程管理。

六、数据字典

数据字典通常由数据项、数据结构、数据流、数据存储和处理过程组成。

1、 数据项：不可分割的数据单位

数据项描述={数据项名，数据项的含义说明，别名，数据类型，长度，取值范

围，取值含义，与其他数据项的逻辑关系}

例：库存数量范围、含义

2、 数据结构

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

3、 数据流

可以是数据项，但更一般的情况是数据结构。表示某一处理过程的输入或输出

数据。

数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，

平均流量，高峰期流量}

平均流量：单位时间（每天、每周、每月等）里的传输次数。高峰期流量：高

峰时期的数据流量。

4、 数据存储：处理过程中要存储的数据

《数据库系统原理》教案

数据存储描述={数据存储名，说明，输入数据流，输出数据流，数据量（每次

存储多少数据），存取频度（每天或每小时或每月存取几次），存取方式（批处理还是联系处理，是检索还是更新，是顺序存取还是随机存取）}

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

与判定树来描述。

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

{简要说明处理过程的功能及处理要求}}

说明：数据字典以能将数据描述清楚为度。

7.3概念结构设计

一、最常用的方法

……….

……….

……….

图 概念结构设计策略

二、数据抽象与局部视图设计

1、 选择局部应用

根据系统的具体情况，在多层数据流图中选择一个适当层次的数据流图，让这

组图中每一部分对应局部应用，设计分E—R图。

往往以中层数据流图作为设计分Ｅ—Ｒ图的依据，因它较好反映系统中各局部

《数据库系统原理》教案

应用子系统的组成。如果局部应用比较复杂，可以从更下层的数据流图入手。

从图6-5 图6-6（a）入手设计学生管理子系统的分E-R图

2、 逐一设计分E—R图

**将收集在数据字典中局部应用所涉及的数据抽取出来，参照数据流图标识局

部应用中的实体、实体属性、标识实体的码，确定实体间的联系及其类型（１:１，１:n，1:m）。

实体抽象：将一组具有某些共同特性和行为的对象抽象为一个实体。

对象与实体间是“is member of ”关系。

属性抽象：对象类型的组成成分可以抽象为实体的属性。

组成成分与对象类型间的关系是“is part of”关系

**有时实体与属性之间很难有截然划分的界限，同一事物，在一种应用环境中

作为“属性”，在另一种应用环境中就必须作为实体。

例：学校的系。有些环境下只作为属性描述，而在另一些环境中作为实体描述

**确定属性准则（考虑到）：

1） 属性不能再具有需要描述的性质。即属性必须是不可分的数据项，

不能再由另外一些属性组成。

例子：

2） 属性不能与其他实体有联系。联系只发生在实体间。

例子：职称

为了简化E_R图的处理，现实世界中的事物凡能够作为属性的，应尽量作为

属性。

例：设计学籍管理局部应用的分E-R图，可用相同方法设计其他局部应用的分E-R图

**

**学籍管理局部应用的分E-R图草图调整，得到分E-R图

1。

2） 数据存储“学生登记表”，有用部分已经转入学生档案中，所以不必作为实体了

（是否重复描述）。

《数据库系统原理》教案

**学籍管理局部应用的分E-R得到分E-R图的所有实体属性

三、视图集成

消除冲突。各分ER图之间的冲突主要有三类：属性冲突，命名冲突，结构

冲突

1) 属性冲突

（1） 属性域冲突。例：学号类型不同分E_R图中分别被说明为整形或

字符型。

（2） 属性的取值单位冲突。

2) 命名冲突

（1） 同名异义

（2） 异名同义

命名冲突在实体、联系和属性上都可能发生。其中属性命名冲突更为

常见。通过讨论、协商等行政手段加以解决。

3) 结构冲突

（1） 同一对象在不同的应用中具有不同的抽象。如课程在某一局部应

用中被当作实体，而在另一局部应用中被当作属性。用属性准则

加以统一。

（2） 同一实体在不同应用局部应用中所包含的属性不完全相同，或属

性的排列次序不同。解决方法为取属性的并集。

（3） 实体间的联系在不同的局部应用中呈现不同的类型。

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

例：学生管理子系统中学籍管理与课程管理局部视图分E_R图存在的冲突

（1） 学籍管理中的“班主任”与课程管理的“教师”在一定程度上属

于异名同义。统一为

教师（职工号，姓名，性别，职称，是否为优秀班主任）

（2） 班主任改为教师后，将两种联系（指导与教学）也综合为教学联

《数据库系统原理》教案

系

（3） 性别在两个局部应用中具有不同的抽象。学籍管理中为实体，课

程管理中为属性。根据属性准则进行合并。

（4） 学生实体的属性的组成与次序在两个不同的分E-R图中都存在差

异，应将所有属性综合，并重新调整次序。

解决上述冲突后得到的学生管理子系统的初步E-R图为：

`

２、 修改与重购，生成基本Ｅ-Ｒ图

**目的：消除冗余的数据和冗余的实体间的联系（冗余容易破坏数据库的完整性，

给数据维护增加困难）

如：

1） 工资单（基本工资，各种补贴，应扣房租水电，实发工资）

实发工资 = 基本工资 + 各种补贴 – 应扣房租水电 （在数据字典中说明）

2） 学生（学号，姓名，出生年月，年龄，所在系，年级，平均成绩）

年龄 = 当前年份 – 出生年月

平均成绩由学生选课联系中的成绩属性推算出

3） 上课联系可由其他联系推算出

**冗余的消除方法：主要为分析法，其分析依据是用数据字典中关于数据项之间逻辑关系的说明来消除冗余。

**并不是所有冗余数据与冗余联系都必须加以消除：为了提高某些应用效率，不得不以冗余信息作为代价。如需要经常查询学生的平均成绩，每次读都需要计

算效率就太底，保留该冗余数据能提高效率。（重点）

**冗余数据的一致性维护：触发器。任何一科成绩修改或学生学了新的科目并有了成绩后，就触发该触发器去修改该学生的平均成绩属性值。（重点）

7.4 逻辑结构设计

主要工作：1、ER图向数据模型转换；2、数据模型优化；3、设计用户子模式

一、ER图向数据模型转换

*将ER图转换为关系模型：将实体、实体属性、和实体间的联系转换为关系模式

《数据库系统原理》教案

*转换的一般原则：

1、 一个实体型转换为一个关系模式，实体的属性就是关系的属性，实体的码就是关系

的码。

2、 一个m:n联系转换为一个关系模式。属性：由与该联系相连的实体码及联系本身的

属性组成。码与该联系相连的实体码的组合。如学生选课联系。

3、 一个1:n联系可以转换为独立的关系模式，也可以与n端对应的关系模式合并。如

学生“组成”班级联系，可以转换成： 组成（学号，班级号）（独立的关系模式，码为n端实体的码）

或

班级号，平均成绩）（与多

端关系模式合并，）

两种表示方法达到同样的目的：学生由组成班级情况。但后一种情况能减少系

统中表的个数，更常用。

4、 1：1联系可以转换为独立的关系模式，也可以与任意一端对应的关系模式合并。 例：教师“管理”班级联系（反映了班主任与班级的对应关系），可以转换为

1） 独立的关系模式 管理（职工号，班级号） 或 管理（职工号，班级号）

2） 与任一端合并 班级（班级号，学生人数，职工号）

或 教师（职工号，姓名，性别，职称，班级号，是否优秀班主任）

注：基于效率考虑，有时联系与某一端合并效率更高。如要经常查询某个班级

的班主任名，则管理联系与教师关系合并更好些。原因是能减少连接操作。

5、 三个或三个以上实体间的联系转换为一个关系模式。与该多元联系相连的各实体的

吗以及联系本身的属性均转换为关系的属性。关系的码为实体码的组合。

6、 自联系即同一实体集的实体间联系，也按上述方法处理。

7、 具有相同码的关系模式可合并：两个关系模式具有相同的主码，可以考虑将他们合

并为一个关系模式。 例：拥有（学号，性别） 学生（学号，姓名，出生年月，所在系，年级，班级号，平均成绩） 合并为：学生（学号，姓名，性别，出生年月，所在系，年级，班级号，平均成绩）

例：依照上述的7个转换规则，学生管理子系统中的18个实体和联系可以转换为下

列关系模型

实体（9个）：有档案材料，班级，宿舍，性别，学生，教师，教室，课程，教科书 联系（9个）：归档，组成，管理，住宿，拥有，教学，选修，讲授，开设

实体：

１、 有档案材料（档案号，…..）

２、 班级（班级号，学生人数）

３、 宿舍（宿舍编号，地址，人数）4性别

４、 性别（性别） 考虑书上属性“宿舍楼”是否显多余？

５、 学生（学号，姓名，出生年月，所在系，年级，平均成绩）1档案号，2班级号，

5性别，

６、 教师（职工号，姓名，性别，职称，是否为优秀班主任）3班级号

《数据库系统原理》教案

７、 教室（教师编码，地址，容量）

８、 课程（课程，课程名，学分）9教室号

９、 教科书（书号，书名，价钱）

联系：（其中只有6、7、8三个需要独立关系模式描述）

１、 归档：1：1归并到 学生实体（档案号）

２、 组成：学生“组成”班级n：1，归并到“学生”（班级号）

３、 管理：教师“管理”班级1：1，归并到“教师”（班级号）

４、 住宿：性别“住宿”宿舍1：n，归并到“宿舍”（性别）

５、 拥有：学生“拥有”性别n：1，归并到“学生”（性别）

６、 教学：学生与教师间的关系m：n，独立关系模式：教学（职工号，学号） ７、 选修：选修（学号，课程号，成绩）

８、 讲授：讲授（课程号，职工号，书号）

９、 开设：课程“开设”教室n：1，归并到“课程”（教室号）

二、数据模型优化

*适当修改、调整数据模型的结构。通常以规范化理论为指导。

三、设计用户子模式

（自看）

１、 使用更符合用户习惯的别名

２、 针对不同级别的用户定义不同的外模式，以满足系统对安全性的要求

３、 简化用户对系统的使用

7．5 数据库的物理设计

一、确定数据库的物理结构

１、 数据库的物理设计：对于设计好的逻辑数据模型选择一个最符合应用要求的物理结构。

物理结构指：数据库在实际的物理设备上的存储结构和存取方法称为数据库的物理结构。

２、 没有通用的物理设计方法可循，原因有

1） 数据库的物理设计完全依赖于给定的硬件环境和数据库产品的。

2） 可能用到的数据库产品多种多样；不同的数据库产品所提供的物理环境、存储结

构和存取方法有很大的区别，能供设计人员使用的设计变量、参数范围也很不相同。

３、 一般的设计内容和原则主要有

1） 确定数据的存储安排：此问题主要是从提高系统性能考虑。例如

（1） 将表和索引分别放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别在

工作，因而可以保证物理读写速度较快

（2） 将比较大的表分别放在两个磁盘上，可以加快存取速度，特别是在多用户环

境下

（3） 将日志文件和数据库对象（表、索引等）分别放在不同的磁盘可以改进系统

的性能。

各系统所提供的对数据进行物理安排的手段、方法差异很大，因此设计

人员应仔细了解给定的DBMS在这方面提供了什么方法，再针对应用环境

的要求，对数据进行适当的物理安排。

2） 设计数据的存取路径

在关系数据库中，主要是指确定如何建立索引。例如：次码索引的建立，组

《数据库系统原理》教案

合索引的建立，其它类型索引。

3） 确定系统配置

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

这些配置变量通常包括：同时使用数据库的用户数；同时打开数据库的对象数；使用的缓冲区长度、个数；数据库大小；锁的数目等，这些参数值影响存取时间和存储分配，在物理设计时要根据应用环境确定这些参数值，以使系统性能最优。

系统配置参数在系统运行时需要做进一步调整，以期切实改进系统性能。

二、评价数据库的物理结构

7.6 数据库实施

１、 用DDL定义数据结构

２、 组织数据入库

３、 编制与调试应用程序

４、 数据库试运行

7．7数据库运行和维护

１、 数据库的转储和恢复

２、 数据库的安全性与完整性控制

３、 数据库性能的监督、分析和改进

４、 数据库的重组织和重构造

本文来源：https://www.bwwdw.com/article/u9xj.html