数据仓库工作日记_记录(四)

前面介绍了需求分析前，物理情况的数据探查，本篇接着介绍关于逻辑探查的内容。

  初探

一般数据仓库的数据都来源于业务系统，而业务系统的数据库设计都属于oltp范畴的，设计思路一般也都是遵循数据库教材里面的三范式设计。知己知彼，百战不殆，所以我建议可以不要先去讨论数据仓库的需求，以自己的理解先去窥探一下业务系统。

我一般会关注几个方面：

一、各系统结构（前面已经提过了）

二、主系统结构

这个主系统一般就指交易系统了，如通信行业，金融行业等。在做这一步工作时，如果能拿到交易系统的数据库模型，那是再好不过的了。探查的内容主要有系统的设计思路（当然这一点还是需要一些经验的，做了多年以后，即使是做数据仓库的，也能把核心系统的结构猜个大概），主要是自己去猜一下设计者的想法，对解决问题很有帮助，具体一点说就是可以推断出系统里该有哪些表或数据，能够供自己使用。然后是按照自己的逻辑，可以基于业务流程或业务模块、业务部门等原则，给业务系统进行一个大致的分类，这会对后面数据仓库的主题设计有一定帮助。

上面是一些宏观的介绍，下面说几个微观的例子：第一个是字典表，到数据仓库中以后一般会转换成维表。比较典型的有机构信息表，产品信息表等，在前期最好摸清情况。一般在交易系统升级时，比如增加了一个信用卡级别内容，分1、2、3、4、5，但是很有可能升级不严谨，对这些数字没有建字典表也没有说明，交易系统的开发人员明白这是什么意思，写程序的时候可以判断，但当这些数据抽取到数据仓库中，如果没有对应的说明可就不好处理了，所以业务表、字典表，这些基本情况一定要摸清。

表的情况摸清了，可以捎带了解一下，哪些数据是人工录入的，即交易的时候，由客户或者业务人员操作录入的数据；哪些数据是通过交易系统的程序自动生成的，这样在数据仓库建设过程中，如果数据不能满足，可以很快的找到源头来支持。

三、逻辑关联

逻辑关联，主要是整理出各系统间的数据关系，直接点的例子，就是交易系统的客户号，如何能与信用卡系统的客户卡信息关联上。一般最大的隐患就是数据壁垒，即两个系统独立，无关联或部分相关，这种情况会影响数据仓库的ETL工作。