节选：第一章 我看DB2设计与优化 1

第1章

我看DB2设计与优化

 

 

 

 

数据库是一种生命体，随着周围环境的变化，自身也在迅速地演变，就如同现代社会人们快速的生活节奏一样——吃快餐、拍快照、喝速溶咖啡、做速成培训，连感冒药都要吃速效的。

快速的影响无处不在，DBA们昨日还在问：“你的数据库容量有多大？”今天，话题已经成了：“你的数据库速度有多快？”

数据库市场纷繁多样，有的数据库性能稳定，有的则频频宕机；有的数据库效率非凡，有的则“不堪重负”。这种巨大的反差迫使数据库技术人员停下匆匆的脚步，思考一个问题：高质量的数据库是怎样炼成的？本章就从这个话题开始。

 

 

 

 

1.1  数据库设计与性能优化

随着数据库应用的日益复杂，人们开始使用一种结构化的方法来设计数据库，这种数据库设计方法由一系列阶段组成。而因为数据库开发模型的不同，这些阶段出现的次数也有所不同。在瀑布式模型中，这些阶段出现一次；在迭代式模型中，这些阶段会出现多次。如图1-1所示，本书建议的数据库设计过程可以按照下面的步骤来做。

图1-1  数据库设计的一系列阶段

首先需要以用户的眼光来看待现实世界的业务，做到真正理解客户的业务需求，这就是通常所说的收集需求阶段；随后业务人员根据业务需求设计概念模型，并且该模型需要和现实世界相对应，这就是概念模型设计阶段；接着进入逻辑结构设计阶段，在这个阶段数据库设计人员使用业务人员的概念设计结果，将其转换为具体数据库的对象结构，例如表、视图等；然后是完成逻辑结构设计后的物理结构设计阶段，需要为逻辑数据模型选取一个最适合逻辑结果的物理环境，例如需要做表空间设计、缓冲池定义等，需要确定I/O、CPU、内存硬件等；最后是实施、运行和维护阶段，这个阶段会将前面物理设计的结果部署在目标机器上进行开发和测试，经过验证后正式上线运行，上线后还需要进行日常的监控和维护工作。

实际上DB2 性能优化工作贯穿于上述结构化设计的各个阶段中，所以需要用系统化的观点来对待性能问题。从理论上来看，数据库设计的好坏直接关系到数据库运行的性能，所以在每个阶段都需要对性能需求做全方位的分析和规划，否则，等到了运行阶段真正遭遇性能问题再考虑，就为时已晚。理论上如此，而从我们为金融、电信行业客户做数据库咨询的实践来看，也证明了上述判断。现实中数据库开发团队最容易忽视的就是数据库的性能需求，这种前期对性能需求的忽视直接导致了问题定位难和解决难。

为了避免上述问题，我们认为：数据库的性能优化时机虽然主要发生在运行过程中，但数据库的初始设计对性能有着重大的影响，因此本章在介绍我们的优化技术之前，先谈一下我们从开发和咨询实践中总结出来的一个数据库的生命周期各个阶段中需要注意的性能相关事项。

1.1.1  收集需求

收集需求是整个结构化设计过程的基础，也是最困难、最耗费时间的第一步。这个阶段的目标是准确了解用户的需求。首先调查组织机构情况、各部门的业务活动情况，协助用户明确对新系统的各种要求，确定新系统的边界。随后调查、收集与分析用户在数据管理中的信息要求、处理要求，安全性及完整性要求，最终得到数据流图表达的数据和处理过程的关系。从方法来看，通常采取自上而下的结构化分析方法，即从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图描述。

除了上述功能需求外，性能需求也应该在这个阶段被定义。通常包括有并发要求的需求、有响应时间要求的需求；数据库容量的需求，例如I/O吞吐能力；系统用户容量的需求；系统运行时间的需求，例如7×24小时不间断运行，或者可连续运行一周或一月。

在真实设计实践中，如何才能获得真正有效的性能需求呢？这需要从以下三个方面加以考虑。

1．性能指标必须量化

指标量化应该不难理解，但是有时候有了数字未必就不模糊。例如常见的一种需求是“系统需要支持5000用户”，或者“最大在线用户数为8000”。这些有数字的需求仍然不够明确，因为还需要考虑区分系统中不同业务模块的负载，以及区分在线用户和并发用户的区别。为便于理解，我们来看一个性能需求的例子，以获得感性的认识。

某个金融行业交易系统的需求如下：

    系统总容量达到日委托9000万笔，成交9000万笔。

    系统处理速度每秒7300笔，峰值处理能力达到每秒10000笔。

    实际股东账号数3000万。

这个例子中已经包括如下三个明确的性能需求。

    最佳并发用户数需求：每秒7300笔。

    最大并发用户数需求：峰值处理能力达到每秒10000笔。

    基础数据容量：实际股东账号数3000万。

2．有实际操作意义

一般来说，性能需求要么由集成商提出，要么由客户提出。对于第一种情况，性能需求不能简单地来源于项目组成员、项目经理或者测试工程师的估计或者猜测，要保证性能需求的提出是有根据的，所使用的数据和计算公式是有出处的。通常电信、银行、保险、证券及一些其他运营商级系统的客户属于第二种情况，这个时候要保证需求合理，有现实意义，要让客户明白性能是有成本的。

3．通过沟通，确保相关人员对性能需求理解的一致性

相关人员对性能需求的理解不一致是由于参考对象的不同导致的。例如有的人员根据客户以往的业务情况，来分析客户的业务量；有的人员参考其他规模类似客户的需求；有的人员参考其他同行企业的公布出来的数据；有的人员参考类似行业的应用的需求。如果相关人员不能对性能需求达成一致，那么会影响后面的验收测试。

1.1.2  设计概念模型

概念模型是按用户的观点来对数据和信息建模，通常用实体-关系图（E-R图）表示。通过对用户需求进行综合、归纳与抽象，形成一个不依赖于具体数据库管理系统（DBMS）的概念数据模型，但可以转换为计算机上某一DBMS支持的特定数据模型。概念模型具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。除此之外，概念模型清晰、易于理解，是用户与业务人员之间进行交流的语言。

 定义实体

实体成员都有一个共同的特征和属性集，这可以从收集需求阶段收集的基本数据资料表中直接或间接标识出大部分实体。例如，根据名字表中表示物的术语以及以“代码”结尾的术语，如客户代码、代理商代码、产品代码等，将其名词部分代表的实体标识出来，从而找出潜在的实体，形成实体表。

 定义关系

关系模型中只允许二元关系，n元关系必须定义为n个二元关系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出关系名和说明。这里的关系类型需要明确，是标识关系还是非标识关系？如果是非标识关系，是强制的还是非强制？如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。

 定义码

通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识候选码属性，以便唯一识别每个实体的实例，再从候选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一时刻有一个以上的值。

 

 定义属性

从基本数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码。以此得到了至少符合关系理论第三范式的改进的全属性视图。

 定义其他对象和规则

定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25714482/viewspace-710018/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25714482/viewspace-710018/