老姜大数据-数仓基础

迷南。 2022-08-31 11:03 358阅读 0赞

# 第1章数仓概念 #

## 数仓的特性 ##

1.  面向主题  
    传统的操作型系统是围绕组织的功能性应用进行组织的，而数据仓库是面向主题的。主题是一个抽象概念，简单地说就是与业务相关的数据的类别，每一个主题基本 对应一个宏观的分析领域。数据仓库被设计成辅助人们分析数据。例如，一个公司要分析销售数据，就可以建立一个专注于销售的数据仓库。
2.  集成  
    集成的概念与面向主题是密切相关的。还用销售的例子，假设公司有多条产品线和多种产品销售渠道，而每个产品线都有自己独立的销售数据库。此时要想从公司层 面整体分析销售数据，必须将多个分散的数据源统一成一致的、无歧义的数据格式后，再放置到数据仓库中。因此数据仓库必须能够解决诸如产品命名冲突、计量单位不 一致等问题。当完成了这些数据整合工作后，该数据仓库就可称为是集成的。
3.  随时间变化

为了发现业务变化的趋势、存在的问题，或者新的机会，需要分析大量的历史数据。这与联机事务处理（OLTP）系统形成鲜明的对比。联机事务处理反应的是当前时 间点的数据情况，要求高性能、高并发和极短的响应时间，出于这样的需求考虑，联机事务处理系统中一般都将数据依照活跃程度分级，把历史数据迁移到归档数据库中。而数据仓库关注的是数据随时间变化的情况，并且能反映在过去某个时间点的数据是怎样的。换句话说，数据仓库中的数据是反映了某一历史时间点的数据快照，这 也就是术语“随时间变化”的含义。

1.  非易失  
    非易失指的是，一旦进入到数据仓库中，数据就不应该再有改变。操作型环境中的数据一般都会频繁更新，而在数据仓库环境中一般并不进行数据更新。也就是说，数据仓库中的数据基本是静态的。这是一个不难理解的逻辑概念。数据仓库的 目的就是要根据曾经发生的事件进行分析，如果数据是可修改的，将使历史分析变得没有意义。
2.  粒度  
    粒度问题遍布于数据仓库体系结构的各个部分。粒度是指数据的细节或汇总程度，细节程度越高，粒度级别越低。例如，单个事务是低粒度级别，而全部一个月事务的汇总就是高粒度级别。

数据粒度一直是数据仓库设计需要重点思考的问题。

# 第2章数据仓库架构 #

## 2.1 基本架构 ##

数据仓库架构：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70]  
图中显示的整个数据仓库环境包括操作型系统和数据仓库系统两大部分。操作型系统的数据由各种形式的业务数据组成，这其中可能有关系数据库、TXT或CSV文 件、HTML或XML文档，还可能存在外部系统的数据，比如网络爬虫抓取来的互联网数据等，数据可能是结构化、半结构化、非结构化的。这些数据经过抽取、转换和装载（ETL）过程进入数据仓库系统。

\*\*RDS（RAW DATA STORES）是原始数据存储的意思。\*\*ETL过程的bug或系统中的其他错误是不可避免的，保留原始数据使得追踪并修改这些错误成为可能。  
\*\*TDS（TRANSFORMED DATA STORES）意为转换后的数据存储。\*\*这是真正的数据仓库中的数据。大量的用户会在经过转换的数据集上处理他们的日常查询。如果前面的工作做得好，这些数据将被以保证最重要的和最频繁的查询能够快速执行的方式构建。

### ETL过程分成了抽取和转换装载两个部分 ###

#### ETL抽取过程 ####

抽取过程负责从操作型系统获取数据，该过程一般不做数据聚合和汇总，但是会按照主题进行集成，物理上是将操 作型系统的数据**全量或增量复制到数据仓库系统的RDS中**。

#### ETL转换装载过程 ####

转换装载过程并将数据进行清洗、过滤、汇总、统一格式化等一系列转换操作，使数据转为适合查询的格式， 然后装载进数据仓库系统的TDS中。

原始数据存储和转换后的数据存储是逻辑概念，它们可能物理存储在一起，也可能分开。

