维度建模.docxVIP

维度建模的基本概念及过程摘要：本文首先介绍维度模型中的维度表和事实表这2个基本构成要素的基础知识；其次，介绍设计维度模型的4个基本步骤；再次，围绕某银行为实现业务价值链数据集成的需要，介绍多维体系结构中的3个关键性概念：数据仓库总线结构、一致性维度、一致性事实。关键词：维度表;事实表;维度模型设计过程;数据仓库总线结构;一致性维度;一致性事实。引言: 与流行的说法不同，Ralph Kimball本人并没有定义“维度”和“事实”这样的术语。术语“维度”与“事实”，最初是20世纪60年代在一个由General Mills与Dartmouth大学主持的联合研究计划中提出的。70年代，AC Nielsen和IRI都一致地使用这些术语描述他们的数据发布应用，用现在更为准确的话来说，就是关于零售数据的维度数据集市（Data Mart）。在简明性成为生活方式的潮流之前的长时期内，早期的数据库垄断组织们致力于将这些概念用来简化用做分析的信息。他们意识到，除非数据库做得简单易用，否则没有人会用它。因此，在将可理解性和性能作为最高目标的驱动下，产生了维度模型的构造思想。 维度表和事实表事实表事实表是维度模型的基本表，其中如图所示存放有大量的业务性能度量值。力图将从一个业务处理过程得到的度量值数据存放在单个数据集市。由于度量值数据压倒性地成为任何数据集市的最大部分，因此应该避免在企业范围内的不同地方存储其拷贝。用术语“事实”代表一个业务度量值。可以设想一个作为例子的情形：查询某个客户在某个机构下某个产品合约账户的某个币种的某个时点余额，在各维度值(客户、产品合约、账户、机构、币种、日期)的交点处就可以得到一个度量值。维度值的列表给出了事实表的粒度定义，并确定出度量值的取值范围是什么。事实表的一行对应一个度量值，一个度量值就是事实表的一行；事实表的所有度量值必须具有相同的粒度。最有用的事实是诸如账户余额这样的数字类型为可做加法的事实。可加性是至关重要的，因为数据仓库应用不仅仅只检索事实表的单行数据。相反，往往一次性带回数百、数千乃至数百万行的事实，并且处理这么多行的最有用的事就是将它们加起来。当然，有些事实是半加性质的，而另外一些是非加性质的。半加性事实仅仅沿某些维度相加，例如销售占比，周期余额；而非加性事实根本就不能相加，例如状态。对于非加性事实，如果希望对行进行总结就不得不使用计数或平均数，或者降为一次一行地打印出全部事实行。度量事实在理论上讲可以是文本形式的，不过这种情况很少出现。在大多数情况下，文本度量值可以是某种事物的描述并取自某个离散列表的值。设计者应该尽各种努力将文本度量值转换成维度，原因在于维度能够与其他文本维度属性更有效地关联起来，并且消耗少得多的空间。不能将冗余的文本信息存放在事实表内。除非文本对于事实表的每行来说都是唯一的，否则它应该归属到维度表中。真正的文本事实在数据仓库中是很少出现的，文本事实具有像自由文本内容那样的不可预见性内容，这几乎是不可能进行分析的。所有事实表有两个或者两个以上的外关键字(如图中FK符号标记的部分)，外关键字用于连接到维度表的主关键字。例如，事实表中的“产品合约关键字”总是匹配产品合约维度表的一个特定“产品合约关键字”。如果事实表中的所有关键字都能分别与对应维度表中的主关键字正确匹配，就可以说这些表满足引用完整性的要求。事实表要通过与之相连的维度表进行存取。事实表根据粒度的角色划分不同，可分为事务事实表、周期快照事实表、累积快照事实表。事务事实表用于承载事务数据，通常粒度比较低，例如产品交易事务事实、ATM交易事务事实；周期快照事实表用来记录有规律的、固定时间间隔的业务累计数据，通常粒度比较高，例如账户月平均余额事实表；累积快照事实表用来记录具有时间跨度的业务处理过程的整个过程的信息，通常这类事实表比较少见。这里需要值得注意的是，在事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中。维度表维度表是事实表不可分割的部分。如图所示，维度表包含有业务的文字描述。在一个设计合理的维度模型中，维度表有许多列或者属性，这些属性给出对维度表的行所进行的描述。应该尽可能多地包括一些富有意义的文字性描述。对于维度表来说，包含50到100个属性的情形并不少见。维度表倾向于将行数做得相当少(通常少于100万行)，而将列数做得特别大。每个维度用单一的主关键字(如图中PK符号标记的部分)进行定义，主关键字是确保同一与之相连的任何事实表之间存在引用完整性的基础。维度属性是查询约束条件、成组与报表标签生成的基本来源。在查询与报表请求中，属性用by这个单词进行标识。例如，一个用户表示要按“产品合约编号”与“机构编号”来查看账户余额，那么“产品合约编号”与“机构编号”就必须是可用的维度属性。维