马红兵

数据分析讲堂

第四课 设计和实现OLAP模型的实践步骤

第五讲　维成员和决策环境

一、维成员

如果你想在高等和低等多维模型之间找出一条分割线，想象此线存在的一个好地方是在层次结构和个体成员之间的边界。像产品和客户这样的维，可能会存在5个到10个等级和成千上万的基础等级成员。一个包含所有2000000个客户的图表不会适合任何实际的目的，当然也不能作为摘要之用，因为成员数太多了。一个有用的模型应该是现实世界的缩小版本，而不只是复制。
列举维成员的一些代表样本在确保不发生混淆方面可能是有用的，通过成员的抽象列表建立测试模型也可能是有用的。但一旦开始在成员数很多的维的所有成员上开展工作是时，你所能做的最好的事，就是确保你自己已经对成员列表进行了充分的清理。例如，对于客户列表，你需要确信的是同一个客户没有出现多次。正如在前面讲堂中提到的，数据（或元数据，如本例中）清理是建设数据仓库的一部分。
在一个典型的大模型中，不会有超过1个或2个维有如此高的势。这也意味着大多数立方体都有一个或更多的低势维。场景和市场通常势都足够低，使得列举它们的所有成员是有用的。例如，可能只有10个不同的市场，每个市场的销售特定的一组产品，或者只有4个不同场景需要制定不同的预算。
除了区别高势维和低势维之外，把变量维与其他维独立开来也是有意义的——假定你正在使用的工具声称同样地看待所有的维，并在一个变量维内保存内容或变量名字。记住，变量维的成员，不管是有5个还是500个，将包含立方体中大部分非求和公式。毕竟，它们是你要在模型中跟踪的值，就像一个大帐户表，即使包含了500个帐户，无论是谁正在使用这一信息都需要知道其中的每一个帐户。变量通常需要以独立个体的方式来处理。
考察那些基本表，维成员信息可以通过两种基本的方式来表示：嵌入在数据表内（这时维信息通常以基于等级的方式表示为列标题），或自由地存在于父——子表内。
维成员交叉定义的单元乘以每个单元内变量的个数，将至少与输入系统的基本数据点的个数一样多。在源数据是表示事务数据的情况下，比如实际的产品销售，输入模型的数据点个数可能只是整个模型单元总数的一小部分，这时的立方体被称为稀疏的。
1． 成员间的关系
对于你所涉及立方体的每一个维来说，成员间的关系是什么样的呢？假定你正在设计商店维。商店之间的关系是什么？它们只是同一个列表中的成员而已，或者存在额外的信息使它们之间有所区别？你应该抓住这类信息的原因是为了进行模式搜索、归纳和其他分析。例如，如果你知道过去3年中销售额是如何随月份而变化的，你就能够根据过去的经验对下一月的销售做出预测。这是由于时间间隔是基数排序的。你可以定义如下的公式：
Sales, timex+1 = ( sales, timex ) + ( projectes change in sales, timex )

如果维成员只是一个名词性排序的元素列表，你就不能定义这样的公式，你也不能探究变量之间的相关性，除非你的标识符维是基数排序的。

2． 改变成员的名字

有时源表的维成员包含代码名，像SKU码，但最终用户不希望被迫与此打交道，为了最终用户的利益，你应该核实所有这些维是否需要给定维成员别名。如果认为这是必须的，你就应该确保你所购买的OLAP工具支持别名，并且检查修改名字会对已存的模型结构带来什么影响。例如，对某些产品，你需要手动地修改依赖成员名字的公式，如果此成员的名字恰好发生了改变，这种情况下，你应该尽可能早地在处理模型之前定义成员别名。

二、决策环境

通过前面的步骤，你已经得到了一个关于你的数据的多维结构，剩下的就是定义公式的任务了。在此项工作之前，你应该暂停一下并问自己如下的问题：你建立模型的目的是什么？你将定义哪些公式来达到此目的？你正在努力绘制一幅描绘你所在公司或组织内的状况图吗？你在试图预测销售、开支和毛利在下12个月内将如何发展吗？或者你正在努力提出政策建议吗？
回忆我们在前面讲过的决策活动的4个阶段：描述性的、解释性的、预测性的和指令性的。虽然OLAP工具被看成是专注于派生的描述，但你的应用可能需要其他的决策功能。假如存在的是一个单领域模型，你应该在一个单一立方体内建立所有的决策功能。从描述型公式到指令型公式的趋势，代表了同一个立方体内分析复杂度的一系列提升。指令型公式依赖于推论型或预测型公式，预测型依赖于解释型，解释型又依赖 于描述型。不管隐式或显式的，都不可能在不包含解释型和描述型公式的情况下建立一个预测型公式。所有的公式共享同一个立方体中定义的维结构。当然如果你正在一个多领域模型上工作，一般会有多个立方体。你的决策功能可能散布在所有这些立方体之中。