2019 NJU SE 商务智能复习整理

最新推荐文章于 2024-03-27 09:58:13 发布

Anmous

最新推荐文章于 2024-03-27 09:58:13 发布

阅读量1.3k

点赞数 3

文章标签：数据仓库

本文链接：https://blog.youkuaiyun.com/u010094719/article/details/103773581

版权

构造数据仓库

明确需求
- 用户的主观分析需求
选择工具
- 数据抽取（Data Extract）工具
- 数据清洗（Data Cleaning）工具
- 元数据（Metadata）管理工具
- 数据分析工具（Look for patterns）
- 数据挖掘工具（Look for hidden patterns）
- 数据展现工具
构建数据仓库

操作型处理

也叫事务处理，是指对数据库的日常联机访问操作，通常是对一个或一组记录的查询和修改，主要是为企业的特定应用服务的，所以也叫联机事务处理
On-Line Transaction Processing（OLTP）
- 通常仅仅是对一个或一组记录的查询或修改
- 查询简单，但执行频率高
- 人们关心的是处理的响应时间、数据的安全性和完整性等指标

分析型处理

也叫做信息型处理，主要用于企业管理人员的决策分析，为制订企业的未来经营管理计划提供辅助决策信息
- 需要对大量的事务型数据进行统计、归纳和分析
- 需要访问大量的历史数据
- 执行频率和对响应时间的要求都不高
典型的分析型处理
- 决策支持系统（DSS——Decision Support System）

事务处理环境不适宜DSS应用的原因*

事务处理和分析处理的性能特性不同
- 用户每次操作处理的时间段，存取数据量小，但操作频率高，并发程度大
- 每次分析可能需要连续运行很长的时间，存取数据量大，但很少做这样的分析处理，也没有并发执行的要求
数据集成问题
- 事务处理一般只需要与本业务部门有关的当前细节数据
- 分析处理的数据可能来自多种不同的数据源
- 对于需要集成数据的DSS应用来说，在应用程序中对事务处理环境中的这些纷繁复杂的数据进行集成，将带来下述问题：
  - 大大加重程序员的负担
  - 重复计算
  - 极低的分析处理效率
数据的动态集成问题
- 集成数据必须以一定的周期进行刷新（即采用动态集成策略），但传统的事务处理并不具备动态集成的能力
历史数据问题
- 事务处理一般只需要当前数据
- 分析处理更看重历史数据
数据的综合问题
- 事务处理需要的是当前的细节性操作数据
- 分析处理需要的往往是大量的总结性分析型数据，而非数据库中的细节性操作型数据
- 在分析前往往需要对细节数据进行不同程度的综合，传统的事务处理不具备这种综合能力
数据的访问问题
- 事务处理对于需要修改的数据必须实时“更新”数据库
- 分析处理不需要实时的“更新”操作，但需要定时刷新

20191228094857

数据仓库

定义

数据仓库就是一个面向主题的、集成的、不可更新的、随时间不断变化的数据集合，用于支持经营管理过程中的决策制定

四个特征

面向主题
- 主题是较高层次上将企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，是对企业中某一宏观分析领域涉及的分析对象
- 面向主题是指数据仓库内的信息是按主题进行组织的，为按主题进行决策的过程提供信息
- 如果按照面向主题的方式进行数据组织，首先一共抽取主题，即按照管理人员的分析要求来确定主题，而与每个主题相关的数据又与有关的事务处理所需的数据不尽相同
集成
- 数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，因此数据仓库中的数据必须从多个数据源中获取，这些数包括多种类型数据库、文件系统以及Internet网上数据等，它们通过数据集成而形成数据仓库中的数据
非易失（稳定的）
- 数据仓库中的数据是经过抽取而形成的分析型数据，不具有原始性，主要供企业决策分析之用，执行的主要是“查询操作，一般情况下不执行“更新”操作。同时，一个稳定的数据环境也有利于数据分析操作和决策的制订
时变的（随时间不断变化）
- 数据仓库内的信息并不只是关于企业当时或某一时点的信息，而是系统记录了企业从过去某一时点到目前的各个阶段的信息，通过这些信息可以对企业的发展历程和未来趋势作出定量分析和预测
- 因此数据仓库中的数据通常带有时间属性，同时必须以一定时间段为单位进行统一更新

