数据仓库-建模

 

 范式模型

        数仓之父 Inmon 所倡导的，从全企业的高度设计一个 3NF 模型，用实体关系（Entity Relationship）模型来描述企业业务，满足 3NF。这种模型实施周期非常长，一致性和扩展性比较好，能经得起时间的考验。但是随着企业数据的高速增长、复杂化，这个模型便因为复杂性和变化性无法很好的适应。该模型最典型的应用时基于金融业务发布的 FS-LDM (Financial Services Logical Data Model ），它通过对金融业务的高度抽象和总结，将金融业务划分为 10 大主题。

        设计步骤：

                -高层模型：考虑所有上层主题，主题之间的关系。

                -中层模型：细化上层主题数据项。

                -物理模型：在中层模型的基础上，考虑物理存储，同时基于性能和平台特点进行物理属性的设计，也可能做一些表的合并、分区的设计等。

维度模型

        Ralph Kimball 大师提出的，是现在数据仓库工程领域最流行的建模模型。其以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。

        设计步骤：

                -选择业务过程：需要进行分析决策的业务过程

                -定义粒度：粒度定义意味着对各事实表行实际代表的内容给出明确的说明。

                -选定维度：围绕业务过程如何得到的数据

                -确认事实：确定分析需要衡量的指标

DataVault 模型

       综合了范式建模和维度建模中的星型模型的优点。

                -继承了3NF的优点，可以从整体上描述企业的业务数据或信息结构，而且能够实现数据模型的动态架构。

                -Hub用于记录在业务应用中常用到的业务实体键值，与星型模型中的维度表非常相似，记录了业务实体的维度信息的键值，但其它描述信息记录在了Satellite组件中。

                -Link通过存储相关业务实体间Hub表的SK(Surrorgate Key)，以记录一对多、多对多的业务实体间关系，与星型模型中的事实表非常相似，只是没有度量数据。

                -Satellite用于Hub表中业务主键所对应的业务描述，即业务实体的属性信息设计，可以解决星型模型中多事实冗余的问题。

        此外还有一个Point-In-Time辅助表，用于同一Hub的多个Satellite组件间的时间同步。因为同一业务实体的不同类型属性的更新频率不同，因此同一Hub的多个Satellite组件基本不会同步更新，因此，只需要在PIT表中记录在同一时点同时有效的Satellite组件描述信息即可，以保证查询到的数据是查询时点的实体状态。通过PIT表中的记录，可以清晰的分析业务实体属性的变化频率及频率差异。

Anchor模型

        Anchor 对 Data Vault 模型做了进一步的规范化处理，它的核心思想是所有的扩展只是添加而不是修改，因此将模型规范到 6NF（过度规范化，使用中会有太多的 Join 操作），基本变成了 K-V 结构化模型。