### 自动化调度组件 ###

自动化调度组件的作用是自动定期重复执行ETL过程。不同角色的数据仓库用户对数据的更新频率要求也会有所不同，财务主管需要每月的营收汇总报告，而销售人 员想看到每天的产品销售数据。作为通用的需求，所有数据仓库系统都应该能够建立周期性自动执行的工作流作业。传统数据仓库一般利用操作系统自带的调度功能（如Linux的cron或Windows的计划任务）实现作业自动执行。

### 数据目录有时也被称为元数据存储 ###

数据目录有时也被称为元数据存储，它可以提供一份数据仓库中数据的清单。用户通过它应该可以快速解决这些问题：什么类型的数据被存储在哪里，数据集的构建 有何区别，数据最后的访问或更新时间等。此外还可以通过数据目录感知数据是如何被操作和转换的。一个好的数据目录是让用户体验到系统易用性的关键。

### 查询引擎组件负责实际执行用户查询。 ###

查询引擎组件负责实际执行用户查询。传统数据仓库中，它可能是存储转换后数据的（Oracle、MySQL等关系数据库系统内置的）查询引擎，还可能是以固定时间间隔向其导入数据的OLAP立方体，如Essbase cube。

### 用户界面 ###

用户界面指的是最终用户所使用的接口程序。可能是一个GUI软件，如BI套件的中的客户端软件，也可能就是一个浏览器。

## 2.2主要数据仓库架构 ##

在数据仓库技术演化过程中，产生了几种主要的架构方法，包括**数据集市架构、Inmon企业信息工厂架构、Kimball数据仓库架构和混合型数据仓库架构。**

### 2.2.1数据集市架构 ###

数据集市是按主题域组织的数据集合，用于支持部门级的决策。有两种类型的数据集市：独立数据集市和从属数据集市。

1.  独立数据集市  
    独立数据集市集中于部门所关心的单一主题域，数据以部门为基础部署，无须考虑企业级别的信息共享与集成。
2.  从属数据集市  
    如Bill Inmon所说，从属数据集市的数据来源于数据仓库。数据仓库里的数据经过整合、重构、汇总后传递给从属数据集市。从属数据集市的架构如图  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 1]

**建立从属数据集市的好处主要有：**

*  性能：当数据仓库的查询性能出现问题，可以考虑建立几个从属数据集市，将查询从数据仓库移出到数据集市。 安全：每个部门可以完全控制他们自己的数据。
 *  数据一致：因为每个数据集市的数据来源都是同一个数据仓库，有效消除了数据不一致的情况。

### 2.2.2Inmon企业信息工厂架构 ###

Inmon企业信息工厂架构如图  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 2]

ETL过程：ETL过程从操作型系统抽取数据，然后将数据转换成一种标准形式，最终将转换后的数据装载到企业级数据仓库中。ETL是周期性运行的批处理过程。

部门级数据集市：是面向主题数据的部门级视图，数据从企业级数据仓库获取。数据在进入部门数据集市时可能进行聚合。数据集市使用多维模型设计，用于数据 分析。重要的一点是，所有的报表工具、BI工具或其他数据分析应用都从数据集市查询数据，而不是直接查询企业级数据仓库。

### 2.2.3Kimball数据仓库架构 ###

Kimball数据仓库架构如图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 3]  
对比上一张图可以看到，Kimball与Inmon两种架构的主要区别在于核心数据仓库的设计和建立。\*\*Kimball的数据仓库包含高粒度的企业数据，使用多维模型设计，这也意味着数据仓库由星型模式的维度表和事实表构成。\*\*分析系统或报表工具可以直接访问多维数据仓库里的数据。在此架构中的数据集市也与Inmon中的不同。这里的数据集市 是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。

### 2.2.4混合型数据仓库架构 ###

混合型数据仓库架构如图

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 4]  
所谓的混合型结构，指的是在一个数据仓库环境中，联合使用Inmon和Kimball两种架构。从架构图可以看到，这种架构将Inmon方法中的数据集市部分替换成了一个多维数据仓库，而数据集市则是多维数据仓库上的逻辑视图。使用这种架构的好处是，既可以利用规范化设计消除数据冗余，保证数据的粒度足够细；又可以利用多维结构 更灵活地在企业级实现报表和分析。

