数据库系统第七章 数据库设计

第七章 数据库设计

(一) 数据库设计概述

1. 数据库设计定义

  1. 数据库设计定义：

    • 数据库设计是指对于一个给定的应用环境
    • 构造（设计）优化的数据库逻辑模式和物理结构
    • 并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求
    • 包括信息管理要求和数据操作要求。

  2. 信息管理要求

    在数据库中应该存储和管理哪些数据对象。

  3. 数据操作要求

    对数据对象需要进行哪些操作，如查询、增、删、改、统计等操作。

  4. 数据库设计的目标

    为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。

  5. 高效率的运行环境

    1. 数据库数据的存取效率高；
    2. 数据库存储空间的利用率高；
    3. 数据库系统运行管理的效率高。

2. 数据库设计的特点

  1. 数据库建设的基本规律

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

    并不是说数据库设计好了就没事了，后续的管理以及数据收集也是关键

    管理：数据库建设项目管理和企业（应用部门）的业务管理。

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

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

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

    • 传统的软件工程：重行为设计。忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策。
    • 早期的数据库设计：重结构设计。致力于数据模型和数据库建模方法研究，忽视了行为设计对结构设计的影响。

image-20230207160743222

早期数据库设计和应用系统设计是分离的

3. 数据库设计知识和方法

大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。

(1) 需要的知识

它要求多方面的知识和技术。主要包括：

  • 计算机的基础知识；
  • 软件工程的原理和方法；
  • 程序设计的方法和技巧；
  • 数据库的基本知识；
  • 数据库设计技术；
  • 应用领域的知识。

(2) 设计的方法

1. 手工与经验结合的方法

存在的问题：

  1. 设计质量与设计人员的经验和水平有直接关系。
  2. 缺乏科学理论和工程方法的支持，工程的质量难以保证。
  3. 数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价。
2. 规范设计法

  1. 基本思想：过程迭代和逐步求精

    在使用数据的过程中一直迭代更新数据库

  2. 典型方法

    • 新奥尔良（New Orleans）方法
    • 基于E-R模型的数据库设计方法（设计概念模型的方法）
    • 3NF（第三范式）的设计方法（去除传递依赖）
    • 面向对象的数据库设计方法
    • 统一建模语言（UML）方法

4. 数据库设计的基本步骤

(1) 数据库设计分6个阶段

需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施、数据库运行和维护。

说明：

  • 需求分析和概念设计独立于任何数据库管理系统。
  • 逻辑设计和物理设计与选用的数据库管理系统密切相关。

image-20230207171148391

  • 数据模型优化返回的是设计逻辑结构
  • 实验性运行返回的是设计物理结构

(2) 参加数据库设计的人员

  1. 系统分析人员和数据库设计人员：自始至终参与数据库设计，其水平决定了数据库系 统的质量。

    系统分析人员：主要参与逻辑设计阶段

    数据库设计人员：主要参与物理设计阶段

    由上图可以看出，二者贯穿数据库设计始终，非常重要

  2. 数据库管理员和用户代表：要参加需求分析与数据库的运行和维护。

    数据库管理员：负责最终如何管理数据库

    用户代表：负责数据库最终要实现什么样的目的

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

(3) 各阶段的主要任务

  1. 需求分析阶段：了解用户需求，该阶段是否做得充分与准确，决定了构建数据库的速度和质量。
  2. 概念结构设计阶段：对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型（ER图）。
  3. 逻辑结构设计阶段：将概念结构转换为数据库管理系统所支持的数据模型，并对其进行优化。
  4. 物理结构设计阶段：逻辑数据结构选取一个最适合应用环境的物理结构，包括存储结构和存取方法。
  5. 数据库实施阶段：根据逻辑设计和物理设计的结果构建数据库，编写与调试应用程序，组织数据入库并进行试运行。
  6. 数据库运行和维护阶段：经过试运行之后即可投入正式运行，在运行过程中必须不断对其进行评估、调整与修改。

说明：

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

(4) 各个阶段的数据设计描述

image-20230207173102265

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

  2. 概念设计阶段：形成独立于机器特点，独立于各个数据库管理系统产品的概念模式（E-R图）。

  3. 逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式。

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

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

(5) 数据库设计过程中的各级模式

image-20230207173240446

(二) 需求分析

1. 需求分析的任务

  1. 详细调查现实世界要处理的对象（组织、部门、企业等）。
  2. 充分了解原系统（手工系统或计算机系统）工作概况。
  3. 明确用户的各种需求。
  4. 确定新系统的功能，新系统必须充分考虑今后可能的扩充和改变。

说明：
调查的重点是“数据”和“处理”，获得用户对数据库在信息、处理、安全性与完整性的要求。

2. 需求分析的方法

(1) 需求分析的目的

需求分析的目的：调查清楚用户的实际需求并进行初步分析，最终与用户达成共识。

(2) 调查用户需求的步骤

调查用户需求的步骤：

  1. 调查组织机构情况。
  2. 调查各部门的业务活动情况。
  3. 协助用户明确对新系统的各种要求，包括信息要求、处理要求、安全性与完整性要求。
  4. 确定新系统的边界。

