08 第8章 数据库的设计.pptx

第1页：第8章数据库的设计

第8章数据库的设计

第2页：概述：数据库设计的基本概念

概述：数据库设计的基本概念

• 数据库设计的基本概念
• 数据库设计人员应具备的知识
• 数据库设计的特点
• 数据库设计的方法
• 数据库设计的基本步骤

第3页：数据库设计的基本概念

数据库设计的基本概念

• 数据库设计是建立数据库及其应用系统的技术的基础，是信息系统开发和建设中的核心技术和重要的组成部分。
• 具体来讲，数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。

第4页：数据库设计的专业人员应具备的知识

数据库设计的专业人员应具备的知识

• 计算机的基础知识和程序设计的方法与技巧；
• 软件工程的原理和方法；
• 数据库的基础知识和设计技术；
• 应用领域的知识。其中应用领域的知识随着应用系统所属的领域不同而不同。数据库设计人员必须深入实际与用户密切接触，对应用环境、专业知识有具体深入的了解才能设计出符合具体领域要求的数据库应用系统。

第5页：数据库设计的特点

数据库设计的特点

• 将技术和管理相结合
• 强调结构（数据）设计和行为（处理）设计相结合。

第6页：数据库设计应该与应用系统设计相结合

数据库设计应该与应用系统设计相结合

结构（数据）设计

设计数据库框架或数据库结构

行为（处理）设计

设计应用程序、事务处理等

第7页：一个性能优良的数据库

一个性能优良的数据库

• 一个性能优良的数据库不可能一次性地完成设计，需要经过“反复探寻，逐步求精”的过程。首先从数据模型开始设计，以数据模型为核心进行展开，将数据库设计和应用系统设计相结合，建立一个完整、独立、共享、冗余小和安全有效的数据库系统。

第8页：数据库设计的方法

数据库设计的方法

• 直观设计法
• 规范设计法
• 计算机辅助设计法
• 自动化设计法这些设计方法大都是数据库设计在不同阶段所使用的具体技术和方法。

第9页：数据库设计的基本步骤

数据库设计的基本步骤

• 按照规范的设计方法，考虑数据库及应用系统开发的全过程，将数据库设计分为以下六个阶段：
  • 需求分析
  • 概念结构设计
  • 逻辑结构设计
  • 物理设计
  • 数据库实施
  • 数据库的运行和维护

第10页：需求收集和分析应用需求

需求收集和分析应用需求

（数据、处理）设计概念结构设计逻辑结构数据模型优化设计物理结构评价设计、性能预测数据库实现试验性运行数据库运行和维护转换规则、DBMS功能、优化方法不满意不满意应用要求、DBMS详细特征逻辑设计阶段物理设计阶段数据库实施阶段需求分析阶段概念设计阶段数据库运行和维护阶段

第11页：IPO表与设计阶段描述

IPO表与设计阶段描述

IPO表……输入：输出：处理：Creat……Load……Main()……if……then……end分区1分区2……逻辑结构设计概念结构设计物理设计设计阶段设计描述数据处理需求分析组织机构、各部门中与系统相关的工作内容及流程、所有表单、报表数据及功能的描述所有数据的处理过程及其功能的描述概念模型（E-R图）数据字典系统说明书包括：①新系统要求、方案和概图②反映新系统信息流的数据流图某种数据模型关系非关系系统结构图（模块结构）存储安排方法选择存取路径建立模块设计IPO表实施阶段编写模式装入数据数据库试运行程序编码、编译联结、测试运行维护性能监测、转储/恢复数据库重组和重构新旧系统转换、运行、维护（修正性、适应性、改善性维护）

第12页：需求分析

需求分析

• 需求分析就是分析用户对数据库的具体要求，需求分析是整个数据库设计的起点。它的结果需要准确地反映用户的实际要求，因为这将影响到后面各个阶段的设计和最终结果是否合理和实用。
• 准确了解与分析用户需求（包括数据与处理）是整个设计过程的基础，是最困难、最耗费时间的一步

第13页：需求分析的任务

需求分析的任务

• 通过详细调查现实世界要处理的对象（组织、部门、企业等），充分了解原系统（手工系统或计算机系统）工作概况，明确用户的各种需求
• 在此基础上确定新系统的功能。新系统必须充分考虑今后可能的扩充和改变，不能仅仅按当前应用需求来设计数据库

第14页：需求分析的重点

需求分析的重点

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

第15页：信息要求

信息要求

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

第16页：处理要求

处理要求

• 对处理功能的要求
• 对处理的响应时间的要求
• 对处理方式的要求(批处理/联机处理)

第17页：安全性与完整性要求

安全性与完整性要求

• 安全性是指用户需要如何保护数据不被未授权的用户破坏，完整性是指用户需要如何检查和控制不合语义的、不正确的数据，防止它们进入数据库。

