计算机三级数据库技术笔记

第一章 数据库应用系统开发方法

1.1 数据库应用系统生命周期

1.1.1 软件工程与软件开发方法

• 瀑布模型
• 快速原型模型
• 螺旋模型

1.1.2 DBAS生命周期模型

• 项目规划
• 需求分析
• 系统设计
• 实施与部署
• 运行与维护

1.2 规划与分析

1.2.1 系统规划与定义

1. 任务陈述
2. 确定任务目标
3. 确定系统范围和边界
4. 确定用户视图

1.2.2 可行性分析

1. 经济可行性
2. 技术可行性
3. 操作可行性
4. 开发方案选择

1.2.3 项目规划

1.3 需求分析

DBAS需求分析规范说明书

1.3.1 数据需求分析

数据字典包括数据项、数据结构、数据流、数据存储和处理过程五部分

1.3.2 功能需求分析

1.数据处理需求分析

分析结果可表示为数据流图（DFD）或DBAS应支持的各种数据处理事务规范
事务规范包括：

• 事务名称
• 事务描述。功能、性能、完整性约束等方面的描述
• 事务所访问的数据项
• 事务用户。启动或执行该事务的事件或用户

数据需求分析与数据处理需求分析的结果组织在一起，可以构成数据字典文档，该文档也被成为数据规范说明书

2.业务规则需求分析

应用领域业务规则描述了应用领域中的业务功能、处理流程和步骤

1.3.3 性能需求分析

性能指标包括：

• 数据响应时间
• 系统吞吐量
• 允许并发访问的最大用户数
• 每TPS代价值

影响DBAS性能的主要因素有：

• 系统硬件资源
• 网络通信设备性能
• 操作系统环境
• 数据库逻辑设计和物理设计质量
• DBMS的配置与性能
• 数据库应用程序自身

1.3.4 其他需求分析

1. 存储需求分析

• 初始数据库大小
• 数据库增长速度

2. 安全性需求分析

• DBAS系统应达到的安全控制级别
• 各类用户数据的数据视图和视图访问权限

3.备份和恢复需求分析

• 备份数据库的时间和备份周期
• 备份全部数据还是其中一部分
• 备份方式是采用完全备份还是差异备份

1.4 系统设计

1.4.1概念设计

概念设计包括数据库概念模型设计和系统总体设计

1.数据库概念模型设计

2. 系统总体设计

• DBAS体系结构设计
• 系统硬件平台的选型和配置
• 应用软件结构设计
• 业务规则初步设计
• 对系统关键技术进行方案选型和初步设计

1.4.2逻辑设计

1.数据库逻辑结构设计

2.应用程序概要设计

3.数据库事务概要设计

1.4.3 物理设计

1.数据库物理结构设计

2.数据库事务详细设计

3.应用程序详细设计

第二章 需求分析

2.1 需求分析

2.1.1 需求分析的概念与意义

需求分析就是对待开发的系统要做什么，完成什么功能的全面描述。
软件产品的下列特性使得需求获取困难重重：

• 软件功能复杂
• 需求的可变性
• 软件产品的不可见性

一个计算机应用信息系统的需求分析工作是在系统分析人员与用户不断交互的过程中完成的。

2.1.2 需求获取的方法

1. 面谈
2. 实地观察
3. 问卷调查
4. 查阅资料

2.1.3 需求分析过程

1. 标识问题
2. 建立需求模型
3. 描述需求
   • 需求概述
   • 功能需求
   • 信息需求
   • 性能需求
   • 环境要求
   • 其他需求
4. 确认需求
   需求确认与评审以下项目：
   • 功能需求
   • 数据需求
   • 性能
   • 数据管理
   • 其他需求

2.2 需求分析方法

2.2.1 需求分析方法概述

结构化分析与功能建模方法有DFD和IDEF0等
基本特征是抽象和分解
优点：

• 不过早陷入具体细节
• 从整体或宏观入手分析问题
• 通过图形化模型对象直观地表示系统要做什么，完成什么功能
• 图形化建模方法方便分析员理解和描述系统
• 模型对象不涉及太多属术语，便于用户理解术语

2.1.2 DFD需求建模方法

DFD建模方法，也被称为过程建模和功能建模方法
核心是数据流

1. DFD方法的基本元素

• 数据流：用一个箭头表示数据的流向
• 处理：表示对数据进行的加工或变换，以矩形框表示
• 数据存储：表示数据库形式（文件形式）存储的数据
• 外部项（又称数据源或数据终点）：以圆角框或平行四边形表示

2. DFD图

自顶向下，逐步细化

3. DFD建模过程

1. 明确目标，确定系统范围
2. 建立顶层DFD
3. 构建第一层DFD
4. 开发DFD层次结构图
   • 保持均匀的模型深度
   • 按困难程度进行选择
   • 如果一个处理难以确切命名可以对它重新分解
5. 检查确认DFD图
   • 父图中描述过的数据流必须在相应的子图中出现
   • 一个处理至少有一个输入流和一个输出流
   • 一个存储必定有流入的数据流和流出的数据流
   • 一个数据流至少有一端是处理框
   • 模型图中至少有一端是处理框

2.2.3 其他需求建模方法

1. IDEF0方法简介

基本元素矩形框和箭头
矩形框代表功能活动，写在矩形框中的短语描述功能活动的名称，活动的编号按照要求写在矩形框右下角指定位置

