当前位置:文档之家› 数据仓库主题建模点滴

数据仓库主题建模点滴

产品维表 产品ID 类别 大类别 日期维表 日期ID 日 月 季

供应商ID 供应商名称 信用等级 电话
销售主题表 产品ID 客户ID 日期ID 销售金额
供应商 客户ID
客户名称 市名 省名 国名
星型模型 Star Schema
客户维表
通过冗余的方法,尽可能把雪花或其他复杂模型转变成星型模型
一个典型的星型维
数据仓库主题建模点滴
沈志良 2007-10
DW建模的原则
简单性
方便分析展现的实现。OLTP数据实现分析展现较难
完整性
保留业务数据的所有内容,不能因建模丢失信息
高效性
执行查询时,尽可能使连接减少,提升查询效率
通用性
符合业界标准的模型(如星型),可以用主流商业BI软件 来分析展示模型数据
一致性事实
为了能在多个数据集市间进行交叉探查,一致性事实需 要保证两点:
1、指标的定义及计算方法要一致(口径一致) 2、事实的度量单位要一致。建议不同单位的事实分开建立字段保 存
一致性维度将多个数据集市在逻辑上结合在一起,一致性 事实保证不同数据集市间的事实数据可以交叉探查,一个 分布式的数据仓库就建成了。
层级维及其处理办法
通过分段的代码组来处理 通过通用维来处理
举例:行政区划码(省、地、县) 试论采用分段代码组和通用维的优缺点。 何时更适合用分段代码组?何时更适合用通用维?
主题建模的形式化方法
画出所有“星星”
产品维表
产品ID
类别
大类别
日期维表 日期ID

发货主题表
供应商
产品ID 客户ID 日期ID
维表的代理键和业务主键
大师建议 维度主键应采用代理键。例如,在日期维度表中,关 键字不应该使用任何有意义的字段,而应该使用代理键。 如果设计成有意义的字段,例如‘20060526’这样的智 能关键字(Smart Key),就给用户提供了只访问这个关 键字而不访问其他字段也能使用的可能。如果其他日期相 关描述是用户根据智能关键字生成的话,不同用户的生成 方法和结果都很可能不一样,给应用和显示带来了很大的 不一致。 Zlshen的观点 可以使用智能关键字!当需要连接星型维时,把 Smart Key当作代理键即可;当可以不连维表实现查询时, 则当作有意义的键。
销售金额
客户ID 客户名称 市名 省名 国名



