马红兵

数据分析讲堂

第三课 维度的内部结构

第三讲　非层次结构（3）

4）度量
所有的实例都和度量是相关的
粗看起来，维度似乎就是由一组实例组成，并且可能带有一定的层次结构。毕竟，你可以在很多不同的OLAP产品中定义层次，在这些OLAP产品中都没有让你定义单位或度量。因此你可能会问为什么要引入单位或度量呢？一个快速简单的答案就是每一次你使用父节点、子节点和层次的时候，其实都隐含地引用了度量。
类型或维度的名称意味着一组可能的实例。例如，以维度命名的城市所指的是如上海或者广州之类有效的城市名称，而不是像红色、蓝色等表示颜色的记号，这些表示颜色的名称是无效的实例。虽然OLAP工具没有强制你一定要保证实例的同质性，但是我还是建议你应该遵循这个原则。让我们考虑如下的例子。如果是你今天担任数据仓库管理员的第一天，现在你正在熟悉公司的维度模型，当你看到一个叫“产品”的类型或者维度，并且发现其中混杂了经理或者城镇的名字的时候，如果你还希望保住自己工作的话，你很可能会将它们作为异常剔除出去。因此，组成类型的事物、元素、实例、成员、位置等从模型的角度上至少可以平等地对待。
我们应该把维度的名称看成是所有实例的一个速记，所以维度的名称应该反映出所有实例具有的共性。但是如果已经存在了某些维度的每个实例都必须满足的条件或者度量，那么一个更加精确的表示实例的方法是将维度表示为“实例——度量”对的形式。
我们一般用如下的形式表示维度和其中的实例：
City：shanghai，guangzhou，tianjin
但是一个更加精确的形式如表达式是：
City.any：City.shanghai，City.guangzhou，City.tianjin       ( 5-1 )

表达式5-1强调了维度中的每一个实例都遵循维度名称所隐含的规则。下面让我们考察如下简单的维度：月份（month）、年份（year）、米（meter）和千米（kilometer）。
Time.metric.彐 Month，year

我们读做“时间维度的集合是月份和年份”。

Time.Month.彐 Month，January，Month.February，...Month.December

我们读成“月份实例的集合是从1月份到12月份”。

Time.Year.彐 Year.1998，Year.1999，Year.2000

我们读成“年份实例的集合从1998年到2000年”。

Distance.Metric.彐 Meter，Kilometer

我们读成“距离度量的集合是米和千米”。

Distance.Meter.彐 Meter1，Meter2,…Meter1000

我们读成“米的实例集合是从1米到1000米”。

Distance.Kilometer.彐 Kilometer1，Kilometer2

我们读成“千米的实例是1和2”。

每一个人都知道12个月是一年，而1000米等于1千米。比率12:1和1000:1分别表示了在时间和距离维度单位或度量上的换算因子。因此，如果我们知道某个按照年份统计的值，我们可以将其除以12得到每个月的平均值，而我们如果有3个月的值，我们知道将其乘以4，从而估计一年的值。正规的做法是米、千米、月和年作为单位或度量处理。

现在让我们看看你对于测度或者值的单位了解到了什么？除了可以在不同的层次粒度上指定换算系数之外，你同时还获得了一组可以使用的操作。比如，在米上可以进行加和减，以及乘或除。它们可以被时间单位做除法。冰河可以每年3米的速度移动，官僚主义的移动速度就更慢了。让我们看一下如果没有单位的话，会丢失什么。比如将5个未知单位长度和3个未知单位长度进行相加？除非你知道它们的度量单位，否则就无法在这些维度上进行任何的操作。因此，你无法将度量中的转换部分与允许的操作，以及度量的定义隔离开来。

虽然我们通常都是将度量的概念作用于那些采用基数排序实例的维度，例如前面的月份——年份和米——千米维度，但是定义实例成员的规则、在换算系数之间提供量化的比较，以及定义有效的操作这些功能完全可以作用于名词排序的维度。

让我们再次考虑城市维度的例子，不过这一次将城市作为多层地理维度的一部分，增加了省份的层次。

Geography.levels.彐 Province，City

Geography.City.彐 Shanghai，Guangzhou，Tianjin

Geography.Province.彐 Guangdong，Shanghai, Tianjin

和谈论月份和年份之间的换算系数一样，我们也可以说城市和省份之间的换算系数。唯一的区别在两个维度之间，换算系数并不是一直固定的。例如，在广东的城市和省份之间的换算系数是3:1，而在上海的城市和省份之间的换算系数是2:1。虽然城市是名词排序的，省份也是名词排序的，但是每个城市和省份都具有一定的级别或度量，就象月份——年份和米——千米的例子一样，它们同样可以定义规则、换算系数及允许的操作。因此，度量的概念，在这里已经泛化，并不局限于基数排序的维度，而是适用于所有的维度，不管它们的排序是怎样的。

既然维度表示了一系列特定度量下的实例，而且有可能和一个实例相关的度量会不止一个，就象前面的城市——省份例子，因此有必要为类型或维度的每个实例确定一个度量，如下所示：

Geography._Province.Guangdong，Province.Shanghai，Province.Tianjin，City.guangzhou，City.Shanghai，City.Tianjin

5）层次的度量基础

当一个维度由不都属于同一个度量的实例组成的时候，不同度量的实例之间需要能够进行定量的比较。如果你回顾一下所熟悉的多层维度，就会发现这个需求是显然的。例如，天、月份和年份属于一个层次维度，它们之间都可以定量比较的。任何属于天的信息都可以转换到月份或者年份上。另一方面，实例.度量对的集合：红色.颜色、蓝色.颜色、绿色.颜色、小.尺寸、中.尺寸和大.尺寸，它们是不能进行定量比较的度量，因为颜色和尺寸不具有可比性。因此，这两组实例的集合应该属于不同的维度。

图3.3.1使用分类树对以上讨论的饿各种类型进行了总结。回忆一下，之前我们介绍过一个合法的类型应该具有的条件，每一个类型至少需要两个惟一而且互斥的实例。每一个实例都与一个度量相联系。如果所有的度量都是相同的，那么这个类型就是非层次的。如果存在两个或者更多的度量，而且它们之间具有定量的可比性，这个类型就是层次类型。如果存在两个或者两个以上的度量，但是它们之间并不完全具有定量的可比性，这个类型就是非法的。



因此，层次的基础是度量关系，如果没有度量的话，那就无法定义层次。如果没有度量的概念，维度或者类型就没有任何的内涵、换算和操作，从而维度就会变成一堆不能支持任何内部计算和逻辑的随意的实例的集合。
那么当你使用OLAP产品的时候，看起来好象并没有提供度量的功能，这个意味着什么呢？首先，你需要意识到任何OLAP产品都会明确地使用某种类型的度量，至少，你的产品会支持一种或更多种数据类型，这些数据类型将与测度或变量相关联，属于基数类型。另外，你定义的其他维度的实例都可能被预先定义为8个字节的字符串。
在工具支持的基本功能之上，你内心应该明了你定义的每个维度相关联的排序和度量。虽然你不一定需要为产品、商店和客户等维度强制定义排序关系，但是还是应该在某些地方为每个维度，比如产品、商店、时间、渠道或客户，手工维护排序的类别等元数据信息。这些维度大都是名词维度，但是其中有些维度，比如时间，或者场景，或者渠道的位置等，可能是序数或者基数排序的。当处理度量、变量或者内容的时候，如果你的系统能够自动地跟踪变量的单位，那么你就可以更加容易地创建、交流和调试你的应用程序。