数据仓库主题建模点滴

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