销售主题星型模型
客户维表
主题建模的形式化方法
全局主题维表交叉图
需求分析后的主题建模步骤
1、找出所有公共的维度,确定每个维的代理键和 业务主键 2、找出所有事实表 3、确定事实表的度量和维 4、确定事实表的颗粒 5、是否有必要把多个事实表进行合并 6、画出星型结构图和事实维交叉图 7、确定每个维的每个属性变化的处理方式
维的变化及其处理办法
在数据仓库系统中,维度属性的变化是不可避免的,通常 我们会用缓慢变化维的三类处理策略来解决这个问题。也 就是 Type1:覆盖原属性。 Type2:添加新的维度行(成员)。 Type3:添加新的维度列。
Type2详解
纳税人属性A发生变化的例子: 变化前:
NSRDM DZDAH VDate_From VDate_To Attr_A 0010 001 200601 999912 01
例如,如果建立月维度的话,月维度的各种描述必须与 日期维度中的完全一致,最常用的做法就是在日期维度上 建立视图生成月维度。这样月维度就可以是日期维度的子 集,在后续钻取等操作时可以保持一致。 再举例,证监会所有监管单位有银行、券商、机构等几种, 银行维则是监管单位维的一个一致性维度,银行名录和属 性必须保持一致。
主题中维键为空值的处理办法
在实际的主题表中,维键为空(Null)的情形经 常发生。而一般的RDBMS系统空值都有一些特殊的 处理规则,空值的存在很可能造成一些预想不到的 结果。另外,在结果报表中,空值的出现也让人费 解。 在实际的应用中,可以增加特殊的维成员来解 决空值问题。 举例:在行业类别码中,在A000前增加: ’@000 : 空’、’@001 : 未知’等项。 以上方案需要ETL来支持。
为什么需要ODS
构建ODS的价值
简化EDW、DataMart.的ETL过程 执行ETL时减少对OLTP系统的影响 实现近期数据的回写及修改 满足部分时效性要求较高的分析查询
一个DW系统可以省略ODS,但一定会有Data Mart.,否则就不是DW。
一致性维度
在同一个集市内,一致性维度的意思是两个维度如果 有关系,要么就是完全一样的,要么就是一个维度在数学 意义上是另一个维度的子集。
变化后: NSRDM DZDAH VDate_From VDate_To Attr_A
0010 0010 001 001 200601 200605 200604 999912 01 02
Type2是目前最流行的SCD解决方案,其优点是什么? 试论Type1和Type3。
如何应用超大维的最新信息
将所有最新的属性建立一张支架维度表(outrigger) 该支架维度表中只保留维度的最新信息,用自然键做主 键,不使用代理键 当维度的属性发生变化时,直接更新这个维度表中的数 据(Type1)。对完整的维表变化依然采用Type2方式
例子:i@Report中的月报。这种事实表一般都有报表期。
累计快照粒度事实表(Accumulating SnapsDetail主题) 这种事实表一般有起止时间,止时间可能是“将来”。
维表的分类
层级维 单级维 退化维
再议星型结构
ODS中不会长期的保留数据,通常ODS保留的数据的时限最长到一个 月或三个月。而数据仓库可以保留五年、十年或更长期的数据。
ODS中保留详细数据
ODS中只保留原子数据,而不保留汇总数据。而在数据仓库中原子数 据和汇总数据都会进行保留。这和ODS可更新的特性相关,因为随时 可能将操作型系统的数据变化更新到ODS中,并且数据的迁移时间间 隔会很短,这都使汇总数据在ODS中的意义不大。
ODS(操作数据存储)是面向主题的、集成的、可变的、 反映当前数据值的和详细的数据的集合,用来满足企业 综合的、集成的以及操作型的处理需求。
数据仓库
数据仓库是一个面向主题的、集成的、相对稳定的、反 映历史变化的数据集合。这里的数据仓库一般特指最细 粒度的数据。(Kimbal & Innom的不同)
主题集(Data Mart.)
为了方便分析展现,在数据仓库(有时ODS)基础上创建的 更具业务性、一般是汇总的数据表。
ODS和数据仓库的差异
ODS中的数据是可以变化的
数据仓库中的数据一般是不进行更新的,对于错误的处理通常是采 用新的快照来进行保存。而ODS是可以按常规方法进行更新的。
ODS反映当前数据值
完整的日期维
日期主键 20060101 „„ 20060303 „„ 20061231 2006 4 12 56 2 非 2006 1 3 9 6 非 年 季度 月 周序 星期 1 1 3 节假日 其他属性 元旦 2006 1
试论采用这样的结构构建日期维的好处。
DW中数据的三个层次
ODS操作数据存储
一些概念
事实表和维表
事实表:维键和度量 维表:列上是属性,行是成员 有些表既是事实表又是维表
事实表的颗粒
刻画数据的细节程度
一些概念
根据数据粒度事实表的分类
事务粒度事实表(Transaction Grain) 周期快照粒度事实表(Periodic Snapshot Grain)
数据检查的步骤
正确性检查(Corret)
检查数据值及其描述是否真实的反映了客观事务。例如地址的描述 是否完全;与第三方软件或SQL结果比对报表中的数据是否正确。
明确性检查(Unambiguous)
检查数据值及其描述是否只有一个意思或者只有一个解释。例如地 名相同的两个县需要加区分方法。
一致性检查(Consistent)
检查数据值及其描述是否统一的采用固定的约定符号来表示。例如 币别中人民币用'CNY'。
完全性检查(Complete)
完全性有两个需要检查的地方,一个是检查字段的数据值及其描述 是否完全。例如检查是否有空值;检查记录的合计值是否完全,有 没有遗忘某些条件。
共勉
谢谢!
举例:辽宁国税最新纳税人信息维表
增加缓慢变化的原因
用TYPE2来处理缓慢变化维问题时,有时客户会提出下面这样的 问题:我们每个月有多少个新增客户? 常用解决办法:在维度表中添加一个变化原因列 (RowChangeReason)。简单的处理方式,我们可以使用两个字节 的缩写来标识变化原因。例如,新建列为 ’NW’,名称变化 为 ’LN’,邮编变化为 ’ZP’,名称和邮编一起变化为 ’LN ZP’, 以空格分开。这样处理后,我们很容易实现像“去年我们有多少客户 的邮编发生了变化?”这样的问题。 SQL如下: SELECT COUNT(DISTINCT CustomerBusinessKey) FROM Customer WHERE RowChangeReason LIKE ‘%ZP%’ AND RowEffectiveDate BETWEEN ‘20050101’ AND ‘20051231’ 这个变化原因列增强的TYPE2处理查询的能力。
相关主题