数据仓库的设计目的

　　软件产品来源于用户的需求，因此，在深入数据仓库的设计之前，我们需要了解客户的痛点有哪些，整理如下：

• 我们收集了海量的数据，但无法对其访问；

• 我们需要以各种方式方便的对数据进行切片和切块；

• 业务人员需要方便的获取数据；

• 将最重要的事情展示给我；

• 会议自始至终争论的是谁的数字正确，而不是制定决策；

• 我们希望能够使用信息来支持更多的基于事实的决策制定；

　　以上述用户的诉求为基础，梳理出数仓的设计目标（即业务需求）如下：

• 能方便的存取信息（即数据要直观，数据结构和标识要符合业务思维，数据查询速度快）；

• 以一致的形式展示信息（对于不同源数据的同名同意性，和异意异名性）；

• 能够适应变化（当业务发生改变时，已有数据和应用不应被改变或破坏）；

• 能够及时展现信息（原始数据需要根据实际业务场景，在几小时、几分钟或几秒钟内分析汇总，转换成可用信息）；

• 成为保护信息资产的安全堡垒（即有效控制对企业中敏感信息的访问）；

• 成为提高决策制定能力的权威和可信的基础（基于数据的正确性，输出分析数据所产生的决策）；

• 数仓成功的标志是业务群体接受该系统（以客户为中心）；

　　由此可见，作为数仓的管理者，其主要职责是获取不同源的数据，保证数据的质量、安全和一致性，并为客户提供其需要的服务。而对于数仓建设所使用的技术，只是达到商业目的的一种手段，并不应该出现在顶层的工作职责中。

　　下面梳理数仓管理者的责任如下：

• 理解用户：理解用户的工作职责、目标和任务；确定用户在制定哪些决策时需要数仓的帮助；识别需要数仓系统的“最佳”用户；发现潜在用户，并让其意识到数仓带来的价值；

• 为用户呈现可信的、相关的、可访问的信息和分析：从多数据源选择业务诉求相关的数据，确保数据精准、可信、一致，并持续的进行数据更新和分析；简化用户接口和应用，适应业务和数据的不断变化，发布高质量信息；

• 维护数仓环境：采用数仓系统制定的成功的业务决策，验证客户的人员配置及投入的开支；定期对系统进行更新；保持用户的信任和满意度；

维度建模简介

　　当前，维度建模依然是展现分析数据的首选技术，主要基于以下两个需要同时满足的需求：

• 以用户可以理解的方式发布数据；

• 提供高效的查询性能；

　　维度建模并不是一种新技术，它通常被应用在关系数据库管理系统之上，但维度模型并不必须满足第三范式（第三范式就是指表中的所有数据元素不但要能唯一地被主关键字所标识，而且它们之间还必须相互独立，不存在其他的函数关系）。

　　规范化的第三范式模型主要应用于操作型过程中，因为对事务的更新与插入仅触及数据库的某几行。然而对于数据挖掘和分析来说，第三范式模型过于复杂，用户查询难以预测的复杂性将耗尽数据库优化器，使查询性能低下。恰好，维度建模解决了这个问题。

星型模型与OLAP多维数据库

　　星型模式是多维的数据关系模型，它由事实表（Fact Table）和维表（Dimension Table）组成，如下图所示。

　　星型模型的每个维表中都会有一个维作为主键，所有这些维的主键结合成事实表的主键，因为其结构类似星型结构，故称其为星型模型。事实表的非主键属性称为事实，它们一般都是数值或其他可以进行计算的数据。

　　而OLAP（联机分析处理）是一种软件技术，它使分析人员能够迅速、一致、交互地从各个方面观察信息，以达到深入理解数据的目的。它具有FASMI（Fast Analysis of Shared Multidimensional Information），即共享多维信息快速分析的特征。其中F是快速性，指系统能在数秒内对用户的多数分析要求做出反应；A是可分析性，指用户无需编程就可以定义新的计算逻辑，将其作为分析的一部分，并以用户所希望的方式给出报告；M是多维性，指提供数据的多维分析视图；I是信息性，指能及时获得信息，并且管理大量信息。

　　在多维数据库环境中实现的维度模型通常称为OLAP多维数据库。

　　当数据被加载到OLAP多维数据库时，对这些数据的存储和索引便采用了为维度数据设计的格式和技术。多维数据库可以通过预计算、索引策略和其他优化方法，实现高性能查询。用户可以通过增加或删除其查询中的属性，开展上钻和下钻操作，获取不同维度的统计信息。

　　如果要将数据部署到OLAP多维数据库中，必须注意以下问题：

• 星型模型（或其它多维数据关系模型）是建立OLAP多维数据库的良好物理基础；

• OLAP多维数据库通常比RDBMS提供更多的安全选项，如限制访问细节数据等，但对汇总数据往往能提供更开放的接口；

• OLAP多维数据库对RDBMS，能提供更丰富的分析能力，这也是选择OLAP产品的主要依据；

• 当需要使用缓慢变化维度技术重写数据时，多维数据库通常需要全部或部分的重新处理；

