精华内容
下载资源
问答
  • 维度建模的基本概念及过程

    万次阅读 2015-09-13 16:03:22
    维度建模的基本概念及过程 摘要:本文首先介绍维度模型中的维度表和事实表这2个基本构成要素的基础知识;其次,介绍设计维度模型的4个基本步骤;再次,围绕某银行为实现业务价值链数据集成的需要,介绍多维体系结构...

    维度建模的基本概念及过程

    摘要:本文首先介绍维度模型中的维度表和事实表这2个基本构成要素的基础知识;其次,介绍设计维度模型的4个基本步骤;再次,围绕某银行为实现业务价值链数据集成的需要,介绍多维体系结构中的3个关键性概念:数据仓库总线结构、一致性维度、一致性事实。

    关键词:维度表;事实表;维度模型设计过程;数据仓库总线结构;一致性维度;一致性事实。

    0 引言

    与流行的说法不同,Ralph Kimball本人并没有定义“维度”和“事实”这样的术语。术语“维度”与“事实”,最初是20世纪60年代在一个由General Mills与Dartmouth大学主持的联合研究计划中提出的。70年代,AC Nielsen和IRI都一致地使用这些术语描述他们的数据发布应用,用现在更为准确的话来说,就是关于零售数据的维度数据集市(Data Mart)。在简明性成为生活方式的潮流之前的长时期内,早期的数据库垄断组织们致力于将这些概念用来简化用做分析的信息。他们意识到,除非数据库做得简单易用,否则没有人会用它。因此,在将可理解性和性能作为最高目标的驱动下,产生了维度模型的构造思想。

    1 维度表和事实表

    1.1 事实表

    事实表是维度模型的基本表,其中如图1.1所示存放有大量的业务性能度量值。力图将从一个业务处理过程得到的度量值数据存放在单个数据集市。由于度量值数据压倒性地成为任何数据集市的最大部分,因此应该避免在企业范围内的不同地方存储其拷贝。用术语“事实”代表一个业务度量值。可以设想一个作为例子的情形:查询某个客户在某个机构下某个产品合约账户的某个币种的某个时点余额,在各维度值(客户、产品合约、账户、机构、币种、日期)的交点处就可以得到一个度量值。维度值的列表给出了事实表的粒度定义,并确定出度量值的取值范围是什么。

    维度建模的基本概念及过程

    图 1.1 示例事实表

    事实表的一行对应一个度量值,一个度量值就是事实表的一行;事实表的所有度量值必须具有相同的粒度。最有用的事实是诸如账户余额这样的数字类型为可做加法的事实。可加性是至关重要的,因为数据仓库应用不仅仅只检索事实表的单行数据。相反,往往一次性带回数百、数千乃至数百万行的事实,并且处理这么多行的最有用的事就是将它们加起来。

    当然,有些事实是半加性质的,而另外一些是非加性质的。半加性事实仅仅沿某些维度相加,例如销售占比,周期余额;而非加性事实根本就不能相加,例如状态。对于非加性事实,如果希望对行进行总结就不得不使用计数或平均数,或者降为一次一行地打印出全部事实行。

    度量事实在理论上讲可以是文本形式的,不过这种情况很少出现。在大多数情况下,文本度量值可以是某种事物的描述并取自某个离散列表的值。设计者应该尽各种努力将文本度量值转换成维度,原因在于维度能够与其他文本维度属性更有效地关联起来,并且消耗少得多的空间。不能将冗余的文本信息存放在事实表内。除非文本对于事实表的每行来说都是唯一的,否则它应该归属到维度表中。真正的文本事实在数据仓库中是很少出现的,文本事实具有像自由文本内容那样的不可预见性内容,这几乎是不可能进行分析的。

    所有事实表有两个或者两个以上的外关键字(如图1.1中FK符号标记的部分),外关键字用于连接到维度表的主关键字。例如,事实表中的“产品合约关键字”总是匹配产品合约维度表的一个特定“产品合约关键字”。如果事实表中的所有关键字都能分别与对应维度表中的主关键字正确匹配,就可以说这些表满足引用完整性的要求。事实表要通过与之相连的维度表进行存取

    事实表根据粒度的角色划分不同,可分为事务事实表周期快照事实表累积快照事实表。事务事实表用于承载事务数据,通常粒度比较低,例如产品交易事务事实、ATM交易事务事实;周期快照事实表用来记录有规律的、固定时间间隔的业务累计数据,通常粒度比较高,例如账户月平均余额事实表;累积快照事实表用来记录具有时间跨度的业务处理过程的整个过程的信息,通常这类事实表比较少见。这里需要值得注意的是,在事实表的设计时,一定要注意一个事实表只能有一个粒度,不能将不同粒度的事实建立在同一张事实表中。

    1.2 维度表

    维度表是事实表不可分割的部分。如图1.2所示,维度表包含有业务的文字描述。在一个设计合理的维度模型中,维度表有许多列或者属性,这些属性给出对维度表的行所进行的描述。应该尽可能多地包括一些富有意义的文字性描述。对于维度表来说,包含50到100个属性的情形并不少见。维度表倾向于将行数做得相当少(通常少于100万行),而将列数做得特别大。每个维度用单一的主关键字(如图1.2中PK符号标记的部分)进行定义,主关键字是确保同一与之相连的任何事实表之间存在引用完整性的基础。

    维度建模的基本概念及过程

    图1.2 示例维度表

    维度属性是查询约束条件、成组与报表标签生成的基本来源。在查询与报表请求中,属性用by这个单词进行标识。例如,一个用户表示要按“产品合约编号”与“机构编号”来查看账户余额,那么“产品合约编号”与“机构编号”就必须是可用的维度属性。

    维度表属性在数据仓库中承担着一个重大的角色。由于它们实际上是所有令人感兴趣的约束条件与报表标签的来源,因此成为使数据仓库变得易学易用的关键。在许多方面,数据仓库不过是维度属性的体现而已。数据仓库的能力直接与维度属性的质量和深度成正比。在提供详细的业务用语属性方面所花的时间越多,数据仓库就越好。在属性列值的给定方面所花的时间越多,数据仓库就越好。在保证属性列值的质量方面所花的时间越多,数据仓库就越好。

    维度表是进入事实表的入口。丰富的维度属性给出了丰富的分析切割能力。维度给用户提供了使用数据仓库的接口。最好的属性是文本的和离散的。属性应该是真正的文字而不应是一些编码简写符号。应该通过用更为详细的文本属性取代编码,力求最大限度地减少编码在维度表中的使用。有时候在设计数据库时并不能很确定,从数据源析取出的一个数字型数据字段到底应该作为事实还是维度属性看待。通常可以这样来做出决定,即看字段是一个含有许多的取值并参与运算的度量值(当事实看待),还是一个多少变化不多并参与作为约束条件的离散取值的描述(当维属性看待)。

    在维度类型中,有一种重要的维度称作为退化维度(Degenerate Dimension),这种维度指的是直接把一些简单的维度放在事实表中而不专门去做一个维度表。退化维度是维度建模领域中的一个非常重要的概念,它对理解维度建模有着非常重要的作用,退化维度经常会和其他一些维度一起组合成事实表的主键。退化维度在分析中可以用来做分组使用。

    1.3 维度表和事实表的融合

    在理解了事实和维度表之后,现在就考虑将两个组块一起融合到维度模型中去的问题。如图1.3所示,由数字型度量值组成的事实表连接到一组填满描述属性的维度表——这个星型特征结构通常被叫做星型连接方案。该术语可以追溯到最早的关系数据库时期。

    维度建模的基本概念及过程

    图1.3维度模型中的事实与维度表

    关于其中用到的维度方案,应该注意的第一件事就是其简明性与对称性。很显然,业务用户会因为数据容易理解和浏览而从简明性方面受益。

    维度模型的简明性也带来了性能上的好处。数据库优化器可以更高效率地处理这些连接关系较少的简单方案。数据库引擎可以采取的非常强劲的做法是,首先集中对建立了充足的索引的维度表进行约束(过滤)处理,然后用满足用户约束条件的维度表关键字的笛卡尔乘积一次性处理全部的事实表。令人惊奇的是,利用这种方法只需使用一次事实表的索引,就可以算出与事实表之间的任意n种连接结果。

    最后,维度模型能够很自然地进行扩展以适应变化的需要。维度模型的可预定框架能够经受住无法预见的用户行为变化所带来的考验。每个维度都是平等的,所有维度都是进入事实表的对等入口。这个逻辑模型不存在内置的关于某种期望的查询形式方面的偏向,不存在这个月要问的业务问题相对于下个月来说具有优先方面的考虑。没有谁会希望,如果业务用户采用新的方式进行业务分析,就要调整设计方案这样的事情发生。

    最佳粒度或者原子数据具有最佳的维度。被聚合起来的原子数据是最有表现力的数据。原子数据应该成为每个事实表设计的基础,从而经受住业务用户无法预见的查询所引起的特别攻击。对于维度模型来说,完全可以向方案中加入新的维度,只要其值对于每个现有的事实行存在唯一性定义就行。同样,可以向事实表加入新的不曾预料到的事实,只要其详细程度与现有事实表处在一致的水平面上就可以了。可以用新的不曾预料到的属性补充先前存在的维度表,也可以从某个前向时间点的角度在一个更低的粒度层面上对现存维度行进行分解。在每种情况下,可以简单地在表中加入新的数据行或者执行一条SQL ALTER TABLE命令来对现存表格进行适当的修改。数据用不着重新加载,所有现存的数据存取应用可以继续运行而不会产生不同的结果。

    2 维度建模设计过程

    本文按照图2.1具有一定顺序的四个步骤的方式进行维度数据库的设计。

    维度建模的基本概念及过程

    图2.1四步骤维度设计过程

    2.1 第一步 选取业务处理

    业务处理过程是机构中进行的一般都由源系统提供支持的自然业务活动。听取用户的意见是选取业务处理过程的效率最高的方式。在选取业务阶段,数据模型设计者需要具有全局和发展的视角,应该理解整体业务流程的基础上,从全局角度选取业务处理。

    要记住的重要一点是,这里谈到的业务处理过程并不是指业务部门或者职能。通过将注意力集中放在业务处理过程方面,而不是业务部门方面,就能在机构范围内更加经济地提交一致的数据。如果建立的维度模型是同部门捆绑在一起的,就无法避免出现具有不同标记与术语的数据拷贝的可能性。多重数据流向单独的维度模型,会使用户在应付不一致性的问题方面显得很脆弱。确保一致性的最佳办法是对数据进行一次性地发布。单一的发布过程还能减少ETL的开发量,以及后续数据管理与磁盘存储方面的负担。

    2.2 第二步 定义粒度

    粒度定义意味着对各事实表行实际代表的内容给出明确的说明。粒度传递了同事实表度量值相联系的细节所达到的程度方面的信息。它给出了后面这个问题的答案:“如何描述事实表的单个行?”。

    粒度定义是不容轻视的至关重要的步骤。在定义粒度时应优先考虑为业务处理获取最有原子性的信息而开发维度模型。原子型数据是所收集的最详细的信息,这样的数据不能再做更进一步的细分。通过在最低层面上装配数据,大多原子粒度在具有多个前端的应用场合显示出其价值所在。原子型数据是高度维结构化的。事实度量值越细微并具有原子性,就越能够确切地知道更多的事情,所有那些确切知道的事情都转换为维度。在这点上,原子型数据可以说是维度方法的一个极佳匹配。

    原子型数据可为分析方面提供最大限度的灵活性,因为它可以接受任何可能形式的约束,并可以以任何可能的形式出现。维度模型的细节性数据是稳如泰山的,并随时准备接受业务用户的特殊攻击。

    当然,可以总是给业务处理定义较高层面的粒度,这种粒度表示最具有原子性的数据的聚集。不过,只要选取较高层面的粒度,就意味着将自己限制到更少或者细节性可能更小的维度上了。具有较少粒度性的模型容易直接遭到深入到细节内容的不可预见的用户请求的攻击。聚集概要性数据作为调整性能的一种手段起着非常重要的作用,但它绝对不能作为用户存取最低层面的细节内容的替代品。遗憾的是,有些权威人士在这方面一直显得含糊不清。他们宣称维度模型只适合于总结性数据,并批评那些认为维度建模方法可以满足预测业务需求的看法。这样的误解会随着细节性的原子型数据在维度模型中的出现而慢慢地消逝。

    2.3 第三步 选定维度

    维度所引出的问题是,“业务人员将如何描述从业务处理过程得到的数据?”应该用一组在每个度量上下文中取单一值而代表了所有可能情况的丰富描述,将事实表装扮起来。如果对粒度方面的内容很清楚,那么维度的确定一般是非常容易的。通过维度的选定,可以列出那些使每个维度表丰满起来的离散的文本属性。常见维度的例子包括日期、产品、客户、账户和机构等。

    2.4 第四步 确定事实

    设计过程的第四步同时也是最后一步,在于仔细确定哪些事实要在事实表中出现。事实的确定可以通过回答“要对什么内容进行评测”这个问题来进行。业务用户在这些业务处理性能度量值的分析方面具有浓厚的兴趣。设计中所有供选取的信息必须满足在第2步中定义的粒度要求。明显属于不同粒度的事实必须放在单独的事实表中。通常可以从以下三个角度来建立事实表[2]

    1、针对某个特定的行为动作,建立一个以行为活动最小单元为粒度的事实表。最小活动单元的定义,依赖于分析业务需求。比如用户的一次网页点击行为、一次网站登录行为,一次电话通话记录。这种事实表,主要用于从多个维度统计,行为的发生情况,主要用于业务分布情况,绩效考核比较等方面的数据分析。

    2、针对某个实体对象在当前时间上的状况。我们通过对这个实体对象在不同阶段存储它的快照,比如账户的余额、用户拥有的产品数等,通过这种可以统计实体对象在不同的生命周期中的关键数量指标。

    3、针对业务活动中的重要分析和跟踪对象,统计在整个企业不同业务活动中的发生情况。比如会员,可以执行或参与多个特定的行为活动。这种事实表是以上两种事实表的一个总结和归纳。它主要用于针对我们业务中的活动对象进行跟踪和考察。

    3 数据仓库总线结构

    业务与IT机构一般都对不同业务处理过程的集成很感兴趣。低级别业务分析师在这方面的愿望可能并不是很急迫,但那些处于较高管理阶层的人员非常清楚,在跨业务的范围内进行数据的查看对于提高评估性能是很必要的。众多的数据仓库项目将注意力放在从终端到终端的视角,更好地理解顾客关系的管理需求方面了。如图3.1所示,在某大型国有银行中,在业务价值链的产品运营中,包含许多相关的业务处理,如营销支持、产品运营、风险管控、财务绩效等诸多业务处理。

    维度建模的基本概念及过程

    图3.1业务价值链

    如果针对这些业务处理分别进行维度建模、建立独立数据集市,数据集市之间没有共享公共的维度,那么就会出现问题,数据集市就会变成孤立的集市,不能组合成数据仓库,而一致性维度的提出正式为了解决这个问题。图3.2给出了这种维度共享情形的逻辑表示形式.

    维度建模的基本概念及过程

    图3.2业务处理之间的维度共享

    共享公共的维度对于设计可以进行集成的数据集市来说,具有绝对的决定性作用。这样做使得来自不同处理的性能度量值可以被组合到单个报表中去。具体的实现过程是,使用多通路的SQL单独查询各个集市,然后基于共同的维度属性对查询结果施加外连接。这个通常称作交叉探查(Drill Across)的连接,在维度表属性具有同一性的情况下是很直接的。

    将一组分布在各处的相关业务处理成一个综合的数据仓库来说,总线结构是最基本的要素。

    3.1 数据仓库总线结构

    很显然,想一个步骤就建成企业数据仓库太令人望而生畏了,然而,将它分成孤立的片段进行建造又会挫败一致性这个压倒一切的目标。要使数据仓库能够长期地成功运转,很需要有一种在体系结构上可以按增量方式建造企业数据仓库的方法。这里提倡使用的一种方法就是数据仓库总线结构。

    通过为数据仓库环境定义标准的总线接口,独立的数据集市就可以由不同的小组在不同的时间进行实现。只要遵循这个标准,独立的数据集市就可以插入到一起并有效地共存。所有业务处理将创建一个维度模型系列,这些模型共享一组综合的具有一致性的共用维度,如图3.3。

    维度建模的基本概念及过程

    图3.3 数据仓库总线结构

    数据仓库总线结构提供了一种可用于分解企业数据仓库规划任务的合理方法。在体系结构确立阶段的较短时间内,开发团队设计出一整套在企业范围内具有统一解释的标准化维度与事实。这样,数据体系结构的框架就建立起来了。然后,开发团队可以全力以赴去实现严格依照体系结构进行迭代开发的独立数据集市。随着独立数据集市的投入使用,它们像积木块一样搭在了一起。在某种意义上讲,需要存在足够的数据集市才可能为集成的企业数据仓库带来美好的前景。

    总线结构使数据仓库管理人员获取两个方面的优势。一方面,他们有了指导总体设计的体系框架,并且将问题分成了可以根据具体时限加以实施的以字节计量的数据集市块。另一方面,各数据集市开发团队遵照体系指南,可以相对独立地异步地开展工作。

    3.2 一致性维度

    在理解了总线结构的重要性以后,现在可以进一步开发发挥数据仓库总线奠基石作用的一致性标准维度了一致性维度要么是同一的,要么是具有最佳粒度性与细节性的维度在严格数学意义上的子集。例如,如果建立月维度话,月维度的各种描述必须与日期维度中的完全一致,最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集,在后续钻取等操作时可以保持一致。

    一致的维度具有一致的维度关键字、一致的属性列名字、一致的属性定义以及一致的属性值(将转化成一致的报表标签与分组标识)。如果属性标签的标记不同或者包含不同的值,维度表就不是一致的(不被处理成一致的)。如果客户或者产品维度是按非一致的方式进行配置的,那么,要么分散的数据集市不能在一起使用,要么更为严重的是,试图将它们用在一起将产生无效的结果。

    一致的维度以几种不同的样式出现。在最基本的层次上,一致的维度意味着与同它们相连接的每种可能的事实表具有完全相同的内容。连接到产品服务签约事实上的日期维度表与连接到产品服务账户余额事实上的日期维度表是同一的。实际上,一致的维度在数据库范围内可能就是相同的物理表。不过,基于对配有多种数据库平台的数据仓库技术环境的典型复杂性的考虑,维度更有可能同时在每个数据集市都存在拷贝。在其中任何一种情况下,两个数据集市的日期维度都将具有相同数目的行、相同的关键字值、相同的属性标签、相同的属性定义与相同的属性值等。同样,也存在一致的数据内容、数据解释与用户展示。

    3.3 一致性事实

    到现在为止,我们已经讨论了建立一致性维度以将数据集市维系在一起的中心任务。这涵盖了数据仓库迁移开发所要付出的大量工作努力,余下的努力要投入到建立一致性事实定义上。

    通常,像利润、经济资本、产品覆盖度、客户满意度以及其他关键性指标(KPI)需要在企业级共享的度量指标,都是必须保持一致性的事实。一般地说,事实表数据并不在各个数据集市之间明确地进行拷贝。不过,如果事实确实存在于多个位置,那么支撑这些事实的定义与方程(公式)都必须是相同的,假如将它们当作同种事物看待的话,如果这些事实具有相同的标记,那么需要在相同维度环境下对它们进行定义,同时使其在各个数据集市之间具有相同的度量单位。必须在数据命名实践中接受规范的约束,如果不可能做到使事实完全一致,那么应该对不同的解释给出不同的名称。这样可以减少计算中使用不兼容的事实的可能性。

    4 总结

    本文作为维度建模综述性文章,基于维度建模理论知识并结合某企业的维度建模实践介绍了事实表、维度表、数据仓库总线结构、一致性维度、一致性事实等维度模型中的基本概念以及维度建模的设计过程。

    5 参考资料

    [1].Ralph Kimball著,谭明金译.《数据仓库工具箱:维度建模的完全指南(第二版)》,电子工业出版社,2003.

    2参照3种不同类型的事实表

     

    http://blog.itpub.net/23716337/viewspace-1118751/

    展开全文
  • 业务分析,离不开维度建模,维度相当于是数据所处环境。维度建模框架作为BI平台,是DW/BI项目成功关键,已经得到广泛认可。数据展现要获得成功,就必须建立在简单性基础上,使用户能够方便地理解数据库,使...

    业务分析,离不开维度建模,维度相当于是数据所处的环境。维度建模框架作为BI平台,是DW/BI项目成功的关键,已经得到广泛的认可。数据展现要获得成功,就必须建立在简单性的基础上,使用户能够方便地理解数据库,使软件能方便地访问数据库,维度建模就是时刻考虑如何提供简单性,坚定不移地回到业务驱动的场景,坚持以用户的可理解性和查询性能为目标,才能建立始终如一地服务于组织的分析需求的设计。

    维度建模循环,是一个循序渐进的过程,如下图:

    06a96f44ab70fd8e358840135451a7c5.png

    图1 - 维度建模循环

    企业关键过程价值链识别

    什么是关键价值链?

    价值链标明了组织主要活动的自然的、逻辑的流程,通俗一点说,就是企业的主要经营活动流程,比如下图所举的零售商的例子就比较好理解了,一个企业包含了好些这样的价值链子集,这些子集的集合就构成了企业的关键过程价值链。

    操作型源系统通常在价值链的每个步骤建立事务或者快照,我们要坚持让关键步骤进入系统的节点,而且是不可避开的,多数DW/BI系统的主要目标是监控关键步骤的性能结果,这样企业的关键活动都在受控中。

    9436c0c109d6d5df12b9ea6079471aee.png

    图2 - 零售商价值子链举例

    企业的价值链弄清楚了之后,我们就可以得到具有共享维度的企业数据仓库总线图。

    2ceb553568e22176036f70334bd3f696.png

    图3 - 具有共享维度的企业数据仓库总线

    对应总线图,我们就可以得到相应的总线矩阵,这一步就是图到表的转换。矩阵的行都是组织的业务过程,矩阵的列都是企业的公共维度。

    38262bc14e2a318f23239f796526cf25.png

    图4 - 总线矩阵

    我们还能得到利益相关方矩阵,组织活动和人员都是关联的,

    9cd9923b4f962066e39130e40e4526ee.png

    图5 - 利益相关方矩阵

    总线矩阵选择目标业务

    总线矩阵下有很多业务过程,那么我们在优先级的选择上应该将注意力集中放在两个方面,一个是容易实现,二是业务影响比较高。从以下的这个图,我们可以看到Business Plan2,Business Plan3就是我们最佳的选择,我们要把有限的资源花在最重要的事情上,这一点都是相通的。这样做还有一个好处,那就是你优先安排了领导想看的内容,而且这些内容也比较容易实现,这样不仅能避免和高层管理者产生冲突,反而较容易得到管理者的器重。

    c6592e637faf92940243b9d525a09240.png

    图6 - 目标业务选择

    建立高层维度模型图

    高层维度模型图,也叫做气泡图。我习惯用Xmind思维导图工具来做,非常方便,这一步非常有用,也一定要坚定不移的去执行,因为高层维度模型是作为内外部沟通的手段,具体体现在如下3个方面:

    1. 方便设计小组内部在进入细节设计前的讨论,谋定而后动。
    2. 保证每个人在被细节淹没前能够具有共同的理解,不至于在做的过程中迷失。
    3. 有利于与利益相关方交流时介绍项目,项目范围及数据内容,我们不可能拿着细节的内容和管理者,业务人员及其他利益相关者进行过多的讨论,高层维度模型就是最好的一个沟通桥梁,又简练又清晰。
    93bd18f7d7775b98a24f4d1fed66886b.png

    图7 - 高层维度模型图

    我们就以上图的订单作为例子,看一下气泡图包含哪些要素:

    • 气泡图图形化表示了业务过程的维度和事实表。
    • 确定了事实表和与之相关的维度表的粒度。
    • 粒度描述需要建模小组考虑满足业务需求需要什么以及物理数据源能够提供什么数据。
    • 气泡图必须根据可用的物理数据设计。
    • 总线矩阵的一行可能会用多个气泡图表示,每个气泡图对应具有特定粒度的特定事实表。
    • 大多数主要的维度在确定了粒度后可以自然的获得。
    • 清楚的事实表粒度声明可以精确地以图示化方法表示相关的维度。

    开发详细维度模型

    • 维度要解决的问题是“业务人员如何描述数据?”,常见的维度包括日期、产品、客户、员工等等。
    • 事实就是对企业业务过程的台账记录,要回答的是“过程的度量是什么?”
    • 详细的表设计文档包括维度表和事实表的设计
    • 对模型出现的问题,我们要建立相应的问题点清单进行跟踪
    80d6128745f392a8bca613f266563dfc.png

    图8 - 详细维度模型开发

    409b92202bc68780498ec46a06126008.png

    图9 - 维度表和事实表模板

    模型评审及验证

    模型评审包含IT评审和业务用户评审两部分。

    1. IT评审主要关注如下:
    • 总线矩阵评审
    • 高层模型气泡图评审
    • 浏览维度和事实表工作单细节开展
    • 存在问题评审
    1. 业务用户评审关注点如下:
    • 教育与培训
    • 描述维度模型如何能够支持业务需求
    • 总线矩阵评审
    • 高层模型气泡图
    • 评审关键维度

    形成设计文档

    每一个项目都得留下文档,不能“船过水无痕”,至少包括以下4个方面:

    1. 项目的简短描述
    2. 高层数据模型图
    3. 详细的针对每个事实和维度表的维度设计工作单
    4. 开放的问题点清单

    这一部分是基础方法论,相当于心法部分,较为枯燥,如果能准确地把握,按照这个过程来操作,至少能保证我们不会有大的偏差,倘若我们只注重最后的结果,在过程中缺少管控,往往会出现很多问题,甚至是框架性的致命错误。

    展开全文
  • 关于维度建模

    2019-07-06 09:51:04
    Ralph Kimball在《The Data Warehouse Toolkit》一书中,将维度建模的过程归纳为四个步骤:确定业务流程(Select the business process to model)确定分析粒度(D...

    Ralph Kimball在《The Data Warehouse Toolkit》一书中,将维度建模的过程归纳为四个步骤:

    • 确定业务流程(Select the business process to model)
    • 确定分析粒度(Declare the grain of the business process)
    • 确定维度(Choose the dimensions that apply to each fact table row)
    • 确定度量(Identify the numeric facts that will populate each fact table row)


    一.确定业务流程

    这里的流程指的是,公司中的一个具体的商业活动,并且其数据已经通过某种系统收集到源系统中,典型的比如:采购系统,订单系统,出货系统,库存系统等等,这些业务系统已经运行在企业的OLTP数据库上。数据仓库就是在这些OLTP的源数据的基础上来构建。建模应当一步一步来,一个流程一个流程的清理,通过倾听客户的需求,可以确定各个流程建模的优先级。

    要注意的是,这里的流程是业务流程,而不是部门流程。不能说这个A部门有个采购系统,B部门也有个采购系统,然后就针对A部门和B部门分别建模。而应该针对采购流程来建模,各部门的采购系统的数据通过ETL汇入到数据仓库的采购模型当中。

    二.确定粒度

    在选择了某个具体的业务流程后,第二步要做的就是确定粒度。所谓粒度,就是指事实表中存储的数据的汇总程度,比如一个销售系统,事实表中如果存储的是具体的每一笔销售记录,则说它的粒度比较小,如果存储的是每种商品的日销售总额的记录,则粒度相对较大。粒度的选择,决定了数据仓库的规模,也影响着分析查询的计算量。

    在数据仓库构建中,可以分两层,一层叫做ODS(Operational Data Storage),存储粒度较小的细节数据,数据仓库则在ODS的基础上,存储粒度较大的汇总数据。

    三.确定维度

    维度就是分析的角度。比如一个销售系统,从时间的角度,分析一个月那一天的销售量最好?一年中哪一个月的销售量最好?这样就有一个时间维度。从商品的角度,哪一种商品的利润最大?哪一种商品的销量最大?这样就有一个商品的维度。

    四.确定度量

    度量就是事实表中记录的数字。比如销售系统,事实表按每天的粒度设计,一条数据就代表某种商品一天的销售量,这个销售量就是度量,另外还有商品单价,一天销售总价,等等。度量是分析的基础,简单点讲,数据仓库的一个目的,就是通过不同的维度,对度量进行不同的聚合,得到各种报表。

    来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/193161/viewspace-50226/,如需转载,请注明出处,否则将追究法律责任。

    转载于:http://blog.itpub.net/193161/viewspace-50226/

    展开全文
  • 整体上是一个动态与迭代的过程。其次是高级维度建模过程,确定设计范围以及事实表、维度表的粒度。个人理解这个过程是做主题设计。其次是详细维度模型设计过程,针对关键点:维度表属性、领域值、来源、关系、数据...

    本章关键:维度建模过程、建模任务的策略性建议,输出文档。

    总体过程:业务人员、业务管理者深度参与(数据调研),数据治理、数据模型人员深度参与调研。整体上是一个动态与迭代的过程。

    其次是高级维度建模过程,确定设计范围以及事实表、维度表的粒度。个人理解这个过程是做主题设计。

    其次是详细维度模型设计过程,针对关键点:维度表属性、领域值、来源、关系、数据质量关注点。确认维度后再建模事实表。

    最后是进行评审和验证(模型要满足用户业务需求,检验加载到模型中的数据的可用性,为ETL打好基础),输出设计文档。

    维度模型是基于一系列设计会议展开,不断地明确客户需求。(一般三到四周完成一次业务过程维度模型设计)

    目标是:在ETL过程的复杂性与BI展现层的简单性和可预测性之间取得平衡。

    73d9add5ae57da165eddfa3295342e34.png

    组织工作

    参与人:业务人员、DBA、ETL,致力于达成一致性(非技术问题)。

    业务需求评审:如果跳过此环节,那就会导致设计模型是源数据驱动,没有带来业务价值。

    建模工具:电子报表?

    数据分析工具:开发源数据结构、内容、关系和获取规则。

    建立命名规则:利用旧规则进行统一。

    时间、地点协调。

    维度模型设计:确定业务过程、声明业务过程粒度、确认维度、确认事实。

    建模过程中的任务:定义模型范围和粒度的高级模型、详细设计每个表的属性和度量、结合业务用户评审和验收、设计文档定稿。

    高级维度模型,使用如下气泡图,确定事实表(订单)与相关维度表(其它所有)的粒度。

    52ae8cab5f0d63e48101592d427b1eb9.png

    详细维度设计

    气泡图设计完成后,开始关注细节。逐表逐列地定义详细地维度模型,业务人员应该参加并反馈对属性、过滤器、分组、标识、和度量的反馈。先设计维度表,然后设计事实表。

    确定维度以及属性

    确定事实

    确定缓慢变化未读技术

    详细的表设计文档

    c60cac4c5fc5bde991a49502fecf52e8.png

    对模型出现的问题进行跟踪

    维护更新总线矩阵

    模型评审与验证

    IT评审:源系统专家、DBA。先介绍基本概念,然后从总线矩阵开始评审,在总线矩阵上选择行并转换到高层模型,浏览维度和事实表工作单细节,对每个存在的表进行评审。

    核心用户评审:通常与IT评审一起。

    广泛地业务用户评审:业务培训,描述维度模型如何支持业务。

    形成设计文档:项目简述、高级数据模型图、详细地针对每个事实和维度表的设计工单、问题。

    展开全文
  • 维度建模的一般流程

    2019-10-23 11:55:42
    维度建模的这4个步骤贯穿了维度建模的整个过程和环节,下面逐一介绍。 1.选取业务 过程业务过程即企业和组织的业务活动,它们一般都有相应的源头业务系统支持。对于一个超市来说,其最基本的业务活动就是用户收银台...
  • 对于维度建模的理解

    千次阅读 2019-08-03 08:27:25
    维度建模,比起传统数仓结构,简单明了,扩展性和耦合性也有所提高。维度建模主要就是围绕着维度表与事实表而进行维度建模就是引入了了这两个表。维度和事实我理解是不需要抠细节,不需要过分强调哪一张表...
  • 维度建模的一般步骤

    2020-05-16 20:38:36
    维度建模通常以一种被称为星型模式的方式构建。所谓星型模式,就是以一个事实表为中心,周围围绕着多个维度表。... 一般使用下面的过程维度建模: 1.选择业务流程 2.声明粒度 3.确认维度 4.确认事实 ...
  • 维度建模理论

    2021-02-22 22:34:17
    维度建模是面向分析,为了提高查询性能可以增加数据冗余,反规范化设计技术。 关系模型 -在关系型数据库使用,适用于OLTP,应用第三范式,减少不于主键直接关联字段,减少数据冗余。 维度模型 -在大数据中使用...
  • 数仓-维度建模

    2020-09-29 15:34:13
    维度建模的好处3.事实表1.事务型事实表2.周期快照事实表3.累计快照事实表4.维度表5.维度建模过程6.缓慢变化维(scd) 一、维度建模介绍 1.维度建模: 是一种将数据结构化的逻辑设计方案,将客观世界分成度量(事实表...
  • 1 维度表的定义在维度建模中,通常将指标的度量称之为“事实”,将产生...维度设计既是维度建模的基础,也是其关键所在,可以说,维度表设计的质量,将决定了整个维度模型分析能力的上限。2 维度表的构成维度表通...
  • 关系建模与维度建模

    2021-01-25 12:42:44
    维度建模主要应用于OLAP系统中,通常以某一个事实表为中心进行表组织,主要面向业务,特征是可能存在数据冗余,但是能方便得到数据。 关系模型虽然冗余少,但是在大规模数据,跨表分析统计查询过程中,会造成...
  • 维度建模的事实表设计

    千次阅读 2019-03-29 09:32:35
    事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和与业务过程有关的度量。 事实表中一条记录所表达的业务细节程度被称为粒度。 通常粒度...
  • 先总结一下数据仓库工具箱中的提到的维度建模的4步过程 第一步:选择业务过程 业务过程的公共特征: 1)业务过程通常表示业务执行的活动,用行为动词表示 2)业务过程通常由某一操作型系统来支撑,如订单管理系统 3...
  • 维度建模之维度表

    2020-10-11 23:26:40
    1.维度表概述 ...维度的设计过程就是确定维度属性的过程,如何生成维度属性,以及所有生成维度属性的优势,决定了维度使用的方便性。 Kimball所说,数据仓库的能力直接与维度属性的质量和深度成...
  • 其中,针对业务系统中某张表记prodcut_id数字枚举值对应关系如下: 01 大华 02 易方达 03 汇添富 04 南方 我们直接在这张事实表中进行就需要写如下代码: case when product_id=‘01’ th...
  • 维度建模 范式建模 经常有人问我:“学习构建高性能系统最佳方法是什么?” 这个问题有很多完全有效答案,但是有一件事情对我来说比其他任何事情都要突出,那就是建模。 对您需要实现模型进行建模是该过程中...
  • 维度建模工具

    2020-09-03 18:00:18
    幵始维度建模工作前,项目组需要理解业务需求,以及作为基础源数据实际情况。 通过与、 Ik务代表交流来发现需求,用于理解他们基于关键性能指标、竞争性商业问题、 决策制定过程、支持分析需求目标。同时,...
  • 描述需要建模的业务流程。例如,需要了解和分析一个零售店的销售情况,那么与该零售店销售相关的所欲业务流程都是需要关注的。 声明粒度 声明维度模型的粒度,用于确定事实中表示的是什么,例如,一个零售店的顾客在...
  • 一般有较好大规模复杂查询响应性能,更直接面向业务,典型代表是我们比较熟知星形模型,常用就是事实表关联很多维度表、退化维度形成宽表、根据某主题下业务过程进行建模,往往是维度建模友好度更高,面向...
  • 数据仓库和商业智能(Data Warehousing and Business Intelligence, DW/BI),DW/BI 系统数据结构与标识必须符合业务用户思维过程和词汇 信息两个目的: 1.操作性记录保存(oltp) 2.分析型决策制定(olap) 维度...
  • 1 维度表的定义在维度建模中,通常将指标的度量称之为“事实”,将产生...维度设计既是维度建模的基础,也是其关键所在,可以说,维度表设计的质量,将决定了整个维度模型分析能力的上限。2 维度表的构成维度表通...
  • 维度建模笔记

    2019-04-21 17:28:59
    2、确保建模基于最细粒度,便于增加新的维度。 2、维度表主要包含不可加分类信息,用于筛选记录 维度表可以拆分为多个,是否拆分取决于维度体系相关性,例如月份与季度关系密切,可以一起放入日期维度表,而...
  • 维度建模是数据建模的一种特殊方法。维度建模有两个同义词,数据集市和星型结构。星型结构是为了更好地进行数据分析,参考下面图示的维度模型,可以有一个很直观的理解。通过它可以立即知道如何通过客户、产品、时间...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 436
精华内容 174
关键字:

维度建模的过程