1. 序
在数据集成类的项目中，最难的过程就是数据分析了，数据分析过程位于数据集成类项目整个过程(前期准备调研-----数据分析-----接口实现)的第二步，它为第三步接口实现提供了充分的准备，因此数据分析的正确与否很大程度上决定了数据集成能否成功的实现和完成。
怎么样有效的进行数据分析呢，怎么样提前在数据分析中尽量避免问题等到实现时才出现呢？这是一个行之有效的数据分析方法论的评判的关键。
经过几个项目的经历，反思了一下在做这些项目时比较有效的方法和失妥的方法，总结了一套目前个人觉得可行的数据分析方法，此套数据分析方法只适用于数据库---文件---数据库或数据库---数据库的分析，对于接口式的集成(例如调用对方的webservice、EJB接口等)并不适用，在这样的一套数据分析的方法中，为数据分析的步骤以及需要注意的问题事项提出了指导，编写此blog以希望有同行的同学们多多交流。
2. 数据分析方法论
此方法论中涉及的名词的解释：
l 目标数据源
指在数据集成中需要导入数据的数据源，此数据源可能是数据库，也有可能是文件。
l 源数据源
指在数据集成中获取数据的数据源，此数据源可能是数据库，也有可能是文件。
l 字典代码
在数据库中以代码的方式(如数字、英文字母等)来代替中文意思进行存储，其中的这些代码就称为字典代码。
2.1. 步骤
2.1.1. 分析目标数据源的数据结构
目标数据源既有可能是数据库也有可能是文件，但无论是哪种，它都是有数据结构的，首先要做的就是分析目标数据源的数据结构，在分析目标数据源的数据结构时，要分析清楚的有：
l 表
目标数据源中需要交换的有哪些表，这些表的含义分别是什么。
l 字段
这些表中包含的字段、字段的类型以及长度。
l 字段含义
分析每个字段的含义，包括字段的中文含义、字段涉及到的字典代码以及字段的规则(如业务规则、生成规则)。
在分析了上面所提及的表、字段、字段含义后，形成如下结构的文档：
表名
|
字段
|
字段类型及长度
|
中文含义
|
涉及到的字典代码
|
字段规则
|
|
id
|
number(10)
|
主键流水号
|
--
|
流水号，通过表名_SEQ的Sequence来获取
|
|
unitcode
|
varchar2(19)
|
单位编码
|
单位编码字典
|
--
|
2.1.2. 分析目标数据源的表关系
在完成了第一步后，需要接着分析目标数据源的表关系，分析表关系最重要的在于分析各个表之间的关联关系(例如一对一、一对多，通过这里可以分析出的为主键、外键的关联关系)，其次就是需要根据业务来分析其各个表之间的隐性关联，如只有当A表中的某个值为03时才关联到B表。
在分析完毕目标数据源的表关系后，形成如下Rose图：
2.1.3. 分析源数据源的数据结构
方法同2.1.1，分析的对象改变为源数据源，分析完毕后形成同2.1.1中的文档。
2.1.4. 分析源数据源的表关系
方法同2.1.2，分析的对象改变为源数据源，分析完毕后形成同2.1.2中的Rose图。
2.1.5. 根据目标数据源的表关系分析其和源数据源的表的对应关系
根据目标数据源的表关系，来分析其和源数据源表的对应关系，在这个步骤中需要分析清楚的是目标数据源的表的数据来源于源数据源的哪些表，怎么获取到这些数据，分析完毕后可形成校验数据集成是否正确的一个标准，那就是目标数据源的表的数据量和其来源的源数据源的那些表的数据量应该是一致的，分析时仍然是根据目标表的业务含义去源数据源中的表中寻找具备相同含义的表，在分析的过程中可能会碰到如下几种情况：
l 含义相同的表
这种情况通常是目标数据源和源数据源均为使用一张表存储，含义相同的表通常都是一对一的数据关系，例如目标数据源中有一张表为常住人口基本信息，源数据源中有张常住人员基本信息，两张表就可以对应上了，当然，有些时候并不一定是意义相同就一定相同，这需要从业务层面去判断。
l 具备包含意义的表
这种情况通常是目标数据源为一张表，源数据源为多张表，这个时候就形成多对一的关系，例如目标数据源中有张表为物品表，源数据源中为手机、证券等几张表，这个时候就需要将手机、证券这些表对应到物品表。
又或者可能会碰到这样的现象，目标数据源为一张表，源数据源也是一张表，但源数据源的这张表的每行记录包含了目标表的两种类型的记录，这种情况下就需要将源数据源的一行记录拆分为两条导入到目标表中，例如目标数据源有张表为迁入迁出表，其存储方式为迁入和迁出都为单独的记录来存储的，源数据源有张表也为迁入迁出表，但其存储方式为迁入和迁出在同一条记录，这个时候就要将源数据源的这张迁入迁出表的一行记录拆分为两条进行导入了。
l 被包含意义的表
和之上的具备包含意义的表相反。
l 根据业务的对应关系
这张是最为复杂的，例如可能会碰到这样的现象，当源数据源的某张表的某个字段的值为多个的时候，就需要拆分为两条记录导入到目标表中。
综合上面所述，目标数据源的表和源数据源的表可能会存在一对一、一对多、多对一、多对多、条件式的对应几种关系，在分析完毕后形成如下的文档：
|
目标数据源
|
源数据源
|
校验标准
|
|
A
|
A
|
A.数据量==A.数据量(变动(新增、编辑、删除)的数据)
|
|
B
|
B
C
|
B.数据量==B.数据量+C.数据量
|
|
C
D
|
D
|
C.数据量+D.数据量=D.数据量
C.数据量=D.数据量(D.wplx=’03’)
D.数据量=D.数据量(D.wplx=’05’)
|
|
E
|
E
|
E.数据量=E.数据量*2
|
|
F
|
F
|
F.数据量=F.数据量/2(F.qrsj=F.qcsj)
|
|
G
|
G
|
G.数据量=G.数据量+G.数据量(G.name包含的,的总数-1)
|
2.1.6. 根据表的对应关系分析字段的对应关系以及转化规则
在对应了表的对应关系后，根据表的单一对应关系(如目标数据源的B表对应到了源数据源的B、C表，则需要分为B对应B以及B对应C两个步骤来分析)来分析每个表中的字段的对应关系以及转化规则了，对应的方法为：
l 先在对应的表中寻找相应的字段
l 如寻找不到则到相关的表中寻找相应的字段
l 如还是寻找不到则需要从业务含义方面去推测
从业务含义角度分析此字段是否需要合并多个字段或拆分字段，又或根据某种业务规则来生成这个字段的值。
在寻找到了相应的字段后，首先根据类型、长度来分析是否需要进行类型和长度的处理，之后需要分析该字段是否为通过关联到其他表来获取的，接着再分析此字段是否涉及到字典代码，如涉及则需要对照两边的字典代码是否一致，如不一致则需要形成两边的字典代码的对应关系，最后分析该字段是否涉及业务含义，如涉及则需注明如何进行处理。
在分析完毕后，形成如下文档：
表名
|
字段
|
字段类型及长度
|
源数据源字段
|
字段类型及长度
|
转化规则
|
|
id
|
number(10)
|
表名.id
|
number(10)
|
|
|
unitcode
|
varchar2(19)
|
表名.xzqh+表名.unit
|
Varchar2(8)+varchar2(20)
|
单位代码字典映射
|
|
content
|
Varchar2(100)
|
Substr(表名.content,0,50)
|
Varchar2(100)
|
|
|
ifmonth
|
Varchar2(1)
|
If(表名.createdate.月份==’系统时间的月份’)
Return ‘1’;
Else
Return ‘2’.
|
|
|
|
unitname
|
Varchar2(100)
|
UnitNames.unitName
|
Varchar2(100)
|
表名.xzqh+表名.unit=UnitNames.UnitCode
|
2.2. 需注意的问题
由于数据集成涉及的为系统中最为重要的基础—数据，那么在做数据集成时就特别需要仔细考虑不要对数据产生了破坏性的影响，这也是数据分析过程中需要慎重考虑的问题。
2.2.1. 数据覆盖/混乱的问题
在做数据分析时需要考虑，这样集成数据后是否会将已存在的数据非法的覆盖或造出混乱，出现这种问题通常都是由于主键的原因，这个在做数据分析时需要考虑。
2.2.2. 制定错误出现时的弥补方案
在做数据分析时需要考虑在进行数据集成后可能会出现的错误，对于这些可能出现的错误需要制定相应的弥补方案，以避免数据的被破坏。
2.2.3. 源数据源数据质量造成的问题的处理方案
需要考虑如源数据源本身的数据质量出现问题时，应如何处理或者如何避免。
2.2.4. 业务专家的支持
在整个数据分析的过程中，可以看出业务专家起到了非常大的作用，可以说如果缺少业务专家的话，数据分析很可能会失败，或需要走很多的弯路才能最后摸索出来，有一点可以肯定，在缺少业务专家的支持下整个数据分析的过程将会大大的延长，从这点可以看出，在进行数据分析时要尽量获取到业务专家的支持。
3. 总结
如上的方法论对数据分析的过程和避免问题的方法做出了一定的描述，在实际的进行数据分析时，最重要的还是负责数据分析的人对于系统的理解，有过系统设计经验的人来做数据分析成功的几率会高很多，有些非常专业的系统的话还得依赖有相应的设计经验的人才做才能做得了，类如流程系统的数据集成。
在一个数据分析过程中，已经可以制定出判断数据集成是否成功的标准了，这也可以列为TDD的入口条件，J。
方法论始终都还是理论，我本来就不是一个那么讲理论的人，但也不否认理论对于实际是有很好的指导作用的，避免在实践过程中走过多的弯路，能做到理论结合实践那是最好的，理论指导实践，实践改进理论。