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

Question

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

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

我的要求是能够运行'OLAP'查询，允许我：

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

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

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

'自然'（或明显）维度是：

• 日期维度
• 地理位置

具有分层属性。但是，我正在努力模拟以下领域：

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

我正在努力解决这些问题的原因是：

1. 他们没有明显的分层属性，这将有助于汇总（AFAIA） - 这表明他们应该在事实表中
2. 它们大多是静态的或很少变化 - 这表明它们应该在维度表中。

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

我将举例说明我想在数据仓库中进行的分析类型 - 希望这将进一步澄清事情。

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

• 在不同的人口统计分类中，男性和女性的权重如何比较？
• 其中人口统计分类（男性和女性），本季度体重增加最多。

等

任何人都可以澄清性别和人口统计分类是否属于事实表，或者它们是否（我怀疑）是维度表。？

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

'明显'架构：

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

可能不正确。

Answer 1

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

表dimGeography和dimDemographic是所谓的迷你维度;它们允许基于人口统计和地理位置进行切片而无需加入dimUser，还可以在测量时捕获用户当前的人口统计和地理位置。

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

Answer 2

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

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

设计查询更容易，更直观

where sex_type.name = 'FEMALE'

大于

where sex_type.is_male = 1

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

修改

  

“我正在考虑如何应对   新性别和人口统计的案例   尚未出现的类别   数据库“

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

Answer 3

通常，所有数字量和度量都是事实表中的列。然后其他一切都是维度属性。它们属于哪个维度是相当务实的，取决于数据。

除了你已经收到的建议外，我没有看到退化的尺寸。在这些情况下，需要在事实中存储诸如发票号或序列号时间戳之类的事情，因为每个事实都不同，否则维度表将与事实表一起变为1-1。

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

类似的事情可能适用于地理位置。虽然你可以通过分析当前的地理变化来显然跟踪一个人的地理位置，但是维度DW的要点是让所有相关的维度直接与事实相关联（你通常可以通过网络在规范化模型中得到的东西）实体 - 关系模型 - 这些在ETL时被锁定。这种冗余使传统RDBMS中的维模型分析更快。

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

Answer 4

您打算使用哪种OLAP /表示层工具？这些通常具有自己的功能，以支持构建多维数据集，层次结构，聚合等。

普通表格通常是灵活高效的数据仓库的最合理的基础，尽管市场有时非规范化以支持一组特定的报告要求。在没有任何其他信息的情况下，我建议您的目标是确保您的数据库至少处于Boyce-Codd / 5th Normal Form。