第18页：需求分析的难点

需求分析的难点

• 用户缺少计算机知识，开始时无法确定计算机究竟能为自己做什么，不能做什么，因此无法一下子准确地表达自己的需求，他们所提出的需求往往不断地变化。
• 设计人员缺少用户的专业知识，不易理解用户的真正需求，甚至误解用户的需求。
• 新的硬件、软件技术的出现也会使用户需求发生变化。

第19页：解决方法

解决方法

• 设计人员必须采用有效的方法，与用户不断深入地进行交流，才能逐步得以确定用户的实际需求

第20页：需求分析的步骤

需求分析的步骤

• 调查组织机构情况（组织部门的组成情况、各部门的职责等）
• 调查各部门的业务活动情况（各个部门输入和使用什么数据、如何加工处理这些数据、输出什么信息、输出到什么部门、输出结果的格式是什么）。--调查重点之一
• 在熟悉业务活动的基础上，协助用户明确对新系统的各种要求（信息要求、处理要求、完全性与完整性要求）。--调查重点之二。
• 对前面调查的结果进行初步分析（确定新系统的边界：即确定哪些功能由计算机完成或将来准备让计算机完成、确定哪些活动由人工完成，由计算机完成的功能就是新系统应该实现的功能。）

第21页：需求调查的常用方法

需求调查的常用方法

• 跟班作业
• 开调查会
• 请专人介绍或询问
• 设计调查表请用户填写
• 查阅记录（包括各类报单、报表）

第22页：做需求调查时、无论使用何种调查方法

做需求调查时、无论使用何种调查方法

• 做需求调查时，往往需要同时采用多种方法
• 无论使用何种调查方法，都必须有用户的积极参与和配合
• 设计人员应该和用户取得共同的语言，帮助不熟悉计算机的用户建立数据库环境下的共同概念，并对设计工作的最后结果共同承担责任

第23页：解用户需求后、分析和表达用户需求

解用户需求后、分析和表达用户需求

• 了解用户需求后，还需要进一步分析和表达用户的需求，使之转换为后续各设计阶段可用的形式。
• 分析和表达用户需求的方法很多，其中结构化分析(StructuredAnalysis，SA)方法是一个简单实用的方法。
• SA方法是从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并且把每一层用数据流图和数据字典进行描述。

第24页：对需求调查结果的分析

对需求调查结果的分析

• 系统抽象
• 分解处理功能和数据

第25页：数据流

数据流

数据流数据存储信息要求数据来源处理数据输出处理要求首先把任何一个系统都抽象为

第26页：分解处理功能和数据

分解处理功能和数据

• 分解处理功能
  • 将处理功能的具体内容分解为若干子功能，再将每个子功能继续分解，直到把系统的工作过程表达清楚为止。
• 分解数据
  • 在处理功能逐步分解的同时，其所用的数据也逐级分解，形成若干层次的数据流图
  • 数据流图表达了数据和处理过程的关系
• 表达方法
  • 处理过程：用判定表或判定树来描述
  • 数据：用数据字典来描述

第27页：需求分析

需求分析

阶段的工作结果是数据库设计的重要基础，因此对用户需求进行分析和表达后，必须要交给用户，征得用户的认可。

第28页：需求分析过程小结

需求分析过程小结

本页以图示呈现，正文文字较少，建议对照原课件图片查看。

第29页：数据流

数据流

7、数据流图数据流图（DFD，Data Flow Diagram）是描述各处理活动之间数据流动的有力工具，是一种从数据流的角度描述一个组织业务活动的图示。数据流图被广泛用于数据库设计中，并作为需求分析阶段的重要文档资料——系统需求说明书的重要内容，也是数据库信息系统验收的依据。

第30页：数据流

数据流

（1）数据流图中使用的基本符号及其含义或数据源点或宿点或变换数据的处理或数据存储数据流

第31页：从原则上讲、分层数据流图中

从原则上讲、分层数据流图中

• 从原则上讲，只要有足够大的纸，一个软件系统的数据流图可以画在一张纸上。但当系统比较复杂时，为了便于理解，控制其复杂性，根据自顶向下逐层分解的思想，可以将数据流图进行分层绘制。
• 在分层数据流图中，顶层图只有一张图，其中只有一个处理，代表整个软件系统，该处理描述了软件系统与外界（源或宿）之间的数据流；顶层图中的加工经过分解后的图称为0层图，也只有一张，它描述系统的全貌，揭示了系统的组成部分及各部分之间的关系；
• 1层图分别描述各子系统的结构。如果系统结构还比较复杂，那么可以继续细化，直到表达清楚为止。在处理功能逐步分解的同时，它们所用的数据也逐级分解，形成若干层次的数据流图。

第32页：顶层数据流图

顶层数据流图

