Skip to content

Latest commit

 

History

History
95 lines (90 loc) · 9.63 KB

book-StarSchema.md

File metadata and controls

95 lines (90 loc) · 9.63 KB

@[TOC](读书笔记《Star Schema》)

读书笔记

读书原则：费曼原则，用一句最简单的话来描述一个概念。

分析性数据库与维度设计

  • 数据库：传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。
  • 数据仓库：数据仓库系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果
  • 操作性系统：支持业务过程的执行和操作
  • 分析型系统：查询大量数据，从宏观上分析趋势。
  • 第三范式：
  • 维度设计：通过事实和维度为基础进行设计。
  • 度量（事实）：销售1000美元。离开了维度，这一事实毫无意义。
  • 事实表：事实元素的聚集。
  • 环境（维度）：是指一件产品还是多件产品，是指全月还是全年。
  • 维度表：维度元素的聚集。
  • 星型模式：事实放中间，维度放在四周 在这里插入图片描述
  • 星型模式 1.星型模式可以将事实和维度以任意方式组合以完成查询，当维度表逐渐复杂，则可得到表的种类几何倍数增加。 2.星型模式报告事实的能力主要受限于事实存储的细节级别。如表中最精细数据是按照天存储的，那么不管怎么进行组合都不能得到以小时为维度的查询表。 3.一些非常重要的报表是从多个星型模式融合查询结果集。
  • 星型模式常见误解：星型模式就是用于收集数据 星型模式的应用将导致信息孤岛
  • 多维数据集：见后面章节
  • 雪花模式：p9
  • 代理键：没有什么实际含义，只是维度表的唯一标识符。1表，2表，3表
  • 自然键：区分特定的事务 如客户、产品的customer-id，product-id
  • 关于两键：在数据仓库中，区分代理键和自然键的目的是追钟数据变化的情况。如果需要追踪一个客户的地址变化情况。若表以客户id作为唯一标志符，当客户地址改变，只能将表中的旧地址改为新地址进行存储。而若创建表2，则可以将旧地址保留在表一中。连接两个表就可以进行地址追踪。 表1、2即是代理键，customer-id即是自然键。

数据仓库体系结构

  • 数据仓库体系结构的种类非常广泛。造成了混乱——同样的术语描述了不同的事务。
  • 数据集市：任何体系结构中的主题区域。如一个企业人事部门的数据。
  • 源系统：采用星型模式获取数据的计算机系统。企业化信息工厂中源系统是企业数据仓库。维度数据仓库中源系统是操作型系统。
  • 分为三类：

2.1 inmon的企业信息化工厂

  • 尽可能的包括最底层的细节数据。
  • 企业信息化工厂中的企业数据仓库不是分析型应用程序来进行直接查询，而是利用附加的数据存储来进行分析。 在这里插入图片描述

2.2 Kimball 的维度数据仓库——被称为维度设计仓库体系结构

  • 可以仅仅只是一个逻辑仓库，数据依然从操作型数据库”们“那里调用。 在这里插入图片描述

2.3独立型数据集市

  • 利用操作型数据系统做多个数据集市（有重复），而不必统一视图为一个数据集市，故有短期内获得快速廉价的结果，同时导致长期费用提高和效率的低下的特点。
  • 造成信息孤岛 在这里插入图片描述
  • 三种数据仓库对比 在这里插入图片描述 在这里插入图片描述

