标签: dimensional-modeling

我们刚刚开始设计一个新的数据仓库，我们正在尝试设计日期和时间维度的工作方式。我们需要能够支持多个时区（可能至少是 GMT、IST、PST 和 EST）。我们最初认为我们将有一个广泛的组合日期时间维度，大约 15 分钟的粒度，这样我们的事实表中有一个键，所有支持的时区的所有不同日期时间数据都在一个维度表中。（即日期键、GMT 日期、GMT 时间、IST 日期、IST 时间等...）

Kimball 建议从一天的时间维度中设置一个单独的日期维度，以防止表变得过大（数据仓库工具包第 240 页），这听起来不错，但这意味着我们在每个时区的事实表中有两个键我们需要支持（一个用于日期，一个用于一天中的时间）。

由于我在这方面非常缺乏经验，我希望有人知道这两种方法之间的权衡，即性能与所有不同时区键的管理。也许还有其他方法，我看到有些人谈论在每个时区的事实表中有一个单独的行，但这似乎是一个问题，如果你的事实表有数百万行，那么你需要将它翻两番来添加时区.

如果我们使用 15 分钟的粒度，我们的日期时间维度表中每年将有 131,400 (24 * 15 * 365) 行，这对性能来说听起来并不太可怕，但在我们测试之前我们不会确定原型查询。在事实表中使用单独的时区键的另一个问题是查询必须根据所需的时区将维度表连接到不同的列，也许这是 SSAS 为您处理的事情，我不确定.

感谢您的任何想法，-马特

我一直在研究 Amazon 的 Redshift 数据库作为我们数据仓库未来可能的替代品。我的经验一直是使用维度建模和 Ralph Kimball 的方法，所以看到 Redshift 不支持自动递增列的串行数据类型等功能有点奇怪。

但是，AWS 大数据博客最近有一篇关于如何为星型架构优化 Redshift 的博客文章：https : //blogs.aws.amazon.com/bigdata/post/Tx1WZP38ERPGK5K/Optimizing-for-Star-Schemas -and-Interleaved-Sorting-on-Amazon-Redshift

我的问题是在 Redshift 中加载星型模式的最佳实践是什么？我在 Redshift 的任何文档中都找不到答案。

我倾向于将我的文件从 S3 导入到临时表中，然后在插入到目标表之前使用 SQL 进行诸如查找和生成代理键之类的转换。

这是其他人目前正在做的事情吗？是否有值得花钱的 ETL 工具使这更容易？

我和我们公司的另一位 DBA 的任务是审查供应商为我们开发的数据库设计。供应商表示他们使用 Kimball 作为其设计的基础。（注意：我不是在寻找 Kimball 与 Inmon 等的论点。）他们设计了一个具有多个事实和维度的集市。

现在平心而论，我们公司从来没有设计过一个单一的市场。我们一直让顾问这样做。我们从来没有被派去上课或做任何事情。所以我们对仓储/集市/维度建模等的知识是基于我们所拥有的一点经验，我们可以在互联网上找到的内容，以及自读（我们有 Inmon 和 Kimball 的书，并正在努力通过它们） .

既然已经为我的知识水平设置了舞台，我们就来到了设计挑战。

有一个名为“索赔损失统计”的事实表（用于保险）。他们试图同时获取索赔的付款（累计到每月的水平），然后是准备金中的资金（有点像索赔的银行账户）。他们希望看到每月的付款金额（没什么大不了的）。但他们希望看到准备金的账户当前余额。

我举一个形象的例子。

假设我们为索赔设置了 1000 美元的准备金。这被搁置了（所以在某些方面它的功能有点像银行账户）。

2014 年 10 月，我们尚未支付任何款项。因此，企业希望查看 10 月底的付款和准备金余额。

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------

然后十一月来了。我们支付 100 美元、150 美元和 75 美元。他们希望看到这些合计金额和余额中的准备金如下：

-----------------------------------------------
-  MONTH_YEAR  -  PAYMENTS -  RESERVE_BALANCE -
-----------------------------------------------
-      102014  -      0.00 -          1000.00 -
-----------------------------------------------
-      112014  -    325.00 -           675.00 -
-----------------------------------------------

然后说我们在 12 月付款为零，然后在明年 1 月再付款 …

我构建了一个 SSIS ETL 来将各种数据源（一个来自 MySQL，两个来自 SQL Server）集成到一个单独的 SQL Server 关系和规范化数据库中，我称之为 [NDS]。

SSIS ETL 处理类型 2 更新，因此 [NDS] 生成代理键和 SCD 表包括一个 [_EffectiveFrom] 时间戳和一个可为空的 [_EffectiveTo] 列，并且对链接所有的自然键和漂亮的外键有约束数据一起。

现在，我想用它构建一个 SSAS 维度数据库，没过多久我意识到我正在为雪花模式设置自己：

所以我正在考虑添加一个新的 [DDS]（关系）数据库，以创建实际的维度和事实表，这些表将为 SSAS 数据库提供 DSV。

这个 [DDS] 数据库将尽可能地非规范化，以便“扁平化”事实和维度（例如，[OrderHeaders]+[OrderDetails] 到 [Orders] 事实表，以及 [CustomerStores]+[Customers]+ [SalesReps] 到一些 [Customers] 维度表中） - 这样做不仅应该让我更容易在 SSAS 中构建维度层次结构，还应该更容易提出实际的星型模式。

