7.1 数据库设计概述：

• 数据库设计一般定义：数据库设计是指对于一个给定的应用环境，构造（设计）优化的数据库逻辑模式和物理结构，并据此建立数据库及其应用系统，使之能够有效地存储和管理数据，满足各种用户的应用需求，包括信息管理要求和数据操作要求
  • 定的应用环境：一个数据库不可能什么数据都接收，如在学校或工厂，就要建立相当于的数据库，学校工厂就是环境　
  • 逻辑模式：如设计的一张表，表的属性设计，每个表中应该放什么数据，是第几范式，这就是在逻辑模式设计的
  • 物理结构：就是数据存储在什么地方，怎么存放
• 信息管理要求：在数据库中应该存储和管理哪些数据对象
• 数据操作要求：对数据对象需要进行哪些操作，如查询、增、删、 改、统计等操作
• 数据库设计的目标：为用户和各种应用系统提供一个信息基础设施和高效的运行环境
• 高效的运行环境：(数据库是应用程序理最底层的交互平台，所以要保证高效的操作，要求如下)
  • 数据库数据的存取效率高
  • 据库存储空间的利用率高
  • 数据库系统运行管理的效率高

7.1.1　数据库设计的特点：

• 三分技术，七分管理，十二分基础数据
  • 管理：数据库建设项目管理、企业（即应用部门）的业务管理
  • 基础数据：数据的收集、整理、组织和不断更新是数据库建设中的重要环节
• 结构（数据）设计和行为（处理）设计相结合
  • 整个设计过程中把数据库结构设计和对数据的处理设计密切结合起来
  • 结构和行为分离的设计：(如图，数据库和软件设计分离，不好的设计)
    • 传统的软件工程：重行为设计，忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策
    • 早期的数据库设计：重结构设计，致力于数据模型和数据库建模方法研究，忽视了行为设计对结构设计的影响
  • 

7.1.2 数据库设计方法：

• 大型数据库设计是涉及多学科的综合性技术，又是一项庞大的工程项目。它要求数据库设计人员具有多方面的知识和技术主要包括：
  • 计算机的基础知识
  • 软件工程的原理和方法
  • 程序设计的方法和技巧
  • 数据库的基本知识
  • 数据库设计技术
  • 应用领域的知识
• 早期数据库设计：主要采用手工与经验相结合的方法:
  • 设计质量与设计人员的经验和水平有直接关系
  • 缺乏科学理论和工程方法的支持，设计质量难以保证
  • 数据库运行一段时间后又不同程度地发现各种问题，增加了系统维护的代价
• 规范设计法基本思想：过程迭代和逐步求精,典型方法如下：
  • 新奥尔良（New Orleans）方法
    • 简介：把数据库设计分为四个间阶段，目前不同的阶段做什么事，如第一个阶段需求分析(了解用户和应用程序对数据库的要求)，第二个阶段概念结构设计根据需求分析设计出数据库大致长什么样(如用E-R图)，第三阶段逻辑设计根据E-R设计转为数据库中实际的表，第四阶段物理结构设计(就是数据存储在什么地方，怎么存放)　　
  • 基于 E-R 模型的设计方法
    • 简介：根据需求分析得到实体与实体之间的联系，做成E-R图　　
  • 3NF（第三范式）的设计方法
    • 简介：就是取消了表中的传递函数依赖　　
  • 面向对象的数据库设计方法
    • 简介：和java中的面向对象一样的原理　　
  • 统一建模语言（UML）方法
    • 简介：这是一种工具，和E-R图有点类似，表达出实体与实体间的联系

7.1.3　数据库设计的基本步骤：

• 数据库设计分 6 个阶段：(在上述的新奥尔良方法中增加了两个设计)
  • 需求分析  -- 就是了解数据库要建成什么样
  • 概念结构设计 -- 把数据库描述出来(如用E-R或UML)
  • 逻辑结构设计 -- 根据概念结构设计，在数据库中设置出一张张表
  • 物理结构设计 -- 数据存储在什么地方，怎么存放
  • 数据库实施 -- 上面四步数据库就建成，那怎么用，就是实施
  • 数据库运行和维护 -- 数据库进行使用枚举需要运行和维护
