DW/BI基本知识
基本知识
维度建模
需求：
1.以商业用户理解的方式发布数据
2.提供高效的查询性能
星型模型和OLAP多维数据库
关系型数据库实现的维度模型成为星型模式，结构类似于星型结构；多为数据库中的维度模式通常称为联机分析处理（OLAP）多维数据库。
DW/BI环境包括星型模式或者OLAP多维数据库，则该环境利用了维度概念。两者的对可识别的维度具有公共的逻辑设计，但是物理实现上具有差异。
当数据加载到OLAP时，对于这些数据的存储和索引，采取了为维度数据设计的格式和技术。性能聚集或者预计算汇总表通常有OLAP多维数据库引擎建立管理。
由于采取预计算，索引策略和其他优化方法，多维数据库可以实现高性能查询。同时，OLAP还会提供强大的分析函数来进行大数据集合的分析。
OLAP部署的注意事项
- 构建于关系数据库上的星型模型是建立OLAP多维数据库的良好基础。
- OLAP比RDBMS具有更好的性能，但是在与硬件性能的提升下，二者的差别可能不是很大
- OLAP的数据库结构比关系型数据库更大
- OLAP会提供更多的安全选项，限制用户访问权限等等
- OLAP的分析能力更加强大
- OLAP比较方便的支持缓慢变化维度类型2变化
- OLAP支持事物和周期性快照事实表
- OLAP下钻会有更加详细的约束
- OLAP需要界定不同的物理维度
事实表
维度模型中的事实表存储的是组织结构业务过程中时间的性能度量结果。应当将来源于同一个业务过程底层的度量结果存储于一个维度模型中。因为度量的数据量巨大，所以不应为了满足多个组织功能的需要将这些数据存放多个地方。应该允许多个组织的业务用户访问同一个单一的集中式仓库，确保他们在整个业务中使用一致的数据。
事实表中的每一行对应的是一个度量事件。每一行的数据都是一个特定级别的细节数据，称为粒度。例如销售事务中用一行来表示每个卖出的产品。维度建模的核心原则之一就是同一个事实表所有度量行都必须具有相同的粒度。建立事实表使用统一的细节级别可以确保不会出现重复计算度量的问题。
物理世界的每一个度量事件与对应的事实表行具有一对一的关系。这是维度建模的基本原则。
最实用的的事实是数值类型和可加类型事实。可加性是至关重要的，因为BI应用不太可能仅仅检索事实表的单一行。通常BI应用一次检索的是成百上千、甚至百万级的事实表行。处理如此多行的数据最有用的操作就是将他们加在一起。事实通常以连续值描述，这样有助于区分是事实还是维度属性的问题。
事实表的粒度可分为三类：事务、周期性快照、累计快照。一般事实表通常有包含外键集合的主键，具有两个或者多个外键与维度表的主键关联。例如，事实表中的产品键始终与产品维度表中的特定产品键匹配。事实表的主键常称为组合键，具有组合键的表成为事实表。事实表表示多对对的关系，其他表称为维度表。通常几个维度一起唯一标识每个事实表行。
描述环境的维度表
维度表是事实表不可或缺的组成部分。维度表包含与业务过程度量事件有关的文本环境。他们用于描述“谁、什么、哪里、何时、如何、为什么”有关的事件。
维度表通常包含多列，或者说包含多个属性，与事实表比较，维度表具有更少的行。但由于可能存在大量文本导致存在多列的情况。每个维度表由单一主键定义，用于与事实表连接操作实现完整参照性的基础。
维度属性可作为查询约束、分组、报表标识的主要来源。对于查询报表请求来说，属性以词或者词组进行区分。例如，单用户希望按照品牌来查看销售额时，要查看的品牌必须存在于维度属性中。
维度表的属性在DW/BI系统中起着至关重要的作用。因为维度表的属性是所有查询约束和报表标识的来源。维度属性对于DW/BI系统的可用性和可理解性也有十分重要的作用。属性应当使用真实的词汇代替难以理解的缩写。
多数情况下，数据仓库的好坏直接取决于维度属性的设置，系统的分析能力直接取决于维度属性的质量和深度。为维度属性提供详细的业务属于耗费的精力越多，效果就越好，强大的维度属性带来的回报是健壮的分片-分块能力。
在分析操作型源数据时，不清楚一个数值数据元素应当是事实属性还是维度属性。可以通过分析该列是否是一种包含多个值并作为计算的参与者的度量，这种情况下该列往往是事实；或者该列是对具体值的描述，是一个常量，某以约束和行标识的参与者，此时该属性往往是一个维度属性。例如，产品的标价看起来是一个产品的常量属性，但是会经常发生变化，因此，他更可能是一个度量事实。
星型模型中维度与事实的连接
在对维度表和事实表有了简单了解后，可以将维度模型的基本元素一起加以思考。如下图：
维度模型表示的每个业务过程中包含的事实表，事实表存储事件的数值变化度量，围绕事实的是多个维度表，维度表包含事件发生时实际存在的文本环境。这种类似星型的结构通常称为星型连接。
维度模式首先需要注意的是简单性和对称性。简单对于业务有利，利于查询和理解。表数量的减少可以在实际业务描述中更容易被查询，减少错误的发送。在于性能方面，数据库优化器处理这些很少使用连接操作的简单模式会更高效。数据库引擎首先处理多重索引的维度表，然后将满足用户约束的维度表关键字与事实表通过笛卡尔积连接。
维度模型适于变化，维度模型可预测的框架可适应用户行为的变化。对于维度来说，每一个维度的地位都相同，所有维度在事实表都存在对应的入口。对于查询来说，不同的维度约束，维度模型并没有任何的偏向性和优先顺序。
粒度最小的数据或者原子数据具有最多的维度。原子数据是最具有表达性的数据。这些数据可以构建满足用户提出的任意查询的事实表的设计基础。对于维度模型来说，可以将全新的维度增加到模式中，只要该维度的单一值被定义到已经存在的事实表行中。相同的，也可以将新的事实增加到事实表中，前提是该粒度与事实表的整体粒度一致。
基于Kimball的DW/BI结构
DW/BI环境划分为四个不同的各具特色的组成部分。分别为：操作型源系统>>ETL系统>>数据展现>>商业智能应用。具体如下图:
操作型源系统
他们是记录的操作型系统，用于获取业务事务。可以认为源系统处于数仓外。因为几乎不能控制这些操作型系统中的数据的格式和内容。这些系统主要关注的事情是处理性能和可用性。针对这些系统的查询是浅显的，一次一条的查询方式严重制约查询对于操作系统的需求。通常操作系统不能实现类似于DW/BI这样的查询特点。源系统不会维护历史信息。多数情况下，源系统是一种针对于特定意图的应用。
ETL系统
DW/BI系统中的ETL系统实际上是一个处理数据的过程集合。ETL系统是处于源系统和DW/BI展现系统之间的区域。
获取是将数据从操作型系统导入到数仓环境中的第一步。获取意味着读取并理解源数据并将需要的数据复制到ETL系统中以利于后续的处理操作。
数据清洗，当数据获取到数仓后，需要进行多种转换操作，例如清洗数据，消除一些脏数据，格式转换等等操作，合并不同的数据源的数据。提高数据的利用性能，增加数据的利用价值。
ETL的最后一步是load数据到展现区域的目标维度模型中。由于ETL的主要任务是在交付过程中划分维度和事实，因此对于其关注维度表处理的子系统就非常重要。
展现区
展现区用于组织、存储数据、支持用户、报表制作者以及其他分析型BI应用的查询。由于展现区的后端的ETL不允许用户直接查询。所以，整个DW/BI环境中的展现区才是最终面对用户所关注的区域。对于展现区，数据应当以维度模型来展现，即星型和OLAP；同时，必须包含详细的原子数据来满足用户无法预测的查询需求，尽管为提高查询性能，会进行聚集性质的存储数据，但是没有原子性数据的展现区是不够完整的，用户无法在最细粒度的层级上进行下钻操作，这在用户需求的级别上是无法满足的。
商业智能应用
BI应用泛指为商业用户提供利用展现区制定分析决策的能力。即BI应用的查询针对的都是DW/BI系统的展现区。查询是关键，BI应用可以很简单，仅仅作为查询工具，也可以很复杂，进行数据挖掘或者建模应用。
维度建模技术概述
维度建模的一般步骤
- 业务需求的收集和数据实现
在开始进行维度建模之前，项目组需要根据业务需求，以及源数据的实际情况，和熟悉业务需求的代表进行过详细沟通后，理解他们的关键性需求指标，需要解决的问题，决策所依赖的数据判断，以及支撑这些指标判断的数据，来确定整个系统的数据的一个出发点。
- 维度模型的商讨和确定
在确定了需求出发点和源数据格式的前提下，数据建模这应当和业务代表进行业务模型的确定，通过不同模型和需求的组合，最终确定使用哪种模型进行系统的组建
- 维度模型设计的过程步骤
维度模型设计主要会涉及到下面几个主要的决策行为：
(1)选择业务过程
(2)声明粒度
(3)确认维度
(4)确认事实
上述问题的解决需要考虑的便是数据底层数据和数据需求。按照业务过程、粒度、维度、事实声明的流程，确定表名和列名，业务规则等等。
业务过程
业务过程是组织完成的操作型活动。例如：获得订单，处理索赔，注册事件等等。业务过程时间建立获取性能度量，转化为事实表中的事实。过程的选择很重要，过程定义特定的设计目标以及粒度、维度、事实的定义。每个业务过程对应企业数仓总线的一行。
粒度选择
声明粒度是维度建模中重要的一步。粒度用于确定某一事实表中的一行表示什么，粒度声明相当于一个必须履行的合同。选择维度和事实之前，必须要确定粒度，保持每一个候选维度或者事实和粒度保持一致。所有维度设计中实行一致性是保证BI应用性能和易用性的关键。在进行数据获取时，原子数据是最细粒度的数据，在进行设计的时候，应当从该级别的粒度开始，以便满足用户不可预测的查询需求，向上在进行汇总粒度的选择时，需要去考虑业务方面，针对不同的业务需求，和不同的事实表的粒度，建立不同的物理表，在同一事实表中不可混用多种粒度。
维度确认
维度提供的是某一业务环境中所涉及的“谁、什么、何处、何时、为什么、如何”这些背景。维度表包含BI应用所需要的用于过滤及分类事实的描述属性。严格区分事实表的粒度，就可以将所有可能存在的维度分开。在和给定事实表进行关联的时候，任何情况都应当使维度保持一致。
事实确认
事实涉及的是来自业务过程中事件的度量，基本都是一数量值表示。一个事实表行与按照事实表粒度描述的度量事件之间存在一对一的关系，因此事实表对应一个物理可观察的事件。事实表中声明的粒度是保持一致的。
事实表技术基础
事实表结构
在现实中的操作型事件，将产生的度量数值，存储在事实表中。从最低的粒度级别来看，事实表中每一行都对应一个度量事件。事实表的设计完全依赖于物理活动，不受可能产生的最终的报表影响。查询的请求的目的也主要是对事实表进行计算和聚合分组操作。
可加、半可加、不可加事实
事实表中的数字度量可以分为三类。最灵活、最有用的为完全可加，可加性度量可以按照与事实表关联的任意维度汇总；半可加维度可以在某些维度上进行汇总，但不能对所有的维度汇总，例如差额，除了时间维度外，可以跨所有维度进行加法操作。不可加度量，比如比率，对于不可加事实，我们尽量存储不可加度量的完全可加的分量，并在计算最终的不可加事实前，将这些分量汇总到最终结果集。
事实表中的空值
事实表中可以存在空值度量，但是外键关联不能存在空值。
一致性事实
如果一些度量值出现在不同的事实表，应当保证对于事实的技术定义是相同的。如果不同的事实表定义一致，这些一致性事实应当具有相同的命名；相反，如果这些事实表不兼容，则应当取不同的命名来做区分。
事务事实表
事务事实表一行对应的是空间或者时间上的一个度量事件。原子事务粒度事实表是维度话及可表达的事实表。这类简装的维度确保对事务数据的最大化分片和分块。事务事实表的数字度量事实与事务粒度保持一致。
周期快照事实表
周期快照事实表中的一行是汇总了发生在某一标准周期，如某一天、某一个月的多个度量事件。粒度是周期性的，而不是原子粒度。周期快照事实表通常包含许多事实，因为任何与事实表粒度一致的度量事件都可以存在。
累计快照事实表
累计快照事实表行汇总发生在过程开始和结束之间可以预测步骤内的度量事件。累计快照事实表中的一行，对应某一个具体的订单，当订单产生是，插入一行。
聚集事实表或者OLAP
聚集事实表是对原子粒度事实表数据进行简单的数字化上卷操作，目的是为了提高查询性能。这些聚集事实表以及原子事实表可以同时被BI层使用。BI可以自由的选择适当的聚集层次进行分析，都可以享受到聚集带来的查询性能。聚集事实的构建是通过对于来自多个原子事务表的度量汇总而获得的。
维度表技术基础
维度表结构
每个维度表包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，维度表行的描述应当和事实表行完全对应。维度表比较宽，包含大量的低粒度的文本属性。操作代码与指示器可以作为属性对待，最强有力的维度属性采用的冗长的描述。维度属性是查询以及BI查询的约束和分组定义的重要指标。
维度代理键
维度表包含一个主键。该主键不是操作系统的自然键，由于需要跟踪变化，DW/BI需要声明对所有维度的主键的控制，因此无法采用单一的自然键，每个维度建立整型主键。这些维度代理建按照顺序分配的整数。
自然键、持久键、超自然键
由于自然键受到业务规则影响，无法被DW/BI系统控制。比如，当一个员工辞职，然后重新工作，员工号码会发生变化（自然键）。数仓希望为该员工创建单一键，这就需要新的持久键来确保不会发生变化。最好的持久键应当存在于原始的业务过程，然后与多个代理建相关联，确保，描述发生变化的时候，持久键不会发生变化。
下钻
下钻是商业用户分析数据最基本的方法，需要在SQL层附加group by表达式，属性选择是当前下钻事实表与之关联的维度。
退化维度
有时，维度除了主键外没有其他内容，比如，当某一天的发票包含多个数据项时，数据项实行继承了发票所有的描述属性外键，发票除了外键，别无其他项。但是发票数量仍然是次数据项级别的合法维度键，这种退化维度被放入事实表，清楚的表明没有关联的维度表。
多层次维度
多数维度并不只是包含一个维度。例如，日历维度可以按照财务周期层次从天到周进行划分，位置密集型维度也可能包含多个地理层次。
维度表中的空值
当给定的维度属性没有被完全填充时，或者存在属性没有被应用到所有维度行时，就会产生空值维度属性。上述情况，建议使用描述性字符串代替空值。避免使用空值的原因是不同的数据库在处理分组和约束时，针对空值的处理方法不一致。
日历日期维度
连接到实际事实表的日历日期维度，使得能够对事实表，按照熟悉的日期、月份、财务周期和日历上的特殊日期进行导航。日历日期维度通常包含许多描述，例如周数、月份名称、财务周期、国家假日等属性。为了方便划分，日期维度的主键可以更有意义，例如，用一个整数表示YYYYMMDD，俄日不是用顺序代理键。当日期维度表需要特定的行表示位置的或者待定的日期，可以在事实表中增加不同的日期时间戳。
角色维度
单个物理维度可以被事实表多次引用，每个引用的逻辑上存在差异的角色维度。例如事实表可以有多个日期，每个日期通过外键表示不同的日期维度，原则上每个外键表示不同的日期维度视图，这样引用具有不同的含义，这些不同的维度视图，称为角色。
杂项维度
事务型商业通常产生一系列混杂、低粒度的标识和指示器。若为每个标识定义不同的维度，不如单独将不同的维度合并到一起建立杂项维度。
雪花维度
维度表中的层次关系是规范型时，低粒度的属性作为辅助表通过属性键连接到基本维度表，这一过程如果包含多重维度表层次时，建立的多级结构被称为雪花模式。但是应当避免雪花模式，对于查询性能的影响相较于维度模式同样的信息获得，雪花模式的代价较大。
使用一致性维度集成
一致性维度
当不同的维度表具有相同的列名和领域内容时，这些维度表具有一致性。利用一致性维度属性和每个事实表关联，可以将来自不同事实表的信息合并到同一报表。当一致性属性作为分组列时，来自不同事实表的结果可以排列跨钻报表的同一行。一致性维度一旦在数据管理方共同定义后，可以被所有相关联的事实表重用。
缩减维度
缩减维度是一种一致性维度，由基本维度的列或者行的子集构成。当构建聚集事实表时需要缩减上卷维度。当商业过程自然地获取粒度级别较高的数据时，也需要缩减维度。两个维度具有同样粒度的细节数矩，但其中一个仅表示行的部分子集时，也需要一致性维度子集。
跨表钻取
跨表钻取当每个查询的分组属性都包含在相同的一致性属性时，使用不同的查询能够对两个或者更多的事实表进行查询。
价值链
价值链用于区分组织中主要业务过程中的自然流程。例如，销售中的价值链包括购买、库存、零售额等等。操作型源系统通常为价值链上的每个步骤建立事务或者快照，因为每个过程在特定的时间间隔，采用特定的粒度和维度建立唯一的度量，每个过程都会建立一个原子事实表。
数仓总线架构
数仓总线架构提供的是一种建立企业DW/BI系统的增量方法。这一架构通过关注业务将DW/BI规划过程分解为可管理的模块，通过重用跨不同过程的标准一致化维度发布实现集成。