• 多维数据库方便的支持事务和周期性快照事实表，但是由于前一个问题而无法处理累积快照事实表；

• 通常支持具有层次不确定的复杂的不规则层次结构，如组织结构图、物料表等，其查询性能更优越；

• 能对实现下钻层次的维度关键词结构提供更详细的约束；

• 一些OLAP产品无法确保实现维度角色和别名，需要定义不同的物理维度；

事实表

　　维度模型中的事实表存储了企业业务过程事件的性能度量结果，且应尽量将来源于同一个业务过程的底层度量结果存储于一个维度模型中。因为数据量巨大，所以不应该为了满足多个企业内组织的需要，而将数据存放在多个数据库中。应该允许多个组织的用户访问同一个单一的集中式数据仓库，确保数据的一致性。

　　“事实”这一术语表示某个业务度量。例如，对于超市商品来说，每种商品的销售数量以及价格，就是它的业务度量，也就是它的“事实”。而事实表中的每一行都对应一个度量事件。

　　下表为超市商品的事实表结构设计：

　　其中Sales Units和Sales Dollars即为零售商品的“事实”。

　　注意，物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这是维度建模的基本原则。

　　对于“事实”的类型选择，最常见的事实类型是数值类型和可加类型事实，因为数仓系统常见的应用场景是一次检索成百上千，甚至百万级别的事实表行，并对“事实”进行累加分析，如上例中的“销售额”和“销售数量”。

　　除此之外，也会遇到一些半可加，甚至不可加的事实。半可加事实（如账户结余）不能按时间维度执行汇总操作；不可加事实（如单位价格）不能相加。面对这种情况时，一般会进行计数或取平均值操作，或者简化为一次输出一个事实行（当处理海量数据时，执行这种操作是不现实的）。

　　事实通常以连续值描述，这样有助于区分到底是事实还是维度属性的问题。

　　理论上，以文本方式表示度量事实是可行的。但通常情况下，文本型度量是对某些事情的描述，来源于离散值列表。

　　不要在事实表中存储冗余的文本信息，除非对事实表中的每一行来说，其文本是唯一的，否则，应尽量将其放入维度表中。

　　事实表的粒度可分为：事务、周期性快照、和累积快照。事务粒度的事实表是最常见的。

　　一般事实表具有两个或更多个外键与维度表的主键相关联。事实表通常有包含外键组合的主键，通常被称为组合键。

维度表

　　维度表一般包含与业务度量事件有关的环境属性，用于描述与“谁、什么、哪里、何时、如何、为什么”有关的内容。如下图的产品维度表：

　　维度表通常有多列，即多个属性，属性有几个、几十个、或者上百个不等。与事实表不同的是，维度表趋向于包含较少的行，因此可能存在大量文本属性而导致的多列的情况。

　　每个维度表由单一主键定义，维度属性可作为查询约束、分组、报表表示的主要来源。例如，用户希望按品牌查看销售额时，要查看的品牌必须存在于维度属性中。

　　同时，维度属性对数仓系统的可用性和可理解性也起着至关重要的作用。属性应命名为具有真实意义的词汇，而不是令人感到迷惑的缩写。应该尽量少的在维度表中使用代码，应该将代码替换为详细的文本属性。应该对操作型代码进行解码，再用于维度属性中，以提供一致性的标识。

　　某些情况下，操作码或标识符对用户具有确定的业务含义，此时，操作码应作为清晰的维度属性出现，辅以用户友好的文本描述。有时候操作码包含一些特定含义，比如身份证号码前六位表示地址，中间八位表示出生日期，此时最好的做法是将其按特定含义拆分，以不同维度的属性的方式呈现给用户，方便用户查询和制作报表等。

　　在分析源数据时，有时不清楚一个数值数据元素应该是事实属性还是维度属性，可以通过分析其是否包含多个值且是否为计算的参与者，是则为事实属性；如果一个数据元素是对具体值的描述，是一个常量、某一约束、或行标识的参与者，则该元素往往为维度属性。有时，识别一个数值数据元素是“事实”还是“维度”，还需要根据业务需求来判断。比如一个商品的单价，我们可以认为其为一个常量，是维度属性，但是单价往往是不断变化，且用户可能有计算一段时间内平均单价的诉求，此时作为事实属性更为合适。

　　实践中，连续值数字基本上可以认为是事实属性，而来自于一个不太大的列表的离散数字基本上可以认为是维度属性。

星型模型中维度与事实的连接

　　在对维度表与事实表有了简单的了解后，可以开始将这两个基本元素连接在一起加以考虑了，如下图：

　　图中，事实表存储事件的数值化度量，维度表存储了事件发生时的文本环境，这种类似星状的结构即为星型模型。

　　星型模型不但简单易用，且查询性能好。在执行SQL时，数据库引擎首先根据条件查询多重索引的维度表，然后将查询到的维度表关键字与事实表通过笛卡尔积的方式连接（即构建一个包含所需信息的宽表），通过这种方式，优化器可以一次遍历事实表索引，大大提高SQL执行效率。