数据仓库-事实表和维度表的设计（三）_维度建模 代理表

数据仓库的物理模型较常见的操作型数据库的物理模型有很大不同。最明显的区别是：操作型数据库主要是用来支撑即时操作，对数据库的性能和质量要求都比较高，为了防止“garbage in，garbage out”，通常设计操作型数据库的都要遵循几个范式的约束，除非少数情况下为了性能进行妥协，才可能出现冗余。而数据仓库的建立并不上为了支撑即时操作，或者说，数据仓库的数据是来源于即时操作产生的数据，而不是直接来源于即时操作。所以它的数据质量是由操作性系统来保证的，而不是由几个范式来保证的。而且为了更好的跟踪历史信息，以及更快的产生报表，数据仓库的物理模型中存在着大量冗余字段。

数据仓库的物理模型分为星型和雪花型两种。所谓星型，就是将模型中只有一个主题，其他的表中存储的都是主题的一些特征。比如货物销量的主题仓库中，每次出售记录是事实表，而时间，售货员，商品是维度，都和事实表有联系，组织起来就是星型。而如果更细化来看，商品是有种类，产地，价格等特征的，从这个角度来看，有两个主题，一个是商品出售，一个是商品本身。组织起来就是雪花型。实际项目中，由于操作型系统业务的复杂性导致本身产生了大量的数据，所以，组织起来也以雪花型居多。

那么围绕着主题，该如何设计事实表和维度表呢？也是有规律可循的。

事实表和维度表的分界线

事实表是用来存储主题的主干内容的。以日常的工作量为例，工作量可能具有如下属性：工作日期，人员，上班时长，加班时长，工作性质，是否外勤，工作内容，审核人。那么什么才是主干内容？很容易看出上班时长，加班时长是主干，也就是工作量主题的基本内容，那么工作日期，人员，工作性质，是否外勤，工作内容是否为主干信息呢？认真分析特征会发现，日期，人员，性质，是否外勤都是可以被分类的，例如日期有年-月-日的层次，人员也有上下级关系，外勤和正常上班也是两类上班考勤记录，而上班时长和加班时长则不具有此类意义。所以一般把能够分类的属性单独列出来，成为维度表，在事实表中维护事实与维度的引用关系。

在上述例子中，事实表可以设计成如下
WorkDate  EmployeeID，WorkTypeID，Islegwork，Content，
而时间，员工，工作类型，是否外勤则归为维度表。

总的来看，和其他建立主外键关系的表也都一样。但是维度表的建立是需要有层次的（虽然不是必须，但是也是典型特征），而事实表的建立是针对已经发生的事实的，是历史数据的存档，也就是说是不应该修改的。以测试部测试软件的Bug为例。每个Bug都是一个事实。这个Bug的状态在数据字典里可能设计成新建，转派，修复，拒绝等等。那么在事实表中Bug表中有一个字段为Status。当测试员或者开发人员改变了这个状态的值，事实表中该如何更新呢？是直接更新Status还是什么其他的方式？显然，为了能够追踪这个Bug的历史信息，应该是重新插入一条新的记录。那么这和以往的数据库设计有什么区别呢？可以看出对于原始记录和新插入的记录，其他字段全部是相同的，也就是全部冗余的。如果以BugID作为主键，这时候会发现主键都是冗余的（当然，插入之前只能删除主键）。所以可以看出，事实表一般是没有主键的。数据的质量完全由业务系统来把握。

例如，在AdventureWorks DW数据库中，事实表是类似于如此

事实表中的外键是指向维度表的，那么维度表又有什么特征呢？以时间维度为例

 

可以看出，维度表一般是有主键的。代表该类物质的一个单一个体，其他的字段一般都是有层次关系的，例如2009年2月19日是主键，那么它会有年--月--日这样的层次，为了方便统计，年月日不会在做聚合的时候才计算出来，而是在维护记录时已经计算出来。那么这些字段的冗余是否值得呢？可以这样解释：维度表的数据一般是比较少的，这个少是指相对事实表来讲的。因为事实表是与日俱增，而维度表则增长缓慢，所以绝对数字也不会太大。在事实表和维度表做连接查询的时候，会产生与事实表一样大的数据量，如果还需要group by Year（TimeKey）的话，其一是会增加计算，其二是由于引入了计算，索引会失效。这个代价比引入冗余字段要大的多。以AdventureWorks为例，它总共引入了日历年-月-日，财年-月-日，还有日历年-周-日，财年-周-日等等多个层次。那么它在每个层次不同级别上做聚合都是不需要引入函数来做Year（TimeKey），Month（TimeKey）这样的运算。

总的说来，事实表的设计是以能够正确记录历史信息为准则，维度表的设计是以能够以合适的角度来聚合主题内容为准则。