维表和事实表介绍

事实表是数据库中最大的表，是星形模型结构的核心。事实表包含了基本商业事务的详细信息，是对商务活动进行客户关系、销售趋势和产品趋势等分析的素材。事实表的设计包括对事实的选择、量度的构造、粒度的设计和聚合的设计等。 3.5.1 事实、度量和事实表 事实是各个维度的交点，是对某个特定事件的度量。维度中的属性描述的是维本身的属性，比如客户的性别、年龄、姓名和地址，这些都是客户的固有属性。 度量是客户发生事件或动作的事实记录，比如客户打电话，可能选择的度量有通话时长、通话次数和通话费用等；客户购买商品，可能选择的度量有购买的次数、购买商品的金额和购买商品的数量等。度量变量的取值可以是离散的数值，也可以是连续的数值。比如，客户通话次数是离散的数值，而客户购买商品的金额是连续的数值。度量变量也可以在某个元素集合内取值。比如客户对公司服务质量的评定可以是很好（Excellent）、好（Good）、一般（Fair）和差（Poor）中的一个。 事实表则是位于星形架构或雪花形架构中间，用来记录商务事实和相应统计指标的表。同维表相比，事实表具有如下的特征。 记录数量很多。 事实表中除了度量变量外，其他字段都是同维表或者中间表（对于雪花形模型）的关键字。 如果事实相关的维度很多，则事实表的字段数也会比较多。 从事实表记录数多的特征中，我们可以得到事实表设计的一个感性认识，即事实表应当尽量减小一条记录的长度，只有这样才能避免事实表过大而难于管理。相对维表来说，事实表是“细长”的结构，如图3-35所示。 错误！ 图3-35 事实表的特征

3.5.2 事实表的设计

由以上分析可知，事实表中一般要包含2部分：一是由主键和外键所组成的键部分，另一部分是用户希望在数据仓库中所了解的数值指标，这些指标是为每个派生出来的键而定义和计算的，称为事实或指标。由于事实是一种度量，所以事实表中的这种指标往往需要具有数值化和可加性的特征。但是在事实表中，只有那些具有完全可加性的事实才能根据所有的维度进行累加而具有意义。而事实表有一些事实表示的是某种强度，这类事实就不具有完全加法性，而是一种半加法性。例如，账目余款反映的是某个时间点的数据，它可以按照地点和商品等大多数维度进行累加，但是对于时间维度则例外，将一年中每个月的账目余款进行累加是毫无意义的，而决策者则可能需要了解所有地区和所有商品账目余款的累加值。在事实表中还有一些事实是非加法性的，即这些事实具有对事实的描述特性，在这种情况下一般要将这些非加法性事实转移到维度表中。

以事实表中度量的可加性情况，可以把事实表及其包含的事实分为4种样式。 1．事务事实

事务事实以企业事件的单一情况为基础，因此通常只包含事实的次数这一种度量条件，应该尽可能以最低级别来表示。比如银行的ATM提款机的提款次数，使用某种服务的次数等。

2．快照事实

快照事实以企业在某一特定时间的特殊状态为基础。也就是只有在某一段时间内才出现的结果。它们也许没有包含所有维的条件，比如不是所有的产品每天都有销售量。

3．线性项目事实

这类事实通常用来储存关于企业经营项目的详细信息。包括表现与企业相关的个别线性项目的所有度量条件，比如销售数量、销售金额、成本和运费等数值数据，也就是关键性能指标。此类事实运用范围很广，比如采购、销售和库存等。

4．事件（状态事实）

这是类特殊的事实，通常只表示事件发生与否和一些非事实本身具备的细节。它所表现的是一个事件发生后的结果变化，并且没有度量数值表示。如哪些产品在促销期间内没有卖出，有还是没有，就是事件或状态事实所表现的结果。

在事实表模型的设计中还需要注意到派生事实。派生事实主要有2种，一种是可以用同一事实表中的其他事实计算得到，例如销售行为中的商品单价可以用商品的销售总金额和销售数量计算得到，对于这些派生事实一般不保留在事实表中；另一种是非加法性事实，例如各种商品的利润率等各种比率。