关键技术

数据的ETL（抽取、转换、装载）
存储和管理
数据的访问和表现

数据抽取

数据仓库中的数据来源于数据源，将数据源中数据通过网络进行抽取，并经加工、转换、综合后形成数据库中的数据，这就是数据仓库的数据抽取

数据刷新

经过抽取进入数据仓库的数据，在经过一段时间后要重新修正，修改那些过时的数据，保存那些不变的数据，此种动作被称为数据仓库的刷新
数据刷新的过程与抽取类似，但刷新的数据量往往小于抽取的数据量。由于仅需要对修改过的数据进行刷新，因而其实现难度与复杂性要大于数据抽取

一般数据刷新的方法包括

时间戳
- 适用情况：若数据库中的记录有时间属性，则可根据OLTP数据库中的数据有无更新，以及在执行更新操作时数据的修改时间标志来实现数据仓库中数据的动态刷新
- 缺点：大多数数据库系统中的数据并不含有时间属性
DELTA文件
- 适用情况：有些OLTP数据库的应用程序在工作过程中会形成一些DELTA文件以记录该应用所作的数据修改操作，可根据该DELTA文件进行数据刷新
- 优点：采用此方法可避免对整个数据库的对比扫描，具有较高的刷新效率
- 缺点：这样的应用程序并不普遍，修改现有的应用程序的工作量又太大
建立映像文件
- 实现方法：在上一次数据刷新后对数据库作一次快照，在本次刷新之前再对数据库作一次快照。比较两个快照的不同，从而确定数据仓库的数据刷新操作
- 缺点：需要占用大量的系统资源，可能较大地影响原有数据库系统的性能
日志文件
- 实现方法：一般OLTP数据库都有日志文件，可根据OLTP数据库的日志信息来实现数据仓库的数据刷新
- 优点：日志是OLTP数据库的固有机制，不会影响原有OLTP数据库的性能，具有比DELTA文件和建立映像文件更高的刷新效率

数据仓库是多维度多层次的

维度是对观察数据对象的角度
层次是数据对象的综合程度

数据仓库的数据组织形式

简单堆积文件
轮转综合文件
简化直接文件
连续文件

元数据

关于数据的数据，描述了数据的结构、内容、编码、索引等内容

通过元数据可以将数据仓库和复杂的数据源系统的变化隔离，是数据仓库开发和维护的一个关键因素，也是保证数据抽取质量的依据。

数据集市

数据仓库与数据集市的关系类似于传统关系数据库系统中的基表与视图的关系.数据集市的数据来自于仓库,它是数据仓库中数据的一个部分与局部,是一个数据的再抽取与组织的过程

完整的数据仓库/数据集市体系结构组成

数据源
数据仓库
数据集市(Data Mart)

数据仓库与数据集市的关系

自顶向下的结构
自底向上的结构
总线结构的数据集市
企业级数据集市结构

自顶向下的结构

先构建企业数据仓库，再基于企业数据仓库构建数据集市
优点
- 建立数据集市能够减轻DW访问负载
- 各部门可以任意处理数据
- 数据转换和整合在DW阶段统一完成
- 具备数据缓冲功能
缺点
- 成本高、见效慢、数据集市间不共享资源

自底向上的结构

先构建数据集市，再基于数据集市构建企业数据仓库
优点
- 见效快、启动资金少
缺点
- 各个部门都啊哟进行数据清理整合
- 可能造成“蜘蛛网”、数据不一致等问题
- 总体上没有节约资金

总线结构的数据集市

特点
- 不直接建立数据仓库而直接建立数据集市
- 各个数据集市之间不是孤立的，相互之间通过一种共享维表和事实表的“总线结构”紧密联系在一起
优点
- 共享维表和事实表，解决了数据集市的许多问题
缺点
- 这种结构基于多维模型，应用限制于OLAP
- 多个数据源直接影响多个集市，造成数据仓库结构不十分稳定

企业级数据集市

（瞄一眼就好。。）

20191230150625

OLAP

