大数据----数据仓库设计基础(实列演示)

常见的数据仓库模型有：关系数据模型、多维数据模型、Data Vault模型。
关系模型、多维模型已经有很长的历史，而Data Vault模型相对比较新。

关系数据模型

关系模型被广泛应用于数据处理和数据存储，尤其是在数据库领域，现在主流的数据库管理系统几乎都是以关系数据模型为基础实现的。

关系数据模型中的结构

假设有一个大型公司在全国都有分公司，每个员工属于一个分公司，一个分公司有一个经理，分公司经理也是公司员工。
1．关系
由行和列构成的二维结构，对应关系数据库中的表，如示例中的分公司表和员工表。
**表的物理存储结构可以是堆文件、索引文件或哈希文件。**堆文件是一个无序的数据集合，索引文件中表数据的物理存储顺序和逻辑顺序保持一致，哈希文件也称为直接存取文件，是通过一个预先定义好的哈希函数确定数据的物理存储位置。

2．属性
由属性名称和类型名称构成的顺序对，对应关系数据库中表的列，，如地址（Variable Characters）是公司表的一个属性。
在关系数据模型中，我们把关系描述为表，表中的行对应不同的记录，表中的列对应不同的属性。

3．属性域
属性的取值范围。每一个属性都有一个预定义的值的范围。属性域是关系模型的一个重要特征，关系中的每个属性都与一个域相关。域描述了属性所有可能的值。
域的概念是很重要的，因为它允许我们定义属性可以具有的值的意义。

分公司编号和员工编号都是字符串，但显然具有不同的含义，换句话说，它们的属性域是不同的。

4．元组
关系中的一条记录，对应关系数据库中的一个表行。元组可以以任何顺序出现，而关系保持不变。

5．关系数据库
一系列规范化的表的集合。 这里的规范化可以理解为表结构的正确性。
“关系、属性、元组”和“表、列、行”。在这里它们的含义是相同的，只不过前者是关系数据模型的正式术语，而后者是常用的数据库术语。

6．关系表的属性
关系表有如下属性：
每个表都有唯一的名称。
一个表中每个列有不同的名字。
一个列的值来自于相同的属性域。
列是无序的。
行是无序的。

7．关系数据模型中的键
（1）超键
一个列或者列集，唯一标识表中的一条记录。

（2）候选键
仅包含唯一标识记录所必需的最小数量列的超键。表的候选键有三个属性：
唯一性：在每条记录中，候选键的值唯一标识该记录。
最小性：具有唯一性属性的超键的最小子集。
非空性：候选键的值不允许为空。
在例子中，分公司编号是候选键，如果每个分公司的邮编都不同，那么邮编也可以作为分公司表的候选键。一个表中允许有多个候选键。

（3）主键
唯一标识表中记录的候选键。主键是唯一、非空的。 没有被选做主键的候选键称为备用键。 对于例子中的分公司表，分公司编号是主键，邮编就是备用键，而员工表的主键是员工编号。
选择主键的原则：
主键要尽可能地小。
主键值不应该被改变。如果改变了主键的值，所有引用该主键的值都需要修改，否则引用就是无效的。
主键通常使用数字类型。数字类型的主键要比其他数据类型效率更高。
主键应该是没有业务含义的，它不应包含实际的业务信息。

（4）外键
一个表中的一个列或多个列的集合，这些列匹配某些其他（也可以是同一个）表中的候选键。注意外键所引用的不一定是主键，但一定是候选键。
分公司表的分公司编号是主键，在员工表里所属分公司是外键。同样，因为公司经理也是公司员工，所以它是引用员工表的外键。主键所在的表被称为父表，外键所在的表被称为子表。

关系完整性

关系数据模型有两个重要的完整性规则：实体完整性和参照完整性。
1．空值（NULL）
空值可以意味着未知，也可以意味着某个记录没有值，或者只是意味着该值还没有提供。空值是处理不完整数据或异常数据的一种方式。**空值与数字零或者空字符串不同，零和空字符串是值，但空值代表没有值。**Oracle的非、与、或逻辑运算真值表：



