第三章 设计数据仓库

第三章 设计数据仓库

3.0 概述

• 建造数据仓库的工作
  • 操作型系统接口的设计
  • 数据仓库本身的设计

3.1 从操作型数据开始（详细说明集成）

• 强调数据进入仓库时必须集成（ETL）不集成时噩梦
• 数据抽取过程中的困难
  1. 集成的困难
     • 编码不一致
     • 度量单位不同
     • 字段命名不同
     • 存储技术不同
  2. 更新数据同步的困难
     • 操作型环境中打上时间戳
     • 操作型环境提供增量文件
     • 日志文件或审计文件
     • 快照对比（噩梦）
  3. 经历的时基变化
     • 数据必须加上时间元素
  4. 对数据仓库中的数据管理
     • 全部压缩

3.2 数据/过程模型与体系结构化环境

设计者需要明白过程模型与数据模型的适用范围及局限

• 过程模型：仅适用于操作环境（如数据集市）
• 数据模型：即适用于操作，有适用于仓库环境

3.3 数据仓库与数据模型

• 一般企业数据模型都没有考虑操作型系统与数据仓库的差别
• 企业数据模型是操作型数据模型和数据仓库数据模型的起源
  数据仓库的数据建模

3.4 数据模型与迭代式开发（一致的数据模型）

数据库必定是迭代式开发（首先搞一部分，然后再另一部分，如此循环）
原因如下：

• 成功案例强烈建议
• 必须快速见到结果
• 第一个迭代后才能提出需求

一致的数据模型

不一致的数据模型

3.5 规范化与反规范化

反规范化提高性能，减少IO

1. 数据数组：
2. 表合并：小表合并为大表
3. 冗余：
4. 分离：按访问频率分
5. 引入预计算：
6. 创造性索引或创造性概要文件
7. 参照完整性管理：不方便实现

3.6 元数据

• 元数据是关于数据的数据

• 没有元数据，用户首先对仓库进行各种试探，才能确认有哪些数据及没有哪些数据，浪费大量时间

• 元数据处于数仓的上层，与指向数仓内容的索引相似（文档？）

• 元数据一般记录的内容

  • 程序员所知的数据结构
  • DSS人员所知的数据结构
  • 数仓的源数据
  • 数据进入数仓时进行的转换
  • 数据模型
  • 数据模型和数据仓库的关系
  • 抽取数据的历史记录

• 数据仓库中的参照表管理(PS:不知为何放到这一章中，Inmon总是这样)

  • 感觉类似与 kimball 的缓慢变化维的作用
  • 第一种方式：每个某个时间段生成一个快照，简单但不完备
  • 第二种方式：历史存一个快照，然后记录每个变化，复杂但完备

3.7 数据周期-时间间隔(数据同步的周期)

1. 24小时最好，越少越贵
2. 间隔24小时，不必在仓库系统中做操作处理，也不必在操作系统中做仓库处理

3.8 转换和集成的复杂性

本章作者列举了大量ETL时要处理的问题，不罗列了

3.9 数据仓库记录的触发（事件快照与时间快照）

PS ：感觉3.6节的 数据仓库中的参照表管理 应该放到这更合理

• 时间快照：每个某个时间段生成一个快照，简单但不完备
• 事件快照：历史存一个快照，然后记录每个变化，复杂但完备

3.10 概要记录

有时数仓的数据不满足稳定不常改变的标准，如:

• 大量
• 经常变化
• 业务上不要求特别详细的记录

概要记录的多种实现方式：

• 汇总
• 计数
• 求最高、最低、平均等
• 第一个和最后一个
• 给出给定的几个参数界限之内的数据
• 最新，最老

3.11 管理大量数据（感觉Inmon一直在重复）

• 大量细节性数据，可以创建概要记录替代，但会丢失细节（可迭代小步开发，提前发现丢失细节的重大作用）
• 再就是可以存储到便宜设备上

3.12 创建多个概念记录

一句话，可以从一份细节数据中创建多个概念记录

3.13 从数据仓库环境到操作型环境

一句话，可以从仓库传数据到操作型系统

3.14 数据仓库数据的直接操作型访问（少）

限制

• 相应时间慢，可能24小时
• 请求的数据必须最小量（KB）
• 仓库需用到跟操作型环境一样的技术
• 返回的数据必须不做格式化（？）

3.15 数据仓库数据的间接访问（多）

• 提前离线算好历史数据，然后同步给操作型系统访问

3.16 数据仓库数据的间接使用

3.17 星形连接（多维）

观点：在这一章中 Inmon 算是狠批了多维建模

1. 没有原因的直接说多维只适合数据集市，因为数据集市是根据实际需求形成的，所以多维不适合数据仓库
2. 这东西就好像在说，牛奶只能早上喝，因为早餐要摄入更高的蛋白质，所以牛奶不适合中午喝

3.18 支持操作型数据存储

4类操作型数据存储（ODS）

• 从操作型到ODS的数据更新是同步进行
• 从操作型到ODS的数据更新2~3小时间隔
• 从操作型到ODS的数据更新夜间同步
• 从数据仓库到ODS的更新是不预先规划的

3.19 需求和Zachman框架(扎克曼)

从 zachman 框架到数据仓库开发过程

graph LR
A[zachman框架 ] --> B(需求)
B --> C[数据模型]
C --> D[数据仓库]

3.20 小结

• 设计数据仓库优先设计一致性数据模型，然后根据一致性模型进行迭代式开发
• 开发时注意物理表的反规范化（非3NF），集成，元数据管理，快照表和概要表等问题
• 本章还对维度建模做了介绍，维度模型只适合数据集市（但没说明原因）
• 最后还提到了 zachman 框架（但没说怎么用）