2.10 传统商务智能系统的劣势
基于这一章所阐述的概念，商务智能系统已经发展了很多年。正如预想的一样，这些系统中的大多数都是基于一个链式数据存储和转换过程，此外，很多数据存储还包括衍生数据。图2-15是一个普通的商务智能系统的例子，它基于这样一个包含了数据中转区、ODS、数据仓库、大量的数据集市和一些PDS的结构。在这个系统中，数据从一个存储区被复制到另一个存储区，直到它存储在一个可以被报告工具访问的区为止。因为这些复制，数据仓库、数据集市和PDS中都包含了相当大数目的派生数据。事实上，这样一种结构其内部所有的数据，例如一个数据集市，是由数据仓库衍生而来的。
我们把有这种类型结构的系统叫作传统商务智能系统。如此多的系统以这种模式发展的原因与过去20年中硬件和软件的状况相关。这些技术在性能和扩展性方面有各自的局限性，因此，一方面，报告和分析的工作负担分散在多个数据存储区中，另一方面，转换和清洗不得不分解到众多的步骤中。
但是技术与解决方案一如既往，不管被引进的时候多么有价值，它们都有失效日期。就像那些强大的三桅杆船一样，它们在几百年前成功地用来发现了新大陆。不管它们以前如何有影响力，最终还是被轮船取代了。它跟马最终被汽车取代是一个道理，这样的例子还有好多。
传统系统的一些缺陷渐渐明显了。
缺陷1—重复数据：第一个缺陷与系统内存储的大量重复数据相关。大多数数据存储区包括从其他数据存储区派生来的数据。例如，一个数据集市的内容是从数据仓库中派生来的，那么数据集市中的数据100%是冗余的。同样，复制导致PDS中装满冗余的数据。甚至是数据中转区和数据仓库也将会有大量重叠的数据。另外，在一个数据存储区内部，大量的重复数据会被存储。这些重复数据中的大多数存储起来，用于提高查询、报告和ETL脚本的性能，这些重复数据以索引、物化查询表、汇总数据的图表和中转区等方式隐藏。
数据仓库占用了大量的存储空间—事实上，是TB，有时候甚至是PB。但是究竟有多少原始数据呢？基于英国现状的分析师Nigel Pendse做了一项大规模的实验，表明了在最大的商务智能应用中实际可访问的网络数据报告量近似是原始数据中的5GB（见文献［34］）。这是数据中的中位数。这个数据听起来是真实的，但是其他很多研究表明数据仓库的平均大小是10TB（或者更多），这两者又是如何匹配的？如果这些都是原始数据，那么根据Pendse的研究，为了得到10TB的数据，2000个不同的且其中没有重复数据元素的商务智能应用将是必须的，这几乎是不可能的。众所周知，数据仓库有时候会包括商务智能应用不能访问到的数据，例如原始细节数据、索引等，但是这还不足以解释它所占用的巨大数据空间的原因。因此，这些数据清楚地说明了大量的重复存储的数据是人们可感知的。
显然，存储这些重复数据是有原因的，这个原因就是性能。为了加速查询，我们需要那些索引、物化查询表、汇总数据的列和派生的数据存储区等。
存储不再是那么昂贵了，那么问题是什么呢？问题就是灵活性。重复数据存储得越多，结构的灵活性就越差。每一个修改都要求对重复数据进行额外的操作。保持重复数据的同步也需要很大的花费。存储重复数据将会导致数据的不一致。通过移除大多数的冗余数据，商务智能系统能够被大大简化。
缺陷2—非共享的元数据规范：传统系统的第二个缺陷可以用非共享的元数据规范来形容。许多报告和分析的工具允许我们使用特定方式，使得报告更加独立于数据资源。例如，在SAP的Business Objects体系的概念中，我们可以定义确定的术语和表格间关系。这对于所有使用这个工具所作的报告来说是完美的，但是如果我们想生成其他的报告，例如用Excel或者用IBM/Cognos的工具，又会是怎样呢？这意味着这些元数据规范必须复制到那些工具中。
总之，很多导入到工具中的规范不是共享的。企业中往往会建立各种各样的环境，在这个环境中，不同的工具用于不同的任务，所以这需要可共享规范的存在。这一不可共享规范的例子与报告和分析工具相关，但是其他的不可共享规范的例子也存在于ETL工具和数据库服务器中。不可共享的元数据规范降低了灵活性，难以管理，将会导致不一致的报告结果。
缺陷3—灵活局限性：关于灵活性的一个重要的弱点。软件工程领域已经教会我们，如果我们设计了一个系统，就需要把内存结构和应用结构分开，因为如果能把它们清晰地分开，存储结构的改变就不会总是需要应用结构的改变，反之亦然。这对于保持性和灵活性都有好处。就像1.5.1节所述的一样，David L. Parnas是首先认识到信息隐藏（别名封装）和抽象化的重要性的人之一。随后，这些概念成为其他概念，诸如面向对象、基于组件的开发、面向服务的体系结构等的基础。
每一个软件工程师都把抽象化和封装视作非常基本的概念，但是似乎商务智能专家不是这样。大多数商务智能系统完全没有基于这两个概念。几乎所有的报告都与一个特别的数据库服务技术相联系。我们来看一个简单的例子：设想我们都使用报告工具，可以写出自己的SQL语句来访问数据库，我们使用所有的所有权的钟声和数据库服务的口哨来获得最佳的性能。如果我们想要用另一个支持略有不同的SQL语言的数据库服务来代替这个数据库服务将会发生什么呢？或者我们想要选择一个基于MDX的数据库服务呢？或者也许我们想要访问一个外部数据库，它不会返回一个表格而是一个XML文件呢？在所有这些可能的情形中，我们需要极大程度地改变报告的定义。
在商务智能系统中采用抽象化和封装的概念，对于提高自身的灵活性、更容易地实现改变和采纳新的工程技术非常重要。
缺陷4—数据质量的下降：当各种相同数据的副本存在时，数据就会有不一致性的风险。换句话说，存储复制数据，正如我们所想的一样，在传统商务智能系统中广泛存在，就包含了数据质量的风险。David Loshin将它规定如下（见文献［35］）：
每次复制数据时，它也受限于数据转换的次数，它们都可能会导致数据错误。越后来的副本与原始的数据相差越大。复制的数据只会导致熵和不一致性。
在每一个商务智能系统中，目标之一应当是最小化数据的复制以达到最小化数据质量的风险。
缺陷5—有局限的运营报告支持：另一个与运营报告和分析相关联的缺陷。越来越多的企业对支持这些新的商务智能的挑战形式感兴趣。运营的商务智能系统决定着报告必须包括最新的数据。每天更新一次数据资源对他们来说是不够的。非常接近商务进程的决策者，像运营经理，尤其需要100%全新的数据。但是这如何做到呢？一个人不需要成为技术巫师也可以理解，如果为了从生产数据库中获取资源到报告中，一个数据必须从一个存储区内复制4～5次到达另一个存储区，在几微秒内完成这些工作几乎是不可能的。大多数商务智能系统没有按照运营报告与运营数据相关联的方式来设计。我们不得不简化结构来支持运营的商务智能系统。最根本的是，可以通过移除数据存储区和最少化复制步骤来简化结构。
缺陷6—基于无结构的外部数据的报告支持的局限性：在无结构化的外部的数据的分析和报告上日益增加的兴趣导致了最后一个缺陷。大多数的数据仓库中都装着来自生产数据库中的结构化数据，但是我们很少在里面找到无结构化的外部的数据。为了允许使用新的数据资源报告，许多专家提议用与内部产生数据相同的处理方式来处理这两种数据：如果它是无结构的，则使其结构化并把它复制到数据仓库中，它就可以被分析和报告所使用。换言之，这一提议是基于复制数据。他们想要改造这些数据资源使其适应传统的商务智能结构。
但是为什么不直接分析无结构化数据资源和外部数据资源本身呢？在某种程度上，那是互联网风格的解决方案。如果在互联网上搜索某些东西，我们不会首先将需要的所有的网页都复制到自己的数据库中。不，数据就在它原本的地方。所以，越来越多的文件管理系统将允许我们直接分析他们的数据库，减少了将数据复制到数据仓库中这种需求。不幸的是，许多商务智能工具不支持访问他们的系统。至于外部数据，在互联网上做有关外部数据的商务智能，在今天可以运用混搭的工具以复杂的方式完成（见1.13节）。
注意：我们想强调的是这一节提到的涉及商务智能系统的不足之处，并不是结构本身。例如，很多商务智能系统基于CIF（企业信息工厂）已经得到了发展，其中数据集市用物理的数据存储区来实现。CIF没有控制这些，但是因为软件和硬件技术的可行性，许多企业开始实现这些。数据虚拟化使得虚拟数据集市成为可能（见7.5.2节和7.6.2节）。一个商务智能系统以这种方式发展对于支持CIF仍然是合格的。
