数据仓库与数仓建模
1.数据仓库的概念
数据仓库，英文名称为DataWarehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合。它出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。
2.数据仓库的特点
2.1 数据仓库的数据是面向主题的
- 与
传统数据库面向应用进行数据组织的特点相对应，数据仓库中的数据是面向主题进行组织的。 - 主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。
- 在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整、一致的描述，能完整、统一地刻划各个分析对象所涉及的企业的各项数据，以及数据之间的联系。
- 所谓较高层次是相对面向应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。
2.2 数据仓库的数据是集成的
数据仓库的数据是从原有的分散的数据库数据抽取来的。操作型数据(原始数据,一般来自于企业操作型系统)与DSS分析型数据(分析型数据/导出数据,是为了提高数据查询和管理效率,根据操作型数据计算得到的数据)之间差别甚大。
- 数据仓库的每一个主题所对应的源数据在原有的各分散数据库中有许多重复和不一致的地方，且来源于不同的联机系统的数据都和不同的应用逻辑捆绑在一起；
- 数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，所要完成的工作有：
（1）要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致，等等。
（2）进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
2.3 数据仓库的数据是不可更新的
- 数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。
- 数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。
- 数据库中进行联机处理的数据经过集成输入到数据仓库中，一旦数据仓库存放的数据已经超过数据仓库的数据存储期限，这些数据将从当前的数据仓库中删去。因为数据仓库只进行数据查询操作，所以数据仓库管理系统相比数据库管理系统而言要简单得多。
- 数据库管理系统中许多技术难点，如完整性保护、并发控制等等，在数据仓库的管理中几乎可以省去。但是由于数据仓库的查询数据量往往很大，所以就对数据查询提出了更高的要求，它要求采用各种复杂的索引技术；
- 同时由于数据仓库面向的是商业企业的高层管理者，他们会对数据查询的界面友好性和数据表示提出更高的要求。
2.4 数据仓库的数据是随时间不断变化的
数据仓库中的数据不可更新是针对应用来说的，也就是说，数据仓库的用户进行分析处理时是不进行数据更新操作的。但并不是说，在从数据集成输入数据仓库开始到最终被删除的整个数据生存周期中，所有的数据仓库数据都是永远不变的。数据仓库的数据是随时间的变化而不断变化的，这是数据仓库数据的第四个特征。这一特征表现在以下3方面：
- 数据仓库随时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据，追加到数据仓库中去，也就是要不断地生成OLTP数据库的快照，经统一集成后增加到数据仓库中去；但对于确实不再变化的数据库快照，如果捕捉到新的变化数据，则只生成一个新的数据库快照增加进去，而不会对原有的数据库快照进行修改。
- 数据仓库随时间变化不断删去旧的数据内容。数据仓库的数据也有存储期限，一旦超过了这一期限，过期数据就要被删除。只是数据仓库内的数据时限要远远长于操作型环境中的数据时限。在操作型环境中一般只保存有60~90天的数据，而在数据仓库中则需要保存较长时限的数据（如1 ~ 3年），以适应DSS进行趋势分析的要求。
- 数据仓库中包含有大量的聚合数据，这些聚合数据中很多跟时间有关，如数据经常按照时间段进行聚合，或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断地进行重新聚合。因此，数据仓库的数据特征都包含时间项，以标明数据的历史时期。
3. 数据仓库的发展
数据仓库的发展大致经历了这样的三个过程：
简单报表阶段：
这个阶段，系统的主要目标是解决一些日常的工作中业务人员需要的报表，以及生成一些简单的能够帮助领导进行决策所需要的汇总数据。这个阶段的大部分表现形式为数据库和前端报表工具。数据集市阶段：
这个阶段，主要是根据某个业务部门的需要，进行一定的数据的采集，整理，按照业务人员的需要，进行多维报表的展现，能够提供对特定业务指导的数据，并且能够提供特定的领导决策数据。数据仓库阶段：
这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。
通过数据仓库建设的发展阶段，我们能够看出，数据仓库的建设和数据集市的建设的重要区别就在于数据模型的支持。因此，数据模型的建设，对于我们数据仓库的建设，有着决定性的意义。
4.数据仓库与数据库的区别
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。
- 操作型处理
联机事务处理OLTP（On-Line Transaction Processing，），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。 - 分析型处理
联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题的历史数据进行分析，支持管理决策。
二者区别之前笔者已经在文章《OLAP实践 —— OLAP基本概念理解总计小记》对此做了分析，大家想详细了解可以直接看。这里只将结果给出：
| OLTP | OLAP | |
|---|---|---|
| 用户 | 操作人员 | 数据分析师、业务分析师、决策人员、高管 |
| 目的 | 操作处理，支持基本业务运行 | 发现和分析问题，支持决策 |
| 设计 | 面向应用，如银行业、零售业 | 面向主题，如销售、库存 |
| 特点 | 处理大量的小交易 | 使用复杂查询处理大量数据 |
| 数据内容 | 当前的、最新的业务交易数据 | 历史的、聚集的、统一的多维数据 |
| 查询类型 | 简单的、标准化的查询 | 复杂查询 |
| 数据操作 | 频繁的增、删、改操作；读取数据量不大 | 很少修改和删除操作；以读为主，读取数据量大。 |
| 时间要求 | 实时性要求高，通常是毫秒级 | 时间要求不严格，根据数据查询量，可以是秒级、分钟级甚至小时级 |
| 空间要求 | 通常较小，MB到GB级 | 由于要聚合大量数据，通常较大，GB到PB级 |
| 模型设计 | 为了保证数据修改的原子性，通常是规范化的数据模型，至少满足第三范式。 | 为了查询性能，通常是非规范化的数据模型 |
| 存储格式 | 修改操作频繁，通常是行存储 | 查询数据量大，通常是列式存储 |
| 主要应用 | 数据库 | 数据仓库 |
5. 数仓建模
说到数仓建模就不得不说数据模型，我们就需要了解什么是数据模型、什么是数仓建模、为什么要数仓建模以及如何进行数仓建模。
5.1 什么是数据模型？
数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。在这里，数据模型表现的抽象的是实体和实体之间的关系，通过对实体和实体之间关系的定义和描述，来表达实际的业务中具体的业务关系。
5.2 什么是数仓建模？
数据仓库模型是数据模型中针对特定的数据仓库应用系统的一种特定的数据模型。一般的来说，我们数据仓库模型分为几下几个层次，如图 ：
通过上面的图形，我们能够很容易的看出在整个数据仓库得建模过程中，我们需要经历一般四个过程：
业务建模，生成业务模型，主要解决业务层面的分解和程序化。领域建模，生成领域模型，主要是对业务模型进行抽象处理，生成领域概念模型。逻辑建模，生成逻辑模型，主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化。物理建模，生成物理模型，主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。
因此，在整个数据仓库的模型的设计和架构中，既涉及到业务知识，也涉及到了具体的技术，我们既需要了解丰富的行业经验，同时，也需要一定的信息技术来帮助我们实现我们的数据模型，最重要的是，我们还需要一个非常适用的方法论，来指导我们自己针对我们的业务进行抽象，处理，生成各个阶段的模型。
5.3 为什么要数仓建模？
一般来说，数据模型的建设主要能够帮助我们解决以下的一些问题：
进行全面的业务梳理，改进业务流程。
- 在业务模型建设的阶段，能够帮助我们的企业或者是管理机关对本单位的业务进行全面的梳理。
- 通过业务模型的建设，我们应该能够全面了解该单位的业务架构图和整个业务的运行情况，能够将业务按照特定的规律进行分门别类和程序化
- 同时，帮助我们进一步的改进业务的流程，提高业务效率，指导我们的业务部门的生产。
建立全方位的数据视角，消灭信息孤岛和数据差异。
通过数据仓库的模型建设，能够为企业提供一个整体的数据视角，不再是各个部门只是关注自己的数据，而且通过模型的建设，勾勒出了部门之间内在的联系，帮助消灭各个部门之间的信息孤岛的问题，更为重要的是，通过数据模型的建设，能够保证整个企业的数据的一致性，各个部门之间数据的差异将会得到有效解决。解决业务的变动和数据仓库的灵活性。
通过数据模型的建设，能够很好的分离出底层技术的实现和上层业务的展现。当上层业务发生变化时，通过数据模型，底层的技术实现可以非常轻松的完成业务的变动，从而达到整个数据仓库系统的灵活性。帮助数据仓库系统本身的建设。
通过数据仓库的模型建设，开发人员和业务人员能够很容易的达成系统建设范围的界定，以及长期目标的规划，从而能够使整个项目组明确当前的任务，加快整个系统建设的速度。
5.4 如何建设数据仓库模型
建设数据模型既然是整个数据仓库建设中一个非常重要的关键部分，那么，怎么建设我们的数据仓库模型就是我们需要解决的一个问题。这里我们将要详细介绍如何创建适合自己的数据模型。
5.4.1 数据仓库数据模型架构
数据仓库的数据模型的架构和数据仓库的整体架构是紧密关联在一起的，我们首先来了解一下整个数据仓库的数据模型应该包含的几个部分。从下图我们可以很清楚地看到，整个数据模型的架构分成5 大部分，每个部分其实都有其独特的功能。
从上图我们可以看出，整个数据仓库的数据模型可以分为大概5 大部分：
系统记录域（System of Record）：这部分是主要的数据仓库业务数据存储区，数据模型在这里保证了数据的一致性。内部管理域（Housekeeping）：这部分主要存储数据仓库用于内部管理的元数据，数据模型在这里能够帮助进行统一的元数据的管理。汇总域（Summary of Area）：这部分数据来自于系统记录域的汇总，数据模型在这里保证了分析域的主题分析的性能，满足了部分的报表查询。分析域（Analysis Area）：这部分数据模型主要用于各个业务部分的具体的主题业务分析。这部分数据模型可以单独存储在相应的数据集市中。反馈域（Feedback Area）：可选项，这部分数据模型主要用于相应前端的反馈数据，数据仓库可以视业务的需要设置这一区域。
通过对整个数据仓库模型的数据区域的划分，我们可以了解到，一个好的数据模型，不仅仅是对业务进行抽象划分，而且对实现技术也进行具体的指导，它应该涵盖了从业务到实现技术的各个部分。
5.4.2 数据仓库建模阶段划分
我们前面介绍了数据仓库模型的几个层次，下面我们讲一下，针对这几个层次的不同阶段的数据建模的工作的主要内容：
从上图我们可以清楚地看出，数据仓库的数据建模大致分为四个阶段：
业务建模，这部分建模工作，主要包含以下几个部分：
- 划分整个单位的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。
- 深入了解各个业务部门的内具体业务流程并将其程序化。
- 提出修改和改进业务部门工作流程的方法并程序化。
- 数据建模的范围界定，整个数据仓库项目的目标和阶段划分。
领域概念建模，这部分得建模工作，主要包含以下几个部分：
- 抽取关键业务概念，并将之抽象化。
- 将业务概念分组，按照业务主线聚合类似的分组概念。
- 细化分组概念，理清分组概念内的业务流程并抽象化。
- 理清分组概念之间的关联，形成完整的领域概念模型。
概念模型具体要求如下：
| 概念模型 | |
|---|---|
| 界定系统边界 | 1. 明确需求 |
| 2. 明确需做的决策类型 | |
| 3. 决策者感兴趣的问题 | |
| 4. 这些问题需要什么样的信息 | |
| 5. 要得到这些信息包含源数据的哪些数据 | |
| 确定主要的主题域及其内容 | 1. 主题域的公共码键 |
| 2. 主题域之间的联系 | |
| 3. 充分代表主题的属性组 | |
| 确定主题域间的关系 | 从企业角度深入了解各个信息系统的业务 |
概念模型理解实例如下：
| 建筑规划图 vs 概念模型 | ||
|---|---|---|
| 建筑规划图 | 概念模型 | 意义 |
| 盖什么房子? 住宅？写字楼？医院？ |
要解决何种商业问题 | 项目的目的 |
| 有几口人，都是谁？什么年龄、习惯、爱好... | 在此商业活动中，有哪些人或者组织参与，角色分别是什么？售货员、出纳、商场经理… | 组织 |
| 有哪些物件需要摆放？汽车、家具、家电… | 在此商业活动中，有哪些物件参与其中？商业、货架、收款机... | 物件 |
| 常识： 一个起居室、一个厨房、一个餐厅，需要一个二层小楼，一楼起居室、厨房和餐厅，二楼是卧室 特征： 两个车位，一个现在用，一个未来备用，一个游泳池... |
行业经验： 核心业务流程、组织架构、行业术语 定制： 特殊的流程、专有的术语、特有的用户群... |
功能范围 |
逻辑建模，这部分的建模工作，主要包含以下几个部分：
- 业务概念实体化，并考虑其具体的属性
- 事件实体化，并考虑其属性内容
- 说明实体化，并考虑其属性内容
逻辑模型具体要求如下：
| 逻辑模型 | |
|---|---|
| 分析丰富主题域，确定当前要装载的主题 | 1. 选择的主题域尽量小 |
| 2. 逐步求精 | |
| 确定粒度层次划分 | 1. 必须保存最细粒度数据 |
| 2. 根据业务部门的查询需求考虑多重粒度来提高复杂查询度 | |
| 确定数据分割策略（表划分，列划分） | 1. 数据量大小是决定是否进行数据分割和如何分割的主要因素 |
| 2. 数据分析处理的要求是选择数据分割标准的一个主要依据 | |
| 3. 所选择的数据分割的标准是自然的、易于实施的 | |
| 4. 考虑数据分割的标准与粒度划分层次式自适应的 | |
| 关系模型定义 | 1. 一个主题对应多个表 |
| 2. 确认主题的公共键码，确定各个表的关系模型 | |
| 记录系统定义 | 记录数据来源以及数据规范化标准 |
逻辑模型理解实例如下：
| 建筑设计图 vs 逻辑模型 | ||
|---|---|---|
| 建筑设计图 | 逻辑模型 | 意义 |
| 分多个域，各个区域的面积。 比如：起居室5m * 4m，主卧室3.3m * 4m... |
分多少个主题？每个主题包含的实体 比如：客户、商品、商店、订单... |
实体的定义 |
| 每个域的功能。 比如：主卧室中要有卫生间，要有衣橱 |
每个实体的属性都有什么？ 比如：客户的属性包括客户编码、客户姓名、客户联系方式、家庭住址......其中客户编码为主键 |
实体属性的定义 |
| 各个区域之间的联系。 比如：各个房间之间的走廊、卫生间和厨房需要相邻、热水器的热水管需要接通到厨房... |
各个实体之间的关系是什么？ 比如：订单实体中包括客户编码和商品编码，来自客户实体和商品实体 |
实体间的关系 |
| 设计时有哪些限制？ 比如：剪力墙不可动、空心砖处不可挂热水器等重物... |
各个实体是否有关系约束？单个属性是否有范围限制？ 比如：订单与客户之间的关系约束，客户编码唯一... |
约束的定义 |
物理建模，这部分得建模工作，主要包含以下几个部分：
- 针对特定物理化平台，做出相应的技术调整
- 针对模型的性能考虑，对特定平台作出相应的调整
- 针对管理的需要，结合特定的平台，做出相应的调整
- 生成最后的执行脚本，并完善之。
物理模型的具体要求如下：
| 物理模型 | |
|---|---|
| 确定项目资源 | 1. 更具预算和项目需求，对该项目的成本周期和资源进行估算 |
| 2. ETL占整个项目的70%，同时确定生命周期 | |
| 确定软件硬件配置 | 1. 估算数据容量 |
| 2. 对集群的性能要做心中有数 | |
| 数仓的存储设计实例 | ODS层： 从应用系统采集而来，只保存一定期限，同时支持部分近实时报表展示 |
| DWD层： 保存经过清洗，转换和重新组织的历史业务数据，数据将保留较久，满足系统最细粒度的查询需要。 |
|
| DIM层： 主要保存各主题域的维度信息数据 |
|
| DWS层： 面向KPI指标计算和分析，支持汇总层面交易级的指标查询，提高汇总级的KPI数据展示速度和数据保存时间，保存较久的历史数据。 |
|
| APP层： 基于部门或者一类特定分析主题需要，从企业及数据仓库单独获取的一个数据的逻辑或者物理子集。 |
|
| ETL工具选择 | spark、flink |
| hive、azkaban、hera | |
| datax、sqoop | |
| kafka、MQ | |
| doris、kylin、clickhouse | |
物理模型理解实例如下：
| 建筑施工图 vs 物理模型 | |
|---|---|
| 建筑施工图 | 物理模型 |
| 墙体的高度和厚度 比如：墙高5m，厚度30cm |
字符长度的定义 比如：VARCHAR、DATE... |
| 窗子高、每扇窗子的大小、是否使用定位器 | 字段的其他详细定义 比如：是否可为空，是否有默认值，是否属于某个域 |
| 各线路的具体位置 比如：水管、电线、网线的走法，以及留下图纸以备未来维修... |
精准详细的定义 比如：某字段为枚举类型，各个枚举值的具体含义，比如STATUS_CD |
| 设计时遵循行业标准以及一定准则 比如：墙面漆的颜色配置和谐、卫生间的防水标准 |
约束的定义 唯一主键、唯一值、强关系约束等 遵循术语表 统一的缩写表，一致的参照术语表 |
从我们上面对数据仓库的数据建模阶段的各个阶段的划分，我们能够了解到整个数据仓库建模的主要工作和工作量，希望能够对我们在实际的项目建设能够有所帮助。
6 数据仓库建模方法
数据仓库的建模方法同样也有很多种，每一种建模方法其实代表了哲学上的一个观点，代表了一种归纳，概括世界的一种方法。目前业界较为流行的数据仓库的建模方法非常多，这里主要介绍范式建模法，维度建模法，实体建模法等几种方法，每种方法其实从本质上讲就是从不同的角度看我们业务中的问题，不管从技术层面还是业务层面，其实代表的是哲学上的一种世界观。我们下面给大家详细介绍一下这些建模方法。
6.1 范式建模法（ThirdNormal Form，3NF）
6.1.1 范式建模简介
范式建模法是我们在构建数据模型常用的一个方法，该方法的主要由Inmon 所提倡的集线器的自上而下（EDW-DM）的数据仓库架构，主要解决关系型数据库的数据存储，利用的一种技术层面上的方法。目前，我们在关系型数据库中的建模方法，大部分采用的是三范式建模法。关系型模型的核心：规范化，规范化是把数据库组织成在保持存储数据完整性的同时最小化冗余数据的结构的过程。- 范式是数据库逻辑模型设计的基本理论，一个
关系模型可以从第一范式到第五范式进行无损分解，这个过程也可称为规范化。在数据仓库的模型设计中目前一般采用第三范式，它有着严格的数学定义。从其表达的含义来看，一个符合第三范式的关系必须具有以下三个条件:
- 每个属性值唯一，不具有多义性 ;
- 每个非主属性必须完全依赖于整个主键，而非主键的一部分 ;
- 每个非主属性不能依赖于其他关系中的属性，因为这样的话，这种属性应该归到其他关系中去。
6.1.2 数仓范式建模常用的三个范式
范式是基于整个关系型数据库的理论基础之上发展而来。我们来看下我们在数据仓库中常用的三大范式。
第一范式（1NF）（针对表的某一列也就是某个字段）：
指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。在符合第一范式（1NF）表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之，第一范式就是无重复的域。
第二范式（2NF）(针对某一列与复合主键的一部分有关)：
所谓第二范式，是指所有的非主属性都完全依赖于关键字。从这个定义可以看出，第二范式不存在非主属性对于部分候选关键字的部分依赖，不过允许非主属性之间存在着传递依赖。2NF是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或记录必须可以被唯一地区分。选取一个能区分每个实体的属性或属性组，作为实体的唯一标识。例如在员工表中的身份证号码即可实现每个一员工的区分，该身份证号码即为候选键，任何一个候选键都可以被选作主键(表的唯一主键)。在找不到候选键时，可额外增加属性以实现区分，如果在员工关系中，没有对其身份证号进行存储，而姓名可能会在数据库运行的某个时间重复，无法区分出实体时，设计辟如ID等不重复的编号以实现区分，被添加的编号或ID选作主键。（该主键的添加是在ER（Entity Relationship Diagram，实体-联系图)设计时添加，不是建库时随意添加）。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
说个例子，假定选课关系表为SelectCourse(学号，姓名，年龄，课程名称,成绩，学分)，关键字为组合关键字(学号，课程名称)，因为存在如下决定关系：
有图我们可以得到：
年龄、姓名是由学号决定的，与科目无关;总分是由科目决定的,与学号无关；成绩是由学号和科目共决定的；由此我们发现了两条关系依赖，即存在组合关键字中的字段决定非关键字的情况。所以这是不符合2NF的。
由于不符合2NF，这个选课关系表会存在如下问题：
(1) 数据冗余：
同一门课程由n个学生选修，"总分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
(2) 更新异常：
若调整了某门课程的学分，数据表中所有行的"总分"值都要更新，否则会出现同一门课程学分不同的情况。
(3) 插入异常：
假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。
(4) 删除异常：
假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
为了满足2NF我们最终将表查分为如下三个表：
学生：Student(学号,姓名，年龄)；
课程：Course(课程名称，学分)；
选课关系：SelectCourse(学号，课程名称，成绩)。
这样的数据库表是符合第二范式的， 消除了数据冗余、更新异常、插入异常和删除异常。
另外，所有单关键字的数据库表都符合第二范式，因为不可能存在组合关键字。第三范式（3NF）(针对某一列与主键无关，但是与某一非主键列有关)：
在2NF基础上，任何非主属性不依赖于其它非主属性（在2NF基础上消除传递依赖）。简而言之，第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。
例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
6.1.3 范式建模的优劣分析
根据 Inmon 的观点，数据仓库模型得建设方法和业务系统的企业数据模型类似。在业务系统中，企业数据模型决定了数据的来源，而企业数据模型也分为两个层次，即主题域模型和逻辑模型。同样，主题域模型可以看成是业务模型的概念模型，而逻辑模型则是域模型在关系型数据库上的实例。
从业务数据模型转向数据仓库模型时，同样也需要有数据仓库的域模型，即概念模型，同时也存在域模型的逻辑模型。这里，业务模型中的数据模型和数据仓库的模型稍微有一些不同。主要区别在于：
- 数据仓库的域模型应该包含企业数据模型的域模型之间的关系，以及各主题域定义。数据仓库的域模型的概念应该比业务系统的主题域模型范围更加广。
- 在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类，以及实体的关系等。
以笔者的观点来看，Inmon 的范式建模法的最大优点就是从关系型数据库的角度出发，结合了业务系统的数据模型，易于维护，高度集成，能够比较方便的实现数据仓库的建模。但其缺点也是明显的，由于建模方法限定在关系型数据库之上，在某些时候反而限制了整个数据仓库模型的灵活性，性能等，结构死板，部署周期较长，特别是考虑到数据仓库的底层数据向数据集市的数据进行汇总时，需要进行一定的变通才能满足相应的需求。因此，笔者建议读者们在实际的使用中，参考使用这一建模方式。
6.1.4 范式建模实例：
这里举一个建模的基本实例，我们知道：
- Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。数据流程是将操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据建设原子数据的数据仓库EDW，EDW不是多维格式的，不方便上层应用做数据分析，所以需要通过汇总建设成多维格式的数据集市层。
- 由于EDW的数据是原子粒度的，数据量比较大，完全规范的3范式在数据的交互的时候效率比较低下，所以通常会根据实际情况在事实表上做一些冗余，减少过多的数据交互。
- 范式数仓的基本架构
- Inmon理论下结构就是：ODS、EDW和DM，也就是贴源层、主题模型层、共性加工层以及集市层。每一个层对应于数据库下面的模式，接下来依次介绍这四个层：
ODS（贴源层）：即这里存放的数据与原系统保持一致，将采集公司所有的系统产生的数据以及外部数据（包括合作数据以及爬虫获得的数据），将所采集的数据汇总到一起，供EDW和DM使用；EDW：这一层分为两个，即ADM（共性加工层）和FDM（主题模型层）。其中FDM将从ODS层不同系统不同表的字段进行分类，同一主题的字段都归为一类，目前流行的十大主题；ADM是加工一些共性的指标，指标从ODS或者FDM的字段加工来，这层主要供集市层使用；DM：数据集市层，这一层是将业务部门所关注的指标进行汇总，形成的数据，不同的业务部门可以形成不同的集市，具体情况可以视情况而定；集市层的架构可以细分为：基础层、汇总层和分析层。
这样的层次结构，虽然层次很清晰，但是如果越靠近底层数据出现问题，那么就会越影响到后面的；同时时间上做不到实时更新，一边都是T+1，或者越到后面时效性都可能是T+2/3的情况。因此当我们考虑到我们的应用的场景是否需要考虑时效性的时候，我们也要做出相应的调整。
6.2 维度建模
6.2.1 维度建模简介
- 维度建模法，Kimball 提出的总线式的自下而上（DM-DW）的数据仓库架构。概念。其最简单的描述就是，按照事实表，维表来构建数据仓库，数据集市。同样的，操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据，利用维度建模方法建设一致维度的数据集市。通过一致性维度可以将数据集市联系在一起，由所有的数据集市组成数据仓库。
6.2.3 常见的维度建模模型
最流行的数据仓库概念是多维数据模型。这种模型可以以星型模式，雪花模式，或事实星座模式的形式存在。
星型模型(Star schema):
事实表在中心，周围围绕地连接着维表(每维一个)，事实表包含有大量数据，没有冗余。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是我们在使用hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。
雪花模型(Snowflake schema):
是星型模型的变种，其中某些维表是规范化的，因而把数据进一步分解到附加表中。结果，模式图形成类似雪花的形状。雪花模型相较于星座模型，是把维表进行了规范化。当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。（雪花模型可以理解为，为了获取更“深”或更“细”一级的信息）
事实星座模型(Fact constellations):
多个事实表共享维表，这种模式可以看作星座模式集，因此称作星系模式(galaxy schema)，或者事实星座(fact constellation)。事实星座模式是把事实间共享的维进行合并。对概念进行分层，有利于数据的汇总。
6.2.3.1 星型模型和雪花模型对比
星形模型(Star Schema)和雪花模型(SnowflakeSchema)是数据仓库中常用到的两种方式，而它们之间的对比要从四个角度来进行讨论。
| 对比项 | 星型模型 | 雪花模型 |
|---|---|---|
| 数据优化 | 星形模型实用的是反规范化数据。在星形模型中，维度直接指的是事实表，业务层级不会通过维度之间的参照完整性来部署。 | 雪花模型使用的是规范化数据，也就是说数据在数据库内部是组织好的，以便消除冗余，因此它能够有效地减少数据量。通过引用完整性，其业务层级和维度都将存储在数据模型之中。 |
| 业务模型 | 而在星形模型中，所有必要的维度表在事实表中都只拥有外键。主键是一个单独的唯一键(数据属性)，为特殊数据所选择。外键(参考属性)仅仅是一个表中的字段，用来匹配其他维度表中的主键。 | 在雪花模型中，数据模型的业务层级是由一个不同维度表主键-外键的关系来代表的。主键是一个单独的唯一键(数据属性)，为特殊数据所选择。外键(参考属性)仅仅是一个表中的字段，用来匹配其他维度表中的主键。 |
| 性能 | 星形模型在维度表、事实表之间的连接相对较少，因此性能较高 | 雪花模型在维度表、事实表之间的连接很多，因此性能方面会比较低。 |
| ETL | 星形模型加载维度表，不需要再维度之间添加附属模型，因此ETL就相对简单，而且可以实现高度的并行化。 | 雪花模型加载数据集市，因此ETL操作在设计上更加复杂，而且由于附属模型的限制，不能并行化。 |
总体来说，雪花模型使得维度分析更加容易，比如“针对特定的广告主，有哪些客户或者公司是在线的?”星形模型用来做指标分析更适合，比如“给定的一个客户他们的收入是多少?”
6.2.4 维度建模优劣势分析
6.2.4.1 维度建模优点
上图的这个架构中是典型的星型架构。星型模式之所以广泛被使用，在于针对各个维作了大量的预处理，如按照维进行预先的统计、分类、排序等。通过这些预处理，能够极大的提升数据仓库的处理能力。特别是针对3NF 的建模方法，星型模式在性能上占据明显的优势。
同时，维度建模法的另外一个优点是，维度建模非常直观，紧紧围绕着业务模型，可以直观的反映出业务模型中的业务问题。不需要经过特别的抽象处理，即可以完成维度建模。
总的来说就是，相对范式性能高，构建迅速，最快的看到投资回报率，与业务紧密结合，敏捷灵活。
但是，维度建模法的缺点也是非常明显的，由于在构建星型模式之前需要进行大量的数据预处理，因此会导致大量的数据处理工作。而且，当业务发生变化，需要重新进行维度的定义时，往往需要重新进行维度数据的预处理。而在这些与处理过程中，往往会导致大量的数据冗余。
6.2.4.2 维度建模缺点
另外一个维度建模法的缺点就是，如果只是依靠单纯的维度建模，不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。作为企业资源不太好维护，结构复杂，数据集市集成困难。
因此以笔者的观点看，维度建模的领域主要适用与数据集市层，它的最大的作用其实是为了解决数据仓库建模中的性能问题。维度建模很难能够提供一个完整地描述真实业务实体之间的复杂关系的抽象方法。
6.3 实体建模法
6.3.1 实体建模简介
实体建模法并不是数据仓库建模中常见的一个方法，它来源于哲学的一个流派。从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法，将整个业务也可以划分成一个个的实体，而每个实体之间的关系，以及针对这些关系的说明就是我们数据建模需要做的工作。
6.3.2 实体建模组成
虽然实体法粗看起来好像有一些抽象，其实理解起来很容易。即我们可以将任何一个业务过程划分成3 个部分，实体，事件和说明，如下图所示：
上图表述的是一个抽象的含义，如果我们描述一个简单的事实：“小明开车去学校上学”。以这个业务事实为例，我们可以把“小明”，“学校”看成是一个实体，“上学”描述的是一个业务过程，我们在这里可以抽象为一个具体“事件”，而“开车去”则可以看成是事件“上学”的一个说明。
从上面的举例我们可以了解，我们使用的抽象归纳方法其实很简单，任何业务可以看成3 个部分：
- 实体，主要指领域模型中特定的概念主体，指发生业务关系的对象。
- 事件，主要指概念主体之间完成一次业务流程的过程，特指特定的业务过程。
- 说明，主要是针对实体和事件的特殊说明。
6.3.3 实体建模优劣分析
由于实体建模法，能够很轻松的实现业务模型的划分，因此，在业务建模阶段和领域概念建模阶段，实体建模法有着广泛的应用。从笔者的经验来看，再没有现成的行业模型的情况下，我们可以采用实体建模的方法，和客户一起理清整个业务的模型，进行领域概念模型的划分，抽象出具体的业务概念，结合客户的使用特点，完全可以创建出一个符合自己需要的数据仓库模型来。
但是，实体建模法也有着自己先天的缺陷，由于实体说明法只是一种抽象客观世界的方法，因此，注定了该建模方法只能局限在业务建模和领域概念建模阶段。因此，到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。
因此，笔者建议读者在创建自己的数据仓库模型的时候，可以参考使用上述的三种数据仓库得建模方法，在各个不同阶段采用不同的方法，从而能够保证整个数据仓库建模的质量。
6.3.4 几种建模方式的选型
- 在关系型数据库中的建模方法，大部分采用的是第三范式建模法;
- 维度建模星型架构是比较常见的。因为我们在实际项目中，往往最关注的是查询性能问题，至于磁盘空间一般都不是问题。 当然，在维度表数据量极大，需要节省存储空间的情况下，或者是业务逻辑比较复杂、必须要体现清晰的层次概念情况下，可以使用雪花型维度。在复合式的数据仓库架构中，操作型或事务型系统的数据源，通过ETL抽取转换和加载到数据仓库的ODS层，然后通过ODS的数据，利用范式建模方法，建设原子数据的数据仓库EDW，然后基于EDW，利用维度建模方法建设数据集市;
- 至于实体建模很少使用,也仅仅局限于业务/领域建模,到了逻辑建模阶段和物理建模阶段，则是范式建模和维度建模发挥长处的阶段。
6.4 维度建模与范式建模对比
6.4.1 特征对比
6.4.2 特性对比
| 特性 | Kimball | Inmon |
|---|---|---|
| 数据摄取 | yes | yes |
| stage | yes | yes |
| ETL | yes | yes |
| 数据集市 | yes | yes |
| 商业需求 | yes | yes |
| 数据时间属性 | yes | yes |
| 数据仓库优先 | no | yes |
| 事实维度拆分 | yes | no |
| 关系表维护 | no | yes |
| 处理导向 | yes | no |
| 数据模型泛化 | no | yes |
| 精心设计 | no | yes |
| 缓慢变化维 | yes | no |
| 连续变化维 | no | yes |
6.4.3 优劣对比
我们主要从时间、开发难度、维护难度、技能要求、数据要求五个方面对比：
| 特性 | Kimball | Inmon |
|---|---|---|
| 时间 | 快速交付 | 路漫漫其修远兮 |
| 开发难度 | 小 | 大 |
| 维护难度 | 大 | 小 |
| 技能要求 | 入门级 | 专家级 |
| 数据要求 | 特定业务 | 企业级 |
6.4.4 特点对比
我们主要从定义、数据集数据存储、开发周期、维护成本等四个方面进行对比：
| 对比项 | 维度模型 | 范式建模 |
|---|---|---|
| 定义 | 维度建模源于Kimball提出的总线式的自下而上（DM-DW）的数据仓库架构。 | 范式建模源于Inmon提出的集线器的自上而下（EDW-DM）的数据仓库架构。 |
| 数据及存储 | 模型结构简单，星型模型为主 | 同一份数据只存放在一个地方，因此只能从一个地方获取，没有数据冗余，保证了数据一致性 |
| 开发周期 | 开发周期短，能够快速迭代 | 开发周期较长，开发成本较高 |
| 维护 | 维护成本较高 | 解耦（系统级与业务级），方便维护 |
6.4.5 总结
- 对于大多数互联网公司由于需求的快速变化，处心积虑设计（Inmon）实体-关系的设计哲学似乎并不能满足快速迭代的业务需要。所以，更多场景下趋向于使用（Kimball）维度-事实的设计哲学反而可以更快地完成任务。
- 数据仓库建设通常以日为粒度，将OLTP数据变化的不情况增量同步到数据仓库中。
- 在数据仓库的实际工作中，80%的时间会花费在任务调度、数据清洗和业务梳理上，只有20%的时间会投入到数据挖掘上。
