数据建模-关系模型、维度模型

数据仓库接典型的两种数据仓库建模的理论是维度建模和基于主题域的实体关系建模，这两种方式分别以Kimball和Immon两位大师为代表。

Kimball：维度建模以数据分析需求为驱动，倡导总线架构：一致的事实和一致的维度，这种数据模型易于用户理解和数据分析操作。

Immon：基于主题域的实体关系建模以源系统数据为驱动，整合企业的所有数据，站在企业级的高度对数据进行抽象，整合，采用3NF的实体关系理论建模，这种数据建模方式以更为抽象的方式尝试建立一个相对稳定的数据模型，并能描述企业级的数据关系。

优劣
1. 对于涉及多表连接以及聚合计算的查询请求，关系模型不如维度模型查询效率高
2. 维度模型更适合作为分析型应用（OLAP、BI）的基础——易用，易理解，查询效率高
3. 关系模型更适于频繁update、insert的应用（事务型应用）

在实践中往往把两种方式结合起来运用数据仓库的不同数据层次结构中。

针对采用基于主题域的实体关系建模中数据整合的方式三种思路：

以属性聚集的方式同一主题域中不同实体的属性。比如对于会员、公司、客户等等实体对象我们都有地址属性信息、名称标识属性信息等等，这种思路就是把属性内聚性高的字段整合在一起，并把不同的属性打上类型标识以树表的形式存放。

它的优点是：
第一，模型稳定性好，外围系统变化了字段，只需要添加不同的类型，不需要进行表结构的变更；
第二，减少大量冗余记历史数据。它的缺点是：第一，丢失了很多实体的属性标识信息，我们从模型上将看不到一个会员究竟有哪些地址属性，只能通过查询类型代码才能获取这些信息；它极度的膨胀数据表的记录数，因为它采用竖表的形式存放；
第三，应用起来很难，效率是一个大问题，因为我们往往要使用一个实体的多个字段，就会有很多join操作和竖转横的操作。
第四：属性聚集也是一件比较难操作的过程，应为这是一个抽象的过程，对建模人员的业务背景知识和抽象能力都提出了很高的要求；
第五：虽然减少了冗余的记历史数据，但是记历史的操作也较为复杂。

采用面向对象建模的方式，抽象不同实体的共同属性，然后再一步步采用继承、组合等面向对象的思想具体化实体。他的优点是模型模型概念比较清晰，缺点也是模型相对不是很稳定，整合后的数据的后续应该也面临重新组合的问题。

贴源的建模方式：
采用基本保持源系统的方式进行建模，重点放在数据的标准化，一致化，和数据业务意义的梳理。这种做法和我们目前数据仓库的做法比较类似。它具有实施比较容易，快速实现，前台可以直接使用数据；缺点是整合度不高，模型不稳定。