• 细节：
  • 需求分析和概念结构设计独立于任何数据库管理系统
    • 理解：这两个阶段不是真得要建立数据库，只是设计阶段，独立于任何数据库管理系统，就是那我设计完了，可能用MySQL或SqlServer
  • 逻辑结构设计和物理结构设计与选用的数据库管理系统密切相关
    • 理解：就是不同的数据库管理系统，设计的操作也不同，所以密切相关，像MySQL或SqlServer的很多操作就不同　
  • 这个图可以多看：　　
• 
• 参加数据库设计的人员
  • 系统分析人员和数据库设计人员：数据库设计的核心人员，将自始至终参与数据库设计，其水平决定了数据库系统的质量
  • 数据库管理员和用户代表：主要参加需求分析与数据库的运行和维护
  • 应用开发人员（包括程序员和操作员）：在实施阶段参与进来，分别负责编制程序和准备软硬件环境
• 各阶段的主要任务：
  • 1. 需求分析阶段
    • 整个设计过程的基础，是最困难和最耗费时间的一步
    • 是否做得充分与准确，决定了构建数据库的速度和质量
  • 2. 概念结构设计阶段
    • 整个数据库设计的关键
    • 通过对用户需求进行综合、归纳与抽象，形成一个独立于具体数据库管理系统的概念模型
  • 3. 逻辑结构设计阶段
    • 将概念结构转换为某个数据库管理系统所支持的数据模型，并对其进行优化
  • 4.物理结构设计阶段　　
  • • 为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
  • 5. 数据库实施阶段
    • 根据逻辑设计和物理设计的结果建立数据库
    • 编写与调试应用程序
    • 组织数据入库并进行试运行
  • 6. 数据库运行和维护阶段
    • 经过试运行后即可投入正式运行
    • 在运行过程中必须不断对其进行评估、调整与修改
• 细节：
  • 设计一个完善的数据库应用系统，往往是上述 6 个阶段的不断反复
  • 这个设计步骤既是数据库设计的过程，也包括了数据库应用系统的设计过程
  • 在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来，将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计　
• 各阶段的数据设计描述：
• 

• 对上述图简单的说明：
  • 1.需求分析阶段
    • 综合各个用户的应用需求
  • 2.概念设计阶段
    • 用图像的方式(E-R图)表示出需要分析
  • 3.逻辑设计阶段
    • 将E-R图转换成具体的数据库产品支持的数据模式(就是表)
    • 然后根据用户处理的要求、安全性考虑，在基本表上在建立视图，形成数据外模式
  • 4.物理设计阶段
    • 根据(不同的产品数据库)数据库管理系统特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

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

7.2 需求分析：

• 什么是需求分析？分析用户的要求

7.2.1 需求分析的任务：

• 详细调查现实世界要处理的对象（组织、部门、企业等）
• 充分了解原系统（手工系统或计算机系统）的工作概况
• 明确用户的各种需求，然后在此基础上确定新系统的功能
• 新系统必须充分考虑今后可能的扩充和改变
• 调查的重点：是“数据”和“处理”，通过调查、收集与分析，获得用户对数据库的信息要求、处理要求、安全性与完整性要求

7.2.2 需求分析的方法：

• 需求分析的目标：
  • 调查清楚用户的实际要求并进行初步分析，与用户达成共识，分析与表达这些需求
• 调查用户需求的具体步骤：
  • 调查组织机构情况
  • 调查各部门的业务活动情况
  • 协助用户明确对新系统的各种要求，包括信息要求、 处理要求、完全性与完整性要求
  • 确定新系统的边界
• 常用的调查方法：
  • 跟班作业。通过亲身参加业务工作来了解业务活动的情况
  • 开调查会。通过与用户座谈来了解业务活动情况及用户需求
  • 请专人介绍
  • 询问。对某些调查中的问题可以找专人询问
  • 设计调查表请用户填写。如果调查表设计得合理，则很有效
  • 查阅记录。查阅与原系统有关的数据记录
  • 结构化分析方法（Structured Analysis，SA）：从最上层的系统组织机构入手，采用自顶向下、逐层分解的方式分析系统
  • 　　　　　　　　　　

7.2.3 数据字典：

