关系模型、维度模型

[size=x-large]关系模型[/size]
[img]http://dl.iteye.com/upload/attachment/0067/4057/5551c5cf-7437-3cbe-84cf-cb822205921b.jpg[/img]
1. 以遵循第三范式（3NF）为基础的关系模型，从ER图的“观感”上来说，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强
2. 主要应用于事务型数据库
3. 在数据仓库领域的倡导者：Inmon。
4. 在Inmon的理念中（可见“参考3”链接），DW并不直接用于DSS/BI等应用，而是作为一个平台，其模型为3NF关系模型，对于更上层的应用，通过建立小的数据集市或其他方式（这时候可以用维度模型），来满足具体的应用要求——即数据仓库作为数据集市的数据源，数据集市来满足具体应用（如BI、DSS）的需求

[size=x-large]维度模型[/size]
[img]http://dl.iteye.com/upload/attachment/0067/4059/d1d15229-48df-32ae-9787-7603b4770c96.jpg[/img]
1. 尽管底层本质在物理实现上还是表和关系，但模型概念上有了一定的抽象，表分为维度表和事实表两种，事实表中以数字型为主，包含了度量信息，而维度表常以文本类型为主，常常被作为事实表的“上下文”，为那些度量数值添加了业务意义
2. 维度表与事实表常以星型模型、雪花模型、星座模型等形式进行组织。
3. 符合同一个主题的维度（事实表）数据，往往被统一整合（Conform）到一个维表（事实表）中，表的数量较之关系模型要少些
4. 维度模型具有更强的业务意义，每个表囊括了某主题的（几乎）全部信息
5. ETL的过程中，如果目标是维度模型，源是关系模型，往往涉及解范式过程（denormalize）
6. 维度模型并非没有关系，维表与事实表之间有关系，维表与维表之间也可能有关系（雪花模型）
7. 维度模型中的表通常都有数字类型的主键，并为之添加索引便于提升查询效率
8. 在数据仓库领域的倡导者：Kimball

[size=x-large]优劣[/size]
1. 对于涉及多表连接以及聚合计算的查询请求，关系模型不如维度模型查询效率高
2. 维度模型更适合作为分析型应用（OLAP、BI）的基础——易用，易理解，查询效率高
3. 关系模型更适于频繁update、insert的应用（事务型应用）
4. 在实时数据流上，普遍认为3NF比维度模型更具实时性处理的优势，因为前者更贴近OLTP数据源，涉及到的转换、聚合相对更少些（可见“参考4”链接）
5. 个人感觉，关系模型更面向“技术”层面，要满足3NF对表进行范式化，属于物理模型；而维度模型，其物理底层实际上还是表和关系，但从概念上有了进一步抽象，面向“业务”层面，尤其符合DW的主题特性。
在数据仓库领域对这二者模型的讨论，往往又牵涉到构建数据集市的方式，这就涉及Kimball vs Inmon的所谓“圣战”了。这方面没有定论，也不可能有定论。不管黑猫白猫，捉到老鼠就是好猫；不管关系还是维度，高效解决问题的就是好模型。参考4的连接中有人把这两种模型比作Ford和Chevy，也有比作高速公路和城市公路的，其实大可不必争论好坏，特有特色而已。另外，我不知道有多少把DW当做数据平台，上层再架其他数据平台，以DW为数据源来满足更上层需要的，添加一层尽管减少了耦合，让DW更为通用，但同时带来了更大的复杂度：DW->上层数据平台需要新的ETL过程；上层数据平台又要花费更多的开发代价；多了一层，实时的难度加大。