(3) 常用的调查方法

  • 跟班作业。通过亲身参加业务工作了解业务活动的情况。
  • 开调查会。通过与用户座谈来了解业务活动情况及用户需求。
  • 请专人介绍。
  • 询问：对某些调查中的问题，可以找专人询问。
  • 设计调查表请用户填写。调查表设计合理，则很有效。
  • 查阅记录。查阅与原系统有关的数据记录。
  • 结构化分析方法（简称SA方法），SA方法从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统。

image-20230207175318422

最终确定系统边界就是要设计出数据字典

3. 数据字典

本节讲解数据库的组成部分，这几个组成部分是有逻辑联系的。

(1) 数据项

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

  • 数据项描述=

  • 说明：

    • “取值范围”、“与其他数据项的逻辑关系”定义了数据的完整性约束条件，是涉及数据检验功能的依据。

      取值范围是用户自定义约束

      与其他数据项的逻辑关系是参照性约束

    • 可以用关系规范化理论为指导，用数据依赖的概念分析和表示数据项之间的联系。

(2) 数据结构

  1. 数据结构：数据结构反映了数据之间的组合关系。
    数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
  2. 说明：
    • 一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成。

比如查成绩，要将学生的学号，姓名，成绩等做成一个数据结构一同传送

(3) 数据流

  1. 数据流：是数据结构在系统内传输的路径。
  2. 数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
  3. 说明：
    • 数据流来源：说明该数据流来自哪个过程。
    • 数据流去向：说明该数据流将到哪个过程去。
    • 平均流量：在单位时间（每天、每周、每月等）里的传输次数。
    • 高峰期流量：在高峰时期的数据流量。

(4) 数据存储

  1. 数据存储：数据结构停留或保存的地方，也是数据流的来源和去向之一。
  2. 数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
  3. 说明：
    • 存取频度：每小时、每天或每周存取次数，每次存取的数据量等信息。
    • 存取方法：批处理/联机处理；检索/更新；顺序检索/随机检索。
    • 输入的数据流：数据来源。
    • 输出的数据流：数据去向。

(5) 处理过程

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

    判定表第一列是判定的条件，第二列是满足条件后做什么事情

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

  3. 说明：

    • “简要说明”说明该处理过程的功能及处理要求。其中功能是指该处理过程用来做什么。处理要求是指处理频度要求，如单位时间里处理多少事务，多少数据量、响应时间要求等。

4. 需求分析小结

  1. 需求收集和分析作为数据库设计的第一阶段是十分重要的。
  2. 第一阶段收集的基础数据（用数据字典来表达）是下一步进行概念设计的基础。
  3. 强调两点：
    • 设计人员应充分考虑到可能的扩充和改变，使设计易于更改，系统易于扩充。
    • 必须强调用户的参与

(三) 概念结构设计

就是将实体抽象为ER图或者UML等概念模型

1. 概念模型

概念结构设计是将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程。
概念模型的特点：

  1. 能真实、充分地反映现实世界，是现实世界的一个真实模型。
  2. 易于理解，可以用它和不熟悉计算机的用户交换意见。
  3. 易于更改，当应用环境和应用要求改变时，容易对概念模型修改和扩充。
  4. 易于向关系、网状、层次等各种数据模型转换。
    概念模型的描述工具：E-R模型。

2. E-R模型

E-R模型是用E-R图来描述现实世界的概念模型，第一章已经讲过了，这里复习

(1) 实体之间的联系

实体型之间的联系都是概念模型的范畴

① 两个实体型之间的联系
a. 一对一联系（1:1）

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

比如说一个班只有一个班长，一个班长对应一个班

在这里插入图片描述

b. 一对多联系（1:n）

如果对于实体集A中的每一个实体，实体集B中有n个实体（n≥0）与之联系，反之，对于实体集B中的每一个实体，实体集A中至多只有一个实体与之联系，则称实体集A与实体集B有一对多联系，记为1:n

比如说一个班对应一班学生，多位学生对应一个班

在这里插入图片描述

c. 多对多联系（m:n）

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

比如说一个学生可以选修多门课，多门课可以供多名学生选修

在这里插入图片描述

image-20230207202927251

② 两个以上实体型之间的联系
a. 一对多联系（1:m||1:n）
  • 若实体集E1，E2，…，En存在联系，对于实体集Ej（j=1，2，…，i-1，i+1，…，n）中的给定实体，最多只和Ei中的一个实体相联系，则我们说Ei与E1E2，…，Ei-1，Ei+1，…，En之间的联系是一对多的。

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

image-20230116102606540

b. 一对一联系（1:1:1）
  • 一个独生子女只有一个父亲，一个母亲
  • 一个父亲也只有一个独生子女
  • 一个母亲也只有一个独生子女

image-20230116102635277

c. 多对多联系（m:n:p）

【例】有3个实体型:供应商、项目、零件，一个供应商可以供给多个项目多种零件，而每个项目可以使用多个供应商供应的零件，每种零件可由不同供应商供给,由此看出供应商、项目、零件
三者之间是多对多的联系。

image-20230116102740298

③ 单个实体型之间的联系
a. 一对多联系（1:n）

职工实体型内部具有领导与被领导的联系

  • 某一职工（干部）“领导”若干名职工
  • 一个职工仅被另外一个职工直接领导
    这是一对多的联系