不过我有几个问题：

• 我可以重用现有代理键的子集吗？我正在考虑采用最细粒度的现有键并将其作为维度键。这是一个好方法，还是我应该忽略 [NDS] 代理键并让 [DDS]（关系数据库）生成一组新的代理键？
• 如何处理SCD？例如，当源系统中的某些特定字段发生变化时，“材料”和“供应商”将在 [NDS] 中生成新记录......我想我必须设计 SSIS ETL 以仅加载“最后一个图像”记录进入 [DDS] 数据库，然后在该过程中重新实现类型 2 更新，即将 [NDS] 视为保留历史记录的“源系统”，同时复制此 [DDS] 数据库中的所有内容。但是，为什么我需要在 [NDS]和[DDS] 中保留历史记录？显然有些不对劲。

我是在为 Big Mess™ 做好准备，还是在正确的轨道上？

据我所知：- 当维度表不能与事实表直接关联时，使用桥接表。

例如，在银行的数据仓库中，由于多个客户可以与同一个银行帐户相关联，因此不能使用客户 ID 作为事实表和客户维度之间的链接来存储客户余额的事实表。（即联名账户）

所以使用事实表存储账户ID和账户维度和客户维度之间的桥接表来区分。

但是它们与解决事实表和另一个维度之间多对多关系的辅助表有什么不同呢？

我正在尝试设计一个星型模式事实表以及一些围绕它的维度表。如果我再利用被称为自然键customer_key同时在fact_table和dim_customer当时我没有看到调用朦胧的东西和查找表之间的差异。此外，如果我每次都需要更新，customer_name我将丢失在录制时代表此事实的历史数据。尝试对暗表和事实表进行建模时，我缺少什么？

我想了解关系“查找”表技术和数据仓库“维度”表之间的区别？

fact_table               dim_customer          dim_product
-------------            ------------          -----------
customer_key             customer_key          product_key
product_key              name                  name
units_sold               email                 description
unit_price

请原谅我在这个问题中可能表现出的任何无知。我是数据仓库新手。

这是我一直在努力解决的一个思想问题。我对事实表中维度值的重复组合的概念有一种发自内心的反感。我已经阅读了很多关于当事实表中的维度组合没有形成唯一键时存在问题的信息。但是，我想了解可能出现的分析失败的确切类型。

请注意，我将事先规定，假设的丑陋事实表具有相同粒度的数据。 假设所有销售都是唯一报告的，但销售时间的最细粒度是一天。显然会有事务共享相同的维度值组合。因此，这种方法不会按照良好实践通常规定的方式汇总每天的交易。

我认为使用标准聚合的简单 DW 查询仍然是正确的。“简单”是指查询中只引用了一个事实表。在聚合/分析度量的通常形式中，我认为查询会产生正确的结果。

尝试通过组合所有维度来选择唯一的事实行会产生一种失败情况。我相信这些类型的查询实际上是未知的；我认为它们没什么用，除非用户想要真正深入到所有维度的最精细级别。我的想法正确吗？

我能看到的唯一可预测和常见的失败案例来自跨事实查询。在这里，额外的基数可能会乘以任何事实表中使用的任何度量。

对于我的学生（以及我的公司工作），我经常被问到“如果我不遵守这条规则会发生什么坏事？” 现在我担心我没有所有的答案。

预先感谢您的想法和答案。

我有一个包含来自零售业务的库存盘点数据的多维数据集。它有 2 个度量组 - 一个包含在每个盘点批次中计算的库存单位数（与产品、批次和时间维度相关），另一个包含产品价格（仅与产品维度相关）。

price 度量组中的度量使用 Min 和 Max 运算符（即它们显示 Products 维度的选定成员的最低或最高价格）。

我似乎已经正确配置了多维数据集和维度（价格度量按预期显示）......除了以下情况：

如果我在 Excel 中查询多维数据集并按时间和批次获取单位，我会看到预期的结果（见下图，按时间 = 2015 过滤，并隐藏没有数据的行），即仅包含所选单位事实数据的批次时间维度成员。

如果我现在添加一个价格度量（不更改任何过滤器），Units total 不变（如预期），但我现在可以看到Batch 维度中的每个成员（见下图）。这对最终用户来说是一个问题，因为他们只想查看先前选择的批次中产品的价格。

从技术角度来看，这是有道理的 - 价格事实与时间无关，因此不能像单位那样被我的时间过滤器过滤。

我可以做些什么（在多维数据集设计或 Excel 中）消除给定过滤器没有单位的 Batch 成员？注意：我无法让用户编写 MDX 查询 - 报告构建需要保持“点击”！

编辑 27/1（添加额外的屏幕截图以说明根据 TomV 的回答设置 Ignore Unrelated Dimensions = False 的奇怪副作用）

假设在 Postgres 数据库中，您有一个名为 的表party，它可以有少于 5 个明确定义的，party_types例如“人”或“组织”。

您会将存储party_type在party表中（例如party_type = 'Person'）还是对其进行标准化（例如party.party_type = 1和party_type(id, name) = (1, 'Person')）？
为什么？

如果我想用一个术语来指代度量/指标和维度，什么是行业公认的好的表达方式？

指标也常用于 UI 中，例如Google Analytics或Tableau。

我的问题的上下文是针对 UI 的。如果存在，我想对它们进行分组，并使用行业公认的名称来引用它们。