• 1.1数据流图n.1数据流图n.p数据流图
• 1.
• 1.1数据流图
• 1.1.q............1层图...顶层图0层图

第33页：数据流图应用举例

数据流图应用举例

• 以图书管理系统开发的需求调研为例，在详细调查用户需求后，经过抽象、综合，将用户的活动归类为：注册、借书、还书和图书查询等活动。在此基础上可将业务活动描述如下：
  • 注册：工作人员对读者进行信息注册，发放借书证。
  • 借书：首先输入读者的借书证号，检查借书证是否有效；如借书证有效，则查阅借还书登记文件，检查该读者所借图书是否超过可借图书数量（不同类别的读者具有不同的可借图书数量）。若超过，拒绝借阅；未超过，再检查图书的库存数量，在有库存的情况下办理借书，修改库存数量，并记录读者借书信息。
  • 还书：根据所还图书编号及借书证编号，从借还书登记文件中，查阅与读者有关的记录，查阅所借日期。如果超期，作罚款处理；否则，修改库存信息与借还书记录。
  • 图书查询：根据一定的条件对图书进行查询，并可查看图书详细信息。

第34页：图书管理系统顶层

图书管理系统顶层

数据流图通过以上描述可以把握用户的工作需求，要进一步分析系统范围内的用户活动所涉及数据的性质、流向和所需的处理，用数据流图进行描述。图书管理系统顶层数据流图如下：图书管理系统流通部读者部借书信息图书拒借信息注册信息借书证还书信息罚款单

第35页：图书管理系统的数据项

图书管理系统的数据项

图书管理系统的0层数据流图流通部借书还书借书信息图书拒借信息读者表图书表借还表还书信息罚款单注册读者部注册信息借书证读者信息图书信息还书信息读者信息借书信息借书信息

第36页：还书处理的第

还书处理的第

1层数据流图还书审核还书信息超期处理登记入库借还表图书表登记还书未超期图书经处理的超期图书罚款单超期图书读者读者信息图书信息图书/读者信息借书信息还书信息

第37页：数据字典

数据字典

数据字典

进行数据收集和数据分析所获得的主要成果。数据字典是各类数据描述的集合,是数据库设计中的又一个有力工具。

数据字典

对数据流图中出现的所有数据元素给出逻辑定义和描述，可供系统设计者，软件开发者、系统维护者和用户参照使用。

数据字典通常包括

数据项、数据结构、数据流、数据存储和处理过程五个部分。

第38页：数据项

数据项

数据项

不可再分的数据单位。对数据项的描述通常包括以下内容：数据项描述＝｛数据项名称，别名，数据项含义说明，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系｝

其中

取值范围、与其他数据项的逻辑关系定义了该数据项的完整性约束条件，是设计数据检查功能的依据。当然不是每个数据项描述都包含上述所有内容。

第39页：图书管理系统涉及很多

图书管理系统涉及很多

• 图书管理系统涉及很多数据项，其中“借书证号”数据项可以描述如下：数据项：借书证号别名：卡号含义说明：唯一标识一个借书证类型：字符型长度：10取值范围：[S|T]000000000至[S|T]999999999取值含义：第一位是字母，代表学生(S)或老师(T)；第二、三位标识该学生所在年级，第四、五位标识该学生所在系部，后五位按顺序编号。

第40页：数据结构

数据结构

• 数据结构反映了数据项之间的组合关系。
• 一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。
• 对数据结构的描述通常包括以下内容：数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝

第41页：图书管理系统中

图书管理系统中

• 在图书管理系统中，“读者”是核心数据结构之一，它可以描述如下：数据结构名：读者含义说明：是图书管理系统的主体数据结构之一，定义了一个读者的相关信息组成：={[学号|工号]＋姓名＋性别＋年龄＋所在系＋年级＋借书证号}

第42页：数据流

数据流

• 数据流是数据结构在系统内传输的路径。对数据流的描述通常包括以下内容：数据流描述＝｛数据流名称，说明，数据流来源，数据流去向，组成:｛数据结构｝，平均流量，高峰期流量｝
• 其中：
  • 数据流来源说明该数据流来自哪里，可以是一个处理、源或文件；
  • 数据流去向说明该数据流将到哪个处理、宿或文件。
  • 平均流量是指在单位时间（每天、每周、每月等）中的传输次数。
  • 高峰期流量则是指在高峰时期的数据流量。

第43页：“罚款单”是图书管理

“罚款单”是图书管理

• “罚款单”是图书管理系统中的一个数据流，具体描述如下：数据流名：罚款单说明：超期归还图书的处理结果数据流来源：超期处理数据流去向：流通部(或读者)组成：={借书证号＋姓名＋图书编号＋书名＋超期天数＋罚款金额}平均流量：……高峰期流量：……

第44页：数据储存

数据储存