• 左侧输入箭头表示活动需要的数据
• 矩形框上方控制箭头描述了影响这个活动执行的事件或约束条件
• 右边输出箭头说明由活动产生的结果和信息
• 下方的进入的机制箭头表示实施该活动的物理手段或完成活动需要的资源（计算机系统、人或组织）
  
  输入和控制两者区别：
• 输入强调被活动消耗或变换的内容
• 控制强调对活动的约束条件

2. UML用例模型简介

面向对象建模

2.2.4 DFD和IDEF0比较

• IDEF0不是强调流或顺序，而是强调数据约束
• IDEF0中箭头语义更丰富，不仅表示数据流还表示如何影响矩形所表示的活动
• 模型组成元素不同。IDEF0图中箭头从哪里来到哪里去可在专门文档说明，不必表示在图中

第三章 数据库结构设计

3.1 数据库概念设计

3.1.1 概念设计的任务

1. 定义和描述应用领域涉及到是数据范围
2. 获取应用领域或问题域的信息模型
3. 描述清楚数据之间的关系
4. 定义和描述数据的约束
5. 说明数据安全性要求
6. 支持用户的各种数据处理需求
7. 保证信息模型方便地转换为数据库的逻辑结构

3.1.2 概念设计的依据及过程

1.概念设计的依据

依据：需求说明书、功能模型、在需求分析阶段收集到的应用领域或问题域的各类报表
构造：信息模型，数据库概念设计说明书

2.概念设计的过程

1. 明确建模目标
2. 定义实体集：分类标识、概括命名
3. 定义联系
4. 建立信息模型
5. 确定实体集属性
6. 对信息模型进行集成和优化

3.1.3 数据建模方法

1.ER建模方法

• 实体或实例：指客观存在并且可以相互区分的事物
• 实体集：表示一个现实的和抽象事物的集合，这些事物具有相同的属性
• 属性：用于描述一个实体集的性质和特征，每个属性的取值范围称为域
• 码：实体集中唯一标识每一个实例的属性或属性组称为实体集的码
• 联系：描述现实世界事物的联系
  • 一对一联系
  • 一对多联系
  • 多对多联系

符号：

• 矩形框标识实体集
• 菱形框标识联系
• 椭圆或圆角矩形框表示属性

2. IDEF1X建模方法

建模元素：

• 实体集
  • 独立实体集：每个实例都能被唯一地标识而不决定于它与其他实体集的联系，矩形框表示
  • 从属实体集：实体集的一个实例的唯一标识依赖于实体集与实体集的联系，用圆角矩形框表示
    
• 联系
  • 标定型联系：在确定型连接联系中，如果子女实体集中的每个实例都是由它与双亲 的联系而确定的。
  • 非标定型联系：在确定型连接联系中，子女实体集中每一个实例都能被唯一地确认而无需了解与之相联系的双亲实体集的实例
  • 分类联系：是两个或多个实体集之间的联系，且在这些实体集中存在一个一般实体集，它的每一个实例都恰好与一个且仅一个分类实体集的一个实例相联系。
  • 非确定关系：多对多

3.2 数据库逻辑设计

3.2.1 概述

数据库逻辑设计的任务是把数据库概念设计的结果（ER模型），转换为具体的数据库管理系统支持的数据模型

3.3.2 逻辑设计实例

规则：

1. 一个实体型转化为一个关系模式，实体的属性就是关系的属性，实体的码就是关系的码
2. 一个m:n的联系转化为一个关系模式。关系的属性是与该联系相连的各实体的键以及联系本身的属性；关系的键是各实体键的组合。“选修”联系是一个m:n的联系，可以将它转化为如下关系模式：选修（学号,课程号，成绩）
3. 一个1:n的联系可以转化为一个独立关系模式，或者与n端对应的关系模式合并
   1. 转化为独立的关系模式：关系的属性为与联系相连的各实体的键以及联系本身的属性；关系的键为n端实体的键
   2. 与n端对应的关系模式合并：合并后关系的属性为在n端关系中加上1端关系的键以及联系本身的属性；合并后关系的键不变。这种方法可以减少系统中关系的个数，一般情况下倾向于采用这种方法
4. 一个1:1的联系可以转化为一个独立的关系模式，也可与任一端的关系模式合并
   • 转化为一个独立的关系模式。关系的属性为与该关系相连的各实体的键以及联系本身的属性。每个实体的键是这个关系的候选码
   • 与某一段对应的关系合并。合并后关系的属性，加入对应关系的键和联系本身的属性，合并后的键不变