• 什么是数据字典？数据字典和新华字典一样，但数据字典解释的是每一个数据，解释每一个数据里面有什么属性和什么操作
• 数据字典是关于数据库中数据的描述，即元数据(不是直接描述，如存的是张三，学号001不是这样描述，而是描述出学号是什么样的，应该学号是三位的的数字，范围是多少，是这样描述的)，不是数据本身。数据字典是在需求分析阶段建立，是继续详细的数据收集和数据分析所得到的，并在数据库设计过程中不断修改、充实、完善的
• 数据字典包括：数据项(有哪些数据)、数据结构(这个数据是什么结构，如：学号的结构是什么)、数据流(数据的流向，部门A指向部门B)、数据存储(数据是B+树存储还是表的形式存储)、处理过程(数据库哪些数据要进行增删改查，这个操作可以被哪些用户拥有)
• 数据项：数据项是不可再分的数据单位
  • 数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系，数据项之间的联系}　
  • 理解：
    • 数据项名 -- 如Sno
    • 数据项含义说明 -- Sno的作用
    • 别名 -- Sno在其它其它表中是否有别名，如学号
    • 数据类型 -- Sno的数据类型，然char(3)
    • 长度 -- char(3),3就是它的长度
    • 取值范围 -- Sno的取值范围001-999
    • 取值含义 -- 001是学号，或表示男女生0是女1是男
    • 与其他数据项的逻辑关系 --如： SC(Sno,Cno)，就是外键
    • 数据项之间的联系：如知道Sno就可以推出学生的姓名，就是函数依赖
  • “取值范围”、“与其他数据项的逻辑关系”定义了数据的完整性约束条件，是设计数据检验功能的依据
  • 可以用关系规范化(范式)理论为指导，用数据依赖的概念分析和表示数据项之间的联系
• 数据结构：数据结构反映了数据之间的组合关系
  • 数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}
  • 说明：一个数据结构可以由若干个数据项组成，也可以由若干个数据结构组成，或由若干个数据项和数据结构混合组成
  • 理解：如仓库进货，入库单就是数据结构，入库单上又有很多信息
• 数据流：数据流是数据结构在系统内传输的路径
  • 数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}
  • 理解：如从选课表中抽取一个成绩反馈给用户
    • 数据流名 -- 就可以是成绩
    • 说明 -- 该数据是干什么的
    • 数据流来源 -- 数据从哪来的SC表
    • 数据流去向 -- 数据到哪去，到应用程序
    • 组成 -- 如学号、姓名和成绩组成
    • 平均流量 -- 如12小时或一个月的传输次数
    • 高峰期流量 -- 如15号来查询成绩，15号就是高峰期流量
  • 说明：
    • 数据流来源：说明该数据流来自哪个过程
    • 数据流去向：说明该数据流将到哪个过程去
    • 平均流量：在单位时间（每天、每周、每月等）里的传输次数
    • 高峰期流量：在高峰时期的数据流量
• 数据存储：数据存储是数据结构停留或保存的地方，也是数据流的来源和去向之一
  • 数据存储描述={数据存储名，说明，编号，输入的数据流，输出的数据流，组成：{数据结构}，数据量，存取频度，存取方式}
  • 理解：
    • 数据存储名 -- 这个存储的名字
    • 说明 -- 存储什么信息
    • 编号 -- 存储编号
    • 输入/出的数据流 -- 输入输出的信息
    • 组成 -- 输入输出的是哪些数据，存取的量，存取的频率，存取的方式
  • 说明：
    • 存取频度：每小时、每天或每周存取次数及每次存取的数据量等信息
    • 存取方式：批处理/ 联机处理；检索/ 更新；顺序检索/随机检索
    • 输入的数据流：数据来源
    • 出的数据流：数据去向
• 处理过程：处理过程的具体处理逻辑一般用判定表或判定树来描述。数据字典中只需要描述处理过程的说明性信息
  • 处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}
  • 说明： -- 说白了就是我要对该数据做什么
    • 说明该处理过程的功能及处理要求 -- 如该处理要达到什么目的，如查询成绩最高的学生
    • 功能：该处理过程用来做什么
    • 处理要求：处理频度要求(如多次时间执行一次)，如单位时间里处理多少事务，多少数据量、响应时间要求等　
    • 这些处理要求是后面物理设计的输入及性能评价的标准
• 需求分析小结：
  • 需求收集和分析作为数据库设计的第一阶段是十分重要的
  • 第一阶段收集的基础数据（用数据字典来表达）是下一步进行概念设计的基础
  • 强调两点：
    • 设计人员应充分考虑到可能的扩充和改变，使设计易于更改、系统易于扩充
    • 必须强调用户的参与　　

