转：数据仓库工具箱——维度建模(Dimensional Modeling)摘要（一）

  首先，最为重要的是数据仓库要考虑商业的需求。这其实是句废话，因为数据仓库本身就是因商业需求而生的。但废话往往容易让人忽略。企业的信息一般存放于两个地方：业务系统(Operational System)和数据仓库(Data Warehouse)。而数据仓库的目标是使信息易于被访问并保持信息在整个企业范围内的一致性。同时，数据仓库要适应需求的改变、保护信息安全、改进由此产生的决策、且被商业界所认可。

 

      先来了解一下数据仓库。数据仓库包含四个相对独立的部分：业务源系统(Operational Source System)、数据Staging区、数据展现(Presentation)区和数据访问工具。

      业务源系统 一般就是获取源数据的业务系统数据库。

      数据Staging区 是指业务源系统和展现区之间所有的一切，包括存储区域和ETL(extract-transformation-load)。在架构上的主要意义在于它不提供任何查询和展现服务。换句话说，这部分对最终用户是不可见的。staging里的数据存储是否符合范式其实并不重要，只是别花太多精力在这非原则性的设计上。但范式化的结构不应该被用户查询，因为这会削弱数据仓库的可读性和查询的性能。一个数据库一旦支持用户查询和展现服务，它就被认为是数据仓库展现层的一部分。所以默认情况下，范式化的数据库不应该属于维度化的展现层。

      数据展现区 组织、存储数据并提供用户查询和分析的地方。它是一系列的集成的数据集市(data mart)。维度化不同于第三范式，维度化为了查询的简单性和性能允许冗余。查询的结果一般是大量数据聚合的结果，因此我们可能会出于性能考虑而预先存储聚合过的数据，但必须同时提供最细节的原子化数据，因为用户可能需要钻取这类信息。所有数据集市都要使用共用的维度表和事实表，就是要求他们是一致的（这是数据仓库总线架构的基础）。在一个大型的企业数据仓库，展现区会包含20多个非常类似的数据集市，每个数据集市会包含若干个事实表和5到15个共享的维度表。数据仓库里展现区的数据是可查询的、维度化的、原子的并且是遵循数据仓库总线架构的。在关系型数据库里，维度表通常表现为星型模型。

      数据访问工具是指能访问展现层数据的所有工具，包括最简单的查询工具也包括复杂的数据挖掘或模型应用。但大约80%到90%的用户都只会去使用包装好的应用模版，提供几个参数就能返回分析结果。有些复杂的数据访问工具还会将结果写进业务源系统或staging/展现区，比如模型或预测工具。

 

      了解完数据仓库，接下来要提一下两个额外需要考虑的事情：元数据(Metadata)和操作型数据存储(Operational Data Store)。

      元数据是指根数据仓库环境相关的除业务数据以外的所有信息。元数据是包括业务源系统数据库的定义、ETL的所有一切规则、展现区的访问权限管理等等一切信息，是对一切数据仓库工作成果的管理。这些往往容易被忽略而从项目计划中砍去，事实上却很重要。我们的目的是使用一个全局的管理框架搜集、分类、整合这些元数据，那么再一次从零构建这一切都将易如反掌。

      操作型数据存储，简称ODS，是一个很纠结的东西。通常情况下，ODS是用来提供一些特定的业务报表以满足战术性的决策需求的。提高性能的聚合、大量历史数据和大量描述性属性是不适合存储在ODS的。作为服务一个报表实例的ODS可以架构在业务源系统和数据仓库之间。而另外一种情况是CRM应用，比如你登陆网站可以看到你的所有旅游历史，或者呼叫中心能查询你以前的呼叫纪录和内容，传统的数据仓库是不提供这种几乎实时的数据的。类似于业务报表的情况，这个数据也是固定格式的。有趣的是这类ODS，例如呼叫中心，有时会从数据仓库获得用户倾向性等信息并存储在ODS里。这类ODS则是架构在数据仓库内的特定区域里。我们显然需要ODS，但我们不会分派人力去专门构建开发这个系统，除非业务数据系统和数据仓库都无法满足你的业务需求时。最后要说的是，ODS不是有些人所定义的数据仓库里原子数据存放的地方。这些原子数据同样也存放于数据仓库的展现层。

 

      最后要解释两个最基本的概念：事实表(Fact Table)和维度表(Dimension Table)。清楚的同学可以直接跳过这部分，因为这部分拗口性和废话性都很强。

      事实表是存放衡量商业结果数值的表。因为这些度量数据（又称作“事实”）是数据集市里最占空间的部分，所以要避免度量数据的重复。例如我们为某天某个零售店里某个商品记录下：以总价a元卖出n件商品。这里的a和n就是存放在一个事实表里的维度下的商业度量。这里的维度（某天、某个零售店、某个商品）则定义了事实表的粒度。同一个事实表里所有的度量都必须使用同一粒度。一个事实表最有用的属性就是数值的可加性。因为我们其实很少使用某行数据，而是大量使用聚合后的数值。后面还会遇到半可加和不可加的事实。理论上说，事实也可以是文本的，但这种情况极少。一般文本形式的度量是从下拉框选取的离散值，而我们就会把文本化的度量归到维度里，除非每一行的文本都不一样或者大部分都不一样；因此我们也不会在事实表里存储冗余的文本化信息，这样能节省大量空间。真正纯文本的事实是极少的（例如评论），因为完全不晓得输入的会是什么东东，导致的结果是几乎不可能去分析其内容。通常事实表占据所有消耗空间的90%以上，它应该倾向于很长（行多）很窄（列少）。在后面的章节我们将会看到所有粒度的事实表都归结于三类：事务、周其快照和累积快照。所有事实表都有两个或以上的外键分别连接于维度表的主键。例如，事实表中“产品”这个外键，连接于产品维度表的主键。如果事实表中所有外键都能连接到维度表中的主键，我们就说这个事实表满足引用完整性。所有外键的某个子集就能构成事实表的主键，我们称为组合键(composite key)，不需要额外的建立纯属浪费空间的单一主键。

      维度表包含很多的属性列，例如产品维度表里的产品描述列、品牌列、类别列等等，属性中的内容则一般为用户友好文本化的描述而非难懂的代码（智能码都应该被翻译成多个属性，有利于过滤、分组等）。维度表倾向于很短（行少，一般少于一百万行）很宽（列多，包含50到100个属性列也是很正常的）。每个维度表都有自己的单一主键，这是其他事实表连接时保证引用完整性的基础。维度表的属性被用于报表的标签，是事实表的入口，所以它是数据仓库可用且易于理解的关键。健壮的维度属性能提供健壮的分析能力，维度表实现通向数据仓库的用户接口。属性应该是离散的文本，不要简写，但也有数值型的，比如尺寸大小。我们通过该字段是连续的数量值参与计算还是离散的描述值参与约束来判断它应该属于事实还是维度。例如，标准成本像是一个产品的固有属性，但可能会经常变化，因此我们可能更倾向于归结到事实中。当然，它们之间没有明确的区分，标准成本怎么建模都可以，这就算是设计人员的特权吧。对于层级关系的处理我们出于查询性能的考虑，保留冗余信息。例如，许多产品都是同一个品牌，将所有品牌单独存储在其他表的做法是雪花模型(snowflake)。因为维度表占比不到10%，所以范不范式差别不大。我们经常用维度表的空间来换取简易性和可访问性。

      把事实表和维度表连接起来的星型模型由于简单，很容易被用户认可和接受。而维度表里冗余的部分能避免连接造成的错误，并且能通过减少连接操作而提高查询性能。这种模型有很高的扩展性：我们很容易给事实表增加维度或者给维度表增加维度列。