（转摘）_《数据库设计入门经典》:构建快速执行的数据库模型_8.1 不同数据库模型的要求
提示：
虽然人很聪明，但只有正确地操作数据库才能使其正常运行。
本章很多内容在本书前几章经常提到并讨论过、甚至分析过。本章将会利用之前已经介绍过的所有内容(所有理论)并进行实践。将叙述不同类型数据库模型中，影响数据库性能的各种因素。如果有些内容是明显重复前几章的内容，则表明该内容在数据库建模中显得加倍重要。就目前关心的数据库或数据库模型而言，数据库的性能是最重要的因素。如果性能不足，那么数据库模型就无法为终端用户正常服务。至少就数据库而言，终端用户就是您的客户，也就是您的衣食父母。
提示：
客户可能是直接客户也可能是间接客户。间接客户可能是其他人的客户—— 如客户的客户。
前几章已经解释了数据库建模的理论。本章将会在数据库建模和前几章中叙述的相关理论概念之间构造一座桥梁，并在本章之后的章节中研究一个实际进行中的大型案例。本书稍后的章节将叙述实际情况中思考、分析、设计并建立数据库模型的全过程，并以此来研究数据库建模的实用性。
学习本章后，您对数据库建模方法的了解将不仅限于理论，而且会稍具实践知识。
本章主要内容：
● 影响不同类型数据库模型调整的因素
● 编写高效查询需要关注的各种细节
● 正确使用索引来提高数据库性能
● 视图
● 应用程序缓存
8.1 不同数据库模型的要求
不同类型数据库模型的性能调整完全取决于该数据库的服务对象，即连接到该数据库的应用程序。前几章已经讨论了数据库模型调整的所有相关理论，但实际上应该将事物相互联系起来。下文将解释到目前为止灌输的所有理论，先从这些理论的使用原因和用法上进行解释。
应该以不同的方式调整不同类型的数据库模型。一般来说，可以根据依赖数据库的应用程序要求来调整数据库模型。从而归结为终端用户的需求。这种划分的两种极端情况就是OLTP数据库模型和数据仓库数据库模型。接下来的几节将按照不同类型数据库模型的性能要求来区分数据库的类型。
8.1.1 影响OLTP数据库模型调整的因素
OLTP数据库是为Internet服务的。OLTP数据库的主要特征如下：
● 大用户群——OLTP数据库具有无法估量的大用户群，而且会在同一时刻要求获取相同信息。
● 极高并发性——并发性意味着相同信息的共享程度非常高。
●
数据库规模很大——按照应用类型和用户群不同，OLTP数据库有大有小。大型全球在线零售书商可能在世界各地拥有很多服务器。而在某个国家某市，仅仅刊登当地夜总会广告的网站就只有当地的访问量，因此包含的信息也少得多。
●
反应时间——对数据库变化和数据库活动作出即时、实时的反应是必需的。如果您从银行ATM机取出现金并在一小时之后在线结算您的账户，那么您一定希望看到这项事务。同样，如果您在线购物，您会希望在几分钟内(最好是几秒钟内)看到信用卡账户的交易。
● 小事务——用户会检索单条记录或非常小的连接。
●
粒度——很多OLTP数据库模型都是高度规范化的结构，但这往往是个错误。OLTP数据库允许访问小块数据；但问题在于，由于过度规范化，有时小块数据实际上却相当于很大的多表连接。如果为了在表结构中符合所有的业务规则而对该表进行规范化，那么就可能会出现性能问题，即使用户只在屏幕上查找10到20条记录也会出现。最典型的示例就是用户登录到银行账户并获取银行报表的情况。如果一张纸(或一个Web页面)中的所有信息分布在很多个表中，那么只要组合数据的响应时间超过7秒钟，用户就可能会变得急躁。想象同一时刻可能还有几千个其他用户在访问同样的数据会是什么情形。
●
可管理性——这一点通常可行，但往往非常困难。OLTP数据库用户群通常分散在全球各地，并且每年365天、每天连续24小时都有用户访问。这就使得OLTP数据库的管理复杂而又麻烦。
●
服务时段——前文已经提及，OLTP数据库必须永久处于唤醒、戒备状态并随时可供使用。这是理想情况，但许多服务提供商根据自身能力不同，其宣传的可靠性会略低于100%。低于100%的服务时间表示允许少量服务空窗时间。
8.1.2 影响客户机-服务器数据库模型调整的因素
有大量客户机-服务器环境为少量用户提供服务，一般是几十个用户甚至更少。客户机-服务器数据库的主要特征如下：
● 小用户群——公司可大可小，可能使用局域网，也可能使用广域网。预测和估算公司的内部使用情况要比满足OLTP数据库容量要求容易得多。
●
低并发程度——公司范围内的客户机-服务器数据库具有可估算的用户群。这类用户群可能非常小，也可能相对大一些，但由于能够估算用户群规模，因此服务的需求也是可以估算的。OLTP数据库的需求实际上也是可估算的；但是对OLTP数据库而言，用户群实在大得难以计算，而且OLTP数据库的使用经常会突增(或突减)，甚至偶尔还有很大的峰值(新增终端用户)。客户机-服务器数据库的并发程度要比OLTP数据库更容易预测。可预测性意味着数据库更容易为应用程序作好准备并符合应用程序的要求。
●
数据库规模——客户机-服务器数据库的规模通常较小。如果数据库规模过于庞大，客户机-服务器体系结构就无法满足这种需求。过度使用客户机-服务器体系结构要求极为昂贵的硬件。这时，利用OLTP和数据仓库体系结构就能降低成本。
● 反应时间——对单个记录的用户界面操作，客户机-服务器响应时间通常可看作实时，报表则可能多花几分钟。
●
大小事务——客户机-服务器环境根据用户界面连接数据的形式，以及报表的需求，同时存在大小事务，报表应该足够小，以便统一管理。由于用户群数量和并发性要求较低，因此这种服务是能够实现的。
●
粒度——通常，所有数据项都相对较小，表结构也更具数学严密性。利用高级别的、如3NF以上级别的规范化，客户机-服务器数据库甚至可以将大量业务规则结构合并到表结构中。
提示：
再次声明我的观点，高级别规范化的应用符合数学要求，但不一定符合实际要求。应该由应用程序进行数学运算，让数据库只负责存储数据，即不应该在数据库中放入过多处理。高级别规范化是可行的，但可能会很复杂，难以管理、修改和控制。现在应用程序SDK具备强大的处理能力和数学运算能力，且远胜于此。关系数据库的目的是结构化存储数据。对象数据库能够很好地管理数据库对象内部的处理，但关系数据库不行！
● 可管理性——这时，由于参数较小并可以估算，而且晚上人人都会回家，留出大量间歇期用于维护，因此很容易管理数据。
● 服务时段——请参见前一节“影响OLTP数据库模型调整的因素”中相同的说明。
8.1.3 影响数据仓库数据库模型调整的因素
数据仓库就是极为大量的数据以及少数几种应用环境，这几种应用环境通常也是技术难点所在。
● 最小用户群——
访问数据仓库的一般有管理员、开发人员和分析型终端用户。这类分析型终端用户通常是知识渊博的主管或中层管理人员。在数据仓库中存储许许多多旧数据的主要目的是用于对未来的预测，分析型用户正是需要这类预测信息。
● 超低并发性—— 数据仓库中的数据共享情况极少。大部分活动是只读的、或当数据库未用于报告和分析时进行事实表的批量更新。因此并发性完全不成问题。
● 恐怖的数据库规模——
数据仓库可能会大到难以置信。管理员和开发人员必须判断保留多少细节、何时删除数据、何时汇总数据以及汇总对象。很多此类判断都需要在该数据仓库的使用过程中作出，因为在设计和开发阶段很难预测将来的需求。当数据仓库非常庞大时，ad-hoc查询会导致很严重的问题。对用户进行培训，告知如何正确编写连接代码固然很重要；除此之外，对效率的预见，如提供预先建立的连接结构以及物化视图的聚合都能起到帮助作用。
提示：
物化视图能够复制数据，并允许访问数据的物理副本，因而避免了底层表访问、代价不菲的连接和聚合。关系数据库允许利用物化视图来使用查询重写。查询重写的意思是查询中对某个表的访问可能会替换会访问另一个更小、更高效的物化视图。实际上就减少了I/O活动和处理活动，能够极大地提高查询性能。
● 反应时间——
数据仓库的反应时间可以是几个小时甚至更长。反应时间与很多因素有关，例如数据仓库数据库的物理尺寸、终端用户报表和分析需求的复杂性、数据的粒度以及终端用户对数据仓库规模的了解程度。
● 惊人的大量事务—— 用户会使用简单的报表以及高度复杂的分析技术来检索大量数据。因此表数越少越好。最好用周期性的大批量操作来更新数据库。
● 超低粒度——
数据仓库最好采用星型模式，因为使用该结构能够使连接中的表数最少。星型模式中仅包含一个事实表，该事实表连接到一个包含很多描述性的、静态小维度表的层上。这样就能用单个较大的表来高效地连接很多较小的表。如果连接中有多个大规模表，那么就可能出现严重的性能问题。
● 可管理性要求高——
由于数据仓库的规模庞大，因此很难管理这种超大数据库。数据库越大，使用数据和更改数据所需的时间和硬件资源就越多。可管理性要求正在逐渐被更为成熟的大规模数据库处理技术所实现，例如非常昂贵的硬件和特殊技巧(例如群集、分区、并行处理和物化视图)。数据仓库往往是只读的大型结构。这样使灵活性更高，应对数据库较大的物理尺寸要求时，也有更多的办法。
● 服务时段——
数据仓库的服务时段一般不成问题，因为终端用户的使用往往是偶然的、突发的大量I/O活动，而不是像OLTP数据库那样持续不断的使用。且大多数I/O活动都是只读的。当然，这取决于数据仓库的实时性。实际上，如果数据仓库的实时报表要求持续的实时更新，会使所有问题都变得很麻烦。
提示：
解决数据仓库性能问题的一种方法是使用数据集市。数据集市是数据仓库的某个子部分。大型数据仓库中可能包含多个大型事实表，且这些事实表链接到相同的维度。数据集市可以认为是单个大型事实表(也可能是1个或2个事实表的星型模式)及其链接的一组维度。
8.1.4 数据库模型调整
数据库模型调整的最大问题是调整必须在设计阶段进行，且最好在所有开发工作完成之前进行。这与表以及表间关系有关。数据仓库大多是只读的，且不受生产阶段变化的限制。因此数据仓库主要是只读型环境。只读型环境能够利用特化数据库结构，这种结构能够在表中覆盖数据、复制数据以及汇总数据。例如物化视图广泛用于数据仓库，甚至某些OLTP数据库。物化视图允许复制表数据，可以复制单独表也可以连接复制，并得到数据的物理副本。根据某个查询或某一组查询的需求建立物化视图副本后，查询就可以对该副本进行，因而具有更好的性能。
调整数据库模型之所以是最困难、代价最高的做法，是因为SQL代码依赖于底层数据库模型的结构；因此调整可能导致应用程序代码的大量修改。数据库模型支持着其他程序，是其他程序的基础。因此数据库模型的更改会导致主应用程序的变化，尤其是在应用程序代码开发完成后。问题在于数据库模型调整修改(例如对底层表的修改)会影响到其他部分。由于其他部分依赖于数据库模型，那么从数据库模型向上修改所有应用程序的工程将非常浩大，使所有应用程序都需要修改。这正是要在应用程序开发之前建立正确数据库模型的原因。遗憾的是，我们的世界并不理想，我们只能争取做好。数据库模型表结构的大改动常常会导致应用软件的完全重写。不过已经有了数据库模型开发后的性能调整方法，即创建候补索引。存储过程同样有助于划分、加速和组织现有数据库。
在数据库模型调整中，最坏情况和代价最高的情况是规范化、非规范化、参照完整性和表结构的变化、以及其他更改基本表结构的情况。最好情况，对现有表和表间关系影响最小的，例如候补索引、物化视图、群集和其他技巧都有助于提高数据库模型的性能，而不会干涉到关键的底层表结构。数据库对象例如物化视图和集群能够创建现有表结构的副本或覆盖，且不会影响到现有的表，从而避免表的修改，并显著地避免了对任何相关应用程序的修改，因为这些应用程序代码可能已经完成、经过测试、调试并用于实际生产环境。覆盖与复制副本的缺点在于能够创建的对象(如物化视图)数量受限制。创建过多对象反而不利于提高性能。
这就是为什么OLTP数据库粒度较低、非规范化和小数据量的原因。另一个极端的数据仓库同样要求较低粒度，需要高度非规范化的(简单的)表结构来最小化连接查询中的表数，这样就不会严重阻碍数据仓库的报告性能。
虽然人很聪明，但只有正确地操作数据库才能使其正常运行。
本章很多内容在本书前几章经常提到并讨论过、甚至分析过。本章将会利用之前已经介绍过的所有内容(所有理论)并进行实践。将叙述不同类型数据库模型中，影响数据库性能的各种因素。如果有些内容是明显重复前几章的内容，则表明该内容在数据库建模中显得加倍重要。就目前关心的数据库或数据库模型而言，数据库的性能是最重要的因素。如果性能不足，那么数据库模型就无法为终端用户正常服务。至少就数据库而言，终端用户就是您的客户，也就是您的衣食父母。
提示：
客户可能是直接客户也可能是间接客户。间接客户可能是其他人的客户—— 如客户的客户。
前几章已经解释了数据库建模的理论。本章将会在数据库建模和前几章中叙述的相关理论概念之间构造一座桥梁，并在本章之后的章节中研究一个实际进行中的大型案例。本书稍后的章节将叙述实际情况中思考、分析、设计并建立数据库模型的全过程，并以此来研究数据库建模的实用性。
学习本章后，您对数据库建模方法的了解将不仅限于理论，而且会稍具实践知识。
本章主要内容：
● 影响不同类型数据库模型调整的因素
● 编写高效查询需要关注的各种细节
● 正确使用索引来提高数据库性能
● 视图
● 应用程序缓存
8.1 不同数据库模型的要求
不同类型数据库模型的性能调整完全取决于该数据库的服务对象，即连接到该数据库的应用程序。前几章已经讨论了数据库模型调整的所有相关理论，但实际上应该将事物相互联系起来。下文将解释到目前为止灌输的所有理论，先从这些理论的使用原因和用法上进行解释。
应该以不同的方式调整不同类型的数据库模型。一般来说，可以根据依赖数据库的应用程序要求来调整数据库模型。从而归结为终端用户的需求。这种划分的两种极端情况就是OLTP数据库模型和数据仓库数据库模型。接下来的几节将按照不同类型数据库模型的性能要求来区分数据库的类型。
8.1.1 影响OLTP数据库模型调整的因素
OLTP数据库是为Internet服务的。OLTP数据库的主要特征如下：
● 大用户群——OLTP数据库具有无法估量的大用户群，而且会在同一时刻要求获取相同信息。
● 极高并发性——并发性意味着相同信息的共享程度非常高。
●
数据库规模很大——按照应用类型和用户群不同，OLTP数据库有大有小。大型全球在线零售书商可能在世界各地拥有很多服务器。而在某个国家某市，仅仅刊登当地夜总会广告的网站就只有当地的访问量，因此包含的信息也少得多。
●
反应时间——对数据库变化和数据库活动作出即时、实时的反应是必需的。如果您从银行ATM机取出现金并在一小时之后在线结算您的账户，那么您一定希望看到这项事务。同样，如果您在线购物，您会希望在几分钟内(最好是几秒钟内)看到信用卡账户的交易。
● 小事务——用户会检索单条记录或非常小的连接。
●
粒度——很多OLTP数据库模型都是高度规范化的结构，但这往往是个错误。OLTP数据库允许访问小块数据；但问题在于，由于过度规范化，有时小块数据实际上却相当于很大的多表连接。如果为了在表结构中符合所有的业务规则而对该表进行规范化，那么就可能会出现性能问题，即使用户只在屏幕上查找10到20条记录也会出现。最典型的示例就是用户登录到银行账户并获取银行报表的情况。如果一张纸(或一个Web页面)中的所有信息分布在很多个表中，那么只要组合数据的响应时间超过7秒钟，用户就可能会变得急躁。想象同一时刻可能还有几千个其他用户在访问同样的数据会是什么情形。
●
可管理性——这一点通常可行，但往往非常困难。OLTP数据库用户群通常分散在全球各地，并且每年365天、每天连续24小时都有用户访问。这就使得OLTP数据库的管理复杂而又麻烦。
●
服务时段——前文已经提及，OLTP数据库必须永久处于唤醒、戒备状态并随时可供使用。这是理想情况，但许多服务提供商根据自身能力不同，其宣传的可靠性会略低于100%。低于100%的服务时间表示允许少量服务空窗时间。
8.1.2 影响客户机-服务器数据库模型调整的因素
有大量客户机-服务器环境为少量用户提供服务，一般是几十个用户甚至更少。客户机-服务器数据库的主要特征如下：
● 小用户群——公司可大可小，可能使用局域网，也可能使用广域网。预测和估算公司的内部使用情况要比满足OLTP数据库容量要求容易得多。
●
低并发程度——公司范围内的客户机-服务器数据库具有可估算的用户群。这类用户群可能非常小，也可能相对大一些，但由于能够估算用户群规模，因此服务的需求也是可以估算的。OLTP数据库的需求实际上也是可估算的；但是对OLTP数据库而言，用户群实在大得难以计算，而且OLTP数据库的使用经常会突增(或突减)，甚至偶尔还有很大的峰值(新增终端用户)。客户机-服务器数据库的并发程度要比OLTP数据库更容易预测。可预测性意味着数据库更容易为应用程序作好准备并符合应用程序的要求。
●
数据库规模——客户机-服务器数据库的规模通常较小。如果数据库规模过于庞大，客户机-服务器体系结构就无法满足这种需求。过度使用客户机-服务器体系结构要求极为昂贵的硬件。这时，利用OLTP和数据仓库体系结构就能降低成本。
● 反应时间——对单个记录的用户界面操作，客户机-服务器响应时间通常可看作实时，报表则可能多花几分钟。
●
大小事务——客户机-服务器环境根据用户界面连接数据的形式，以及报表的需求，同时存在大小事务，报表应该足够小，以便统一管理。由于用户群数量和并发性要求较低，因此这种服务是能够实现的。
●
粒度——通常，所有数据项都相对较小，表结构也更具数学严密性。利用高级别的、如3NF以上级别的规范化，客户机-服务器数据库甚至可以将大量业务规则结构合并到表结构中。
提示：
再次声明我的观点，高级别规范化的应用符合数学要求，但不一定符合实际要求。应该由应用程序进行数学运算，让数据库只负责存储数据，即不应该在数据库中放入过多处理。高级别规范化是可行的，但可能会很复杂，难以管理、修改和控制。现在应用程序SDK具备强大的处理能力和数学运算能力，且远胜于此。关系数据库的目的是结构化存储数据。对象数据库能够很好地管理数据库对象内部的处理，但关系数据库不行！
● 可管理性——这时，由于参数较小并可以估算，而且晚上人人都会回家，留出大量间歇期用于维护，因此很容易管理数据。
● 服务时段——请参见前一节“影响OLTP数据库模型调整的因素”中相同的说明。
8.1.3 影响数据仓库数据库模型调整的因素
数据仓库就是极为大量的数据以及少数几种应用环境，这几种应用环境通常也是技术难点所在。
● 最小用户群——
访问数据仓库的一般有管理员、开发人员和分析型终端用户。这类分析型终端用户通常是知识渊博的主管或中层管理人员。在数据仓库中存储许许多多旧数据的主要目的是用于对未来的预测，分析型用户正是需要这类预测信息。
● 超低并发性—— 数据仓库中的数据共享情况极少。大部分活动是只读的、或当数据库未用于报告和分析时进行事实表的批量更新。因此并发性完全不成问题。
● 恐怖的数据库规模——
数据仓库可能会大到难以置信。管理员和开发人员必须判断保留多少细节、何时删除数据、何时汇总数据以及汇总对象。很多此类判断都需要在该数据仓库的使用过程中作出，因为在设计和开发阶段很难预测将来的需求。当数据仓库非常庞大时，ad-hoc查询会导致很严重的问题。对用户进行培训，告知如何正确编写连接代码固然很重要；除此之外，对效率的预见，如提供预先建立的连接结构以及物化视图的聚合都能起到帮助作用。
提示：
物化视图能够复制数据，并允许访问数据的物理副本，因而避免了底层表访问、代价不菲的连接和聚合。关系数据库允许利用物化视图来使用查询重写。查询重写的意思是查询中对某个表的访问可能会替换会访问另一个更小、更高效的物化视图。实际上就减少了I/O活动和处理活动，能够极大地提高查询性能。
● 反应时间——
数据仓库的反应时间可以是几个小时甚至更长。反应时间与很多因素有关，例如数据仓库数据库的物理尺寸、终端用户报表和分析需求的复杂性、数据的粒度以及终端用户对数据仓库规模的了解程度。
● 惊人的大量事务—— 用户会使用简单的报表以及高度复杂的分析技术来检索大量数据。因此表数越少越好。最好用周期性的大批量操作来更新数据库。
● 超低粒度——
数据仓库最好采用星型模式，因为使用该结构能够使连接中的表数最少。星型模式中仅包含一个事实表，该事实表连接到一个包含很多描述性的、静态小维度表的层上。这样就能用单个较大的表来高效地连接很多较小的表。如果连接中有多个大规模表，那么就可能出现严重的性能问题。
● 可管理性要求高——
由于数据仓库的规模庞大，因此很难管理这种超大数据库。数据库越大，使用数据和更改数据所需的时间和硬件资源就越多。可管理性要求正在逐渐被更为成熟的大规模数据库处理技术所实现，例如非常昂贵的硬件和特殊技巧(例如群集、分区、并行处理和物化视图)。数据仓库往往是只读的大型结构。这样使灵活性更高，应对数据库较大的物理尺寸要求时，也有更多的办法。
● 服务时段——
数据仓库的服务时段一般不成问题，因为终端用户的使用往往是偶然的、突发的大量I/O活动，而不是像OLTP数据库那样持续不断的使用。且大多数I/O活动都是只读的。当然，这取决于数据仓库的实时性。实际上，如果数据仓库的实时报表要求持续的实时更新，会使所有问题都变得很麻烦。
提示：
解决数据仓库性能问题的一种方法是使用数据集市。数据集市是数据仓库的某个子部分。大型数据仓库中可能包含多个大型事实表，且这些事实表链接到相同的维度。数据集市可以认为是单个大型事实表(也可能是1个或2个事实表的星型模式)及其链接的一组维度。
8.1.4 数据库模型调整
数据库模型调整的最大问题是调整必须在设计阶段进行，且最好在所有开发工作完成之前进行。这与表以及表间关系有关。数据仓库大多是只读的，且不受生产阶段变化的限制。因此数据仓库主要是只读型环境。只读型环境能够利用特化数据库结构，这种结构能够在表中覆盖数据、复制数据以及汇总数据。例如物化视图广泛用于数据仓库，甚至某些OLTP数据库。物化视图允许复制表数据，可以复制单独表也可以连接复制，并得到数据的物理副本。根据某个查询或某一组查询的需求建立物化视图副本后，查询就可以对该副本进行，因而具有更好的性能。
调整数据库模型之所以是最困难、代价最高的做法，是因为SQL代码依赖于底层数据库模型的结构；因此调整可能导致应用程序代码的大量修改。数据库模型支持着其他程序，是其他程序的基础。因此数据库模型的更改会导致主应用程序的变化，尤其是在应用程序代码开发完成后。问题在于数据库模型调整修改(例如对底层表的修改)会影响到其他部分。由于其他部分依赖于数据库模型，那么从数据库模型向上修改所有应用程序的工程将非常浩大，使所有应用程序都需要修改。这正是要在应用程序开发之前建立正确数据库模型的原因。遗憾的是，我们的世界并不理想，我们只能争取做好。数据库模型表结构的大改动常常会导致应用软件的完全重写。不过已经有了数据库模型开发后的性能调整方法，即创建候补索引。存储过程同样有助于划分、加速和组织现有数据库。
在数据库模型调整中，最坏情况和代价最高的情况是规范化、非规范化、参照完整性和表结构的变化、以及其他更改基本表结构的情况。最好情况，对现有表和表间关系影响最小的，例如候补索引、物化视图、群集和其他技巧都有助于提高数据库模型的性能，而不会干涉到关键的底层表结构。数据库对象例如物化视图和集群能够创建现有表结构的副本或覆盖，且不会影响到现有的表，从而避免表的修改，并显著地避免了对任何相关应用程序的修改，因为这些应用程序代码可能已经完成、经过测试、调试并用于实际生产环境。覆盖与复制副本的缺点在于能够创建的对象(如物化视图)数量受限制。创建过多对象反而不利于提高性能。
这就是为什么OLTP数据库粒度较低、非规范化和小数据量的原因。另一个极端的数据仓库同样要求较低粒度，需要高度非规范化的(简单的)表结构来最小化连接查询中的表数，这样就不会严重阻碍数据仓库的报告性能。
