设计数据仓库
数据仓库基础笔记思维导图已经整理完毕，完整连接为：
数据仓库基础知识笔记思维导图
建造数据仓库只要包含两个部分的工作：
- 与操作型系统接口的设计
- 数据仓库本身的设计
数据仓库需求只有在已经装载部分数据并开始使用时才能弄清楚
数据仓库是在启发方式下建造的
从操作型数据开始
- 集成
- 性能
- 数据从操作型环境到数据仓库时要经历时基变化
- 对数据仓库中已有的以及要传入的数据规模进行管理
- 数据在抽取和进入数据仓库时要进行压缩，否则数据仓库的数据量就会失控
操作型数据集成
从多处抽取操作型数据，经过无数细节编程，并进行一致性处理。
集成数据遇到的问题
- 数据编码不一致
- 数据度量单位不一致
- 字段语义转换
- 原有的数据在不同的DBMS下可能以多种不同格式存储
- 访问现有数据系统的效率
集成数据的工作类型
- 装载档案数据
- 装载操作型数据库现有数据
- 将上次数据仓库刷新以来操作型环境不断发生更新从操作环境装载到数据库来
数据仓库刷新技术
- 扫描在操作环境中那些被打上时间戳的数据
- 扫描增量文件
- 作为事务处理的副产品产生日志文件或审计文件进行扫描
- 将一个前映像文件和后映像文件进行比较
模型与体系结构化环境
过程建模： 通过过程设计和过程定义来建立过程模型的活动
数据建模：对现实世界各类数据的抽象组织，确定数据库需要管辖的范围，数据的组织、形式等直接转化成现实的数据库
数据仓库与数据模型
过程模型是需求驱动的，不适用于数据仓库
数据模型适应于现有系统环境，也适用于数据仓库环境
建立独立的现有的系统用于数据仓库的数据模型
操作型环境：
- 操作型数据模型等价于企业数据模型
- 数据库设计之前要加入性能因素 数据仓库环境：
- 去除纯粹用于操作型环境的数据
- 关键字结构中增加时间元素
- 导出数据作为公用并只经过一次计算
- 数据关系转变为人工关系
- 稳定性分析
数据仓库的数据模型
数据建模
- 高层建模：实体关系图，ERD
- 中间层建模：数据项集，DIS
- 底层建模：物理建模
高层建模
以实体和关系为特征，直接给出依赖关系，依赖数据最小化，由集成范围设定并规范
高层建模的基本构造
- 实体
- 关系
中间层建模
对高层模型中标识的每个主要主题域和实体，都要建立一个中间层模型。某个主要主题域中间层数据模型扩展后，首先队模型的一部分进行充实，模型的其他部分不变，一直迭代。
中层建模的基本构造
- 主要数据分组：每个主要主题域，有且只有一个，相同属性只存在一次，包含对应主题域的属性和关键字
- 二级数据分组：每个主要主题域，包含存在多次的数据属性，最大数量由可以出现多次不同数据分组确定
- 连接器：表示连个主要主题域之间的数据关系，将两个分组的数据连接起来，在ERD层确定的每一个关系在DIS层必须有与其对应的连接器
- 数据的类型
物理数据建模
物理数据建模步骤
- 扩展中间件层模型，使模型中包含有关键字和物理特性，结果有时称作关系表。
- 进行性能特性优化系数，确定数据的粒度与分区
- 考虑物理IO的使用情况，保证执行一次物理IO能返回最大数据量的记录,这里指的是将那些高访问率的大量记录批量传入的一种非常复杂的机制。
数据建模与迭代开发
迭代开发的重要性
- 业界成功记录强烈建议这样做
- 最终用户在第一遍迭代开发完成以前不能清晰地提出需求
- 只有实际结果切实而明确时，管理部门才会做出充分承诺
- 必须能很快地见到可见结果
规范化与反向规范化
数据模型处理的输出结果是一系列的表，每个表都包含关键字和属性。常规的数据是大量的表，但是每个表包含少量数据，会对性能造成影响。
优化性能的办法：
- 将物理表进行合并，使得IO代价最小化：设计人员需要设计一种健全的策略来合并物理表
- 创建数据数组：只有当数列中值的数量稳定，数据是按照顺序访问、数据的创建与修改在统计上非常有规律多个条件满足时才有意义
- 有意引入冗余数据
- 当访问率相差悬殊时，对数据做进一步的分离
- 创造索引或者创造性概要文件
- 参照完整性的管理
参照完整性
若属性或属性组F是基本关系R的外键，它与基本关系S的主键Ks相对应（基本关系R和S不一定是不同的关系），则对于R中的每个元组在F上的值必须为：
（1）空值，F的每个属性值均为空值。
（2）S中某个元组中的主键值（主码值）。
即参照的关系中的属性值必须能够在被参照关系找到或者取空值，否则不符合数据库的语义。在实际操作时如更新、删除、插入一个表中的数据，通过参照引用相互关联的另一个表中的数据，来检查对表的数据操作是否正确，不正确则拒绝操作。
操作型系统数据仓库环境数据表之间的动态链接人工关系，可以单独管理，无需更新，访问效率高
数据仓库中的快照
触发快照的事件
- 对离散活动信息的记录
- 时间
事件触发的快照的基本组成部分：
- 关键字
- 时间单元
- 只与关键字相关的主要数据
- 作为快照过程的一部分被捕获但与主要数据和关键字都无直接关系的二级数据（可选）
元数据
元数据是关于数据的数据
元数据存储的一般记录项
- 程序员所知的数据结构
- DSS分析员所知的数据结构
- 数据仓库的源数据
- 数据进入数据仓库时进行的转换
- 数据模型
- 数据模型和数据仓库的关系
- 抽取数据的历史记录
数据仓库的参照表
数据仓库参照表是指一种用于关联多个数据表的数据结构，它通常是一个具有外键约束的二维表格。数据仓库参照表的主要作用是方便用户进行跨表关联，减少数据查询时的冗余操作，提高数据查询效率。
参照数据应该通数据仓库的其他部分一样，加入时间元素以反映他们的时变特征
参照表设计方法
- 每隔一段时间对整个参照表生成一次快照：简单、高效但是逻辑上不完备
- 在某一个时间起点上，对参照表生成一个快照，并收集一年中所有对参照表的活动：繁重、复杂但是逻辑完备
- 介于前面两个极端之间的设计方案
数据周期
数据从操作型环境中的数据发生改变起，到这个变化反映到数据仓库中所用的时间
数据周期的要求–至少要经历24小时
- 操作型环境与数仓相互之间结合越紧密，技术越昂贵复杂
- 给环境附加了一个限制：不必在数据仓库中做操作型处理，也不必在操作环境中做数据仓库处理
- 在转入数据仓库之间，数据能达到稳定
转换和集成的复杂性
数据从操作型环境到数据仓库环境传递要完成的功能
- 需要实现技术上的变化
- 从操作环境中选择数据非常复杂
- 来自操作型环境中输入的关键字在输出到数据仓库之前往往需要被重建和转换
- 非关键字结构在从操作环境转移到数据仓库环境时要重新格式化
- 数据在从操作环境转移到数据仓库环境时要进行清理
- 数据传入数据仓库时要进行多数据源合并
- 文件合并之前要先进行关键字解析
- 文件的顺序可能不相同甚至互不相容
- 可能会产生多个输出结果
- 需要提供默认值
- 为抽取过程选择输入数据时，效率通常是一个问题
- 经常需要进行数据的汇总
- 应该队数据元素的重命名操作进行跟踪
- 需要读取的输入记录具有异常或非标准的格式 - 定长格式- 变长记录- 出现不定- 出现子句
- 必须理解并清楚建立在旧的传统程序逻辑语义层次的数据关系。
- 必须进行数据格式的转换
- 必须考虑到大容量输入的问题
- 数据仓库的设计必须符合企业数据模型
- 数据仓库反映的是对信息的历史需求，而操作环境体现对当前信息的即时需求
- 数据仓库着眼于企业的信息化需求，而操作环境则着眼于精确到秒的企业日常事务需求
- 必须考虑将要进入数据仓库的新创建的数据输出文件的传输问题
- 等等其他问题
操作环境数据集成过程自动化结束
抽取/转换/装载（ETL）软件
- 产生源代码的软件：强大
- 产生参数化的运行时模块软件：需要首先对原有数据格式进行统一
抽取/装载/转换（ELT）软件
在转换时可以引用大量数据，但是它试图抽取和装载数据而跳过转换过程，这个操作显著减少了数据仓库的价值。
ETL的需求与步骤
ETL的主要过程参考:
- 决定数据仓库中需要的所有目标数据
- 决定所有数据源，包括外部和内部
- 准备从源到目标数据元素的数据映像关系
- 建立全面的数据抽取规则
- 决定数据转换和清洗规则
- 为聚集表制订计划
- 组织数据缓存区域和检测工具
- 为所有的数据装载编写规程
- 维表的ETL
- 事实表的ETL
ETL的关键因素
- 数据抽取转换的复杂度，主要原因是源系统上的差距
- 数据装载功能，无论是最初的装载还是定期的刷新，大量数据刷新都会带来困难，不是因为复杂性，而是因为装载工作本身的时间过长
数据抽取
首先，你必须从很多不同的系统中抽取数据。
其次，对于数据仓库来说，你必须根据增量装载工作和初始完全装载的变化来抽取数据。
数据抽取要点:
- 数据源确认，确认数据的源系统和结构
- 抽取方法，针对每个数据源，定义抽取过程是人工抽取还是基于工具抽取
- 抽取频率，对于每个数据源，确定抽取的频率，每天，每星期，每季度等等。
- 时间窗口，对于每个数据源，表示出抽取过程进行的时间窗口
- 工作顺序，决定抽取任务中某项工作是否必须等到前面的工作成功才能开始。
- 异常处理，决定如何处理无法抽取的输入记录
数据源确认
对全部正确数据源的确认，并不是对数据源的简单确认，还要检查个确定数据源是否可以提供数据仓库的值。
数据源确认不是一个简单的过程，它是数据抽取功能中十分重要的第一步，你必须对存储在数据仓库中的每一项信息进行数据源确认，需要大量的时间和复杂彻底的分析工作。
数据源确认，一个逐步的方法
- 列出对事实表进行分析所需要的每一个数据项或事实
- 从所有维度中列出每一个维度的属性
- 对每个目标数据项，找出源系统和源数据项
- 如果一个元素有多个开源，选择最好的来源
- 确认一个目标字段的多个源字段，建立合并规则
- 确认一个目标字段的多个源字段，建立分离规则
- 确定默认值
- 检查缺失值的源数据
数据抽取技术
源系统中的操作数据一般来说，分为两类
- 当前值，源系统中的大多数数据属于这个类型，存储的属性值代表当前时刻的属性值，当商业交易发生时候，这个值就会发生变化，无法预测当前值能持续的时间，以及什么时候会变化。
- 周期性状态，属性存储的是每次发生变化时的状态，在每一个时间点，状态值根据新值有效的时间进行存储，这类数据还包括带有事件发生时的事件
- 立即型数据获取，数据抽取是实时的
- 延缓的数据抽取
周期性状态
装载类型
- 初始装载 从一个特定时间开始的最初数据必须迁移到数据仓库中
- 历史装载 初始装载之后，数据仓库必须保持更新，使变化的历史和状态可以在数据仓库中反映出来抽取数据类型
- 静态数据，给定时间捕获的，像是相关数据源某个特定时刻的快照
- 修正数据，它并不是增加的数据，而是最后一次捕获数据的修正
立即获取型数据
- 通过交易日志捕获
- 从数据库触发器中捕获
- 从源应用中捕获
延缓的数据抽取
- 基于日期和时间标记的捕获
- 通过文件的比较来捕获
数据抽取技术优缺点比较
| 静态数据捕获 | 在源应用程序中的捕获 |通过交易日志捕获|基于日期和时间标记的捕获|通过数据库触发器的捕获|通过文件比较的捕获|
|:--------|:-------------|:-------------|:-------------|:-------------|:-------------|:-------------|
| 灵活性较好 | 灵活性好 |不是那么灵活|灵活性好|不是那么灵活|灵活性好|
|源系统性能不受影响 |对源系统性能有一点影响 |源系统性能不受影响|源系统的性能不受影响|对源系统的性能有一点影响|源系统的性能不受影响|
| 对已有的应用程序不需要修改 |对已有的应用程序有很大修改 |对已有的应用程序不需要修改|很可能会对已有的应用程序有很大修改|对已有的应用程序不需要修改|对已有的应用程序不需要修改|
| 能用在旧的系统中 |能用在大多数的旧系统中 |可以应用在大多数旧系统中|不能用在大多数旧系统中|不能用在大多数的旧系统中|可能可以用在大多数的旧系统中|
| 能用在面向文件的系统中|能用在面向文件的系统中 |不能用在面向文件的系统中|不能用在面向文件的系统中|不能用在面向文件的系统中|可能可以用在面向文件的系统中|
|使用供应商产品，没有内部成本 |因为内部工作带来很高的内部成本 |使用供应商产品，没有内部成本|可能使用供应商产品|需要使用供应商产品，没有内部成本|需要使用供应商产品，没有内部成本|
数据转换，基本任务
- 选择
- 分离/合并
- 转化
- 汇总
- 丰富
主要转换类型
- 数据修正
- 字段的解码
- 计算值和导出值
- 单个字段的分离
- 信息的合并
- 特征集合的转化
- 度量单位的转化
- 日期时间的转化
- 汇总
- 键的重新构造
数据的整和合并
实体识别问题
三个不同时期的旧系统，实体的编码不同，无法确定是同一实体，必须设计复杂的算法来将所有的记录进行匹配。没有任何匹配算法可以完全解决这个问题。
多数据源问题
数据元素拥有多个数据源，存在细微差别
- 两个系统分配优先级
- 根据最新的刷新日期，或者其他字段辅助
如何实施转换
- 使用转换工具
- 使用手工技术
维度表的装载见数据仓库__关系建模与维度建模
事实表，历史与增量的装载
- 确认历史数据对数据仓库有用
- 定义个改进抽取商业规则
- 捕获审查数据，再返回操作型系统
- 执行事实表代理键
- 改善事实表内容
- 数据重构
- 准备装载文件
- 事实表的增量抽取，由新交易构成，由更新交易构成，为了数据捕获使用数据库交易日志
- 事实表的增量装载，尽量频繁地装载，使用分区和文件索引，应用并行处理技术
数据仓库记录的触发
引起数据仓库的数据载入的基本的业务交互活动可以称为“事件-快照”交互。
某个事件触发的数据快照，然后这个快照转移到数据仓库环境中。
事件
- 业务活动产生事件：一个 重要活动的发生
- 时间产生事件：规律性的时间推移标志
快照的构成
- 标志事件发生的事件单元
- 用来标识快照的关键字
- 与关键字相关联的主要、非关键字数据
- 形成快照时偶然捕获并被置入快照中的二级数据
概要记录
产生概要记录的前提，有以下情况一种或多种
- 数据并不满足稳定和不常改变的标准
- 数据量巨大
- 数据经常发生变化
- 业务上并不要求特别详细的历史记录 将操作型数据中许多不同的、详细的记录组合在一起形成一条概要记录，一条概要记录代表了许多条操作型记录 数据仓库中单个活动记录代表了单一的事件，一条概要记录代表了多个事件。
概要记录的形式
- 对操作数据的取值进行汇总
- 对操作数据的单元进行计数
- 对操作数据单元进行处理，找出最高值、最低值、平均值等
- 捕获第一个和最后一个数据
- 度量出处于给定几个参数界限内的数据
- 捕获在一段时间内某一时刻有效数据
- 捕获最老的数据和最新的数据
- 等等。。。没有限制
概要记录为最终用户访问和分析提供了一种紧凑的、方便的数据组织形式。
管理大量数据
- 建立概要记录
- 在建立概要记录的同时，建立历史细节的备用层
- 根据相同的细节创建多个概要记录
- 聚集成一条概要记录的过程通常是在操作型服务器是那个完成的 - 操作型服务器能管理大量的数据- 任何情况下数据都驻留于服务器上- 创建概要记录的过程涉及数据排序和合并的过程，一旦建立快照的过程变得十分复杂冗长时，需要重新考虑是否有必要建立快照
从数据仓库环境到操作型环境
一些非常规情况，数据仓库数据可以回流进数据仓库
数据仓库数据的直接操作型访问
操作型环境直接访问数据仓库时严格的、不能妥协的限制：
- 这个请求必须能够接受冗长的响应时间
- 对数据的请求必须是最小量的
- 管理数据仓库所用到的技术必须与管理操作型环境所用到的技术一致
- 从数据仓库取得的、准备传输到操作型环境的数据必须不做活仅需做最小量的格式化
数据仓库数据的间接访问
数据仓库的一个最为高效的使用方式就是操作型环境访问数据仓库的数据
- 离线计算和分析周期性进行，创建一个小的易于访问的状态表
- 数据仓库环境有一个分析程序不断读入和分析顾客的记录，周期地提供给操作环境一个需要的内容文件
- 定期分析用户行为，使用预处理方式，进行预先操作。
数据仓库数据的间接使用
程序对数据仓库进行定期分析，以检验相关的特征和标准，分析过程将在在线环境中产生一个小文件，其中包含了有关企业业务方面的简明信息
间接使用数据仓库数据时应考虑的几个因素
- 分析程序 - 拥有许多人工智能特征- 可以运行在任何可用的数据仓库中- 在后台运行- 程序的运行与数据仓库发生变化的速度一致
- 周期性刷新 - 不是经常进行- 以一种替代模式操作- 从支持数据仓库的技术传送数据到支持操作型环境的技术
- 在线预分析数据文件 - 每个数据单元仅仅包含少量的数据- 总体上可以包含大量的数据（因为可以有很多数据单元）- 准确地包含在线处理人员所需要的东西- 不被修改，但是以批量方式周期性刷新- 是现在高性能环境的一部分- 访问效率高- 适于访问单个数据单元，而不是大批量数据
星型连接
数据仓库设计绝对是一个适合于使用规范或关系型方法的领域
规范化产生数据仓库最优设计的原因
- 可以带来灵活性
- 很好地适用于粒度化的数据
- 规范方法不是对任何给定的处理需求集合是最优的
- 能很好地与数据模型相匹配
多维方法
多维方法需要的元素：
- 星型连接
- 事实表
- 维多维方法只适用于数据集市，而不适合数据仓库****数据集市在很大程度上是根据需求来形成的，与数据仓库不同。为了建立一个数据集市，首先要对在数据集市上进行处理的需求有很多了解。一旦这些需求已知，可以将数据集市建成一个最优的星型连接结构。数据仓库是为一个非常大的群体服务的，数据仓库对于任何一个需求集合而言，性能和便携性都不是最优的。 数据仓库建立星型连接将是一个错误，因为最终结果是数据仓库在牺牲所有其他群体的利益代价中，对一个群体实现了最优。 用来管理载入数据集市中某个实体的大量数据的设计结构称为星型连接。事实表：星型连接中央的表维度表：事实表周围的其他实体表称为维表 如果非外键的信息经常被事实表使用，那么星型连接内的非外键信息将会伴随外键关系一起存放。 星型连接现象：
- 可以有任意多个外键与维表相关
- 很多情况下，文本数据与数值数据是分开的，事实表装在数字型数据与外键，而维表装在字符型数据。
创建星型连接的好处
- 可以为决策支持系统的处理优化数据，通过预连接数据和建立优选择的数据冗余，设计者大大简化和调整访问和分析的数据
- 如果不是在决策支持系统数据集市环境使用星型连接，则会有很多缺点 数据怎么从数据仓库到达数据集市
- 数据仓库中数据是粒度化的，数据集市中的数据是紧凑和综合的，数据必须周期性地从数据仓库转移到数据集市。与从操作型环境到数据仓库的转移相似
- 必须对数据仓库的数据进行选择，访问，充足才能适合数据集市的需求。
数据集市与数据仓库
- 数据集市中的数据结构是根据部门的特殊需求而建立的
- 任何一个给定的数据集市中的数据结构都与其他数据集市不同
- 每一个数据集市都有不同的数据结构,将数据集市转变成为数仓都不具意义
- 数据集市数据结构,贯穿整个企业,不可重用,没有灵活性,不能作为调和矛盾的基础
支持操作型数据库
操作型数据存储（ODS）有四类：
- 操作性环境到ODS的数据更新时间是同步的
- 操作型环境与ODS的数据更新时间有2~3个小时的间隔
- 操作性环境到ODS的数据更新同步是在夜间完成的
- 数据仓库到这类ODS的更新是不预先规划的
需求和Zachman框架
数据仓库不是由处理需求间形成的,而是根据企业需求而设计的。
企业需求综合地看待对于处理、数据和基础框架的所有需求。
聚集和组织企业需求的最好办法之一是叫做Zachman框架方法。
版权归原作者 墨染丶eye 所有， 如有侵权，请联系我们删除。