image-20230116103300085

b. 一对一联系（1:1）
  • 身份证可以唯一确认一个人的身份，人与身份证有确认和被确认的关系
  • 一个身份证唯一确定一个人
  • 一个人也唯一确认一个身份证

image-20230116103349697

c. 多对多联系 （m:n）
  • 饮料和厂商之间有制造和被制造的关系
  • 多个饮料可以被多个厂商制造
  • 多个厂商可以制造出多种饮料

image-20230116103405946

(2) E-R图

这是用来表示概念模型的一种方式

  • E-R图也称实体-联系图(Entity Relationship Diagram)，提供了表示实体型、属性和联系的方法，用E-R图来描述现实世界的概念模型
  • E-R方法也称为E-R模型

ER图是用来描述概念模型的方式

① 表示方式

  • 实体型：用矩形表示，矩形框内写明实体名。

  • 属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。

  • 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1,1:n或m:n）。

    联系也可以具有属性。

【注意】如果一个联系具有属性，则这些属性也要用无向线该联系连接起来。

例子：如果用“供应量”来描述联系“供应”的属性，表示某
供应商供应了多少数量的零件给某个项目。那么这3个实休及其之间联系的E-R图如下。

image-20230116105810264

可以看到，联系也是有属性的

② 案例
a. 理清实体和属性

第一步要先搞明白有哪些实体以及这些实体之间的属性有哪些

用E-R图来表示某个工厂物资管理的概念模型。物资管理涉及的实体有:

  1. 仓库属性有仓库号、面积、电话号码;
  2. 零件属性有零件号、名称、规格、描述;
  3. 供应商属性有供应商号、姓名、申话号码、账号、
  4. 项目属性有项目号、预算、开工白期;
  5. 职工属性有职工号、姓名、年龄、职称。
b. 理清实体间的联系

这一步要搞明白实体之间的联系，联系的类型在上面已经讲过了，是两个实体型之间的练习，还是单个实体型之间的练习；一对一还是一对多等等。

并且要想好联系是否有属性

联系：

  1. 一个仓库可以存放多种零件，一种零件可以存放在多个仓库中，因此仓库和零件具有多对多的联系,用库存量来表示零件在某个仓库中的数量。
  2. 一个仓库有多个职工当仓库保管员，一个职个仓库工作,因此仓库和职工之间是一对多的联系。
  3. 职工之间具有领导-被领导关系。即仓库主任领导若管员,因此职工实体集中具有一对多的联系。
  4. 供应商、项目和零件三者之间具有多对多的联系。1个供应商可以供给若干项目多种零件，每个项目可以使用不同商供应的零件,每种零件可由不同供应商供给。
c. 实体的ER图

实体型E-R图

image-20230116111654315

d. 联系的ER图

实体和联系的ER图

image-20230116111705105

在画联系的ER图的时候，不需要写属性，否则会太乱。

可以看到联系也是有属性的

e. 完整的ER图

完整的ER图

image-20230116111719925

最终画出完整的ER图

3* 扩展的E-R模型

E-R模型得到了广泛的应用，人们在基本E-R模型的基础上进行了某些方面的扩展，使其表达能力更强。

(1) ISA联系

用E-R方法构建一个项目的模型时,经常会遇到某些实体型是某个实体型的子集

例如，研究生和本科生是学生的子类，学生是父类。这种父类-子类的联系称为ISA联系，表示“is a”的语义，如下图，研究生is a 学生，本科生 is a学生。

ISA联系用三角形来表示。

image-20230207213003855

说明：
ISA联系描述了一个实体型中实体的一种分类方法，其一个重要的性质是子类继承了父类的所有属性，同时子类也可有自己的属性。

分类属性

根据分类属性的值把父实体型中的实体分派到子实体中。

【例】下图中在ISA联系符号三角形的右边加一个分类属性“学生类别”，说明一个学生是研究生还是本科生由“学生类别”这个属性决定。

image-20230207213003855

不想交约束与可重叠约束
a. 不相交约束

不相交约束：父类中的一个实体不能同时属于多个子类中的实体集，即一个父类中的实体最多属于一个子类实体集。（比如学生，要么是本科生，要么是研究生，不能两个都是）

用ISA联系三角形符号内加一个“X”来表示。

b. 可重叠实体

可重叠约束：父类中的一个实体能同时属于多个子类中的实体集，三角形符号内没有“X”来表示。

完备性约束

完备性约束：描述父类中的一个实体是否必须是某一个子类中的实体。如果是，则为完全特化，否则为部分特化。

比如学生的子类是研究生和本科生，但是不一定，还可能是专科生没有画出来。

  1. 完全特化用双线连接，部分特化用单线连接。

image-20230207213324214

  1. 双线表示完全特化
  2. 三角形的×表示不相交约束

(2) 基数约束

  1. 基数约束：是对实体之间一对一、一对多和多对多联系的细化。约束用一对数min…max表示，0≤min≤max。