比较项目	OLAP	OLTP
应用基础	数据仓库	DBMS
用户	决策者（高级管理人员）	一般操作员（管理人员）
目的	为决策和管理提供支持	为日常工作服务
数据特征	导出数据	原始数据
数据细节	综合性数据，细节程度低	细节程度高
时间特征	历史数据，横跨一个时段	当前数据
更新方法	周期性刷新	可实时更新
数据量需求	一次处理需大量数据	一次处理需少量数据

基本概念

维（Dimension）：维指观察分析对象的角度
- 例如，可以从三个“维”角度观察“销售金额”这个对象：
  - 时间维：可从时间角度统计商品在不同时段内的销售金额，以便于分析其与时间之间的关系
  - 商品维：根据商品的分类情况统计每一类的销售金额，以便于分析其与商品类型之间的关系
  - 地域维：可根据每个连锁店所在的地域统计其销售金额，以便于分析其与地域之间的关系
层（Layer）：反映了对分析对象的分析深度
- 例如：
  - 按商品的价格分为：高档、中档、低档
  - 按商品的供应商分为：外资、合资、国营、私营、个体
  - 购买商品的顾客信息按年龄层次分为：老年、中年、青年、少年儿童、婴儿
维成员：维的一个取值称为该维的一个“维成员”
- 如果一个维是多层次的，则该维的“维成员”可以是
  - 在不同维层次上取值的组合
  - 在某个维层次上的取值
- 对一个度量值来说，维成员正是该度量值在某维中位置的描述
  - 多维数组：（维1，维2，···，变量（表示我们所要观察的度量值））
数据单元（单元格）
- 多维数组可以被看成是一个根据多个下标进行定位的值的集合
- 当多维数组的每一维都选中一个维成员，这些维成员的组合就唯一确定了一个度量值，即：（维成员1，维成员2，……，维成员n，度量值）
- 这样一个值或存放该值的地方我们称其为一个“数据单元”

OLAP的数据的构造方式

ROLAP（Relational OLAP）：用RDBMS管理，将星型（雪花）模式用二维表形式存储，表间用关键字相连，从而构成一个关系模式，称为ROLAP
MOLAP（Multi-Dimensional OLAP）：用“多维数据库管理系统”管理，多维数据库采用的基本数据模式就是“多维数组”
HLOAP：联机混合分析处理

数据模型

星型模式
- 星型模式是一种多维表结构，它一般由两种不同性质的二维表组成
  - 事实表（fact table）：它存放多维表中的主要事实，我们称其为量（Measure）
  - 维表（Dimension Table）：用以存放多维表中的维成员的取值
- 一般一个n维的多维表往往有n个维表和一个事实表，它们构成了一个星形结构，因而称其为星型模式
雪花模式
- 雪花模型是对星型模型的维表进一步层次化，原来的各维表可能被扩展为小的事实表，形成一些局部的“层次”区域
- 优点：最大限度地减少数据存储量，使维表尽可能地规范化
- 缺点：执行查询需要更多的连接操作，可能会影响查询性能

数据立方体

数据仓库的数据模式通常可以看成是定义在多个数据源上的数据视图，其中存储的分析型数据通常是一些经过统计而获得的综合性数据
为了提高对统计信息的查询速度，我们可以预先计算好数据视图中的统计信息并保存在数据仓库中，这称为 “物化视图”，即将虚的视图转变成实际的视图。
存放物化视图的三维数据模型叫“数据立方体“

数据超立方体

大于等于四位，称为”数据超立方体“

多维数据分析

定义

多维分析是指对以多维形式组织起来的数据采取***切片、切块、旋转、钻取等各种分析动作，以求剖析数据，使最终用户能从多个角度、多个侧面地观察数据*，从而深入地了解被包含在数据中的信息、内涵。

基本操作

切片（Slice）
- 根据某一维上的某个维成员值选择统计数据进行分析
切块（Dice）
- 根据某一维上的某个维成员取值的区间选择统计数据进行分析
- 根据多个维度上的维成员取值的区间选择统计数据进行分析
数据概括（roll up上钻）
- 将多维下标的取值提高到较高的概念层次上，从而形成新的统计查询结果，并进行分析
数据细化（drill down下钻）
- 将多维下表的取值降低到较低的概念层次上，从而形成更细致的统计查询结果，并进行分析

