数据仓库EDW层数据整合集成的思考
比尔*门恩（Bill Inmon）给出了数据仓库这样一个定义，数据仓库是在企业管理和决策中面向主题的、集成的、与时间相关的、不可修改的数据集合。今天单就数据仓库的集成整合特性进行思考，我想数据仓库的集成性大致主要体现在如下几个方面。
1、将企业相关IT系统经过面向主题的处理，本身就是一种集成
1.1、不同系统、不同业务逻辑的相关数据在各主题的统一
1.2、不同系统、相似业务逻辑的相关数据在同一主题内或主题之间的数据整合
2、统一的命名规范
2.1、表名、字段名、存储过程名以及用户名的统一规划命名
如：表名或字段名统一使用英文大写字母和固定的字段英文简称，如“LOAN_CONTRACT_NO”表示贷款合同编号；表名相同主题下具有相同的前缀；每一字段和表都要求有必要的注释等。
2.2、代码字段、标志字段统一添加后缀处理
如：为与其他键及属性字段区分，代码字段、标志字段统一添加“_CD”、“_FLAG”后缀。
2.3、相同字段在不同仓库表里统一用同一个列名及相应的注释
3、相同及相似字段的Domain处理
3.1、对于相同字段在不同数据仓库表里，其字段类型用Domain统一处理
3.2、对于有需要的可以处理为同一字段类型的不同字段，也使用Domain统一处理
4、公共代码及代码值的统一
4.1、公共代码及标志性字段，其字段数据类型、命名方式等的统一
4.2、公共代码及标志字段，相对于源系统其代码值的统一
如：标志可用“0”表示“否”，“1”表示“是”；对于来源于不同业务系统的具有相同业务含义的公共代码，其代码值需要进行统一，对外代表的是数据仓库的统一标准代码（当然，数据仓库的标准代码可能跟某一源系统的代码相同，其他系统的代码值经业务分析后向那一个源系统靠近和统一）。
对于代码值的整合，如果不想太费劲分析，那么就用“源系统编号||源系统代码值”生成数据仓库的代码值，这应该叫做公共代码值的轻度整合。
5、业务含义相同，表结构有相同含义字段的表的整合
根据整合的程度或项目的实际需要，通常有如下整合方式：
5.1、采用主从表的设计方式，两表或多表都有的字段放在主表中（主要基本信息），从属修改信息分别放在各自的从表中
对于主表中的主键，要么采用复合主键，源主键和系统或表区别标志；要么采用唯一主键，“源主键||系统或表区别标志”生成新的主键。通常建议采用复合主键的方式。
5.2、进行两表的直接合并，共有信息和个性信息都放在一个表中
采用此种直接合并的方式，会出现大量空值，不利于系统存储和性能的提升；如果表字段的重合度在80%以下，不建议采用此方式。
5.3、虽然有相同的业务逻辑，但两源表的表结构及主键等却大相径庭
这种情况已经没有办法合并，所以索性就不合并，使用两个数据仓库里的表存放各自数据；不合并不代表不整合，其集成整合特性在其他方面依然有体现。
6、各主题内总分模式表间关系
主要主题内都会有一个总表统筹主题内各表，他是该主题内的精神核心（有时此表在模型中有，但并不物理化，所以称之为精神核心）。当然并非所有主题都具体这种总分架构，对于主要主题是都存在着的。
7、各主题间关联关系
各个主题间的连接关系通过主题间关系表进行关联。这些关系表，通常来源于源业务系统已经存在着的表间关系，并非数据仓库制造。
8、相关联表的相似属性集中存储
相关联的表的相似属性集中在同一张表中存储，这样一是便于查找，再是使存储效率更好；此种情况还较多的用于进行历史拉链数据存储的情况。
如：协议状态历史，会存储贷款合同、贷款借据、授信合同等协议类型的状态相应属性值；为了数据存储效率高效，采用历史拉链表记录协议记录的全景信息，节省了空间且提高了数据的取数效率。
9、其他的一些处理
数据仓库最大的整合就是根据源系统的业务进行分析，在数据仓库中重新组织和存储数据。如，删除无用无效的列字段、过滤无意义的表或记录、数据关联代码转换、数据类型转换、源系统不同表进行组合与关联存储等。
数据仓库巨量数据产生，通常来自于两方面的原因：一是集成了企业内各业务系统，各系统数据的累加；二是存储了大量的时间序列流水数据。所以在仓库数据架构最优化的同时，我们在数据仓库处理的时候就必须进行有效的筛选和清洗，防止无用数据占用大量存储空间。
