接上文：数据库星型模式结构与创建指南（上）

　　事实粒度

　　数据的粒度或频度由每个维表的最小级别的粒度决定。例如，事实表可以存储每种产品每周或每月的总数，粒度越低，表中的记录数就越多。粒度也决定了用户可以下钻到的数据事务级别。

　　数据库星型模式的优点是低一级的事务可以汇总到事实表的粒度。这加速了作为决策支持过程一部分的查询性能。然而，要创建立方体(Cube)，也不一定总是要做事实表的聚集或汇总。

　　事实表大小

　　前面讨论了500种产品如何在200家门店中销售，如果累积10年粒度到天的数据，就会在事实表中产生3.56亿条记录。这是表的最大容量。数据库的星型模式不能存储0值，除非这个0值是有意义的。所以，如果某一天某种产品在某个门店没有销售，系统就不会保存这些为0 值的记录。

　　即使事实表是很稀疏的，仍然可以在数据库中存放极大数目的记录，占用几乎所有的磁盘空间。粒度越低，事实表越大。在前面的例子中，如果粒度从天变到周，就有可能减少大约5200万条记录。

　　事实表中字段的数据类型要尽可能的小。在大多数事实表中，所有的字段都是数字型的，其存储空间比定义在维表中的长描述字段要小。

　　最后，注意每增加一个维度都会极大地增加事实表的大小。如果在前面的例子中仅仅增加一个包括20种可能值的维度，就有可能增加73亿条记录。

　　变更属性

　　对于数据库中的星型模式，数据库的属性变更是个问题。例如，图1中的商店维度，如果由于某种原因，商店的区域、地区或地段要改变，那么历史销售的统计数据就不准确了。如果只是在原有的记录上简单地更新了商店的地区，该地区的总销售额还是用目前的结构。这样业务就会“丢失”了历史。

　　事实上，公司可能想看看在前一年该区域中商店的销售额。更常见的是，业务并不想改变历史数据。一般的方法是为商店创建一个包含新区域的新记录 ，但保留原来的商店记录不变，因而该区域销售的历史数据也不变。这样公司要将商店的情况与历史比较，就只能保留是以前的Storeid。解决方法是保留已有的商店名(源系统中的主键)记录，另外增加 开始日期和结束日期字段来表示每条记录何时是有效的。商店ID是一个保留键，所以每条记录有不同的商店ID，但有相同的商店名称，允许为商店存放访问时间，而不必考虑其结构。

　　聚集

　　事实表中的数据总是聚集到事实表的粒度。用户常常要看更高级别聚集值。例如，他们可能想将销售数据按月汇总或按季度汇总。此外，用户可能想知道产品或类别级的汇总数据。

　　数字值可以用 标准的SQL语句来计算，但是这种计算很花时间，因此，数据库中的星型模式，可以通过预先计算并将数据存放在事实表中从而能更好地存放更高级别的聚集数据。这要求最低级别的记录有值。例如，时间维记录了实际保存的周数，可能在DayOfWeek字段中有一个9这个值来表示这个特定的记录保存着本周的汇总数。

　　第二种方法是创建另外一个事实表，但粒度是周。这种方法对于存放不同的汇总级别比较有效，但是在检查可能需要的表的数目时问题就来了。为了按产品汇总到周、月、季度和年级别，除了真正的事实表或者是“天”的事实表以外，还需要4个事实表。然而，任何其他的组合，例如按产品子类的周汇总，或按商店的月汇总，这都需要它们自己的事实表。

　　立方体结构

　　以上方法在过去曾经使用，但是现在还有更好的方法。这种替代方法通常是构建立方体结构来保存预先计算的值。除了数据库星型模式外，cube设计的目的是要解决在不同级别计算汇集并能对查询快速响应这类问题的。

　　可能会有已经创建好的数据库模式可用，但如果要选择数据仓库的话，还是要考虑到有多个用户使用，同时会有多个查询运行这样的需求。如果组织中存在这种需求的话，还要支持多个引擎，连接大量的表来运行一个查询。在做任何购买的决定以前，你可能都要测试数据仓库模式以确保与你的业务需求一致。