问题标签 [dimensional-modeling]

我目前正在研究一个大致使用维度建模方法的仓库模式。

一般的想法是有一个单一的事实表，在最低粒度级别上充满感兴趣的事件度量。除此之外，当然还有一个维度表（a），其中将保存正在记录的事件的维度。这些表由dimension_id.

我的问题是：是否有可能，或者更确切地说，它是否有意义，既是维度又是度量。

一个例子可能是产品在某些搜索结果中的位置。给定产品的位置可以被认为是一个度量；用户可能希望对产品运行以下查询：

上周展示尺寸为 x = y 的产品的平均排名是多少？

同时，位置本身也可以被认为是一个维度：

显示上个月所有 position = 2 的产品的点击率

在数据仓库中解决此类问题的正确方法是什么（我们正在研究面向列的解决方案，如果这有所作为）。

一个客户要求一个响应式网页设计的宽度最小为 1px（他们最初要求 0px，但我能够说服他们这实际上并不存在）。

显然，我无法渲染字符或图像，所以我的想法是使用页面高度下方的像素以摩尔斯或二进制代码对所有内容进行编码。这可以只使用 CSS 来完成吗？

在源关系数据库中，有一个名为 CompanySurety 的表，其中 INT IDENTITY PK SuretyId 具有指向父 SuretyId 行的自引用 ExtendsSuretyId FK 列。

将这些数据引入星型模式模型，我设计了 CompanySurety 事实表（到目前为止）如下：

问题是，我如何以适当的维度方式对这种父子关系进行建模（实际上，如何在维度模型中对任何父子层次结构进行建模）？

我考虑过复制所有维度和事实列来表示父事实（因为目前，层次结构只有一层深）。但这对我来说似乎是错误的。

我是 pentaho 水壶的新手，想知道它会自动创建数据仓库、维度和事实表吗？

谁能给我一个链接，我可以从中学习水壶的全部功能？

如何从关系源填充 Dim_tbls？

给出了这些示例表：

我的目标是将这些属性放入启动模式中。我遇到的问题是加载维度表背后的逻辑。我的意思是，我会将哪些数据加载到 Dim_Product 中？tbl_product 中的所有产品？但是我怎么知道特定产品完成了多少销售呢？

我想做的分析是：

示例数据：

我有描述 [events] 和 [event_segment] 和 [event_staff] 的事实表。

[events] 由许多 [event_segment] 组成 - 例如“introduction”、“pre-check”、“1st stage”、“2nd stage”等。[events] 的键（即粒度唯一 ID）是 [event_ref]，但是 [event_segment] 的键（即唯一标识符）是复合的 - [event_ref] 和 [segment_order]

[event_staff] 对 1 个事件有很多人员，因此唯一 id 是 [event_ref] 和 [staff_id] 的组合

有几个一致的维度 - 例如日期、位置等。

我正在努力决定该数据的模型，因为我希望能够轻松比较 3 个表中的汇总事实，特别是在报告中。即 count([staff]) vs sum([event_segment_duration]) where [staff_type] = 'basic' and [event_segment_type] != 'clean up'

因为有很多员工参加一个活动，一个活动有很多部分，但我无法将员工与我必须在 [event_ref] 上分组的部分联系起来。

这“有效”，但它是否算作违反 Kimball/数据仓库标准，因为它正在加入（很好地分组）事件？

此外，[event_ref] 是否应该存在于 [event_segment] 表中，因为它应该是代理键，因此不能用于分组？

假设我们有一个代表销售办事处的维度。办公室可能会搬迁，这将是第二类变化。我们希望跟踪在旧办公地点发生的操作，以及现在在新办公地点发生的操作，并了解更改发生的时间。到目前为止，只是标准的 II 型设计。现在假设一个办公室与另一个办公室合并。也就是说，两个原本不同的办公室（“上级办公室”）的业务活动现在在一个办公室（“合并的办公室”）中进行，这可能是其中任何一个办公室的延续（物理上或人员方面）原来的办公室，或者它可能是一个新的办公室，从商业的角度来看，它是前两个办公室的延续。