# 第3章 数据ETL抽取-转换-装载 #

**ETL（Extract、Transform、Load）中文意为抽取、转换、装载。**

ETL是建立数据仓库最重要的处理过程，也是最体现工作量的环节，一般会占到整个数据仓库项目工作量的一半以上。

*  抽取：从操作型数据源获取数据。
 *  转换：转换数据，使之转变为适用于查询和分析的形式和结构。
 *  装载：将转换后的数据导入到最终的目标数据仓库。

建立一个数据仓库，就是要把来自于多个异构的源系统的数据集成在一起，放置于一个集中的位置用于数据分析。

## 3.1数据抽取 ##

抽取操作从源系统获取数据给后续的数据仓库环境使用。这是ETL处理的第一步，也是最重要的一步。数据被成功抽取后，才可以进行转换并装载到数据仓库中。

**下面分别从逻辑和物理两方面介绍数据抽取方 法。**

### 逻辑抽取 ###

有两种逻辑抽取类型：全量抽取和增量抽取。

### 物理抽取 ###

依赖于选择的逻辑抽取方法和能够对源系统所做的操作和所受的限制，存在两种物理数据抽取机制：直接从源系统联机抽取或者间接从一个脱机结构抽取数据。

## 3.2数据转换 ##

数据从操作型源系统获取后，需要进行多种转换操作。如统一数据类型、处理拼写错误、消除数据歧义、解析为标准格式等。数据转换通常是最复杂的部分，也是ETL开发中用时最长的一步。数据转换的范围极广，从单纯的数据类型转化到极为复杂的数据清洗技术。

**数据转换一个最重要的功能是清洗数据，目的是只有“合规”的数据才能进入目标数据仓库。这步操作在不同系统间交互和通信时尤其必要。**

某些业务和技术的需要，也需要进行多种数据转换，例如下面的情况：（面试）  
只装载特定的数据列。例如，某列为空的数据不装载。  
统一数据编码。例如，性别字段，有些系统使用的是1和0，有些是‘M’和‘F’，有些是‘男’和‘女’，统一成‘M’和‘F’。  
自由值编码。例如，将‘Male’改成‘M’。  
预计算。例如，产品单价\*购买数量＝金额。基于某些规则重新排序以提高查询性能。  
合并多个数据源的数据并去重。预聚合。例如，汇总销售数据。行列转置。  
将一列转为多列。例如，某列存储的数据是以逗号作为分隔符的字符串，将其分割成多列的单个值。  
 合并重复列。  
预连接。例如，查询多个关联表的数据。  
数据验证。针对验证的结果采取不同的处理，通过验证的数据交给装载步骤，验证失败的数据或 直接丢弃，或记录下来做进一步检查。

## 3.3数据装载 ##

ETL的最后步骤是把转换后的数据装载进目标数据仓库。这步操作需要重点考虑两个问题，一是数据装载的效率问题，二是一旦装载过程中途失败了，如何再次重复 执行装载过程。

装载到数据仓库里的数据，经过汇总、聚合等处理后交付给多维立方体或数据可视化、仪表盘等报表工具、BI工具做进一步的数据分析。

## 第4章 数据仓库需求 ##

**从基本需求和数据需求**两方面介绍对数据仓库系统的整体要求。

## 4.1基本需求 ##

数据仓库的目的就是能够让用户方便地访问大量数据，允许用户查询和分析其中的业务信息。这就要求数据仓库必须是安全的、可访问的和自动化的。

1.  安全性

数据仓库中的数据对于最终用户是只读的，任何人都不能修改其中的数据，这是由数据的非易失性所决定的。  
划分数据的安全等级，如公开的、机密、秘密、绝密等。  
制定访问控制方案，决定哪些用户可以访问哪些数据。  
设计授予、回收、变更用户访问权限的方法。  
添加对数据访问的审计功能。

1.  可访问性  
    能够快速准确地分析所需要的数据是辅助决策支持的关键。

3.自动化