【例】0..1、1..3、1..*(*代表无穷大）。

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

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

image-20230207213622844

【例】学生和课程联系中，假设学生实体型的基数约束是20..30，课程的一个合理的基数约束是0..*。

image-20230207213658832

要搞清实体约束的位置与实体的对应关系：

  • 学生旁边的0...*是学生的数量，表示一个课程最少0个学生，最多无穷个学生
  • 课程旁边的20..30是课程的数量，表示一个学生选20-30门课程

【例】班级和学生联系中，一个学生必须参加一个班，并只能参加一个班，因此为1..1，一个班级最少30个学生，最多40个学生，因此是30..40。

image-20230207213850935

(3) Part-of联系

Part-of联系：即部分联系，表明某个实体型是另外一个实体型的一部分。

【例】汽车和轮子两个实体型，轮子是汽车的一部分，即Part-of汽车实体。

Part-of联系的分类：

非独占的Part-of联系
  • 非独占的Part-of联系：整体实体如果被破坏，部分实体仍然可以独立存在。非独占的Part-of联系可以通过基数约束来表达。

【例】汽车实体型和轮子实体型之间，汽车车体被毁坏了，轮子还存在，可以拆下来独立使用。具体如下图

image-20230207214234747

  1. 因为轮子的编号可以唯一标识轮子的
  2. 一个轮子有0-1辆车，这是非独占的意思
  3. 一辆车有且仅有4个轮子
独占的Part-of联系
  • 独占的Part-of联系：实体如果被破坏，部分实体不能存在。在E-R图中用弱实体类型和识别联系来表示独占联系。
  • 如果一个实体型的存在依赖于其他实体型的存在，则这个实体型叫做弱实体型，否则叫做强实体型。
  • 判断方法：如果不能从一个实体型属性中找出可以作为码的属性，这个实体型是弱实体型。
  • 在E-R图中用双矩形表示弱实体型，用双菱形表示识别联系。

【例】用户从银行贷款购房，这笔贷款一次贷出，分期归还。还款就是一个弱实体，因为它只有还款序号、日期和金额三个属性，第1笔还款的序号为1，第2笔还款的序号为2，以此类推，这些属性的组合都不能作为还款的码。还款的存在必须依赖于贷款实体。

image-20230207214505877

【例】房间和楼房的联系。每座楼都有唯一的编号或名称，每个房间都有编号，如果房间号不包含楼号，则房间号不能作为码，所以房间是个弱实体。

image-20230207214532216

房间实体和拥有联系都是双线

4* UML

UML是统一建模语言或标准建模语言，是始于1997年一个OMG标准，它是一个支持模型化和软件系统开发的图形化语言，为软件开发的所有阶段提供模型化和可视化支持，包括由需求分析到规格，到构造和配置。也可以作为表示E-R图的一种方法。
UML表示E-R图的说明：

  • 实体型：用类表示，矩形框上部写实体名，下面列出属性名。
  • 实体的码：在类图中属性后面加“PK”。
  • 联系：用类图之间的“关联”来表示。

【例】学生、课程它们之间的联系以及基数约束的E-R图用UML表示。

image-20230207214643866

5. 概念结构设计

概念设计的第一步就是对需求分析阶段收集到的数据进行分类、组织，确定实体、实体属性、实体间联系类型，形成E-R图。

前面已经初步学习如何做ER图，现在来讲ER图进行进一步处理

(1) 实体与属性的划分原则

本节主要讲解哪些项适合作为属性，哪些不适合，以及几个案例演示如何处理这些不适合作为属性的项

实体与属性的划分原则

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

两条准则：

  1. 作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。(这个是满足第一范式)
  2. 属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。

【例】职工是一个实体，职工号、姓名、年龄是职工的属性。

  • 职称如果没有与工资、福利挂钩，根据准则（1）可以作为职工实体的属性。
  • 如果不同的职称有不同的工资、住房标准和不同附加福利，则职称作为一个实体更恰当。

image-20230207223536186

【例】在医院中，一个病人只能住在一个病房

  • 病房号可以作为病人实体的一个属性
  • 如果病房还要与医生实体发生联系，即一个医生负责几个病房的病人的医疗工作，则根据准则（2）痕作为一个实体。

image-20230207223630918

【例】货物存在仓库中

  • 如果一种货物只存放在一个仓库，那么就可以把存放货勿的仓库的仓库号作为描述货物存放地点的属性。
  • 如果一种货物可以存放在多个仓库中，或者仓库本身又用面积作为属性,或者仓库与职工发生管理上的联系，那么就应把仓库作为一个实体。

image-20230207223753351

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

根据这个案例学习如何画ER图

该子系统的主要功能是:

  • 处理顾客和销售员送来的订单;
  • 工厂是根据订货安排生产的;
  • 交出货物同时开出发票;
  • 收到顾客付款后，根据发票存根和信贷情况进行应收款处理。

先设计E-R草图如下

image-20230207223903325

参照需求分析和数据字典中的详尽描述，遵循前面给出的两个准则，进行如下调整:

  1. 订单与订单细节两个实体之间是1: n的联系。每张订单由订单号、若干头信息和订单细节组成。订单细节又有订货的零件号、数量等来描述。按照准则(2），订单细节就不能作订单的属性处理而应该上升为实体。一张订单可以订若干产品。
  2. 原订单和产品的联系实际上是订单细节和产品的联系。每条订货细节对应一个产品描述，订单处理时从中获得当前单价、产品重量等信息。
  3. 增加一个“折扣规则”实体。工厂对大宗订货给予优惠。每种产品都规定了不同订货数量的折扣，应增加一个“折扣规则”实体存放这些信息，而不应把它们放在产品实体中。

最后得到销售管理子系统E-R图如下:

image-20230207224048591

对每个实体定义的属性如下:

  • 顾客:{顾客号,顾客名,地址,电话,信贷状况,账目余额}
  • 订单:{订单号,顾客号,订货项数,订货日期,交货日期,工种号,生产地点}
  • 订单细则:{订单号.细则号,零件号,订货数,金额}
  • 应收账款:{顾客号.订单号,发票号,应收金额,支付日期，支付金额,当前余额,货款限额}
  • 产品:{产品号,产品名,单价,重量}
  • 折扣规则:{产品号.订货量,折扣}

(2) E-R图的集成

前面生成了多个ER图，现在要将ER图集成到一个ER图中

E-R图的集成一般需要分两步：

  • 第一步：合并。解决各分E-R图之间的冲突，将分E-R图合并起来生产初步E-R图。
  • 第二步：修改和重构。消除不必要的冗余，生成基本E-R图。（要求ER图满足范式）

image-20230208102745557

可以看到，修改与重构要使用到规范化理论

合并E-R图，生成初步E-R图

  • 各个局部应用所面向的问题不同，各个子系统的E-R图之间必定会存在许多不一致的地方，称之为冲突。

  • 子系统E-R图之间的冲突主要有三类：

    • 属性冲突
    • 命名冲突
    • 结构冲突
a. 属性冲突

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

    例如零件号，有的部门把它定义为整数，有的部门把它定义为字符型。

    年龄，某些部门以出生日期形式表示职工的年龄，而另一些部门用整数表示职工的年龄。

  2. 属性取值单位冲突。

    例如，零件的重量有的以公斤为单位，有的以斤为单位，有的以克为单位。

b. 命名冲突

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

  2. 异名同义（一义多名），即同一意义的对象在不同的局部应用中具有不同的名字。

    如对科研项目，财务科称为项目，科研处称为课题，生产管理处称为工程。

  3. 命名冲突

    可能发生在实体、联系一级上

    也可能发生在属性一级上

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

c. 结构冲突
冲突 例子/说明 解决方法
同一对象在不同应用中具有不同的抽象 例如，职工在某一局部应用中被当作实体，而在另一局部应用中则被当作属性 把属性变换为实体或把实体变换为属性，使同一对象具有相同的抽象
同一实体在不同子系统的E-R图中所包含的属性个数和属性排列次序不完全相同 使该实体的属性取各子系统的E-R图中属性的并集，再适当调整属性的次序
实体间的联系在不同的E-R图中为不同的类型 实体E1与E2在一个E-R图中是多对多联系，在另一个E-R图中是一对多联系 解决方法是根据应用的语义对实体联系的类型进行综合或调整

看下面的例子

零件与产品之间存在多对多的联系“构成”。产品、零件与供应商三者之间还存在多对多的联系“供应”。

image-20230208103731206image-20230208103734903

然后合并两个图

image-20230208103744558

可以看到产品与零件之间加了一层关系

消除不必要的冗余，设计基本E-R图
举例
  • 所谓冗余的数据是指可由基本数据导出的数据，冗余的联系是指可由其他联系导出的联系。
  • 消除冗余主要采用分析方法，即以数据字典和数据流图为依据，根据数据字典中关于数据项之间逻辑关系的说明来消除冗余。
  • 消除冗余后的初步E-R图,称为基本E-R图。

举例如下

如图，Q3=Q1×Q2，Q4=∑Q5。

  • 所以Q3和Q4是冗余数据，可以消去。
  • 并且由于Q3消去，产品与材料间m:n的冗余联系也应消去。

image-20230208103909721

Q3和Q4扇区了

说明：

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

如果每次查询都要查询每个仓库中此种材料的库存，再求和，就使得查询效率低下。因此应保留Q4，同时把Q4=∑Q5定义为Q的完整性约束条件。每当Q,修改后，触发完整性检查。

用规范化理论来消除冗余
  1. 确定分E-R图实体之间的数据依赖。

实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。于是有函数依赖集FL。

就是将ER图中实体之间的联系转换为函数依赖

如图：

image-20230208104443044

  • 部门和职工之间一对多的联系可表示为 职工号→部门号
  • 职工和产品之间多对多的联系可表示为（职工号，产品号）→工作天数等。（多对多的联系，决定因素就多一些）
  1. 求FL的最小覆盖GL，差集为 D=FL-GL

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

由于规范化理论受到泛关系假设的限制，应注意下面两个问题：

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

我们来合成下面的图

  1. 工厂物资管理E-R图

image-20230208104651229

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

image-20230208104700426

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

image-20230208104707501

集成过程需要解决以下问题

  1. 异名同义，项目和产品含义相同。某个项目实质上是指某个产品的生产。统一用产品作实体名。
  2. 消除冗余联系：库存管理中职工与仓库的工作关系已包含在劳动人事管理的部门与职工之间的联系之中，所以可以取消。职工之间领导与被领导关系可由部门与职工（经理）之间的领导关系、部门与职工之间的从属关系两者导出，所以也可以取消。

最终的集成E-R图如下

image-20230208104757015

上面学习了如何画出E-R图，下面一节将E-R图转换为数据库中的一张表

(四) 逻辑结构设计

逻辑结构设计的任务：把概念结构设计阶段设计好的基本E-R图转换为与选用数据库管理系统产品所支持的数据模型相符合的逻辑结构。

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

E-R图由实体型、实体的属性和实体型之间的联系三个要素组成。E-R图向关系模型的转换就是将实体型、实体的属性和实体型之间的联系转化为关系模式。

(1) 转换原则

  • 一个实体型转换为一个关系模式。
  • 关系的属性为实体的属性
  • 关系的码为实体的码。

(2) 实体型之间联系的转换

1:1联系

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

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

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

比如说Sdept与Mname(系与系主任)，中间的联系是管理，属性是时间

那么得到的关系就是（Sdept，Mname，Time）

b. 与某一端实体对应的关系模式合并

合并后关系的属性：加入对应关系的码和联系本身的属性。
合并后关系的码：不变。

就是将Mname和Time合并到Sdept的关系中

这种方式可以减少关系的个数，多用这个

1:n联系

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

a. 转换为一个独立的关系模式
  • 关系的属性：与该联系相连的各实体的码及联系本身的属性。
  • 关系的候选码：n端实体的码。

比如Sdept与Sno的联系，联系的属性为人数

那么得到的关系为(Sdept, Sno, num)

b. 与n端对应的关系模式合并
  • 合并后关系的属性：在n端关系中加入1端关系的码和联系本身的属性。
  • 合并后关系的码：不变，还是n端的码
  • 不能加到1端

比如将Sno与num合并到Sdept中

该方法可以减少系统中的关系个数，一般情况下更倾向于采用这种方法。

m:n联系

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

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

[例]“选修”联系是一个m:n联系，可以将它转换为如下关系模式，其中学号与课程号为关系的组合码：

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

多个实体之间的联系

三个或三个以上实体间的一个多元联系转换为一个关系模式。

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

image-20230208103734903

比如这个，最终的关系就是

（产品的码，供应商的码，零件的码，数量）

合并具有相同码的关系模式

具有相同码的关系模式可合并。

  • 目的：减少系统中的关系个数。
  • 合并方法：
    • 第一步：将其中一个关系模式的全部属性加入到另一个关系模式中。
    • 第二步：去掉其中的同义属性（可能同名也可能不同名）。
    • 第三步：适当调整属性的次序。
举例

将下面E-R图转换为关系模型。关系的码用下横线标出。

image-20230208140947567

  1. 先找到所有的实体
  • 部门（部门号，部门名，…）
  • 职工（职工号、职工名，职务，…）
  • 产品（产品号，产品名…）
  • 供应商（供应商号，姓名，…）
  • 零件（零件号，零件名，…）
  1. 分析每一个零件，按照上面的处理方式处理

  • 部门和职工是1:1的领导关系，可以合并

    部门（部门号，部门名，经理的职工号，…）

  • 部门和职工有1:n的属于关系，合并到n端职工

    职工（职工号、部门号，职工名，职务，…）

  • 职工和产品是1:1的负责关系，合并到产品

    产品（产品号，产品名，产品组长的职工号，…）

  • 职工和产品是n:m的参加关系，独立一个联系

    职工工作（职工号，产品号，工作天数，…）

  • 供应是三者之间的关系，独立为一个关系

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

最终的成果如下：

  • 部门（部门号，部门名，经理的职工号，…）
  • 职工（职工号、部门号，职工名，职务，…）
  • 产品（产品号，产品名，产品组长的职工号，…）
  • 职工工作（职工号，产品号，工作天数，…）
  • 供应（产品号，供应商号，零件号，供应量）
  • 零件（零件号，零件名，…）
  • 供应商（供应商号，姓名，…）

2. 数据模型的优化

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

优化数据模型的方法

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

  2. 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系。（得到DL）

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

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

    说明：并不是规范化程度越高的关系就越优。
    例如当查询经常涉及两个或多个关系模式的属性时，系统就必须经常性地进行连接运算，代价相当高，因此在这种情况下，第二范式甚至第一范式也许是适合的。

  5. 对关系模式进行必要分解，提高数据操作效率和存储空间的利用率。

    常用分解方法有水平分解和垂直分解。

分解关系模式
a. 水平分解
  • 水平分解：把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系。
  • 分解方法：
    • 一是对符合80/20(之前提到过的)的，把经常使用的数据（约20%）水平分解出来，形成一个子关系。
    • 二是每个事务存取的数据对应一个子关系。

总之就是将经常查询的给提取出来

比如将学生分成本科生与毕业生，这样查询本科生或者毕业生就不必再筛选了

b. 垂直分解
  • 垂直分解：把关系模式R的属性分解为若干子集合，形成若干子关系模式。
  • 分解原则：经常在一起使用的属性从R中分解出来形成一个子关系模式。或者根据范式的要求分解
  • 分解优点：可以提高某些事务的效率。
  • 分解缺点：可能使另一些事务不得不执行连接操作，降低了效率。
  • 适用范围：取决于分解后R上的所有事务的总效率是否得到了提高。
  • 分解方法：
    • 简单情况直观分解。
    • 复杂情况用第6章中的模式分解算法。
    • 垂直分解必须不损失关系模式的语义（保持无损连接性和保持函数依赖）。

3. 设计用户子模式

  • 定义数据库模式主要是从系统的时间效率、空间效率、易维护等角度出发。

    定义用户外模式时应该更注重考虑用户的习惯与方便

    包括三个方面：

    • 使用更符合用户习惯的别名
      合并各分E-R图曾做了消除命名冲突的工作，以使数据库系统中同一关系和属性具有唯一的名字。

      用视图机制可以在设计用户视图时可以重新定义某些属性名，使其与用户习惯一致，方便使用。

    • 针对不同级别的用户定义不同的视图，以保证系统的安全性。

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

(五) 物理结构设计

1. 概述

(1) 什么是数据库的物理设计

  • 数据库在物理设备上的存储结构(顺序/链式)与存取方法(遍历/索引/树)称为数据库的物理结构，它依赖于选定的数据库管理系统。
  • 为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计。

(2) 数据库物理设计的步骤

  1. 确定数据库的物理结构

    在关系数据库中主要指存取方法和存储结构。

  2. 对物理结构进行评价
    评价的重点是时间和空间效率。

    若评价结果满足原设计要求，则可进入到物理实施阶段

    否则，就要重新设计或修改物理结构，有时甚至要返回逻辑设计阶段修改数据模型。

2. 数据库物理设计的内容和方法

(1) 设计物理数据库结构的准备工作

  1. 充分了解应用环境，详细分析要运行的事务，以获得选择物理数据库设计所需参数。
  2. 充分了解所用关系型数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构。

(2) 选择物理数据库设计所需参数

  1. 对于数据库查询事务，需要得到以下信息：
    • 查询的关系。
    • 查询条件所涉及的属性。
    • 连接条件所涉及的属性。
    • 查询的投影属性。
  2. 对于数据更新事务，需要得到以下信息：
    • 被更新的关系。
    • 每个关系上的更新操作条件所涉及的属性。
    • 修改操作要改变的属性值。(经常要修改的属性不适合作为索引)
  3. 每个事务在各关系上运行的频率和性能要求。

(3) 关系数据库物理设计的内容

  • 为关系模式选择存取方法（建立存取路径）
  • 设计关系、索引等数据库文件的物理存储结构。

3. 存取方法选择

  • 数据库系统是多用户共享的系统，对同一个关系要建立多条件存取路径才能满足多用户的多种应用要求。
  • 物理结构设计的任务之一是根据关系数据库管理系统支持的存取方法确定选择哪些存取方法。
  • 数据库管理系统常用存取方法：
    • B+树索引存取方法。
    • Hash索引存取方法。
    • 聚簇存取方法。

(1) B+树索引存取方法

选择索引存取方法实际上就是根据应用要求确定对哪些属性列建立索引、对哪些属性列建立组合索引、对哪些索引要设计为唯一索引等。

说明：

  1. B+树索引仅仅是记录元组的存储位置，不改变空间，因此可以建立多个索引
  2. 可以为一个属性组建立一个索引，比如(Sno, Cno, Grade)，可以为(Sno, Cno)这个属性组建立索引
  3. 唯一索引：这个属性是unique的，当然可以建立不唯一的索引

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

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

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

    因为索引已经给排好序了，所以最大值和最小值很好找，不用再遍历了

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

(2) Hash存取方法

选择Hash存取方法的规则：如果一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一：

  • 该关系的大小可预知，而且不变。
  • 该关系的大小动态改变，但所选用的数据库管理系统提供了动态Hash存取方法。

了解即可，实际使用效率高于B+树

(3) 聚簇存取方法的选择

聚簇是为了提高谋而属性（或属性组）的查询速度，把这个或这些属性（称为聚簇码）上具有相同值的元组集中存放在连续的物理块中称为聚簇。

比如将dept = "CS"的都放在C盘，将dept = "Ma"的都放在D盘，这样根据dept查找的时候只需要查找一次就可以将全部符合条件的查找出来

说明：

  1. 聚簇对于某些类型的查询，可以提高查询效率。

  2. 在一个基本表上最多只能建立一个聚簇索引。

    因为要根据建立聚簇索引的属性建立连接条件，因此只能建立一个聚簇索引

  3. 聚簇索引的适用条件，一是很少对基表进行增删操作，二是很少对其中的变长列进行修改操作。

    进行增删操作会改变记录的顺序，比如删除一条记录会前移后面的记录

    变长列(比如varchar)会改变记录的长度，同样会改变后面记录的位置

选择聚簇存取方法：

  1. 设计候选聚簇

    1. 常在一起进行连接操作的关系可以建立组合聚簇。
    2. 如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇。
    3. 如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。

  2. 检查候选聚簇中的关系，取消其中不必要的关系

    1. 从聚簇中删除经常进行全表扫描的关系。

    2. 从聚簇中删除更新操作远多于连接操作的关系。

      删除操作会改变物理顺序

    3. 从聚簇中删除重复出现的关系（比如一个表中有多个候选聚簇）。当一个关系同时加入多个聚簇时，必须从这多个聚簇方案（包括不建立聚簇）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小。

4. 存储结构选择

  • 确定数据库物理结构主要指确定数据的存放位置和存储结构，包括：确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等。
  • 确定数据的存放位置和存储结构要综合考虑存取时间（顺序存储存取比较快）、存储空间利用率（链式存储使用率比较高）和维护代价3个方面的因素。

(1) 确定数据的存放位置

根据应用情况将

  • 易变部分与稳定部分分开存放
  • 经常存取部分与存取频率较低部分分开存放。

[例]

  • 可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。

这里包括垂直分解和水平分解

  • 垂直分解：将常用的属性分开，比如学生表中有成绩与其他基本属性，学生经常查询成绩，可以将成绩分到一块，老师经常查询基本信息，基本信息分到一块
  • 水平分解：比如本科生与研究生分到一块
  • 可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。

日志文件是系统文件，数据库对象是用户文件，分开放

(2) 确定系统配置

  • 数据库管理系统一般都提供了一些系统配置变量和存储 分配参数，初始情况下，系统都为这些变量赋予了合理的缺省值（默认值），在进行物理设计时需要根据应用环境确定这些参数值，使系统性能最优。
  • 系统配置变量很多，例如：同时使用数据库的用户数、同时打开的数据库对象数、内存分配参数、缓冲区分配参数（使用的缓冲区长度、个数）、存储分配参数、物理块的大小、物理块装填因子、时间片大小、数据库的大小、锁的数目等。

这些都是配置量

5. 评价物理结构

  • 对数据库物理设计过程中产生的多种方案进行评价，从中选择一个较优的方案作为数据库的物理结构。
  • 评价方法主要是定量估算各种方案的存储空间、存取时间、维护代价，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。

(六) 数据库的实施和维护

1. 数据的载入和应用程序的调试

(1) 数据的载入

  • 数据库结构建立好后，就可以向数据库中装载数据了。组织数据入库是数据库实施阶段最主要的工作。
  • 数据装载方法：人工方法（比如将纸上的数据人工载入到数据库中）、计算机辅助数据入库。

(2) 应用程序的调试

数据库应用程序的设计应该与数据设计并行进行，在组织数据入库的同时还要调试应用程序。

2. 数据库的试运行

  • 应用程序调试完成，并且已有一小部分数据入库后，就可以开始对数据库系统进行联合测试，也称数据库的试运行。
  • 主要工作包括：
    • 功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
    • 性能测试：测量系统的性能指标，分析是否符合设计目标。
  • 说明：
    • 数据的分期入库(一次全部存入可能出问题)。
    • 做好数据库的转储和恢复。

3. 数据库的运行和维护

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

(1) 数据库的转储和恢复

数据库管理员要针对不同的应用要求制定不同的转储计划，一旦发生介质故障，尽快将数据库恢复到某种一致性状态。

(2) 数据库的安全性、完整性机制

当应用环境发生变化，对安全性的要求也会发生变化，数据库管理员需要根据实际情况修改原有的安全性控制，同样数据库的完整性约束条件也会变化。

(3) 数据库性能的监督、分析和改进

在数据库运行过程中，数据库管理员必须监督系统运行，对检测数据进行分析，找出改进系统性能的方法。

(4) 数据库的重组织与重构造

数据库的重组织
  • 数据库运行一段时间后，由于记录的不断增、删、改，会使数据库的物理存储变坏，从而降低数据库存储空间的利用率和数据的存取效率，使数据库的性能下降。
  • 数据库的重组织不会改变原设计的数据逻辑结构和物理结构。
  • 重组织的方法：按原设计要求重新安排存储位置、回收垃圾、减少指针链。

仅仅是删除垃圾信息

数据库的重构造
  • 数据库应用环境发生变化，会导致实体及实体间的联系也发生相应的变化，使原有的数据库设计不能很好地满足新的需求。
  • 数据库的重构造需根据新环境调整数据库的模式和内模式。
  • 重构造的方法：增加或删除某些数据项、改变数据项的类型、增加或删除某个表、改变数据库的容量、增加或删除某些索引等。
  • 若应用变化太大，已无法通过重构数据库来满足新的需求，或重构数据库的代价太大，则表明现有数据库应用系统的生命周期已经结束，应该重新设计新的数据库应用系统了。

重构造是要更改结构

(七) 小结

  1. 数据库设计的方法和步骤

  2. 数据库设计6个阶段

    重点是概念结构设计（ER图）和逻辑结构的设计（实际数据表）。

  3. 概念结构设计

    概念结构的设计着重介绍了E-R模型的基本概念和图示方法。应重点掌握实体型、属性和联系的概念，理解实体型之间的一对一、一对多和多对多联系。掌握E-R模型的设计以及把E-R模型转换为关系模型的方法。

  4. 逻辑结构的设计

    将概念结构转化为具体的数据模型。

posted @ 2023-10-07 17:57  Crispy·Candy  阅读(450)  评论(0)  编辑  收藏  举报