数仓系列-数据建模方法
内容整理自:
数据模型的基本概念
数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系，分为以下几个层次:
通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程：
业务建模，生成业务模型，主要解决业务层面的分解和程序化。
领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。
逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。
物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题
范式建模
在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件 :
- 每个属性值唯一，不具有多义性 ;
- 每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
- 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去
维度建模
最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。如星型模式、雪花模型等
星型模型(Star-schema)
上图的这个架构中是典型的星型架构。星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余，如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余
特点
只有一个事实表，并且每一个维度有一个单独的表。
事实表中的每一个元组都是一个外键指向维度表的主键。
每一个维度表的列是组成这个维度的所有属性
事实表与维度表通过主键外键相关联，维度表之间没有关联，就像很多星星围绕在一个恒星周围，故取名为星形模型。
优点
星形模型是最简单， 也是最常用的模型。
由于星形模型只有一张大表， 因此它相比于其他模型更适合于大数据处理。
其他模型可以通过一定的转换， 变为星形模型
雪花模型(Snow Schema)
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起,故称雪花模型。
雪花模型是对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 “ 层次 “ 区域，这些被分解的表都连接到主维度表而不是事实表
如上图所示，将地域维表又分解为国家，省份，城市等维表。它的优点是 : 通过最大限度地减少数据存储量以及联合较小的维表来改善查询性能，去除了数据冗余。
数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来提升查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。
事实星座模型（Fact Constellation）
星座模型是更复杂的模型，其中包含了多个事实表，而维度表是公用的，可以共享多个事实表共享维表，这种模式可以看作星座模式集，因此称作星系模式(galaxy schema)，或者事实星座(fact constellation)
总结
维度建模法的优点:
维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模
维度建模法的缺点:
由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。
当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。
维度建模的领域主要适用于数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。