• 数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一。对数据存储的描述通常包括以下内容：
• 数据存储描述＝｛数据存储名，说明，编号，写文件加工，读文件加工，组成:｛数据结构｝，数据量，存取方式｝
• 其中：
  • 流入的数据流要指出其来源；
  • 流出的数据流要指出其去向；
  • 数据量是指每次存取多少数据，每天（或每小时、每周等）存取几次等信息；
  • 存取方式包括是批处理还是联机处理，是检索还是更新，是顺序检索还是随机检索等。

第45页：“图书借阅表”是图书

“图书借阅表”是图书

• “图书借阅表”是图书管理系统中的一个数据存储，具体描述如下：数据存储名：借还表说明：记录图书借阅的基本信息写文件的处理：登记借书、登记还书流出数据流：还书审核组成：={借书证号＋图书编号＋借阅日期＋应归还日期＋实际归还日期…}数据量：平均每年60000条存取方式：随机存取

第46页：处理过程

处理过程

• 数据字典中只需要描述处理过程的说明性信息，通常包括以下内容：处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝,处理逻辑:｛简要说明｝｝
• 其中，简要说明中主要描述该处理过程的功能及处理要求。
  • 功能是指该处理过程用来做什么(而不是怎么做)
  • 处理要求包括处理频度要求，如单位时间里处理多少事务，多少数据量；响应时间要求等。这些处理要求是后面物理设计的输入及性能评价的标准。

第47页：处理过程“还书审核”

处理过程“还书审核”

• 处理过程“还书审核”可如下描述：处理过程名：还书审核说明：认定该图书借阅是否超期输入：还书信息、借书信息、读者信息输出：超期图书或未超期图书处理逻辑：根据借阅表和读者表，如果借阅图书没有超过规定的期限，认定未超期图书，否则认定为超期图书。要求从借阅之日起，学生借阅时间不能超过3个月，教师不能超过6个月。

第48页：由此可见

由此可见

，数据字典是关于数据库中数据的描述，而不是数据本身。数据本身将存放在物理数据库中，由数据库管理系统管理。数据字典有助于这些数据的进一步管理和控制，为设计人员和数据库管理员在数据库设计、实现和运行阶段控制有关数据提供依据。

第49页：概念结构设计

概念结构设计

概念结构

各种数据模型的共同基础，它比数据模型更独立于机器、更抽象，从而更加稳定。

概念结构设计

整个数据库设计的关键

第50页：现实世界到机器世界的抽象

现实世界到机器世界的抽象

现实世界机器世界信息世界需求分析概念结构设计

本页以图示呈现，正文文字较少，建议对照原课件图片查看。

第51页：概念结构设计的特点

概念结构设计的特点

• （1）能真实、充分地反映现实世界，包括事物和事物之间的联系，能满足用户对数据的处理要求。是对现实世界的一个真实模型。
• （2）易于理解，从而可以用它和不熟悉计算机的用户交换意见，用户的积极参与是数据库的设计成功的关键。
• （3）易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
• （4）易于向关系、网状、层次等各种数据模型转换。

第52页：描述概念模型的工具

描述概念模型的工具

• E-R模型

第53页：概念结构设计的方法

概念结构设计的方法

• 自顶向下
  • 首先定义全局概念结构的框架，然后逐步细化
• 自底向上
  • 首先定义各局部应用的概念结构，然后将它们集成起来，得到全局概念结构
• 逐步扩张
  • 首先定义最重要的核心概念结构，然后向外扩充，以滚雪球的方式逐步生成其他概念结构，直至总体概念结构
• 混合策略
  • 将自顶向下和自底向上相结合，用自顶向下策略设计一个全局概念结构的框架，以它为骨架集成由自底向上策略中设计的各局部概念结构。

第54页：自顶向下策略

自顶向下策略

本页以图示呈现，正文文字较少，建议对照原课件图片查看。

第55页：自底向上策略

自底向上策略

本页以图示呈现，正文文字较少，建议对照原课件图片查看。

第56页：逐步扩张策略

逐步扩张策略

本页以图示呈现，正文文字较少，建议对照原课件图片查看。

第57页：概念结构设计的步骤

概念结构设计的步骤

• 常用策略
  • 自顶向下地进行需求分析
  • 自底向上地设计概念结构
• 自底向上设计概念结构的步骤
  • 第1步：抽象数据并设计局部视图
  • 第2步：集成局部视图，得到全局概念结构
• 见P211图7.8

第58页：数据抽象与局部视图设计

数据抽象与局部视图设计

• 数据抽象
• 局部视图设计

第59页：数据抽象

数据抽象

• 概念结构是对现实世界的一种抽象
  • 从实际的人、物、事和概念中抽取所关心的共同特性，忽略非本质的细节
  • 把这些特性用各种概念精确地加以描述
  • 这些概念组成了某种模型

