3.1.1 建模工具是什么？

PowerDesigner/SQLYog/EZDML

3.1.2、ER模型 

实体关系模型（Entity Relationship）符合3NF模式

实体关系模型将复杂的数据抽象为两个概念-----实体、关系。实体表示一个对象，关系表示对象与

对象之间的关系。列如，学生和班级就是两个实体，学生和班级之间是从属关系。

3.1.3、三范式 

（1）、函数依赖

1. 完全函数依赖

通过AB得到C，但是AB单独得不出C，那么说C完全依赖于AB

2. 部分函数依赖

通过AB能够得到C，但是单独A或单数B也能得到C,那么说C部分依赖于AB

3. 传递函数依赖

通过A得到B，通过B得到C，但是C得不到A。那么说C传递依赖于A

（2）、范式

1. 第一范式

原则：属性(字段)不可切割

2. 第二范式

原则：属性(字段)不能存在 部分函数依赖

3. 第三范式

原则：属性不能存在 传递函数依赖

3.1.4、维度模型 

维度模型时将复杂的 业务过程 通过 事实和维度 两个概念进行呈现，事实通常对应业务过程，而 维度通常对应业务过程发生时所处的环境。

注：业务过程可以概括为一个不可拆分的行为事件，如下单，取消订单，付款，退单等等。

3.1.5、维度建模理论之事实表 

（1）、事实表概述

1、事实表作为数据仓库维度建模的核心，紧紧围绕业务过程来设计。其包含于该业务过程有关的维度引用（维度表外键）以及该业务过程的度量值（度量值通常是可加的数值）

2、特点：事实表通常比较 细长，即列较少，但是行较多，且行的增速快。

3、分类：事务型事实表、周期型快照事实表、累积型快照事实表 

（2）、事务型事实表

1、概述事务型事实表用来记录各业务过程，它保存的是 各业务过程 的 原子操作事件，即最细粒度的操作事件。粒度是指事实表中一行数据所表达的业务细节程度。

2、设计流程

遵循四个步骤：选择业务过程→声明粒度→确认维度→确认事实

选择业务过程：选择业务需求的业务过程，以及可能需求的业务过程。业务过程可以概  括为 一个个不可拆分的行为事件，如：下单，付款等等。通常情况，一 个业务过程对应一张事务 型事实表。

声明粒度：业务过程确认后，需要为每个业务过程声明粒度。即精确定义每张事务表的   每行数据表示什么，应尽可能选择最细粒度。

确认维度：确定与每张事务型事实表相关的维度，确认维度时应该尽量多的选择与业务  过程相关的环境信息。因为维度的丰富成果决定了维度模型能够支持的指标      的丰富程度。

确认事实： 其实就是确认每个业务过程的度量值（通常是可累加的数字类型的值，如：   次数、个数、件数、金额等）

3、确认事实的事实类型

此处的事实类型是指度量值的类型，而非事实表的类型。事实（度量值）共分为三类，分别是可加事实，半可加事实和不可加事实。

1）. 可加事实：是指可以按照与事实表相关的所有维度进行累加，列如事务型事实表中的事实(件数，金额)

2）. 半可加事实：是指只能按照与事实表相关的一部分维度进行累加

3）. 不可加事实：是指完全不具备可加性，列如比率事实。不可加事实通常需要转化成可加事实，如比率可转化为分子和分母。

（3）、周期型快照事实表

1、概述

周期型快照事实表以具有 规律性的、可预见的 时间间隔来记录事实，主要用于分析一些存量型(商品库存，账户余额)或者状态型（空气温度、行驶速度）指标。

2、设计流程

确认粒度：周期型快照事实表的粒度可由 采样周期和维度描述 来确定。周期可以（每   日，每周，每月等）。列如指标为统计每个仓库中每种商品的库存→粒度表   示：每日-仓库-商品

确认事实：事实可以根据指标决定，列如指标为统计每个仓库中每种商品的库存，则事       实就是商品库存数。

（4）、累积型快照事实表

1、概述

累积型快照事实表是基于一个业务过程中的多个关键业务过程联合处理而构建的事实表，如（交易流程中的下单、支付、发货、确认收货业务过程）。累积型快照事实表通常情况具有多个日期字段，每个日期对应业务流程中的一个关键业务过程(里程碑) 累计型快照事实表主要用于分析业务过程之间的时间间隔等需求。列如：用户下单到支付的平均时间间隔，适用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，从而变得十分简单高效。