这里的自动化有狭义和广义两个层面的理解。狭义的自动化指的是数据仓库相关作业的自动执行。比如ETL过程、报表生成、数据传输等处理，都可以周期性定时自 动完成。广义的数据仓库自动化指的是在保证数据质量和数据一致性的前提下，加速数据仓库系统开发周期的过程。整个数据仓库生命周期的自动化，从对源系统分析到ETL，再到数据仓库的建立、测试和文档化，可以帮助加快产品化进程，降低开发和管理成本，提高数据质量。

## 4.2数据需求 ##

通过数据仓库，既可以周期性地回答已知的问题（如报表等），也可以进行即席查询（ad-hoc queries）。报表最基本的需求就是对预定义好的一系列查询条件、查询内容，排序条件等进行组合，查询数据，把结果用表格或图形的形式展现出来。而所谓的即席查询不是预定义好的，而是在执行时才确定的。

1.  准确性  
    想要数据仓库实施成功，业务用户必须信任其中的数据。
2.  时效性  
    用户的时效性要求差异很大。有些用户需要数据精确到毫秒级，而有些用户只需要几分钟、几小时甚至几天前的数据就可以了。数据仓库是分析型系统，用于决策支 持，所以实践中一般不需要很强的实时性，**以一天作为时间粒度是比较常见的**
3.  历史可追溯性  
    数据仓库更多的价值体现在它能够辅助随时间变化的趋势分析，并帮助理解业务事件（如特殊节日促销等）与经营绩效之间的关系。

# 第5章 数仓模型设计 #

## 5.1关系数据模型 ##

**关系数据模型 就是关系性表**

### 关系数据模型中的结构 ###

![在这里插入图片描述][5a699de35e1e47f1bf12fb5d3779882e.png]

1.  关系(表/实体)  
    **关系：由行和列构成的二维结构，对应关系数据库中的表**

注意，这种认识只是我们从逻辑上看待关系模型的方式，并不应用于表在磁盘上 的物理结构。表的物理存储结构可以是堆文件、索引文件或哈希文件。堆文件是一个无序的数据集合，索引文件中表数据的物理存储顺序和逻辑顺序保持一致，哈希文件 也称为直接存取文件，是通过一个预先定义好的哈希函数确定数据的物理存储位置。

1.  属性(列/字段)  
    由属性名称和类型名称构成的顺序对，对应关系数据库中表的列，如地址（Variable Characters）是公司表的一个属性。属性值是属性的一个特定的有效值，可以是简单的标量值，也可以是复合数据类型值。

**在关系数据模型中，我们把关系描述为表，表中的行对应不同的记录，表中的列对应不同的属性。**

1.  属性域(字段的范围)  
    属性的取值范围。每一个属性都有一个预定义的值的范围。  
    ![在这里插入图片描述][214b78e8e1eb47b0b5dcba816a1132bd.png]
2.  元组(行)  
    关系中的一条记录，对应关系数据库中的一个表行。元组可以以任何顺序出现，而关系保持不变，也就是说，在关系理论中，表中的行是没有顺序的。
3.  关系数据库  
    **关系数据库：一系列规范化的表的集合。**

以上介绍了关系数据模型的两组术语：**“关系、属性、元组”和“表、列、行”**。在这里它们的含义是相同的，只不过前者是关系数据模型的正式术语，而后者是常用的数 据库术语。其他可能会遇到的类似术语还有实体（表）、记录（行）、字段（列）等。

**关系表的属性**  
关系表有如下属性：

每个表都有唯一的名称。  
一个表中每个列有不同的名字。  
一个列的值来自于相同的属性域。列是无序的。  
行是无序的。

**关系数据模型中的键**  
主键 外键

**数据表的规范化**

关系数据模型的规范化是一种组织数据的技术。规范化方法对表进行分解，以消除数据冗余，避免异常更新，提高数据完整性。

1.  第一范式（1NF）  
    表中的列只能含有原子性（不可再分）的值

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 5]  
![在这里插入图片描述][4b86665d7df04098a68a04e8b0f963f9.png]

1.  第二范式（2NF）

第二范式要同时满足下面两个条件：  
满足第一范式。且没有部分依赖。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 6]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 7]

1.  第三范式（3NF）