第60页：三种常用抽象

三种常用抽象

• 分类
• 聚集
• 概括

第61页：分类（Classification）

分类（Classification）

• 定义某一类概念作为现实世界中一组对象的类型
• 这些对象具有某些共同的特性和行为
• 它抽象了对象值和型之间的“is member of”的语义
• 在E-R模型中，实体型就是这种抽象见P212图7.10

第62页：聚集（Aggregation）

聚集（Aggregation）

• 定义某一类型的组成成分
• 它抽象了对象内部类型和成分之间“is partof”的语义
• 在E-R模型中若干属性的聚集组成了实体型，就是这种抽象见P212图7.11

第63页：概括（Generalization）

概括（Generalization）

• 定义类型之间的一种子集联系
• 它抽象了类型之间的“is subset of”的语义
• 概括有一个很重要的性质：继承性。子类继承超类上定义的所有抽象。例：P217图6.13

第64页：注：原E-R模型不具有概括

注：原E-R模型不具有概括

• 用双竖边的矩形框表示子类，
• 用直线加小圆圈表示超类-子类的联系

第65页：数据抽象的用途

数据抽象的用途

• 对需求分析阶段收集到的数据进行分类、组织（聚集），形成
  • 实体
  • 实体的属性，标识实体的码
  • 确定实体之间的联系类型(1:1，1:n，m:n)

第66页：局部视图设计设计

局部视图设计设计

（2）局部视图设计设计分E-R图的步骤:⒈选择局部应用⒉逐一设计分E-R图

第67页：选择局部应用

选择局部应用

• 需求分析阶段，已用多层数据流图和数据字典描述了整个系统。
• 设计分E-R图首先需要根据系统的具体情况，在多层的数据流图中选择一个适当层次的数据流图，让这组图中每一部分对应一个局部应用，然后以这一层次的数据流图为出发点，设计分E-R图。

第68页：通常以中层数据流图作

通常以中层数据流图作

• 通常以中层数据流图作为设计分E-R图的依据。原因：
  • 高层数据流图只能反映系统的概貌
  • 中层数据流图能较好地反映系统中各局部应用的子系统组成
  • 低层数据流图过细

第69页：分E-R图的设计入手点

分E-R图的设计入手点

对于学籍管理、课程管理等不太复杂的系统，可以从它们数据流图入手设计学生管理子系统的分E-R图。如果局部应用比较复杂，则可以从更下层的数据流图入手。

第70页：逐一设计分E-R图

逐一设计分E-R图

• 标定局部应用中的实体、属性、码，实体间的联系
  • 将各局部应用涉及的数据分别从数据字典中抽取出来，参照数据流图，标定各局部应用中的实体、实体的属性、标识实体的码，确定实体之间的联系及其类型（1:1，1:n，m:n）

第71页：实体：现实世界中一组具有某些共

实体：现实世界中一组具有某些共

• 现实世界中一组具有某些共同特性和行为的对象就可以抽象为一个实体。对象和实体之间是“is member of"的关系。例：在学校环境中，可把张三、李四等对象抽象为学生实体。

第72页：属性：对象类型的组成成分可以抽

属性：对象类型的组成成分可以抽

• 对象类型的组成成分可以抽象为实体的属性。组成成分与对象类型之间是“is partof"的关系。例：学号、姓名、专业、年级等可以抽象为学生实体的属性。其中学号为标识学生实体的码。

第73页：如何区分实体和属性

如何区分实体和属性

• 实体与属性是相对而言的。同一事物，在一种应用环境中作为“属性”，在另一种应用环境中就必须作为“实体”。例：学校中的系，在某种应用环境中，它只是作为“学生”实体的一个属性，表明一个学生属于哪个系；而在另一种环境中，由于需要考虑一个系的系主任、教师人数、学生人数、办公地点等，这时它就需要作为实体了。

第74页：一般原则 属性的特性

一般原则 属性的特性

• 属性必须是不可分的数据项，不能再由另一些属性组成。
• 属性不能与其他实体具有联系。联系只发生在实体之间。
  • 符合上述两条特性的事物一般作为属性对待。
  • 为了简化E-R图的处置，现实世界中的事物凡能够作为属性对待的，应尽量作为属性。

第75页：例1：“学生”由学号、姓名等属性

例1：“学生”由学号、姓名等属性

举例例1：“学生”由学号、姓名等属性进一步描述，根据准则１，“学生”只能作为实体，不能作为属性。例2：职称通常作为教师实体的属性，但在涉及住房分配时，由于分房与职称有关，也就是说职称与住房实体之间有联系，根据准则２，这时把职称作为实体来处理会更合适些。（教程Ｐ194图6-10）

第76页：设计分E-R图的步骤

设计分E-R图的步骤

