数据仓库主题建模点滴

为什么需要ODS
构建ODS的价值
简化EDW、DataMart.的ETL过程 执行ETL时减少对OLTP系统的影响 实现近期数据的回写及修改 满足部分时效性要求较高的分析查询
一个DW系统可以省略ODS，但一定会有Data Mart.，否则就不是DW。
一致性维度
在同一个集市内，一致性维度的意思是两个维度如果 有关系，要么就是完全一样的，要么就是一个维度在数学 意义上是另一个维度的子集。
wk.baidu.com
主题中维键为空值的处理办法
在实际的主题表中，维键为空（Null）的情形经 常发生。而一般的RDBMS系统空值都有一些特殊的 处理规则，空值的存在很可能造成一些预想不到的 结果。另外，在结果报表中，空值的出现也让人费 解。 在实际的应用中，可以增加特殊的维成员来解 决空值问题。 举例：在行业类别码中，在A000前增加： ’@000 ： 空’、’@001 ： 未知’等项。 以上方案需要ETL来支持。
销售金额
客户ID 客户名称 市名 省名 国名
月
季
年
销售主题星型模型
客户维表
主题建模的形式化方法
全局主题维表交叉图
需求分析后的主题建模步骤
1、找出所有公共的维度，确定每个维的代理键和 业务主键 2、找出所有事实表 3、确定事实表的度量和维 4、确定事实表的颗粒 5、是否有必要把多个事实表进行合并 6、画出星型结构图和事实维交叉图 7、确定每个维的每个属性变化的处理方式
一致性事实
为了能在多个数据集市间进行交叉探查，一致性事实需 要保证两点：
1、指标的定义及计算方法要一致（口径一致） 2、事实的度量单位要一致。建议不同单位的事实分开建立字段保 存
一致性维度将多个数据集市在逻辑上结合在一起，一致性 事实保证不同数据集市间的事实数据可以交叉探查，一个 分布式的数据仓库就建成了。
例子：i@Report中的月报。这种事实表一般都有报表期。
累计快照粒度事实表（Accumulating Snapshot Grain）。
例子：针对某合同，客户的付款累计。（另外对应付款Detail主题） 这种事实表一般有起止时间，止时间可能是“将来”。
维表的分类
层级维 单级维 退化维
再议星型结构
层级维及其处理办法
通过分段的代码组来处理 通过通用维来处理
举例：行政区划码（省、地、县） 试论采用分段代码组和通用维的优缺点。 何时更适合用分段代码组？何时更适合用通用维？
主题建模的形式化方法
画出所有“星星”
产品维表
产品ID
类别
大类别
日期维表 日期ID
日
发货主题表
供应商
产品ID 客户ID 日期ID
维的变化及其处理办法
在数据仓库系统中，维度属性的变化是不可避免的，通常 我们会用缓慢变化维的三类处理策略来解决这个问题。也 就是 Type1：覆盖原属性。 Type2：添加新的维度行（成员）。 Type3：添加新的维度列。
Type2详解
纳税人属性A发生变化的例子： 变化前：
NSRDM DZDAH VDate_From VDate_To Attr_A 0010 001 200601 999912 01
数据检查的步骤
正确性检查（Corret）
检查数据值及其描述是否真实的反映了客观事务。例如地址的描述 是否完全；与第三方软件或SQL结果比对报表中的数据是否正确。
明确性检查（Unambiguous）
检查数据值及其描述是否只有一个意思或者只有一个解释。例如地 名相同的两个县需要加区分方法。
一致性检查（Consistent）
主题集（Data Mart.）
为了方便分析展现，在数据仓库(有时ODS)基础上创建的 更具业务性、一般是汇总的数据表。
ODS和数据仓库的差异
ODS中的数据是可以变化的
数据仓库中的数据一般是不进行更新的，对于错误的处理通常是采 用新的快照来进行保存。而ODS是可以按常规方法进行更新的。
ODS反映当前数据值
一些概念
事实表和维表
事实表：维键和度量 维表：列上是属性，行是成员 有些表既是事实表又是维表
事实表的颗粒
刻画数据的细节程度
一些概念
根据数据粒度事实表的分类
事务粒度事实表（Transaction Grain） 周期快照粒度事实表（Periodic Snapshot Grain）
完整的日期维
日期主键 20060101 „„ 20060303 „„ 20061231 2006 4 12 56 2 非 2006 1 3 9 6 非 年 季度 月 周序 星期 1 1 3 节假日 其他属性 元旦 2006 1
试论采用这样的结构构建日期维的好处。
DW中数据的三个层次
ODS操作数据存储
ODS（操作数据存储）是面向主题的、集成的、可变的、 反映当前数据值的和详细的数据的集合，用来满足企业 综合的、集成的以及操作型的处理需求。
数据仓库
数据仓库是一个面向主题的、集成的、相对稳定的、反 映历史变化的数据集合。这里的数据仓库一般特指最细 粒度的数据。(Kimbal & Innom的不同)
检查数据值及其描述是否统一的采用固定的约定符号来表示。例如 币别中人民币用'CNY'。
完全性检查（Complete）
完全性有两个需要检查的地方，一个是检查字段的数据值及其描述 是否完全。例如检查是否有空值；检查记录的合计值是否完全，有 没有遗忘某些条件。
共勉
谢谢！
数据仓库主题建模点滴
沈志良 2007-10
DW建模的原则
简单性
方便分析展现的实现。OLTP数据实现分析展现较难
完整性
保留业务数据的所有内容，不能因建模丢失信息
高效性
执行查询时，尽可能使连接减少，提升查询效率
通用性
符合业界标准的模型（如星型），可以用主流商业BI软件 来分析展示模型数据
变化后： 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方式
例如，如果建立月维度的话，月维度的各种描述必须与 日期维度中的完全一致，最常用的做法就是在日期维度上 建立视图生成月维度。这样月维度就可以是日期维度的子 集，在后续钻取等操作时可以保持一致。 再举例，证监会所有监管单位有银行、券商、机构等几种， 银行维则是监管单位维的一个一致性维度，银行名录和属 性必须保持一致。
举例：辽宁国税最新纳税人信息维表
增加缓慢变化的原因
用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处理查询的能力。
ODS中不会长期的保留数据，通常ODS保留的数据的时限最长到一个 月或三个月。而数据仓库可以保留五年、十年或更长期的数据。
ODS中保留详细数据
ODS中只保留原子数据，而不保留汇总数据。而在数据仓库中原子数 据和汇总数据都会进行保留。这和ODS可更新的特性相关，因为随时 可能将操作型系统的数据变化更新到ODS中，并且数据的迁移时间间 隔会很短，这都使汇总数据在ODS中的意义不大。
产品维表 产品ID 类别 大类别 日期维表 日期ID 日 月 季
年
供应商ID 供应商名称 信用等级 电话
销售主题表 产品ID 客户ID 日期ID 销售金额
供应商 客户ID
客户名称 市名 省名 国名
星型模型 Star Schema
客户维表
通过冗余的方法，尽可能把雪花或其他复杂模型转变成星型模型
一个典型的星型维
维表的代理键和业务主键
大师建议 维度主键应采用代理键。例如，在日期维度表中，关 键字不应该使用任何有意义的字段，而应该使用代理键。 如果设计成有意义的字段，例如‘20060526’这样的智 能关键字（Smart Key），就给用户提供了只访问这个关 键字而不访问其他字段也能使用的可能。如果其他日期相 关描述是用户根据智能关键字生成的话，不同用户的生成 方法和结果都很可能不一样，给应用和显示带来了很大的 不一致。 Zlshen的观点 可以使用智能关键字！当需要连接星型维时，把 Smart Key当作代理键即可；当可以不连维表实现查询时， 则当作有意义的键。