第三章 设计数据仓库
2018-12-13 本文已影响11人
晨磊的微博
第三章 设计数据仓库
3.0 概述
- 建造数据仓库的工作
- 操作型系统接口的设计
- 数据仓库本身的设计
3.1 从操作型数据开始（详细说明集成）
- 强调数据进入仓库时必须集成（ETL）不集成时噩梦
- 数据抽取过程中的困难
- 集成的困难
- 编码不一致
- 度量单位不同
- 字段命名不同
- 存储技术不同
- 更新数据同步的困难
- 操作型环境中打上时间戳
- 操作型环境提供增量文件
- 日志文件或审计文件
- 快照对比（噩梦）
- 经历的时基变化
- 数据必须加上时间元素
- 对数据仓库中的数据管理
- 全部压缩
- 集成的困难
3.2 数据/过程模型与体系结构化环境
设计者需要明白过程模型与数据模型的适用范围及局限
- 过程模型：仅适用于操作环境（如数据集市）
- 数据模型：即适用于操作，有适用于仓库环境
3.3 数据仓库与数据模型
- 一般企业数据模型都没有考虑
操作型系统与数据仓库的差别 - 企业数据模型是
操作型数据模型和数据仓库数据模型的起源
数据仓库的数据建模
| 高层建模 | ERD | 集成范围定义模型的边界、多个ERD合成企业ERD |
| 中层建模 | DIS | 每个实体都要建立DIS，主要数据分组（一次），二级数据分组（多次），连接器（实体建的关系），数据的类型（左线父右线子,可以多条线），每个数据分组一般对应一张表 |
| 底层建模 | 物理模型 | 性能优化：数据数组，表合并，冗余，分离，预格式化，预连接等 |
image.png
3.4 数据模型与迭代式开发（一致的数据模型）
数据库必定是迭代式开发（首先搞一部分，然后再另一部分，如此循环）
原因如下：
- 成功案例强烈建议
- 必须快速见到结果
- 第一个迭代后才能提出需求
一致的数据模型
image.png
不一致的数据模型
image.png
3.5 规范化与反规范化
反规范化提高性能，减少IO
- 数据数组：
- 表合并：小表合并为大表
- 冗余：
- 分离：按访问频率分
- 引入预计算：
- 创造性索引或创造性概要文件
- 参照完整性管理：不方便实现
3.6 元数据
-
元数据是关于数据的数据
-
没有元数据，用户首先对仓库进行各种试探，才能确认有哪些数据及没有哪些数据，浪费大量时间
-
元数据处于数仓的上层，与指向数仓内容的索引相似（文档？）
-
元数据一般记录的内容
- 程序员所知的数据结构
- DSS人员所知的数据结构
- 数仓的源数据
- 数据进入数仓时进行的转换
- 数据模型
- 数据模型和数据仓库的关系
- 抽取数据的历史记录
-
数据仓库中的参照表管理(PS:不知为何放到这一章中，Inmon总是这样)
- 感觉类似与 kimball 的缓慢变化维的作用
- 第一种方式：每个某个时间段生成一个快照，简单但不完备
- 第二种方式：历史存一个快照，然后记录每个变化，复杂但完备
3.7 数据周期-时间间隔(数据同步的周期)
- 24小时最好，越少越贵
- 间隔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 算是狠批了多维建模
- 没有原因的直接说多维只适合数据集市，因为数据集市是根据实际需求形成的，所以多维不适合数据仓库
- 这东西就好像在说，牛奶只能早上喝，因为早餐要摄入更高的蛋白质，所以牛奶不适合中午喝
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 框架（但没说怎么用）
