数据仓库工具箱

第1章 维度建模初步

1. 操作型系统与数据仓库

任何机构的信息以操作型系统的记录和数据仓库两种形式存在

  • 操作型系统:存入数据的地方,按一次一条记录的方式存入格式化数据并不断重复;
  • 数据仓库:索取数据的地方,从事对新订单计数等需要搜索大量的记录并压缩成几个答案的操作;

2. 数据仓库的目标

  • 使组织结构的信息变得容易获取:让业务人员能对仓库中的数据进行切割处理的分离与合并操作;
  • 一致地展示组织机构的信息:关于数据仓库的所有定义对于用户都是共同的;
  • 具有广泛的适应性和便于修改:如果对仓库的描述性数据进行修改,必须考虑这种修改是否恰当;
  • 发挥安全堡垒作用以保护信息资产:必须有效地控制对机构机密信息的访问;
  • 在推进有效决策方面承担最基本的角色:数据仓库有且仅有一个正确的输出——由数据仓库提供的依据而制定的决策;
  • 为业务群体所接受的前提是被认定是成功的:业务用户除了是数据仓库的处理简化外,别无所求。

3. 数据仓库管理人员工作职责

  • 在业务范围、工作职责和计算机性能等方面多为用户考虑;
  • 确定业务用户在数据仓库帮助下想要做出什么样的决策;
  • 标定那些使用数据仓库进行效能高而作用大的决策制定的“最佳”用户;
  • 寻找潜在的新用户并让他们了解数据仓库;
  • 选取从机构海量数据中挑出的最有效和最富有实际意义的数据子集并在数据仓库中进行展示;
  • 适应用户对相关处理概况的感性认识,将用户接口和应用做得简单并且是模板驱动的;
  • 跨部门一致性地标注数据,确保数据是准确的、可信的;
  • 持续不断地对数据的准确性和提交报告的内容进行监控;
  • 搜罗新的数据来源,持续不断地调整数据仓库以适应数据概况的修改、需求支持和业务优先权地调整等方面的需要;
  • 抽取一部分在使用数据仓库进行业务决策方面具有良好声誉的实现,并用这些成功的例子对人员、软件和硬件设备与选购是否合理做出评判;
  • 按通行的方式发布数据;
  • 维持业务用户的信任;
  • 让业务用户、经理和老板都满意

4. 数据仓库的基本组成

1. 操作型源系统

  • 操作型源系统是获取行业事务的记录(形式的)操作型系统;
  • 一般情况下,只能对源系统转发过来的数据内容及其格式施加少量的控制,所以可以将源系统视为数据仓库以外的部分;
  • 对源系统进行的查询是小范围内一次一条记录的查询,查询的内容是一般事务流量中的一部分,且严格限制在针对操作型系统进行的请求方面;
  • 如果有一个性能好的数据仓库,源系统可以将重现旧内容方面的事情交给数据仓库来完成;
  • 在**企业应用一体化(EAL)**方面,若将源系统按一致的视角设计,能简化数据仓库的设计

2. 数据聚集环节

  • 数据聚集环节包括存储环节和**析取、转换、加载(ETL)**的一组处理过程;
  • 数据聚集环节的关键性结构要件,要不受行业用户的约束以及不必提供查询和展示服务;
  • 析取析取操作进行读解释源数据,并将数据仓库所需要的数据复制到聚集环节再做进一步处理;
  • 数据被析取到聚集环节后,可能进行:1、数据的清理(更正拼写错误、消除定义冲突、补充丢失元素、析构标准格式);2、多源数据的组合;3、重复数据的去除;4、仓库关键字的分配等大量的转换操作;
  • 在数据转载到展示环节即进行查询和报表服务之前,将还没有或者已经处理过的数据实例化为物理的规范化结构形式,这种规范化结构形式称为企业数据仓库(EDW)
  • 数据聚集环节主要进行分类和排序等活动,一般基于平面文件系统;若数据以第3范式关系的形式提供给数据仓库聚集环节,数仓管理人员可能会为了使清理和转换工作更方便而使用规范化。但在数据聚集环节就规范化数据库,就意味着数据要被析取、转换和加载两次——一次用于规范化数据库,另一次针对维度模型,开销较大,假如规范化结构还不存在的话可以试着用其他方法;
  • 可以为支持聚集过程而创建一个规范化数据库,但规范化结构必须远离用户查询(因为规范化结构会对可理解性和性能造成损害);
  • 默认情况下,规范化数据库会被排除在展示环节之外,展示环节应该被严格限定是维度的,同时还要考虑查询和展示服务;
  • ETL环节的最后步骤始终是数据加载,即将维度表提供给数据中心,然后数据中心对新到的数据进行索引从而提供更好的查询性能;
  • 数据的发布过程包括:1、出现在任何维度中的变化性质的通信;2、引入到度量值或者运算事实中的新设想的通信。

