数据库仓库设计：事实表和维度表答案

【问题标题】：Database warehouse design: fact tables and dimension tables数据库仓库设计：事实表和维度表
【发布时间】：2011-02-25 10:13:12
【问题描述】：

我正在使用 RDBMS 构建一个穷人的数据仓库。我已确定要记录为的关键“属性”：

性别（真/假）
人口统计分类（A、B、C 等）
出生地
出生日期
体重（每天记录）：正在记录的事实

我的要求是能够运行允许我执行以下操作的“OLAP”查询：

'切片和骰子'
“向上/向下钻取”数据和
一般来说，能够从不同的角度查看数据

在阅读了这个主题领域之后，普遍的共识似乎是最好使用维度表而不是规范化表来实现。

假设这个断言是正确的（即解决方案最好使用事实和维度表来实现），我想在这些表的设计中寻求一些帮助。

“自然”（或明显的）维度是：

日期维度
地理位置

具有分层属性。但是，我正在努力为以下字段建模：

性别（真/假）
人口统计分类（A、B、C 等）

我在这些领域苦苦挣扎的原因是：

它们没有有助于聚合 (AFAIA) 的明显分层属性 - 这表明它们应该在事实表中
它们大多是静态的或很少更改 - 这表明它们应该在维度表中。

也许我上面使用的启发式方法太粗糙了？

我将给出一些关于我想对数据仓库执行的分析类型的示例 - 希望这将进一步澄清事情。

我想按性别和人口统计分类汇总和分析数据 - 例如回答以下问题：

男性和女性的体重在不同的人口统计分类中有何不同？
哪个人口统计分类（男性和女性）显示本季度体重增加最多。

等等

谁能澄清性别和人口统计分类是否属于事实表的一部分，或者它们是否（我怀疑）是维度表？

还假设它们是维度表，有人可以详细说明表结构（即字段）吗？

“显而易见的”架构：

CREATE TABLE sex_type (is_male int);
CREATE TABLE demographic_category (id int, name varchar(4));

可能不是正确的。

【问题讨论】：

标签： sql database-design data-warehouse olap

【解决方案1】：

不知道为什么您觉得使用 RDBMS 是穷人的解决方案，但希望这可能会有所帮助。

表 dimGeography 和 dimDemographic 是所谓的小维度；它们允许根据人口统计和地理进行切片，而无需加入 dimUser，并且还可以在测量时捕获用户当前的人口统计和地理。

顺便说一句，在 DW 世界中，详细 -- Gender = 'female', AgeGroup = '30-35', EducationLevel = 'university', etc.

【讨论】：

【解决方案2】：

星型模式搜索是维恩图交点的 SQL 等价物。正如您的示例查询清楚地显示的那样，SEX_TYPE 和 DEMOGRAPHIC_CATEGORY 是您要搜索的集合，因此必须是维度。

至于表结构，我认为您对 SEX_TYPE 的设计是错误的。对于初学者来说，在

的基础上设计查询更容易、更直观

where sex_type.name = 'FEMALE'

比

where sex_type.is_male = 1

此外，在现实世界中，性不是布尔值。大多数应用程序也应该收集 UNKNOWN 和 TRANSGENDER，这对于您似乎正在做的健康/医疗应用程序来说当然是正确的。此外，如果您有任何女性同事，它将避免一些令人不快的办公室争吵。

编辑

“我在想怎么处理新的性别类型和人口统计案例尚未在数据库”

在数据仓库中没有外键是一种时尚。但是它们提供了有用的元数据，查询优化器可以使用这些元数据来得出最有效的搜索路径。当需要处理大量数据和临时查询时，这一点尤其重要。除非您的源系统为您提供通知，否则处理新的维度值总是很困难。这实际上取决于您的设置。

【讨论】：

感谢您的反馈。现在我知道 SEX_TYPE 和 DEMOGRAPHIC_CATEGORY 是维度。这对我来说是一个新领域，所以我可能不得不再问一些对你来说似乎平庸/愚蠢的问题。请多多包涵。从上面我的理解是，我需要在事实表中有 FK，即 SEX_TYPE 和 DEMOGRAPHIC_CATEGORY 中的 PK。你能证实这一点吗？（我正在考虑如何处理数据库中尚未包含的新的 sex_types 和人口统计类别的案例）。

【解决方案3】：

通常，所有数字量和度量都是事实表中的列。那么其他一切都是维度属性。属于哪个维度比较务实，要看数据。

除了你已经收到的建议外，我没有看到退化维度的提及。在这些情况下，需要将每个事实不同的发票号或序列号时间戳等内容存储在事实中，否则维度表将与事实表成为 1-1。

如果研究正在进行，您的案例中的一个关键设计决策可能是分析与年龄相关的数据。因为人们的年龄随着时间的推移而变化，他们会在某个时候转移到另一个年龄组。根据研究开始时组是否固定，这可能会决定您希望如何聚合。我不一定说您应该有一个群体维度并通过它来达到年龄，但您可能需要在 ETL 期间确定正确的年龄/人口统计维度。但这取决于最终用途（或者通过事实表链接的两个维度角色来适应两者 - 初始人口统计数据，永远不会改变，当前人口统计数据会随着时间而改变）。

类似的情况也适用于地理。尽管您可以通过分析当前地理随时间的变化来明显地跟踪一个人的地理，但维度 DW 的要点是让所有相关维度直接与事实相关联（您通常可以通过网络在标准化模型中推导出的事物）实体关系模型 - 这些在 ETL 时被锁定）。这种冗余使得对传统 RDBMS 中维度模型的分析更快。

请注意，其中很多不适用于像 Teradata 这样的大规模并行 DW，它们在星型模式下表现不佳 - 它们喜欢所有数据标准化并链接到同一个主索引，因为它们是要分发的主索引处理单元上的数据。

【讨论】：

【解决方案4】：

您打算使用什么 OLAP/表示层工具？这些通常有自己的特性来支持多维数据集、层次结构、聚合等的构建。

正常形式通常是灵活高效的数据仓库最可靠的基础，尽管有时会对 Mart 进行非规范化以支持一组特定的报告要求。在没有任何其他信息的情况下，我建议您的目标是确保您的数据库至少处于 Boyce-Codd / 5th Normal Form。

【讨论】：