• 数据字典中的“数据结构”、“数据流”和“数据存储”等已是若干属性的有意义的聚合（2）按上面给出的准则进行必要的调整。

第77页：在图书管理系统中的实体

在图书管理系统中的实体

• 由于一本图书可以借给多个学生阅读，而一个学生又可以借阅多本图书，因此图书与读者之间是m:n的联系；
• 由于一个读者属于一种读者类型，一种读者类型包括多名读者，因此读者类型与读者之间是1:n的联系。

第78页：得到：“注册”局部应用的分E-

得到：“注册”局部应用的分E-

得到“注册”局部应用的分E-R图读者类别属于n1卡号姓名性别部门办卡日期卡状态类型编号借阅天数类型名称借阅数量

第79页：得到：“借还”局部应用的分E-

得到：“借还”局部应用的分E-

得到“借还”局部应用的分E-R图读者图书借还mn卡号读者类别书号作者名称库存数量出版社价格包括类别r1类别编号类别名称类别备注借书日期还书日期

第80页：全局概念结构的集成

全局概念结构的集成

• 当所有的局部E-R图设计完毕后，就可以对局部E-R图进行集成。
• 集成即把各局部E-R图加以综合连接在一起，使同一实体只出现一次，消除不一致和冗余。局部E-R模型的集成一般需要经过两个步骤：(1)合并，解决各局部E-R图之间的冲突问题，生成初步的E-R图。(2)修改和重构，消除不必要的冗余，生成基本的E-R图。见P220-223

第81页：逻辑结构设计

逻辑结构设计

概念结构

独立于任何一种数据模型的信息结构，它与DBMS无关。

逻辑结构设计的任务就

把概念结构设计阶段产生的系统基本E-R图转换为某种具体的DBMS所支持的数据模型相符合的逻辑结构。

逻辑结构设计一般分三步

①将概念结构转换为一般的关系、网状或层次模型。②将转换来的关系、网状、层次模型向DBMS支持下的数据模型转换，变成合适的数据库模式。③对模式进行调整和优化。

第82页：E-R图向关系模型的转换

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

• E-R图由实体、实体的属性、实体之间的联系三个要素组成，因此E-R图向关系模型的转换就是解决如何将这三要素转换成关系模型中的关系和属性以及如何确定关系的码。

第83页：在E-R图向关系模式的转换遵循的原则

在E-R图向关系模式的转换遵循的原则

• 实体的转换原则
• 联系的转换原则

第84页：实体的转换

实体的转换

• 原则1：一个实体型转换为一个关系模式，实体名成为关系名，实体的属性成为关系的属性，实体的码就是关系的码。

第85页：联系的转换

联系的转换

• 由于实体间的联系存在一对一、一对多、多对多三种联系类型，所以实体间的联系转换时，则采取不同的原则。

第86页：1：1联系的转换

1：1联系的转换

• 原则2：一个1：1联系，可以将联系转换成一个独立的关系模式，也可以与联系的任意一端对应的关系模式合并。
• 如果转换成独立的关系模式，则与该联系相连的各实体的码及联系本身的属性均转换成新关系的属性，每个实体的码均是该关系的候选码；
• 如果将联系与其中的某端实体对应的关系模式合并，则需在该关系模式中加上另一关系模式的码及联系自身的属性。

第87页：1：n联系的转换

1：n联系的转换

• 原则3：一个1：n联系，可以将联系转换成一个独立的关系模式，也可以与n端对应的关系模式合并。
• 如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系自身的属性均转换成新关系模式的属性，n端实体的码成为新关系的码；
• 如果将其与n端实体对应的关系模式合并，则将1端关系的码和联系的自身的属性加入到n端实体对应的关系模式中，这时n端实体对应的关系模式的码仍然保持不变。

第88页：m：n联系的转换

m：n联系的转换

• 原则4：对于m:n联系，将其转换成一个独立的关系模式。与该联系相连的各实体的码及联系自身的属性均转换成新关系的属性，而新关系模式的码为各实体的码的组合。

第89页：多元联系的转换

多元联系的转换

• 原则5：对于三个或三个以上实体的多元联系可以转换成一个独立的关系模式。与该联系相连的各实体的码及联系本身的属性均转换成新关系的属性，而新关系模式的码为各个实体的码的组合。

第90页：关系模式的合并

关系模式的合并

• 原则6：具有相同码的关系模式可以合并。
• 为减少系统中的关系个数，如果两个关系模式具有相同的主码，可以考虑将它们合并为一个关系模式，合并时将其中一个关系模式的全部属性加入到另一个关系模式，然后去掉其中的同义属性，并适当调整属性的次序。

第91页：例如在转换中得到的关

例如在转换中得到的关

• 例如在转换中得到的关系模式中得到“属于”和“读者”两个关系模式：
  • 属于（卡号，读者类别ID）
  • 读者（卡号，姓名，性别，部门，办卡日期，卡状态）
