《数据库系统原理》教案Word格式文档下载.docx

《数据库系统原理》教案Word格式文档下载.docx

《《数据库系统原理》教案Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《《数据库系统原理》教案Word格式文档下载.docx（15页珍藏版）》请在冰豆网上搜索。

第三次：

逻辑结构及物理结构设计。

作业与要求

P234第6、7、9、11、12、13、18、19。

备注

本提交文档内容与次序与实际讲课内容与次序有不一致的地方。

第七章数据库设计

7.1数据库设计的步骤

设计局部视图

集成视图

设计逻辑结构

优化逻辑模型

设计物理结构

评价物理结构

2、概念结构设计

3、逻辑结构设计

4、数据库物理设计

数据库系统的物理实现

试验性运行

5、数据库实施

6、数据库运行和维护

1、需求分析

1、需求分析：

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

是最困难、最耗时的一步。

作为地基的需求分析是否做得充分与准确，决定了在其上构建数据库大厦的速度与质量。

做得不好，甚至会导致整个数据库设计返工重做。

2、概念结构设计阶段：

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

3、逻辑结构设计阶段：

将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化。

4、数据库物理设计阶段：

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

5、数据库实施阶段：

设计人员运用DBMS提供的数据语言及其宿主语言，根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。

6、数据库运行和维护阶段：

数据库应用系统经过试运行后即可投入正式运行。

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

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

7.2需求分析

一、需求分析的过程

需求分析

4、确定

系统边界

3、明确

用户需求

2、熟悉

业务活动

1、调查组织机构总体情况

概念设计

用户与设计人员交互

数据流图

数据字典

1、调查组织机构总体情况：

调查这个组织由哪些部门组成，各部门的职责是什么等，为分析信息流程做准备。

2、熟悉业务活动情况：

调查各部门输入和使用的数据，数据的加工和处理，输出信息，输部门，输出的结果格式等。

是调查的重点。

3、明确用户需求：

在熟悉业务活动的基础上，协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求。

调查重点。

4、确定系统边界：

对调查的结果进行初步分析，确定整个系统中，哪些由计算机完成，哪些将来由计算机完成，哪些由手工完成。

由计算机完成的功能就是新系统应该实现的功能。

*需求分析任务（上述4步概括，也可直接用上述4点回答）：

通过详细调查现实世界要处理的对象，充分了解原系统（手工系统或计算机系统）的工作概况，明确用户的各种需求，然后在此基础上确定新系统的功能。

新系统必须充分考虑今后可能的扩充和改变不能仅仅按当前应用的需求来设计数据库。

其重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。

*用户的信息要求：

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

*用户的处理要求：

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

二、调查方法

1、跟班作业：

通过亲生参加业务工作来了解业务活动的情况。

此法可以比较准确理解用户的需求，但比较耗费时间。

2、开调查会：

通过与用户座谈来了解业务活动情况及用户需求。

座谈时，参加者之间可以相互启发。

3、请专人介绍：

4、询问：

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

5、设计调查表请用户填：

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

6、查阅记录：

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

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

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

四、在众多分析和表达用户需求的方法中，结构化分析方法（structuredanalysis,SA方法）是一种最为简单实用的方法。

SA方法用自顶向下，逐步分解的方式分析系统，用数据流图、数据字典描述系统。

即设计人员首先需要把任何一个系统抽象为下图形式，再

数据存储

数据输出

数据来源

处理

数据流数据流

将处理功能的具体内容分解为若干子功能，在把每个字功能继续分解，直到把系统的工作过程表达清楚为止。

在处理功能分解的同时，他们所用的数据也逐级分解，形成若干层次的数据流图。

数据流图表示数据与处理间的关系。

数据字典则详尽描述系统中的数据。

对数据库设计来说，数据字典是进行详细的数据收集和数据分析所获得的主要结果。

在数据字典中的内容在数据库设计过程中还要不断修改、充实、完善。

五、需求分析举例

例：

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

每个子系统分配一个开发小组。

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

六、数据字典

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

1、数据项：

不可分割的数据单位

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

库存数量范围、含义

2、数据结构

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

{数据项或数据结构}}

3、数据流

可以是数据项，但更一般的情况是数据结构。

表示某一处理过程的输入或输出数据。

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

{数据结构}，平均流量，高峰期流量}

平均流量：

单位时间（每天、每周、每月等）里的传输次数。

高峰期流量：

高峰时期的数据流量。

4、数据存储：

处理过程中要存储的数据

数据存储描述={数据存储名，说明，输入数据流，输出数据流，数据量（每次存储多少数据），存取频度（每天或每小时或每月存取几次），存取方式（批处理还是联系处理，是检索还是更新，是顺序存取还是随机存取）}

5、处理过程：

数据字典中只描述处理过程的说明性信息。

具体处理逻辑一般用判定表与判定树来描述。

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

{输入流}，输出：

{输出流}，处理：

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

说明：

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

7.3概念结构设计

一、最常用的方法

自底向上设计概念结构法，通常分两部：

抽象数据并设计局部视图，集成局部视图

子需求

……….

概念模式

……..

全局概念模式

图概念结构设计策略

概念结构设计

抽象数据，设计局部视图

需求分析逻辑结构设计

总E_R图

分E_R图

图概念结构设计

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

1、选择局部应用

根据系统的具体情况，在多层数据流图中选择一个适当层次的数据流图，让这组图中每一部分对应局部应用，设计分E—R图。

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

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

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

2、逐一设计分E—R图

**将收集在数据字典中局部应用所涉及的数据抽取出来，参照数据流图标识局部应用中的实体、实体属性、标识实体的码，确定实体间的联系及其类型（１:

１，１:

n，1:

m）。

实体抽象：

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

对象与实体间是“ismemberof”关系。

属性抽象：

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

组成成分与对象类型间的关系是“ispartof”关系

**有时实体与属性之间很难有截然划分的界限，同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为实体。

学校的系。

有些环境下只作为属性描述，而在另一些环境中作为实体描述

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

1）属性不能再具有需要描述的性质。

即属性必须是不可分的数据项，不能再由另外一些属性组成。

例子：

2）属性不能与其他实体有联系。

联系只发生在实体间。

职称

教师

分配

性别

姓名

住房

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

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

**学籍管理局部应用的分E-R图草图

教室

上课

管理

班级

班主任

11mn

11

指导

组成

nn

住宿

归档

档案材料

宿舍

学生

1n11

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

1）性别与宿舍分配有关，根据属性准则2应调整为实体（是否描述全）。

拥有

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

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

三、视图集成

分E-R图

基本

E-R图

修改与重构

（消除不必要的冗余）

合并

（消除冲突）

规范化理论

分析

初步E-R图

1、合并分Ｅ—Ｒ图，初步生成Ｅ—Ｒ图

消除冲突。

各分ER图之间的冲突主要有三类：

属性冲突，命名冲突，结构冲突

1）属性冲突

（1）属性域冲突。

学号类型不同分E_R图中分别被说明为整形或字符型。

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

2）命名冲突

（1）同名异义

（2）异名同义

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

其中属性命名冲突更为常见。

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

3）结构冲突

（1）同一对象在不同的应用中具有不同的抽象。

如课程在某一局部应用中被当作实体，而在另一局部应用中被当作属性。

用属性准则加以统一。

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

解决方法为取属性的并集。

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

解决方法：

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

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

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

统一为

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

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

（3）性别在两个局部应用中具有不同的抽象。

学籍管理中为实体，课程管理中为属性。

根据属性准则进行合并。

（4）学生实体的属性的组成与次序在两个不同的分E-R图中都存在差异，应将所有属性综合，并重新调整次序。

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