2．关系完整性规则
（1）实体完整性
**在一个基本表中，主键列的取值不能为空。**例如，分公司编号是分公司表的主键，在录入数据的时候，该列的值不能为空。
（2）参照完整性
如果表中存在外键，则外键值必须与主表中的某些记录的候选键值相同，或者外键的值必须全部为空。
员工表中的所属分公司是外键。该列的值要么是分公司表的分公司编号列中的值，要么是空（如新员工已经加入了公司，但还没有被分派到某个具体的分公司时）。

3．业务规则
定义或约束组织的某些方面的规则。

4．关系数据库语言
关系语言定义了允许对数据进行的操作，包括从数据库中更新或检索数据所用的操作以及改变数据库对象结构的操作。关系数据库的主要语言是SQL语言。
SQL是Structured Query Language的缩写，意为结构化查询语言。SQL语言又可分为DDL、DML、DCL、TCL四类。

DDL是Data Definition Language的缩写，意为数据定义语言，用于定义数据库结构和模式。典型的DDL有create、alter、drop、truncate、comment、rename等。

DML是Data Manipulation Language的缩写，意为数据操纵语言，用于检索、管理和维护数据库对象。典型的DML有select、insert、update、delete、merge、call、explain、lock等。

DCL是Data Control Language的缩写，意为数据控制语言，用于授予和回收数据库对象上的权限。典型的DCL有grant和revoke。

TCL是Transaction Control Language的缩写，意为事务控制语言，用于管理DML对数据的改变。它允许一组DML语句联合成一个逻辑事务。典型的TCL有commit、rollback、savepoint、set transaction等。

规范化

规范化方法对表进行分解，以消除数据冗余，避免异常更新，提高数据完整性。

不规范化带来的问题
没有规范化，数据的更新处理将变得困难，异常的插入、修改、删除数据的操作会频繁发生。

假设有一个名为employee的员工表，它有九个属性：id（员工编号）、name（员工姓名），mobile（电话）、zip（邮编）、province（省份）、city（城市）、district（区县）、deptNo（所属部门编号）、deptName（所属部门名称），表中的数据如表所示：

由于此员工表是非规范化的，我们将面对如下的问题。

修改异常： 上表中张三有两条记录，因为他隶属两个部门。如果我们要修改张三的地址，必须修改两行记录。假如一个部门得到了张三的新地址并进行了更新，而另一个部门没有，那么此时张三在表中会存在两个不同的地址，导致了数据不一致。
新增异常： 假如一个新员工加入公司，他正处于入职培训阶段，还没有被正式分配到某个部门，如果deptNo字段不允许为空，我们就无法向employee表中新增该员工的数据。
删除异常： 假设公司撤销了D3这个部门，那么在删除deptNo为D3的行时，会将李四的信息也一并删除。因为他只隶属于D3这一个部门。

规范化是通过应用范式规则实现的。最常用的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。

（1）第一范式（1NF）
表中的列只能含有原子性（不可再分）的值。
上例中张三有两个手机号存储在mobile列中，违反了1NF规则。为了使表满足1NF，数据应该修改为如表所示。

（2）第二范式（2NF）
第二范式要同时满足下面两个条件：
满足第一范式。
没有部分依赖。
例如，员工表的一个候选键是{id，mobile，deptNo}，而deptName依赖于{deptNo}，同样name仅依赖于{id}，因此不是2NF的。为了满足第二范式的条件，需要将这个表拆分成employee、dept、employee_dept、employee_mobile四个表。
员工表

部门表

员工-部门表

员工-电话表

（3）第三范式（3NF）
第三范式要同时满足下面两个条件：
满足第二范式。
没有传递依赖。
例如，员工表的province、city、district依赖于zip，而zip依赖于{id}，换句话说，province、city、district传递依赖于{id}，违反了3NF规则。为了满足第三范式的条件，可以将这个表拆分成employee和zip两个表。
员工表

地区表

在关系数据模型设计中，一般需要满足第三范式的要求。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。
同时也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。而如果连接的表过多，会影响查询的性能。

