（转摘）_《数据库设计入门经典》:通过分析进行规划与准备_9.1 创建数据库模型的步骤
提示：
火箭科学是一门精确的科学。分析却绝不是一门精确的科学。
在筹划本书的时候，我刚好想到“规划”一词。如果没有规划，人类将会生存在哪里？也许仍然挂在粗糙的树枝上，时不时地喊着“啊！……”。本书的前几章不仅对创建关系数据库模型的理论进行了阐述，而且对这一模型的发展历史及产生原因等主题也进行了讨论。
在现阶段，设计关系数据库模型仍然是有意义的。另外，不同的应用程序会对同一主题产生不同的需求，从而导致专门的数据仓库的数据库模型的产生。与OLTP(事务型)类型的数据库模型结构相比，数据仓库数据库模型由于非规范化而或多或少地难以理解。OLTP的ERD和数据仓库数据库模型的ERD看起来很相似，但是二者在结构上是完全不同的。这是由于数据仓库数据库模型被彻底地非规范化。本书之所以着重介绍OLTP模型和数据仓库数据库模型的原因也基于此。二者紧密相关并且都要求通过透彻的分析和准备来保证可用的结果。
本章将从一个案例分析开始，在这个案例中，理论信息(从前面的章节中获得)将应用到现实情况中。本章(以及接下来的3章)将采用实例对前7章所阐述的理论加以应用。这样做的原因在于理论和实践是两个完全不同的方面。理论描述和阐明一组规则，试图通过形式化方法来量化和解释真实世界。形式化方法的本质是诸如方法论一类的精确数学表达式。方法论是指可以应用到现实情况中的途径。在本书中，所希望的结果是合用的基本结构，即：关系数据库模型。
如果不采用明晰的形式将理论应用到实践中，那么自始至终，我们对于理论的理解将会在记忆中逐渐消失。换言之，如果不能够真正地理解所学的知识，不能够明确学习这些知识的目的，那么记住知识是没有用处的。通过案例分析可以帮助我们从理论的应用中学到知识。
看起来这样做似乎有些傻，但是我发现理解可以使自己能够不经意地而不是刻意地记住关于某个主题的所有内容。我更倾向于理解而不是简单的记忆。理解使我更能够将所学的知识应用到陌生的情景中。通过对于这些章节中案例分析的理解，可以学到数据库设计的各个部分是如何组合在一起的。
到目前为止，您已经阅读过关系数据库模型的历史、它的实际应用程序以及许许多多的理论。甚至某些较难的内容(例如数据仓库及其性能)也简要地浏览过。当所有的信息填满您的大脑时，如果不加以说明，那么这些信息的作用在哪里？通过渐进的虚构案例分析进行说明正是本书从本章开始的方式。前面的章节虽然已经提供了足够的示例，但是它们的规模都比较小。本章将开始对一个较大规模案例进行分析。这样做的目的是说明并描述为整个应用程序创建数据库模型的过程。这个案例将在本章的一开始出现。唯一需要的准备知识是知道鼠标的使用方法并且了解计算机为何物。本章将从为OLTP数据库和数据仓库创建合适的数据库模型开始。特定的企业类型是某个联机拍卖Web站点。联机拍卖不仅包含许多并发的行为(OLTP行为)，也包含大量的潜在历史事务(数据仓库行为)。
本章从最基本的要素开始。最基本的要素不是指抽出一张纸并在上面画出表的结构，或是安装最感兴趣的ERD工具并开始熟悉它。数据库模型设计(以及任何软件项目的设计)的起始步骤应该是草拟出对所需内容的具体分析。您应该与用户进行交谈，分析应该构建什么软件。当然，开发的成本和时间也是很重要的考虑因素。本章的目的是希望在潜移默化中传递给读者这样的信息：我们应该专注于从合适的人中获得正确信息的方法。目标是以结构的形式表示信息。
当您结束本章的阅读之后，将会深入地理解分析过程，这个分析过程不仅适用于数据库建模，也同样适用于其他软件的开发过程。更重要的是，您应该了解规划的重要性。也许我们可以在事先不绘图、不设计和不施工的情况下修建出一座桥。作为工程师，能够避免作许多复杂的土木工程中的数学计算。但是如果不对桥梁进行规划会发生什么情况？想象一座未经任何规划而建造的桥梁。付钱请工程师造桥的人很有可能会谨慎地要求建造者首先从桥上走过去。
本章主要内容：
● 分析和设计的基本要素
● 设计的步骤
● 与分析相关的常见问题和误解
● 追踪书面文档的价值
● 创建符合要求的数据库模型的方法
● 用业务规则对数据库模型进行细化的途径
● 将目前所学知识应用到综合案例分析中的方式
9.1 创建数据库模型的步骤
在认真地开始案例分析示例之前，您需要先学习一下本节和以下几节的课程。在构建数据库模型的系统化过程(“是什么和如何做”)方面包含许多信息。
数据库模型的建立可以分成若干独立的步骤(与所有的软件开发过程一样)。这些步骤可以大略地定义如下：
(1) 分析
(2) 设计
(3) 构造
(4) 实现
下面将简单地介绍每个步骤的细节。
9.1.1 步骤1：分析
分析情况或公司是通过对终端用户的访问来寻求最初事实的过程。具备额外知识和公司内部操作知识的计算机技术人员如果在场，那么他们也是需要访问的对象。
提示：
仅仅通过访问技术人员并不能获得正确的分析。我们所要求的是对某个客户或某种情况的全面描述。终端用户是那些最终会使用产品的人。终端用户显得更为重要！数据库系统的建立目的是针对应用程序。由技术人员编写应用程序。作为数据库设计人员或建模人员，您所提供产品的最终接受人是终端用户。
正如前面所述，分析更多地是关于需求的内容，而不是关于提供这些内容的方法。为了实现这些需求，数据库模型需要完成的工作是什么？实现这些需求的途径则是另一个不同的问题。分析的本质是对某项商业行为的描述。公司应该通过何种途径来获得利润？如果某家公司为汽车制造轮胎，那么它很有可能做如下几件事情：购买橡胶、钢铁和用于加固的尼龙、购买阀门、为轮胎作广告以及和其他商品一起销售轮胎。分析有助于了解公司从原材料到获得最终产品的所有步骤。在轮胎制造商的案例中，原材料是橡胶、钢铁、尼龙和阀门。最终产品则是轮胎。
提示：
分析是否完全是某个公司谋生的途径？这种说法是否将分析等同于数据库中表的概念？表与表之间最基本和最本质的关系又是什么？
分析对表的总体结构作出定义。某个拍卖Web站点也许会同时包含卖家表和投标者表。根据信息的内容，必定能够知道这些表中应该包含的内容。这两张表是否应该分别包含卖家和投标者的地址？分析仅仅是作出定义。它不能够对地址所使用字段的数目或是字段的数据类型作出描述。分析只是确定地址字段确实存在，以及哪个表或那些表需要地址信息的表。
9.1.2 步骤2：设计
设计包括通过可用的软件工具来利用在分析过程中所发现的知识，并判断分析结果所适用的场合。分析阶段决定应该创建的事物。设计阶段通过确定创建表的方法将分析结果进一步加以利用。这一阶段包括表、表的字段和数据类型。更为重要的是，设计阶段包括将所有要素联系在一起的方法。
分析对表、表中的信息以及表与表之间的基本关系作出定义。将设计阶段的所有要素以最基本的形式联系在一起就是对参照完整性的精确定义。由于参照完整性(Referential
integrity)是对表与表之间关系的加强，因此它是一种设计过程。表与表之间关系的最初建立是分析过程，而不是设计过程。
换言之，分析定义要做什么；设计则组织如何做。设计阶段引入数据库建模细化过程的概念，例如：规范化和非规范化。根据应用程序的构造，设计阶段将开始为前端用户进行“零碎”地定义，例如报表和图形用户界面(GUI)的屏幕。
提示：
图形化地构建表、添加字段、定义数据结构以及应用参照完整性。通过规范化和非规范化的过程可以达到细化的目的。
9.1.3 步骤3：构造
在这一阶段，需要构建和测试代码。对于数据库模型而言，需要为创建表、参照完整性主键、索引以及存储过程构建脚本。换言之，在这一步骤中，需要构建能够创建表的脚本并加以执行。
9.1.4 步骤4：实现
这是整个过程中的最后一步。在这一步中，您将创建某个数据库。换言之，在整个过程中，这一步是将全部理论应用到实践的阶段。
注意：
本书主要关注的是分析阶段的全部内容和设计阶段的部分内容。正如刚才所提到的那样，构造主要关于测试和验证。实现则是将前3个阶段的成果产品化。本书的内容是数据库建模(分析与设计)。构造和实现阶段与本书关系不大；但是，我们必须明确的是：分析与设计并不能完成整个建立过程。我们需要通过物理的构造和实现来获得最终的结果。
本节稍后将介绍的案例分析的示例是关于数据库模型中所需内容的分析(即整个过程的分析阶段)。让我们把注意力集中到分析上来。何为分析？为数据库模型进行分析过程的方法又是什么？
火箭科学是一门精确的科学。分析却绝不是一门精确的科学。
在筹划本书的时候，我刚好想到“规划”一词。如果没有规划，人类将会生存在哪里？也许仍然挂在粗糙的树枝上，时不时地喊着“啊！……”。本书的前几章不仅对创建关系数据库模型的理论进行了阐述，而且对这一模型的发展历史及产生原因等主题也进行了讨论。
在现阶段，设计关系数据库模型仍然是有意义的。另外，不同的应用程序会对同一主题产生不同的需求，从而导致专门的数据仓库的数据库模型的产生。与OLTP(事务型)类型的数据库模型结构相比，数据仓库数据库模型由于非规范化而或多或少地难以理解。OLTP的ERD和数据仓库数据库模型的ERD看起来很相似，但是二者在结构上是完全不同的。这是由于数据仓库数据库模型被彻底地非规范化。本书之所以着重介绍OLTP模型和数据仓库数据库模型的原因也基于此。二者紧密相关并且都要求通过透彻的分析和准备来保证可用的结果。
本章将从一个案例分析开始，在这个案例中，理论信息(从前面的章节中获得)将应用到现实情况中。本章(以及接下来的3章)将采用实例对前7章所阐述的理论加以应用。这样做的原因在于理论和实践是两个完全不同的方面。理论描述和阐明一组规则，试图通过形式化方法来量化和解释真实世界。形式化方法的本质是诸如方法论一类的精确数学表达式。方法论是指可以应用到现实情况中的途径。在本书中，所希望的结果是合用的基本结构，即：关系数据库模型。
如果不采用明晰的形式将理论应用到实践中，那么自始至终，我们对于理论的理解将会在记忆中逐渐消失。换言之，如果不能够真正地理解所学的知识，不能够明确学习这些知识的目的，那么记住知识是没有用处的。通过案例分析可以帮助我们从理论的应用中学到知识。
看起来这样做似乎有些傻，但是我发现理解可以使自己能够不经意地而不是刻意地记住关于某个主题的所有内容。我更倾向于理解而不是简单的记忆。理解使我更能够将所学的知识应用到陌生的情景中。通过对于这些章节中案例分析的理解，可以学到数据库设计的各个部分是如何组合在一起的。
到目前为止，您已经阅读过关系数据库模型的历史、它的实际应用程序以及许许多多的理论。甚至某些较难的内容(例如数据仓库及其性能)也简要地浏览过。当所有的信息填满您的大脑时，如果不加以说明，那么这些信息的作用在哪里？通过渐进的虚构案例分析进行说明正是本书从本章开始的方式。前面的章节虽然已经提供了足够的示例，但是它们的规模都比较小。本章将开始对一个较大规模案例进行分析。这样做的目的是说明并描述为整个应用程序创建数据库模型的过程。这个案例将在本章的一开始出现。唯一需要的准备知识是知道鼠标的使用方法并且了解计算机为何物。本章将从为OLTP数据库和数据仓库创建合适的数据库模型开始。特定的企业类型是某个联机拍卖Web站点。联机拍卖不仅包含许多并发的行为(OLTP行为)，也包含大量的潜在历史事务(数据仓库行为)。
本章从最基本的要素开始。最基本的要素不是指抽出一张纸并在上面画出表的结构，或是安装最感兴趣的ERD工具并开始熟悉它。数据库模型设计(以及任何软件项目的设计)的起始步骤应该是草拟出对所需内容的具体分析。您应该与用户进行交谈，分析应该构建什么软件。当然，开发的成本和时间也是很重要的考虑因素。本章的目的是希望在潜移默化中传递给读者这样的信息：我们应该专注于从合适的人中获得正确信息的方法。目标是以结构的形式表示信息。
当您结束本章的阅读之后，将会深入地理解分析过程，这个分析过程不仅适用于数据库建模，也同样适用于其他软件的开发过程。更重要的是，您应该了解规划的重要性。也许我们可以在事先不绘图、不设计和不施工的情况下修建出一座桥。作为工程师，能够避免作许多复杂的土木工程中的数学计算。但是如果不对桥梁进行规划会发生什么情况？想象一座未经任何规划而建造的桥梁。付钱请工程师造桥的人很有可能会谨慎地要求建造者首先从桥上走过去。
本章主要内容：
● 分析和设计的基本要素
● 设计的步骤
● 与分析相关的常见问题和误解
● 追踪书面文档的价值
● 创建符合要求的数据库模型的方法
● 用业务规则对数据库模型进行细化的途径
● 将目前所学知识应用到综合案例分析中的方式
9.1 创建数据库模型的步骤
在认真地开始案例分析示例之前，您需要先学习一下本节和以下几节的课程。在构建数据库模型的系统化过程(“是什么和如何做”)方面包含许多信息。
数据库模型的建立可以分成若干独立的步骤(与所有的软件开发过程一样)。这些步骤可以大略地定义如下：
(1) 分析
(2) 设计
(3) 构造
(4) 实现
下面将简单地介绍每个步骤的细节。
9.1.1 步骤1：分析
分析情况或公司是通过对终端用户的访问来寻求最初事实的过程。具备额外知识和公司内部操作知识的计算机技术人员如果在场，那么他们也是需要访问的对象。
提示：
仅仅通过访问技术人员并不能获得正确的分析。我们所要求的是对某个客户或某种情况的全面描述。终端用户是那些最终会使用产品的人。终端用户显得更为重要！数据库系统的建立目的是针对应用程序。由技术人员编写应用程序。作为数据库设计人员或建模人员，您所提供产品的最终接受人是终端用户。
正如前面所述，分析更多地是关于需求的内容，而不是关于提供这些内容的方法。为了实现这些需求，数据库模型需要完成的工作是什么？实现这些需求的途径则是另一个不同的问题。分析的本质是对某项商业行为的描述。公司应该通过何种途径来获得利润？如果某家公司为汽车制造轮胎，那么它很有可能做如下几件事情：购买橡胶、钢铁和用于加固的尼龙、购买阀门、为轮胎作广告以及和其他商品一起销售轮胎。分析有助于了解公司从原材料到获得最终产品的所有步骤。在轮胎制造商的案例中，原材料是橡胶、钢铁、尼龙和阀门。最终产品则是轮胎。
提示：
分析是否完全是某个公司谋生的途径？这种说法是否将分析等同于数据库中表的概念？表与表之间最基本和最本质的关系又是什么？
分析对表的总体结构作出定义。某个拍卖Web站点也许会同时包含卖家表和投标者表。根据信息的内容，必定能够知道这些表中应该包含的内容。这两张表是否应该分别包含卖家和投标者的地址？分析仅仅是作出定义。它不能够对地址所使用字段的数目或是字段的数据类型作出描述。分析只是确定地址字段确实存在，以及哪个表或那些表需要地址信息的表。
9.1.2 步骤2：设计
设计包括通过可用的软件工具来利用在分析过程中所发现的知识，并判断分析结果所适用的场合。分析阶段决定应该创建的事物。设计阶段通过确定创建表的方法将分析结果进一步加以利用。这一阶段包括表、表的字段和数据类型。更为重要的是，设计阶段包括将所有要素联系在一起的方法。
分析对表、表中的信息以及表与表之间的基本关系作出定义。将设计阶段的所有要素以最基本的形式联系在一起就是对参照完整性的精确定义。由于参照完整性(Referential
integrity)是对表与表之间关系的加强，因此它是一种设计过程。表与表之间关系的最初建立是分析过程，而不是设计过程。
换言之，分析定义要做什么；设计则组织如何做。设计阶段引入数据库建模细化过程的概念，例如：规范化和非规范化。根据应用程序的构造，设计阶段将开始为前端用户进行“零碎”地定义，例如报表和图形用户界面(GUI)的屏幕。
提示：
图形化地构建表、添加字段、定义数据结构以及应用参照完整性。通过规范化和非规范化的过程可以达到细化的目的。
9.1.3 步骤3：构造
在这一阶段，需要构建和测试代码。对于数据库模型而言，需要为创建表、参照完整性主键、索引以及存储过程构建脚本。换言之，在这一步骤中，需要构建能够创建表的脚本并加以执行。
9.1.4 步骤4：实现
这是整个过程中的最后一步。在这一步中，您将创建某个数据库。换言之，在整个过程中，这一步是将全部理论应用到实践的阶段。
注意：
本书主要关注的是分析阶段的全部内容和设计阶段的部分内容。正如刚才所提到的那样，构造主要关于测试和验证。实现则是将前3个阶段的成果产品化。本书的内容是数据库建模(分析与设计)。构造和实现阶段与本书关系不大；但是，我们必须明确的是：分析与设计并不能完成整个建立过程。我们需要通过物理的构造和实现来获得最终的结果。
本节稍后将介绍的案例分析的示例是关于数据库模型中所需内容的分析(即整个过程的分析阶段)。让我们把注意力集中到分析上来。何为分析？为数据库模型进行分析过程的方法又是什么？