7.3 概念结构设计(E-R):

• 什么是概念结构设计？将需求分析得到的用户需求抽象为信息结构（即概念模型）的过程就是概念结构设计

7.3.1 概念模型：

• 什么是概念模式？将需求分析得到的用户需求抽象为信息结构（即概念模型）

• 概念模型的主要特点：

  （1）能真实、充分地反映现实世界，包括事物和事物之间的联系，是现实世界的一个真实模型

  （2）易于理解，可以用它和不熟悉计算机的用户交换意见

  （3）易于更改，当应用环境和应用要求改变时容易对概念模型修改和扩充

  （4）易于向关系、网状、层次等各种数据模型转换

7.3.2 E-R模型：

• 描述现实世界的概念模型的工具：E-R 模型
• 实体是E-R图的核心，做E-R图的时要先找实体，实体包括实体的名称，实体的属性，在找另外一个实体，在找实体与实体的联系
• 什么是实体？在现实世界中客观存在并可相互区别的事物，如一个人，商店等
• 实体之间的联系： 两个实体型之间的联系
  • 一对一联系（1:1）、一对多联系（1:n）、多对多联系（m:n）
• 

• 两个以上的实体型之间的联系：

  • 多个以上的实体型之间也存在着一对一、一对多、多对多联系
• 

• 单个实体型内的联系：

  • 同一个实体集内的各实体之间也可以存在一对一、一对多、多对多联系

• 

• 联系的度：参与联系的实体型的数目
  • 两个实体型之间的联系度为 2，也称为二元联系
  • 三个实体型之间的联系度为 3，称为三元联系
  • N个实体型之间的联系度为 N，也称为 N 元联系
• E-R 图:
  • E-R 图提供了表示实体型、属性和联系的方法:
    • 实体型：用矩形表示，矩形框内写明实体名
    • 属性：用椭圆形表示，并用无向边将其与相应的实体型连接起来
    • 联系：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体型连接起来，同时在无向边旁标上联系的类型（1:1、1:n 或 m:n）　
• 例子：
  • 某个工厂物资管理的概念模型。物资管理涉及的实体有：
    • 仓库：属性有仓库号、面积、电话号码
    • 零件：属性有零件号、名称、规格、单价、描述
    • 供应商：属性有供应商号、姓名、地址、电话号码、账号
    • 项目：属性有项目号、预算、开工日期
    • 职工：属性有职工号、姓名、年龄、职称
  • 这些实体之间的联系如下：　　
    • 一个仓库可以存放多种零件，一种零件可以存放在多个仓库中，因此仓库和零件具有多对多的联系。用库存量来表示某种零件在某个仓库中的数量
    • 一个仓库有多个职工当仓库保管员，一个职工只能在一个仓库工作，因此仓库和职工之间是一对多的联系
    • 职工之间具有领导与被领导关系，即仓库主任领导若干保管员，因此职工实体型中具有一对多的联系　
    • 供应商、项目和零件三者之间具有多对多的联系，即一个供应商可以供给若干项目多种零件，每个项目可以使用不同供应商供应的零件，每种零件可由不同供应商供给
  • 

7.4 逻辑结构设计：

• 什么是逻辑结构设计？ 就是把一个E-R图转换为一个二维表　
  • 转换原则：一个实体型转换为一个关系模式，关系的属性就是实体的属性，关系(表)的码就是实体的码
