精华内容
下载资源
问答
  • 维度建模的一般流程

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

    维度建模的一般流程

    即选择业务过程、定义粒度、确定维度和确定事实。维度建模的这4个步骤贯穿了维度建模的整个过程和环节,下面逐一介绍。

    1.选取业务

    过程业务过程即企业和组织的业务活动,它们一般都有相应的源头业务系统支持。对于一个超市来说,其最基本的业务活动就是用户收银台付款;对于一个保险公司来说,最基本的业务活动是理赔和保单等。当然在实际操作中,业务活动有可能并不是那么简单直接,此时听取用户的意见通常是这一环节最为高效的方式。
    但需要注意的是,这里谈到的业务过程并不是指业务部门或者职能。模型设计中,应将注意力集中放在业务过程而不是业务部门,如果建立的维度模型是同部门捆绑在一起的,就无法避免出现数据不一致的情况(如业务编码、含义等)。因此,确保数据一致性的最佳办法是从企业和公司全局与整体角度,对于某一个业务过程建立单一的、一致的维度模型。

    2定义粒度

    定义粒度意味着对事实表行实际代表的内容和含义给出明确的说明。粒度传递了事实表度量值相联系的细节所达到的程度的信息。其实质就是如何描述事实表的单个行。

    典型的粒度定义包括:

    超市顾客小票的每一个子项;
    医院收费单的明细子项;
    个人银行账户的每一次存款或者取款行为;
    个人银行账户每个月的余额快照。

    对于维度设计来说,在事实表粒度上达成一致非常重要,如果没有明确的粒度定义,则不能进入后面的环节。如果在后面的环节中发现粒度的定义不够或者是错误的,那么也必须返回这一环节重新定义粒度。
    在定义粒度过程中,应该最大限度地选择业务过程中最为原子性的粒度,这样可以带来后续的最大灵活度,也可以满足业务用户的任何粒度的分析需求。

    3.确定维度

    定义了粒度之后,相关业务过程的细节也就确定了,对应的维度就很容易确定。正如前文所述,维度是对度量的上下文和环境的描述。通过维度,业务过程度量与事实就会变得丰富和丰满起来。对于订单来说,常见的维度会包含商品、日期、买家、卖家、门店等而每一个维度还可以包含大量的描述信息,比如商品维度表会包含商品名称、标签价、商品品牌、商品类目、商品上线时间等。

    4.确定事实

    确定事实通过业务过程分析可能要分析什么来确定。定义粒度之后,事实和度量一般也很容易确定,比如超市的订单活动,相关的度量显然是销售数量和销售金额。
    在实际维度事实设计中,可能还会碰到度量拆分的问题,比如超市开展单个小票满10减10元的活动,如果小票金额超过10元,这10元的优惠额如何分配到每一个小票子项实际设计中,可以和业务方具体讨论并制订具体的拆分分配算法。

    展开全文
  • 这样就会很麻烦,因此这时候就要设计一张产品维度表B,包含如下两个关键字段: product_id product_name 01 大华 02 易方达 03 汇添富 04 南方 其中这两个字段对应的就是case when后面的字段product_id和then...

    针对一张表A存在如下几个字段:
    trans_id product_id cust_id merchant_no
    01
    02
    03
    04
    其中,针对业务系统中的某张表记的prodcut_id的数字枚举值对应关系如下:
    01 大华
    02 易方达
    03 汇添富
    04 南方
    我们直接在这张事实表中进行就需要写如下的代码:
    case when product_id=‘01’ then ‘大华’
    when product_id=‘02’ then ‘易方达’
    。。。。M字段
    这样就需要写一堆很冗余的case when,同时当一次写完之后,当prodcut_id
    这个字段新增了不同的枚举值比如‘05’ ‘06’之后,还需要在原始的脚本基础上
    再加两行case when的代码,这样就会导致不断新加,就不断改A表这个事实表,
    这样就会很麻烦,因此这时候就要设计一张产品维度表B,包含如下两个关键字段:
    product_id product_name
    01 大华
    02 易方达
    03 汇添富
    04 南方
    其中这两个字段对应的就是case when后面的字段product_id和then后面的字段product_name,然后再将A表与B表采用case when后面的字段product_id进行关联,而M字段对应该取product_name。

    展开全文
  • 维度建模的基本概念及过程

    万次阅读 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/

    展开全文
  • 数据仓库维度建模建设步骤

    千次阅读 2020-08-04 22:22:45
    一、数据仓库的架构 数据仓库(Data Warehouse DW)是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立...而相比较而言,雪花型架构的中间为事实表,两边的维度表可以再有其关联子表,从而表达了清晰

    一、数据仓库的架构

    数据仓库(Data Warehouse DW)是为了便于多维分析和多角度展现而将数据按特定的模式进行存储所建立起来的关系型数据库,它的数据基于OLTP源系统。数据仓库中的数据是细节的、集成的、面向主题的,以OLAP系统的分析需求为目的。

    数据仓库的架构模型包括了星型架构(图二:pic2.bmp)与雪花型架构(图三:pic3.bmp)两种模式。如图所示,星型架构的中间为事实表,四周为维度表,类似星星;而相比较而言,雪花型架构的中间为事实表,两边的维度表可以再有其关联子表,从而表达了清晰的维度层次关系。

    从OLAP系统的分析需求和ETL的处理效率两方面来考虑:星型结构聚合快,分析效率高;而雪花型结构明确,便于与OLTP系统交互。因此,在实际项目中,我们将综合运用星型架构与雪花型架构来设计数据仓库。

    那么,下面我们就来看一看,构建企业级数据仓库的流程。

    二、构建企业级数据仓库五步法

    (一)、确定主题

    即确定数据分析或前端展现的主题。例如:我们希望分析某年某月某一地区的啤酒销售情况,这就是一个主题。主题要体现出某一方面的各分析角度(维度)和统计数值型数据(量度)之间的关系,确定主题时要综合考虑。

    我们可以形象的将一个主题想象为一颗星星:统计数值型数据(量度)存在于星星中间的事实表;分析角度(维度)是星星的各个角;我们将通过维度的组合,来考察量度。那么,“某年某月某一地区的啤酒销售情况”这样一个主题,就要求我们通过时间和地区两个维度的组合,来考察销售情况这个量度。从而,不同的主题来源于数据仓库中的不同子集,我们可以称之为数据集市。数据集市体现了数据仓库某一方面的信息,多个数据集市构成了数据仓库。

    (二)、确定量度

    在确定了主题以后,我们将考虑要分析的技术指标,诸如年销售额之类。它们一般为数值型数据。我们或者将该数据汇总,或者将该数据取次数、独立次数或取最大最小值等,这样的数据称为量度。

    量度是要统计的指标,必须事先选择恰当,基于不同的量度可以进行复杂关键性能指标(KPI)等的设计和计算。

    (三)、确定事实数据粒度

    在确定了量度之后,我们要考虑到该量度的汇总情况和不同维度下量度的聚合情况。考虑到量度的聚合程度不同,我们将采用“最小粒度原则”,即将量度的粒度设置到最小。

    例如:假设目前的数据最小记录到秒,即数据库中记录了每一秒的交易额。那么,如果我们可以确认,在将来的分析需求中,时间只需要精确到天就可以的话,我们就可以在ETL处理过程中,按天来汇总数据,此时,数据仓库中量度的粒度就是“天”;反过来,如果我们不能确认将来的分析需求在时间上是否需要精确到秒,那么,我们就需要遵循“最小粒度原则”,在数据仓库的事实表中保留每一秒的数据,以便日后对“秒”进行分析。

    在采用“最小粒度原则”的同时,我们不必担心海量数据所带来的汇总分析效率问题,因为在后续建立多维分析模型(CUBE)的时候,我们会对数据提前进行汇总,从而保障产生分析结果的效率。关于建立多维分析模型(CUBE)的相关问题,我们将在下期栏目中予以阐述。

    (四)、确定维度

    维度是指分析的各个角度。例如我们希望按照时间,或者按照地区,或者按照产品进行分析,那么这里的时间、地区、产品就是相应的维度。基于不同的维度,我们可以看到各量度的汇总情况,也可以基于所有的维度进行交叉分析。

    这里我们首先要确定维度的层次(Hierarchy)和级别(Level)(图四:pic4.bmp)。如图所示,我们在时间维度上,按照“年-季度-月”形成了一个层次,其中“年”、“季度”、“月”成为了这个层次的3个级别;同理,当我们建立产品维度时,我们可以将“产品大类-产品子类-产品”划为一个层次,其中包含“产品大类”、“产品子类”、“产品”三个级别。

    那么,我们分析中所用到的这些维度,在数据仓库中的存在形式是怎样的呢?

    我们可以将3个级别设置成一张数据表中的3个字段,比如时间维度;我们也可以使用三张表,分别保存产品大类、产品子类、产品三部分数据,比如产品维度。(图五:pic5.bmp)

        另外,值得一提的是,我们在建立维度表时要充分使用代理键。代理键是数值型的ID号码(例如图六中每张表的第一个字段),它唯一标识了每一维度成员。更重要的是,在聚合时,数值型字段的匹配和比较,JOIN效率高,便于聚合。同时,代理键对缓慢变化维度有着重要的意义,在原数据主键相同的情况下,它起到了对新数据与历史数据的标识作用。

    在此,我们不妨谈一谈维度表随时间变化的问题,这是我们经常会遇到的情况,我们称其为缓慢变化维度。

    比如我们增加了新的产品,或者产品的ID号码修改了,或者产品增加了一个新的属性,此时,维度表就会被修改或者增加新的记录行。这样,我们在ETL的过程中,就要考虑到缓慢变化维度的处理。对于缓慢变化维度,有三种情况:

    1、缓慢变化维度第一种类型:历史数据需要修改。这种情况下,我们使用UPDATE方法来修改维度表中的数据。例如:产品的ID号码为123,后来发现ID号码错了,需要改写成456,那么,我们就在ETL处理时,直接修改维度表中原来的ID号码为456。

    2、缓慢变化维度第二种类型:历史数据保留,新增数据也要保留。这时,要将原数据更新,将新数据插入,我们使用UPDATE / INSERT。比如:某一员工2005年在A部门,2006年时他调到了B部门。那么在统计2005年的数据时就应该将该员工定位到A部门;而在统计2006年数据时就应该定位到B部门,然后再有新的数据插入时,将按照新部门(B部门)进行处理,这样我们的做法是将该维度成员列表加入标识列,将历史的数据标识为“过期”,将目前的数据标识为“当前的”。另一种方法是将该维度打上时间戳,即将历史数据生效的时间段作为它的一个属性,在与原始表匹配生成事实表时将按照时间段进行关联,这种方法的好处是该维度成员生效时间明确。

    3、缓慢变化维度第三种类型:新增数据维度成员改变了属性。例如:某一维度成员新加入了一列,该列在历史数据中不能基于它浏览,而在目前数据和将来数据中可以按照它浏览,那么此时我们需要改变维度表属性,即加入新的字段列。那么,我们将使用存储过程或程序生成新的维度属性,在后续的数据中将基于新的属性进行查看。

    (五)、创建事实表

    在确定好事实数据和维度后,我们将考虑加载事实表。

    在公司的大量数据堆积如山时,我们想看看里面究竟是什么,结果发现里面是一笔笔生产记录,一笔笔交易记录… 那么这些记录是我们将要建立的事实表的原始数据,即关于某一主题的事实记录表。

    我们的做法是将原始表与维度表进行关联,生成事实表(图六:pic6.bmp)。注意在关联时有为空的数据时(数据源脏),需要使用外连接,连接后我们将各维度的代理键取出放于事实表中,事实表除了各维度代理键外,还有各量度数据,这将来自原始表,事实表中将存在维度代理键和各量度,而不应该存在描述性信息,即符合“瘦高原则”,即要求事实表数据条数尽量多(粒度最小),而描述性信息尽量少。

    如果考虑到扩展,可以将事实表加一唯一标识列,以为了以后扩展将该事实作为雪花型维度,不过不需要时一般建议不用这样做。

    事实数据表是数据仓库的核心,需要精心维护,在JOIN后将得到事实数据表,一般记录条数都比较大,我们需要为其设置复合主键和索引,以实现数据的完整性和基于数据仓库的查询性能优化。事实数据表与维度表一起放于数据仓库中,如果前端需要连接数据仓库进行查询,我们还需要建立一些相关的中间汇总表或物化视图,以方便查询。

    三、什么是ETL

    在数据仓库的构建中,ETL贯穿于项目始终,它是整个数据仓库的生命线,包括了数据清洗、整合、转换、加载等各个过程。如果说数据仓库是一座大厦,那么ETL就是大厦的根基。ETL抽取整合数据的好坏直接影响到最终的结果展现。所以ETL在整个数据仓库项目中起着十分关键的作用,必须摆到十分重要的位置。

    ETL是数据抽取(Extract)、转换(Transform)、加载(Load )的简写,它是指:将OLTP系统中的数据抽取出来,并将不同数据源的数据进行转换和整合,得出一致性的数据,然后加载到数据仓库中。例如:下图就向我们展示了ETL的数据转换效果。(图七:pic7.bmp)

    那么,在这一转换过程中,我们就完成了对数据格式的更正、对数据字段的合并、以及新增指标的计算三项操作。类似地,我们也可以根据其他需求,完善数据仓库中的数据。

    简而言之,通过ETL,我们可以基于源系统中的数据来生成数据仓库。ETL为我们搭建了OLTP系统和OLAP系统之间的桥梁。

     

    五、项目实践技巧

    (一)、准备区的运用

     在构建数据仓库时,如果数据源位于一台服务器上,数据仓库在另一台服务器端,考虑到数据源Server端访问频繁,并且数据量大,需要不断更新,所以可以建立准备区数据库(图八:pic8.bmp)。先将数据抽取到准备区中,然后基于准备区中的数据进行处理,这样处理的好处是防止了在原OLTP系统中频繁访问,进行数据运算或排序等操作。

    例如我们可以按照天将数据抽取到准备区中,基于数据准备区,我们将进行数据的转换、整合、将不同数据源的数据进行一致性处理。数据准备区中将存在原始抽取表、转换中间表和临时表以及ETL日志表等。

    (二)、时间戳的运用

    时间维度对于某一事实主题来说十分重要,因为不同的时间有不同的统计数据信息,那么按照时间记录的信息将发挥很重要的作用。在ETL中,时间戳有其特殊的作用,在上面提到的缓慢变化维度中,我们可以使用时间戳标识维度成员;在记录数据库和数据仓库的操作时,我们也将使用时间戳标识信息。例如:在进行数据抽取时,我们将按照时间戳对OLTP系统中的数据进行抽取,比如在午夜0:00取前一天的数据,我们将按照OLTP系统中的时间戳取GETDATE到GETDATE减一天,这样得到前一天数据。

    (三)、日志表的运用

    在对数据进行处理时,难免会发生数据处理错误,产生出错信息,那么我们如何获得出错信息并及时修正呢? 方法是我们使用一张或多张Log日志表,将出错信息记录下来,在日志表中我们将记录每次抽取的条数、处理成功的条数、处理失败的条数、处理失败的数据、处理时间等等。这样,当数据发生错误时,我们很容易发现问题所在,然后对出错的数据进行修正或重新处理。

    (四)、使用调度

    在对数据仓库进行增量更新时必须使用调度(图九:pic9.bmp),即对事实数据表进行增量更新处理。在使用调度前要考虑到事实数据量,确定需要多长时间更新一次。比如希望按天进行查看,那么我们最好按天进行抽取,如果数据量不大,可以按照月或半年对数据进行更新。如果有缓慢变化维度情况,调度时需要考虑到维度表更新情况,在更新事实数据表之前要先更新维度表。

    调度是数据仓库的关键环节,要考虑缜密。在ETL的流程搭建好后,要定期对其运行,所以调度是执行ETL流程的关键步骤。每一次调度除了写入Log日志表的数据处理信息外,还要使用发送Email或报警服务等,这样也方便的技术人员对ETL流程的把握,增强了安全性和数据处理的准确性。

    五、总结

    构建企业级数据仓库需要简单的五步,掌握了这五步的方法,我们可以构建一个强大的数据仓库。然而,每一步都有很深的内容需要研究与挖掘,尤其在实际项目中,我们要综合考虑。例如:如果数据源的脏数据很多,在搭建数据仓库之前我们首先要进行数据清洗,以剔除掉不需要的信息和脏数据。

    ETL是OLTP系统和OLAP系统之间的桥梁,是数据从源系统流入数据仓库的通道。在数据仓库的项目实施中,它关系到整个项目的数据质量,所以马虎不得,必须将其摆到重要位置,将数据仓库这一大厦的根基筑牢!

    展开全文
  • kimball维度建模步骤

    千次阅读 2018-11-09 11:48:45
    在对业务实例研究进行描述之后,现在就可以开始维度建模的设计工作了。 第一步:选取业务处理 设计工作的第一步使,通过将对业务需求的理解与对可用数据的理解组合起来而确定 建模的业务处理内容。 建立的第一个...
  •   开始讨论维度建模设计工作前,必须考虑正确的人选 。最值得注意的是,我们强烈主张业务代表参加建模会议 。他们的加入与合作必然会增加最终模型解决用户需求的可能性。同样,组织的业务数据 管理人员也
  • 5.Kimball维度建模四步骤

    千次阅读 2018-11-14 09:38:09
     四步过程维度建模由Kimball提出,可以做为业务梳理、数据梳理后进行多维数据模型设计的指导流程,但是不能作为数据仓库系统建设的指导流程。本文就相关流程及核心问题进行解读。 二、数据仓库建设流程  以下...
  • 维度建模的缓慢变化维 1维度建模的数仓中,有一个概念SCD:slowly channing dimensions.缓慢变化维。因为在现实世界中,维度的属性并不是静态的,它会随着时间的流失而发生缓慢的变化,这种随时间发生变化的维度我们...
  • 数仓维度建模

    2020-09-13 22:28:07
    20世纪80年代末期,数据...Kimball提出了数据仓库的建模技术--维度建模(dimensional modelling),该方法是在实践观察的基础上开发的。虽然它不基于任何理论,但是在实践中却非常成功。维度建模被视为设计数据仓库和数据
  • 维度建模的优缺点

    2021-05-04 18:21:58
    维度建模方法体系中,维度是描述事实的角度,如日期、商品、地址等,事实是要度量的指标,如用户数、销售额等。 维度建模是将层次化的数据结构展开为单一层次,构建出来的数据库结构表更加符合人的直觉、易于被人...
  • 关系建模由Bill Inmon所倡导,维度建模由Ralph Kimball所倡导。 3. 关系建模 关系建模将复杂的数据抽象为两个概念——实体和关系,并使用规范化的方式表示出来。关系模型如图所示,从图中可以看出,较为松散、零碎...
  • 维度建模示例

    2021-03-17 00:34:16
    以库存模块和零售模块这两个模块来谈一谈维度建模的相关事项梳理库存业务中的表的构造与设计思想梳理一下缓慢变化维的处理方法与优缺这篇博客计划用周末来完成,只能简单的讨论一下建模概况,从维度建模...
  • 维度建模关系

    2021-05-21 00:56:22
    复杂的数据关系数据仓库模型建设数据管理一直在演进,从早期的电子表格、蛛网系统到架构式数据仓库。发展至今以维度建模和关系建模为主,而随着互联网的发展,数据从GB到PB的裱花,企业业务迭代更新...
  • 关系建模与维度建模

    2021-01-04 21:24:37
    关系建模与维度建模 当今的数据处理大致可以分成两大类:联机事务处理OLTP(on-line transaction processing)、联机分析处理OLAP(On-Line Analytical Processing)。OLTP是传统的关系型数据库的主要应用,主要是...
  • 维度建模之事实表

    千次阅读 2019-12-08 13:54:38
    维度建模之事实表 每个数据仓库都包含一个或者多个事实数据表。其中可能包含业务销售数据,如现金登记事务所产生的数据,通常包含大量的行。事实数据表的主要特点是包含数字数据(事实),并且这些数字信息可以汇总...
  • Kimball维度建模基本理论

    千次阅读 2019-08-15 15:21:07
    维度建模基础理论,以及优越之处和应用场景。阐明了何为事实和维,并且解释了相关细分类别和应用场景。
  • 维度建模 范式建模 经常有人问我:“学习构建高性能系统的最佳方法是什么?” 这个问题有很多完全有效的答案,但是有一件事情对我来说比其他任何事情都要突出,那就是建模。 对您需要实现的模型进行建模是该过程中...
  • 数仓范式建模和维度建模

    千次阅读 2019-11-17 11:29:02
    一、数仓建模分为传统型的范式建模和新型维度建模: 范式建模 Inmon提出的集线器的自上而下(EDW-DM)的数据仓库架构。操作型或事务型系统的数据源,通过ETL抽取转换和加载到数据仓库的ODS层,然后通过ODS的数据...
  • 维度建模工具

    2020-09-03 18:00:18
    幵始维度建模工作前,项目组需要理解业务需求,以及作为基础的源数据的实际情况。 通过与、 Ik务代表交流来发现需求,用于理解他们的基于关键性能指标、竞争性商业问题、 决策制定过程、支持分析需求的目标。同时,...
  • 维度建模是以业务过程为驱动 先确定某些业务过程 围绕业务过程去建立模型 通常采用自底向上的方法 从明确关键业务过程开始 再到明确粒度 最后明确事实 在我们项目初期 我们首先要确定的就是 一个数仓建模的设计 ...
  • 维度建模四步骤

    2020-09-14 17:39:17
    一、选择业务过程 二、声明粒度 三、确认维度 四、确认事实
  • 维度建模的一般步骤

    2020-05-16 20:38:36
    维度建模通常以一种被称为星型模式的方式构建。所谓星型模式,就是以一个事实表为中心,周围围绕着多个维度表。... 一般使用下面的过程维度建模: 1.选择业务流程 2.声明粒度 3.确认维度 4.确认事实 ...
  • 1.维度建模的四个步骤: 确定业务过程 声明粒度 确定维度 确定事实 2.事实表: (1)事务事实表 单事务事实表 多事务事实表(描述多个业务过程) (2)周期快照事实表(状态度量,账户余额等) (3)全量快照事实表 ...
  • 维度建模之维度表

    2020-10-11 23:26:40
    1.维度表概述 ...维度的设计过程就是确定维度属性的过程,如何生成维度属性,以及所有生成维度属性的优势,决定了维度使用的方便性。 Kimball所说,数据仓库的能力直接与维度属性的质量和深度成...
  • 数据仓库(二)之维度建模

    万次阅读 多人点赞 2018-09-12 22:29:28
    维度建模是一种将数据结构化的逻辑设计方法,它将客观世界划分为度量和上下文。度量是常常是以数值形式出现,事实周围有上下文包围着,这种上下文被直观地分成独立的逻辑块,称之为维度。它与实体-关系建模有很大的...
  • 维度建模的数据仓库中,有一个概念叫Bus Architecture,中文一般翻译为“总线架构”。总线架构是Kimball的多维体系结构(MD)中的三个关键性概念之一,另两个是一致性维度(Conformed Dimension)和一致性事实...
  • 2. 维度建模技术概述2.1 事实表2.2 维度表2.1 维度设计过程Reference 本文为《维度建模权威指南-kimball》前两章的读书笔记,如有错误,请指正。 1. 维度建模是什么? 对一个产品,我们通常会存储用户行为日志等海量...
  • 维度建模的事实表设计

    千次阅读 2019-03-29 09:32:35
    事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和与业务过程有关的度量。 事实表中一条记录所表达的业务细节程度被称为粒度。 通常粒度...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 45,041
精华内容 18,016
关键字:

维度建模的过程