5. 三个或三个以上实体之间的一个多元联系转化为一个关系模式。关系属性为该多元联系相连的各个实体的键以及该联系本身的属性。关系的键是各个实体键的组合。例如“讲授”是一个三元联系，讲授（教工号，课程号，书号）
6. 同一实体集的实体间的联系，即自联系也可按照上述1:1,1:n,m:n三种情况分别处理处理。教师实体集内部存在领导与被领导的1:n的自联系，可以将该联系与教师实体合并，这时主键职工号将多次出现，可以用不同的属性名加以区分，教师：{职工号，姓名，性别，职称，系主任）
7. 具有相同键的关系模式可以合并。目的是减少系统中关系的个数。合并方法，将其中一个关系模式的所有属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），并适当调整属性的次序

3.3 数据库物理设计

3.3.1 物理设计概述

通常数据库物理设计并不包括文件和数据库具体的实现细节
需要了解不同文件组织方式、索引技术及其使用方法

3.3.2 数据库的物理结构

3.3.3 索引

1. 索引技术

索引技术的关键是建立记录域取值到记录的物理地址间的映射关系，这种映射关系被称为索引
在设计和创建索引时，应确保对性能的提高程度大于在存储空间和处理资源方面的代价

2.索引技术分类

1. 有序索引技术
   也被称为索引文件机制。利用索引文件实现记录域取值到记录物理地址之间的映射关系。记录域就是查找码，查找码也称排序域。
2. 散列技术
   也称哈希索引机制。散列技术利用一个散列函数实现记录域取值到记录物理地址间的直接映射关系。这里记录域就是查找码，也称散列函数的排序域或散列域

在一个文件中查找某个或某些特定文件记录时，需要给出记录应满足的查询条件。这种查询条件形如“文件记录在它的某个或某些记录域/属性上的取值满足…条件”。这些用于数据文件中查找记录的属性或属性集合就是文件查找码。对于存储有关系表数据的数据库文件，该文件的查找码可以是关系表的主码或候选码，也可以是关系表的其他非主属性。

3. 有序索引

数据库中的数据文件经常采用顺序文件结构，文件的数据记录按照某个特定的查找码值的升序或降序顺序地储存在文件中。
索引文件建立的方法：首先选定数据文件中的某个或某些记录域作为查找码，然后建立起数据记录在查找码上的取值与该记录物理地址间的映射关系，组成索引项。所有索引项作为索引记录存储在索引文件中。索引文件根据某个特定的查找码值的升序或降序存储索引记录，并且也组织为顺序文件。
一个数据文件可以有多个查找码和多个索引文件

几类主要的有序索引及其特点：

• 聚集索引和非聚集索引
  • 聚集索引：数据文件中国数据记录的排列顺序与索引文件中索引项的排列顺序一致，或者说索引文件中按照其查找码指定的顺序与数据文件中数据文件的排列顺序相一致。
  • 非聚集索引：数据文件中数据记录的排列顺序与索引文件中的索引项的排序不一致。
• 稠密索引与稀疏索引
  • 稠密索引：数据文件中每个查找码在索引文件中都对应一个索引记录
  • 稀疏索引：只是一部分查找码的值有对应的索引记录
• 主索引与辅索引
  • 主索引：在数据文件的主码属性值上建立的索引
  • 辅索引：在数据文件的非主属性上建立的索引
• 唯一索引：可以确保索引列不包含重复的值。在多列唯一索引的情况下，可确保每个值的组合是唯一的。例如在last_name,first_name,middle_initial列的组合上创建了唯一索引full_name，则该表中任何两个人都不可以具有相同的全名。
• 单层索引和多层索引
  当数据文件很大时，即使采用稀疏索引，建立的索引文件也会很大。可以对索引项本身再建立起一级稀疏索引，组成二层索引结构
  多层索引的典型例子是B数和B+树索引

3.3.4 数据库物理设计

1. 物理设计内容

1. 数据库逻辑模式描述
2. 文件组织与存取设计
3. 数据分布设计
4. 确定系统配置
5. 物理模式评估

2. 数据库逻辑模式描述

1. 面向目标数据库描述基本表和视图
2. 设计基本表业务规范

3.DB文件组织与存取设计

1. 使用事务-基本表交叉引用矩阵

基本表1

基本表2

基本表3

I

R

U

D

I

R

U

D

I

R

U

D

事务1

*

*

*

*

*

事务2

*

*

*

*

*

事务3

*

*

*

*

事务4

*

*

*

*

*

注： I-插入 R-读取 U-更新 D-删除

2. 估计各事务的执行频率，即单位时间内事务的执行次数
3. 对于每张基本表，汇总所有作用于该表上的各事务的操作频率信息，得到如下数据访问估计信息：该表是否被频繁访问，该表中哪些属性列的访问频率较高和作用于这些属性上的操作类型和查询条件类型（等值查询，范围查询）

---

基本表选择合适的文件结构的原则：

1. 如果数据库中的一个基本表中的数据量很少，并且插入、删除、更新等操作很频繁，该基本表可以采用堆文件组织方式。堆文件无需建立索引，维护代价非常低，向表中加载数据访问效率较低，但在数据量较少时，定位文件记录的时间非常短。
   当需要向新创建的基本表批量加载数据时，可将表的文件结构优先选为堆文件，向表中加载数据后重新调整文件结构，如改为数据查询效率更高的B+树文件。
2. 顺序文件支持基于查找码的顺序访问，也支持快速的二分查找。如果用户的查询条件定义在查找码上，则顺序文件是比较合适的文件结构
3. 如果用户查询是基于散列域值的等值匹配，特别是如果访问顺序是随机的，则散列文件比较合适，但散列文件组织不适合下列情况：
   • 基于散列域值的非精确查询（模糊查询，范围查询）
   • 基于非散列域的查询
4. B树和B+树文件是实际数据库系统中非常广泛的索引文件结构，适合于定义在大数据量基本表上、基于查找码的等值查询、范围从查询、模糊查询和部分查询。B树和B+树属于动态索引，可以随着数据文件的内容变化不断调整，保证数据查询的性能不会恶化。
5. 如某些频繁执行且需要进行多表连接的操作的查询，可以考虑将这些基本表组织为聚集文件，以改善查询效率。

---

可以根据以下原则决定是否为一个基本表建立索引：

1. 对于经常需要进行查询、连接、统计操作的，且数据量较大的可以考虑建立索引；而对于经常进行插入、删除、更新操作或小数据量的基本表应尽量避免建立索引 。
2. 一个表上除了可以建立一个聚集索引外还可以建立多个非聚集索引。多个索引为用户提供了多个查找码快速访问文件的手段。但是索引越多，对表内数据更新时维护索引所需要的开销就越大。因此对于一个更新频繁的表应该不建或减少索引。
3. 索引可以由用户根据需要随时创建或删除，以提高数据查询性能。

---

对于基本表可以考虑在下面属性上建立索引：

1. 表的主码（大部分关系型数据库会自动会为主码建立唯一索引）
2. 在where查询子句中引用率较高的属性
3. 参与连接操作的属性
4. 在Order by子句、group by子句中出现过的属性
5. 在某一范围内频繁搜索的属性，但只有当使用索引查询其结果不超过记录总数20%时索引才有明显效果
6. 如果where子句中同时包含一个表的多个属性，则可以考虑为这些属性建立多属性索引；如果数据库文件需要频繁执行精确匹配查询（等值查询），则可以考虑建立散列索引，而B+树等有序索引更适合于范查询
7. 当一个属性有较多的不同值时，使用索引有明显的作用；当一个属性的不同值很少时，使用索引没有好处
8. 对于包含大量空值的属性建立索引要仔细考虑，因为很多数据库管理系统中的索引不引用具有空值的行，对空值的查找要使用全表扫描来实现

4. 数据分布设计

（1）不同类型数据的物理分布

数据库备份数据、日志文件备份数据用于故障恢复，使用频率低且数据量大，可以存储在磁带中。而应用数据、索引和日志使用频繁，要求响应时间短，必须放在支持直接存取的磁盘存储介质上

（2）应用数据的划分与分布

对基本表的划分可以依据下面不同原则

• 根据数据使用特征分：例如，如果一个基本表中有部分数据被频繁查询，并且要求查询响应速度快，则可以将基本表分为频繁使用分区和非频繁使用分区，分别存储在不同磁盘上。对频繁使用分区中数据可以建立B+树等多层索引，以提高数据访问速度；对非频繁使用分区中的数据可以不建或只建立单层索引
• 根据时间、地点划分
• 分布式数据库系统（DDBS）中的数据划分。采用水平划分和垂直划分。数据划分和分布的原则是数据应靠近其使用者，以降低查询过程中的数据传输代价，提高数据访问响应速度，并且通过副本冗余机制提高数据可靠性。

（3）派生属性划分

派生属性指该属性取值可以根据表中其他属性的取值唯一确定

（4）关系模式去规范化

在数据库物理设计阶段，可以根据实际需要对数据库中某些3NF、BCNF模式考虑是否可以降低其规范化程度，以提高查询效率

3.3.5 其他物理设计环节

1. 确定系统配置

数据库配置参数（如允许同时使用数据库的用户数、允许同时打开数据库对象数、数据库初始空间大小），磁盘块使用参数，内存缓存区参数（如缓存区个数和大小），时间片大小，装填因子，锁的大小。

2. 物理模式评估

第四章 数据库应用系统功能设计与实施

4.1 软件体系结构与设计过程

4.1.1 软件体系结构

软件体系结构又称软件架构，软件体系结构 = {构件，连接件，约束}

4.1.2 软件设计过程

软件设计可分为概要设计和详细设计两大步骤。

1.概要设计

概要设计的任务是建立软件系统的总体结构和模块间的关系，定义各功能的接口，设计全局数据库或数据结构，规定设计约束，制定测试计划。
概要设计的要求：良好的总体结构，功能模块间较低的耦合程度和功能模块内较高的内聚度，并尽量降低接口复杂度。

2.详细设计

3.关于软件总体设计

对于大型复杂软件系统，可根据逐步抽象和层次化原则，将概要设计分解为两个步骤：

1. 软件总体结构设计，也就是对软件需求进行分解。按照一定原则将其划分为几个若干个子系统；定义各个子系统应实现的功能和相互间的交互关系和通信机制。
2. 将每个子系统进一步划分为功能模块，定义各个功能模块的数据结构、相互间交互关系，根据需要，每个模块进一步分解为多个子模块

系统-子系统-模块-子模块
可将上述概要设计第一步称为软件总体设计，第二步称为软件概要设计。整个软件设计过程都由总体设计、概要设计和详细设计三步骤组成。

4.2 DBAS总体设计

广义上，DBAS设计包括结构设计、过程设计和数据设计三个方面。
DBAS设计第一步是DBAS概念设计，包括数据库概念模型设计和系统总体设计，概念模型设计属于数据设计范畴，系统总体设计涵盖结构设计，过程设计则由其后的事务和应用程序的概要设计和详细设计完成。此外，数据设计除了数据库设计之外还包括事务和应用程序中的数据结构设计。
DBAS总体设计内容：

• DBAS体系结构设计
• DBAS软件总体设计
• 软硬件选型和配置设置
• 业务规则初步设计

4.2.1 DBAS体系结构设计

两种常见DBAS体系结构

1. 客户/服务器结构

C/S结构将数据库管理功能与数据库应用相分离，将DBMS数据管理功能在客户端和服务器之间进行合理的分布和配置。其中数据库服务器完成DBMS核心功能。而客户端或应用服务器则负责完成用户交互功能，接受用户数据，根据业务规则处理应用任务，生成并向数据库服务器发出数据操作请求，然后从数据库服务器接受数据查询结果并通过客户端反馈给用户。

两层C/S结构的数据库应用系统，其特点：

• DBAS的数据管理和数据处理功能被分解并分布在客户端和数据库服务器上。客户端人机交互，数据库服务器数据管理。
• 数据库服务器可以为多个客户端应用提供共享的数据管理功能，避免了为每一个新的应用单独开发对应的服务器端数据管理功能，提高了应用程序相对于数据库的独立性，减少了应用程序的开发和维护代价。
• 客户端可以通过网络访问多个不同数据源。
• 客户端除了完成人机交互功能外，还需要完成面向应用的数据处理功能，负荷较重，属于典型的胖客户端。

2. 浏览器/服务器结构

三层浏览器/服务器（B/S）结构，数据处理功能分解并分布在表示层、功能层和数据层三个层次上，分别由Web浏览器、Web应用服务器和数据库服务器来实现，其特点是：

• 表示层位于客户端，由Web浏览器实现。客户端功能单一，一般只安装Web浏览器。没有其他用户应用程序，属于典型的瘦客户端
• 功能层位于web应用服务器，实现面向具体应用领域的业务规则。
• 数据层位于数据库服务器，通过DBMS完成具体的数据存储和数据存取等数据管理功能。

三层B/S结构将人机交互、应用逻辑处理和数据管理三类功能相互分离，提高了系统的可维护性。

4.2.2 DBAS软件总体设计

4.2.3 软硬件选型与配置设计

软硬件选型涉及内容包括：

• 网络及网络设备选型
• 数据存储设备及备份方案制定
• 应用服务器、Web服务器选型
• 确定系统终端软件环境
• 确定软件平台及开发语言、工具
• 系统中间件及第三方软件选型

考虑以下因素：

• 数据规模：数据量大小、数据增长速度
• 系统性能：系统响应时间、并发访问需求、系统吞吐量、实时性需求、峰值时系统响应速度
• 安全可靠性：数据安全性、数据传输安全性、系统访问安全性、设备可靠性
• 用户需求：用户的特性化需求
• 项目预算情况

4.2.4 业务规则初步设计

业务流程图

4.3 DBAS功能概要设计

功能角度DBAS系统通常划分四个层次实现

• 表示层：负责所有与用户交互的功能
• 业务逻辑层：负责根据业务逻辑需要将表示层获取的数据进行组织后，传递给数据访问层，或将数据访问层获取的数据进行相应的加工后传递给表示层用于展示
• 数据访问层：负责与DBMS系统进行交互，提取或存入应用系统所需的数据
• 数据持久层：负责保存和管理应用系统数据

4.3.1 表示层概要设计

遵循以下原则

1. 用户应当感觉系统的运行始终在自己控制下
2. 当系统发生错误或程序运行时间长时应该提供有意义的反馈信息
3. 一个好的用户界面应该容忍用户的各种操作错误
4. 用户界面应该遵循一定的标准和常规
5. 用户界面应采取灵活多样的数据输入方式，尽量减少用户的输入负担
6. 使用web界面设计应具有简洁性；清晰分类信息，导航；界面一致性；界面美观与交互性能折中平衡

4.3.2 业务逻辑层概要设计

高内聚，松耦合

• 单一责任原则
• 独立功能，减少功能重叠
• 接口简单明确
• 某两个构件间的关系比较复杂的话，应该进一步进行模块划分
• 构件过于复杂，可以考虑将其细分

高内聚和松耦合是相互矛盾的，分解程度越粗的系统耦合性越低，分解越细的系统内聚度越高。

4.3.3 数据访问层概要设计

4.4 DBAS功能详细设计

4.4.1 表示层详细设计

原型迭代法

1. 初步设计
2. 用户界面细节设计
3. 原型设计与改进

4.4.2 业务逻辑层详细设计

4.5 应用系统安全架构设计

4.5.1 数据安全设计

• 安全性保护：防止非法用户对数据库的非法使用，以避免数据的泄露篡改或破坏
• 完整性保护：即保证数据源的正确性和一致性
• 并发控制：即保证多个用户能共享数据库，并维护数据的一致性
• 数据库的备份与恢复
• 数据加密传输

1. 数据库的安全性保护

• 用户身份鉴别
• 权限控制
• 视图机制

2. 数据库的完整性保护

数据库中数据的正确性、一致性和相容性。

3. 数据库的并发控制

常用技术：封锁技术，一段时间禁止某用户对数据对象做某些操作以避免数据不一致的问题
基本的封锁一般包括排他锁（x锁）和共享锁（s锁）两种类型
不可避免带来死锁问题，可以考虑以下原则：

• 按同一顺序访问资源
• 避免事务中的用户交互
• 采取小事务模式，尽量缩短事务的长度，减少占有锁时间
• 尽量使用记录级别的锁（行锁），少用表级别的锁
• 使用绑定连接，使同一应用所打开的两个或多个连接可以相互合作。次级连接获得的任何锁可以像由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞

4.数据库的备份与恢复

数据库恢复首先要建立冗余数据，然后利用这些冗余数据实施恢复

• 双机热备
• 数据转储
• 数据加密传输

5.数据加密传输

• 数字安全证书
• 对称密钥加密
• 数字签名
• 数字信封

4.5.2 环境安全设计

1. 漏洞与补丁

2. 计算机病毒防护

• 安装杀毒软件，定期查杀病毒
• 计算机实时监控

3. 网络环境安全

• 防火墙
• 入侵检测系统
• 网络隔离

4. 物理环境安全

4.5.3 制度安全设计

4.6 DBAS实施

1. 创建数据库
2. 装载数据
3. 编写与调试应用程序
4. 数据库试运行

4.6.1 创建数据库

数据定义语言DDL
创建数据库应该考虑：

• 初始空间大小
• 数据库增量大小
• 访问性能

4.6.2 数据装载

1. 筛选数据
2. 转换数据格式
3. 输入数据
4. 检验数据

4.6.3 编写与调试应用程序

4.6.4 数据库系统试运行

1. 功能测试

2. 性能测试

应该先测试DBMS的恢复功能，做好数据库转储和恢复工作

第五章 UML与数据库应用

5.1 DBAS建模

统一建模语言
UML的定义由语义和表示法两部分组成。语义用自然语言描述，而表示法定义了UML可视化标准表示符号
UML语义是定义在一个四层（四个抽象级别）建模概念框架中，这四层分别：

1. 元元模型层，组成了UML的最基本的元素“事物”，代表要定义的所有事物。
2. 元模型层，组成了UML的基本元素，包括面向对象和面向组件的概念。这一层的每个概念都是元元模型中“事物”概念的实例。
3. 模型层，组成了UML的模型，这一层中每个概念都是元模型层中概念的一个实例，这一层的模型通常叫做类模型或类型模型
4. 用户模型层，这层所有的元素都是UML模型的实例，这层中每个概念都是模型层的一个实例（通过分类）也是元模型层的一个实例。这一层的模型通常叫对象模型或实例模型。

视图是对系统的模型在某方面的投影，注重于系统的某个方面
UML中包括五种视图，结构视图、实现视图、行为视图、环境视图、用例视图
UML2.0有十三种不同的图
结构图：类图，对象图，复合结构图，包图，组件图，部署图
行为图：用例图，交互图（顺序图、通信图、交互概述图、时间图）、状态图和活动图

5.2 DBAS业务流程与需求表达

5.2.1 业务流程与活动图

可以并行执行
起始点：指一连串活动的开始点。在一张活动图中，必须有且只有一个起始点。
结束点：指一连串活动的终点。在一张活动图中，可以有多个结束点。
加粗直线为同步条，表示这之后的活动路线可以并行执行，或在其上的所有并行活动执行完毕后，到此转为顺序执行。

5.2.2 系统需求与用例图

用例模型是把满足用户需求的所有功能表示出来的工具。
用例模型由用例、角色、系统三部分组成。

1. 系统

长方框，系统的名字写在方框上或方框里面，方框内部还可以包含该系统中用符号表示的用例。

2. 角色

角色是与系统交互的人或其他实体。所谓“与系统交互”指的是角色从系统中接收消息，或是向系统提交消息。一个角色可以执行多个用例，反过来，一个用例可以被多个角色使用。角色是类，所以它拥有与类相同的关系描述。在用例图中用通用化关系来描述角色之间的行为。
通用化关系是指把某些角色的共同行为抽取出来作为通用行为，这些通用行为构成它们的超类。这样在定义某一具体角色时，仅仅定义其不同的行为。角色之间的通用化关系用带空心三角形（作为箭头）的直线表示，箭头的方向指向超类。

3. 用例

用例代表一个完整的功能，是所有动作的集合。动作是系统的一次操作，如与角色通信、进行计算，在系统内部进行的工作都可以称为动作。
用例用椭圆表示，用例位于系统边界的内部。用例与角色有连接关系，此关系属于关联又称为通信关联。这种关联表明哪种角色能与该用例通信。关联关系是双向的一对一关系，表示不仅角色不仅可以与用例通信。用户也可以与该角色通信，表示方法是一条连接角色和用例的带箭头直线。
用例之间存在关系，包括扩展、使用、组合三种。

• 扩展关系
  扩展使用的是继承关系，即通用化关系的另一种体现形式。如果有一个用例，在这个用例的基础上加入新的动作形成了另一个用例，即后者是通过继承前者的属性并加入新内容而来的，则前者称为通用化用例，后者称为扩展用例。扩展用例可以根据需要有选择的继承通用用例的部分行为。用例之间的扩展关系可以用带有构造型<>标志的通用化关系
• 使用关系
  一个用例使用另一个用例时构成了使用关系，用例之间的使用关系用构造型具有<>标志的通用化关系。
• 组合关系
  把相关的用例打成包，当做一个整体对待
  

5.3 DBAS系统内部结构的表达

5.3.1 系统结构与类图

1. 属性

属性包括属性的名称、类型和缺省值。
可见性 名称: 类型=缺省值 {约束性}

1. 可见性
   1. 公有 +
   2. 受保护 #
   3. 私有 -
2. 名称
3. 类型
4. 缺省值
5. 约束性：列出该属性所有可能的取值，在定义枚举类型的属性时经常使用，每个枚举值之间用逗号分隔，此外还可以用来说明该属性的其他信息，比如属性的持久性等。

2. 操作

可见性 名称（参数表）：返回类型表达式（约束性）

1. 可见性
2. 名称
3. 参数表
4. 返回类型表达式：可选项，依赖语言的描述
5. 约束性

3. 关系

1. 关联关系

1. 双向关联

通常情况下关联是双向的，其图示是连接两个类之间的直线

2. 单向关联

如果类和类之间的关联是单向的则称为导航关联。导航关联采用实体箭头连接两个类，只有箭头所指的方向上才有这种关联关系。

3. 多重性

如果关联上没有角色名，则隐含着用类名作为角色名。
角色具有多重性，表示有多少对象参与该关联。多重性表示参与对象的数目的上下界限制。*代表0到无穷大，“1”是“1…1"的简写，"6…10"表示6到10个对象。没有明确标识关联的重数则为1。

4.关联类

关联类通过一根虚线与关联连接，用于描述关联可能需要记录的一些信息

5. 聚集

聚集是一种特殊的关联，它表示类之间整体与部分的关系。部分可以参加多个整体则构成共享聚集，整体拥有部分，部分与整体共存则构成了组成关系。
共享聚集表示为空心菱形,组成表示为实心菱形

2. 继承关系

人们将具有共同特性的元素抽象成类别，并通过增加其内涵进一步分类。在面向对象方法中前者被称为一般元素、基类元素或父元素，将后者称为特殊元素或子元素
继承关系表示为一头为空心三角形的连线

3. 依赖关系

有两个元素X和Y，如果修改元素X的定义会引起元素Y定义的修改，则称元素Y依赖于元素X

4. 精化关系

表示同一事物的两种描述之间的关系。对同一事物的两种描述建立在不同的抽象层上。比如定义了某种抽象数据类型，然后将其实现为某种语言中的类，那么抽象定义的类型与用语言实现的类之间就是精化关系，这种情况叫实现，用带空心的三角形的虚线表示。

关系	图例
单向关联	单向实线箭头
双向关联	连接实线
共享聚集	空心菱形实线箭头
组成	实心菱形实线箭头
关联类	连接虚线
依赖	虚线箭头
继承	实心三角形虚线箭头
精化	空心三角形虚线箭头

5.3.2 系统结构与顺序图

针对每一个特定的用例，如何用类图所规范的对象，来完成用例交付的任务，就必须用顺序图表达。
顺序图有两个坐标轴：纵向表示时间的持续过程，横向表示对象，每一个对象用矩形框表示，纵向的虚线表示对象在序列中的执行情况，称为对象的“生命线”
对象间的通信用对象生命线之间的水平消息线表示，消息线的箭头说明消息的类型，单步、异步、简单
顺序图中后面发生消息应该比前面发生的线画的低一些，以表示他们之间的时间关系

当一个对象销毁时，打一个x标记

5.3.3 系统结构与通信图

通信图是交互图的一种，也称为协作图
顺序图和通信图都描述交互，但是顺序图强调的是时间，通信图强调的是空间
通信图中主要元素基本和顺序图相同，只是在消息的传递上要特别表达消息的传递是由哪一个对象到另外一个对象

5.4 DBAS系统微观设计的表达

5.4.1 微观设计与对象图

对象图被用来描述特定时间点所有对象在系统中的结构，也可以把对象图当成系统在某一时间的快照
对象图是类图的一个实例，对象之间的关系是类之间的关系

5.4.2 微观设计与状态机图

当一个对象或某一个事件有非常复杂的状态转换时，可以用状态机图描述这个过程

5.4.3 微观设计与时间图

整个矩形框就是一个生命线

5.5 DBAS系统宏观设计的表达

5.5.1 宏观设计与包图

包图可以表达不同系统的包、命名空间或不同的项目间彼此的关系
包是一种组合机制，把模型元素通过内在的语义连在一起成为一个整体叫包
包通常被称为子系统
包的图示类似书签卡片，由两个长方形组成，小长方形位于大长方形的右上角
包图是表明包与包之间关系的类图

5.5.2 宏观设计与交互概述图

利用活动图作为基础，只是在控制流间连接的UML元素并非活动，而是交互图（包括顺序图、通信图、时间图及交互概述图）

5.5.3 宏观设计与复合结构图

复合结构图最重要的元素是部件，一个部件可以代表某个实体组件，也可以代表一个子系统
部件与部件之间连接关系主要是装配关系，这种关系通过接口沟通。部件与外部部件连接时必须通过端口才能实现，用正方形图示。

5.6 DBAS系统实现与部署的表达

5.6.1系统实现与组件图

在UML中组件表示为一个大方块且在它的左边有两个突出的小方块

5.6.2 系统实现与部署图

部署图又叫配置图，描述系统中硬件和软件的物理配置情况和系统体系结构

总结

第六章 高级数据查询

6.1 一般数据查询功能扩展

6.1.2 使用TOP限制结果集

top n [percent][with ties]

top n 取前n行
top n percent 取查询结果前n%
with ties 表示包括最后一行取值并列的结果

第九章 安全管理

9.1 安全控制概述

安全性：保护数据以防止不合法用户故意造成的破坏
完整性：保护数据以防止合法用户无意中造成的破坏

1.数据库安全控制的目标

数据库安全控制的目标是保护数据免受意外或故意的丢失、破坏或滥用。

2.数据库安全的威胁

• 可用性的损失。意味着用户不能访问数据或系统或者两者都不能访问
• 机密性数据的损失。机密性数据的损失是指数据库中关键性机密数据的损失
• 私密性数据的损失。私密性数据的损失是指个人数据的损失
• 偷窃和欺诈
• 意外的损害

3.安全控制模型

4.授权和认证

授权是将合法访问数据库或数据库对象的权限授予用户的过程。
认证是一种鉴定用户身份的机制
授权控制有时也被认为是访问控制

• 自主存取控制
  用户对不同的数据对象具有不同的存取权限，而且没有固定的关于哪些用户对哪些对象具有哪些存取权限的限制
• 强制存取控制
  每一个数据对象被标以一定的密级，每一个对象被授予一个许可证级别

9.2 存取控制

9.2.1 自主存取控制

1.权限种类

• 对数据库管理系统进行维护
• 对数据库中的对象和数据进行操作的权限
  • 语句权限：对数据库对象的操作权限，包括创建、删除和修改数据库对象
  • 对象权限：对数据库数据操作的权限，包括对表、视图数据的增删改查权限，存储过程的执行权

2.用户分类

1. 系统管理员
2. 数据库对象拥有者。创建数据库对象的用户即为数据库对象拥有者。
3. 普通用户

9.2.2 强制存取控制

将全部实体划分为主体客体两大类
敏感度标记被分为若干级别，例如绝密，秘密，可信和公开
主体的敏感度标记被称为许可证级别，客体的敏感度标记被称为密级

• 仅当主体的许可证级别大于或等于客体的密级时，该主体才能读取相应的客体
• 仅当主体的许可证级别等于客体密级时，该主体才能写相应的客体
  通用安全性分级模式

D类最小保护，C类自主保护，B类强制保护，A类验证保护

• 自主保护。C类分为两个子类C1和C2，C1安全级别低于C2
  • C1子类对所有权和存储权限区分，虽然它允许用户拥有自己的私有数据，但仍然支持共享数据的概念
  • C2子类还需要通过注册、审计以及资源隔离以支持安全责任说明
• 强制保护。B类分为三个子类B1 B2 B3，B1安全级别最低，B3最高
  • B1要求标识化安全保护，并要求每个数据对象都标以一定的密级，同时还要求安全策略的非形式化说明
  • B2要求安全策略的形式化说明，能够识别并消除隐蔽通道（隐蔽通道的例子有从合法查询结果推断不合法查询结果）
  • B3子类要求支持审计和恢复以及指定安全管理者
• 验证保护。A类要求安全机制是可靠的且足够支持对指定安全策略给出严格的数学证明

9.3 审计跟踪

审计跟踪实质上是一种特殊的文件或数据库，系统在上面自动记录用户对常规数据的所有操作

9.4 统计数据库的安全性

9.5 SQL server的安全控制

9.5.1 身份验证模式

1.windows身份验证模式

2.混合验证模式

9.5.2 登录账户

1.建立登录账户

例1：创建SQL server 身份验证的登录账户

create login SQL_User1 with password = '12345678'

例2：创建Windows身份验证的登录账户，从Windows域账户创建[TEST\Win_User2]登录账户

create login [TEST\Win_User2] from windows

例3：创建SQL server身份验证的登录账户。要求该用户首次连接服务器时必须更改密码

create login SQL_User3 with password = '123456789'
must_change

2.修改登录账户属性

例4：启用或禁用的登录账户

alter login SQL_User1 enable

例5：修改登录账户的密码

alter login SQL_User1 with password='12345'

例6：更改账户名

alter login SQL_User3 with name = 'NewUser'

3. 删除登录账户

例7：删除登录账户

drop login SQL_User2

9.5.3 数据库用户

让登录账户成为数据库用户的操作是映射 。一个登录账户可以映射为多个数据库中的用户。 默认情况下，新建立的数据库只有一个用户dbo，他是数据库的拥有者

1.建立数据库用户

例8 使SQL_User2登录账户成为某数据库中的用户，并且用户名同登录名

create user SQL_User2

例9 首先创建名为SQL_JWC且具有密码的SQL Server身份验证的服务器登录名，然后在test数据库中创建与此登录名对应的数据库用户JWC 、

create login SQL_JWC with password='123456'
go
use test
go
create user JWC for login SQL_JWC  
go

2.Guest用户

启用guest用户
grant connect to guest
禁用guest用户
revoke connect to guest

3.删除数据库用户

drop user user_name

9.5.4 权限管理

1. 对象级别的权限

操作权限	使用说明
select	允许用户查询数据
insert	允许用户插入数据
update	允许用户修改数据
delete	允许用户删除数据
references	如果用户要插入数据的表上有外键约束，而用户在外键所引用的表上没有select权限，则拥有该权限的用户能够向这样的表插入数据
execute	允许用户具有执行存储过程和标量函数的权限

（1）授权语句

例10授予用户RosaQdm对Address表具有select权限

grant select on Address to RoseQdm

例11