一、数仓以及商业智能（Data Warehousing and Business Intelligence, DW/BI）系统
1.1数据操作和数据获取的区别
对所有组织来说，信息都是其最重要的财富之一。信息几乎总是用作两个目的:操作型记录的保存和分析型决策的制定。简单来说，操作型系统保存数据，而DW/BI系统使用数据。
操作型系统的用户确保组织能正常运转。操作型系统获取订单、签订新客户、监视操作型活动的状态、记录问题。对操作型系统进行优化的目的是使其能够更快
操作型系统一般一次处理一个事务记录。它们按部就班，以可预测的方式完成同样的操作型任务，可预测地执行组织的业务过程。鉴于这种执行特点，操作型系统通常不必维护历史数据，只需修改数据以反映最新的状态。
另一方面，DW/BI系统的用户研究分析企业的运转，并对其性能进行评估。DW/BI系统计算新订单的数量，并与过去一周的订单进行比较，找寻签订新客户的原因，了解客户在抱怨什么。这些信息用于分析并判断操作型过程是否处于正确的工作状态。尽管也需要详细的数据来支持始终处于变化状态的问题，但DW/BI系统一般不会一次只处理一个事务。对 DW/BI系统进行优化的目的是高性能地完成用户的查询，而回答用户的查询通常需要搜索成千上万条事务,并将查询结果放入一个查询集合中。为应对更复杂的问题,DW/BI系统的用户通常要求保存历史环境，用于精确地评估组织在一段时间内的性能。
2.1维度建模简介
基于前述对DW/BI系统目标的介绍，本节开始介绍维度建模的基本概念。维度建模是展现分析数据的首选技术，这一观点之所以被广泛接受，主要基于以下两个需要同时满足的需求:
以商业用户可理解的方式发布数据。
提供高效的查询性能。维度建模并不是一种新技术，早期主要用于简化数据库。50多年来，经过大量案例的考验，IT 组织、行业顾问和商业用户自然而然地被这种以单一维度结构满足人们基本需求的简单性所吸引。简单性至关重要，因为它能够确保用户方便地理解数据，以及确保软件能够快速、有效地发现及发布结果。
假设某个业务经理描述其业务为:“我们在各种各样的市场销售产品，并不断地对我们的表现进行度量。”维度设计者通过仔细倾听和分析，知道其业务强调的是产品、市场、时间。多数人发现其业务包含三维数据，即将其业务数据标识为产品、市场和时间。设想沿着上述三维进行切片和切块操作。多维数据库中的点表示度量结果，例如，销售额或利润，这一结果是满足特定产品、市场和时间的结果。将某些事情以具体、有形的方式抽象成数据集展示出来的能力是解决可理解能力的法宝。如果上述场景表现太简单，这正是我们的所需!从简单的数据模型开始是保持设计简单性的基础。如果从复杂的数据模型起步，那么最终会导致模型过度复杂，从而导致查询性能低下，最终使商业用户反感。爱因斯坦曾经说过“凡事应该尽量简单，直到不能再简单为止。”
业界有时将 3NF 模型称为实体-关系模型。实体-关系图(ER图或ERD)表示了表间的交互关系。3NF模型及维度模型都可以用ERD表示，因为它们都包含可连接的关系表。主要差别在于规范化程度。因为两种模型都可以用ERD表示，我们强调不要将ER模型当成
3NF 模型，将3NF 模型称为规范化模型以消除混淆。规范化的 3NF 模型主要应用于操作型过程中,因为对事务的更新与插入仅触及数据库的单一地方。然而，对 BI查询来说，规范化模型太复杂。用户难以理解、检索，难以记住类似洛杉矶地铁系统那样具有复杂网络的模型。而且，多数关系数据库管理系统不能有效地查询规范化模型，用户查询难以预测的复杂性将耗尽数据库优化器，产生灾难性的查询性能。在 DW/BI这样的展现系统中使用规范化建模方法难以满足对数据的高性能检索需求。幸运的是，维度建模解决了模式过分复杂的问题。
3.1事实表
维度模型中的事实表存储组织机构业务过程事件的性能度量结果。应该尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中。因为度量的数据量巨大，所以不应该为满足多个组织功能的需要而将这些数据存放在多个地方。应该允许多个组织的业务用户访问同一个单一的集中式数据仓库，确保他们能在整个企业中使用一致的数据。
事实表中的每行对应一个度量事件。每行中的数据是一个特定级别的细节数据，称为粒度。例如，销售事务中用一行来表示每个卖出的产品。维度建模的核心原则之一是同一事实表中的所有度量行必须具有相同的粒度。牢记建立事实表时使用统一的细节级别这原则可以确保不会出现重复计算度量的问题，
注意:
物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这一思想是维度建模的基本原则。其他工作都是以此为基础建立的。最实用的事实是数值类型和可加类型事实。
4.1维度表
维度表是事实表不可或缺的组成部分。维度表包含与业务过程度量事件有关的文本环它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。境。如图1-3所示，维度表通常有多列，或者说包含多个属性。有50~100个属性的维度表并不稀奇。尽管如此，也可能存在一些只包含少量属性的维度表。与事实表比较，维度表趋向于包含较少的行，但由于可能存在大量文本列而导致存在多列的情况。每个维度表由单一主键定义(参考图 1-3 的主键概念),用于在与事实表连接操作时实现参照完整性的基础。维度属性可作为查询约束、分组、报表标识的主要来源。对查询或报表请求来说，属性以词或词组加以区分。例如，当用户希望按照品牌来查看销售额时，要查看的品牌必须存在于维度属性中。
5.1ETL转化
DW/BI环境中获取、转换、加载(Extract Transformation and Load，ETL)系统包括一个工作区间、实例化的数据结构以及一个过程集合。ETL系统是处于操作型源系统与DW/BI展现系统之间的区域。此处仅对DW/BI系统中的这一基础模块进行简单介绍。
获取是将数据从操作型系统导入数据仓库环境这一ETL过程的第1步。获取意味着读取并理解源数据并将需要的数据复制到ETL系统中以利于后续的处理操作。从这点来看，数据属于数据仓库。
数据获取到ETL 系统后，需要进行多种转换操作，例如，清洗数据(消除拼写错误、解决领域冲突、处理错误的元素、解析为标准格式)，合并来自不同数据源的数据，复制数据等。ETL系统通过增强或数据变换，采用清洗和整合上述任务的方法，增加数据的利用价值。另外，这些工作还可以建立诊断元数据，逐步建立业务过程再工程以改进源系统的数据质量。
ETL 最后的步骤是实际构建和加载数据到展现区域的目标维度模型中。由于ETI系统的主要任务是在交付过程中划分维度和事实，因此其所包含的子系统非常重要。此处定义的子系统关注维度表的处理，例如，代理键分配、查找代码以提供适当的描述、拆分或组合列以提供适当的数据值、连接满足第3范式的数据表成为扁平的不满足规范化要求的维度等。相比之下，事实表往往比较庞大，因此在加载时需要耗费大量时间，将其加载并导入到展现区是必须开展的工作。当维度模型中的维度表和事实表被更新、索引、适当聚集，并确保良好质量后，业各用户就可以开始使用这些数据了。
6.1分层
