数据仓库学习笔记三

太上有立德，其次有立功，其次有立言，虽久不废，此谓不朽。——《左传》
简单解释：
事实表就是交易表。
维度表就是基础表。
二者的区别：
维度表的冗余很大，主要是因为维度一般不大(相对于事实表来说的)，而维度表的冗余可以使事实表节省很多空间。
事实表一般都很大，如果以普通方式查询的话，得到结果一般发的时间都不是我们可以接受的。所以它一般要进行一些特殊处理。如SQL Server 2005就会对事实表进行如预生成处理等。
事实表一般是没有主键的，数据的质量完全由业务系统来把握。

数据模型作为一种数据仓库的设计基础，在实际应用中还存在许多缺点。考虑图3 - 5 6所

示的简单数据模型。

图 1

图3 - 5 6中所示的数据模型中有四个相互关联的简单实体。如果数据库设计只需要考虑数
据模型的话，可以推断所有的实体都是平等关系。换言之，从数据模型的设计角度来看，所
有的实体之间的关系是对等的。仅仅从数据模型的角度来着手设计数据仓库会产生一种“平
面”效应。实际上，由于种种原因，数据仓库的实体绝不会是相互对等的。一些实体，要求
有它们自己的特别处理。为了明确为什么从数据模型的角度看一个组织中的数据和关系会发
生失真，根据在数据仓库中建立实体时将载入数据实体的数据量，我们来考虑数据仓库中数
据的一种三维透视。图3 - 5 7表明了这种三维透视。代表供应商、客户、产品、发货的实体被
稀疏地载入，而代表订单的实体则大量地载入。将会有大量的数据载入代表订单实体的表中，
而在代表别的实体的表中载入的数据量则相对较少。由于大量的数据要载入订单实体，因此
需要一种不同的设计处理方式。

图2

用来管理数据仓库中载入某个实体的大量数据的设计结构被称为“星型连接”。图3 - 5 8给
出星型连接的一个简单例子。“订单”位于星型连接的中央。它是被大量载入数据的实体。在
其周围分别是“产品”、“客户”、“供应商”和“发货”实体。这些实体仅仅会产生不大的数
据量。星型连接中央的“订单”被称作是“事实表”，而其周围的其他实体—“产品”、“客
户”、“供应商”和“发货”则被称为“维表”。事实表包含了“订单”独有的标识数据，也包
含了订单本身的独有数据。事实表还包含了指向其周围的表—维表的外键。如果非外键的
信息经常被事实表使用，那么星型连接内的非外键信息将会伴随外键的关系共同存在。例如，
如果“产品”的描述将被“订单”处理过程经常用到的话，那么这个描述将会与产品号一起
存储在事实表中。

图3

可以有任意多个外键与维表相关。当有必要检查外键数据与事实表中的数据时，就创建
一个外键关系。
创建和使用星型连接的一个有趣的方面是，在很多情况下，文本数据与数值数据是分离
开的。考虑图3 - 5 9所示的图表。文本数据常出现在维表中，数值数据常出现在事实表中，这
种划分似乎在所有情况都会发生。
创建和使用星型连接的好处是可以为决策支持系统的处理优化数据。通过数据预连接和建立
有选择的数据冗余，设计者为访问和分析过程大大简化了数据，这正是数据仓库所需要的。应该

注意，如果不是在决策支持系统数据仓库环境中使用星型连接，则会有很多的缺点。在决策支持
系统数据仓库环境以外，常有数据更新，而且数据关系的管理要在秒的一级上进行。在这种情况
下星型连接在创建和维护上就是很麻烦的数据结构。但是由于数据仓库是一个装载—访问环境，
它包括很多历史数据，且有大量的数据要管理，因此，星型连接的数据结构是十分理想的。

图4

图5

是不是星型连接结构的存在意味着数据模型不是设计数据仓库的基础了呢？完全不是！
数据模型对于大多数数据仓库环境的设计来讲，仍然是非常有用的一种结构。然而，星型连
接有它本身的恰当位置。图3 - 6 0说明了数据仓库决策支持系统的设计中星型连接和数据模型
是怎样配合起来使用的。星型连接应用于设计数据仓库中很大的实体，而数据模型则应用于
数据仓库中较小的实体。