星型模式和多维数据集

  • 为何代理价不能用customerID+序号或者customerID+时间戳，是因为那样如写SQL语句会难以理解。
  • 杂项维度：一类属性之间并没有什么关系，但都可以用于描述一个对象，简单的组合到一张表中称为杂项维度。如对象是订单，可以有属性表示其是不是二次订单，有的则表示订单是否付清，有的表示是否是信用卡订单等等。
  • 维度表存在大量冗余，如品牌数一般远远超过产品数，而产品表则不可避免地重复品牌。解决方法：雪花模式
  • 雪花模式：如上例，将品牌属性从产品表中去掉，存储到其他表中。第七行待完善
  • 为何要冗余呢？为何不在计算时实时生成表呢。
  1. 以空间换时间，提高查询性能。
  2. 方便使用者与数据库交互。 如用United States 比用07国家代码容易让人理解。
  • 稀疏性： 出现在事实表中的组合数量远远小于可能存在的组合数量。
  • 退化维：有时，不能将所有的维度都存储在维度表中，将一个或多个维度存储在事实表中是合适的选择。 但注意事实表增长很快，使用退化维可能造成存储空间的过度消耗 一般放到杂化维中
  • 缓慢变化维：反映了维度积累变化的实际情况，某些情况下，保留的历史数据将起到至关重要的作用。
  • 变化类型一，将不需要保留历史的数据直接修改为新值即可。
  • 变化类型二：保存了变化的历史事实。1.插入新的维度行表示新的事实，历史信息用老数据维度行保留。
  • 多维数据集（MDB）：各种维度可以排列组合得到各种表，这种排列组合的过程是预处理得到的。
  1. 主要优势在于速度，得益于预处理，客户可交互式 即时获得灵活的数据。（联机分析处理（OLAP（On-Line Analytical Processing）））
  2. 另一个优点是不受SQL语言的限制，有专用的语言实现SQL难以实现的功能。 缺点：当维度增加时，排列组合可得到的维度组合数几何倍数增加，预处理难度增大很快。 限制了对海量数据的处理能力。 在这里插入图片描述

过程处理中的事实表

  • 横向钻取：从多个事实表中正确的集成信息。可应用于两个或两个以上的星型模式，跨越多个数据库，甚至跨越存储在不同厂商关系数据库管理系统中的数据。也可对一个星型模式查询多次建立对比报表。
  • tips：为便于独立地分析研究，应为每个过程建立一个事实表。
  • 如何划分过程：
  1. 这些事是同时发生的吗？
  2. 这些事实粒度等级相同吗？
  • 如果上面两个问题有任何一个问题的答案为否定，则表明事实表示不同的过程。
  • 对销售分析，是建立一个销售过程事实表，还是按照下单、发货等建立多个事实表呢？
  • 按照上面两个问题，下单和发货没有同时发生，所以分为两个过程，建立两个事实表。
  • 若将本该属于两个事实表的数据归并在一个事实表中会怎样？
  • 因稀疏性导致查询表中会带有NULL或者0之类的无效数据，客户不会喜欢。
  • 那加一个大于零的查询条件不行吗？
  • 答：累积效应将使报表开发人员无法承受。（分析单个过程时，总是需要插入HAVING子句。其他的查询类型，包括计数、平均值、子查询等也会受到影响，并且有关的子查询都会变得更复杂。更让人烦恼的是，还需要记住需要分析两个过程时，HAVING子句必须要去掉。）
  • 不要试图对事实表进行连接操作，无论是直接操作还是通过维度表进行操作。对事实表的连接操作将产生不正确的结果。
  • 维度的一致性对横向钻取来说至关重要。

维度一致性问题

  • 实现横向钻取的维度表的属性尽可能要保持一致，当一个维度表中的属性是另一个维度表属性的子集时，横向钻取也可以实现。
  • 若维度不一致，则必须由经验丰富的开发人员进行横向钻取（即便是这样也会导致查询性能下降），而无法实现商业智能的自动化横向钻取。
  • 尽量做到结构相同和内容相同。
  • 结构相同：属性名字结构一致。
  • 内容相同：如产品名称在一张表内是表示为”9 * 12 bubble mailer“则在另一张表中也要表示为如此，省去了数据清洗的麻烦。即内容格式相同。

最后一课

  • OLTP联机事务处理：传统的操作型系统

  • OLAP联机分析处理：数据仓库，分析型数据库

  • OLAP和数据挖掘的区别：OLAP从不同维度分析数据（描述型），数据挖掘：探索型，可以进行预测