• 实体型间的联系有以下不同情况：
  • 一个 1:1 联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并
    • 转换为一个独立的关系模式： -- 一般不使用有数据冗余
      • 关系的属性：与该联系相连的各实体的码以及联系本身的属性(没有本身属性就不用写)
      • 关系的候选码：每个实体的码
    • 与某一端实体对应的关系模式合并：
      • 合并后关系的属性：加入对应关系的码和联系本身的属性
      • 合并后关系的码：不变
  • 
  • 一个 1:n 联系可以转换为一个独立的关系模式，也可以与 n 端对应的关系模式合并
    • 转换为一个独立的关系模式：
      • 关系的属性：与该联系相连的各实体的码以及联系本身的属性(没有本身属性就不用写)
      • 关系的码：n 端实体的码
    • 与 n 端对应的关系模式合并： -- 可以减少系统中的关系个数，一般情况下更倾向于采用这种方法
      • 合并后关系的属性：在 n 端关系中加入 1 端关系的码和联系本身的属性
      • 合并后关系的码：不变　
  • 
  • 一个 m:n 联系转换为一个关系模式
    • 关系的属性：与该联系相连的各实体的码以及联系本身的属性
    • 关系的码：各实体码的组合
  • 
  • 三个或三个以上实体间的一个多元联系转换为一个关系模式：
    • 关系的属性：与该多元联系相连的各实体的码以及联系本身的属性
    • 关系的码：各实体码的组合
  • 
  • 具有相同码的关系模式可合并：
    • 目的：减少系统中的关系个数
    • 合并方法：将其中一个关系模式的全部属性加入到另一个关系模式中，然后去掉其中的同义属性（可能同名也可能不同名），适当调整属性的次序
• 例子：下面把某工厂管理信息系统虚线上部的 E-R 图转换为关系模型
  • 
  • 部门（部门号，部门名，经理的职工号，…）
  • 职工（职工号、部门号，职工名，职务，…）
  • 产品（产品号，产品名，产品组长的职工号，…）
  • 供应商（供应商号，姓名，…）
  • 零件（零件号，零件名，…）
  • 参加（职工号，产品号，工作天数，…）
  • 供应（产品号，供应商号，零件号，供应量）

7.4.2 数据库模式的优化：

• 目的：就是为了提高查询效率
• 数据库逻辑设计的结果不是唯一的
• 得到初步数据模型后，还应该适当地修改、调整数据模型的结构，以进一步提高数据库应用系统的性能，这就是数据模型的优化　
• 关系数据模型的优化通常以规范化(范式)理论为指导
• 优化数据模型的方法：
  • 确定数据依赖，按需求分析阶段所得到的语义，分别写出每个关系模式内部各属性之间的数据依赖以及不同关系模式属性之间数据依赖
  • 对于各个关系模式之间的数据依赖进行极小化处理，消除冗余的联系，具体方法见7.3.3“概念结构设计　
  • 按照数据依赖的理论对关系模式逐一进行分析，考察是否存在部分函数依赖、传递函数依赖、多值依赖等，确定各关系模式分别属于第几范式
  • 根据需求分析阶段得到的处理要求，分析对于这样的应用环境这些模式是否合适，确定是否要对某些模式进行合并或分解
  • 对关系模式进行必要分解，提高数据操作效率和存储空间的利用率
    • 水平分解：把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系，以提高系统的效率　
      • 如何分解：根据“80/20原则”，把经常被使用的数据（约20%）水平分解出来，形成一个子关系
      • 例：如学生表，到了毕业季，那么毕业学生的信息就会频繁使用，非毕业的学生学习不所有，就可以把毕业学生的信息分解出来成为以后给子关系，没有必要去调用整张学生表
      • 细节：水平分解为若干子关系，使每个事务存取的数据对应一个子关系
    • 垂直分解：把关系模式 R ​的属性分解为若干子集合，形成若干子关系模式
      • 例：就是把一张表分成多个表，和前面的范式相同
      • 原则：将经常在一起使用的属性从 R ​中分解出来形成一个子关系模式
      • 优点：可以提高某些事务的效率
      • 缺点：可能使另一些事务不得不执行连接操作，降低了效率
      • 适用范围：取决于分解后 R ​ 上的所有事务的总效率是否得到了提高　　　　　　　　　　　
• 细节：
  • 并不是规范化程度越高的关系就越优
  • 例：当查询经常涉及两个或多个关系模式的属性时，系统经常进行连接运算，连接运算的代价是相当高的（可以说关系模型低效的主要原因就是由连接运算引起的),因此在这种情况下，第二范式甚至第一范式也许是适合的

7.4.3 设计用户子模式：

• 什么是设计用户子模式？就是从用户都角度去考虑，根据用户的习惯去设计　　
• 在定义数据库全局模式主要是从系统的时间效率、空间效率、易维护等角度出发
• 在定义用户外模式时应该更注重考虑用户的习惯与方便。包括三个方面：
  • 使用更符合用户习惯的别名
    • 例：工厂，生产车间把一个产品叫产品，研发部把产品叫项目，但他们说的都是同一个东西，就需要根据他们叫法的不同去设计不同的别名
  • 针对不同级别的用户定义不同的视图，以保证系统的安全性
    • 例：根据不同的用户等级设计不同的视图，不同的视图看到的东西也不同
  • 简化用户对系统的使用
    • 例：一个复杂的多表连接查询，那么就可以把这个复杂的查询定义为一个视图　　　　　　　　　　　　　　　　　