在事实表模型的设计中必须要考虑到事实表中的这些事实特性，通过多次反复来确定。首先，通过调查确定所有可能的基本事实和派生事实；然后，对所有的事实按照功能或某种方式进行排序，以删除重复的事实；接着，确认那些基于不同准则但是有相同性质的派生事实，例如公司门市销售总额与地区销售总额虽由于维度的不同而被定义为不同的事实，但实际计算方法是一样的；最后，再一次确定事实表模型，在确认中要检查所有的计算派生事实的基本事实是否已经包含在模型中，并且与用户取得—致。

在设计事实表时，一定要注意使事实表尽可能地小，因为过于庞大的事实表在表的处理、备份和恢复及用户的查询等方面需要较长的时间。在实际设计时，可以利用减少列的数量、降低每一列的大小和把历史数据归档到单独的事实表中等多种方法来降低事实表的大小。另外，在事实表中还要解决好数据的精度和粒度的问题，下面将阐释粒度的设计方法。

3.5.3 粒度的设计 在数据仓库中的数据分为4个级别：早期细节级、当前细节级、轻度综合级和高度综合级。如图3-36所示，源数据经过综合后，首先进入当前细节级，并根据具体需要进行进一步综合，从而进入轻度综合级乃至高度综合级，老化的数据将进入早期细节级。从中可以看出，数据仓库中存在着不同的综合级别，这就是 “粒度”的直观表现。 错误！ 图3-36 数据仓库中的数据细节级别

粒度模型是数据仓库设计中需要解决的十分重要的问题之一。所谓粒度是指数据仓库中数据单元的详细程度和级别。数据越详细，粒度就越小，级别也就越低；数据综合度越高，粒度就越大，级别也就越高。 1．粒度对数据分析的影响 1）影响逻辑结构的设计 先举一个粒度设计的例子，Adventure Works Cycles公司的管理者想按照国家、区域、分区域和分区域内的销售员这样的层次关系来查看公司的销售情况，按照此需求可以得到如图3-37所示的设计结果。它是通过将地理层次国家、区域和分区域嵌入到销售员维度得到的。 图3-37 细化到销售员层次的设计结果 如果公司的决策者认为不需要了解具体到某个销售人员的情况，而只需要了解各个地理区域的销售情况，则没有必要把销售员维作为一个维度，把地域相关的表综合成为地理维度就可以了，设计结构如图3-38所示。 由以上实例可知，对事实粒度需求的不同，会直接导致数据仓库逻辑设计的差异。 错误！ 图3-38 细化到分区域层次的设计结果 2）影响数据的存储 粒度对数据仓库最直接的影响就是存储容量。如图3-39所示的例子，按照每“月”统计的客户购买数据和按照每次消费记载的客户购买数据，两者的数据量相差极大。不妨假定每个字段为8个字节，每个客户一天有5次消费，则1个客户1个月的消费细节数据的数据量为8×6×30×5＝7200字节，而1个客户1个月的消费汇总数据的数据量为8×4＝32字节。 错误！ 图3-39 不同粒度的储存容量示例

3）影响分析效果

不同的粒度设计对应不同的分析需求，若分析需求和粒度设计不匹配，则会直接影响分析效果。

因为数据的综合使得细节信息丢失，所以若分析需求的粒度小于设计的粒度，则需求不可能得到满足；反之，若分析需求的粒度大于设计的粒度，则查询会在更小的粒度上进行统计运算后才能回答，这将增加用户的等待时间。

例如在图3-40中，要回答“张某在2007年1月29号是否在北京买了一辆山地车”这样非常细致的问题，细节数据非常合适，而综合数据不可能回答。如果要回答“王某在2006年1月到2006年12月自行车配件的总消费是多少”这样综合程度较高的问题时，使用综合

为什么分割如此重要呢？因为小的物理单元能为操作者和设计者在管理数据时提供比对大的物理单元更大的灵活性。数据仓库的本质之一就是灵活地访问数据。如果是大块的数据，就达不到这一要求。因而，对所有当前细节的数据仓库数据都要进行分割。分割的原理类似如图3-42所示，由于全部销售记录过于庞大，可以按照不同的年度把它分为5个小的物理单元。 错误！ 图3-42 数据分割处理