• 两者的码均是“卡号”，因此可以将这两个关系模式进行合并，合并后的关系模式为：
  • 读者（卡号，姓名，性别，部门，办卡日期，卡状态，读者类别ID）

第92页：逻辑结构的优化

逻辑结构的优化

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

第93页：常用的优化步骤

常用的优化步骤

1）确定各属性间的数据依赖。从E-R图转换而来的关系模式还只是逻辑结构的雏形，根据需求分析阶段得到的语义，用数据依赖的概念分析和表示数据之间的联系，写出每个关系模式的各属性之间的函数依赖以及不同关系模式各属性之间的数据依赖关系。2）对于各个关系模式之间的数据依赖进行极小化处理，消除冗余联系。3）根据数据依赖的理论逐一分析各关系模式，考查是否存在部分函数依赖，传递函数依赖等，确定它们分别属于第几范式。4）按照需求分析阶段得到的处理要求，分析这些模式对于这样的应用环境是否合适，确定是否要对某些模式进行合并和分解。5）对关系模式进行必要的分解。我们知道被查询关系的大小对查询的速度有很大的影响，为了提高数据操作的效率和存储空间的利用率，有时需要把关系进行分割。常用方法是水平分解和垂直分解，这两种方法的思想都是提高数据访问的局部性。

第94页：外模式的设计

外模式的设计

• 将概念结构转换为逻辑结构后，也就生成了整个应用系统的模式，此时，还应该根据局部应用的需求，结合具体DBMS的特点设计用户的外模式。
• 外模式是用户所看到的数据模式，各类用户有各自的外模式。目前关系数据库管理系统一般都提供了视图概念，可以利用这一功能设计更符合局部用户需要的外模式。

第95页：定义外模式时可以考虑如下几个方面

定义外模式时可以考虑如下几个方面

• (1)尽可能符合不同用户的使用习惯
• (2)保证数据的安全性
• (3)简化用户对系统的使用

第96页：应用实例

应用实例

• 为学生信息管理系统设计一个学生信息数据库，该系统主要实现对学生基本信息、班级、课程、教师等的管理，学生选课管理以及数据的综合查询统计等功能。学生信息管理系统功能需求包括：基本信息管理、课程设置与选课管理、查询与统计。

第97页：功能需求分析

功能需求分析

• （1）基本信息管理该模块包括班级信息、学生基本信息、课程基本信息、教师基本信息的输入、维护、删除功能。
• （2）课程设置与选课管理该模块包括学期课程设置、编制课表、学生选课。学期课程设置设定本学期所开设课程并安排相应的教师；编制课程表，根据学期课程安排编制课程表；根据学期的课程安排和课程表，学生进行选课。
• （3）查询与统计查询和统计学生、教师、课程的基本信息、课表信息、学期课程安排信息、课程表、学生选课信息等。

第98页：得到如下的数据需求

得到如下的数据需求

（1）班级信息

班级编号、班级名称、专业、所属院系、入学年度、学制、备注。

（2）学生基本信息

学号、姓名、性别、出生日期、政治面貌、毕业学校、照片、籍贯、备注。

（3）课程信息

课程编号、课程名、类别、学分、备注

（4）教师信息

工号、姓名、性别、所在院系、专业、学历、毕业学校、备注。

（5）教室信息

教室编号、教室名称、位置、容纳人数、备注。

（6）班级学生表

班级编号、学号、状态、备注。

（7）学期课程安排表

安排编号、学期、课程编号、教师编号、周课时数、上课周数、开始时间、结束时间、考试方式、学分、班级编号、备注。

（8）课程表

课程表编号、安排编号、教室编号、上课时间、备注。

（9）学生选课表

课程安排编号、学号、成绩、备注。

第99页：编写数据字典

编写数据字典

• 对数据项、数据结构、数据流、数据存储、处理过程进行描述。

第100页：班级编号数据项描述

班级编号数据项描述

数据项“班级编号”描述：数据项：班级编号别名：班级号含义说明：唯标识一个班级类型：字符型长度：10位取值范围：0000000001-9999999999取值含义：前4位为该班建立的年度号；第5位标注入学季节，0为春季入学，1为秋季入学；第6、7位为所在二级学院序列号；第8位为所在系序列号；第9位为所学专业序列号；第10位为相关专业的班级序列号。

本页主体为图示表格，源文本仅提取到图中标注文字，未还原为表格，建议对照原课件图片查看。

第101页：“课程信息”的数据结构描述

“课程信息”的数据结构描述

数据结构名

课程信息

含义说明

它是学生选课的依据之一，定义了一门课程的相关信息

组成

=课程编号+课程名+类别+学分+备注

第102页：“学期课程安排表”的数据流描述

“学期课程安排表”的数据流描述