7.5 物理结构设计：

• 什么是物理结构设计？选择一种合适的存储方式去存储关系模式(表)

• 数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于选定的数据库管理系统，

  为一个给定的逻辑数据模型选取一个最适合应用要求的物理结构的过程，就是数据库的物理设计

• 数据库物理设计的步骤：
  • 确定数据库的物理结构，在关系数据库中主要指存取方法和存储结构
  • 对物理结构进行评价，评价的重点是时间和空间效率

7.5.1 数据库物理设计的内容和方法：

• 首先对要运行的事务进行详细分析，获得选择物理数据库设计所需要的参数；其次，要充分了解所用关系数据库管理系统的内部特征，特别是系统提供的存取方法和存储结构
• 选择物理数据库设计所需参数：
  • 对于数据库查询事务，需要得到如下信息：
    • 查询的关系
    • 查询条件所涉及的属性
    • 连接条件所涉及的属性
    • 查询的投影属性
  • 对于数据更新事务，需要得到如下信息：
    • 被更新的关系
    • 每个关系上的更新操作条件所涉及的属性
    • 修改操作要改变的属性值
  • 还需要知道每个事务在各关系上运行的频率和性能要求 -- 例：如事物B必须要在5秒内完成查询，就需要对于存取方法的选择具有重大的影响　

7.5.2 关系模式存取方法选择：

• 数据库管理系统常用存取方法：B+树索引存取方法（索引方法）、hash 索引存取方法（索引方法）、聚簇存取方法（聚簇方法）
• B+树索引存取方法的选择:
  • 根据应用要求确定对表的那些属性建立索引、哪些属性列建立组合索引、哪些索引要设计为唯一索引
  • 一般规则：
    • 一个（或一组）属性经常在查询条件中出现，则该属性（或这组）属性上就可以建立索引
    • 一个属性经常作为最大值和最小值等聚集函数的参数，则考虑在这个属性上建立索引
    • 一个（或一组）属性经常在连接操作的连接条件中出现，则考虑在这个（或这组）属性上建立索引
  • 关系上定义的索引数并不是越多越好，系统为维护索引要付出代价，查找索引也要付出代价。
    • 例：若一个关系的更新频率很高，这个关系上定义的索引数不能太多。因为更新一个关系时，必须对这个关系上有关的索引做相应的修改
  • 
• hash索引存取方法的选择：　　　　　　　　　　　　　　　　
  • 一个关系的属性主要出现在等值连接条件中或主要出现在等值比较选择条件中，而且满足下列两个条件之一
    • 该关系的大小可预知，而且不变
    • 该关系的大小动态改变，但所选用的数据库管理系统提供了动态 hash 存取方法 -- 说白就是数据库系统可以动态调整hash
• 聚簇存取方法的选择：
  • 聚簇：为了提高某个属性（或属性组）的查询速度，把这个或这些属性上具有相同值的元组集中存放在连续的物理块(同一个磁盘中)中。该属性（或属性组）称为聚簇码（cluster key）
    • 理解：为什么说存放连续的物理块，因为如果磁盘的空间不够存放，就会把数据分开到其它的磁盘存放　　
  • 一个数据库可以建立多个聚簇，一个关系(表)只能加入一个聚簇。选择聚簇存取方法，即确定需要建立多少个聚簇，每个聚簇中包括哪些关系
  • 首先设计候选聚簇，一般来说：
    • 对经常在一起进行连接操作的关系可以建立聚簇
    • 如果一个关系的一组属性经常出现在相等比较条件中，则该单个关系可建立聚簇　
    • 如果一个关系的一个（或一组）属性上的值重复率很高，则此单个关系可建立聚簇。即对应每个聚簇码值的平均元组数不能太少，太少则聚簇的效果不明显　
  • 然后检查候选聚簇中的关系，取消其中不必要的关系：
    • 从聚菱中删除经常进行全表扫描的关系
    • 从聚簇中删除更新操作远多于连接操作的关系
    • 不同的聚簇中可能包含相同的关系，一个关系可以在某一个聚簇中，但不能同时加入多个聚簇。要从这多个聚簇方案（包括不建立聚族）中选择一个较优的，即在这个聚簇上运行各种事务的总代价最小
  • 适用范围：
    • 适用于单个关系，也适用于经常进行连接操作的多个关系
  • 强调：聚簇只能提高某些应用的性能，而且建立与维护聚簇的开销是相当大的。对已有关系建立聚簇，将导致关系中元组的物理存储位置移动，并使此关系上原来建立的所有索引无效，必须重建。当一个元组的聚簇码改变时，该元组的存储位置也要做相应移动

