文章/答案/技术大牛

发布

社区首页 >专栏 >【读书笔记】《 Hadoop构建数据仓库实践》第2章

【读书笔记】《 Hadoop构建数据仓库实践》第2章

辉哥

发布于 2022-05-13 06:22:24

1K0

文章被收录于专栏：区块链入门区块链入门

02-《 Hadoop构建数据仓库实践》.jpg

第2章数据仓库设计基础

2.1 关系数据模型

2.1.1 关系数据模型中的结构

6．关系表的属性

关系表有如下属性：

● 每个表都有唯一的名称。

● 一个表中每个列有不同的名字。

● 一个列的值来自于相同的属性域。

● 列是无序的。

● 行是无序的。

7．关系数据模型中的键

（1）超键

一个列或者列集，唯一标识表中的一条记录。超键可能包含用于唯一标识记录所不必要的额外的列，我们通常只对仅包含能够唯一标识记录的最小数量的列感兴趣。

【举例】

表一：学号、姓名、性别、身份证号、教室号

表二：教室号、班主任

超键：我们可以使用（学号、姓名）的组合键来确定性别属性，则（学号、姓名）就是超键。

候选键：就是将超键中的多余属性去除掉，我们其实可以使用学号来确定性别，这时候，学号就是候选键。

主键：学号和身份证号都能够唯一确定性别，但是我们只会选择其中的一个来充当主键。

外键：就是表一的教室号是外键，关联的是表二的教室号。

（2）候选键

仅包含唯一标识记录所必需的最小数量列的超键。

表的候选键有三个属性：

● 唯一性：在每条记录中，候选键的值唯一标识该记录。

● 最小性：具有唯一性属性的超键的最小子集。

● 非空性：候选键的值不允许为空。

在我们的例子中，分公司编号是候选键，如果每个分公司的邮编都不同，那么邮编也可以作为分公司表的候选键。一个表中允许有多个候选键。

（3）主键

唯一标识表中记录的候选键。主键是唯一、非空的。没有被选做主键的候选键称为备用键。对于例子中的分公司表，分公司编号是主键，邮编就是备用键，而员工表的主键是员工编号。

主键的选择在关系数据模型中非常重要，很多性能问题都是由于主键选择不当引起的。在选择主键时，我们可以参考以下原则：

● 主键要尽可能地小。

● 主键值不应该被改变。主键会被其他表所引用。如果改变了主键的值，所有引用该主键的值都需要修改，否则引用就是无效的。

● 主键通常使用数字类型。数字类型的主键要比其他数据类型效率更高。

● 主键应该是没有业务含义的，它不应包含实际的业务信息。无意义的数字列不需要修改，因此是主键的理想选择。大部分关系型数据库支持的自增属性或序列对象更适合当作主键。

● 虽然主键允许由多列组成，但应该使用尽可能少的列，最好是单列。

（4）外键

一个表中的一个列或多个列的集合，这些列匹配某些其他（也可以是同一个）表中的候选键。注意外键所引用的不一定是主键，但一定是候选键。当一列出现在两张表中的时候，它通常代表两张表记录之间的关系。如例子中分公司表的分公司编号和员工表的所属分公司。它们的名字虽然不同，但却是同一含义。分公司表的分公司编号是主键，在员工表里所属分公司是外键。同样，因为公司经理也是公司员工，所以它是引用员工表的外键。主键所在的表被称为父表，外键所在的表被称为子表。

2.1.2 关系完整性

关系数据模型有两个重要的完整性规则：实体完整性和参照完整性。

1．空值（NULL）

表示一个列的值目前还不知道或者对于当前记录来说不可用。空值可以意味着未知，也可以意味着某个记录没有值，或者只是意味着该值还没有提供。空值是处理不完整数据或异常数据的一种方式。

2．关系完整性规则

（1）实体完整性

在一个基本表中，主键列的取值不能为空。基本表指的是命名的表，其中的记录物理地存储在数据库中，与之对应的是视图。视图是虚拟的表，它只是一个查询语句的逻辑定义，其中并没有物理存储数据。

（2）参照完整性

如果表中存在外键，则外键值必须与主表中的某些记录的候选键值相同，或者外键的值必须全部为空。在图2-1中，员工表中的所属分公司是外键。该列的值要么是分公司表的分公司编号列中的值，要么是空（如新员工已经加入了公司，但还没有被分派到某个具体的分公司时）。

4．关系数据库语言

关系数据库的主要语言是SQL语言。

SQL是Structured Query Language的缩写，意为结构化查询语言。SQL已经被国际标准化组织（ISO）进行了标准化，使它成为正式的和事实上的定义和操纵关系数据库的标准语言。

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等。

2.1.3 规范化

没有规范化，数据的更新处理将变得困难，异常的插入、修改、删除数据的操作会频繁发生。为了便于理解，来看下面的例子。

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

image.png

为了克服这些异常更新，我们需要对表进行规范化设计。规范化是通过应用范式规则实现的。最常用的范式有第一范式（1NF）、第二范式（2NF）、第三范式（3NF）。

(1) 第一范式(1NF)

