精选星型模式建模.docx
《精选星型模式建模.docx》由会员分享，可在线阅读，更多相关《精选星型模式建模.docx（11页珍藏版）》请在冰点文库上搜索。
精选星型模式建模
星型模式建模
星型模式的基本形式必须实现多维空间（常常被称为方块），以使用关系数据库的基本功能。
首先，我们需要理解多维空间。
多维分析空间
几何学中的方块是指一个三维空间，其中每个维度的尺寸都相同。
想象一个立方体，每个维度都有三个单元，我们即得到相同结构的33＝27个单元。
图1一个具有x、y、z维度的方块
多维分析空间（或者数据仓库方块）与几何空间中的方块仅仅存在细节上的差异。
∙维度不仅限于3维。
不过，处理很多维度的立方体也不是件轻松的事情，这会导致大多数的实现被限制于6或者7维。
不要期盼使用图形可以很好地表示超过4的维度--如果您有幸能发现一种方法，别忘了告诉我一下。
∙维度并不具有相同的规模和单元。
规模从几个单元到几百万个单元，差别巨大。
单元可以是一天、一位顾客、部门等。
∙单元，相当于子方块（1×1×1等），包含事实。
图2一个三维数据立方体
数据立方体需要很大的内存以存储所有事实。
无论是否包含事实，都必须要预留单元。
这就是为什么使用关系数据库和星型模式的原因。
使用它们能够优化存储并且保持数据结构的灵活性。
星型模式
星型模式的基本思想就是保持立方体的多维功能，同时也增加了小规模数据存储的灵活性。
图3一个星型模式
在图3中，星型模式使用事实Flight表示了一个4维方块（Passenger、Menu、FlightSchedulet和Time）。
基本上，事实必须指定一个维度，以将其放入立方体的单元中。
我们的例子中的维度是：
∙Passenger，描述了飞行航程中的每位乘客，由经常飞行号（frequentflyernumber）指定。
不是经常乘坐飞机的乘客不是数据仓库的一部分。
∙FlightSchedule，是指所有常规飞行的日程。
∙Menu，是用于飞行的菜单。
只有对菜单进行基本的分类才会对数据挖掘有重要意义。
∙Time，是指飞行的时间。
事实Flight描述了乘客在唯一的Time的单程飞行上选择Menu。
分析空间可以是完整的方块，或者我们可以根据维度将分析空间分割成小片。
每个维度根据一个对象进行描述，对象可以用类表示，这些类就是有关业务主题的名称。
这一点对于成功建立数据仓库来说是很重要的，因为仓库的用户（经理、分析员、市场）对于信息技术的术语并不是很熟悉。
事实本身就是商业智能的另一个对象，仍然通过类进行表示。
事实指每个维度。
事实与维度的关联常常是一对任意，这也就意味着每个事实都与单个维度的一个单元准确对应，而维度的每个单元（每个Passenger、Time等）可以与任意数量的事实发生关联（包括0个事实）。
使用RationalRose将对象模型转换为数据模型即完成了星型模式的实现。
这里我们可以看到转换后的结果。
图4使用RationalRose实现星型模式
在图4中，没有显示自动创建的主键和外键约束。
星型模式的维度是独立的表。
当对象模型转换为数据模型时，RationalRose可以生成维度的主键。
事实表指从维度表中使用键迁移的维度，当生成数据模型时RationalRose可以生成外键。
在星型模式中切片和切块是对维度的限制（选择）。
这是一个运行时问题，而不是建模问题，但是模型必须分辨其需要。
雪花模式
基本的星型模式并不能满足数据挖掘的所有需要。
我们需要更复杂的维度，例如时间。
分析员希望根据周、月、季度等识别模式。
维度必须进行规范化。
我们不需要冗余的维度表，这只会使数据切片变得更加复杂。
这种过程中我们得到的模式被称为雪花模式。
我们来看一个简单的雪花模式例子。
我们将时间维度规范化为周、月和季度。
图5规范化的Time维度
我们希望能够使用附加的规范化维度将立方体切片：
周、月和季度。
在本例中，我们假定季度是月的平行层次，这也就意味着我们不能将季度假定为若干月的聚合。
由于这个原因，我们将使用一张范化表（是对OLAP查询的一项简单附加）预先选择时间维度。
最终雪花模式添加了规范化维度。
图6带有范化维度的Time和事实Flight的雪花模式
当然，所有的维度都可以像时间例子那样进行规范化，这就导致了比较复杂的数据集市模式的出现。
由RationalRose从雪花模式中开发的实现模式（数据模型）是完善的。
图7带有范化Time维度的雪花模式的数据模型
创建的约束在图中也没有显示。
雪花模式中可以存在切片，不仅仅在基本的Time维度上，也可以在规范化的Week、Month和Quarter维度上。
多对多关系
在一次飞行中，我们不仅仅只吃一顿饭。
在长途飞行中可能要多次用餐。
在这种情况下，我们认为事实Flight和Menu维度不是一对多的关联。
我们必须使用多对多关联。
不过，这种关联不可能在星型模式中实现。
雪花模式的一种特殊形式是使用一种必要的数据结构以满足这项要求。
首先，我们将模型变更为事实和维度间的多对多关联。
使用RationalRose，这只是关联基数的变更。
图8Menu的多对多维度的星型模式
我们无法在关系数据库中实现多对多关联。
实现多对多关联需要使用另一种雪花模式。
在下图中，我们关注一下已经开发的雪花模式的一部分，该部分处理多对多维度。
图9雪花模式解决了Menu的多维度
RationalRose生成了附加的维度表FlightMenu，它是指Menu维度和Flight事实。
确定关系用于解决多对多关联。
对于雪花模式的架构师来说，最重要的一点就是识别多对多关系。
简单对象视图可能会使设计员理解概念，而生成的数据视图有助于进一步深入有关实现的问题。
层次
数据挖掘可以从隐藏在操作系统表面下的数据中发现信息。
我们想了解的一个问题就是选定菜单与乘客统计资料之间的依赖关系。
乘客统计资料数据可以在Passenger维度的层次上构建。
乘客可以根据邮政编码分组，然后再按国家进行分组。
图10乘客的层次
层次通过使用聚合来指定。
聚合定义了所包括的内容。
Country包含了ZIP编码，ZIP编码包含了多名Passenger信息。
最终通过使用外键实现了聚合。
图11雪花模式实现了Passenger维度的聚合
生成的约束仍然没有在图中表示出来。
使用聚合，维度可以在任何定义的级别上使用。
分析空间可以通过Passenger、ZIPCode或者Country进行切片。
一致的维度
随着数据仓库架构师不断地添加细节内容，雪花模式变得越来越复杂。
因此设计过程必须在到达某种程度后停止以保持数据仓库运行良好。
星型或者雪花模式仍然仅仅关注于一个事实--在本例中就是Flight。
那么复杂关系又是什么情况呢？
对于每个事实我们都必须设计其各自的模式。
如果我们想要进行复杂查询的话，它们就必须具有共同的维度--我们称其为一致的维度。
让我们使用Pilot作为一个维度，PilotFlight作为一个事实来定义第二个星型模式。
我们还要使用附加的FlightSchedule维度和Time维度。
图12Pilot星型模式
第二个模式可以单独使用或者与Passenger模式结合使用，从而根据使用一致维度的飞行员维度来查询Passenger的满意程度。
图13一致维度Time和FlightSchedule
即使在使用一致维度的数据仓库的简单结构中，Pilot与Passenger之间的关系也是简单的。
在开发数据模型时，数据仓库将大量小型星型模式与雪花模式相结合形成了大型的数据仓库模式。
事实与维度的数据
我们想要评估乘客对于飞行的满意率。
可以使用不满意到很满意几个级别进行评定。
评定记录存放在事实表Flight中作为一个属性（列）。
如果我们想要得出一个平均记录，那么就必须为记录定义值以进行计算。
我们可以将记录分为0到10级。
这样就可以得到一个平均记录。
平均值应该存储在维度表中，以用于简单的切片，其中我们只想进行一维切片。
RationalRose根据目标数据库的数据类型生成了实现属性。
对象模型是用来定义数据库的数据源的。
升级会员 