（转摘）_《数据库设计入门经典》:通过分析进行规划与准备_9.2 分析
9.2 分析
正如前文所介绍的，分析是建立一个良好的关系数据库模型的开始。分析是关于某个公司的操作因素和商业事务。它与计算机系统的技术方面无关。分析与数据库模型，或与数据库管理员与程序员所希望和想要获得的内容都没有关系。分析人员必须理解业务。来自业务人员(公司中技术的和非技术的员工(终端用户，甚至包括主要管理层)的参与对于最后的成功至关重要。某些公司仅仅通过临时雇用的人员而不是通过内部技术人员的参与来开发软件。这样做的结果是一个完全基于终端用户的数据库模型。我们需要在技术人员和非技术人员之间寻求一个平衡。
很重要的一点是将设计阶段理解成一种需求行为。哪些内容是需要的？当建立数据库模型、应用程序或者软件产品时，重要的是要了解有一个说明数据库中的内容的过程。您需要那些表？在计算机术语中，这些过程通常称为方法论(规则的集合)，通过方法论，计算机系统的建立者可以获得从A到B的结果(从草稿纸上的涂鸦到有用的计算机系统)。许多人曾经花费许多年的时间来考虑这些规则，不断地细化，从而为人们提供时而简单时而又十分复杂的从A到B的步骤。
提示：
规范化是一种方法论。规范化是用于细化关系数据库中表结构的规则的复杂集合。将数据库模型设计过程分为分析、设计、构造和实现步骤也是一种方法论。
通过在分析阶段对细节的关注可以获得最佳的数据库模型。在匆忙地开始分析之前，准确地理解所需的内容是十分重要的。如果在后面的开发阶段需要进行修改，那么可以在稍后的阶段添加修改内容。但是，对生产系统所使用的数据库模型进行修改会造成很多问题，这种做法绝非一个好选择。这是由于应用程序通常依赖于数据库，从而也会依赖于数据库模型。
分析是规划。为数据库模型进行计划具有双倍的重要性。原因在于：就整个公司而言，数据库模型是所有基于数据库的应用程序的基本要素。在现有产品的情况下，数据库模型可以为数以百计甚至数以千计的公司驱动相同的或是半专用化的应用程序。在第一时间获得数据库模型是十分重要的。分析阶段对数据库模型理解得越透彻，那么最终获得的数据库模型和产品将会越好。
有些数据库建模和设计工具允许为不同的数据库引擎生成表的脚本。本书用于数据库建模的工具称为ERWin。ERWin可以用于为许多数据库引擎生成表的创建脚本。Microsoft
Access
就具有内置的ERD建模工具。数据库模型通常可以通过图形化的数据库建模工具中的漂亮图片(例如ERWin)来设计。当进行设计时，通过漂亮的图片和直观的图形数据包建立数据库模型可以考虑到分析状态和途径，而忽略过于技术化的细节。事实上，在一开始，深层次的技术方面(例如字段的数据类型和精确组成)由于包含过多的复杂性，所以会影响分析过程。
提示：
分析关注的是所需的内容。设计则关注通过已经完成的分析来提供这些内容的方法。
当对某个已经存在的系统进行重写(即对已存在的数据库模型进行重新构造)时，分析仅仅包含从终端用户和技术人员的访问和讨论中获得的旧系统。如果正在对某个系统进行重写，那么在某些方面，原先的系统很有可能是不合适的。通过执行分析过程可以使我们明白旧系统中缺失、错误和不合适的地方。
终端用户可能会告诉我们他们在现有的系统中所不能完成的任务。终端用户也可能会列出他们所希望功能的清单。对于分析人员而言，一种稳妥的方法是对增强功能和新特征的重要性作出评估。这样做的原因在于：分析阶段中最重要的特征是估算出整个过程的花费。随着工作量的增加，开发的费用也随之增长。
编程人员和管理员之类的技术人员有可能会告诉我们系统中存在的错误。他们也会告诉我们避开这些问题的方法，例如通过kludge来达到目的。
提示：
kludge是一种计算机编程人员经常使用的说法，它用于描述一种能够解决问题但是不太好用的方法。采用kludge的结果经常是产生由匹配较差的元素所组成的计算机系统。
9.2.1 分析中的考虑因素
由于分析阶段是建立和限定所需内容的过程，因此我们需要记住如下所示的因素和考虑事项。
● 总体目标——
这些目标包括创建数据库模型时某个公司的全部目标。包括：数据库模型中的内容、所希望的结果、应该获得的结论。例如：这是新的应用程序还是需要重写的应用程序？
● 公司运作—— 这些行为包括公司的谋生手段和计算这些手段的方法。
● 业务规则—— 这是分析阶段的核心，业务规则描述了分析的内容和设计数据库模型所需要创建的内容。包括所需要的表以及表之间的基本关系。
● 规划和时间表——
对于较大的工程而言，规划和时间表非常有用。典型的项目计划包括完成人、完成工作和完成时间。为了与更多的人分享这些计划并确保满足任务独立性，更完善的计划将多任务结合在一起。例如，如果任务B需要任务A的完成，那么可以由一个人完成A任务和B任务，如果没有依赖性，那么可以由两个人在同样的时间内分别完成A任务和B任务。
● 预算——
整个工程的开销是多少？这些开销是否有效、是否值得、是否能够承担？在将市场竞争中的优势带给公司之前，这些开销是否会导致公司的破产。预算所包含的考虑内容如下所示：
· 聘请辅助人员所需的开销—— 您是否需要聘请辅助人员？辅助人员的开销通常很高。是否具有可用的熟练的人员？是否需要补充新人？是否需要花高价聘请顾问？
· 硬件开销—— 根据速度和存储容量需要对硬件需求作出评估。对于OLTP数据库而言，根据处理器的数目和规模而决定的并发性、on-board
RAM、专用硬件设备(RAID矩阵)以及网络带宽都是很重要的因素。存储空间的设计和I/O性能对于数据仓库来说也很重要。
· 维护—— 维护的简易性意味着长期的低开销。
· 培训——
终端用户和编程人员必须知道所创建系统的使用方法。否则，即使系统可用，也很难获得最大限度的利用。如果数据库设计者为某家公司引入新的数据库引擎(例如Oracle
Database)，那么进行培训是必须的要求，并且必须将培训编入预算。技术培训十分昂贵和耗时。
● 其他因素—— 其他较少注意到(但相关性没有减少)的因素包括如下内容：
· 数据的重复性——
应该避免数据的重复(条件是不牺牲性能)和过细的粒度。过细的粒度经常是过度规范化的结果。过度的规范化会使SQL代码的编写过于复杂和难以执行，还会产生诸多问题和高昂的维护代价。
提示：
过度的规范化可以清除数据中的潜在错误(违反参照完整性的错误)。这样做也会使ERD包含许多表，并会为程序员造成许多麻烦的问题。过度的规范化对于数据库设计人员来说是一件好事，但却是编程人员的噩梦。关系数据库模型设计是一种达到目的的手段，本身并不是目的。换言之，数据库模型是为编程人员和终端用户建立的。数据库模型不应该建立在过于完美的数学规则的基础上，这样做的后果是只有数据库建模者才能理解这一模型。我们应该时刻将设计的目的记在头脑中。设计的目的是满足应用程序的需求并为公司提供优势，而不是使生活变得更加复杂。
· 只读或者读写——
数据库是否只读或者要求完全的可读写？数据仓库中的数据库经常是部分只读。OLTP数据库的部分静态数据的内容要求可读。考虑到OLTP数据库的灵活性，静态表中需要使用专门的方法。
不用惊讶，对包括公司操作、业务规则、计划和时间限制、以及预算在内的所有目标的考虑可以作为整个分析过程的框架。事实上，在本节稍后的案例分析示例的开发中，这些考虑因素都将包含在内。在学习案例分析的示例之前，先了解分析企业数据库模型时所暗藏的问题。
提示：
前面所提到的“其他因素”在本节将作详细的叙述。与主题相关的因素已在本书前面的章节中进行过叙述。
9.2.2 潜在问题和误解
当分析公司数据库模型时，有很多值得考虑和记忆的消极因素。这些因素包括如下内容：
● 规范化和数据完整性
● 更多的规范化会导致更好的查询结果
● 性能
● 通用和标准的数据库模型
让我们对这些内容进一步的讨论。
1. 规范化和数据完整性
许多分析人员提出通过使用所有可用的范式来进行各种层次的规范化，从而保证数据不被丢失(冗余性)以及完全地匹配参照完整性(孤立记录)。数据库是信息的储存库。不良的应用程序编程或者不正确的数据库使用会产生问题数据。高度规范化的数据库模型可以确保较好的数据完整性，但是数据库模型本身却不会产生这些问题数据。应用程序编程人员和终端用户由于编码错误或者对数据库的不正确修改会导致这些问题的产生。
2. 更多的规范化会导致更好的查询结果
这是由很多分析者所提出的另一种观点。一些声明如下所示：
● “问题查询通常是不合适(非规范化)的数据库结构的产物。”
● “与规范化的数据库结构相比，编写快速的查询和更新操作更为简单。”
笔者的观点与上述两条完全相反。非规范化的结构会产生快速的查询并且使终端用户更容易地编写查询操作。从可操作的角度来看，非规范化的表与商业应用匹配得更真实。换言之，负责编写ad-hoc查询的忙碌的执行者可以理解表和表之间的联系方法。
在许多表之间建立查询会导致大量的连接查询。连接查询不仅编写起来十分复杂，具有讽刺意味的是，这样的查询执行起来也十分耗时。对于刚开始使用数据库的终端用户来说，编写过于复杂的连接查询几乎是不可能的。这样做并不公平。即使对于熟练的编程人员来说，在DKNF层次的规范化数据库模型上建立连接查询通常也是件很荒唐的事情。例如，在某个数据库里建立对于15张表的连接查询将会占用1GB的空间，30秒的时间。这种作法是完全无法令人接受的。笔者曾在过去见过这种情况。
提示：
数据库建模不应该是对过度完美的数学规则的表达，而是应该作为达到目的的方法。这种方法是数据库建模。目的是满足用户的要求。我们的目的不是生成无法满足用户需求但是粒度最完美的数据库模型。
3. 性能
某些分析人员声称计算机的性能、应用程序以及数据库模型与业务分析没有关系。笔者完全不同意这种说法。由于一开始没有考虑到最重要的性能因素，从而造成应用程序和整个服务环境被淘汰的情况，笔者也曾见过。性能一直是很重要的因素。离开性能来分析数据库模型就如同买下一艘新船却付不起钱——
完全是把钱往水里扔。
所有SQL代码都依赖于底层的表结构和表内容，甚至需要依赖表的标识和表的信息内容。在分析阶段应该对这些内容作出决定。毫无疑问，在分析时作出的决定会影响以后的性能。数据库和应用程序的性能是十分重要的。
4. 通用和标准的数据库模型
我们需要当心被特定的行业或者应用程序作为标准的通用数据库模型。通用数据库模型通常出现在所购买的半定制化的应用程序中。通用模型可以满足多种应用程序的要求。如果您正在使用自己的数据库模型，那么可以建立专门满足公司要求的数据库模型。通用数据库模型的许多作用域是无法应用到特定的公司要求中的。换言之，您的数据库也许会有许多无用的空表。从技术上来说，无用的表并不是真正的问题，但是它们会对编程人员和终端用户造成混淆。通用模型的另一个缺陷是它也许无法精确地满足所有的要求，同时很有可能需要修改。
标准数据库模型，尤其是为满足特定行业的需要并作为一种准则的模型，也会很危险。因为它们很可能已经过时。与通用模型一样，标准模型很可能包含冗余的表，这些表也会造成所有可能的问题和不足。如果您正在建立数据库模型，那么您也会分析实际情况，为您的公司和特定应用程序自定义构建模型；但是，作用域的减小会导致不灵活性并最终在系统中产生局限性。这样做需要达到完美的平衡。
现在我们可以了解到叙述上述内容的原因、我写这本书的原因以及阅读本章的原因。如何将理论应用到实践的方法？让我们从分析开始介绍。
正如前文所介绍的，分析是建立一个良好的关系数据库模型的开始。分析是关于某个公司的操作因素和商业事务。它与计算机系统的技术方面无关。分析与数据库模型，或与数据库管理员与程序员所希望和想要获得的内容都没有关系。分析人员必须理解业务。来自业务人员(公司中技术的和非技术的员工(终端用户，甚至包括主要管理层)的参与对于最后的成功至关重要。某些公司仅仅通过临时雇用的人员而不是通过内部技术人员的参与来开发软件。这样做的结果是一个完全基于终端用户的数据库模型。我们需要在技术人员和非技术人员之间寻求一个平衡。
很重要的一点是将设计阶段理解成一种需求行为。哪些内容是需要的？当建立数据库模型、应用程序或者软件产品时，重要的是要了解有一个说明数据库中的内容的过程。您需要那些表？在计算机术语中，这些过程通常称为方法论(规则的集合)，通过方法论，计算机系统的建立者可以获得从A到B的结果(从草稿纸上的涂鸦到有用的计算机系统)。许多人曾经花费许多年的时间来考虑这些规则，不断地细化，从而为人们提供时而简单时而又十分复杂的从A到B的步骤。
提示：
规范化是一种方法论。规范化是用于细化关系数据库中表结构的规则的复杂集合。将数据库模型设计过程分为分析、设计、构造和实现步骤也是一种方法论。
通过在分析阶段对细节的关注可以获得最佳的数据库模型。在匆忙地开始分析之前，准确地理解所需的内容是十分重要的。如果在后面的开发阶段需要进行修改，那么可以在稍后的阶段添加修改内容。但是，对生产系统所使用的数据库模型进行修改会造成很多问题，这种做法绝非一个好选择。这是由于应用程序通常依赖于数据库，从而也会依赖于数据库模型。
分析是规划。为数据库模型进行计划具有双倍的重要性。原因在于：就整个公司而言，数据库模型是所有基于数据库的应用程序的基本要素。在现有产品的情况下，数据库模型可以为数以百计甚至数以千计的公司驱动相同的或是半专用化的应用程序。在第一时间获得数据库模型是十分重要的。分析阶段对数据库模型理解得越透彻，那么最终获得的数据库模型和产品将会越好。
有些数据库建模和设计工具允许为不同的数据库引擎生成表的脚本。本书用于数据库建模的工具称为ERWin。ERWin可以用于为许多数据库引擎生成表的创建脚本。Microsoft
Access
就具有内置的ERD建模工具。数据库模型通常可以通过图形化的数据库建模工具中的漂亮图片(例如ERWin)来设计。当进行设计时，通过漂亮的图片和直观的图形数据包建立数据库模型可以考虑到分析状态和途径，而忽略过于技术化的细节。事实上，在一开始，深层次的技术方面(例如字段的数据类型和精确组成)由于包含过多的复杂性，所以会影响分析过程。
提示：
分析关注的是所需的内容。设计则关注通过已经完成的分析来提供这些内容的方法。
当对某个已经存在的系统进行重写(即对已存在的数据库模型进行重新构造)时，分析仅仅包含从终端用户和技术人员的访问和讨论中获得的旧系统。如果正在对某个系统进行重写，那么在某些方面，原先的系统很有可能是不合适的。通过执行分析过程可以使我们明白旧系统中缺失、错误和不合适的地方。
终端用户可能会告诉我们他们在现有的系统中所不能完成的任务。终端用户也可能会列出他们所希望功能的清单。对于分析人员而言，一种稳妥的方法是对增强功能和新特征的重要性作出评估。这样做的原因在于：分析阶段中最重要的特征是估算出整个过程的花费。随着工作量的增加，开发的费用也随之增长。
编程人员和管理员之类的技术人员有可能会告诉我们系统中存在的错误。他们也会告诉我们避开这些问题的方法，例如通过kludge来达到目的。
提示：
kludge是一种计算机编程人员经常使用的说法，它用于描述一种能够解决问题但是不太好用的方法。采用kludge的结果经常是产生由匹配较差的元素所组成的计算机系统。
9.2.1 分析中的考虑因素
由于分析阶段是建立和限定所需内容的过程，因此我们需要记住如下所示的因素和考虑事项。
● 总体目标——
这些目标包括创建数据库模型时某个公司的全部目标。包括：数据库模型中的内容、所希望的结果、应该获得的结论。例如：这是新的应用程序还是需要重写的应用程序？
● 公司运作—— 这些行为包括公司的谋生手段和计算这些手段的方法。
● 业务规则—— 这是分析阶段的核心，业务规则描述了分析的内容和设计数据库模型所需要创建的内容。包括所需要的表以及表之间的基本关系。
● 规划和时间表——
对于较大的工程而言，规划和时间表非常有用。典型的项目计划包括完成人、完成工作和完成时间。为了与更多的人分享这些计划并确保满足任务独立性，更完善的计划将多任务结合在一起。例如，如果任务B需要任务A的完成，那么可以由一个人完成A任务和B任务，如果没有依赖性，那么可以由两个人在同样的时间内分别完成A任务和B任务。
● 预算——
整个工程的开销是多少？这些开销是否有效、是否值得、是否能够承担？在将市场竞争中的优势带给公司之前，这些开销是否会导致公司的破产。预算所包含的考虑内容如下所示：
· 聘请辅助人员所需的开销—— 您是否需要聘请辅助人员？辅助人员的开销通常很高。是否具有可用的熟练的人员？是否需要补充新人？是否需要花高价聘请顾问？
· 硬件开销—— 根据速度和存储容量需要对硬件需求作出评估。对于OLTP数据库而言，根据处理器的数目和规模而决定的并发性、on-board
RAM、专用硬件设备(RAID矩阵)以及网络带宽都是很重要的因素。存储空间的设计和I/O性能对于数据仓库来说也很重要。
· 维护—— 维护的简易性意味着长期的低开销。
· 培训——
终端用户和编程人员必须知道所创建系统的使用方法。否则，即使系统可用，也很难获得最大限度的利用。如果数据库设计者为某家公司引入新的数据库引擎(例如Oracle
Database)，那么进行培训是必须的要求，并且必须将培训编入预算。技术培训十分昂贵和耗时。
● 其他因素—— 其他较少注意到(但相关性没有减少)的因素包括如下内容：
· 数据的重复性——
应该避免数据的重复(条件是不牺牲性能)和过细的粒度。过细的粒度经常是过度规范化的结果。过度的规范化会使SQL代码的编写过于复杂和难以执行，还会产生诸多问题和高昂的维护代价。
提示：
过度的规范化可以清除数据中的潜在错误(违反参照完整性的错误)。这样做也会使ERD包含许多表，并会为程序员造成许多麻烦的问题。过度的规范化对于数据库设计人员来说是一件好事，但却是编程人员的噩梦。关系数据库模型设计是一种达到目的的手段，本身并不是目的。换言之，数据库模型是为编程人员和终端用户建立的。数据库模型不应该建立在过于完美的数学规则的基础上，这样做的后果是只有数据库建模者才能理解这一模型。我们应该时刻将设计的目的记在头脑中。设计的目的是满足应用程序的需求并为公司提供优势，而不是使生活变得更加复杂。
· 只读或者读写——
数据库是否只读或者要求完全的可读写？数据仓库中的数据库经常是部分只读。OLTP数据库的部分静态数据的内容要求可读。考虑到OLTP数据库的灵活性，静态表中需要使用专门的方法。
不用惊讶，对包括公司操作、业务规则、计划和时间限制、以及预算在内的所有目标的考虑可以作为整个分析过程的框架。事实上，在本节稍后的案例分析示例的开发中，这些考虑因素都将包含在内。在学习案例分析的示例之前，先了解分析企业数据库模型时所暗藏的问题。
提示：
前面所提到的“其他因素”在本节将作详细的叙述。与主题相关的因素已在本书前面的章节中进行过叙述。
9.2.2 潜在问题和误解
当分析公司数据库模型时，有很多值得考虑和记忆的消极因素。这些因素包括如下内容：
● 规范化和数据完整性
● 更多的规范化会导致更好的查询结果
● 性能
● 通用和标准的数据库模型
让我们对这些内容进一步的讨论。
1. 规范化和数据完整性
许多分析人员提出通过使用所有可用的范式来进行各种层次的规范化，从而保证数据不被丢失(冗余性)以及完全地匹配参照完整性(孤立记录)。数据库是信息的储存库。不良的应用程序编程或者不正确的数据库使用会产生问题数据。高度规范化的数据库模型可以确保较好的数据完整性，但是数据库模型本身却不会产生这些问题数据。应用程序编程人员和终端用户由于编码错误或者对数据库的不正确修改会导致这些问题的产生。
2. 更多的规范化会导致更好的查询结果
这是由很多分析者所提出的另一种观点。一些声明如下所示：
● “问题查询通常是不合适(非规范化)的数据库结构的产物。”
● “与规范化的数据库结构相比，编写快速的查询和更新操作更为简单。”
笔者的观点与上述两条完全相反。非规范化的结构会产生快速的查询并且使终端用户更容易地编写查询操作。从可操作的角度来看，非规范化的表与商业应用匹配得更真实。换言之，负责编写ad-hoc查询的忙碌的执行者可以理解表和表之间的联系方法。
在许多表之间建立查询会导致大量的连接查询。连接查询不仅编写起来十分复杂，具有讽刺意味的是，这样的查询执行起来也十分耗时。对于刚开始使用数据库的终端用户来说，编写过于复杂的连接查询几乎是不可能的。这样做并不公平。即使对于熟练的编程人员来说，在DKNF层次的规范化数据库模型上建立连接查询通常也是件很荒唐的事情。例如，在某个数据库里建立对于15张表的连接查询将会占用1GB的空间，30秒的时间。这种作法是完全无法令人接受的。笔者曾在过去见过这种情况。
提示：
数据库建模不应该是对过度完美的数学规则的表达，而是应该作为达到目的的方法。这种方法是数据库建模。目的是满足用户的要求。我们的目的不是生成无法满足用户需求但是粒度最完美的数据库模型。
3. 性能
某些分析人员声称计算机的性能、应用程序以及数据库模型与业务分析没有关系。笔者完全不同意这种说法。由于一开始没有考虑到最重要的性能因素，从而造成应用程序和整个服务环境被淘汰的情况，笔者也曾见过。性能一直是很重要的因素。离开性能来分析数据库模型就如同买下一艘新船却付不起钱——
完全是把钱往水里扔。
所有SQL代码都依赖于底层的表结构和表内容，甚至需要依赖表的标识和表的信息内容。在分析阶段应该对这些内容作出决定。毫无疑问，在分析时作出的决定会影响以后的性能。数据库和应用程序的性能是十分重要的。
4. 通用和标准的数据库模型
我们需要当心被特定的行业或者应用程序作为标准的通用数据库模型。通用数据库模型通常出现在所购买的半定制化的应用程序中。通用模型可以满足多种应用程序的要求。如果您正在使用自己的数据库模型，那么可以建立专门满足公司要求的数据库模型。通用数据库模型的许多作用域是无法应用到特定的公司要求中的。换言之，您的数据库也许会有许多无用的空表。从技术上来说，无用的表并不是真正的问题，但是它们会对编程人员和终端用户造成混淆。通用模型的另一个缺陷是它也许无法精确地满足所有的要求，同时很有可能需要修改。
标准数据库模型，尤其是为满足特定行业的需要并作为一种准则的模型，也会很危险。因为它们很可能已经过时。与通用模型一样，标准模型很可能包含冗余的表，这些表也会造成所有可能的问题和不足。如果您正在建立数据库模型，那么您也会分析实际情况，为您的公司和特定应用程序自定义构建模型；但是，作用域的减小会导致不灵活性并最终在系统中产生局限性。这样做需要达到完美的平衡。
现在我们可以了解到叙述上述内容的原因、我写这本书的原因以及阅读本章的原因。如何将理论应用到实践的方法？让我们从分析开始介绍。