数据仓库设计

设计原则

面向主题原则
- 建立数据仓库的目的
  - 根据数据仓库的目的是面向企业的管理人员，为经营管理提供决策支持信息。因此数据仓库的组织设计必须以用户决策的需要来决定，即从用户决策的主观需求（主题）开始
- 数据仓库中数据的组织方法
  - 为了进行数据分析首先要有分析的主题，以主题为起始点，进行相关数据的设计，最终建立起一个面向主题的分析型环境
  - 在数据库设计中则是以客体（Object）为起始点，即以客观操作需求为设计依据
- 例如：“商品销售”主题
  - 建立目的
    - 管理人员能够在适当的时候，订购适当的商品，并把它们分发到适当的商店中去销售，以提高商品的销售总金额
  - 需要执行的分析操作
    - 分析什么样的商品，在什么样的时间和商店内畅销。即分析商品的销售额与商品类型、销售时间及商店位置之间的变化关系
    - 管理人员将据此决定他们的经营策略
数据驱动原则
- 在数据仓库设计中，由于其所有数据均应建立在已有的数据库基础上，即是从已经存在于操作型环境中的数据出发进行数据仓库的设计，这种设计方法称为“数据驱动”方法
原型法设计原则
- 数据仓库系统的原始需求不明确，且不断变化与增加，开发者最初并不能确切了解到用户明确而详细的需求，用户所能提供的无非是需求的大方向或部分需求，更不能较准确的预见到以后的需求
- 因此，采用原型法来进行数据仓库的开发是比较合适的，即从构建系统的基本框架着手，不断丰富与完善整个系统

设计步骤

系统规划

明确主题
- 在数据仓库设计的开始，首先要做的事是有关分析人员需要确定具体领域的分析对象，这个对象就是主题。主题是一种较高层次的抽象，对它的认识与表示是一个逐步完善的过程。因此，在开始时不妨先确定一个初步的主题概念以利于工作的开始，此后随着设计工作的进一步开展，再逐步扩充与完善（原型设计法）
技术准备

概念设计

确定系统边界
确定主要的主题及其内容
OLAP等分析应用的设计

一般将数据划分为：详细数据、轻度总结、高度总结三种粒度，或者采用更多级的粒度划分方法

逻辑设计

将E—R图转换成关系数据库的二维表
定义数据源和数据抽取规则
在逻辑模型的设计过程中，需要考虑以下问题
- 适当的粒度划分
- 合理的数据分割策略
- 定义合适的数据来源

物理设计
数据仓库生成
数据仓库的运行与维护

物理模型设计

在逻辑模型设计基础上确定数据的存储结构、确定索引策略、确定存储分配及数据存放位置等与物理有关的内容，物理模型设计的具体方法与数据库设计中的大致相似。其目的是为了提高数据仓库系统的访问性能，一些常用的技术有：
- 合并表
  - 在常见的一些分析处理操作中，可能需要执行多表连接操作。为了节省 I/O 开销，可以把这些表中的记录混合存放在一起，以减低表的连接操作的代价。这样的技术我们称为合并表。
- 建立数据序列
  - 考虑创建一个数据数组，这样如果数据存放在一行中，那么一次 I/O 就足以检索到了。通常当数列中值的数量稳定、数据是按顺序访问的、数据的创建与修改在统计上是以非常有规律的方式进行等条件都满足时，创建一个数组才是有意义的
- 引入冗余
  - 在面向某个主题的分析过程中，通常需要访问不同表中的多个属性，而每个属性又可能参与多个不同主题的分析过程。因此可以通过修改关系模式把某些属性复制到多个不同的主题表中去，从而减少一次分析过程需要访问的表的数量
- 表的物理分割
  - 对于访问频率较高的属性，可以单独考虑其物理存储组织，以便选择合适的索引策略和特定的物理组织方式
  - 对于需要频繁更新的属性，也可以单独组织其物理存储，以免因数据更新而带来的空间重组、重构等工作。
