2.9 报告和分析的新形式
1964年，Bob Dylan 写了歌曲《The Times They Are“A-Changin”》。最可能的是，他从来不是商务智能方面的专家（虽然你永远不会知道Dylan）。但是这篇文章对如今商务智能现状是非常适用的。在一开始，用户对简单的可以让发生的事情一目了然的表格报告很满意，这之后的用户希望提供更生动的数据。接下来，用户想拥有更多的动态能力：他们想与报告中数据有所互动，并且他们想能够做到所谓的下拉和上滚窗口。新的需求接踵而至，似乎没有停止的势头。他们的愿望清单也在不断地改变。他们要求新类型的报告和分析能力。因此最大的问题是，经典的商务智能系统能胜任新的报告和分析形式吗？在后面的章节里对一些新的报告和分析形式有介绍。当有必要去实现这些新的报告和分析形式时，这毫无疑问地对商务智能系的设计和开发有深远的影响。
2.9.1 运营报告和分析
运营报告和分析是指被运营管理层所应用的报告和分析的形式。在大多数情况下，运营管理的分析需要访问几乎100%最新的数据，换句话说，（近乎）是实时数据。我们用术语运营数据代表100%达到最新的数据。
有很多案例说明运营分析存在的必要性。例如，一家零售公司也许想了解是否一辆正在运送货品到特定商店的火车应该重新定方向去一家对那些商品有更紧急需要的商店。这种需求分析运行在昨天的数据上没有任何意义。另一个应用的地方是信用卡欺诈检测。一种经典的信用卡欺诈检测形式的检测是在被盗的卡被用来购买产品时。每一次交易数据都需要被分析来看看它是否符合卡持有者的购买模式和购买是否有意义。检测之一是在很短的时间间隔内两次购买是否发生在不同的城市。例如，一次新的购买是在波士顿，上一次在旧金山的购买仅仅比其早了几秒钟，这个可能性只能在信用卡被欺诈的情况发生。但这种分析形式在对运营数据分析的时候才有意义。
对于运营报告和分析，商业用户必须至少访问到运营数据。一个巨大的挑战是大多数的数据仓库提供一天一次或一周一次的数据刷新率，所以他们不包含运营数据。另一个挑战是在经典的商务智能系统中，报告与运营数据相离太远。对于新数据，从源系统到报告的道路很长。
2.9.2 深度和大数据分析
对于很多报告和分析的形式，存储详细数据不是必须的；聚合数据和稍微聚合数据足够用了。例如，为了决定每个地区的总销售量，没有必要去存储和分析个人销售记录。例如，以用户数量方式聚合数据可能已经足够了。但是对于某些分析形式，详细数据是必需的。这叫作深度分析。当一个企业试图分析一辆卡车应该改道或者决定投放哪一条在线广告时，必须分析详细数据。要求详细数据最最有名的是时间序列分析。但是详细数据意味着数据所需要的存储将会增长巨大，可能会导致查询性能的严重问题。
一种新型的分析方式和深度分析很相似，从名字上来说很相像，称为大数据分析。许多传统信息系统存储和管理大量记录。最近，一个存储数据量比在更传统的系统要大的新系统已经出现。例如，点击流应用、基于传感器的应用和图像处理应用每天都产生庞大的数字的记录。这里记录的数量不是以百万计量的，而是有时以兆计量。分析这样量级的数据是一个巨大的挑战。
对于深度分析和大数据分析，像运营分析一样，应该制定类似的解决方案。应该允许用户直接访问生产系统和数据中转区。数据的庞大规模和一直涌入的新数据的数量使得连续地刷新数据仓库几乎是不可能的。
2.9.3 自助式报告和分析
在用户生成他们的报告之前，IT部门必须设置整个环境。自助式报告和分析允许用户用IT部门要求的最小设置来生成自己的报告。在报告必须很快完成，并且没有时间去准备一个完整的环境，自助分析是非常有用的。例如，一家航空公司想知道会有多少位乘客被明天一次特定的撞击所影响。另外，被需要的报告是一次性的，自助分析也很有帮助。在上述两种情况下，首先开发一个像数据集市或PDS一样的数据存储，其中包含了在运行报告之前所需要的聚合数据。对于第一个例子，建立一个数据存储将花费很长的时间；对于第二个例子，根本不值得这样做。
自助式可能是分析方式和报告最重要的新形式。由Aberdeen Group 在2011年3月做的调查表明超过60%的受访者把使商业用户变得更加自足，作为提供敏捷的商务智能的主要策略（见文献［2］）。（更多关于自助的知识请看7.6.9节。）
自助分析也许也被称作无计划分析，因为数据仓库的管理员不清楚哪次查询会被执行和什么时候会被执行。这意味着提前对这些查询进行优化和调整是不可能的。
2.9.4 无限制的自组织分析
除了经典的报告和分析方式，运营管理也有对于除高层特定需要数据之外的数据需求。在运营环境中，需要直接回应的情况可能会出现。想象一下一家零售公司拥有的一辆货车期望在开业时间之前运送15托盘的苏打水到波士顿的商店。不幸的是，这辆货车发动机出现故障，停在道路一侧。对于值班经理要解决的难题是找到另一种使苏打水运到商店的方式。一种方式是派一辆空货车去故障车那里，装上托盘，然后将苏打水运到指定地点。但是在指定区域会有可用的车吗？另一种方式也许是检查是否在该地区是否有另一家苏打水商店，并且能从中获得苏打水。或者安排一次新的配送会不会更好？无论选择哪种解决方案，这名经理需要访问最新的数据。给他昨天的数据将是无用的，因为那将不会告诉他现在车在哪里。
另外，由于解决方案可能不止一个，这名经理必须访问可以让他想到不同的解决方案的系统。他应该能够自由查询可用的数据。例如，他应该能够进入一个包含关键字苏打水、波士顿和火车的查询中。查询的结果应该向他展示出这个系统知道所有的关于这些关键字的信息，希望他会从那些地方找到最好的解决方案。
尽管大多数的数据仓库环境不支持这种分析形式，但很多组织能够从中受益。试想在一个医院的环境里，一名被送到医院的病人迫切需要某种特定手术。然而所有的手术室都被占用了，怎么办？找另一家医院？手术室什么时候才可用？另一个例子是由于大雾不得不临时关闭机场。你会对本应降临在那里的飞机怎么做？或者当最近降落的飞机舱门不开时，你会做什么呢？你会如何处置行李？在上述两种情境中，用户应该可以自由浏览全部信息。
这些例子的特别之处是，该分析是通过一个事件来触发。一些不可预期的事情发生，并且机构必须做出反应，而且要迅速做出反应。经典的报告对重复发生的问题起作用，但对特殊的事件没有用。在一个经典数据仓库环境中，让用户查询未定义的关系将涉及非常多的工作。现存的表必须随着新数据扩展，ETL脚本必须进行调整，等等。但是因为这是一个突发事件，根本没有时间来做这个。
在前面的情境中，需要的是一种新的分析形式—在这种形式中，用户可以分析IT部门未预定义的表格和关系。用户应当可以访问运营数据。我们称这种分析形式为无限制的自组织分析。添加形容词“无限制”用来与更加传统的自组织分析形式相区别。通过传统的自组织分析，用户可以进入任何查询，但是只有预定义的表格和关系才能使用。如果确定的关系不存在，用户不能使用他们来分析。所以尽管传统形式是自组织分析形式，但它仍然是受限的。
无限制的自组织分析很难在经典的智能系统实现，因为用户在请求数据时应该可以访问到数据，无论源系统是什么。没有时间为用户准备数据集市和PDS。这些用户需要机会去访问任意数据存储库。
2.9.5 360
保险公司的顾客定期呼叫该公司的客服中心，询问有关他们保险的问题。对于一个客服中心的接线员来说，他们所了解到的不仅直接关系到他们的保险，而且能够对顾客有360witter上发布有关公司的负面消息，呼叫有多频繁，有多少次呼叫是为了同一件事。呼叫中心的接线员接触的数据越多，接线员对顾客需求的理解越好，他就会使顾客更高兴。
2.9.6 探索性分析
想象一下在波士顿地区的一群零售店的经理发现在商店里各个品牌汽水的销售量一直非常低。很明显，他想知道为什么会这样。原因可能不会那么明显，也会有很多原因。一个原因可能是，最近给波士顿门店的交货一直被耽搁，所以产品经常缺货。也可能是很多员工因患流感而在家休息，这就可能意味着商店不能定期将货物上架，对销量有着负面的影响。当然也会有外部的原因，例如顾客由于天气原因不进行购物。另一个外部原因是竞争者进行各个品牌汽水半价的促销活动。
传统的报告并不能帮助找到问题的根源。用那些工具完成的报告将会表明，例如，销售量下降了，而不是这个问题的原因。他们被限制在只显示预先定义的汇报中，如果没有任何报告能回答问题，那么管理者将找不到背后的问题。
分析工具为管理者提供了从各个角度和每个可能层面的细节来看问题的功能。然而，它仅仅能够发现在数据库中预先定义的数据元素链接、关系、关键字和维度的关系。在一个多维的立方体中，如果销售数据和配送数据或者是员工病情之间没有联系，就不能说明是配送出了问题。
统计和数据挖掘工具同样也没有帮助，因为这些工具虽然很强大，但是只能用已有的数据制作模型。在某种程度上，我们需要引导这些工具。如果管理者认为是配送导致了问题，我们可以用工具确定确实是这一个原因。但是这不是管理者的问题，他还不知道是否是配送的问题，所以仍然在寻找原因。而且，正如预测的那样，原因可能是任何事情。
换言之，当我们对一个问题的原因有初步想法时，这些产品是非常有用的。管理者需要的是一个工具，运用这个工具他可以自己发现问题。发现了问题之后，他能够切换到使用报告和分析工具来更详细地研究这个问题。
管理者需要一个这样的工具，这个工具能够让管理者没有任何限制地查询、浏览、分析数据。它应当允许管理者在并没有被事先定义好关系的数据元素之间建立关系。他应当能够问到例如“波士顿发生了什么事？”或者“2012年5月13号所在的这一周有没有什么特别的事情发生？”等问题。当问题被解答时，他能沿这个方向继续。这就是我们所说的探索式分析或调查式分析。
不受限制的自组织分析和探索式分析之间最重要的不同就是，当一个事件发生并且很快找到答案时会使用前者。探索式分析对于那些不需要快速回复的紧急事件可能也是有用的。
在传统商务智能系统中运用探索式分析也会和不受限自组织文本分析存在同样的问题。这种形式也需要访问非常大范围的数据资源和无条理的数据资源。
2.9.7 基于文本的分析
2011年5月4日，《美国日报》报道了华尔街交易者为投资线索叫喊。他们监控并解码了话语、观点、胡言乱语，甚至是键盘所产生的发送在社交媒体网站上的笑脸符号。换句话说，他们在分析文本。
许多例子证明分析文本能够提高团队的决策进程。例如，一个保险公司可能想要分析所有的合同（文本文件）来找出他们中的多少将会在一年内到期。一个电器公司可能会对分析Twitter上的短消息感兴趣，从而找出他们的产品是否被提及，这些信息是否是积极的。考虑一个机构发出或者收到的所有邮件，网上和社交媒体网站上的所有信息。这种无条理数据形式的文本分析就被认为是基于文本的分析。
大多数当前的商务智能系统允许使用者分析结构化数据资源的数据，也就是生产的数据，但是他们不允许使用者开发非结构化的数据（文本）用于报告和分析。这个机会严重地错失了，因为无结构数据数量之巨大，丰富的信息就隐藏在其中。华尔街的情形是一个完美的例子，它向我们说明了为什么这些机构在做决定时都想要分析无结构化数据（尤其是在这个例子中）。那么，最大的问题就是：这些无结构化数据中当前未开发的资源如何运用到报告和分析中？这些无结构化数据如何与目前数据仓库里存储的结构化数据合并？我们如何丰富传统的商务智能系统使机构受益？
