目录
前言：
笔记来自《文老师软考数据库》教材精讲，精讲视频在b站，某宝都可以找到，个人感觉通俗易懂。
11.1 数据库设计概述
数据库应用系统的生命周期：
（1）数据库规划：起点，数据库应用系统的任务陈述和任务目标制定阶段；
（2）需求描述与分析：从用户的角度，收集和整理用户需求；
（3）数据库设计与应用程序设计： 针对用户数据的组织和存储设计，在此基础上对数据操作及业务实现的设计，包括事务设计和用户界面设计；
（4）实现：依据设计，使用DBMS支持的DDL实现数据库的建立，用高级语言编写应用程序；
（5）测试：对数据库系统进行测试；
（6）运行维护：不断的对DBS进行评价、调整与修改，直至系统消亡。
- 数据库设计的一般策略：自顶向下，自底向上。
- 数据库设计的步骤
(1)用户需求分析·即分析数据存储的要求和边界，产出物有数据流图、数据字典、需求说明书。
(2)概念结构设计，设计用户的数据模型，与具体DBMS无关的概念模型，一般般是设计E-R图，也即实体-属性图，与物理实现无关，就是说明有哪些实体，实体有哪些属性。
(3)逻辑结构设计:(将抽象的概念模型转化为与选用的DBMS 产品所支持的数据模型相符合的逻辑模型，它是物理结构设计的基础。包括模式初始设计、子模式设计、应用程序设计、模式评价以及模式求精。
(4)物理结构设计: 逻辑模型在计算机中的具体实现方案。
(5)数据库实施阶段。数据库设计人员根据逻辑设计和物理设计阶段的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。
(6)数据库运行和维护阶段。数据库应用系统经过试运行即可投入运行，但该阶段需要不断地对系统进行评价、调整与修改。 - 数据库设计一般应包括数据库的结构设计和行为设计两部分内容。数据库的结构设计是指系统整体逻辑模式与子模式的设计，是对数据的分析设计:数据库的行为设计是指施加在数据库上的动态操作 (应用程序集)的设计，是对应用系统功能的分析设计。
11.2 系统需求分析
- 在整个设计开发过程中是最困难、最耗时的一步。
- 需求分析的任务：对现实世界中要处理的对象进行详细调查，确定新系统功能，收集支持系统目标的基础数据及处理方法。
- 分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。
- 需求分析的重点是调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界，以此获得用户对系统的如下要求：
(1)信息要求。用户需要在系统中保存哪些信息，由这些保存的信息要得到什么样的信息，这些信息以及信息间应当满足的完整性要求。
(2)处理要求。用户在系统中要实现什么样的操作功能，对保存信息的处理过程和方式，各种操作处理的频度、响应时间要求、处理方式等以及处理过程中的安全性要求和完整性要求。
(3)系统要求。包括安全性要求、使用方式要求和可扩充性要求。安全性要求:系统有几种用户使用，每一种用户的使用权限如何。使用方式要求:用户的使用环境是什么，平均有多少用户同时使用，最高峰时有多少用户同时使用，有无查询相应的时间要求等。可扩充性要求:对未来功能、性能和应用访问的可扩充性的要求。 - 需求分析阶段的文档: 需求说明文档、数据流图DFD、数据字典DD
11.3 概念结构设计
- 概念结构设计的目标是产生反映系统信息需求的数据库概念结构，即概念模式。概念结构是独立于支持数据库的DBMS 和使用的硬件环境的。此时，i设计人员从用户的角度看待数据以及数据处理的要求和约束，产生一个反映用户观点的概念模式，然后再把概念模式转换为逻辑模式。
- 概念结构设计策略与方法: 自顶向上、自底向上、逐步扩张、混合策略。
- 使用E-R 方法，无论是哪种策略，都要对现实事物加以抽象认识，以E-R 图的形式描述出来对现实事物抽象认识的三种方法分别是分类、聚集和概括。
(1)分类:对现实世界的事物，按照其具有的共同特征和行为，定义一种类型。这在现实生活中很常见，如学校中的学生和教师就属于不同的类型。在某一类型中，个体是类型的一个成员或实例，即“is member of”，如李娜是学生类型中的一个成员。
(2)聚集:定义某一类型所具有的属性。如学生类型具有学号、姓名、性别、班级等共同属性每一个学生都是这一类型中的个体，通过在这些属性上的不同取值来区分。各个属性是所属类型的一个成份，即“is part of”，如姓名是学生类型的一个成份。
(3)概括:由一种己知类型定义新的类型。如由学生类型定义研究生类型，在学生类型的属性上增加导师等其他属性就构成研究生类型。通常把己知类型称为超类，新定义的类型称为子类。子类是超类的一个子集，即“is subset of”,如研究生是学生的一个子集。 - 用E-R方法建立概念模型：
(1)选择局部应用:依据数据流图，将庞大的数据划分成一个个局部应用场景。
(2)逐一设计分E-R图:依据局部应用，设计分E-R图。现实生活中许多事物，作为实体还是属性没有明确的界定，这需要根据具体情况而定，一般遵循以下两条准则:属性不可再分，即属性不再具有需要描述的性质，不能有属性的属性属性不能与其他实体发生联系，联系是实体与实体间的联系。
(3)E-R图合并: 多个分E-R图合并
合并的目的是为了消除分E-R图之间存在的冲突和信息几余，会产生如下冲突:属性冲突:同一属性可能会存在不同的分E-R图，由于设计人员不同或是出发点不同，属性的类型、取值范围及数据单位可能会不一致。命名冲突:相同意义的属性，在不同分E-R图上有着不同的命名，或者是不同意义的属性有着相同的名称。同一实体在不同的分E-R图中有不同的属性，同一个对象在分E-R图中被抽象为实体结构冲突:或属性。 - E-R图合并时的优化：
(1)实体类型的合并:两个具有1:1 联系或1:联系的实体，可以予以合并，使实体个数减少有利于减少将来数据库操作过程中的连接开销
(2)几余属性的消除:一般在各分E-R 图中的属性是不存在余的，但合并后就可能出现几余因为合并后的E-R 图中的实体继承了合并前该实体在分E-R 图中的全部属性，属性间就可能存在几余，即某一属性可以由其他属性确定。
(3)几余联系的消除:在分E-R 图合并过程中，可能会出现实体联系的环状结构，即某一实体A另一实体B 间有直接联系，同时A 又通过其他实体与实体B 发生间接联系，通常直接联系可以通过间接联系所表达，可消除直接联系。
11.4 逻辑结构设计
- 逻辑结构设计的主要任务:确定数据模型、将E-R图转换为指定的数据模型、确定完整性约束、确定用户视图。
- E-R图转换为关系模式：
1.实体向关系模式的转换:将E-R 图中的实体逐一转换成为一个关系模式实体名对应关系模式的名称，实体的属性转换为关系模式的属性，实体标识符就是关系的码。
2.联系向关系模式的转换：
(1)一对一联系的转换。通常一对一联系不需要将其转换为一个独立的关系模式，只需要将联系归并到关联的两个实体的任一方，给待归并的一方实体属性集中增加另一方实体的码和该联系的属性即可，归并后的实体码保持不变。
(2)一对多联系的转换。通常一对多联系也不需要将其转换为一个独立的关系模式，只需要将联系归并到关联的两个实体的多方，给待归并的多方实体属性集中增加一方实体的码和该联系的属性即可，归并后的多方实体码保持不变。
(3)多对多联系的转换。多对多联系只能转换成一个独立的关系模式，关系模式的名称取联系的名称，关系模式的属性取该联系所关联的两个多方实体的码及联系的属性，关系的码是多方实体的码构成的属性组。 - 由E-R图转换得来的初始关系模式并不完全符合要求，还会有数据几余或更新异常存在，需要经过进一步的规范化处理，步骤如下:
(1)根据语义确定各关系模式的数据依赖
(2)根据数据依赖确定关系模式的范式
(3)如果关系模式不符合要求，要根据关系模式的分解算法进行分解，达到规定范式级别(4)关系模式的评价及修正。根据处理要求，可能还需要增加部分几余以满足处理要求，这就需要做部分关系模式的处理，分解、合并或增加几余属性，提高存储效率和处理效率。 - 确定完整性约束:根据规范化理论确定了关系模式之后，还要对关系模式加以约束包括数据项的约束、表级约束及表间约束等
- 确定用户视图:确定了整个系统的关系模式之后，还要根据数据流图及用户信息建立视图模式提高数据的安全性和独立性：
(1)根据数据流图确定处理过程使用的视图。
(2)根据用户类型确定不同用户使用的视图。
11.5 物理结构设计
- 数据库在物理设备上的存储结构与存取方法称为数据库的物理结构，它依赖于给定的计算机系统。为一个给定的逻辑数据模型设计个最适合应用要求的物理结构的过程，就是数据库的物理设计。
- 数据库物理设计的目标：
（1）使设计出的物理数据库占用较少的存储空间。
（2）对数据库的操作具有尽可能高的速度。 - 物理设计的步骤：
1.确定数据分布:从企业计算机应用环境出发，需要确定数据是集中管理还是分布式管理，但目前企业内部网及因特网的应用越来越广泛，大都采用分布式管理。对于数据如何分布需要从以下几个方面考虑：
(1)根据不同应用分布数据。
(2)根据处理要求确定数据的分布。
(3)对数据的分布存储必然会导致数据的逻辑结构的变化，要对关系模式做新的调整，回到数 据库逻辑设计阶段做必要的修改。
2.确定数据的存储结构:存储结构具体指数据文件中记录之间的物理结构。在文件中，数据是以记录为单位存储的，可以采用顺序存储、哈希存储、堆存储和B + 树存储等方式。为提高数据的访问速度，通常会采用索引技术。
3.确定数据的访问方式:数据的访问方式是由其存储结构所决定的，采用什么样的存储结构，就使用什么样的访问方式。数据库物理结构主要由存储记录格式、记录在物理设备上的安排及访问路径(存取方法)等构成包括记录的组成、数据项的类型、长度和数据项间的联系，以及逻辑记录：
1)存储记录结构设计:到存储记录的映射。
2)存储记录布局:就是确定数据的存放位置。存储记录作为一个整体，如何分布在物理区域上是数据库物理结构设计的重要环节。采用聚簇功能可以大大提高按聚簇码进行查询的效率。建立聚簇索引的原则如下:
(1)聚簇码的值相对稳定，没有或很少需要进行修改。
(2)表主要用于查询，并且通过聚簇码进行访问或连接是该表的主要应用。
(3)对应每个聚簇码值的平均元组数既不太多，也不太少。
3)存取方法的设计:是为存储在物理设备 (通常是外存储器)上的数据提供存储和检索的能力是快速存取数据库中数据的技术。存取方法包括存储结构和检索机制两部分。其中:存储结构限定了可能访问的路径和存储记录:检索机制定义每个应用的访问路径。在数据库中建立存取路径最普遍的方法是建立索引。确定索引的一般顺序如下:
（1）首先可确定关系的存储结构，即记录的存放是无序的，还是按某属性(或属性组)聚簇存放。
（2）确定不宜建立索引的属性或表。
（3）确定宜建立索引的属性。
11.6 实施阶段
- 根据逻辑和物理设计的结果，在计算机上建立起实际的数据库结构，数据加载(或称装入)进行试运行和评价的过程，叫作数据库的实施(或称实现)。
- 1)建立实际的数据库结构: 用DBMS 提供的数据定义语言(DDL)编写描述逻辑设计和物理设计结果的程序(一般称为数据库脚本程序)，经计算机编译处理和执行后，就生成了实际的数据库结构。应包含以下内容：
（1）数据库模式与子模式以及数据库空间等的描述；
（2）数据库完整性描述；
（3）数据库安全性描述；
（4）数据库物理存储参数描述。 - 2)数据加载:数据库应用程序的设计应该与数据库设计同时进行。一般地，应用程序的设计应该包括数据库加载程序的设计。
- 3)数据库试运行和评价:一般将数据库的试运行和评价结合起来的目的是测试应用程序的功能测试数据库的运行效率是否达到设计目标，是否为用户所容忍。
11.7 运行与维护
11.7.1 数据库系统的运行
- 数据库系统的运行计划主要包括三个方面: 数据库系统运行策略、数据库系统监控对象和监控方式以及数据库系统管理计划。
- 制定运行策略:要考虑正常运行策略和非正常运行策略两个方面。
(1)正常运行策略是指在正常运行状态下的数据库执行策略，包括：
系统运行对物理环境的要求；
系统运行对人员的要求;
数据库的安全性策略;
数据库备份和恢复策略
(2)非正常运行策略是指在特殊时期的数据库运行策略，包括：
突发事件的应对策略;
高负载状态的应对策略 - 确定数据库系统监控对象和监控方式
（1）依照监控对象的不同，系数据库系统监控的对象分别是系统性能系统故障和系统安全00统监控分为性能监控、故障监控、安全监控。
● 性能监控是掌握系统运行性能的手段。
● 性能监控应当从资源占用率、事务响应时间、事务量死锁、用户量等方面实现。
● 故障监控是保障数据库系统正常运行的手段。从数据库系统故障的类型入手，监控事务故障系统故障和介质故障，出现需要管理员干预的故障时及时恢复。
● 安全监控是对破坏数据库安全事件的监控，包括入侵监控、用户访问监控、病毒监控等。
（2）数据库系统的监控方式分为系统监控和应用程序监控系统。
● 监控是通过DBMS 提供的监控功能，进行参数设定后，由系统自动监控。
● 应用程序监控需要管理人员根据具体情况编制应用程序进行系统监控，是对DBMS监控功能的补充。 - 需要注意的是，系统日志是监控中的主要依据。日志文件详细记录了系统运行中的各种信息管理员可以从日志文件中了解系统运行状态和事件，以此为据发现系统运行中的问题。
- 1.监控数据的收集与分析:系统监控能够动态地掌握数据库的运行状态，监控就是对系统运行信息的记录，称为监控数据，监控数据是发现系统问题和改进系统性能的依据。依照监控的类型，监控数据分为性能监控数据、故障监控数据和安全监控数据
- 2.稳定运行中的业务持续性:业务持续性是指一个组织的主要业务流程、营运服务，以及IT 服务能够得到连续性处理。业务持续性需要从以下方面考虑：
(1)界定哪些是不允许停工的持续性业务，哪些是允许有一定时间的停工期的弹性业务；
(2)要有业务持续性的技术体系，如高效率服务器、存储系统、网络、DBMS;
(3)检测和响应管理，包括紧急决策制定、准备工作、最初的紧急响应和系统恢复等所有详细程序;
(4)要有保障业务持续性的设备
(5)界定相关人员的职务和权责包括各类技术人员(程序员、管理员和操作员》，执行经理(紧急事件决策者)，设备管理人员(电力、供冷、电缆)，人力资源 (人事问题和需求)，业务实体(业务流程)，以及外部组织(外包机构、电信、供应商等》。
11.7.2 数据库系统的维护
- 数据库维护：在数据库运行阶段，对数据库的维护主要由DBA 完成：
1)对数据库性能的监测和改善;
2)数据库的备份及故障恢复;
3)数据库重组和重构:数据库的重组是指在不改变数据库逻辑和物理结构的情况下，去除数据库存储文件中的废弃空间以及碎片空间中的指针链，使数据库记录在物理上紧连。 - 在数据库系统的运行过程中，可能会由于某些原因需要修改数据库的结构，称为数据库重构.对于如下情况，数据库重组和重构的处理方法为：
(1)修改属性列名或数据类型:由于修改表中的属性列名或数据类型，必须修改使用该表的应用程序，所以应尽量减少这样的修改。
(2)增加和删除属性:只修改使用该列的应用程序。
(3)约束的修改:如果是DBMS 支持的约束，如主码约束、参照完整性约束和检查约束，一般不需要修改应用程序，复杂的约束可以通过修改触发器程序实现。
(4)表的分解:可以通过建立与分解前表同名的视图来避免修改应用程序。但这样会相应引起性能的下降，如果分解是为了提高性能，则需要修改应用程序，只访问分解后的一个表。
(5)表的合并:通常也是为了提高系统性能，可以通过建立两个与原表同名的视图来避免应用程序的修改。 - 在数据库重构过程中引入或修改视图，可能会影响数据的安全性，因此必须对视图进行评价和验证，保证不会因为数据库的重构而引起数据的泄密。
- 文档必须与系统保持一致性，否则会造成人为的困难和错误。修改历史必须在文档中体现。
11.7.3 数据库系统的管理
- 数据字典的管理:当用户使用DDL 语言定义数据库对象或某些DML语言进行表扩展等操作时系统会自动修改数据字典中的元数据。数据字典是只读的，可以利用DBMS 提供相应的数据字典访问命令，访问数据字典的内容。
- 数据完整性维护和管理: 是通过DBMS 系统提供的完整性约束机制和应用程序来实现，以保证运行过程中数据的正确性。在系统运行过程中对数据完整性的维护和管理采用两种方式：
(1)对于DBMS 管理的约束，通过修改数据库的定义，如增加或删除实体完整性约束、参照完整性约束、检查约束来实现。
(2)对于应用程序实现的复杂的完整性约束，通过分析和修改应用程序，通常是采用触发器程序来实现。 - 数据库的存储管理:通过以下手段进行存储管理，可有效地提高系统性能：
（1）索引文件和数据文件分开存储，事务日志文件存储在高速设备上。
（2）适时修改数据文件和索引文件的页面大小。
（3）定期对数据进行排序。
（4）增加必要的索引项。除进行数据库的存储管理之外，也可以通过增加计算机内存、引入高速存储设备等方式来提高系统的访问效率。 - 备份和恢复:备份计划的制订和实施，有以下建议:
(1)根据数据变更情况，设定合理的备份周期和备份时间，最好是在业务量最小的时段进行备份。
(2)事务日志文件保存在最稳定的存储设备上。
(3)定期在事务日志文件中加入检查点(Checkpoint)。 - 并发控制与死锁管理:管理员通过系统监控了或系统日志，找出频繁产生死锁的事务，分析死锁的原因，修改事务程序来减少死锁，提高系统的井发性。
- 数据安全性管理:实际运行中的数据库系统可以从以下几个方面实现安全性管理：
（1）建立网络级安全，主要是防火墙的设置。
（2）操作系统级安全，进行登录用户的管理。
（3）DBMS级安全，对访问数据库的用户进行密码验证。
（4）角色和用户的授权管理。
（5）建立视图和存储过程加强安全性。
（6）使用审计功能，为追纠非法入侵者法律责任提供证据，发现安全漏洞。
11.7.4 性能调整
- SQL语句的编码校验：
● 尽可能的减少多表查询或建立物化视图
● 以不相关子查询代替相关子查询。
● 只检索需要的列。
● 用带IN的条件子句等价替换OR子句。
● 经常提交commit，以尽早释放锁。 - 表设计的评价：
● 如果频繁的对两个相关表进行连接操作，考虑将其合并；
● 如果频繁的访问表中的某一部分字段，考虑分解表，将该部分单独作为一个表;
● 对于很少更新的表，引入物化视图。 - 索引维护和改进：
● 如果查询时瓶颈则在关系上建立适当的索引，通常，在作为查询条件的属性上建立索引可以提高查询效率;
● 如果更新是瓶颈，考虑删除某些索引;
● 选择适当的索引类型，如果经常使用范围查询，则B树索引比散列索引更高效;
● 将有利于大多数数据查询和更新的索引设为聚簇索引。 - 设备增强:在数据库系统运行过程中，如果经过各种调整之后，仍不能满足性能要求，则应当考虑增强系统设备。例如，引入高速的计算机、增加系统内存、使用高速的网络设备和高速的存储设备等方面。