数据仓库工具箱The Data Warehouse Toolkit 阅读笔记 （一：了解DW/BI）

许久没有更新了，被半年来的阅读量吓了一跳。感谢大家的陪伴，现在已经在新的一个阶段了。我会继续努力给大家带来认真写的东西！

概述

数据仓库和商业智能系统（DW/BI）是本书讨论的基础。这章会从讨论DW/BI的结构入手，进行了解，是后面讨论的基础。

DW/BI的介绍和解释

DW/BI系统使用数据，是分析型系统。我们在理解上要把其和操作型系统（主要用于记录保存）区分开，区别的根源应该从业务需求说起：相比于记录和存储为主相对单纯的操作型系统，DW/BI系统的“用户研究分析企业的运转，并对其性能进行评估”。更简单的说，我们要考虑更多的是存下来的数据怎么用？如何呈现？查询的时候怎么更加高质量高效率？

挑了几个关键词来说DW/BI的业务需求：1）方便存取； 2） 数据整齐一致；3）能够适应变化（数据改动不影响原有的功能和应用）4）快速呈现有效信息；5）正确性； 6）有效控制对组织中机密信息的访问。

要成为一个好的DW/BI工作者，需要两个重点：理解用户和以信息技术为基础高精准分析决策。这个过程需要去分析用户的组成、层次、目标、侧重点等；而在后者中需要选择好的应用、合适的数据源、做好维护与更新、监控分析和改进、不断适应由用户或者外界带来的变化。

1. 维度建模

维度建模是展现分析数据的首选技术，其强调简单性。主要有两个特点：以商业用户可理解的方式发布数据、提供高效的查询性能。维度建模也可以用ER Diagram表示（实体-关系图）。

虽然简单是要求，但是维度建模并不要求满足3NF。在3NF的规则中，指出要消除冗余，这样可能会为了满足条件近乎无限的将本来不算复杂的表编程复杂的“蜘蛛网状图”，包含上百个表。如果这么搞，查询效率和难度可想而知，更别提高效查询了。为此，我们的维度建模就是用来解决这个过于复杂的问题的。

星型模式与OLAP多位数据库
OLAP: Online Analyticala Processing, 联机分析处理多维数据库。
关于星型模式和OLAP的关系我们解释为：

• 在关系数据管理系统中实现的维度模型成为星型模式，因为其结构类似星型结构。在所谓数据库环境中实现的模型通常称为OLAP。
• 更直接的说，星型模式是部署在关系数据库管理系统（RDBMS）上的多维结构。联机分析处理（OLAP）多维数据库是是现在多维数据库上的多维结构。他们的内容等价，或者可以理解为OLAP来源于关系性星型模式。 – Chapter 2

个人认为这里不要去纠结OLAP和星型模型的区别，区别在这里可能不是最重要的，我们想要学到的应该是二者某种共性。
星型采用的是多维度的概念，如下的图画的挺好的。

“当数据被夹在到OLAP多位数据库的时候，对这些数据的存储和索引，采用了为维度数据设计的格式和技术… 由于采用与计算、索引策略和其他优化方法，多位数据库可以实现高性能查询”。也就是说，用户发出的查询一般都不是新的查询。此外，OLAP还提供大量健壮的分析函数，特别是针对大数据集合时，分析函数相对SQL语句体现的优势更加明显。

此外，星型模式需要两个关键部件的支持：用于度量的事实表、用于描述环境的维度表
事实表：存储组织机构业务过程时间的性能度量结果。事实表粒度可以划分为：事务、周期性快照、积累快照。一般事实表具有两个或更多个foreign key与维度表的primary key关联。其通常包含外键集合的主键，事实表的primary key常为组合键，常用于表示多对多关系。其他的表称为维度表。

维度表：简单来说就是描述业务需求/或者某些名词的描述性特征的维度表，也就相当于事实表中某些外键所对应的字表。

这样的维度模型具有简单和适于变化的特点。简单是因为表的设计尽可能减少了链接操作，从而使查询更加高效；适于变化是因为，首先在查询的时候时间这些因素并没有偏好和先后顺序，访问完全是基本公平的，且在添加条目的时候通过SQL ALTER TABLE直接对当前更新，相当于添加一条信息到事实表中就可以了，而不是分很多次一个个表的去追加。
我们在写SQL语句的时候WHERE后面需要写维度与事实表之间需要做的链接操作。举例如下，其他大致与普通的SQL语句差不多。

2. Kimball的DW/BI架构

（1）操作型源系统
要获取数据要从操作型系统里拿，虽然我们确实可以直接从操作型系统查，但是效率极低。
（2）获取-转化-加载（ETL）系统 【举例：厨房（将食材转换为有意义的东西）】
所以我们需要一个步骤把数据加载出来到DW/BI中。读过来以后还没完，还要进行数据转换。比如清洗啊这些操作。这些即将进行ETL处理的数据一般都是满足3NF的数据，这样更加方便。整个“获取-转化-加载”过程需要进行两次：一次加载到数据库中，一次加载到维度模型中。但是ETL系统不能允许用户直接查询。
（3）支持商业智能决策的展现区 【举例：就餐区】
这就是这个环节的意义。展现区的数据应该以维度模型来展现（星型模型/OLAP多维数据库），且必须包含详细的原子数据。
“如果希望建立一种健壮的、继承的DW/BI环境，必须采用企业总线结构。”
（4）商业智能应用
泛指为商业用户提供利用展现区制定分析决策的能力，此所有BI应用的查询针对UW/BI展示区。BI应用既可以仅仅作为专用的查询工具，也可以复杂到数据挖掘、建模等更麻烦的操作。