现状
针对大数据Hadoop体系中，Hive作为数据仓库工具;但是对于大数据中数据仓库上构建数据模型的方法和传统的关系数据库的方法
是否还是可以使用。
世间万物不会孤立的存在，它们以各种关系进行联系;构建的数据模型如何体现这些关系。
从目前各大厂商(IBM,微软)的数据仓库构建方法中，还是保留原来关系型数据仓库(传统的数据仓库)的模式，
在Hive中构建各表及其间的关系;尽管在Hive中并不是只存储了结构化的数据，并没有强制的约束要求。
所以各种数据模型，是否适合在Hive上构建，要根据业务模型，数据量等因素，
但是Data Vault模型是较为适合当前大数据体系上构建(在<<数据构架,大数据,数据仓库及Data vault>>有相关论述)
本文说明3种常见的数据模型，并在后续种针对3种模型构建MS NorthWind数据库的相关的数据仓库。
相关的概念
| 概念 | 说明 |
|---|---|
| ODS，是Operational Data Store | 一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求 |
| ETL | 数据抽取、转换、装载，ETL是建立数据仓库最重要的处理过程，也是最体现工作量的环节 |
| 变化数据捕获技术 | 捕获数据变化的机制 |
| CDC 变化数据捕获 | 常用的变化数据捕获方法有时间戳、快照、触发器和日志四种(关系型数据库) 。对应维度模型种的渐变维度 |
| 数据仓库 | 是一个面向主题的、集成的、随时间变化的、非易失的数据集合，用于支持管理者的决策过程 |
| 数据集市 | 数据集市是按主题域组织的数据集合，用于支持部门级的决策，两种类型的数据集市：独立数据集市和从属数据集市 |
| 代理键 Surrogate key | 代理关键字一般是指维度表中使用顺序分配的整数值作为主键 |
3种数据仓库模型
3.1 关系数据模型(范式建模法)
| 概念 | 说明 |
|---|---|
| 超键 super key | 一个列或者列集，唯一标识表中的一条记录。超键可能包含用于唯一标识记录所不必要的额外的列 |
| 候选键 Alternate Key | 仅包含唯一标识记录所必需的最小数量列的超键 |
| 主键 Primary Key | 唯一标识表中记录的候选键。主键是唯一、非空的 |
| 外键 Froeign Key | 一个表中的一个列或多个列的集合，这些列匹配某些其他表中的候选键。注意外键所引用的不一定是主键，但一定是候选键 |
关系：数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。
所以在数据库中，通过表间的关系作为现实中的实体关系的映射。通过表间的关系，也是构造出数据模型的基础，这样才能表达出丰富的业务关系。
对于构造关系数据模型，遵循3各最基本的范式：
| 范式 | 说明 |
|---|---|
| 1NF | 表中的列只能含有原子性（不可再分）的值;每个属性值唯一，不具有多义性 |
| 2NF | 满足第一范式,没有部分依赖;每个非主属性必须完全依赖于整个主键，而非主键的一部分 |
| 3NF | 满足第二范式,没有传递依赖;每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去 |
对于关系数据模型：
从关系型数据库的角度出发，结合了业务系统的数据模型，能够比较方便的实现数据仓库的建模 ;
但是建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，
特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求
3.2 维度建模法
按照事实表，维表来构建数据仓库，数据集市。这种方法的最被人广泛知晓的名字就是星型模式（Star-schema）
| 概念 | 说明 |
|---|---|
| 事实表 | 事实表记录了特定事件的数字化的考量，一般由数字值和指向维度表的外键组成 |
| 维度表 | 维度表的记录数通常比事实表少，但每条记录包含有大量用于描述事实数据的属性字段 |
| 星型模式 | 一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表 |
| 雪花模式 | 与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓的“雪花化”就是将星型模式中的维度表进行规范化处理 |
优点：对于维度建模，针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。
通过这些预处理，能够极大的提升数据仓库的处理能力
维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。
缺点： 由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。
而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
3.3 Data Vault 模型
Data Vault方法需要跟踪所有数据的来源，因此其中每个数据行都要包含数据来源和装载时间属性，用以审计和跟踪数据值所对应的源系统。
Data Vault不区分数据在业务层面的正确与错误，它保留操作型系统的所有时间的所有数据，装载数据时不做数据验证、清洗等工作，这点明显有别于其他数据仓库建模方法
| 概念 | 说明 |
|---|---|
| 中心表 | 中心表用来保存一个组织内的每个实体的业务主键，业务主键唯一标识某个业务实体，中心表和源系统表是相互独立的 |
| 链接表 | 链接表是中心表之间的链接。一个链接表意味着两个或多个中心表之间有关联。一个链接表通常是一个外键，它代表着一种业务关系 |
| 附属表 | 附属表用来保存中心表和链接表的属性，包括所有的历史变化数据。一个附属表总有一个且唯一一个外键引用到中心表或链接表 |
具备的优点：
- 所有数据都基于时间来存储，即使数据是低质量的，也不能在ETL过程中处理掉。
- 依赖越少越好。
- 和源系统越独立越好。
- 设计上适合变化。
- 源系统中数据的变化。
- 在不改变模型的情况下可扩展。
- ETL作业可以重复执行。
- 数据完全可追踪。
总结
各种的数据模型中，映射现实实体及其关系，都使用了表及其表间的关系 ; Data Vault模式是较为适合大数据的数据模型,首先在Hive上建立Data Vault,然后再在Data Vault上
建立数据仓库或数据集市。
接下来要进行对NorthWind进行上述模型的实验尝试。
对于NorthWind的E-R关系图如下，相关的Github地址 https://github.com/Shadow-Hunter-X/hive_datawarehouse_mode_practice