数据流名

学期课程安排表

说明

下学期授课的安排信息

数据流来源

授课计划、教室信息表、教师信息表、课程信息表

数据流去向

听课学生、任课教师、教务处

组成

安排编号+学期+课程编号+教师编号+周课时数+上课周数+开始时间+结束时间+考试方式+班级编号+学分+备注

平均流量

10000条/年

高峰期流量

300条/天

第103页：“学生信息表”数据存储描述

“学生信息表”数据存储描述

数据存储名

学生信息表

说明

记录学生的基本信息

写文件的处理

新生入学报到后从新生登记表中获取信息并输入。

流出数据流

为所有学生相关的表如成绩表登记、选课表登记等提供学生基本信息。也为学生基本信息查询、统计模块提供原始数据。

组成

学号+姓名+性别+出生日期+政治面貌+毕业学校+照片+籍贯+备注

数据量

平均每年30000条

存取方式

随机存取

第104页：进行概念结构设计

进行概念结构设计

• 经过分析、归纳、整理，可以得到的具体实体有：学生、教师、课程、班级、教室等。学生、教师、课程、班级、教室实体

第105页：实体属性图

实体属性图

得到相关实体的属性图

本页以图示呈现，正文文字较少，建议对照原课件图片查看。

第106页：E-R图

E-R图

得到E-R图

本页以图示呈现，正文文字较少，建议对照原课件图片查看。

第107页：逻辑结构设计

逻辑结构设计

• 学生（学号，姓名，性别，出生日期，政治面貌，毕业学校，籍贯，照片，备注）
• 教师（工号，姓名，性别，所在院系，专业，毕业学校，学历，照片，备注）
• 班级（班级编号，班级名称，专业，入学年度，学制，所属院系，备注）
• 教室（教室编号，教室名称，位置，容纳人数，备注）
• 课程（课程编号，课程名称，学分，类别，备注）

第108页：增加m:n联系对应的关系

增加m:n联系对应的关系

• 由于存在m:n的关系，所以需要增加一些关系：
  • 选课-成绩（学号，课程号，任课教师编号，成绩，学分）
  • 课程-教室（课程编号，教室编号，上课时间）

第109页：物理结构设计

物理结构设计

• 物理结构设计根据具体的DBMS的特点和应用处理的需要，将逻辑结构设计的关系模式进行物理存储安排，建立索引，形成数据库的内模式。

第110页：数据库

数据库

的物理结构设计通常分为两步：①确定数据库的物理结构；②对物理结构进行评价，评价的重点是时间和空间效率。

第111页：确定数据库的物理

确定数据库的物理

1、确定数据库的物理结构1）数据库物理设计的要求2）确定数据的存取方法3）确定数据的存储结构

第112页：数据库物理设计的要求

数据库物理设计的要求

• 通常对于关系数据库物理结构设计的内容主要包括：
  • 为关系模式选择存取方法；
  • 设计关系、索引等数据库文件的物理存储结构。

第113页：确定数据的存取方法

确定数据的存取方法

• 存取方法是快速存取数据库中数据的技术，许多关系型数据库管理系统都提供了多种存取方法。常用的方法有三类：①索引存取方法；②聚簇（Cluster）存取方法；③HASH方法。其中索引方法中的B+树索引方法是数据库中经典的存取方法。
• 具体采用哪种存取方法由系统根据数据的存储方式决定，一般用户不能干预。

第114页：确定数据的存储结构

确定数据的存储结构

• 确定数据库物理结构主要指确定数据的存放位置和存储结构，包括确定关系、索引、聚簇、日志和备份等的存储安排和存储结构；确定系统配置等。
• 确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，因此需要进行权衡，选择一个折中方案。

第115页：评价物理结构

评价物理结构

• 在确定了数据库的物理结构之后，还需进行评价，其评价重点是时间和空间的效率。
• 在实施数据库前，对这些方案进行细致的评价，以选择一个较优的方案作为数据库的物理结构。

第116页：数据库的实施

数据库的实施

• 设计人员使用具体的关系数据库管理系统提供的数据定义语言DDL和其他的实用程序将数据库逻辑结构设计和物理结构设计严格地描述出来，在计算机上建立起实际数据库结构，然后装入数据、进行测试和试运行，这就是数据库实施阶段的主要任务。

第117页：数据库的运行和维护

数据库的运行和维护

• 数据库试运行符合要求后，数据库就可以正式运行。
• 由于应用环境在不断的变化，数据库运行过程中物理存储也会不断的变化，因此对数据库设计进行评价、调整、修改等维护工作是一个长期的任务，也是设计工作的继续和提高。

第118页：思考题

思考题

1、什么

数据库设计？它有什么特点？

3、什么

数据字典？它包括哪些内容？

4、什么

数据流图？它有什么作用？