2、设计流程

设计流程和事务型事实表类似，也可采用以下四个步骤选择业务过程→声明粒度→确认维度→确认事实

不同之处：

1）. 选择业务过程：选择业务过程中需要关联分析多个关键业务过程，多个业务过程对应一张累积型快照事实表

2）. 确认维度：选择与各业务过程相关的维度，需要注意的是，每个业务过程均需要一个日期维度

3.1.6、维度建模理论之维度表 

（1）、维度表概述

事实表是紧紧围绕业务过程进行设计的，而维度表则围绕业务过程所处的环境进行设计。维度表主要包含一个主键和各种维度字段(维度属性)。

（2）、维度表设计步骤

1、确定维度（表）

在设计事实表时已经确定了每个事实表相关的维度，理论上每个相关的维度均需要对应一张维表。需要注意到，可能存在多个事实表与同一个维度都相关的情况，这种情况需要保证维度的唯一性(即只创建一张维度表)，另外如果某些维度表的维度属性很少，则可以不创建改维度表，而是把该维度表属性直接增加到与之相关的事实表中(维度退化)。

2、确认主维度表和相关维表

此处的主维表和相关维表均指业务系统中与某维度相关的表 。相关维度表的粒度通常和主维度表粒度相同

3、确认维度属性

确认维度属性即确认维度表字段。维度属性主要来自业务系统中与改维度对应的主维度表和相关维度表。维度属性可以直接从主维表或者相关维表中获取，也可以通过进一步加工得到。

确认维度属性时，需要遵循一下要求：

1）. 尽可能生成丰富的维度属性

2）. 尽量不适用编码，而是用明确的文字说明， 一版可以编码和文字一起使用

3）. 尽量沉淀出通用的维度属性 

（3）、维度表设计要点

1、规范化和反规范化

规范化：是指使用一系列范式设计数据库的过程，其目的是减少数据的冗余，曾强数据的一致性。通常情况下，规范化之后，一张表的字段会被拆分到多张表。

反规范化：是指将多种表的数据冗余到一张表，其目的是减少join的操作，提高查询性能。

设计维度表时候，如果对其进行了规范化，得到的维度模型称为雪花模型，如果进行反规范化得到的模型称为星型模型。多个星型模型通过公共维表连接起来的我们称为星座模型

2、维度变化

维度属性通常不是静态的，而是会随时间变化的，数据仓库的一个重要特点就是反映历史的变化，所以如何保存维度的历史状态是维度设计的重要工作之一。保存维度数据的历史状态，通常有以下两种做法，分别是全量快照表和拉链表。

1）、全量快照表：离线数据仓库的计算周期通常为每天一次，所以可以每天保存一份全量的维度数据。这种方式

的优点和缺点都很明显。

优点：简单而有效，开发和维护成本低，且方便理解和使用。

缺点：浪费存储空间，尤其是当数据的变化比例比较低时。

2）、拉链表：拉链表的意义就在于能够更加高效的保存维度信息的历史状态 

3、多值维度

如果事实表中一条记录在某个维度表中有多条记录与之对应，称为多值维度。例如，下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，所会商品维度表中就可能有多条数据与之对应。

针对这种情况，通常采用以下两种方案解决。

第一种：降低事实表的粒度，例如将订单事实表的粒度由一个订单降低为一个订单中的一个商品项。

第二种：在事实表中采用多字段保存多个维度值，每个字段保存一个维度id。这种方案只适用于多值维度个数固定的情况。

建议尽量采用第一种方案解决多值维度问题。

4、多值属性

维表中的某个属性同时有多个值，称之为“多值属性”，例如商品维度的平台属性和销售属性，每个商品均有多个属性值。

针对这种情况，通常有可以采用以下两种方案。

第一种：将多值属性放到一个字段，该字段内容为key1:value1，key2:value2的形式，例如一个手机商品的平台属性值为“品牌:华为，系统:鸿蒙，CPU:麒麟990”。

第二种：将多值属性放到多个字段，每个字段对应一个属性。这种方案只适用于多值属性个数固定的情况。