报告/分析要求如下：

• 我们希望能够看到新合并办公室的所有当前活动。
• 我们希望能够看到合并后的办公室或上级办公室曾经做过的所有活动。
• 我们希望能够看到随着时间的推移在合并之前和之后在一个母公司中发生的活动，而不会看到另一个母公司的活动（至少在合并之前）。

我不确定如何使用任何 SCD 类型对此进行建模。如果我们简单地将两个父办公室条目替换为一个新条目，并相应地更新所有事实表，我们就有了一个类型 I 更改。这使我们可以很好地查看当前活动，但我们会丢失历史记录。如果我们将记录分开，我们就不会知道合并。如果我们添加第三条记录来表示合并后的办公室，我们也会丢失历史记录（它会有哪个自然键？父办公室的自然键都不合适）。

我需要使用桥接/多对多表吗？这引入了我想避免的复杂性。但是，如果这是最好的方法，那就这样吧。但是，我仍然不确定这将如何构建。也许事实表将指向一个办公室条目，并且办公室将以多对多的方式分组。报告将基于组进行，而不是直接在办公室维度上进行。

ElectricLlama 问题的答案

• 大多数用户交互是通过预制报告进行的，因此底层结构的任何复杂性都将被隐藏起来。
• 一些用户确实使用 SQL 或 SAS 来获取数据。目前，他们不太可能关心这个特定问题，但随着我们让更多用户使用这些工具，这种情况可能会发生变化。
• 目前我们没有查询作者。
• 我不认为会有多层次的合并，但我不能肯定地说不。不过，如果有的话，我会感到惊讶。
• 我不知道如何让最终用户轻松完成这种事情，这可能足以放松一些要求。

我在尝试进行多维数据库设计时遇到了这个问题。基本上，我有一个事实表（sale_fact），其中包含一个代理键、几个外键（产品 ID 的 pid、国家 ID 和日期的 cid）和销售数据。粒度或这个事实表是按天计算的。如何根据这些外键的不同组合汇总几周（或几个月）的销售数据？例如，我想总结产品 1 在国家 1 本周的销售数据（pid = 1 和 cid = 1 和日期 = 星期一），产品 2 在国家 2 的销售数据在同一周（pid = 2 和cid = 2 和日期 = 星期一）。如何在一个 SQL 中获取这些数据？示例结果集如下所示：

我在设计时间维度时处于两难境地，我不确定是否应该在时间维度中包含毫秒或为毫秒粒度创建一个维度。

我可以看到在时间维度内包含毫秒粒度的优点和缺点。

优点：

• 直接在维度键上执行计算（日期和时间维度是唯一允许在其中包含任何智能的数据仓库）。事实表的目的是衡量响应时间。

缺点：

• 时间维度变大，我可能会失去查询性能。

其他重要信息：

• 营销人员告诉我每个月预计会有 5000 万个事实（我们知道它们是怎样的，我应该为更多的事实做好准备）
• 事实将以非加法方式汇总，这是：我想要服务质量度量：平均值（半加法），中位数，百分位数。
  • 每个事实有 12 个时间检查点。

我的仓库中有三个事实，它们可以是我的关系数据库中的相关事件。它们是PhoneContact、Appointment和Donation。PhoneContact可能会导致Appoinment和/或Donation。我已经有了Apppointment和Donation及其相关维度的事实，现在正在将PhoneContact添加到我的仓库中。所有这些事实之间的共同维度是捐赠者维度，它描述了谁接到电话并进行了预约和捐赠。

如果PhoneContact确实导致了Appointment和/或Donation，我想加入这些事实，但我的理解是加入事实是一个禁忌。我将如何最好地关联这些事实？现在我想不出更好的办法，所以我正在考虑将 AppointmentID 和 DonationID 字段放在我的 Phonecontacts 事实中。

更多信息：每月大约有 120 万个电话联系人，但其中只有大约 10 万个导致约会或捐赠，所以除了不加入事实之外，每月只需将 110 万NULL个放入表中，这样我就可以获得 10 万个其他事件不太好。