7.5.3 确定数据库的存储结构：

• 目的？确定数据的存放位置和存储结构，包括确定关系、索引、聚簇、日志、备份等的存储安排和存储结构，确定系统配置等
• 确定数据的存放位置和存储结构要综合考虑存取时间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，因此需要进行权衡，选择一个折中方案
• 确定数据的存放位置：-- 大小不同的表可以分开存放
  • 为了提高系统性能，应该根据应用情况将数据的易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放
    • 如：比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效
    • 如：将日志文件与数据库对象（表、索引等）放在不同的磁盘上，以改进系统的性能
• 确定系统配置：- 改变数据库系统产品的系统默认值
  • 关系数据库管理系统产品一般都提供了一些系统配置变量和存储分配参数，系统都为这些变量赋予了合理的默认值。但是这些值不一定适合每一种应用环境，在进行物理设计时需要重新对这些变量赋值，以改善系统的性能
• 评价物理结构：-- 选择一个最好的物理结构
  • 对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案。数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构
  • 细节：评价物理数据库的方法完全依赖于所选用的关系数据库管理系统

7.6 数据库的实施和维护：

7.6.1 数据的载入和应用程序的调试：

• 数据库实施阶段包括两项重要的工作：数据的载入(就是把数据导入到数据库中)、应用程序的编码和调试
• 数据装载方法：人工方法、计算机辅助数据入库

7.6.2 数据库的试运行：

• 目的：在实际从场景运行，看能不能满足用户的要求，性能能不能达到最优
• 在原有系统的数据有一小部分（小部分是因为导入数据是一个大工程，如果全部导入数据库出错就又要重新导入数据，所有是一小部分）已输入数据库后，就可以开始对数据库系统进行联合调试，也称数据库的试运行
• 主要工作包括：
  • 功能测试：实际运行应用程序，执行对数据库的各种操作，测试应用程序的各种功能。
  • 性能测试：测试系统的性能指标，分析是否达到设计目标
• 数据库性能指标的测量：
  • 在设计阶段，会忽略很多细节，所以在试运行时，又不符合设计要求的，要重新调整物理结构，修改系统参数
• 数据库性能指标的测量：
  • 数据入库工作量实在太大，所以可以采用分期分批输入数据的方法：先输入小批量数据供先期联合调试使用，待试运行基本合格后再输入大批量数据，逐步增加数据量，逐步完成运行评价
• 数据库的转储和恢复:
  • 试运行阶段，系统还不稳定，硬、软件故障随时都可能发生,系统的操作人员对新系统还不熟悉，误操作也不可避免，因此必须做好数据库的转储和恢复工作，尽量减少对数据库的破坏　

7.6.3 数据库的运行和维护:

• 在数据库运行阶段，对数据库经常性的维护工作主要是由数据库管理员完成的，包括：
  • 数据库的转储和恢复
    • 针对不同的应用要求制定不同的转储计划，定期对数据库和日志文件进行备份　
    • 一旦发生介质故障，即利用数据库备份及日志文件备份，尽快将数据库恢复到某种一致性状态　
  • 数据库的安全性、完整性控制
    • 如：一个机密数据，可能过了十几天就不是机密的了，这就是控制　　
  • 数据库性能的监督、分析和改造　　　　
    • 利用监测工具获取系统运行过程中一系列性能参数的值
    • 通过仔细分析这些数据，判断当前系统是否处于最佳运行状态
    • 如果不是，则需要通过调整某些参数来进一步改进数据库性能　　
  • 数据库的重组织与重构造
    • 重组织：大修改
    • 重构造：结构发生变化　　　　

出处：https://www.cnblogs.com/Mr-shne/p/16880207.html