例如，在第2章用到的foodmart 2000.mdb中，由于设计该数据库的时候考虑到了它将要作为数据仓库使用，因此，对于销售事实按照年份分割成了sales_fact_1997、sales_fact_1998和sales_fact_dec_1998 3个表，对库存事实则分割成了inventory_fact_1997和inventory_fact_1998两个表，如图3-43所示。

图3-43 Foodmart数据库中的数据分割

在工程实践中，除了时间以外，还可以有多种数据分割的标准。例如商务业务、地理位置和组织单位或者各种标准的综合。

3.6 规划分析的视角：维度

对客户、产品、服务、提供商、地点、渠道和事件发生的时间及对企业来说很重要的其他实体的观察是商业智能的基本驱动力。当它们在一个关系数据库中表示和抽象出来的时候，它们便叫做维。维是人们观察客观世界的角度，是一种高层次的类型划分。例如如果希望按照时间，或者按照地区或产品进行分析，那么这里的时间、地区和产品就是相应的维度。基于不同的维度，可以看到各量度的汇总情况，也可以基于所有的维度进行交叉分析。

3.6.1 维度的构成

在图3-10的星形架构图中可以看到，处于星形结构中央的事实表不仅包含度量，而且也包含维表的外键和事实表的主键。维度表除了代表维之外，还具有字段，例如客户维度表包含一个主键“CustomerKey”和用来向客户提供信息的其他字段。维度由主键和维属性构成。

维属性是维表里的列。维元素定义维表中的层次关系，属性则以用户熟悉的术语描述维元素。图3-44显示了维元素和相关属性的关系。 图3-44 维元素和相关属性的关系

在设计过程中，来自数据源的数值数据字段到底是一个已度量的事实还是一个维度的属性是比较容易混淆的一个问题。一般情况下，在每次抽样时，如果数值数据字段的度量都改变，那么它就是事实，如果它是某种东西的离散值描述，并几乎保持为常数，那么它就是维属性。

3.6.2 维度的特性

所有的维度都有一些共同特性，它们包括以下几个方面。

（1）维存在于关系式的表中，包含了键值和支持的属性，而且属性与所陈述的事实高度相关。对于属性一般使用简单易用的文字信息，不应该有代码或缩写，没有空值或NULL，没有无用或过时的数值。

（2）维度使用解析过的时间、名字或地址元素，这样可以使你的查询更灵活。比如时间可分为年、季度、月、周和日等；个人的名字可以分为姓氏和称谓（如先生或小姐）；组织名可以用部门来区分；地址则可以用地理区域来区分（如国家、州省和、城市）。

（3）不要使用业务数据库的键值，对每个维表另外增加一个额外的惟—值字段作为主键来识别维表实体，通常最常使用的字段类型是Identity类型或者16位格式的全局唯一标识符（Global Unique Identity，GUID）。这样，就不需要改变OLTP系统可能会发生的重复情形，也使得OLTP系统可以重复使用键值。这个在维表中新设定的键也叫代理键。

（4）维表至少包含一个决策因子，每个决策因子字段可以通过使用相关的主键，并结合事实表的KPI数据来响应用户的查询。

（5）维度表应该包含有随时间变化的数据记录字段，当数据集市或数据仓库的数据随时间变化而有额外增加或改变时，维表的数据行应该随着维属性的变化而变化。

3.6.3 维度的分类

维度主要有4种类型，包括结构维、信息维、分区维和分类维。结构维最为普通，它包含具有层次结构的成员；信息维包含需要计算的属性；分区维用于信息的比较，如计划销售情况和实际销售情况；分类维用于根据维的属性来分组。此外，还有一些结构上比较特殊的维，如退化维和垃圾维等。

1．结构维

结构维表示在层次结构组成中的信息量度。因此，年、月和日可以组成一个结构维。一个部门将总销售量用作一个度量，便是如何应用结构维的一个例子。与这个度量相关的是包含涉及产品的所有属性的产品信息表。可以通过产品信息表生成的维可能是“product_name”、“product_brand”、“product_category”、“product_department”和“product_family”。

在此会发现，这个产品维可以组成一个层次结构。增加一个时间信息表，就可以通过由年、月和日组成的时间信息对象建立一个时间维。通过这个度量和2个结构维，可以用SSAS确定一种特殊产品在某一特定时期的销售总量。

