Mat*_*lee 10 data-warehouse sql-server ssas ssis dimensional-modeling
我们刚刚开始设计一个新的数据仓库，我们正在尝试设计日期和时间维度的工作方式。我们需要能够支持多个时区（可能至少是 GMT、IST、PST 和 EST）。我们最初认为我们将有一个广泛的组合日期时间维度，大约 15 分钟的粒度，这样我们的事实表中有一个键，所有支持的时区的所有不同日期时间数据都在一个维度表中。（即日期键、GMT 日期、GMT 时间、IST 日期、IST 时间等...）
Kimball 建议从一天的时间维度中设置一个单独的日期维度，以防止表变得过大（数据仓库工具包第 240 页），这听起来不错，但这意味着我们在每个时区的事实表中有两个键我们需要支持（一个用于日期，一个用于一天中的时间）。
由于我在这方面非常缺乏经验，我希望有人知道这两种方法之间的权衡，即性能与所有不同时区键的管理。也许还有其他方法，我看到有些人谈论在每个时区的事实表中有一个单独的行，但这似乎是一个问题，如果你的事实表有数百万行，那么你需要将它翻两番来添加时区.
如果我们使用 15 分钟的粒度，我们的日期时间维度表中每年将有 131,400 (24 * 15 * 365) 行，这对性能来说听起来并不太可怕，但在我们测试之前我们不会确定原型查询。在事实表中使用单独的时区键的另一个问题是查询必须根据所需的时区将维度表连接到不同的列，也许这是 SSAS 为您处理的事情，我不确定.
感谢您的任何想法，-马特
将日期和时间分开将使您可以轻松地按时间进行聚合。例如：如果您想运行查询以查找一天中最繁忙的时间段。使用单独的时间维度很容易执行此操作。
此外，您应该只有一个时间键。决定 GMT/EST 时间 - 然后在事实表中使用它。如果您需要基于其他时区运行报告，只需在您的应用程序或查询中转换它。
只是关于我们如何决定实施我们的 DataWarehouse 以支持多个时区并尽可能高效的跟进：我们选择创建一个时区表（id、名称等...）以及一个“时区”桥”表看起来像这样：
time_zone_bridge
---------------
date_key_utc
time_key_utc
timezone_id
date_key_local
time_key_local
这样我们就可以保持正常的日期和时间维度表很小，我们所有的事实都链接到 UTC 日期/时间键，然后如果我们需要按不同的时区报告/分组，我们只需要通过时区桥表加入并将本地日期/时间键链接回日期和时间维度表。我们使用从 SSIS 调用的 C# 代码填充我们的时区桥表，因为这比直接从 SqlServer 执行 TZ 内容要简单得多。
| 归档时间： |
|
| 查看次数： |
12299 次 |
| 最近记录： |