关系数据模型与数据仓库

关系数据模型可以提供高性能的数据更新操作，能很好地满足事务型系统的需求，但是对于查询与分析密集型的数据仓库系统还是否合适呢？ Inmon阵营是应用关系数据模型构建数据仓库的支持者。
Inmon方法是以下面这些假设的成立为前提的。
必须尽可能快地把新数据装载进数据仓库，需要简化数据装载过程或减少数据的装载量。
数据仓库的建立必须从一开始就被设计成支持多种BI技术，这就要求数据仓库本身所使用的技术越通用越好。
假设数据仓库的需求一定会发生变化。它必须能完美地适应其数据和数据结构的变化。

使用关系数据模型构建数据仓库的优势和必然性：
1．非冗余性
为适应数据仓库有限的装载周期和海量数据，数据仓库数据模型应该包含最少量的数据冗余。

2．稳定性
由于数据仓库的需求会不断变化，我们需要以一种迭代的方式建立数据仓库。

3．一致性
数据仓库模型最本质的特点是保证作为组织最重要资源的数据的一致性，而确保数据一致性正是关系数据模型的特点之一。

4．灵活性
应用其规范化规则，将产生一个稳定的、一致的数据模型。该模型支持由组织制定的政策和约定的规则，同时为数据集市分析数据提供了更多的灵活性，使得数据库存储以及数据装载方面也是最有效的。

关系数据模型的缺点也很明显，它需要额外建立数据集市的存储区，并增加相应的数据装载过程。

维度数据模型

维度数据模型简称维度模型，用于数据仓库设计。维度模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术， 是围绕性能和易理解性构建的。

事实和维度是两个维度模型中的核心概念。
事实表示对业务数据的度量，而维度是观察数据的角度。事实通常是数字类型的，可以进行聚合和计算。
维度通常是一组层次关系或描述信息，用来定义事实。
例如， 销售金额是一个事实，而销售时间、销售的产品、购买的顾客、商店等都是销售事实的维度。

维度数据模型建模过程

维度模型通常以一种被称为星型模式的方式构建。所谓星型模式，就是以一个事实表为中心，周围环绕着多个维度表。
还有一种模式叫做雪花模式，是对维度做进一步规范化后形成的。
一般使用下面的过程构建维度模型：1.选择业务流程、2.声明粒度、3.确认维度、4.确认事实
1．选择业务流程
确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础。例如，需要了解和分析一个零售店的销售情况，那么与该零售店销售相关的所有业务流程都是需要关注的。

2．声明粒度
声明维度模型的粒度。这里的粒度用于确定事实中表示的是什么，例如，一个零售店的顾客在购物小票上的一个购买条目。每个候选维度或事实必须与定义的粒度保持一致。在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用性的关键。

3．确认维度
确认模型的维度。维度的粒度必须和第二步所声明的粒度一致。维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。**维度表存储了某一维度的所有相关数据，**例如，日期维度应该包括年、季度、月、周、日等数据。

4．确认事实
确认事实。这一步识别数字化的度量，构成事实表的记录。它是和系统的业务用户密切相关的，因为用户正是通过对事实表的访问获取数据仓库存储的数据。

维度规范化

对维度的规范化（又叫雪花化），可以去除冗余属性，是对非规范化维度做的规范化处理。一个非规范化维度对应一个维度表，规范化后，一个维度会对应多个维度表，维度被严格地以子维度的形式连接在一起。

设计维度数据模型时，会因为如下原因而不对维度做规范化处理：
规范化会增加表的数量，使结构更复杂。
不可避免的多表连接，使查询更复杂。
不适合使用位图索引。
查询性能原因。分析型查询需要聚合计算或检索很多维度值，此时第三范式的数据库会遭遇性能问题。如果需要的仅仅是操作型报表，可以使用第三范式，因为操作型系统的用户需要看到更细节的数据。

维度数据模型的特点

