建设网站实验活动小结,云南网站制作多少钱,无极门户网站,logo模板一、数仓建模的意义
数据模型就是数据组织和存储方法#xff0c;它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后#xff0c;数据才能得到高性能、低成本、高效率、高质量的使用。 高性能#xff1a;良好的数据模型能够帮助我们快速查询…一、数仓建模的意义
数据模型就是数据组织和存储方法它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后数据才能得到高性能、低成本、高效率、高质量的使用。 高性能良好的数据模型能够帮助我们快速查询所需要的数据。 低成本良好的数据模型能减少重复计算实现计算结果的复用降低计算成本。 高效率良好的数据模型能极大的改善用户使用数据的体验提高使用数据的效率。 高质量良好的数据模型能改善数据统计口径的混乱减少计算错误的可能性。 二、数据仓库建模方法论
2.1、ER模型
数据仓库之父Bill Inmon提出的建模方法是从全企业的高度用实体关系Entity RelationshipER模型来描述企业业务并用规范化的方式表示出来在范式理论上符合3NF。
2.1.1、实体关系模型
实体关系模型将复杂的数据抽象为两个概念——实体和关系。实体表示一个对象例如学生、班级关系是指两个实体之间的关系例如学生和班级之间的从属关系。
2.1.2、数据库规范化
数据库规范化是使用一系列范式设计数据库通常是关系型数据库的过程其目的是减少数据冗余增强数据的一致性。
这一系列范式就是指在设计关系型数据库时需要遵从的不同的规范。关系型数据库的范式一共有六种分别是第一范式1NF、第二范式2NF、第三范式3NF、巴斯-科德范式BCNF、第四范式(4NF和第五范式5NF。遵循的范式级别越高数据冗余性就越低。
2.1.3、三范式
2.1.3.1、函数依赖
函数依赖是指关系中属性间或者说是表中字段间的对应关系。 完全函数依赖 书上定义的意思基本是如果存在 X 属性集注意是集合说明是联合主键决定 唯一的 Y 且 X 中的任一子集都不能决定 唯一的 Y则 Y 完全依赖于 X。 例如学生数学成绩完全由该学生的学号和数学课决定所以数学课成绩完全依赖于学号数学课 部分函数依赖 定义和完全函数依赖有一点不一样就是 X 的属性集中任一子集可以决定唯一的 Y则 Y 部分依赖于 X。 例如学生学号和姓名可以决定唯一的学生但是学生号也可以决定唯一的学生 传递函数依赖 定义设 R 为任一给定关系 X Y Z 为其不同的属性子集若 X — Y, Y 不决定 X 且 Y —Z则有 X —Z称为 Z 传递函数依赖于 X 例如书的出版编号是唯一版权归出版社所有所以只能由该出版社出版。所以存在函数依赖书出版编号—出版社名出版社名—出版社地址但是出版社名不能决定唯一的出版书编号除非出版社只出版过一本书那我没话说?则有出版社地址传递函数依赖于出版书编号 2.1.3.2、第一范式
每一列都是不可分割的原子数据项什么意思每一项都不可分割像下面的表格就能分割所以它连第一范式都算不上 2.1.3.3、第二范式
在1NF基础上非主属性必须完全依赖于主键属性在1NF基础上消除非主属性对主键属性的部分函数依赖不能存在部分依赖函数。
如下分数完全依赖学号、课名但是姓名不完全依赖学号、姓名 2.1.3.4、第三范式
在2NF的基础上任何的非主属性不依赖于其他非主属性 在第二范式基础上消除传递依赖
注意看第二范式的学生表存在系主任依赖于系名 系名--- 系主任所以不符合第三范式 继续拆分 ER模型这种建模方法的出发点是整合数据其目的是将整个企业的数据进行组合和合并并进行规范处理减少数据冗余性保证数据的一致性。这种模型并不适合直接用于分析统计。 2.2、维度建模
数据仓库领域的令一位大师——Ralph Kimball倡导的建模方法为维度建模。维度模型将复杂的业务通过事实和维度两个概念进行呈现。
事实通常对应业务过程业务过程可以概括为一个个不可拆分的行为事件例如电商交易中的下单取消订单付款退单等都是业务过程。
而维度通常对应业务过程发生时所处的环境如何人何时何地干了什么事。 下图为一个典型的维度模型其中位于中心的SalesOrder为事实表其中保存的是下单这个业务过程的所有记录。位于周围每张表都是维度表包括Date日期Customer顾客Product产品Location地区等这些维度表就组成了每个订单发生时所处的环境即何人、何时、在何地下单了何种产品。从图中可以看出模型相对清晰、简洁。 维度建模以数据分析作为出发点为数据分析服务因此它关注的重点的用户如何更快的完成需求分析以及如何实现较好的大规模复杂查询的响应性能。
三、维度建模理论之事实表
3.1 事实表概述
事实表作为数据仓库维度建模的核心紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用维度表外键以及该业务过程的度量通常是可累加的数字类型字段。
3.1.1 事实表特点
事实表通常比较“细长”即列较少但行较多且行的增速快。
3.1.2 事实表分类
事实表有三种类型分别是事务事实表、周期快照事实表、累积快照事实表每种事实表都具有不同的特点和适用场景下面逐个介绍。
3.2、事务型事实表
3.2.1 概述
事务事实表用来记录各业务过程它保存的是各业务过程的原子操作事件如查订单、下单即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。
事务型事实表可用于分析与各业务过程相关的各项统计指标由于其保存了最细粒度的记录可以提供最大限度的灵活性可以支持无法预期的各种细节层次的统计需求。
3.2.2 设计流程
设计事务事实表时一般可遵循以下四个步骤
选择业务过程→声明粒度→确认维度→确认事实
1选择业务过程
在业务系统中挑选我们感兴趣的业务过程业务过程可以概括为一个个不可拆分的行为事件例如电商交易中的下单取消订单付款退单等都是业务过程。通常情况下一个业务过程对应一张事务型事实表。
2声明粒度
业务过程确定后需要为每个业务过程声明粒度。即精确定义每张事务型事实表的每行数据表示什么应该尽可能选择最细粒度以此来应各种细节程度的需求。
典型的粒度声明如下订单事实表中一行数据表示的是一个订单中的一个商品项。
3确定维度
确定维度具体是指确定与每张事务型事实表相关的维度有哪些。
确定维度时应尽量多的选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度。
4确定事实
此处的“事实”一词指的是每个业务过程的度量值通常是可累加的数字类型的值例如次数、个数、件数、金额等。
经过上述四个步骤事务型事实表就基本设计完成了。第一步选择业务过程可以确定有哪些事务型事实表第二步可以确定每张事务型事实表的每行数据是什么第三步可以确定每张事务型事实表的维度外键第四步可以确定每张事务型事实表的度量值字段。
3.2.3、不足
事务型事实表可以保存所有业务过程的最细粒度的操作事件故理论上其可以支撑与各业务过程相关的各种统计粒度的需求。但对于某些特定类型的需求其逻辑可能会比较复杂聚合或者效率会比较低下。例如
1存量型指标
例如商品库存账户余额等。此处以电商中的虚拟货币为例虚拟货币业务包含的业务过程主要包括获取货币和使用货币两个业务过程各自对应一张事务型事实表一张存储所有的获取货币的原子操作事件另一张存储所有使用货币的原子操作事件。
假定现有一个需求要求统计截至当日的各用户虚拟货币余额。由于获取货币和使用货币均会影响到余额故需要对两张事务型事实表进行聚合且需要区分两者对余额的影响加或减另外需要对两张表的全表数据聚合才能得到统计结果。
可以看到不论是从逻辑上还是效率上考虑这都不是一个好的方案。
同一个指标需要聚合多个表的结果
2多事务关联统计
例如现需要统计最近30天用户下单到支付的时间间隔的平均值。统计思路应该是找到下单事务事实表和支付事务事实表过滤出最近30天的记录然后按照订单id对两张事实表进行关联之后用支付时间减去下单时间然后再求平均值。
逻辑上虽然并不复杂但是其效率较低应为下单事务事实表和支付事务事实表均为大表大表join大表的操作应尽量避免。
可以看到在上述两种场景下事务型事实表的表现并不理想。下面要介绍的另外两种类型的事实表就是为了弥补事务型事实表的不足的。
需要使用到多个事实表进行关联的时候由于数据量大造成效率低下
3.3、周期型快照事实表
3.3.1 概述
周期快照事实表以具有规律性的、可预见的时间间隔来记录事实主要用于分析一些存量型例如商品库存账户余额或者状态型空气温度行驶速度指标。
对于商品库存、账户余额这些存量型指标业务系统中通常就会计算并保存最新结果所以定期同步一份全量数据到数据仓库构建周期型快照事实表就能轻松应对此类统计需求而无需再对事务型事实表中大量的历史记录进行聚合了。
对于空气温度、行驶速度这些状态型指标由于它们的值往往是连续的我们无法捕获其变动的原子事务操作所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样构建周期型快照事实表。
3.3.2 设计流程
1确定粒度
周期型快照事实表的粒度可由采样周期和维度描述故确定采样周期和维度后即可确定粒度。采样周期通常选择每日。
维度可根据统计指标决定例如指标为统计每个仓库中每种商品的库存则可确定维度为仓库和商品。
确定完采样周期和维度后即可确定该表粒度为每日-仓库-商品。
2确认事实
事实也可根据统计指标决定例如指标为统计每个仓库中每种商品的库存则事实为商品库存。
3.3.3 事实类型
此处的事实类型是指度量值的类型而非事实表的类型。事实度量值共分为三类分别是可加事实半可加事实和不可加事实。
1可加事实
可加事实是指可以按照与事实表相关的所有维度进行累加例如事务型事实表中的事实。
2半可加事实
半可加事实是指只能按照与事实表相关的一部分维度进行累加例如周期型快照事实表中的事实。以上述各仓库中各商品的库存每天快照事实表为例这张表中的库存事实可以按照仓库或者商品维度进行累加但是不能按照时间维度进行累加因为将每天的库存累加起来是没有任何意义的。
3不可加事实
不可加事实是指完全不具备可加性例如比率型事实。不可加事实通常需要转化为可加事实例如比率可转化为分子和分母。 3.4 累积型快照事实表
3.4.1 概述
累计快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表如交易流程中的下单、支付、发货、确认收货业务过程。
累积型快照事实表通常具有多个日期字段每个日期对应业务流程中的一个关键业务过程里程碑。 订单id 用户id 下单日期 支付日期 发货日期 确认收货日期 订单金额 支付金额 1001 1234 2020-06-14 2020-06-15 2020-06-16 2020-06-17 1000 1000
累积型快照事实表主要用于分析业务过程里程碑之间的时间间隔等需求。例如前文提到的用户下单到支付的平均时间间隔使用累积型快照事实表进行统计就能避免两个事务事实表的关联操作从而变得十分简单高效。
3.4.2 设计流程
累积型快照事实表的设计流程同事务型事实表类似也可采用以下四个步骤下面重点描述与事务型事实表的不同之处。
选择业务过程→声明粒度→确认维度→确认事实。
1选择业务过程
选择一个业务流程中需要关联分析的多个关键业务过程多个业务过程对应一张累积型快照事实表。
2声明粒度
精确定义每行数据表示的是什么尽量选择最小粒度。
3确认维度
选择与各业务过程相关的维度需要注意的是每各业务过程均需要一个日期维度。
4确认事实
选择各业务过程的度量值。
四、维度建模理论之维度表
4.1、维度表概述
维度表是维度建模的基础和灵魂。前文提到事实表紧紧围绕业务过程进行设计而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段维度字段称为维度属性。
4.2、维度表设计步骤
1确定维度表
在设计事实表时已经确定了与每个事实表相关的维度理论上每个相关维度均需对应一张维度表。需要注意到可能存在多个事实表与同一个维度都相关的情况这种情况需保证维度的唯一性即只创建一张维度表。另外如果某些维度表的维度属性很少例如只有一个**名称则可不创建该维度表而把该表的维度属性直接增加到与之相关的事实表中这个操作称为维度退化。
2确定主维表和相关维表
此处的主维表和相关维表均指业务系统中与某维度相关的表。例如业务系统中与商品相关的表有sku_infospu_infobase_trademarkbase_category3base_category2base_category1等其中sku_info就称为商品维度的主维表其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。
3确定维度属性
确定维度属性即确定维度表字段。维度属性主要来自于业务系统中与该维度对应的主维表和相关维表。维度属性可直接从主维表或相关维表中选择也可通过进一步加工得到。
确定维度属性时需要遵循以下要求
1尽可能生成丰富的维度属性
维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源是数据易用性的关键。维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。
2尽量不使用编码而使用明确的文字说明一般可以编码和文字共存。
3尽量沉淀出通用的维度属性
有些维度属性的获取需要进行比较复杂的逻辑处理例如需要通过多个字段拼接得到。为避免后续每次使用时的重复处理可将这些维度属性沉淀到维度表中。
4.3、维度设计要点
4.3.1 规范化与反规范化
规范化是指使用一系列范式设计数据库的过程其目的是减少数据冗余增强数据的一致性。通常情况下规范化之后一张表的字段会拆分到多张表。
反规范化是指将多张表的数据冗余到一张表其目的是减少join操作提高查询性能。在设计维度表时如果对其进行规范化得到的维度模型称为雪花模型如果对其进行反规范化得到的模型称为星型模型。 星型模型基本只有一层维度表
雪花模型有多层的维度表 星座模型有多个事实表公用同一个维度表即多个星型交织在一起。 数据仓库系统的主要目的是用于数据分析和统计所以是否方便用户进行统计分析决定了模型的优劣。采用雪花模型用户在统计分析的过程中需要大量的关联操作使用复杂度高同时查询性能很差而采用星型模型则方便、易用且性能好。所以出于易用性和性能的考虑维度表一般是很不规范化的。
4.3.2 维度变化
维度属性通常不是静态的而是会随时间变化的数据仓库的一个重要特点就是反映历史的变化所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态通常有以下两种做法分别是全量快照表和拉链表。
1全量快照表
离线数据仓库的计算周期通常为每天一次所以可以每天保存一份全量的维度数据。这种方式的优点和缺点都很明显。
优点是简单而有效开发和维护成本低且方便理解和使用。
缺点是浪费存储空间尤其是当数据的变化比例比较低时。
2拉链表
拉链表的意义就在于能够更加高效的保存维度信息的历史状态。
1什么是拉链表
拉链表是针对数据仓库设计中表存储数据的方式而定义的顾名思义所谓拉链就是记录历史。记录一个事物从开始一直到当前状态的所有变化的信息。(注拉链表一般包含一个数据有效的起始日期和结束日期如果结束日期长久有效将会记录为日期的极大值) 2为什么要做拉链表
拉链表适合于数据会发生变化但是变化频率并不高的维度即缓慢变化维。
比如用户信息会发生变化但是每天变化的比例不高如果数据量有一定规模按照每日全量的方式保存效率很低。比如1亿用户*365天每天一份用户信息每日做全量效率低。 3拉链表的使用场景
在数据仓库的数据模型设计过程中经常会遇到下面这种表的设计 有一些表的数据量很大比如一张用户表大约10亿条记录50个字段这种表即使使用ORC压缩单张表的存储也会超过100G在HDFS使用双备份或者三备份的话就更大一些。 表中的部分字段会被update更新操作如用户联系方式产品的描述信息订单的状态等等。 需要查看某一个时间点或者时间段的历史快照信息比如查看某一个订单在历史某一个时间点的状态。 表中的记录变化的比例和频率不是很大比如总共有10亿的用户每天新增和发生变化的有200万左右变化的比例占的很小。 4如何使用拉链表 5设计拉链表
在2017-01-01这一天表中的数据是 注册日期 用户编号 手机号码 2017-01-01 001 111111 2017-01-01 002 222222 2017-01-01 003 333333 2017-01-01 004 444444
在2017-01-02这一天表中的数据是 用户002和004资料进行了修改005是新增用户 注册日期 用户编号 手机号码 备注 2017-01-01 001 111111 由222222变成233333 2017-01-01 002 222222 2017-01-01 003 333333 2017-01-01 004 444444 由444444变成432432 2017-01-02 005 555555 2017-01-02新增
在2017-01-03这一天表中的数据是 用户004和005资料进行了修改006是新增用户 注册日期 用户编号 手机号码 备注 2017-01-01 001 111111 由222222变成233333 2017-01-01 002 222222 2017-01-01 003 333333 2017-01-01 004 444444 由432432变成654321 2017-01-02 005 555555 由555555变成115115 2017-01-03 006 666666 2017-01-03新增
如果在数据仓库中设计成历史拉链表保存该表则会有下面这样一张表这是最新一天即2017-01-03的数据 注册日期 用户编号 手机号码 t_start_date t_end_date 2017-01-01 001 111111 2017-01-01 9999-12-31 2017-01-01 002 222222 2017-01-01 2017-01-01 2017-01-01 002 233333 2017-01-02 9999-12-31 2017-01-01 003 333333 2017-01-01 9999-12-31 2017-01-01 004 444444 2017-01-01 2017-01-01 2017-01-01 004 432432 2017-01-02 2017-01-02 2017-01-01 004 654321 2017-01-03 9999-12-31 2017-01-02 005 555555 2017-01-02 2017-01-02 2017-01-02 005 115115 2017-01-03 9999-12-31 2017-01-03 006 666666 2017-01-03 9999-12-31
说明 t_start_date表示该条记录的生命周期开始时间t_end_date表示该条记录的生命周期结束时间。 t_end_date 9999-12-31’表示该条记录目前处于有效状态。 如果查询当前所有有效的记录则select * from user where t_end_date ‘9999-12-31’。 如果查询2017-01-02的历史快照则select * from user where t_start_date ‘2017-01-02’ and t_end_date ‘2017-01-02’。此处要好好理解是拉链表比较重要的一块。 4.3.3 多值维度
如果事实表中一条记录在某个维度表中有多条记录与之对应称为多值维度。例如下单事实表中的一条记录为一个订单一个订单可能包含多个商品所会商品维度表中就可能有多条数据与之对应。
针对这种情况通常采用以下两种方案解决。
第一种降低事实表的粒度例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。
第二种在事实表中采用多字段保存多个维度值每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。
建议尽量采用第一种方案解决多值维度问题。
4.3.4 多值属性
维表中的某个属性同时有多个值称之为“多值属性”例如商品维度的平台属性和销售属性每个商品均有多个属性值。
针对这种情况通常有可以采用以下两种方案。
第一种将多值属性放到一个字段该字段内容为key1:value1key2:value2的形式例如一个手机商品的平台属性值为“品牌:华为系统:鸿蒙CPU:麒麟990”。
第二种将多值属性放到多个字段每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。 五、数据仓库设计
5.1、为什么要分层 把复杂问题简单化将复杂的任务分解成多层来完成每一层只处理简单任务方便定位问题。 减少重复开发规范数据分层通过中间层数据能够减少极大的重复计算增加一次计算结果的复用性。 隔离原始数据不论是数据的异常还是数据的敏感性使真实数据与统计数据解耦开。
5.2、数据仓库分层规划
优秀可靠的数仓体系需要良好的数据分层结构。合理的分层能够使数据体系更加清晰使复杂问题得以简化。以下是该项目的分层规划。 ODS层原始数据层存放原始数据直接加载原始日志、数据数据保持原貌不做处理。 DWD层对ODS层数据进行清洗去除空值脏数据超过极限范围的数据、维度退化脱敏等。 DWS层以DWD为基础按天进行轻度汇总。 DWT层以DWS为基础按主题进行汇总。 ADS层为各种报表提供数据。 DIM层可以理解为一些字典表、单独存放。
5.2、数据仓库构建流程
以下是构建数据仓库的完整流程。 5.2.1、数据调研
数据调研重点要做两项工作分别是业务调研和需求分析。这两项工作做的是否充分直接影响着数据仓库的质量。
1业务调研
业务调研的主要目标是熟悉业务流程、熟悉业务数据。
熟悉业务流程要求做到明确每个业务的具体流程需要将该业务所包含的每个业务过程一一列举出来。
熟悉业务数据要求做到将数据包括埋点日志和业务数据表与业务过程对应起来明确每个业务过程会对哪些表的数据产生影响以及产生什么影响。产生的影响需要具体到是新增一条数据还是修改一条数据并且需要明确新增的内容或者是修改的逻辑。
下面业务电商中的交易为例进行演示交易业务涉及到的业务过程有买家下单、买家支付、卖家发货买家收货具体流程如下图。 2需求分析
典型的需求指标如最近一天各省份手机品类订单总额。
分析需求时需要明确需求所需的业务过程及维度例如该需求所需的业务过程就是买家下单所需的维度有日期省份商品品类。
3总结
做完业务分析和需求分析之后要保证每个需求都能找到与之对应的业务过程及维度。若现有数据无法满足需求则需要和业务方进行沟通例如某个页面需要新增某个行为的埋点。 5.2.2、明确数据域
数据仓库模型设计除横向的分层外通常也需要根据业务情况进行纵向划分数据域。
划分数据域的意义是便于数据的管理和应用。
通常可以根据业务过程或者部门进行划分本项目根据业务过程进行划分需要注意的是一个业务过程只能属于一个数据域。
下面是本数仓项目所需的所有业务过程及数据域划分详情。 数据域 业务过程 交易域 加购、下单、取消订单、支付成功、退单、退款成功 流量域 页面浏览、启动应用、动作、曝光、错误 用户域 注册、登录 互动域 收藏、评价 工具域 优惠券领取、优惠券使用下单、优惠券使用支付
5.2.3、构建业务总线矩阵
业务总线矩阵中包含维度模型所需的所有事实业务过程以及维度以及各业务过程与各维度的关系。矩阵的行是一个个业务过程矩阵的列是一个个的维度行列的交点表示业务过程与维度的关系。 一个业务过程对应维度模型中一张事务型事实表一个维度则对应维度模型中的一张维度表。所以构建业务总线矩阵的过程就是设计维度模型的过程。但是需要注意的是总线矩阵中通常只包含事务型事实表另外两种类型的事实表需单独设计。
按照事务型事实表的设计流程选择业务过程-声明粒度-确认维度-确认事实得到的最终的业务总线矩阵见以下表格。 后续的DWD层以及DIM层的搭建需参考业务总线矩阵。 5.2.4、明确统计指标
明确统计指标具体的工作是深入分析需求构建指标体系。构建指标体系的主要意义就是指标定义标准化。所有指标的定义都必须遵循同一套标准这样能有效的避免指标定义存在歧义指标定义重复等问题。
1指标体系相关概念
1原子指标
原子指标基于某一业务过程的度量值是业务定义中不可再拆解的指标原子指标的核心功能就是对指标的聚合逻辑进行了定义。我们可以得出结论原子指标包含三要素分别是业务过程、度量值和聚合逻辑。
例如订单总额就是一个典型的原子指标其中的业务过程为用户下单、度量值为订单金额聚合逻辑为sum()求和。需要注意的是原子指标只是用来辅助定义指标一个概念通常不会对应有实际统计需求与之对应。
2派生指标
派生指标基于原子指标其与原子指标的关系如下图所示。 与原子指标不同派生指标通常会对应实际的统计需求。请从图中的例子中体会指标定义标准化的含义。
3衍生指标
衍生指标是在一个或多个派生指标的基础上通过各种逻辑运算复合而成的。例如比率、比例等类型的指标。衍生指标也会对应实际的统计需求。 2指标体系对于数仓建模的意义
通过上述两个具体的案例可以看出绝大多数的统计需求都可以使用原子指标、派生指标以及衍生指标这套标准去定义。同时能够发现这些统计需求都直接的或间接的对应一个或者是多个派生指标。
当统计需求足够多时必然会出现部分统计需求对应的派生指标相同的情况。这种情况下我们就可以考虑将这些公共的派生指标保存下来这样做的主要目的就是减少重复计算提高数据的复用性。
这些公共的派生指标统一保存在数据仓库的DWS层。因此DWS层设计就可以参考我们根据现有的统计需求整理出的派生指标。
指标体系.xmind
5.2.5、维度模型设计
维度模型的设计参照上述得到的业务总线矩阵即可。事实表存储在DWD层维度表存储在DIM层。
5.2.6、汇总模型设计
汇总模型的设计参考上述整理出的指标体系主要是派生指标即可。汇总表与派生指标的对应关系是一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标。请思考汇总表与事实表的对应关系是
