马红兵

数据分析讲堂

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

第三讲　立方体和维

你需要进行的第一件设计是模型的逻辑立方体和维结构。即使你正在使用的是超立方体产品，你也需要把所有的数据放到一个物理立方体内进行交互，同样，查看数据的逻辑立方体结构也是有用的。
虽然人们可以在不提及变量的情况下谈论维结构的设计，OLAP工具也允许你在没有任何变量信息的情况下创建维结构，并将其链接建立立方体，但由于维（或作为定位器的类型）的用途是个体化变量的值，为正确地确定维，你仍需考虑变量。变量是要展现、存储、访问和操纵的内容，并且随着维组合的不同而变化。处理的方法是找出跟踪、测量或计算的变量，并根据它变化所依赖的定位器维分组。
比如，对一个销售应用来说，要把所有的东西都放在一个业务模型内，变量可能包括销售额、成本和销售量，维可能包括时间、市场和产品。对金融应用来说，变量可能包含账户余额和信用评级，维饱含账户号码、分支号码、账户类型和时间。对于预算计划应用，变量可能包含预期收入、head count、间接费用和分配的开支，维可能组织为条目、时间和方案。与用户交谈，他们应该能告诉你基本内容是什么以及何种方式比变化。
假设你正在以表格形式查看数据源，这些表格包含了关键字列和属性列，你就是要寻找非关键字属性作为可能的变量，寻找关键字作为可能的维。如果似乎所有的数据都在一个称为数据或值得列内，那么寻找一个列作为包含变量名字的变量维。
如果你的起始点包含基本表，则你能从基本表使用的链接中抽出一些基本维。比如，给定一个包含商店、时间、产品、销售和支出的表，你很可能把商店、时间和产品定义为维，并把支持和销售定义为变量维的成员。不同工具间惟一的差别是，你是把商店、时间和产品定义为OLAP系统内的维，还是把它们定义为SQL数据库内的查询表维，以及是否把销售和开支定义为一个变量维的成员，亦或将其看成是维商店、时间和产品的变量。无论哪种方法，它们的含义都是一样的。有些OLAP产品甚至能够在你给出表格形式的数据源时自动建立立方体。不同供应商的表格形式可能不同，但一般不是类型0就是类型1。
有时基本表存放的叶子层次的数据并用另外一些表存放层次信息，这时要依照层次表中的定义把源表连接到维的叶子层上。
如果存在多个表，那么观察这些表，并问自己表中的事实是否相互包含。是否有些关键字，如时间、地点或方案，在一个表中隐含但是在其他表中直接可见？表之间是否存在互相关联的关键字从而能通过某种方式将其合并在一个立方体内？是否一个表表示西北地区同时有另外一个描述南部？是否有些表你找不出合并其关键字结构的方法，两个表中的数据也无法访入共同维集合内？这时这些表很可能应该用不同的立方体建模。为了更加确信，你应该执行过去介绍过的密度检验方法。
如果源数据是在电子表格中，考虑一下维在电子表格中是如何展现的。有页或工作表吗？或者一个工作表内有多个不同的区域？区别不同页、表或文件的值可能构成一个维。比如，可能每一页表示的是不同的商店。但电子表格并不一定像这样规格化。单一个工作表就可能包含多个坐标，不同的粒度层次，甚至多个立方体的数据。
建立OLAP解决方案就像建立一个连接峡谷两端的桥梁。一端是用户需求，使用立方体；一端是数据源，源立方体。模型就是将两端连接在一起的桥梁。当工作于显然是立方体情形时，通常有多个源立方体，多个中间立方体，多个最终用户立方体，这时我几乎总是从两端中的一端开始，源或使用。这减少了出错的机会。
当在多个立方体上进行跨立方体分析时，这些立方体需要按照结构相同的共有维进行连接。有时，尤其是当OLAP工作是在建立数据仓库之后，这些用于连接不同立方体的共有维将要或已经进行了同一结构化，此过程通常称之为一致化。但如果这些共有维没有进行同一结构化你该怎样做呢？
我更喜欢把具有相同维的变量建模到同一个立方体内——即使它们并不共享相同的单元。这种逻辑简化法降低了我的模型中立方体的个数（有些具有5个或10个物理立方体的多立方体模型可以逻辑地表示为一个或两个立方体。这种情况下，这些物理立方体展现的更接近于是不同的物理两部分，而不是具有不同内容的信息）。假定你能够为几个不同变量建立派生变量来把它们映射到立方体的相同位置，这将使下面的事实更加突出，即同一立方体内的数据可以进行有意义的比较。
例如，考虑为一个包含跨国销售和宏观经济信息的数据集建模。想象销售数据在商店层次上每周收集一次，同时宏观经济信息在国家层次上每月收集一次。根据你所应用的多维工具，你可能最后为每个数据集建立不同的立方体。但符合逻辑地说，在设计模型时，我总是发现将其定义为同一个立方体的一部分更加简单些。此外，当在同一个立方体之内时，可以很容易地发现，我可以把商店和周层次上的销售数据聚合到国家和月层次后在再将其与宏观经济进行比较，并且可以把国家层次的销售与宏观经济指标的变化进行有意义的对比。
虽然数据可以属于同一个逻辑立方体，但基于性能的考虑——比如数据更新要求，立方体必需的网络传输或数据集大小，以及基于内存的工具强制你必须把整个模型加载到内存内这些事实——都可能预示需要把数据保持在相互独立的物理立方体内。
你也需要意识到称为属性的东西。属性作为一个维成员的函数是一个经常——但不永远——变化的内容。它们通常出现于与维表关联或是其中一部分的查找表内。大多数应用广泛地使用属性。不同OLAP工具对属性的支持有显著的不同。在维为商店、时间、产品和变量的零售模型中，存在很多关于每个维的成员的事实。例如，关于商店的事实可以包括面积、租金、地址、管理员姓名、电话号码，等等。符合逻辑地说，这些变量或事实对立方体中所有依据商店和时间的产品都适用。它们在所有产品层都适用，是因为商店的地址是与商店中所放的产品无关的，但它们只对某些时间但不是全部时间适用，是因为这些事实可能随着时间变化，并且也可能需要跟踪这些值的历史变化。
根据你的OLAP应用与后端的数据仓库结合得有多紧密，你可以简单地应用数据仓库中的属性表，你也可以建立独立的属性立方体，你可以把属性作为常量加载（但当其变化时准备将其转化为年度或季度变量），或结果跟踪内容的变化很重要，你也可以把它们维护在带时间戳属性的表内。
需要谨记的是给定模式中交叉连接的维集合，内容经常依这些维组合的不同而不同（由于数据仓库世界中的第四范式和所谓的M对N关系）。因此要确保你能够坦诚地看待内容随维的任何组合进行变化。如果在此之后，对你正在建设的模型来说，存在大量的内容仅在一个维上显著地变化，并且你喜欢属性这个术语，那么一定要使用它。
在此步骤地最后，你应该能够找出定义模型的所有立方体和组合每个立方体的维。图4.3.1展示了看起来像一个立方体结构的样子。注意，这是模型的高层逻辑视图。它显示了变量的数目，定位器维德数目和每个维成员的大概数目。但它没有显示任何一个维等级的任何信息或关于数据流的任何信息。图4.3.2显示的是多立方体模型的高等级信息。
在进行下一个步骤之前，你还应该建立一个你的解决方案的动态图。除了要了解定义立方体的维和变量集合之外，你还要知道立方体间的数据流和每个立方体展现的大概数据量。图4.3.3显示的是与图4.3.2中相同的高等级信息，但包含了数据流、稀疏性和数据集大小的信息。图4.3.3中的视图显示，兑换立方体中兑换率信息被用来计算购买立方体中的派生值（假定把输入的当地价格转换位派生的美元价格），并且配方立方体中的信息被用来决定满足给定数量的生产需要多少库存。此图显示了销售数据流到库存，再流到生产，并且兑换和配方立方体中数据量比其他三个都少。


