数据仓库模型几大类
数据仓库中有几种经典的数据模型：范式模型、维度模型、DataVault。
很多模型的设计都在同构化，而且在工作中也不是单独地用一种模型，会根据业务场景做出各种取舍。
一、范式模型
范式模型也叫ER模型、实体模型。
范式是数据库逻辑模型设计的基本理论，一个关系模型可以从第一范式到第五范式进行无损分解。
在数据库的模型设计中目前一般采用第三范式。一个符合第三范式的关系具有以下三个条件 :
- 数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值
- 数据库表中的每个实例或行必须可以被惟一地区分
- 数据库表中不包含已在其它表中已包含的非主关键字信息。
我们提到的范式模型由数据仓库之父 Inmon 提倡 ，可以大致地按照OLTP设计中的3NF来理解，它在范式理论上符合3NF，
它与OLTP系统中的3NF的区别在于数据仓库中的3NF上站在企业角度面向主题的抽象，而不是针对某个具体业务流程的实体对象关系抽象，它更多的是面向数据的整合和一致性治理。
二、维度模型
维度模型是数据仓库领域另一位大师 Ralph Kimball 所倡导，他的《The DataWarehouse Toolkit-The Complete Guide to Dimensona Modeling，中文名《数据仓库工具箱》，是数据仓库工程领域最流行的数仓建模经典。
按照书中所讲，维度建模并不要求维度模型必须满足第3范式。数据库中强调的 3NF 主要是为了消除冗余。规范化的 3NF 将数据划分为多个不同的实体，每个实体构成一个关系表。比如说订单数据库，开始可能是每个订单中的一行表示一条记录，到后来为了满足 3NF会变成蜘蛛网状图，也许会包含上百个规范化表。而且对于 BI 查询来讲，规范化模型太复杂，用户会难以理解和记录这些模型的使用。 而维度建模解决了模式过分复杂的问题。
维度模型的典型代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型和星座模型。维度模型里面有2个十分重要的概念：事实表和维度表。
事实表：
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。从最低的粒度级别来看，事实表行对应一个度量事件，反之亦然。
维度表：
每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。 维度表通常比较宽，是扁平型非规范表，包含大量的低粒度的文本属性。
感觉解释的不清楚？没关系，后面专门有文字来讨论维度建模。
三、Data Vault
Data Vault 是 Dan Linstedt 发起创建的一种模型方法论，现在应该叫做Data Vault 2.0了，它也是一套完整的数据仓库理论，其中也有专门的一部分关于数据模型设计。
个人理解 Data Vault 模型 应该说是范式模型和维度模型的一种混合，它兼容了两种模型的优势。
Data Vault 通常可以分为3种类型，中心体，链接体和附属体 它主要由：Hub（中心表）、Link（链接表）和 Satellite（卫星表） 三部分组成 。
中心表：
中心表主要是存储一些日常用的一些业务关键码，比如客户号，发票号，流水号等等。它包括三个要素：
- 代理键：这就是一些操作性的组件，包括客户号，发票号等等
- 装载时间戳：这里可以理解为ETL进行日加载的时间。
- 数据源：就是可以追索到的原系统，比如，CRM，ERP等
链接表：
是3NF的多对多关系的物理表现形式，它表现的是多个业务键之间的关系。它和范式模型的最大区别是将关系作为一个独立单元抽象出来，可以提升模型的扩展性。它主要包含以下特征:
- 代理键
- 代理键间的映射关系
- 装载时间戳：这里可以理解为ETL进行日加载的时间。
- 数据源：就是可以追索到的原系统，比如，CRM，ERP等
卫星表：
业务领域中的其余信息可能随着时间而变化，所以卫星表必须有能力存储新的或者变化的各种粒度的数据，他们将被存储在卫星表内。
卫星表是中心表的详细描述内容，一个中心表会有多个卫星表。它由中心表的代理键、装载时间、来源类型、详细的中心表描述信息等组成。
总结
目前市面上容易买到的数据仓库领域的经典书有三本：《数据仓库》、《数据仓库工具箱》和《数据架构 大数据 数据仓库以及Data Vault》，
这三本书分别对应了前面提到的三种数据模型，个人感觉书有点些枯燥，而且不太容易理解，不过做过一段数据仓库后再回头学习一下这些书还是会有很多收获的，参考价值很大。
关于数据模型，个人感觉在实际的场景中会有很多个性化的设计，有时候还不得不做一些反模式的设计。模型很重要，业务场景也很重要。