数据库原理第七章知识点

7.1数据库设计概述

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

• 信息管理要求：在数据库中存储和管理需要的数据对象。
• 数据处理要求：对数据对象需要进行的处理，如査询、增删改、统计和分析等

7.1.1数据库设计的特点

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

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

数据库建设的基本规律

将数据库结构设计和数据处理设计密切结合
传统的软件工程：重行为设计
早期的数据库设计：重结构设计

7.1.2数据库设计方法

• 手工设计法
• 规范设计法
• 基于ER模型的设计方法
• 3NF（第三范式）的设计方法
• ODL（Object Definition Language）方法
• UML（Unified Modeling Language）方法面向对象的建模方法

7.1.3数据库设计的基本步骤

1. 需求分析
2. 概念结构设计
3. 逻辑结构设计
4. 物理结构设计
5. 数据库实施
6. 数据库运行和维护

设计阶段	设计描述
需求分析	数字字典、全系统中数据项、数据结构、数据流、数据存储的描述
概念结构设计	概念模式（E-R图）
逻辑结构设计	某种数据模式
物理结构设计	存储安排、存取方法选择、存取路径建立
数据库实施	创建数据库模式、装入数据、数据库试运行
数据库运行和维护	性能监测、转储恢复、数据库軍组和重构

参与数据库设计人员：

• 系统分析人员和数据库设计人员
• 数据库管理员和用户代表
• 应用开发人员

7.1.4数据库设计过程中的各级模式

7.2需求分析

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

7.21需求分析的任务

• 充分了解原系统（手工系统或计算机系统）工作概况
• 详细调查要开发应用系统的组织/部门/企业等
• 明确用户的各种需求
  • 信息要求
  • 处理要求
  • 安全性与完整性要求

7.2.2数据字典

数据字典是关于数据库中数据的描述，称为元数据。它不是数据本身，而是数据的数据

数据字典的组成

• 数据项
• 数据结构
• 数据流
• 数据存储
• 处理过程

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

7.3概念结构设计

7.3.1概念模型

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

7.3.2E-R模型

实体之间的联系

• 一对一联系（1:1），例如班级与班长
• 对多联系（1:n），例如班级与学生
• 多对多联系（m:n），例如课程与学生

E-R图

• 实体型：用矩形表示，矩形框内写明实体名。
• 属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来。
  
• 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型

7.3.3概念结构设计

实体与属性的划分原则

• 作为属性，不能再具有需要描述的性质属性必须是不可分的数据项，不能包含其他属性
• 属性不能与其他实体具有联系ER图中所表示的联系是实体与实体之间的联系

ER图的集成

1. 合并。解决各分E-R图之间的冲突，将分E-R图合并，生成初步E-R图。
2. 修改和重构。消除不必要的冗余，生成基本E-R图。

合并E-R图时的三种冲突

• 属性冲突
  • 属性域冲突
  • 属性取值单位冲突。
• 命名冲突
  • 同名异义
  • 异名同义
  • 命名冲突
• 结构冲突
  • 同一对象在不同应用中具有不同的抽象
  • 同一实体在不同子系统的ER图中的属性个数和属性排列次序不完全相同
  • 实体间的联系在不同的ER图中为不同的类型。

消除不必要的冗余

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

用规范化理论来消除冗余:

1. 确定分E-R图实体之间的数据依赖。实体之间一对一、一对多、多对多的联系可以用实体码之间的函数依赖来表示。于是有函数依赖集FL
2. 求F的最小覆盖G，差集为D=FL-GL,逐一考察D中的函数依赖，确定是否是冗余的联系，若是，就把它去掉今

注意:

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

7.4逻辑结构设计

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

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

实体型的转换

一个实体型转换为一个关系模式

• 关系模式的属性：实体的属性
• 关系模式的码：实体的码

实体型间的1:1联系

• 要么转换为一个独立的关系模式
  • 关系模式的属性：与该联系相连的各实体的码以及联系本身的属性
  • 关系模式的属性：或者是该关系模式的属性中加入另一端关系模式的码和联系的属性
• 要么与相连的任意一端对应的关系模式合并
  • 关系模式的候选码：每个实体的码均是该关系模式的候选码
  • 关系模式的候选码：不变

实体型间的1：n联系

• 转换为一个独立的关系模式
  • 关系模式的属性：与该联系相连的各实体的码+联系本身的属性
  • 关系模式的码：n端的实体的码
• 与n端对应的关系模式合并
  • 合并后关系模式的属性：在n端关系模式中+1端关系的码+联系本身的属性
  • 合并后关系模式的码：不变
  • 可以减少系统模式中的关系个数，一般情况下更倾向于采用这种方法

实体型间的m:n联系

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

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

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

转换为一个关系模式

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

关系模式合并

具有相同码的关系模式可合并,减少系统中的关系个数
合并方法:

1. 将其中一个关系模式的全部属性加入到另一个关系模式中
2. 然后去掉其中的同义属性（可能同名也可能不同名）
3. 适当调整属性的次序

7.4.2数据模型的优化

关系数据模型的优化通常以规范化理论为指导
优化数据模型的方法:

1. 确定数据依赖,按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖。
2. 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系
3. 按照数据依赖的理论对关系模式进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式。
4. 按照需求分析阶段得到的各种应用对数据处理的要求，分析对于这样的应用环境这些模式是否合适，确定是否要对它们进行合并或分解包括水平分解和垂直分解。

7.4.3设计用户子模式

数据库模式——全局模式。
用户子模式——视图机制

1. 使用更符合用户习惯的别名
2. 针对不同级别的用户定义不同的视图，提高系统的安全性
3. 简化用户对系统的使用