大型项目中如何开展数据库设计工作
本文基于我在上海证券交易所第三代监察系统项目的实践描述如何在大型项目中开展数据库设计工作，本文避免过多的描述具体实现的技术细节，侧重于从软件工程角度描述数据库设计的整体流程以及项目各个阶段的工作侧重点。
1. 开展数据库设计工作所需条件
对于基于数据信息处理的大型行业解决方案项目来说，数据库设计是整个系统设计工作中最为重要、最为基础的环节之一，具备什么样的条件才能顺利开展数据库设计工作呢？
本章主要从资源配置角度描述如何确保数据库设计工作能够顺利进行。
1.1. 独立的数据库设计小组
对于一个软件合同额数千万，前后参与项目的人员数量数百人的大型软件工程项目来说，项目管理的重要程度要远比几十个人月、几个人完成的小项目要重要的多，而成功进行项目管理的基础之一便是完备的组织机构。
对于一个基于数据处理的大型核心业务应用系统来说，数据库设计是整个应用系统实现的基础，可以说其设计质量的好坏直接影响到整个项目的成败，应当有专门的组织机构负责其设计。
教训：在3GSS 项目中数据库规划组成立时间过晚，只是在开发工作过半的时候才组建起来，在这之前我个人也是在需求工作、架构工作都已基本结束的时间点进入项目组，这对于顺利的进行数据库设计造成了很大的困难。
1.1.1 职责
数据库设计小组的职责主要体现在以下方面：
● 参与项目总体架构设计，对于涉及到数据库应用的架构问题主要
负责。
● 保证在项目进行过程中数据库设计的稳定，为各个应用子系统的
开发提供稳定的数据平台，从而保证项目计划的正常执行。
● 在数据库性能优化工作起到主导作用，并对数据库性能优化的结
果负责。
● 对于数据库版本的管理和发布以及变更负责。
● 做好需求与开发之间的桥梁。
1.1.2 在项目组中的地位和作用
数据库设计小组在整个项目组的组织机构配置中应当与架构组、需求组、测试组等平级，直接对项目组PM 、PSM 负责，因为数据库设计
的工作需要各个小组的积极配合才能够顺利完成，所以项目小组之间的沟通协调工作显得尤其重要，如果不能做到从组织机构上将数据库设计小组提到项目组中一个相对较高的位置上，那么在一个大型项目组中，沟通协调工作将会很难进行。
教训：3GSS 项目中，数据库规划组在项目进入到编码阶段之前并没有单独独立出来，只是隶属于核心预警系统组，因此在与其他组的沟
通协调方面增加了一定的困难。
1.2. 如何组建数据库设计小组
描述数据库设计小组的组建过程和资源角色配置。
1.2.1. 角色配置
一个数据库设计小组主要应当包括以下角色：
1.2.2. 资源使用
可以这样说，数据库设计工作没有太多的开发工作量，但是对人员素质的要求很高，因此数据库设计小组的组建要按照“外科手术”的标准进行，贵在精而不在多：
1.3. 硬件资源
数据库设计工作顺利开展的一个重要条件是拥有既定硬件方案所规定型号的主机以及配套的存储设备，并且网络通讯能力要和真实上线条件一致，总之数据库设计工作需要一整套真实上线环境下的硬件设备，这不仅仅是数据库设计的需要，同时也是整个项目开发工作的一个重要基础条件，因为没有经过真实上线环境的检验，谁也不敢说我们用PC 机和低档服务器开发出来的系统能否在上线的时候稳定运行。必需要保证在编码工作开始前准备好硬件方案所规定型号的主机以及配套的存储设备。
教训：3GSS 项目在7月进入开发编码阶段，而硬件环境直到9月份才到位，在这之前我们只能使用PC 机来作数据库服务器，根本没有
办法模拟大数据量存储，致使数据库物理设计的优化调整只能延后，如果我们能够在这宝贵的2个月时间内仔细验证、优化我们的数据库物理设计方案，我们完全可以规避很多实现风险，也不会造成后来开发阶段数据库存储性能的瓶颈问题。
1.4. 设计工具
工欲善其事，必先利其器，现在有很多数据库设计工具可供选择，3GSS 项目选择Sybase 公司的PowerDesigner9.5作为设计工具，我认为这个工具主要有以下好处：
1、 可以方便地进行数据库的物理设计、逻辑设计
2、 有很强的文档生成能力，可以定制生成各种数据库设计文档
3、 拥有数据库反向工程能力
2. 数据库设计工作的流程与方法
首先提出一个问题：在一个项目中数据库设计工作什么时候开始启动？什么时候结束？
我认为，从需求工作启动的那一刻起，数据库设计工作就正式开始了，直到项目交付完毕、正式上线运行方才告一段落！其中工作重心主要放在需求阶段、架构设计阶段、详细设计阶段。
2.1. 需求阶段
数据库的设计，特别是大型核心业务应用系统的数据库设计，远非建几张数据库表那么简单，在数据库设计工作的初时阶段，就其本质来讲，是对客户核心业务的一次数据建模，出色完成该阶段数据库设计任务的关键条件是对用户核心业务的业务模式、处理流程、数据构成充分理解，可以说在这一阶段的数据库设计工作中，并没有涉及多少数据库技术方面的工作，更多的工作集中在对于客户核心业务的理解和学习上，为在后续阶段对数据库进行逻辑设计打好基础。而在这一方面，无疑需求组的同事是处于主导地位的，我们必须和需求组的同事合作，获取它们的帮助，同时，我们的参与也会促进需求组的同事进一步和客户沟通、明确很多业务方面的细节问题，从某种意义上讲也是间接推动了客户需求的细化工作。
数据库设计小组需要在需求阶段投入最大的精力和资源。
这一阶段数据库设计小组（以数据建模员为主）主要从事以下方面的工作：
● 对于客户需求的分析、理解、细化
有人可能会说：这是需求组来作的事，干吗让我来做？
这种观点是不正确的，因为需求人员的工作是站在偏业务的方面与客户进行沟通，而数据库设计人员是站在设计实现的角度去作，可以说数据库设计人员对于客户的数据需求比需求组的同事更加敏锐。 这段时间的工作是数据库设计工作中最困难也是最重要的工作，因为对于客户业务需求的理解是整个数据库设计工作的基础，磨刀不误砍柴工，在需求阶段将客户业务需求理解透彻将会在后续的设计工作中节省大量的时间。
● 数据概念模型建模
在对客户的需求用例有了比较透彻的理解之后，就应当着手针对需求用例进行数据抽象，得出初步的数据流图、E_R模型、数据字典。 主要应当考虑以下方面的内容：
1、 创建数据字典和E_R模型图表。E_R模型图表和数据字典可以
让任何了解数据库的人都明确如何从数据库中获得数据。ER 图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对后续开发SQL 来说这是完全必要的。
2、 确定数据依赖，识别数据实体之间的关系，对数据实体间的关系
作规范化处理。数据库实体之间关系规范化的范式有很多专门的技术文档可供参考，这里不加详细描述，但是需要指出一点，在实际项目实践过程中，并不一定完全按照范式的要求实现就是最好的设计，需要根据实际情况适当的作出一定的逆范式设计。例如，一个股票订单信息的数据实体，包括投资者帐号、投资者名称等投资人信息；订单号、交易价格、交易数量等交易信息；按照标准的范式设计应当将该数据模型划分为两个实体，既主从关系的投资人实体和交易信息实体，使用订单号关联，但是实际情况是，每日的订单信息数量达到了5000万笔，而投资人信息也将达到8000万条，如果仍然按照范式设计，那么在查询订单信息时将会人为的在两张超大表之间进行关联，那将严重影响查询速度，所以只能反规范化，将投资人信息和交易信息融合在一个数据实体中。
3、 对数据概念模型进行优化调整。针对数据库概念模型中的不足和
缺陷，要及时作出修正和调整，在这期间要与需求组的同事配合，充分和客户沟通，数据库设计的调整在概念模型上进行调整代价是最小的。
4、 制定数据对象命名规范。对于一个大型行业业务解决方案来说，
需要建模的数据项可能会有成千上万个，如果没有一个统一的命名规范将会给后续的设计开发工作造成不必要的麻烦。这一工作一般由数据库设计小组组长完成，完成后要经过项目组一级的评审。
经验：在概念模型的建立过程中，对于那些有着明确数据接口格式定义的外部输入数据，建模工作相对容易一些，对于用户需求用例中数据的流转过程建模，从而得出数据流图相对来说要困难一些，数据建模员切忌只看输入输出，不看数据流转、处理过程。数据的流转处理过程是建立数据库概念模型的重要依据，我们只有搞清楚了数据是如何流转的，如何被使用的才能够设计出尽可能贴近客户业务需求的数据模型。
● 做好需求与开发之间的桥梁。
为什么呢？因为数据库作为整个应用系统的运行基础，可以说整个系统的设计工作都将或多或少的与数据库系统的设计工作产生交叉，而数据库设计人员出于完成数据库逻辑设计的目的，必须对整个项目的需求用例以及业务背景有着全面的了解和掌握，可以这么说，在整个项目组中，只有数据库设计人员才能站在开发设计角度掌握整个系统完整的需求细节，可以说数据库设计人员在以后的设计、开发阶段是一个宝贵的资源，数据库设计人员应当对应用系统的设计人员提供咨询上的帮助，并且对应用系统设计进行评审，确定其设计是否与数据库设计相契合。
2.2. 系统架构阶段
在系统架构阶段，数据库设计小组的主要工作是：
● 确定数据库服务器所使用的硬件配置方案
这项工作需要数据库设计小组和系统集成组的同事合作完成，数据库设计小组主要从客户对于数据库的性能指标入手，得出对于数据库服务器的硬件要求，系统集成组的同事负责具体的硬件选型。
在确定硬件配置方案的时候，数据库设计小组主要从以下几个方面入手：
1、 满足数据的存储容量需求。以需求阶段所得出的数据库概念模型
和数据字典为基础，按照客户给出的未来一段时间内业务数据的增长速度预估出数据存储空间，在这里应当注意：需要为索引预留出存储空间，一般经验性的做法，索引的存储空间与数据存储空间按照1：1来预估。
2、 满足数据库交易处理能力的需求。我们要考虑高峰时的处理器的
能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。如果要保持快速的响应能力，应当为CPU 保留20%至40%的富余量。要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素:
交易的复杂性
交易频率
数据读/写比例
并发连接数目
并发交易数目
数据库最大表的大小
性能度量的目标
教训：在3GSS 项目架构设计阶段硬件方案选型的时候，没有考虑到会在每天的交易时间内在数据库服务器上并发运行数据预处理存储过程，只为数据库服务器配置了4CPU ，结果导致在项目后期出现了严重的数据库服务器处理性能不足问题。
● 规划数据库的物理设计
数据库最终是要存储在物理设备上的。为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构（存储结构与存取方法）的过程，就是数据库的物理设计。
物理结构依赖于给定的DBMS 和和硬件系统，因此设计人员必须充分了解所用DBMS 的内部特征，特别是存储结构和存取方法；充分了解应用环境，特别是应用的处理频率和响应时间要求；并充分了解外存设备的特性。
数据库的物理设计通常分为两步：
第一步：确定数据库的物理结构
在这里数据库设计小组主要从事以下方面的工作：
1、 确定数据的存储结构。确定数据库存储结构时要综合考虑存取时
间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，例如消除一切冗余数据虽然能够节约存储空间，但往往会导致检索代价的增加，因此必须进行权衡，选择一个折中方案。
2、 设计数据的存取路径。在关系数据库中，选择存取路径主要是指
确定如何建立索引。例如，应把哪些域作为次码建立次索引，建立单码索引还是组合索引，建立多少个为合适，是否建立聚集索引等。
3、 确定数据的存放位置。为了提高系统性能，数据应该根据应用情
况将易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。例如，目前许多计算机都有多个磁盘，因此进行物理设计时可以考虑将表和索引分别放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别在工作，因而可以保证物理读写速度比较快。也可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。此外还可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
4、 确定系统配置。DBMS 产品一般都提供了一些存储分配参数，供
设计人员和DBA 对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值以改善系统的性能。通常情况下，这些配置变量包括：同时使用数据库的用户数，同时打开的数据库对象数，使用的缓冲区长度、个数，时间片大小、数据库的大小，装填因子，锁的数目等等，这些参数值影响存取时间和存储空间的分配，在物理设计时就要根据应用环境确定这些参数值，以使系统性能最优。在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
第二步：对数据库物理结构优化
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的DBMS ，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。
● 完成数据库概念模型到逻辑模型的转换
逻辑结构设计的任务：就是把概念结构设计阶段设计好的基本E-R 图转换为与选用DBMS 产品所支持的数据模型相符合的逻辑结构。因此设计逻辑结构首先应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS 。设计逻辑结构时一般要分两步进行：
1、 将概念结构转换为特定DBMS 支持下的数据模型。
2、 数据模型进行优化。
这些工作基本上都可以使用PowerDesigner 设计工具开完成。
2.3. 详细设计阶段
有一点是要明确的，就是数据库设计要走在各个子系统应用程序设计的前面，原因是明显的，因为各个子系统需要在数据库支撑环境已经明确的情况下才可以开展设计、开发工作。
数据库设计小组这一阶段的主要工作有两点：
1、 支持各个子系统应用程序的设计。特别是查询、报表模块的设计，
这是与数据库关联最为密切的模块，可以说没有数据库的良好支持，根本不可能设计出性能优良的查询、报表程序。
2、 对数据库模型进行优化调整。在各个子系统设计的深入过程中我
们会不断发现原有数据库模型设计上的一些不足，主要集中在以下方面：
库表结构设计不合理。
不能够提供所需要的数据。
数据库表的主键、索引设置不合理。
数据库的物理存储空间分配不足。
2.4. 编码阶段
如果之前阶段的工作顺利完成，那么进入到编码阶段，可以说数据库设计工作已经完成大半了，编码阶段数据库设计小组的工作重心应当转移到性能验证、性能测试工作上。
此外，在编码阶段数据库设计小组应当对于开发人员的PL/SQL编程提供技术支持和代码检查，以保证PL/SQL编码的质量。
2.5. 测试阶段
随着开发工作的逐步推进，测试组的同事会对各个阶段获取的系统版本进行系统测试，数据库设计小组要做好数据库的版本控制工作，全力配合测试组的同事进行系统测试。
另外，数据库设计小组还应当积极协助测试组的同事准备数据库性能验证测试的测试案例、测试数据。
2.6. 系统交付阶段
如果能够顺利进行到系统最终交付阶段，也可以说我们的数据库设计工作已经功德圆满了。
这一阶段要做好数据库设计的最终封版工作，对数据库设计的各种工作成果物进行整理，对数据库设计个个阶段产生的设计文档进行归纳总结。
3. 数据库设计工作中的版本控制
由于大型项目的开发周期很长，出于配置管理的需要，在大型项目的开发阶段，需要设置若干个里程碑，在每个里程碑都需要对软件系统进行封版，形成配置基线，这些配置基线对于开发工作的延承和最终系统的按时交付有着重要意义，与此相对应，作为应用系统基础的数据库也需要在相应的里程碑得到对应的设计版本，数据库设计的版本控制与配置管理是整个项目组版本控制与配置管理的一部分，但是与应用系统开发过程的版本控制与配置管理又有所区别，我们在3GSS 项目的实践中摸索出了一套数据库设计版本控制的工作流程与方法。
3.1. 版本控制
数据库设计的工作成果主要包括数据库建库脚本、初始化数据、PL/SQL脚本等内容，其特点在于数据库设计的版本与应用系统的开发版本之间存在很强的相互依赖性，一个开发版本通常情况下只能在
与该开发版本对应的数据库设计基础之上才能够正常运行，这是由于在项目开发工作的不断推进过程中，数据库设计工作也在不断的细化、完善。这种依赖性在测试组的同事针对某一开发版本进行测试的时候表现的最为明显。
教训：在3GSS 开发工作的初始阶段，数据库设计的版本控制没有形成规范化，与开发版本的控制脱节，因此曾经一度造成数据库版本的混乱，测试组在进行系统测试的时候取得开发版本后不知道应该使用什么版本的数据库。
经验：在后续的开发工作中，数据库设计的版本控制严格跟随应用系统开发版本的版本控制进程进行，在应用系统发布每一个开发版本的时候，我们都会发布一个与之对应的数据库设计版本，并且在交付测试组进行系统测试前明确指出开发版本与数据库设计版本的对应关系，从而避免了开发版本与数据库设计版本的脱节问题，开发、测试工作也得以稳定、顺利的进行下去。
3.2. 配置管理
数据库设计的配置管理工作应当紧跟应用系统开发的阶段性封版工作，要与应用系统形成统一的配置基线。
数据库设计工作成果物的目录组织形式可以参照下图所示：
但是并不一定拘泥于此，只要能够清晰、简便的体现出数据库设计的各个配置基线，能够方便地获取各个时期各个时期的不同版本即可。 配置管理工具可以选用微软的SourceSafe 。
经验：在开发阶段，数据库的结构细微变动较为频繁，数据库的变动通过补丁方式维护数据库，在一个开发阶段结束，数据库版本稳定后，根据数据库的变动情况形成数据库设计的配置基线。
3.3. 变更流程
在项目的编码开发阶段，随着编码工作的逐渐深入，原有系统设计中的不足和一些没有考虑到的设计细节问题开始逐渐暴露出来，随之就要进行设计的调整，数据库设计也是如此。
但是数据库设计是整个应用系统运行的基础，对于数据库系统的设计调整将有可能影响到整个系统的正常运行，因此对于数据库设计的调整应当十分谨慎，在数据库设计的变更工作中应当注意以下方面：
● 数据库设计变更的要求只能由各个子系统的开发组长提出，并
且经过项目组开发负责人同意。
这样做是为了保证数据库设计的稳定性，因为在一个大型项目中，编码人员非常多，而且编码人员看待设计问题的方法和角度往往和系统设计人员、架构师的角度不同，有可能提出一些不切合实际的变更要求，因此就需要有人对变更要求进行评审和把关。
● 数据库设计小组在接到变更要求后绝对不可以随意变更数据库
设计，必须经过数据库设计小组组长评审通过后方可进行相应修改。
这样做同样是为了保证数据库设计的稳定性，避免设计工作的反复。如果数据库设计小组组长评审后认为不适宜修改应当立即和项目组开发负责人进行沟通协商，如果仍然没能达成一致就需要召开项目组级别的架构评审会议进行评审。
● 数据库设计的变更需要做好修改记录。
这样做是为了清楚地记录下整个数据库设计过程中所发生的设计变动过程，有了这份记录，我们在将来就可以很容易对数据库设计的依据进行回溯，有助于我们更好的理解数据库设计的历史延承。 ● 数据库设计变更完毕后一定要将变更结果通知项目组中所有涉
及到该项变更的开发小组组长。
在一个大型项目组中，由于开发小组很多，再加上沟通不畅，很容易造成这样一种结果：某张表已经作出了变更，但是某些开发小组并不知道，仍然依据老的表结构进行开发，这样就人为的制造了系统BUG 。因此务必要将数据库设计的变更结果传达到每一个相关的开发人员，而开发人员数量较多，因此我们只将变更结果传达到开发小组长，再由开发小组长传达到每一个开发人员。
教训：3GSS 项目中在开发阶段的初期，数据库设计调整之后，数据库设计小组作了版本控制，也做了修改记录，但是没有将变更结果通知到涉及该次变更的开发人员，结果造成了数据库版本已经升级而开发人员还在使用老版本的数据库设计进行开发的情况
经验：我们采取了变更后对开发小组组长进行邮件通知的做法，一定程度上避免了该问题，但是有一些开发小组组长对于邮件通知不敏感，没有将变更通知继续向组员传达，所以数据库设计小组就在每次发送变更通知邮件后再口头通知一遍各个开发小组组长。
● 每一次数据库设计变更后应当做好相应的版本控制和配置管理
工作。
● 发布每一次数据库设计的变更之前都应当对所发布的内容在专
用的数据库服务器上进行发布测试，以保证所发布设计的可用性。
● 开发用数据库服务器由数据库设计小组负责管理和维护，此外
任何人不得对数据库服务器作出任何变更。
开发用数据库服务器是系统开发过程中全项目组公用的开发环境，任何人对于数据库服务器的私自改变都将会影响到其他开发人员的正常开发，应当予以严厉禁止。
经验：破坏性最大的是对数据库表结构的私自变更，在3GSS 项目中，我们采取了设置不同数据库用户，分别授权的方法来规避该问题。具体做法是，设置管理员用户，赋予数据库DBA 权限，可以对数据库服务器作出任何变更，这个用户只有数据库设计小组相关成员拥有密码；设置开发用户，只赋予数据增删改查权限以及其他必要的权限，该用户供所有开发人员开发使用。
4. 数据库设计中的性能优化问题
说到数据库性能优化，在我接触到的同事中持以下两种观点的人居多：
● 性能优化太复杂了，根本无从下手！
● 不就是优化嘛，等开发完了找个高手过来优化一下就可以了！ 如果说持以上观点的只是普通开发人员还有可以挽回的余地，如果在一个大型的项目组中，负责数据库设计工作的负责人也持有以上观点，那么注定将会出现一个失败的数据库设计！
数据库性能优化并不是独立于数据库设计和实现之外，而是自始至终贯彻于数据库设计的工作之中，可以说从数据库设计工作启动的哪一刻起，我们就应当将性能优化作为我们的一个工作重点。也可以说数据库设计的过程就是一个数据库性能优化的过程。
性能优化也不是洪水猛兽，也是有一定的工作方法可循的，只要我们按照正确的方法来做，相信一定会顺利的完成，下面我们来着重谈一下性能优化这个话题。
4.1. 什么是数据库性能？
这个问题如果问100个人，可能会得到101种答案，例如：SQL 语句的执行时间长短、每秒钟能够插入数据库的记录条数、数据导入导出数据库的时间长短等等，这些答案都对，但是并不完全。
我认为，以技术的角度来看，数据库的性能就是以最少的时间获取所需要的数据的能力；以软件工程的角度来看，性能就是满足客户需求的能力。
许多人都喜欢说这么一句话：“没有最好，只有更好。”我很欣赏这句话，作工作需要这种积极向上的态度，但是这句话如果放在数据库性能优化这件事情上则不尽然，应当加上一个限制条件：“如果不计成本，那么数据库性能没有最好，只有更好。”
作软件，特别是象我们这种行业解决方案提供商，如何平衡质量（Quality ）、成本（Cost ）及交付（Delivery ）的关系，从而利益最大化是每一个软件从业人员都必须考虑的事情，从客户角度来讲，客户花钱让我们来做解决方案，是为了能够在实际应用中体现出该解决方案的价值，能够满足其特定的应用需求，因此我们只要满足了客户需求即可，性能优化不需要画蛇添足！
4.2. 什么时间优化？
有很多人认为数据库性能优化在编码结束、系统稳定后再进行，理由是：应当首先保证项目的开发进度和交付能力，优化工作必须等到开发结束并且系统已经稳定之后进行，并且要保证优化后的系统依然是稳定的、可交付的系统。
可以肯定的说，这种看法是错误的，试问一个不能满足客户性能指标的稳定的系统何谈交付能力？数据库是应用系统运行的基础，数据库的性能优化、调整可以说是牵一发而动全身，是一件应当慎重对待的事情，如果等到系统开发完毕再想到进行性能优化，那么我们已经错过了性能优化的最佳时期，如果此时再去勉为其难的去作优化工作，那么数据库设计小组的成员就只能双掌合十，心中默念从释迦牟尼一直到圣母玛利亚等诸多中外神佛保佑，祈祷之后我们会发现他们都不站在我们这边。
数据库的性能优化工作在项目的需求分析阶段就已经开始了，并且一直伴随着数据库设计工作的开展而进行，可以说数据库的性能优化工作是贯穿数据库设计全过程的，数据库设计小组成员心中需要牢记一条准则：数据库性能优化无处不在，我们所作的一切都是为了性能的优化。
解决问题的最高境界是将问题消灭在萌芽阶段，同样性能优化的最佳时期是在需求分析阶段和系统架构设计阶段。
4.3. 优化些什么？
● 首先需要优化需求
这里所指的优化并非是指数据库技术方面的优化，而是在项目的需求分析阶段对客户的性能需求本身进行优化，目的只有一个：得出切实可行的数据库性能指标！数据库设计所作的一切可以说都是在围绕着如何满足数据库性能指标在作。可以说在性能指标面前成王败寇，没有任何回旋的余地，性能指标对于数据库设计工作的顺利进行有着无比重要的意义，因此在项目的需求分析阶段，数据库设计小组必须和需求组的同事合作，与客户反复协商，最终确定切实可行的数据库性能指标，在这期间客户很可能会提出一些不可能实现或者实现起来很困难的性能需求，这些性能需求都将会在后续的数据库设计工作中产生极大的实现风险，数据库设计小则必须识别出这类需求并且和需求组密切配合与客户沟通协商，争取将风险降到最小，之所以强调数据库设计小组需要作这部分工作是因为数据库设计小组对于数据库的设计实现有着更丰富的经验，对于风险需求的识别相比需求组的同事更有发言权。
● 优化硬件方案
如果客户要求你夺取F1大奖赛冠军，而只提供给你一辆奥拓，你觉得你能完成任务吗？我觉得恐怕赛纳在世也不可能完成。
数据库设计小组必需要在系统架构阶段和系统集成组的同事密切合作，依据数据库性能指标认真研究硬件方案的可行性。如果硬件基础和性能指标脱节，再怎么优化也是无济于事。
数据库设计小组要对整个项目的顺利进行负责，绝对不能放弃对于硬件方案的优化，其目的就在于为后续的数据库物理设计工作创造稳定、宽松的环境和条件。
● 优化数据库逻辑设计
数据库逻辑设计的优化工作说到底就是随着对客户业务需求的分析不断细化，对已有的数据库逻辑模型进行调整，使之更加适应系统开发的需要。
这一阶段优化的主要工作在于对逻辑模型中的实体进行增删、修改，剔除逻辑模型中的冗余数据。
● 优化数据库物理设计
数据库物理设计的优化工作主要从以下两方面入手：
1、 数据存储方式的优化。通过对表空间规划的调整、分区规划的调
整、日志空间大小的调整等等技术手段力争达到使用最小的磁盘I/O代价获取所需数据。
2、 提高数据读取速度。通过对索引设置的优化、数据存取路径的调
整等技术手段来提高数据读取速度。
● PL/SQL优化
根据经验，解决由于SQL 语句写法不合理而造成的性能问题大约占到性能优化工作的80％以上，因此如何缩减低效SQL 所带来的不必要工作量就成为数据库设计小组所必须面对的一个问题。 我觉得可以从以下方面入手：
1、 在编码工作开始前组织使用数据库进行开发的编码人员进行
PL/SQL编程的培训，让开发人员学会如何正确地进行SQL 语句的书写。
2、 对于关键的、有可能成为数据库性能瓶颈的核心业务应用模块所
进行的PL/SQL编程，数据库设计小组应当定期作代码检查。
3、 对于编码工作中开发人员所面临的PL/SQL编程所遇到的技术问
题，数据库设计小组应充分做好技术支持工作。
教训：3GSS 项目在编码工作进行前没有统一对开发人员进行PL/SQL编程的培训，因此造成了开发人员SQL 语句编写的混乱，重新调整、优化这些不合格的SQL 语句浪费了很多的工作量。
● 数据库运行期优化
这里所作的主要是对数据库DBMS 的配置优化，任何一个数据库，特别是Oracle 这样的大型数据库系统，都需要根据具体应用情况进行配置后才能够达到最优的运行性能。
这项工作需要使用具有DBA 资格的资源来完成，可以在编码阶段结合性能测试工作在系统真实运行环境下进行。
5. 综述
在大型项目中作数据库设计工作，一定要高瞻远瞩，未雨绸缪，将问题消灭在萌芽阶段才是解决问题代价最低的方法。
一定要将数据库设计工作的中心放在整个项目的需求阶段、架构设计阶段、详细设计阶段，其中又以需求阶段和架构设计阶段为重，数据库设计工作一定要走在系统设计工作的前面。
性能优化工作自始至终贯穿于数据库设计工作的全过程，不能将性能优化工作与数据库设计工作割裂开来。
大型项目中如何开展数据库设计工作
本文基于我在上海证券交易所第三代监察系统项目的实践描述如何在大型项目中开展数据库设计工作，本文避免过多的描述具体实现的技术细节，侧重于从软件工程角度描述数据库设计的整体流程以及项目各个阶段的工作侧重点。
1. 开展数据库设计工作所需条件
对于基于数据信息处理的大型行业解决方案项目来说，数据库设计是整个系统设计工作中最为重要、最为基础的环节之一，具备什么样的条件才能顺利开展数据库设计工作呢？
本章主要从资源配置角度描述如何确保数据库设计工作能够顺利进行。
1.1. 独立的数据库设计小组
对于一个软件合同额数千万，前后参与项目的人员数量数百人的大型软件工程项目来说，项目管理的重要程度要远比几十个人月、几个人完成的小项目要重要的多，而成功进行项目管理的基础之一便是完备的组织机构。
对于一个基于数据处理的大型核心业务应用系统来说，数据库设计是整个应用系统实现的基础，可以说其设计质量的好坏直接影响到整个项目的成败，应当有专门的组织机构负责其设计。
教训：在3GSS 项目中数据库规划组成立时间过晚，只是在开发工作过半的时候才组建起来，在这之前我个人也是在需求工作、架构工作都已基本结束的时间点进入项目组，这对于顺利的进行数据库设计造成了很大的困难。
1.1.1 职责
数据库设计小组的职责主要体现在以下方面：
● 参与项目总体架构设计，对于涉及到数据库应用的架构问题主要
负责。
● 保证在项目进行过程中数据库设计的稳定，为各个应用子系统的
开发提供稳定的数据平台，从而保证项目计划的正常执行。
● 在数据库性能优化工作起到主导作用，并对数据库性能优化的结
果负责。
● 对于数据库版本的管理和发布以及变更负责。
● 做好需求与开发之间的桥梁。
1.1.2 在项目组中的地位和作用
数据库设计小组在整个项目组的组织机构配置中应当与架构组、需求组、测试组等平级，直接对项目组PM 、PSM 负责，因为数据库设计
的工作需要各个小组的积极配合才能够顺利完成，所以项目小组之间的沟通协调工作显得尤其重要，如果不能做到从组织机构上将数据库设计小组提到项目组中一个相对较高的位置上，那么在一个大型项目组中，沟通协调工作将会很难进行。
教训：3GSS 项目中，数据库规划组在项目进入到编码阶段之前并没有单独独立出来，只是隶属于核心预警系统组，因此在与其他组的沟
通协调方面增加了一定的困难。
1.2. 如何组建数据库设计小组
描述数据库设计小组的组建过程和资源角色配置。
1.2.1. 角色配置
一个数据库设计小组主要应当包括以下角色：
1.2.2. 资源使用
可以这样说，数据库设计工作没有太多的开发工作量，但是对人员素质的要求很高，因此数据库设计小组的组建要按照“外科手术”的标准进行，贵在精而不在多：
1.3. 硬件资源
数据库设计工作顺利开展的一个重要条件是拥有既定硬件方案所规定型号的主机以及配套的存储设备，并且网络通讯能力要和真实上线条件一致，总之数据库设计工作需要一整套真实上线环境下的硬件设备，这不仅仅是数据库设计的需要，同时也是整个项目开发工作的一个重要基础条件，因为没有经过真实上线环境的检验，谁也不敢说我们用PC 机和低档服务器开发出来的系统能否在上线的时候稳定运行。必需要保证在编码工作开始前准备好硬件方案所规定型号的主机以及配套的存储设备。
教训：3GSS 项目在7月进入开发编码阶段，而硬件环境直到9月份才到位，在这之前我们只能使用PC 机来作数据库服务器，根本没有
办法模拟大数据量存储，致使数据库物理设计的优化调整只能延后，如果我们能够在这宝贵的2个月时间内仔细验证、优化我们的数据库物理设计方案，我们完全可以规避很多实现风险，也不会造成后来开发阶段数据库存储性能的瓶颈问题。
1.4. 设计工具
工欲善其事，必先利其器，现在有很多数据库设计工具可供选择，3GSS 项目选择Sybase 公司的PowerDesigner9.5作为设计工具，我认为这个工具主要有以下好处：
1、 可以方便地进行数据库的物理设计、逻辑设计
2、 有很强的文档生成能力，可以定制生成各种数据库设计文档
3、 拥有数据库反向工程能力
2. 数据库设计工作的流程与方法
首先提出一个问题：在一个项目中数据库设计工作什么时候开始启动？什么时候结束？
我认为，从需求工作启动的那一刻起，数据库设计工作就正式开始了，直到项目交付完毕、正式上线运行方才告一段落！其中工作重心主要放在需求阶段、架构设计阶段、详细设计阶段。
2.1. 需求阶段
数据库的设计，特别是大型核心业务应用系统的数据库设计，远非建几张数据库表那么简单，在数据库设计工作的初时阶段，就其本质来讲，是对客户核心业务的一次数据建模，出色完成该阶段数据库设计任务的关键条件是对用户核心业务的业务模式、处理流程、数据构成充分理解，可以说在这一阶段的数据库设计工作中，并没有涉及多少数据库技术方面的工作，更多的工作集中在对于客户核心业务的理解和学习上，为在后续阶段对数据库进行逻辑设计打好基础。而在这一方面，无疑需求组的同事是处于主导地位的，我们必须和需求组的同事合作，获取它们的帮助，同时，我们的参与也会促进需求组的同事进一步和客户沟通、明确很多业务方面的细节问题，从某种意义上讲也是间接推动了客户需求的细化工作。
数据库设计小组需要在需求阶段投入最大的精力和资源。
这一阶段数据库设计小组（以数据建模员为主）主要从事以下方面的工作：
● 对于客户需求的分析、理解、细化
有人可能会说：这是需求组来作的事，干吗让我来做？
这种观点是不正确的，因为需求人员的工作是站在偏业务的方面与客户进行沟通，而数据库设计人员是站在设计实现的角度去作，可以说数据库设计人员对于客户的数据需求比需求组的同事更加敏锐。 这段时间的工作是数据库设计工作中最困难也是最重要的工作，因为对于客户业务需求的理解是整个数据库设计工作的基础，磨刀不误砍柴工，在需求阶段将客户业务需求理解透彻将会在后续的设计工作中节省大量的时间。
● 数据概念模型建模
在对客户的需求用例有了比较透彻的理解之后，就应当着手针对需求用例进行数据抽象，得出初步的数据流图、E_R模型、数据字典。 主要应当考虑以下方面的内容：
1、 创建数据字典和E_R模型图表。E_R模型图表和数据字典可以
让任何了解数据库的人都明确如何从数据库中获得数据。ER 图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对后续开发SQL 来说这是完全必要的。
2、 确定数据依赖，识别数据实体之间的关系，对数据实体间的关系
作规范化处理。数据库实体之间关系规范化的范式有很多专门的技术文档可供参考，这里不加详细描述，但是需要指出一点，在实际项目实践过程中，并不一定完全按照范式的要求实现就是最好的设计，需要根据实际情况适当的作出一定的逆范式设计。例如，一个股票订单信息的数据实体，包括投资者帐号、投资者名称等投资人信息；订单号、交易价格、交易数量等交易信息；按照标准的范式设计应当将该数据模型划分为两个实体，既主从关系的投资人实体和交易信息实体，使用订单号关联，但是实际情况是，每日的订单信息数量达到了5000万笔，而投资人信息也将达到8000万条，如果仍然按照范式设计，那么在查询订单信息时将会人为的在两张超大表之间进行关联，那将严重影响查询速度，所以只能反规范化，将投资人信息和交易信息融合在一个数据实体中。
3、 对数据概念模型进行优化调整。针对数据库概念模型中的不足和
缺陷，要及时作出修正和调整，在这期间要与需求组的同事配合，充分和客户沟通，数据库设计的调整在概念模型上进行调整代价是最小的。
4、 制定数据对象命名规范。对于一个大型行业业务解决方案来说，
需要建模的数据项可能会有成千上万个，如果没有一个统一的命名规范将会给后续的设计开发工作造成不必要的麻烦。这一工作一般由数据库设计小组组长完成，完成后要经过项目组一级的评审。
经验：在概念模型的建立过程中，对于那些有着明确数据接口格式定义的外部输入数据，建模工作相对容易一些，对于用户需求用例中数据的流转过程建模，从而得出数据流图相对来说要困难一些，数据建模员切忌只看输入输出，不看数据流转、处理过程。数据的流转处理过程是建立数据库概念模型的重要依据，我们只有搞清楚了数据是如何流转的，如何被使用的才能够设计出尽可能贴近客户业务需求的数据模型。
● 做好需求与开发之间的桥梁。
为什么呢？因为数据库作为整个应用系统的运行基础，可以说整个系统的设计工作都将或多或少的与数据库系统的设计工作产生交叉，而数据库设计人员出于完成数据库逻辑设计的目的，必须对整个项目的需求用例以及业务背景有着全面的了解和掌握，可以这么说，在整个项目组中，只有数据库设计人员才能站在开发设计角度掌握整个系统完整的需求细节，可以说数据库设计人员在以后的设计、开发阶段是一个宝贵的资源，数据库设计人员应当对应用系统的设计人员提供咨询上的帮助，并且对应用系统设计进行评审，确定其设计是否与数据库设计相契合。
2.2. 系统架构阶段
在系统架构阶段，数据库设计小组的主要工作是：
● 确定数据库服务器所使用的硬件配置方案
这项工作需要数据库设计小组和系统集成组的同事合作完成，数据库设计小组主要从客户对于数据库的性能指标入手，得出对于数据库服务器的硬件要求，系统集成组的同事负责具体的硬件选型。
在确定硬件配置方案的时候，数据库设计小组主要从以下几个方面入手：
1、 满足数据的存储容量需求。以需求阶段所得出的数据库概念模型
和数据字典为基础，按照客户给出的未来一段时间内业务数据的增长速度预估出数据存储空间，在这里应当注意：需要为索引预留出存储空间，一般经验性的做法，索引的存储空间与数据存储空间按照1：1来预估。
2、 满足数据库交易处理能力的需求。我们要考虑高峰时的处理器的
能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。如果要保持快速的响应能力，应当为CPU 保留20%至40%的富余量。要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素:
交易的复杂性
交易频率
数据读/写比例
并发连接数目
并发交易数目
数据库最大表的大小
性能度量的目标
教训：在3GSS 项目架构设计阶段硬件方案选型的时候，没有考虑到会在每天的交易时间内在数据库服务器上并发运行数据预处理存储过程，只为数据库服务器配置了4CPU ，结果导致在项目后期出现了严重的数据库服务器处理性能不足问题。
● 规划数据库的物理设计
数据库最终是要存储在物理设备上的。为一个给定的逻辑数据模型选取一个最适合应用环境的物理结构（存储结构与存取方法）的过程，就是数据库的物理设计。
物理结构依赖于给定的DBMS 和和硬件系统，因此设计人员必须充分了解所用DBMS 的内部特征，特别是存储结构和存取方法；充分了解应用环境，特别是应用的处理频率和响应时间要求；并充分了解外存设备的特性。
数据库的物理设计通常分为两步：
第一步：确定数据库的物理结构
在这里数据库设计小组主要从事以下方面的工作：
1、 确定数据的存储结构。确定数据库存储结构时要综合考虑存取时
间、存储空间利用率和维护代价三方面的因素。这三个方面常常是相互矛盾的，例如消除一切冗余数据虽然能够节约存储空间，但往往会导致检索代价的增加，因此必须进行权衡，选择一个折中方案。
2、 设计数据的存取路径。在关系数据库中，选择存取路径主要是指
确定如何建立索引。例如，应把哪些域作为次码建立次索引，建立单码索引还是组合索引，建立多少个为合适，是否建立聚集索引等。
3、 确定数据的存放位置。为了提高系统性能，数据应该根据应用情
况将易变部分与稳定部分、经常存取部分和存取频率较低部分分开存放。例如，目前许多计算机都有多个磁盘，因此进行物理设计时可以考虑将表和索引分别放在不同的磁盘上，在查询时，由于两个磁盘驱动器分别在工作，因而可以保证物理读写速度比较快。也可以将比较大的表分别放在两个磁盘上，以加快存取速度，这在多用户环境下特别有效。此外还可以将日志文件与数据库对象（表、索引等）放在不同的磁盘以改进系统的性能。
4、 确定系统配置。DBMS 产品一般都提供了一些存储分配参数，供
设计人员和DBA 对数据库进行物理优化。初始情况下，系统都为这些变量赋予了合理的缺省值。但是这些值不一定适合每一种应用环境，在进行物理设计时，需要重新对这些变量赋值以改善系统的性能。通常情况下，这些配置变量包括：同时使用数据库的用户数，同时打开的数据库对象数，使用的缓冲区长度、个数，时间片大小、数据库的大小，装填因子，锁的数目等等，这些参数值影响存取时间和存储空间的分配，在物理设计时就要根据应用环境确定这些参数值，以使系统性能最优。在物理设计时对系统配置变量的调整只是初步的，在系统运行时还要根据系统实际运行情况做进一步的调整，以期切实改进系统性能。
第二步：对数据库物理结构优化
数据库物理设计过程中需要对时间效率、空间效率、维护代价和各种用户要求进行权衡，其结果可以产生多种方案，数据库设计人员必须对这些方案进行细致的评价，从中选择一个较优的方案作为数据库的物理结构。
评价物理数据库的方法完全依赖于所选用的DBMS ，主要是从定量估算各种方案的存储空间、存取时间和维护代价入手，对估算结果进行权衡、比较，选择出一个较优的合理的物理结构。如果该结构不符合用户需求，则需要修改设计。
● 完成数据库概念模型到逻辑模型的转换
逻辑结构设计的任务：就是把概念结构设计阶段设计好的基本E-R 图转换为与选用DBMS 产品所支持的数据模型相符合的逻辑结构。因此设计逻辑结构首先应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS 。设计逻辑结构时一般要分两步进行：
1、 将概念结构转换为特定DBMS 支持下的数据模型。
2、 数据模型进行优化。
这些工作基本上都可以使用PowerDesigner 设计工具开完成。
2.3. 详细设计阶段
有一点是要明确的，就是数据库设计要走在各个子系统应用程序设计的前面，原因是明显的，因为各个子系统需要在数据库支撑环境已经明确的情况下才可以开展设计、开发工作。
数据库设计小组这一阶段的主要工作有两点：
1、 支持各个子系统应用程序的设计。特别是查询、报表模块的设计，
这是与数据库关联最为密切的模块，可以说没有数据库的良好支持，根本不可能设计出性能优良的查询、报表程序。
2、 对数据库模型进行优化调整。在各个子系统设计的深入过程中我
们会不断发现原有数据库模型设计上的一些不足，主要集中在以下方面：
库表结构设计不合理。
不能够提供所需要的数据。
数据库表的主键、索引设置不合理。
数据库的物理存储空间分配不足。
2.4. 编码阶段
如果之前阶段的工作顺利完成，那么进入到编码阶段，可以说数据库设计工作已经完成大半了，编码阶段数据库设计小组的工作重心应当转移到性能验证、性能测试工作上。
此外，在编码阶段数据库设计小组应当对于开发人员的PL/SQL编程提供技术支持和代码检查，以保证PL/SQL编码的质量。
2.5. 测试阶段
随着开发工作的逐步推进，测试组的同事会对各个阶段获取的系统版本进行系统测试，数据库设计小组要做好数据库的版本控制工作，全力配合测试组的同事进行系统测试。
另外，数据库设计小组还应当积极协助测试组的同事准备数据库性能验证测试的测试案例、测试数据。
2.6. 系统交付阶段
如果能够顺利进行到系统最终交付阶段，也可以说我们的数据库设计工作已经功德圆满了。
这一阶段要做好数据库设计的最终封版工作，对数据库设计的各种工作成果物进行整理，对数据库设计个个阶段产生的设计文档进行归纳总结。
3. 数据库设计工作中的版本控制
由于大型项目的开发周期很长，出于配置管理的需要，在大型项目的开发阶段，需要设置若干个里程碑，在每个里程碑都需要对软件系统进行封版，形成配置基线，这些配置基线对于开发工作的延承和最终系统的按时交付有着重要意义，与此相对应，作为应用系统基础的数据库也需要在相应的里程碑得到对应的设计版本，数据库设计的版本控制与配置管理是整个项目组版本控制与配置管理的一部分，但是与应用系统开发过程的版本控制与配置管理又有所区别，我们在3GSS 项目的实践中摸索出了一套数据库设计版本控制的工作流程与方法。
3.1. 版本控制
数据库设计的工作成果主要包括数据库建库脚本、初始化数据、PL/SQL脚本等内容，其特点在于数据库设计的版本与应用系统的开发版本之间存在很强的相互依赖性，一个开发版本通常情况下只能在
与该开发版本对应的数据库设计基础之上才能够正常运行，这是由于在项目开发工作的不断推进过程中，数据库设计工作也在不断的细化、完善。这种依赖性在测试组的同事针对某一开发版本进行测试的时候表现的最为明显。
教训：在3GSS 开发工作的初始阶段，数据库设计的版本控制没有形成规范化，与开发版本的控制脱节，因此曾经一度造成数据库版本的混乱，测试组在进行系统测试的时候取得开发版本后不知道应该使用什么版本的数据库。
经验：在后续的开发工作中，数据库设计的版本控制严格跟随应用系统开发版本的版本控制进程进行，在应用系统发布每一个开发版本的时候，我们都会发布一个与之对应的数据库设计版本，并且在交付测试组进行系统测试前明确指出开发版本与数据库设计版本的对应关系，从而避免了开发版本与数据库设计版本的脱节问题，开发、测试工作也得以稳定、顺利的进行下去。
3.2. 配置管理
数据库设计的配置管理工作应当紧跟应用系统开发的阶段性封版工作，要与应用系统形成统一的配置基线。
数据库设计工作成果物的目录组织形式可以参照下图所示：
但是并不一定拘泥于此，只要能够清晰、简便的体现出数据库设计的各个配置基线，能够方便地获取各个时期各个时期的不同版本即可。 配置管理工具可以选用微软的SourceSafe 。
经验：在开发阶段，数据库的结构细微变动较为频繁，数据库的变动通过补丁方式维护数据库，在一个开发阶段结束，数据库版本稳定后，根据数据库的变动情况形成数据库设计的配置基线。
3.3. 变更流程
在项目的编码开发阶段，随着编码工作的逐渐深入，原有系统设计中的不足和一些没有考虑到的设计细节问题开始逐渐暴露出来，随之就要进行设计的调整，数据库设计也是如此。
但是数据库设计是整个应用系统运行的基础，对于数据库系统的设计调整将有可能影响到整个系统的正常运行，因此对于数据库设计的调整应当十分谨慎，在数据库设计的变更工作中应当注意以下方面：
● 数据库设计变更的要求只能由各个子系统的开发组长提出，并
且经过项目组开发负责人同意。
这样做是为了保证数据库设计的稳定性，因为在一个大型项目中，编码人员非常多，而且编码人员看待设计问题的方法和角度往往和系统设计人员、架构师的角度不同，有可能提出一些不切合实际的变更要求，因此就需要有人对变更要求进行评审和把关。
● 数据库设计小组在接到变更要求后绝对不可以随意变更数据库
设计，必须经过数据库设计小组组长评审通过后方可进行相应修改。
这样做同样是为了保证数据库设计的稳定性，避免设计工作的反复。如果数据库设计小组组长评审后认为不适宜修改应当立即和项目组开发负责人进行沟通协商，如果仍然没能达成一致就需要召开项目组级别的架构评审会议进行评审。
● 数据库设计的变更需要做好修改记录。
这样做是为了清楚地记录下整个数据库设计过程中所发生的设计变动过程，有了这份记录，我们在将来就可以很容易对数据库设计的依据进行回溯，有助于我们更好的理解数据库设计的历史延承。 ● 数据库设计变更完毕后一定要将变更结果通知项目组中所有涉
及到该项变更的开发小组组长。
在一个大型项目组中，由于开发小组很多，再加上沟通不畅，很容易造成这样一种结果：某张表已经作出了变更，但是某些开发小组并不知道，仍然依据老的表结构进行开发，这样就人为的制造了系统BUG 。因此务必要将数据库设计的变更结果传达到每一个相关的开发人员，而开发人员数量较多，因此我们只将变更结果传达到开发小组长，再由开发小组长传达到每一个开发人员。
教训：3GSS 项目中在开发阶段的初期，数据库设计调整之后，数据库设计小组作了版本控制，也做了修改记录，但是没有将变更结果通知到涉及该次变更的开发人员，结果造成了数据库版本已经升级而开发人员还在使用老版本的数据库设计进行开发的情况
经验：我们采取了变更后对开发小组组长进行邮件通知的做法，一定程度上避免了该问题，但是有一些开发小组组长对于邮件通知不敏感，没有将变更通知继续向组员传达，所以数据库设计小组就在每次发送变更通知邮件后再口头通知一遍各个开发小组组长。
● 每一次数据库设计变更后应当做好相应的版本控制和配置管理
工作。
● 发布每一次数据库设计的变更之前都应当对所发布的内容在专
用的数据库服务器上进行发布测试，以保证所发布设计的可用性。
● 开发用数据库服务器由数据库设计小组负责管理和维护，此外
任何人不得对数据库服务器作出任何变更。
开发用数据库服务器是系统开发过程中全项目组公用的开发环境，任何人对于数据库服务器的私自改变都将会影响到其他开发人员的正常开发，应当予以严厉禁止。
经验：破坏性最大的是对数据库表结构的私自变更，在3GSS 项目中，我们采取了设置不同数据库用户，分别授权的方法来规避该问题。具体做法是，设置管理员用户，赋予数据库DBA 权限，可以对数据库服务器作出任何变更，这个用户只有数据库设计小组相关成员拥有密码；设置开发用户，只赋予数据增删改查权限以及其他必要的权限，该用户供所有开发人员开发使用。
4. 数据库设计中的性能优化问题
说到数据库性能优化，在我接触到的同事中持以下两种观点的人居多：
● 性能优化太复杂了，根本无从下手！
● 不就是优化嘛，等开发完了找个高手过来优化一下就可以了！ 如果说持以上观点的只是普通开发人员还有可以挽回的余地，如果在一个大型的项目组中，负责数据库设计工作的负责人也持有以上观点，那么注定将会出现一个失败的数据库设计！
数据库性能优化并不是独立于数据库设计和实现之外，而是自始至终贯彻于数据库设计的工作之中，可以说从数据库设计工作启动的哪一刻起，我们就应当将性能优化作为我们的一个工作重点。也可以说数据库设计的过程就是一个数据库性能优化的过程。
性能优化也不是洪水猛兽，也是有一定的工作方法可循的，只要我们按照正确的方法来做，相信一定会顺利的完成，下面我们来着重谈一下性能优化这个话题。
4.1. 什么是数据库性能？
这个问题如果问100个人，可能会得到101种答案，例如：SQL 语句的执行时间长短、每秒钟能够插入数据库的记录条数、数据导入导出数据库的时间长短等等，这些答案都对，但是并不完全。
我认为，以技术的角度来看，数据库的性能就是以最少的时间获取所需要的数据的能力；以软件工程的角度来看，性能就是满足客户需求的能力。
许多人都喜欢说这么一句话：“没有最好，只有更好。”我很欣赏这句话，作工作需要这种积极向上的态度，但是这句话如果放在数据库性能优化这件事情上则不尽然，应当加上一个限制条件：“如果不计成本，那么数据库性能没有最好，只有更好。”
作软件，特别是象我们这种行业解决方案提供商，如何平衡质量（Quality ）、成本（Cost ）及交付（Delivery ）的关系，从而利益最大化是每一个软件从业人员都必须考虑的事情，从客户角度来讲，客户花钱让我们来做解决方案，是为了能够在实际应用中体现出该解决方案的价值，能够满足其特定的应用需求，因此我们只要满足了客户需求即可，性能优化不需要画蛇添足！
4.2. 什么时间优化？
有很多人认为数据库性能优化在编码结束、系统稳定后再进行，理由是：应当首先保证项目的开发进度和交付能力，优化工作必须等到开发结束并且系统已经稳定之后进行，并且要保证优化后的系统依然是稳定的、可交付的系统。
可以肯定的说，这种看法是错误的，试问一个不能满足客户性能指标的稳定的系统何谈交付能力？数据库是应用系统运行的基础，数据库的性能优化、调整可以说是牵一发而动全身，是一件应当慎重对待的事情，如果等到系统开发完毕再想到进行性能优化，那么我们已经错过了性能优化的最佳时期，如果此时再去勉为其难的去作优化工作，那么数据库设计小组的成员就只能双掌合十，心中默念从释迦牟尼一直到圣母玛利亚等诸多中外神佛保佑，祈祷之后我们会发现他们都不站在我们这边。
数据库的性能优化工作在项目的需求分析阶段就已经开始了，并且一直伴随着数据库设计工作的开展而进行，可以说数据库的性能优化工作是贯穿数据库设计全过程的，数据库设计小组成员心中需要牢记一条准则：数据库性能优化无处不在，我们所作的一切都是为了性能的优化。
解决问题的最高境界是将问题消灭在萌芽阶段，同样性能优化的最佳时期是在需求分析阶段和系统架构设计阶段。
4.3. 优化些什么？
● 首先需要优化需求
这里所指的优化并非是指数据库技术方面的优化，而是在项目的需求分析阶段对客户的性能需求本身进行优化，目的只有一个：得出切实可行的数据库性能指标！数据库设计所作的一切可以说都是在围绕着如何满足数据库性能指标在作。可以说在性能指标面前成王败寇，没有任何回旋的余地，性能指标对于数据库设计工作的顺利进行有着无比重要的意义，因此在项目的需求分析阶段，数据库设计小组必须和需求组的同事合作，与客户反复协商，最终确定切实可行的数据库性能指标，在这期间客户很可能会提出一些不可能实现或者实现起来很困难的性能需求，这些性能需求都将会在后续的数据库设计工作中产生极大的实现风险，数据库设计小则必须识别出这类需求并且和需求组密切配合与客户沟通协商，争取将风险降到最小，之所以强调数据库设计小组需要作这部分工作是因为数据库设计小组对于数据库的设计实现有着更丰富的经验，对于风险需求的识别相比需求组的同事更有发言权。
● 优化硬件方案
如果客户要求你夺取F1大奖赛冠军，而只提供给你一辆奥拓，你觉得你能完成任务吗？我觉得恐怕赛纳在世也不可能完成。
数据库设计小组必需要在系统架构阶段和系统集成组的同事密切合作，依据数据库性能指标认真研究硬件方案的可行性。如果硬件基础和性能指标脱节，再怎么优化也是无济于事。
数据库设计小组要对整个项目的顺利进行负责，绝对不能放弃对于硬件方案的优化，其目的就在于为后续的数据库物理设计工作创造稳定、宽松的环境和条件。
● 优化数据库逻辑设计
数据库逻辑设计的优化工作说到底就是随着对客户业务需求的分析不断细化，对已有的数据库逻辑模型进行调整，使之更加适应系统开发的需要。
这一阶段优化的主要工作在于对逻辑模型中的实体进行增删、修改，剔除逻辑模型中的冗余数据。
● 优化数据库物理设计
数据库物理设计的优化工作主要从以下两方面入手：
1、 数据存储方式的优化。通过对表空间规划的调整、分区规划的调
整、日志空间大小的调整等等技术手段力争达到使用最小的磁盘I/O代价获取所需数据。
2、 提高数据读取速度。通过对索引设置的优化、数据存取路径的调
整等技术手段来提高数据读取速度。
● PL/SQL优化
根据经验，解决由于SQL 语句写法不合理而造成的性能问题大约占到性能优化工作的80％以上，因此如何缩减低效SQL 所带来的不必要工作量就成为数据库设计小组所必须面对的一个问题。 我觉得可以从以下方面入手：
1、 在编码工作开始前组织使用数据库进行开发的编码人员进行
PL/SQL编程的培训，让开发人员学会如何正确地进行SQL 语句的书写。
2、 对于关键的、有可能成为数据库性能瓶颈的核心业务应用模块所
进行的PL/SQL编程，数据库设计小组应当定期作代码检查。
3、 对于编码工作中开发人员所面临的PL/SQL编程所遇到的技术问
题，数据库设计小组应充分做好技术支持工作。
教训：3GSS 项目在编码工作进行前没有统一对开发人员进行PL/SQL编程的培训，因此造成了开发人员SQL 语句编写的混乱，重新调整、优化这些不合格的SQL 语句浪费了很多的工作量。
● 数据库运行期优化
这里所作的主要是对数据库DBMS 的配置优化，任何一个数据库，特别是Oracle 这样的大型数据库系统，都需要根据具体应用情况进行配置后才能够达到最优的运行性能。
这项工作需要使用具有DBA 资格的资源来完成，可以在编码阶段结合性能测试工作在系统真实运行环境下进行。
5. 综述
在大型项目中作数据库设计工作，一定要高瞻远瞩，未雨绸缪，将问题消灭在萌芽阶段才是解决问题代价最低的方法。
一定要将数据库设计工作的中心放在整个项目的需求阶段、架构设计阶段、详细设计阶段，其中又以需求阶段和架构设计阶段为重，数据库设计工作一定要走在系统设计工作的前面。
性能优化工作自始至终贯穿于数据库设计工作的全过程，不能将性能优化工作与数据库设计工作割裂开来。