第三范式要同时满足下面两个条件：  
满足第二范式。没有传递依赖。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 8]

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

## 5.2维度数据模型 ##

**维度数据模型简称维度模型（Dimensional modeling, DM），是一套技术和概念的集合，用于数据仓库设计。不同于关系数据模型，维度模型不一定要引入关系数据库。**  
维度模型是一种趋向于支持最终用户对数 据仓库进行查询的设计技术，是围绕性能和易理解性构建的。尽管关系模型对于事务处理系统表现非常出色，但它并不是面向最终用户的。

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

### 5.2.1维度数据模型建模过程（面试重点） ###

**维度模型通常以一种被称为星型模式的方式构建。所谓星型模式，就是以一个事实表为中心，周围环绕着多个维度表。还有一种模式叫做雪花模式，是对维度做进一 步规范化后形成的。本节后面会讨论这两种模式。一般使用下面的过程构建维度模型：**  
**选择业务流程  
声明粒度  
确认维度  
确认事实**  
这种使用四步设计法建立维度模型的过程，有助于保证维度模型和数据仓库的可用性。

#### 选择业务流程 ####

确认哪些业务处理流程是数据仓库应该覆盖的，是维度方法的基础。因此，建模的第一个步骤是描述需要建模的业务流程。例如，需要了解和分析一个零售店的销售情况，那么与该零售店销售相关的所有业务流程都是需要关注的。为了描述业务流程，可以简单地使用纯文本将相关内容记录下来，或者使用“业务流程建模标

#### 声明粒度 ####

确定了业务流程后，下一步是声明维度模型的粒度。这里的粒度用于确定事实中表示的是什么，例如，一个零售店的顾客在购物小票上的一个购买条目。在选择维度 和事实前必须声明粒度，因为每个候选维度或事实必须与定义的粒度保持一致。在一个事实所对应的所有维度设计中强制实行粒度一致性是保证数据仓库应用性能和易用 性的关键。从给定的业务流程获取数据时，原始粒度是最低级别的粒度。建议从原始粒度数据开始设计，因为原始记录能够满足无法预期的用户查询。汇总后的数据粒度 对优化查询性能很重要，但这样的粒度往往不能满足对细节数据的查询需求。不同的事实可以有不同的粒度，但同一事实中不要混用多种不同的粒度。维度模型建立完成 之后，还有可能因为获取了新的信息，而回到这步修改粒度级别。

#### 确认维度 ####

设计过程的第三步是确认模型的维度。维度的粒度必须和第二步所声明的粒度一致。维度表是事实表的基础，也说明了事实表的数据是从哪里采集来的。典型的维度 都是名词，如日期、商店、库存等。维度表存储了某一维度的所有相关数据，例如，日期维度应该包括年、季度、月、周、日等数据。

#### 确认事实 ####

确认维度后，下一步也是维度模型四步设计法的最后一步，就是确认事实。这一步识别数字化的度量，构成事实表的记录。它是和系统的业务用户密切相关的，因为 用户正是通过对事实表的访问获取数据仓库存储的数据。大部分事实表的度量都是数字类型的，可累加，可计算，如成本、数量、金额等。

### 5.2.2星型模式 ###

![在这里插入图片描述][74f1a2704f874c519d676c05a4d43b5d.png]

星型模式是维度模型最简单的形式，也是数据仓库以及数据集市开发中使用最广泛的形式。星型模式由事实表和维度表组成，一个星型模式中可以有一个或多个事实表，每个事实表引用任意数量的维度表。星型模式的物理模型像一颗星星的形状，中心是一个事实表，围绕在事实表周围的维度表表示星星的放射状分支，这就是星型模式这个名字的由来。  
星型模式将业务流程分为事实和维度。事实包含业务的度量，是定量的数据，如销售价格、销售数量、距离、速度、重量等是事实。维度是对事实数据属性的描述，如日期、产品、客户、地理位置等是维度。一个含有很多维度表的星型模式有时被称为蜈蚣模式，显然这个名字也是因其形状而得来的。蜈蚣模式的维度表往往只有很少 的几个属性，这样可以简化对维度表的维护，但查询数据时会有更多的表连接，严重时会使模型难于使用，因此在设计中应该尽量避免蜈蚣模式。

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