下面是一些普通的结构维：

客户地理位置维这个维可提供一个根据客户所在地进行归类的层次结构。客户维的典型例子是“customer_city”、“customer_state”和“custmer_country”。这个维通常用于查看不同的地理位置在销售、利润和其他客户度量方面的不同。

时间维可表明事件发生的时间。典型的时间维应该是年、月和日。

销售人员地理位置维这个维可提供一个根据销售人员所在地域进行归类的层次结构。这个维通常用来查看工作在不同地域的销售人员的销售情况和利润等。

产品维出售的产品。这个层次结构可能包括“product_name”、“product_brand”、

“product_category”和“product_department”。这个维用来查看不同类别的产品的销售利润和其他指标。

所有这些结构维都包含他们所在层次结构的属性。在结构维中层次是非常重要的，所以要在下面分别进行讨论。首先来看另外3种维：信息维、分类维和分区维。

2．信息维

信息维是计算字段建立的。用户也许想通过销售利润了解所有产品的销售总额。也许希望通过增加销售来获得丰厚的利润。然而，如果某一款商品降价销售，可能会发现销售量虽然很大，而利润却很小或几乎没有利润。从另一方面看，用户可能希望通过提高某种产品的价格获得较大利润。这种产品可能具有较高的利润空间，但销量却可能很低。因此，就利润建立一个维，就销售总量建立一个度量可以提供有用的产品信息。

用户可以对利润进行2种计算。第1种是计算每种商品的平均利润，这一方法很简单，即用销售价格减去销售人员的开销。知道了每种商品的平均利润之后，还可以用它乘以每一天的销售量从而得到每种商品每一天的总利润。

真实世界在实际应用中，也许需要进行很多项这样的计算，因为每一天的销售价格和开销都有很大差异。因此，需要一个包含每天的销售价格和每天开销情况的表。在用户查看的时间段上，每一天的销售价格和每天的开销情况都是有区别的，需要进行合计并求平均。某一天每种商品的利润乘以这一天的销售量等于当天的总利润，选定时间段的利润总和为各天的利润之和。

创建了一个包括每种商品利润和全部利润的维，就有了一个信息维。 3．分区维生成信息表

以同一结构生成两个或多个维时，要用到分区维。例如，用户可能要创建用于预测销售额和实际销售额的两个维。这两个维的结构相同，只是数值不同。另一个例子是时间维，每一年有相同的季度，相同的月和相同的天（除了闰年以外，而它不影响维）。在OLAP Services中，将频繁使用时间分区维来分割数据仓库中的数据。

例如：为下列结构生成两个同样的维。 the_day the_month the_year

一个时间维中的数据是针对1998年的，而另一个时间维中的数据针对1999年的。建立事实表时，可以把度量分割为1998年的数据和1999年的数据，这将带来许多益处。

4．分类维

分类维是通过对一个维的属性值分组而创建的。如果客户表中有家庭收入属性，那么，可能希望查看客户根据收入的购物方式。为此，可以生成一个含有家庭收入的分类维。 例如：如果有以下家庭每年收入的数据分组：0~20 000元、20001~40 000元、40 001~

60 000元、60 001~100 000元和大于100 001元。现在就可以考虑如何度量，例如，从这些分类中的每一个所购买产品的数量上来看他们的收入水平怎样和购买量怎样。另外一个可能的分类是家庭成员的性别和数量。

5．特殊维类型

特殊的维主要是在结构上区别于常见的维度，主要有退化维、垃圾维和一致维3类。 （1）当维表中的主键在事实表中没有与外键关联时，这样的维称为退化维。退化维与事实表并无关系，但对于一般在企业事件中跨越维之间数据时，所用到的约束，也就是查询限制条件（比如订单号码、出货单编号等），这时就常用退化维。以销售分析而言，通常是把出货日期作为事实的时间，而把订单日期或需求日期等作为查询条件，这里，订单日期或需求日期就是退化维。

（2）垃圾维。针对某企业事件，通常提供了必要的查询值，但是却没有直接映射信息对象产生的维表，这样的字段就是垃圾维。一般来说，如果OLAP系统包含杂乱的标识和文字属性，而且与时间维以外的维表没有关系，就可以使用垃圾维。唯一要注意的是，垃圾维必须是对企业决策潜在限制值非常重要的属性，通常会创建一个维表来存储这些属性。