- 生成导出数据
  - 在原始、细节数据的基础上进行一些统计和计算，生成导出数据，并保存在数据仓库中
  - 避免在分析过程中执行过多的统计或计算操作，减少输入/出的次数，提高分析操作的性能
  - 避免了不同用户进行重复统计操作可能产生的偏差
- 建立广义索引
  - 用于记录数据仓库中数据与 “最” 有关的统计结果的索引被称为 “广义索引”
  - 可以在每次进行数据仓库数据加载工作时生成或刷新这样的广义索引。用户可以从已经建立的广义索引里直接获取这些统计信息，而不必对整个数据仓库进行扫描
规范化/反规范化

数据仓库生成

建立数据模式
编制数据抽取城区
数据加载

数据仓库的生命周期

20191230183925

多维建模

事实表

事实表是维度建模的核心和基本表
每一事实表都对应着一个或若干个“度量值”
- 度量值是事实表的核心，也是趋势分析的对象
- 通过事实表来记录维度值与度量值之间的关系
事实表中的一行对应一个度量值
- 事实表中的所有度量值必须具有相同的粒度
- 粒度划分：事务、周期快照、累积快照
最常用的度量值：数值类型
三种类型的度量值
- 可做加法运算
- 可沿着某些维度做加法运算
- 不能做加法运算：计数统计、计算平均值、取样统计
很少采用文本形式的度量值
度量值通常是一个可以连续取值的量
每个事实表都有两个或两个以上的外关键字
- 通过外关键字建立事实表与维表之间的联系，从而可以通过维度表来存取事实表中的度量值
- 可以由外关键字的组合构成事实表的主关键字

维度表

维度表是事实表的入口，为用户提供了使用数据仓库的接口
维度表中的维度属性通常用于定义事实表上的查询条件，也可作为定义报表和统计查询的“列”
维度表的定义通常包括
- 尽可能多的列
- 相对少的行（相对于事实表）

维度建模的设计过程

选取要建模的业务处理过程（分析型）
- 分析需要
定义业务处理的粒度
- 事实表中每一行的度量值的取值粒度
选择事实表中的维度（事先已建立）
选择事实表中的度量值
- 以分析对象为依据
- 可以有多个度量值
通过计算而获得的可加性度量值也应该物理存储在事实表中，如：毛利润金额
不具有可加性的结果则应该由数据存取工具在访问过程中进行计算，如：毛利润率、单价

退化维度

维度表为空，具体的维度值直接存放在事实表中

维度的规范化处理

规范化	非规范化
雪花模型	星型模型
复杂的表关系	简单的表关系
节省存储空间	记录之间存在数据冗余
连接的复杂，高开销	连接简单，低开销
低维度浏览能力	高维度浏览能力
不支持物理加速技术	支持物理加速技术

代理关键字，避免使用操作型数据作为维度表和事实表的主关键字和外关键字

可以缓冲操作型数据的变化对数据仓库的影响
性能优势
操作型数据可能无法作为关键字
日期维度的特殊要求
历史一致性

值链

由企业的关键业务组成
值链确定了企业主体活动的自然逻辑流程

三种互补的库存模型

周期库存快照
- 定时生成每种商品的库存水平
库存事务
- 记录影响库存水平的主要因素
- 商品的进/出仓库等事务
库存累计快照
- 记录每件商品的分发历史，直至其离开仓库为止

商品的库存事实表与销售事实表的区别

销售事实是稀疏的，而库存事实是稠密的
- 在销售事实表中记录每天实际发生的商品销售情况
- 而库存事实表则需要记录每天、每种商品、在每个商场的库存情况（不管是否发生了实际的销售）
解决办法
- 随着时间的推移可降低快照的频度
  - 最近60天内的以天为粒度的周期快照
  - 最近3年内的以周为粒度的周期快照

半加型事实（Semiadditive Facts)

只在部分维度上具有可加性的度量值被称为“半加型事实”
在商品营销中，绝大部分的度量值在所有的维度范围内都具有极好的可加性
在库存快照模型中，“库存量”可以跨“产品”或“商场”进行汇总（具有可加性），但不具有跨“日期”的可加性

几种半加型事实