3. 数据展示环节

  • 数据展示环节是进行:1、数据组织、存储;2、向用户、报表撰写和其他分析型应用提供直接查询操作的场所,是业务群体通过数据存取工具所看到和接触到的一切;

  • 展示环节的注意点

    • 数据应以维度形式进行展示、存储和访问,维度模型是为数据仓库用户提交数据的最可行的技术手段;
    • 实现可理解性:用某种具体而可行的方法将事务抽象为一组数据的能力;
  • 维度建模与第3范式(3NF)建模不同:3NF建模是一种以消除数据冗余为追求目标的设计技术(数据被划分成多个离散的实体,而每个实体形成关系数据库中的一个表)

  • 实体关系图(ER图/ERD):为描述表格间关系所绘制的一些方框和线条,为区分3NF模型,通常将3NF模型称为规范化模型

  • 3NF模型和维度模型都包含连接关系表,因而都可以用ERD表示,不同在于规范化进行的程度;

  • 规范化建模能够提高操作型处理性能,因为更新或者插入事务处理仅仅需要接触一个地方的数据库,但会复杂化数据仓库的查询(同理数据库管理系统RDBMS也不能高效率地查询规范化模型),所以尽量不要在展示环节使用规范化建模

  • 维度建模解决了规范化建模在展示环节的复杂性,因为维度建模包含与规范化模型相同的信息,但采用一种将设计目标以某种形式对数据进行封装,这种形式通常需要考虑用户的易理解性、查询的高性能和修改的灵活性等方面;

  • 展示环节要求数据中心必须包含详细的原子数据,其能够经受住来自无法预期的特殊用户的查询攻击;

  • 展示环节需要存放具有最细微粒度的数据,以便让用户可以提出一些可能的最为精确的问题;

  • 数据仓库总线结构的基础是所有数据中心必须采用共同的维度和事实来建造,即要求所有数据中心是一致的;

  • 构造分布式数据仓库的关键是使用总线结构,同时数据仓库可查询展示环节的数据必须是维度的、原子的和依附于数据仓库总线结构的;

  • 展示环节的建立基础:

    • 如果展示环节是建立在关系数据库的基础之上的,则这些按维度形式建立起来的表格称为星型图
    • 如果展示环节是建立在维度数据库或者在线分析处理(OLAP)技术基础之上的,则数据就存储在多维表格或称为立方体
  • 维度建模既可以用于关系数据库,又可以用于维度数据库,两个数据库在可辨别的维度方面具有共同的逻辑设计,但在物理实现方面是不同的;

  • 通过不同聚合浏览的使用,多数OLAP立方体都同时起源或归入于关系维度星型方案;

4. 数据存取工具

  • 所有数据存取工具访问的数据都是数据仓库展示环节中的数据;
  • 如建模或者预测工具这样更为复杂的工具,可以将结果逆向上载到数据仓库的操作型源系统或者聚集/展示环节

5. 元数据

  • 元数据指数据仓库环境中除去数据本身之外的所有信息;
  • 数据仓库各组成部分的元数据
    • 操作型源系统元数据
      • 源方案
      • 方便析取处理的书写器
    • 聚集环节元数据(用于引导转换与加载处理)
      • 聚集文件
      • 目标表格布局
      • 转换与清理规则
      • 一致的维度与事实定义
      • 集合定义
      • ETL传输规划
      • 运行日志结果
      • 自定义编程代码
    • 仓库DBMS元数据
      • 系统表格
      • 分区设置
      • 索引
      • 视图定义
      • DBMS级安全方面的特权与授权等项目内容
    • 数据存取工具元数据
      • 确定展示环节的表格及其列项的业务名字与定义
      • 过滤条件
      • 应用模板说明
      • 存取与使用情况统计
      • 其他用户文档资料