（3）一致维。当有好几个数据集市要合并成一个企业级的数据仓库时，可以使用一致维来集成数据集市以便确定所有的数据集市可以使用每个数据集市的事实。所以，一致维常用于属于企业级的综合性数据仓库，使得数据可以跨越不同的模式来查询。

3.6.4 维度的层次和级别

“维”一般包含着层次关系，这种层次关系有时会相当复杂。通过把一个实体的多项重要的属性定义为多个维（dimension），使用户能对不同维上的数据进行比较。因此OLAP也可以说是多维数据分析工具的集合。

这里首先要确定维度的层次和级别。如图3-45所示，在时间维度上，按照“年－季度－月”形成了一个层次，其中“年”、“季度”和“月”成为这个层次的3个级别。同理，当建立产品维度时，可以将“产品大类－产品子类－产品”划为一个层次，其中包含“产品大类”、“产品子类”和“产品”3个级别 错误！

图3-45 维度的层次和级别 分析中所用到的这些具有层次的维度，在数据仓库中的存在形式，一般说来，有合并维分层结构和雪花分层结构2种方式。 1．合并维分层结构 合并维分层结构的最显著的特点是将不同分层结构的信息对象完全合并到同一个维中。如产品维表可能就包含产品总类、产品类别、产品详细类别及产品名称等，如图3-46所示。 合并维分层结构是星形模式的标准分类法，它有2个特点。 （1）查询简单：由于所有的分层结构都合并在同一维表中，因此不需要知道每个分层结构的表名称，也不需要额外的表连接。 （2）需要较多的硬盘存储空间：因为没有做过正规化，所以存在数据重复。 图3-46 合并维分层结构 图3-47 时间维合并维分层结构 2．雪花分层结构 这种分层结构类似正规化，所有类别用独立的表来存储数据。也就是将产品详细类别、产品类别及产品总类这3个分层结构分别独立成一个表，再用主键与外部键来维持彼此的关系。如图3-48所示。 雪花分层 结构把星形模式进行正规化，也因此产生了两种OLAP标准模型，星形模式与雪花模式，它的特点是： 节省硬盘空间：因为做过正规化，所以没有冗余数据。 查询较复杂：由于所有的分层结构都在不同的表中，因此除了需要进行表连接以外，还需要知道每个分层结构所属的表名。 图3-48是产品维度分别保存产品大类、产品子类和产品3部分数据形成的雪花分层结构。 图3-48 产品维在数据仓库中的储存形式

3.6.5 维度的缓慢变化特性及其处理

维度可以根据变化剧烈程度主要分为无变化维度、缓慢变化维度和剧烈变化维度。例如一个人的相关信息，身份证号、姓名和性别等信息数据属于不变的部分，政治面貌和婚姻状态属于缓慢变化部分，而工作经历、工作单位和培训经历等在某种程度上属于急剧变化字段。

对于剧烈变化维度，通常情况下都是一分为二进行处理的，把其中不常变动的部分单独抽出来作为一个维表，按照缓慢变化维方式进行处理；另外一部分也单独抽取出来，通常作为维度的属性进行处理。 大多数维度表随时间的迁移是缓慢变化的。比如增加了新的产品，或者产品的ID号码修改了，或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，在设计维度和使用维度的过程中，就要考虑到缓慢变化维度的处理。 维度的缓慢变化有3种不同情况，其对应的处理方法也有所不同。 1．历史数据需要修改 这种情况主要是发生在业务数据库中的数据出现错误，在分析过程中需要修改。 处理办法是用直接覆盖法，即使用UPDATE方法来修改维度表中的数据。例如商店维度中商店经理是张三，后来错了，需要改写成李四，那么，我们就在ETL处理时，直接修改维度表中原来的商店经理为李四，如图3-49所示。 错误！ 图3-49 直接覆盖法处理维度

2．新增数据维度成员改变了属性

若某维度成员新加入了1列，该列在历史数据中不能基于它浏览，而在当前数据和将来数据中可以按照它浏览。此时的解决方法是增加数据行来记录新成员。可以使用存储过程或程序生成新的维度属性，在后续的数据中将基于新的属性进行查看，如图3-50所示。 错误！