库存数量、银行账户余额、温度、水位、含量。。（都跟时间有关。。。。随口bb）
用于记录静态水平的度量值在跨日期维度以及可能的其他维度范围内都是不可加的（bb的对的）
- 对于不可加的度量值，可用的聚集方法如：平均统计
- 不能简单地利用sql中的avg函数来完成这样的平均统计工作
- AVG_DATE_SUM

数据仓库总线结构

一种可以按增量开发方式分布建造企业数据仓库的方法

计算机中的总线
通过为数据仓库环境定义标准的总线接口，独立的数据集市就可以由不同的开发小组在不同的时间进行实现。只要遵循这个标准，独立的数据集市就可以插入到一起并有效地共享

数据仓库总线矩阵

矩阵的行：对应着数据集市
- 如果数据来源不同，处理功能不同，或者矩阵代表的内容无法在单个迭代过程中合理完成，就应当创建独立的矩阵行
矩阵的列：对应着共享的公共维度

一致性维度

一致性维度是进一步开发总线结构数据仓库的基础
一致性维度
- 要么是同一的，要么是具有最佳粒度与细节性的维度在严格数学意义上的子集
- 一致的维度具有如下特征
  - 一致的维度关键字
  - 一致的属性列名字
  - 一致的属性定义
  - 一致的属性值
一致的维度可能意味着是相同的维度表
- 与它们相连的事实表具有完全相同的内容（不同的度量值），例如：
  - 连接到销售事实表与库存事实表上的日期维度表是同一的，意味着销售事实表和库存事实表中的内容是相同的
- 这样的维度表在物理上可能是同一张表，也可能是不同的表，但他们应该具有相同数目的行、相同的关键字、相同的属性标签、相同的属性值

原子型维度

在最佳粒度层次上的维度定义（最小的粒度）

堆积维度（roll up dimensions）

在较高层次上的维度定义（较大的粒度）
- 每日快照 vs. 每周快照
如果堆积维度是基本层次上原子型维度严格意义上的子集，则堆积维度与原子型维度保持一致

一致性事实

同样的事实在不同的数据集市进行存储的一致性
- 取值单位的一致性
- 值的一致性
- 自然关键字的一致性
一般来说，事实表数据不再多个数据明确地进行拷贝
如果事实表存在与多个数据集市，那么支撑这些事实的定义和方程必须是相同的
如果无法使事实完全保持一致，那么应该对不同的解释给与不同的名称

日期维度的角色模仿

后台只维持一个单一的日期维度表
为事实表中的每一个日期外关键字建立一个日期维度表上的视图
优点：降低存储开销，方便使用

三种类型事实表的比较

特征	事务粒度	周期快照粒度	累积快照粒度
代表的时间段	时间	规律性可预见间隔	不确定时间跨度，一般是短期
粒度	每个事务一行	每段一行	每个生命期一行
事实表加载	插入	插入	插入与更新
事实行更新	不重新存取	不重新存取	行为发生任何时候都要重新存取
日期维度	事务发生日期	时间段终止日期	标准环节的多个日期
事实	事务活动	预定时间间隔的性能	给定生命期的性能

三种不同类型的实时分区

事务粒度——当前的记录（并非统计结果）
周期快照——最近一个周期内的统计结果（对非/半加性事实的考虑）
累积快照——只记录最近被更新的项

支架维度

将一组低基数属性单独构成客户维度的一个维度（称为支架维度），从而使整个模型呈雪花状
支架维度中的数据一般是从外部数据提供者那里获得的
- 如：县人口统计支架维度
使用维度支架的好处
- 客户维度与支架维度具有相差悬殊的粒度
- 具有不同的管理与加载次数
- 可以节省客户维度表的存储空间
- 如果用户的查询工具坚持使用星型结构，那么可以通过视图定义来隐藏纬度值加

在数据仓库的维度模型中，部分维度属性是会随时间而发生变化的，若只是将这些变化的维度属性值作简单的修正，即在维度表中只保留该维度属性的当前值，这会直接影响到对事实表中该维度属性所对应的事实数据元组的访问，特别是无法根据维度属性值的变化情况来进行分析处理