数据仓库设计小知识之一个属性的维度设计

咱们一般在数据仓库的设计中碰到这种问题：在维度设计中若是这个维度只有一个属性，那咱们面临的选择是为这个属性单首创建一个维度，仍是将这个维度的属性直接放在事实表中做为事实表的一部分？

假设这里有一个维度，一般在设计上至少会有两列（DimKey 和 DimAttribute 属性），事实表经过 DimKey 关联到这个维度。首先，在查询阶段多表的 JOIN 关系比较单表的查询在效率上确定要低一些，咱们来看下下面的这个例子：

CREATE DIM_TABLE
(
 DIM_KEY  INT PRIMARY KEY IDENTITY(1,1),
 DIM_ATTR NVARCHAR(20)
)

CREATE FACT_TABLE
(
 DIM_KEY INT FOREIGN KEY REFERENCES DIM_TABLE(DIM_KEY),
 MEASURE DECIMAL(18,2)
)

一个典型的星型结构的查询以下：

SELECT D.DIM_ATTR,
       SUM(F.MEASURE) AS TOTAL
FROM FACT_TABLE AS F
INNER JOIN DIM_TABLE AS D
ON F.DIM_KEY = D.DIM_KEY
GROUP BY D.DIM_ATTR

若是把这个属性直接放在 FACT 表中，结果和查询以下：

CREATE TABLE FACT_TABLE_2
(
 DIM_ATTR INT FOREIGN KEY REFERENCES DIM_TABLE(DIM_KEY),
 MEASURE DECIMAL(18,2)
)

SELECT SUM(MEASURE) AS TOTAL
FROM FACT_TABLE_2
GROUP BY DIM_ATTR

咱们的查询和聚合更加简单，从查询效率上来讲要更好一些。可是咱们一般又为何会选择将这个单独的属性仍是放在维度表中，这里有如下几个缘由是咱们须要考虑的：

1. 若是事实表很是庞大的话，使用 DIM_KEY INT 类型 4 Bytes 相对于 DIM_ATTR 的 NVARCHAR(20) 类型能够明显的减小事实表的体积。

2. 若是这个属性值在源业务系统发生改变的话，就意味着咱们要更新事实表中全部与该属性相关的属性值。

3. 有可能今天这个维度确实只有一个属性，可是谁又能确保这个维度之后不会添加别的相关的属性呢？

数据仓库的设计是一个迭代的开发过程，开发一年，维护若干年，若是咱们能够考虑到以上缘由，就能够很清楚的考虑到在设计阶段是否有必要将单一属性挑选出来做为维度来设计了。

更多 BI 文章请参看 BI 系列随笔列表 (SSIS, SSRS, SSAS, MDX, SQL Server) 若是以为这篇文章看了对您有帮助，请帮助推荐，以方便他人在 BIWORK 博客推荐栏中快速看到这些文章。