(1）易理解。相对于规范化的关系模型，维度模型容易理解且更直观。在维度模型中，信息按业务种类或维度进行分组，这会提高信息的可读性，也方便了对于数据含义的解释。

**（2）高性能。**维度模型更倾向于非规范化，因为这样可以优化查询的性能。
如图所示，左边是一个销售订单的典型的规范化表示。订单（Order）实体描述有关订单整体的信息，订单明细（Order Line）实体描述有关订单项的信息，两个实体都包含描述其订单状态的信息。右边是一个订单状态维（Order Status Dimension），该维描述订单和订单明细中对应的状态编码值的唯一组合。它包括在规范化设计的订单和订单明细实体中都出现的属性。当销售订单事实行被装载时，参照在订单状态维中的适合的状态编码的组合设置它的外键。

（3）可扩展。 维度模型是可扩展的。由于维度模型允许数据冗余，因此当向一个维度表或事实表中添加字段时，不会像关系模型那样产生巨大的影响，带来的结果就是更容易容纳不可预料的新增数据。

星型模式

星型模式是维度模型最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支。
星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。

1．事实表
事实表记录了特定事件的数字化的考量，一般由数字值和指向维度表的外键组成。
事务事实表。记录特定事件的事实，如销售。
快照事实表。记录给定时间点的事实，如月底账户余额。
累积事实表。记录给定时间点的聚合事实，如当月的总的销售金额。

2．维度表
维度表的记录数通常比事实表少，但每条记录包含有大量用于描述事实数据的属性字段。维度表可以定义各种各样的特性，以下是几种最长用的维度表：
时间维度表。描述星型模式中记录的事件所发生的时间，具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合，需要记录数据的历史，因此每个数据仓库都需要一个时间维度表。
**地理维度表。**描述位置信息的数据，如国家、省份、城市、区县、邮编等。
**产品维度表。**描述产品及其属性。
**人员维度表。**描述人员相关的信息，如销售人员、市场人员、开发人员等。
**范围维度表。**描述分段数据的信息，如高级、中级、低级等。

3.优缺点
优点：简化查询、简化业务报表逻辑、获得查询性能、快速聚合、便于向立方体提供数据。
缺点：不能保证数据的完整性、对于分析需求来说不够灵活。

示例
假设有一个连锁店的销售数据仓库，记录销售相关的日期、商店和产品，其星型模式如图所示。

Fact_Sales是唯一的事实表，Dim_Date、Dim_Store和Dim_Product是三个维度表。每个维度表的Id字段是它们的主键。事实表的Date_Id、Store_Id、Product_Id三个字段构成了事实表的联合主键，同时这个三个字段也是外键，分别引用对应的三个维度表的主键。Units_Sold是事实表的唯一一个非主键列，代表销售量，是用于计算和分析的度量值。维度表的非主键列表示维度的附加属性。下面的查询可以回答2015年各个城市的手机销量是多少。

select s.city as city, sum(f.units_sold)
 from fact_sales f
 inner join dim_date d on (f.date_id = d.id)
 inner join dim_store s on (f.store_id = s.id)
 inner join dim_product p on (f.product_id = p.id)
 where d.year = 2015 and p.product_category = 'mobile'
 group by s.city;

雪花模式

事实上，星型模式是雪花模式的一个特例。

雪花模式也是由事实表和维度表所组成。所谓的**“雪花化”就是将星型模式中的维度表进行规范化处理**。将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。基数指的是一个字段中不同值的个数，如主键列具有唯一值，所以有最高的基数，而像性别这样的列基数就很低。
在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而事实表存在具有层次关系的多个父表。

1．数据规范化与存储

规范化的过程就是将维度表中重复的组分离成一个新表，以减少数据冗余的过程。
从存储空间的角度看，典型的情况是维度表比事实表小很多。这就使得雪花化的维度表相对于星型模式来说，在存储空间上的优势没那么明显了。

2.优缺点
优点：一些OLAP多维数据库建模工具专门为雪花模型进行了优化、规范化的维度性节省存储空间。

缺点：维度属性规范化增加了查询的连接操作和复杂度、并不确保数据完整性。

示例
图显示的是将上述星型模型规范化后的雪花模式。日期维度分解成季度、月、周、日期四个表。产品维度分解成产品分类、产品两个表。由商场维度分解出一个地区表。

下面的查询可以回答2015年各个城市的手机销量是多少。可以明显看到此查询比星型模式的查询有更多的表连接。

select g.city,sum(f.units_sold) fromfact_sales f 
inner join dim_date d on f.date_id = d.id
inner join dim_store s on f.store_id = s.id
inner join dim_geography g on s.geography_id = g.id
inner join dim_product p on f.product_id = p.id
inner join dim_product_category c on p.product_category_id = c.id
where d.year= 2015 and c.product_category = 'mobile'
group by g.city;

Data Vault模型

Data Vault是一种数据仓库建模方法，用来存储来自多个操作型系统的完整的历史数据。Data Vault方法需要跟踪所有数据的来源，它保留操作型系统的所有时间的所有数据，装载数据时不做数据验证、清洗等工作。Data Vault建模方法显式地将结构信息和属性信息分离，允许并行数据装载，不需要重新设计就可以实现扩展。

Data Vault模型

Data Vault是面向细节的，可追踪历史的，一组有连接关系的规范化的表的集合。是一种综合了第三范式（3NF）和星型模型优点的建模方法。

Data Vault模型的组成部分

Data Vault模型有中心表（Hub）、链接表（Link）、附属表（Satellite）三个主要组成部分。中心表记录业务主键，链接表记录业务关系，附属表记录业务描述。

1．中心表

中心表用来保存一个组织内的每个实体的业务主键，业务主键唯一标识某个业务实体。中心表和源系统表是相互独立的。当一个业务主键被用在多个系统时，它在Data Vault中也只保留一份，其他的组件都链接到这一个业务主键上。

2．链接表

链接表是中心表之间的链接。一个链接表意味着两个或多个中心表之间有关联。一个链接表通常是一个外键，它代表着一种业务关系。

在Data Vault里，每个关系都以多对多方式关联，这给模型带来了很大的灵活性。无论数据在源系统中是什么关系，都可以保存在Data Vault模型中。

3．附属表

附属表用来保存中心表和链接表的属性，包括所有的历史变化数据。一个附属表总有一个且唯一一个外键引用到中心表或链接表。
在Data Vault模型的标准定义里，附属表的主键应该是附属表里参照到中心表或链接表的外键字段和装载时间字段的组合。尽管这个定义是正确的，但从技术角度考虑，我们最好还是增加一个代理键。使用只有一列的代理键更易维护。另外，对外键列和装载时间列联合建立唯一索引，也是一个好习惯。

Data Vault模型的特点

所有数据都基于时间来存储，即使数据是低质量的，也不能在ETL过程中处理掉；
依赖越少越好；
和源系统越独立越好；
设计上适合变化；
源系统中数据的变化；
在不改变模型的情况下可扩展；
ETL作业可以重复执行；
数据完全可追踪。

Data Vault模型的构建

在Data Vault模型中，各个实体有着严格、通用的定义与准确、灵活的功能描述，这不但使得Data Vault模型能够最直观、最一般地反映数据之间内含的业务规则，同时也为构建Data Vault模型提供了一致而普遍的方法。Data Vault模型的建立可以遵循如下步骤：

1．设计中心表

首先要确定企业数据仓库要涵盖的业务范围；其次要将业务范围划分为若干原子业务实体，比如客户、产品等；然后，从各个业务实体中抽象出能够唯一标识该实体的业务主键，该业务主键要在整个业务的生命周期内不会发生变化；最后，由该业务主键生成中心表。

2．设计链接表

链接表体现了中心表之间的业务关联。
首先要熟悉各个中心表代表的业务实体之间的业务关系，可能是两个或者多个中心表之间的关系。根据业务需求，这种关系可以是1对1、1对多，或者多对多的。
然后，从相互之间有业务关系的中心表中，提取出代表各自业务实体的中心表主键，这些主键将被加入到链接表中，组合构成该链接表的主键。同样出于技术的原因，需要增加代理键。
在生成链接表的同时，要注意如果中心表之间有业务交易数据的话，就需要在链接表中保存交易数据，有两种方法，一是采用加权链接表，二是给链接表加上附属表来处理交易数据。

3．设计附属表

附属表包含了各个业务实体与业务关联的详细的上下文描述信息。
首先要收集各个业务实体在提取业务主键后的其他信息，比如客户住址、产品价格等；由于同一业务实体的各个描述信息不具有稳定性，会经常发生变化，所以，在必要的时候，需要将变化频率不同的信息分隔开来，为一个中心表建立几个附属表。
然后提取出该中心表的主键，作为描述该中心表的附属表的主键。
当业务实体之间存在交易数据的时候，需要为没有加权的链接表设计附属表，也可以根据交易数据的不同变化情况设计多个附属表。

4．设计必要的PIT表

Point—In—Time表是由附属表派生而来的。如果一个中心表或者链接表设计有多个附属表的话，而为了访问数据方便，就有用到PIT表的可能。
PIT表的主键也是由其所归属的中心表提取而来，该中心表有几个附属表，PIT表就至少应该有几个字段来存放各个附属表的变化对比时间。

建立Data Vault模型的原则

（1）关于中心表的原则
中心表的主键不能够直接“伸入”到其他中心表里面。就是说，不存在父子关系的中心表。各个中心表之间的关系是平等的，这也正是Data Vault模型灵活性与扩展性之所在。
中心表之间必须通过链接表相关联，通过链接表可以连接两个以上的中心表。
必须至少有两个中心表才能产生一个有意义的链接表。
中心表的主键总是“伸出去”的（到链接表或者附属表）。

（2）关于链接表的原则
链接表可以跟其他链接表相连。
中心表和链接表都可以使用代理键。
业务主键从来不会改变，就是说中心表的主键也即链接表的外键不会改变。

（3）关于附属表的原则
附属表必须是连接到中心表或者链接表上才会有确定的含义。
附属表总是包含装载时间和失效时间，从而包含历史数据，并且没有重复的数据。
由于数据信息的类型或者变化频率快慢的差别，描述信息的数据可能会被分隔到多个附属表中去。

Data Vault模型实例

下面用一个销售订单的例子说明如何将关系模型转换为Data Vault模型，以及如何向转换后的Data Vault模型装载数据。关系模型如图所示，共有省、市、客户、产品类型、产品、订单、订单明细7个表。

1．将关系模型转换为Data Vault模型

按照下面的步骤转换中心表。
**（1）确定中心实体。**示例中的客户、产品类型、产品、订单、订单明细这5个实体是订单销售业务的中心实体。省、市等地理信息表是参考数据，不能算是中心实体，实际上是附属表。
（2）把第一步确定的中心实体中有入边的实体转换为中心表，因为这些实体被别的实体引用。把客户、产品类型、产品、订单转换成中心表。
**（3）把第一步确定的中心实体中没有入边且只有一条出边的实体转换为中心表。**该示例中没有这样的表。
如表所示列出了所有中心表。

**每个中心表只有代理键、业务主键、装载时间、数据来源四个字段。**在这个示例中，业务主键就是关系模型中表的主键字段。
然后按照下面的步骤转换链接表。
**（1）把示例中没有入边且有两条或两条以上出边的实体直接转换成链接表。**符合条件的是订单明细表。
**（2）把示例中除第一步以外的外键关系转换成链接表。**订单和客户之间建立链接表，产品和产品类型之间建立链接表。注意Data Vault模型中的每个关系都是多对多关系。
如表2-17所示列出了所有链接表。

链接表中包含有代理键、关联的中心表的一个或多个主键、装载时间、数据来源等字段。

最后转换附属表。附属表为中心表和链接表补充属性。所有源库中用到的表的非键属性都要放到Data Vault模型的附属表中。
如表所示列出了所有附属表：

附属表中包含有代理键、关联的中心表或链接表的主键、装载时间、失效时间、数据来源、关联的中心表或链接表所对应的关系模型表中的一个或多个非主键属性等字段。
转换后的Data Vault模型如图所示。

2．向Data Vault模型的表中装载数据
现在Data Vault模型的中心表、链接表、附属表都已经建立好，需要向其中装载数据，数据的来源是关系模型中的表。
假设Data Vault的表使用MySQL数据库建立，代理键使用自增列，装载时间使用时间戳数据类型，在插入数据时，这两列不用显式赋值，数据会自动维护。数据来源字段简单处理，就填写与之相关的表名。附属表的失效时间字段，初始值填写一个很大的默认时间，这里插入‘2200-01-01’。

使用以下的SQL代码装载hub_product中心表、link_order_product链接表、sat_order_product附属表，其他表的装载语句类似，这里从略。
– 装载hub_product中心表

insert into hub_product (product_id,record_source)
select product_id,'product' from product;

– 装载link_order_product链接表

insert into link_order_product(
                  hub_sales_order_id,
                  hub_product_id,
                  record_source)
select hub_sales_order_id,hub_product_id,'hub_sales_order,hub_product,sales_order_item'
from
hub_sales_order t1,
hub_product t2,
sales_order_item t3
where t1.sales_order_id = t3.sales_order_id and t2.product_id = t3.product_id;

– 装载sat_order_product附属表

insert into sat_order_product (
                  link_order_product_id,
                  load_end_dts,
                  record_source,
                  unit_price,
                  quantity)
select
link_order_product_id,
'2200-01-01',
'link_order_product,hub_sales_order,hub_product,sales_order_item',
t4.unit_price,
t4.quantity
from
link_order_product t1,
hub_sales_order t2,
hub_product t3,
sales_order_item t4
where t1.hub_sales_order_id = t2.hub_sales_order_id
and t1.hub_product_id = t3.hub_product_id
and t4.sales_order_id = t2.sales_order_id
and t4.product_id = t3.product_id;

数据集市

数据集市的概念

数据集市是数据仓库的一种简单形式，通常由组织内的业务部门自己建立和控制。

数据集市与数据仓库的区别

数据仓库处理整个组织范围内的多个主题域,需要集成很多操作型源系统中的数据。
数据集市面向单一主题域。由于数据集市的复杂度和需要处理的数据都小于数据仓库，因此更容易建立与维护。

数据集市设计

数据集市主要用于部门级别的分析型应用，数据大都是经过了汇总和聚合操作，粒度级别较高。数据集市一般采用维度模型设计方法，数据结构使用星型模式或雪花模式。

数据仓库实施步骤

实施一个数据仓库项目的主要步骤是：定义项目范围、收集并确认业务需求和技术需求、逻辑设计、物理设计、从源系统向数据仓库装载数据、使数据可以被访问以辅助决策、管理和维护数据仓库。

小结

（1）关系模型、多维模型和Data Vault模型是三种常见的数据仓库模型。
（2）数据结构、完整性约束和SQL语言是关系模型的三个要素。
（3）规范化是通过应用范式规则实现的。第一范式（1NF）要求保持数据的原子性、第二范式（2NF）消除了部分依赖、第三范式（3NF）消除了传递依赖。关系模型的数据仓库一般要求满足3NF。
（4）事实、维度、粒度是维度模型的三个核心概念。
（5）维度模型的四步设计法是选择业务流程、声明粒度、确定维度、确定事实。
（6）星型模式和雪花模式是维度模型的两种逻辑表示。对星型模式进一步规范化，就形成了雪花模式。
（7）Data Vault模型有中心表（Hub）、链接表（Link）、附属表（Satellite）三个主要组成部分。中心表记录业务主键，链接表记录业务关系，附属表记录业务描述。
（8）Data Vault不区分数据在业务层面的正确与错误，它保留操作型系统的所有时间的所有数据，装载数据时不做数据验证、清洗等工作。
（9）数据集市是部门级的、面向单一主题域的数据仓库。
（10）数据集市的复杂度和需要处理的数据都小于数据仓库，因此更容易建立与维护。
（11）实施一个数据仓库项目的主要步骤是：定义范围、确认需求、逻辑设计、物理设计、装载数据、访问数据、管理维护。