6. 操作数据的存储

  • **操作数据的存储(ODS,Operational Data Store)**经常需要更新,并在某种意义上讲就是操作数据的复制集成;
  • 改善性能用的聚合值、重大的历史时刻系列值以及扩展的描述属性等内容,应该被排除在ODS之外;
  • 当**联机事务处理(OLTP,Online Transaction Processing)**不能为“生成操作报表”提供足够的支持时,ODS会提交“生成操作报表”所需的内容;
  • ODS也经常被用于实时交互操作,与“生成操作报表”类似,支持这种实时交互操作的数据查询具有固定的结构形式,还支持从数据仓库获取信息;
  • 在任何场合下,ODS要么是一个处在操作型系统和数据仓库之间的第三方物理系统,要么是一个数据仓库的专门管理热区,但出于成本考虑,普遍采取第二种。

7. 维度建模词汇表

7.1 事实表

  • 事实表是维度模型的基本表,事实代表一个业务度量值;
  • 在各维度值(日期、产品与商品)的交点处可以得到一个度量值(维度值的列表给出了事实表的粒度定义,并确定出度量值的取值范围是什么);
  • 事实表的一行对应一个度量值,但事实表的所有度量值都必须具有相同的粒度;
  • 事实表中最有用的事实是数字类型可加性事实半加性事实仅仅沿某些维度相加,而非加性事实根本就不能相加);
  • 通常将事实描述成是可连续取值的,但应避免文本形式的度量事实,因为文本事实具有像自由文本那样的不可预见性内容,几乎不能进行分析;
  • 数据仓库的设计者应该尽可能将文本度量值转为维度,因为维度能够与其他文本维度属性更有效地关联起来;
  • 不能用代表什么都没有发生的零值来填充事实表,因为这些零会将多数事实表淹没,通常上事实表倾向于具有更少的行和更少的列;
  • 所有事实表粒度都归属于三类之一:
    • 事务(最常见)
    • 周期快照
    • 累积快照
  • 所有事实表有两个或者两个以上的外关键字(用于连接到维度表的主关键字)【如果事实表中的所有关键字都能与对应的维度表中的主关键字正确匹配,则就可以说这些表满足引用完整性的要求】;
  • 事实表通过与之相连的维度表进行存取;
  • 在维度模型中,每个表示多对多关系的表都是事实表,而其他所有的表都是维度表;

7.2 维度表

  • 判断一个从数据生产源析取的数字型数据字段是事实还是维度属性,可以看该字段是一个含有许多的取值并参与运算的度量值(当事实看待),还是一个变化不多并参与作为约束条件的离散取值的描述(当维度看待)【例如产品的标准成本由于可能经常改变,所以应该当作事实处理】
  • 维度表倾向于缩短行数而增加列数;
  • 不同于事实表,维度表只有一个主键

7.3 事实与维度的融合

8. 应避免的常见疏误

第2章 零售营销

第3章 库存

第4章 采购

第5章 订单管理

第6章 客户关系管理

第7章 账目

第8章 人力资源管理

第9章 财经服务

第10章 电信与公用事业

第11章 交通

第12章 教育

第13章 卫生保健

第14章 电子商务

第15章 保险

第16章 建立数据仓库

1. 业务维度生命周期

image-20220303110349789
  • 项目规划业务需求定义存在交互内容;
  • 在选择产品之前一定要清楚地理解要完成什么样的任务;
  • 首先,将需求转换成维度模型;然后,将维度模型转换成物理结构,在物理设计行为的区间中,处理的焦点是像聚集、索引与分区之类的性能调整手段;最后,进行设计与开发,即数据转储ETL处理;
  • 分析型应用以参数驱动模板与分析工具的形式存在;

第17章 相关知识与展望

术语表

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值