表中的列只能含有原子性（不可再分）的值。

数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。

上例中张三有两个手机号存储在mobile列中，违反了1NF规则。为了使表满足1NF，数据应该修改为如表2-6所示。

image.png

(2) 第二范式(2NF)

规则是符合第一范式，而且没有部分主键功能决定其他属性的现象，也就是主键之外的其他属性都完全的功能相依于主键。

第二范式要同时满足下面两个条件：

● 满足第一范式。

● 没有部分依赖。

例如，员工表的一个候选键是{id, mobile, deptNo}，而deptName依赖于{deptNo}，同样name仅依赖于{id}，因此不是2NF的。为了满足第二范式的条件，需要将这个表拆分成employee、dept、employee_dept、employee_mobile四个表，如表2-7至表2-10所示。

image.png

image.png

(3) 第三范式(3NF)

第三范式要同时满足下面两个条件：

● 满足第二范式。

● 没有传递依赖。

例如，员工表的province、city、district依赖于zip，而zip依赖于{id}，换句话说，province、city、district传递依赖于{id}，违反了3NF规则。为了满足第三范式的条件，可以将这个表拆分成employee和zip两个表，如表2-11、表2-12所示。

image.png

在关系数据模型设计中，一般需要满足第三范式的要求。如果一个表有良好的主外键设计，就应该是满足3NF的表。规范化带来的好处是通过减少数据冗余提高更新数据的效率，同时保证数据完整性。然而，我们在实际应用中也要防止过度规范化的问题。规范化程度越高，划分的表就越多，在查询数据时越有可能使用表连接操作。而如果连接的表过多，会影响查询的性能。关键的问题是要依据业务需求，仔细权衡数据查询和数据更新的关系，制定最适合的规范化程度。还有一点需要注意的是，不要为了遵循严格的规范化规则而修改业务需求。

(4) BCNF范式

BCNF范式(Boyce/Codd Normal Form)，是由R.F.Boycy和E.F. Codd共同提出的，可以算成是第三正则化的补充，规则是符合第三正则化原则，并且没有非主键属性可以功能性决定部分主键的现象。

假设有一个表R，其中的属性有A，B，C，D，E，以A和B为复合主键，R={A，B，C，D，E}，如果存在有非主键属性，比如说C可以功能性决定B，C→B，而B是主键的一部分，这时第三正则化是没有办法分辨出来这种错误的，所以有BCNF正则化规则来把关，同样地，BCNF正则化的方法也是将原来的表拆开，成立一个新的关联表R1来装C→B，R1={C，B}，但原来的表R还是以(A，B)为复合主键，以B为外键关联到新的表去，以保留原有的信息。

R={A,B,D,E}，R1={C,B}，R.B=R1.B

2.2 维度数据模型

维度数据模型简称维度模型（Dimensional modeling, DM），是一套技术和概念的集合，用于数据仓库设计。

事实和维度是两个维度模型中的核心概念。事实表示对业务数据的度量，而维度是观察数据的角度。事实通常是数字类型的，可以进行聚合和计算，而维度通常是一组层次关系或描述信息，用来定义事实。例如，销售金额是一个事实，而销售时间、销售的产品、购买的顾客、商店等都是销售事实的维度。维度模型按照业务流程领域即主题域建立，例如进货、销售、库存、配送等。不同的主题域可能共享某些维度，为了提高数据操作的性能和数据一致性，需要使用一致性维度，例如几个主题域间共享维度的复制。术语“一致性维度”源自Kimball，指的是具有相同属性和内容的维度。

2.2.1 维度数据模型建模过程

维度模型通常以一种被称为星型模式的方式构建。所谓星型模式，就是以一个事实表为中心，周围环绕着多个维度表。还有一种模式叫做雪花模式，是对维度做进一步规范化后形成的。

一般使用下面的过程构建维度模型：

● 选择业务流程

● 声明粒度

● 确认维度

● 确认事实

1．选择业务流程

确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础。因此，建模的第一个步骤是描述需要建模的业务流程。

为了描述业务流程，可以简单地使用纯文本将相关内容记录下来，或者使用“业务流程建模标注”（BPMN）方法，也可以使用统一建模语言（UML）或其他类似的方法。

2．声明粒度

在选择维度和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。

不同的事实可以有不同的粒度，但同一事实中不要混用多种不同的粒度。

3．确认维度

维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。典型的维度都是名词，如日期、商店、库存等。维度表存储了某一维度的所有相关数据，例如，日期维度应该包括年、季度、月、周、日等数据。

4．确认事实

大部分事实表的度量都是数字类型的，可累加，可计算，如成本、数量、金额等。

2.2.2 维度规范化

与关系模型类似，维度也可以进行规范化。对维度的规范化（又叫雪花化），可以去除冗余属性，是对非规范化维度做的规范化处理。

总体来说，当多个维度共用某些通用的属性时，做规范化会是有益的。例如，客户和供应商都有省、市、区县、街道等地理位置的属性，此时分离出一个地区属性就比较合适。

2.2.4 星型模式

星型模式是维度模型最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。