图3-50 增加数据行的方法处理维度 3．历史数据保留，新增数据也要保留 在这种需求下的解决方法是创建额外字段来记录这些数据之间的关系，例如将该维度打上时间戳，即将历史数据生效的时间段作为它的一个属性，在与原始匹配生成事实表时将按照时间段进行关联，这种方法其最大的优点在数据更改时，不需要创建额外的数据行，也不需要改变维表中的键值结构，因此可以在现有的数据行中查看所有历史纪录。而最大的缺点是由时间点来判断更新的数据很难查询，如果数据经常变化，则此方法并不适合，如图3-51所示。 错误！ 图3-51 加上时间戳来处理维度

【责任编辑：杜书 TEL

3.6.6 典型的维度设计

在数据仓库设计中，有一些维度是常用的，下面将列举几个常用的维度设计。 1．时间维度

时间维度是最常见的维度，数据仓库保留的是系统历史的数据，商务分析最基础的一个维度就是时间维度。图3-52展示了一个时间维度及其层次关系，在图中时间包含年、季度、

月、星期和日等5个层次，实际应用可能还会在月和星期之间增加旬层次，对日可能还会进一步分类，如节假日和工作日，以及周末和非周末。进行这些分类的目的是为了适应业务分析的需要。比如电信公司为了促进用户在节假日和周末多打电话，便在节假日和周末对通话资费实行优惠。服务性公司在周末和工作日也采用不同的服务方式和收费方式。 图3-52 时间维度及其层次关系 图3-53 财务时间维度

另一类型常见的时间维度是按照财年定义的时间维度，如图3-53所示，这在财务方面的分析是必须使用的。其中定义了财年（Fiscal Year ID）、财季（Fiscal Qtr ID）、财月（Fiscal MonthID）、财周（Fiscal Week ID）和财日（Fiscal Day ID）还增加了一些标识，诸如季节标识（SeasonID）、周末标识（Weekend Flag）和节假日标识（Holiday Flag）。涉及财务问题的项目需要将普通的时间信息同财务时间进行非常细致地转化。

2．地理维度

地理维度在OLAP展现中也是常见的，如图3-54所示的国家、区域和分区域。通常地理维度的展示要同地理信息系统结合起来，使得最终用户能够得到更加直观的概念。 3．机构维度 机构维通常是指实施项目的公司的机构组织情况。有的公司可能需要将公司各个部门或者各个分公司之间进行对比，这时就需要建立机构维。 某些公司的机构维和地理维有部分的重叠，比如国内子公司的划分基本上是按照省市区域进行的。但是机构维同地理维在本质是不同的，地理维描述的是地理信息，而构维描述的是公司的机构组织情况，这两个维度不能混同。比如某公司在某些地方没有开设分公司，这些地区在分公司上没有体现，但是这些地区将在地理维度上体现。 图3-55示例了某公司的机构维度层次。总公司下设各省公司，在省公司下设各个城市分公司，在地市局下设业务部门，业务局是最小的单位。 图3-54 地理维度层次 图3-55 机构维度层次

4．客户维度

任何公司都是服务于客户的，因此客户维度是必不可少的。分析客户背景信息对客户消费行为的影响，通过客户背景信息对客户群体进行合理地分类能够对公司的市场策略等方面提供有效的指导。常用的客户背景包括客户年龄、性别、婚姻状况、爱好和教育程度等，客户维度分类如图3-56所示。 数据仓库主要用于商务分析和决策支持，维度自然要体现业务特色，比如保险、金融或服务行业均有不同的分类方法，通常这些方法要针对具体用户而有所不同。在对数据仓库进行分析时，维提供了路径，沿着路径会发生数据基本聚合的“上钻”或“下钻”。这条路径位于一个层次结构中，体现的是用户对分析查询的需求，因而是先于维内容而建立的。 图3-56 客户维度分类

以上3节完成了从主题到维度的设计，可以说，概念模型和逻辑模型都已经完成了，下面的任务就是要依照逻辑模型来设计物理模型。

本文来源：https://www.bwwdw.com/article/t7u8.html