1． 优化维的数量
不管你是基于已存在的数据源还是基于要进行建模的数据来定义你的立方体，你都应该在用层次和成员固化你选择的维之前，花一定的时间进行一下更新检查。更改立方体多维结构的主要途径是添加和删除维。
如果一个立方体非常稀疏，并且造成稀疏的维组合都是名次性的，并且如果你所用的工具不支持自动稀疏管理，你可能需要把那些相互组合不是很有意义的维和并，并把有意义的组合包含在其中。生成一个基数比较高的维。维合并的好处是消除了无意义的值，并且降低了立方体中无意义派生数据的增长。维合并的主要不利之处是丧失了处理单一维中变化的效率（比如本来在分离的维中一个就足够的计算项，合并后可能要多个才行）。
添加维的两个主要原因是：
l       考虑前面忽略了的因素，比如时间或地点
l       把在维内部存在相关因素影响的维拆成相互独立的维
对于忽略的信息，你的源数据可能来自多个不同的表，每个表代表不同的时间或地点。这种情况下，数据的时间或地点可能比数据本身更含蓄，因此没有直接包含在表的任何字段中（反而可能在表名内）。考虑这些信息并没有什么实在的不利方面。如果你没有考虑到，你就没有办法把它们放到同一个立方体内。
至于相关因素，你可能有一个包含如下属性列的表：实际直接销售、实际间接销售、实际薪水、实际材料支出、实际其他支出、预计直接销售、预计间接销售、预计薪水、预计材料支出和预计其他支出。你的所有销售和支出数据都包含实际的、预计的或一个计算偏差。每个实际的和预计的数据都对应了销售和支出两个值。销售和支出（可以想象成一个财务维的成员）与实际和预计（可以想象成场景维的成员）是一对相关因素。通过把此信息用财务和场景两个维来表示，你会更容易地定义适合财务和场景的计算关系，也更容易在屏幕上通过独立的坐标轴分别显示财务和场景的内容。如果原成员的数目非常巨大，比如说，有一百万个，并且，如果新生成的两个维的成员个数基本相同，那么新生成两个维的成员个数基本是原维成员个数的平方根。换句话说，包含1000000个成员的维可以拆分成两个成员数是1000的维。
2． 当维随着时间变化时
就像一位佛学大师所说的，惟一不变的是变化本身。对维来说真正的问题是，变化的频率有多快？一个极端情况是，有些维在模型的整个生命期内都不会变化，尤其是当此模型只是一个基于单一服务器的短期应用时。但对那些随着用户发展的模型来说，至少有一个维的变化是必然的。最动态变化的维通常有产品维、组织维、雇员维、市场地理维等。例如，产品的增加和删除，产品线的重新组织，雇员来了又走，企业改变了它们的报表层次。
对这些变化的建模并不存在惟一正确的方法。你可以保留维的多个拷贝，并为每个维版本建立不同的立方体。你可以在立方体内只保留一个维，表示每个维版本的联合，你也可以在一个立方体内保留维的多个版本。第二种和第三种方法需要工具的直接支持，第一种方法的实现可以不受产品的限制。
在数据仓库领域处理这种变化维的情况已经有很长历史，Ralph Kimball提供了多种跟踪这些变化的方法。OLAP应用在处理外部表定义维的变化时，通常是基于数据仓库的情况，需要从这些表中刷新其维结构。然而，你仍然需要决定OLAP应用要如何处理具有两个状态或多个状态维间的比较。
例如，假如变化的维是产品维，并且你想执行一种基于时间的分析，这时你需要决定如何处理这一事实，即有些早期存在的产品后来消失了，同时还有一些早期不存在的产品后来又被引入。
显然，有些在变化维上的查询是没有意义的。例如，计算特定时期的产品销售增长率时，对于不在整个时期内存在产品的查询是没有意义的。（它破坏了销售变量的应用区间）。虽然对特定产品的查询可能没有意义，但有一种利用不在整个时期内存在产品的销售信息的方法，就是把不在整个时期内出现的产品抽象成在整个时期内出现的产品类别，然后在产品类别上进行时间比较。所以，比如，虽然某个特定型号的女鞋可能被引入，然后再消失，但女鞋类保持稳定。查询女鞋的销售增长是相当有意义的，虽然组成此类别特定鞋的类型在不断变化。