星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。一个含有很多维度表的星型模式有时被称为蜈蚣模式，显然这个名字也是因其形状而得来的。

1．事实表

事实表记录了特定事件的数字化的考量，一般由数字值和指向维度表的外键组成。通常会把事实表的粒度级别设计得比较低，使得事实表可以记录很原始的操作型事件，但这样做的负面影响是累加大量记录可能会更耗时。事实表有以下三种类型：

● 事务事实表。记录特定事件的事实，如销售。

● 快照事实表。记录给定时间点的事实，如月底账户余额。

● 累积事实表。记录给定时间点的聚合事实，如当月的总的销售金额。

一般需要给事实表设计一个代理键作为每行记录的唯一标识。代理键是由系统生成的主键，它不是应用数据，没有业务含义，对用户来说是透明的。

2．维度表

维度表的记录数通常比事实表少，但每条记录包含有大量用于描述事实数据的属性字段。

维度表可以定义各种各样的特性，以下是几种最长用的维度表：

● 时间维度表。描述星型模式中记录的事件所发生的时间，具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合，需要记录数据的历史，因此每个数据仓库都需要一个时间维度表。

● 地理维度表。描述位置信息的数据，如国家、省份、城市、区县、邮编等。

● 产品维度表。描述产品及其属性。

● 人员维度表。描述人员相关的信息，如销售人员、市场人员、开发人员等。

● 范围维度表。描述分段数据的信息，如高级、中级、低级等。

通常给维度表设计一个单列、整型数字类型的代理键，映射业务数据中的主键。业务系统中的主键本身可能是自然键，也可能是代理键。自然键指的是由现实世界中已经存在的属性组成的键，如身份证号就是典型的自然键。

5．示例

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

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

image.png

2.2.5 雪花模式

雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓的“雪花化”就是将星型模式中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中心的雪花型结构，即雪花模式。将维度表进行规范化的具体做法是，把低基数的属性从维度表中移除并形成单独的表。

星型模式和雪花模式都是建立维度数据仓库或数据集市的常用方式，适用于加快查询速度比高效维护数据的重要性更高的场景。这些模式中的表没有特别的规范化，一般都被设计成一个低于第三范式的级别。

4．示例

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

下面所示的查询语句的结果等价于前面星型模式的查询，可以明显看到此查询比星型模式的查询有更多的表连接。

image.png

2.3 Data Vault模型

参考

（1）Data Vault 数据仓库模型构建-1

https://www.jianshu.com/p/df3684c20092

（2）Data Vault初探（三） —— 建立Data Vault模型

https://blog.csdn.net/wzy0623/article/details/50222269

2.4 数据集市

2.4.1 数据集市的概念

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

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

image.png

2.4.3 数据集市设计

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

正如前面所介绍的，设计维度模型先要确定维度表、事实表和数据粒度级别，下一步是使用主外键定义事实表和维度表之间的关系。数据集市中的主键最好使用系统生成的自增的单列数字型代理键。模型建立好之后，设计ETL步骤抽取操作型源系统的数据，经过数据清洗和转换，最终装载进数据集市中的维度表和事实表中。

2.5 数据仓库实施步骤

1．定义范围

首要任务是定义项目的范围。项目范围定义了一个数据仓库项目的边界。典型的范围定义是组织、地区、应用、业务功能的联合表示。定义范围时通常需要权衡考虑资源（人员、系统、预算等）、进度（项目的时间和里程碑要求）、功能（数据仓库承诺达到的能力）三方面的因素。定义好清晰明确的范围，并得到所有项目干系人的一致认可，对项目的成功是非常重要的。项目范围是设定正确的期望值、评估成本、估计风险、制定开发优先级的依据。

2．确定需求

数据仓库项目的需求可以分为业务需求和技术需求。

（1）定义业务需求

与业务人员进行面对面的沟通，是理解业务流程的好方式。沟通的结果是使数据仓库的业务需求更加明确。在为数据仓库收集需求的过程中，还要考虑设计要能适应需求的变化。

（2）定义技术需求

需要知道如何清理操作型数据，如何移除垃圾数据，如何将来自多个源系统的相同数据整合在一起。另外，还要确认数据的更新频率。

3．逻辑设计

下面就要进入数据仓库的逻辑设计阶段。逻辑设计过程中，需要定义特定数据的具体内容，数据之间的关系，支持数据仓库的系统环境等，本质是发现逻辑对象之间的关系。

（1）建立需要的数据列表

细化业务用户的需求以形成数据元素列表。

（2）识别数据源

应该从最大最复杂的源系统开始，在必要时再查找其他源系统。

（3）制作实体关系图

逻辑设计的交付物是实体关系图（entity-relationshipdiagram，简称ERD）和对它的说明文档（数据字典）。实体对应关系数据库中的表，属性对应关系数据库中的列。ERD传统上与高度规范化的关系模型联系密切，但该技术在维度模型中也被广泛使用。在维度模型的ERD中，实体由事实表和维度表组成，关系体现为在事实表中引用维度表的主键。因此先要确认哪些信息属于中心事实表，哪些信息属于相关的维度表。维度模型中表的规范化级别通常低于关系模型中的表。