事务事实表。记录特定事件的事实，如销售。  
快照事实表。记录给定时间点的事实，如月底账户余额。  
累积事实表。记录给定时间点的聚合事实，如当月的总的销售金额。一般需要给事实表设计一个代理键作为每行记录的唯一标识。代理键是由系统生成的主键，它 不是应用数据，没有业务含义，对用户来说是透明的。  
**维度表**  
维度表的记录数通常比事实表少，但每条记录包含有大量用于描述事实数据的属性字段。维度表可以定义各种各样的特性，以下是几种最长用的维度表：

时间维度表。描述星型模式中记录的事件所发生的时间，具有所需的最低级别的时间粒度。数据仓库是随时间变化的数据集合，需要记录数据的历史，因此每个数 据仓库都需要一个时间维度表。  
地理维度表。描述位置信息的数据，如国家、省份、城市、区县、邮编等。产品维度表。描述产品及其属性。  
人员维度表。描述人员相关的信息，如销售人员、市场人员、开发人员等。范围维度表。描述分段数据的信息，如高级、中级、低级等。  
通常给维度表设计一个单列、整型数字类型的代理键，映射业务数据中的主键。业务系统中的主键本身可能是自然键，也可能是代理键。自然键指的是由现实世界中 已经存在的属性组成的键，如身份证号就是典型的自然键。

### 5.2.3雪花模型 ###

![在这里插入图片描述][32d7bb250206469d8a9d78e6149172d7.png]单一的依赖关系

雪花模式是一种多维模型中表的逻辑布局，其实体关系图有类似于雪花的形状，因此得名。与星型模式相同，雪花模式也是由事实表和维度表所组成。所谓 的“雪花化”就是将星型模式中的维度表进行规范化处理。当所有的维度表完成规范化后，就形成了以事实表为中心的雪花型结构，即雪花模式。  
在雪花模式中，一个维度被规范化成多个关联的表，而在星型模式中，每个维度由一个单一的维度表所表示。一个规范化的维度对应一组具有层次关系的维度表，而 事实表作为雪花模式里的子表，存在具有层次关系的多个父表。

### 5.2.4 星座模型 ###

多个事实表共享关联一张维度表  
![在这里插入图片描述][6eb2efb07dc74c9b99cbe1568289096a.png]

# 第6章数据仓库实施步骤（面试重点） #

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70]: /images/20220829/a30025acfdc34f9285d1c593ba0af973.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 1]: /images/20220829/a6305f76c7c14304bef0c65d6a45fca1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 2]: /images/20220829/7b343c382bf349c497a89d511cf550bc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 3]: /images/20220829/83540c578d4e40ecb65bfdc11e16e380.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 4]: /images/20220829/2af6eb07033e4d1e9b8b9038e961f0ff.png
[5a699de35e1e47f1bf12fb5d3779882e.png]: /images/20220829/2b2bb8ddd62e47179e887c29d28d332b.png
[214b78e8e1eb47b0b5dcba816a1132bd.png]: /images/20220829/2100412283304246bc6c26d06c4fd9b7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 5]: /images/20220829/fb339788443e4118bf718b7be7f79afd.png
[4b86665d7df04098a68a04e8b0f963f9.png]: /images/20220829/23f71efcab354e66a780456fad9b78ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 6]: /images/20220829/c8ab90057a6f4692b6c74b4e507417c8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 7]: /images/20220829/26b2294bf80e4270a459e4300ca25461.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3lhbmdzaGVuZ3dlaTIzMDYxMg_size_16_color_FFFFFF_t_70 8]: /images/20220829/224a33706a9f4d529434381c156e0e0e.png
[74f1a2704f874c519d676c05a4d43b5d.png]: /images/20220829/ff05e5f7918c4779bc4fef6bd95b5b10.png
[32d7bb250206469d8a9d78e6149172d7.png]: /images/20220829/9d68918806444a748bf0cbdaf6306f3e.png
[6eb2efb07dc74c9b99cbe1568289096a.png]: /images/20220829/9de20696abde45eeb79d4b7de74fa162.png