商务智能复习提纲（三）
跳转链接
数据仓库的设计
数据仓库设计的由来
类似于在事务型数据处理中需要做数据库设计，需要在分析型数据处理中做数据仓库设计，所以很多思想是可以使用的，但是设计方式还是有着区别。
建造数据仓库主要由两部分，一个是与操作型系统结构的设计（ETL），另一个是数据仓库本身的设计。
OLTP的需求是清晰的，但是数据仓库的需求是开始使用之后才知道，所以无法使用传统的需求驱动的方式进行。
操作型数据库 VS. 数据仓库
面向的处理类型不同
面向应用 vs. 面向分析
面向的需求不同
确定的应用需求 vs. 不确定的分析需求
系统设计目标不同
事务处理性能 vs. 全局一致的数据环境
数据来源或系统的输入不同
事务相关数据 vs. 多种多样
系统设计的方法和步骤不同
SDLC（系统生命周期） vs. CLDS
数据仓库的设计原则
由于数据仓库的特性（面向主题的、集成的、非易失、时变的），有一下三个原则：
面向主题原则
建立数据仓库的目的
一般面向管理人员或者是提供决策支持，所以组织设计以用户需要来确定。
数据仓库中数据的组织方法
数据仓库以主题为设计依据，最终要建立起一个面向主题的分析型环境。
数据库设计中则是以客体为起点，以客观操作需求为设计依据。
数据驱动原则
数据来源是已有数据加工而来的
数据仓库是在数据库基础上开发的，注重ETL，分析，挖掘，提供决策支持
因为数据都是已有的，所以一定是从操作型环境出发， 这叫做数据驱动。
会对数据的联系进行重新考察
原型法设计原则
不断变化的分析需求
由于数据仓库的原始需求不明确，一直会发生变化且会增加，所以需要使用原型法来进行数据仓库的开发，从基本框架着手不断丰富与完善整个系统。
逐步求精的设计过程
开发过程中不断地对数据仓库进行完善，需求也会不断增加，需要协同合作，保证工作效率
启发方式
开发过程中会出现迭代，根据用户反馈修改数据，反馈的过程贯穿于数据仓库的整个开发生命周期之中。
需求预测依然十分重要，实际情况通常介于启发和预测两者之间。
从操作型数据开始
数据从操作型环境移入到数据仓库环境不是简单的抽取，通常这些数据缺乏集成，建立操作型应用是没有考虑过集成问题，每个应用都拥有自己的需求，导致相同的数据以不同的名字出现在各地方，不同的数据以相同的名字出现在不同的地方。
从操作型环境到数据仓库有三种装在工作：
- 装载档案数据
- 装载操作型系统中已有的数据
- 装载变化（更新）描述符或者文件到数据仓库中。
还要考虑到存取操作型数据的效率
数据量的管理（数据集成、多粒度、数据转储）
过程/数据模型与设计环境
过程模型（仅适合操作型环境）
- 功能分解
- 第零层上下文图标
- 数据流图
- 结构图标
- 状态转换图
- HIPO图
- 伪代码
数据模型（两者都适合）
数据模型的性质
- 稳定性分析，根据各个数据数据行的变化特性将这些属性分组
- 根据稳定成都讨论逻辑优化物理优化及ETL设计等。
数据模型与迭代开发
强烈推荐进行迭代开发（业界成功记录推荐），在第一次迭代成功之前用户很难提出清晰的需求。
数据模型在每一遍开发中都起着路标的作用，在开发结束时，所有遍次的开发结果融合在一起。
数据仓库设计的三级数据模型
概念模型
为一定目标设计系统、收集信息而服务的概念型工具，是客观世界到机器世界的一个中间层次
逻辑模型
- 描述了数据仓库的主题的逻辑实现
- 关系模型
物理模型
逻辑模型在数据仓库中的实现
高级模型
- 对数据的抽象程度最大
- ER图
中极模型
数据项
低级模型
物理数据模型
数据仓库的设计步骤
系统规划
明确主题
数据仓库设计的开始就是要明确主题，这是一个比较高层次的抽象，对他的认知和表示是一个逐步完成的过程（原型设计法）。
技术准备
准备技术以及物理实现环境。
技术评估数据仓库的性能指标（数据存取能力、模型重组能力、数据装载能力）
准备计算机、网络结构、操作系统、数据库、数据仓库软件。
概念设计
确定系统边界
- 要做的决策类型有哪些？
- 决策者感兴趣的时什么问题？
- 这些问题需要什么样的信息？
- 要得到这些信息需要包含哪些数据源？
确定主要的主题及其内容
- 确定主要的主题（明确分析对象，对每个主题的内容进行详细描述）
- 在确定上述内容后可以用传统的实体联系模型（ER）来表示数据仓库的概念数据模型。
OLAP等分析应用的设计
PPT中无相关内容
逻辑设计
在这个步骤将ER图转换成关系数据库的二维表
定义数据源和数据抽取规则
粒度划分
一般将数据划分为：详细数据、轻度总结、高度总结三种粒度，或者采用更多级的粒度划分方法
粒度划分将直接影响到数据仓库中的数据量以及所适合的查询类型，会影响仓库的性能。
举一个例子，用于商场管理者的数据仓库：
| 主题名 | 公共键码 | 属性信息 |
|---|---|---|
| 商品 | 商品号 | 固有信息：商品号，商品名，类别，颜色等 采购信息：商品号，供应商号，供应价，供应日期，供应量等 销售信息：商品号，顾客号，售价，销售日期，销售量等 库存信息：商品号，库房号，库存量，日期等 |
| 供应商 | 供应商号 | 固有信息：供应商号，供应商名，地址，电话，供应商类型等 供应商品信息：供应商号，商品号，供应价，供应日期，供应量等 |
| 顾客 | 顾客号 | 固有信息：顾客号，姓名，性别，年龄，文化程度，住址，电话等 购物信息：顾客号，商品号，售价，购买日期，购买量等 |
数据分割
把逻辑上是统一整体的数据分割成较小的，可以独立管理的数据单元进行存储，便于重构、重组和回复，提高创建索引和顺序扫描的效率。（常用时间作为分割）
选择数据分割的因素有
- 数据量的大小
- 数据分析处理的对象（主题）
- 简单易行的数据分割标准
- 数据粒度的划分策略
类似于数据库的分片，目的是提高数据仓库性能。
定义数据来源
物理设计
具体方法和数据库设计中的大致相似，目的是为了提高数据仓库系统的访问性能。
常用的技术有：
- 合并表
- 建立数据序列
- 引入冗余
- 表的物理分割
- 生成导出数据
- 建立广义索引
合并表
分析处理操作中需要执行表的连接，为了节省开销，直接将记录混合存放，和数据库中的集簇技术类似
数据序列
创建一个数据序列则一次IO就可以检索，但是需要数列中的值数量稳定、数据按序访问、数据的创建和修改在统计上以非常有规律的方式进行。
引入冗余
分析过程有时需要从不同的表访问多个属性，每个属性又能在不同分析过程中使用，所以将某些属性复制到主题表中去减少访问的表的数量
使用这种方式会有大量的数据冗余，必须保持数据一致性。数据仓库的数据更新比较少，开销较小，所以可以有效提高性能。
表的物理分割
类似于逻辑设计阶段的数据分割，根据表中的数据访问频率和稳定性程度对表的存储结构进行分割。（高频访问、更新的属性单独存储）
生成导出数据
在一些细节数据的基础上进行一定的计算和统计，将结果直接保存在数据仓库中，避免分析过程中过多的统计以及不同用户统计的偏差（过于简单，不给图了）
建立广义索引
用于记录数据仓库中与“最”有关的统计结果的索引被称为广义索引，数据量非常小，用户直接访问迅速，不再需要对整个仓库进行扫描（过于简单，一样没图）
数据仓库生成
- 建立数据模式
- 编制数据抽取程序
- 数据加载
数据仓库的运行和维护
建立数据仓库之后就可以直接运行分析、决策性应用系统，使用过程中不断加深理解，改进主题（原型法设计），随着数据源的数据的变化刷新数据仓库的数据，保证数据的一致性
数据仓库的生命周期
数据仓库的设计/生成和运维
数据仓库设计案例一
维度建模中的基本概念
事实表
维度建模的核心和基本表
每一事实表都对应着一个或若干个度量值
度量值是事实表的核心，也是趋势分析的对象
通过事实表来记录纬度值与度量值之间的关系
事实表中的一行对应一个度量值
- 事实表中的素有度量值必须具有相同的粒度
- 粒度划分模型：事务，周期快照，累计快照
事实表中的度量值常用数值类型，很少使用文本
每个事实表都有两个及以上的外关键字（FK）
维度表
维度表是事实表的入口，为用户提供使用数据仓库的接口。
维度表中的维度属性通常用于定义事实表上的查询条件。
维度表的定义要尽量多的列和尽可能少的行
维度表通常是文本数据或者是离散数据
尽量少使用编码属性
度量值属性可以参与统计运算，唯独属性一般是离散的，很少发生变化
维度的规范化处理
| 规范化 | 非规范化 |
|---|---|
| 雪花模型 | 星型模型 |
| 复杂的表关系 | 简单的表关系 |
| 节省存储空间 | 记录之间存在数据冗余 |
| 连接的复杂，高开销 | 连接简单，低开销 |
| 低维度浏览能力 | 高维度浏览能力 |
| 不支持物理加速技术 | 支持物理加速技术 |
数据仓库设计案例二
值链
- 由企业的关键业务组成
- 确定了企业主体活动的自然逻辑流程
- 每一步业务处理都产生那个大量的周期性事务记录
- 决策支持系统的目标是监控关键处理过程的性能结果
事实表粒度模型
有三种互补的粒度模型
库存周期快照（粒度最大）
定期生成每种商品的库存水平
库存事务模型（粒度最小）
记录影响库存水平的主要因素
库存累计快照（适中）
记录每件商品的分发历史，直至其离开仓库
数据仓库的总线结构
- 一种可以按增量开发方法分布建造企业数据仓库的方法
- 一组综合的具有一致性的公共维度
一致性维度
- 一致性维度是进一步开发总线结构数据仓库系统的基础
- 一致的维度可能意味着是相同的维度表
- 大多数一致的维度是在可能的最佳粒度层次上定义的
- 原子型维度
- 上钻维度（在较高层次上的维度定义）
- 不同业务处理的事实粒度不同
- 两个处于相同细节层次上的维度表，如果他们均是另一个维表的子集，则它们也是一致的
一致性事实
同样的事实在不同的数据备份中进行存储的一致性
一般说来，事实表数据不在多个数据备份间明确的进行拷贝
如果事实表存在于多个数据备份，那么支撑这些事实的定义和方程必须都是相同的
如果无法使事实完全保持一致，那么应该对不同的解释给与不同的名称
数据仓库设计案例三
事实表的规范化考虑
事实表的规范化是将一张事实表总的多个度量值分解组装成多个事实表，但是一般不会这么做，因为会添加大量的属性以及计算时的连接操作。
如果度量值的计算处于不同的粒度上，那么需要将它们分解。
如果可以将“粗”粒度的度量值分配到“细”的粒度层次上也进行分解。
三种类型事实表的比较
| 特 征 | 事务粒度 | 周期快照粒度 | 累积快照粒度 |
|---|---|---|---|
| 代表的时间段 | 时间点 | 规律性可预见间隔 | 不确定时间跨度，一般是短期 |
| 粒度 | 每个事务事件一行 | 每段一行 | 每个生命期一行 |
| 事实表加载 | 插入 | 插入 | 插入与更新 |
| 事实行更新 | 不重新存取 | 不重新存取 | 行为发生任何时候都要重新存取 |
| 日期维度 | 事务发生日期 | 时间段终止日期 | 标准关键环节的多个日期 |
| 事实 | 事务活动 | 预定时间间隔的性能 | 给定生命期的 性能 |
实时分区
有三种不同类型的实时分区
事务粒度
- 实时分区具有与它的支撑静态事实表具有完全相同的维度
- 可能完全不建立索引
- 避免包含聚集值
周期粒度
- 静态数据仓库事实表具有一个周期粒度，实时分区可以看作是当前的热积月
- 实时分区是当前正在开发的月份的映像，随着月份的推进不断更新。半加性或全加性事实随报表不断调整
- 月份结束时累计起来的实时分区，作为最新月份加载到静态仓库
累计快照
- 静态数据仓库事实表采用累计快照时，实时分区仅仅包含当天更新的分列项
- 当天结束时，实时分区包含了需要写到主要事实表上的记录的最新版本
- 无需索引和聚集
数据仓库设计案例四
维度表的划分：稳定维度、渐变维度、快变维度。
渐变维度
类型1：改写属性值
直接改变属性值
容易实现，但不能对旧属性值的任何历史数据进行维护
类型2：添加维度行
同名的情况加添加一个新的关键字用于记录新值
- 准确跟踪渐变属性的主要方法
- 引入新的行用来反映新的属性值
- 增加了唯独行的膨胀
- 可以引入生效或者截止日期
类型3：添加维度列
- 使用维度列保存旧的属性值
- 不适合跟踪唯独属性大量变化
类型6：1+2+3
快变维度
微型维度
将分析频率高或变化频率大的属性拆成独立的微型维度（例如：客户维度中的年龄，性别，收入水平等属性，它们的每一种取值组合构成微型维度表中的一行）
预设波段
对于诸如收入与购买总额等不断变化的属性，应该被转换成呈波段分布的范围，即进行离散化处理，使其只能在数目相当小的离散值中取值，以减少维度表中的数据量
体系桥接连表样本行
体系桥接连表样本行数计算公式：每层的取值数据 * 层深度（从顶层开始计数）然后将乘积相加起来。
数据挖掘
有没有懂哥告诉我这个考不考。
