问题标签 [dimensional-modeling]

在我的 SQL Server 数据库中，我每小时都有数据。但我希望使用 SSAS CUBE 以每周的粒度每周提供这些数据。

免责声明：我以前从未创建过数据仓库。我已经阅读了 Kimball 的数据仓库工具包的几章。

背景：工厂（工厂）管理团队需要能够以各种方式对生产信息进行切片和切块，并且我们希望在我们部门的制造工厂之间具有一致的报告格式。通过业务分析，我们得出的结论是，事实粒度是每个流程完成 1 行。一个完整的过程可以意味着“机器”或“组装”。我称之为“生产事实”。

企业需要回答的问题如下：

• 流程完成时谁在工作？
• 该过程的周期时间是多少？
• 该流程正在生产的零件的序列号是多少？

我的架构包括以下一级维度。我没有超出第一级的任何尺寸，但工厂尺寸与零件类型、班次和工艺尺寸之间存在一些交叉关系。

• 零件类型（属性：代理键、零件编号、型号、变体、零件名称）
• 植物（属性：代理键、植物名称、植物缩写）
• Shift（属性：代理键、工厂键、开始 Hour24、开始分钟、结束 Hour24、结束分钟）
• 流程（属性：代理键、工厂键、生产线、流程组、流程名称、机器类型）
• 日期（典型的日期维度属性）
• 一天中的时间（一天中的典型时间维度属性）

无量纲事实是：

• 零件序列号（零件类型的实例）
• 周期
• 员工 ID *多值*

问题

我的问题是，当时可能有不止一名员工在处理这个过程。所以，我想知道是否需要更改我的模型以及如何最好地代表模型中的员工。我们不是试图保存员工信息，只是他们的公司员工 ID。我考虑了以下选项：

1. 允许在事实表的员工列中使用多个员工 ID（例如，逗号分隔）。缺点：在流程上工作的员工数量是可变的。我是否需要创建足够大的字段以容纳最多 X 名员工？X 应该是什么？
2. 为每个员工的每个生产事实创建一个记录。这意味着同一事实的记录不止一个；那会很糟糕。:)
3. 在员工维度表和事实表之间创建一个员工维度和一个“流程员工”桥接表。问题：当时在流程上工作的员工并没有出现在事实表中。
4. 创建员工维度、流程员工组表以及流程员工组表和员工维度表之间的桥接表。员工组和桥表需要 a) 预先填充所有可能的员工组合——这在任何级别上都不实用，因为我们有数千名员工——或者 b) 在 ETL 期间动态填充。4b 需要检查每个流程是否已经存在给定的员工组；如果源记录的批处理频率高于每天几次（例如，近实时报告每小时 10 次），这可能会对 DBMS/ETL 系统造成负担。

我的问题

我认为选项 3 是最可行的选项，但我有一些保留意见。是否有潜在的注意事项？我应该考虑其他替代方案吗？是否可以将参与该流程的员工从事实表中剔除？

谢谢你的任何建议。

我正在研究客户维度表大于事实表的数据仓库项目。维度表和事实表是从 CRM 系统创建的。

事实表监控活动，例如向客户发送信件或客户呼叫寻求帮助。一半的客户没有活动，其余客户的活动很少；大多数有活动的客户只有一个活动。

我不确定星型模式是否是项目的最佳解决方案。您是否从事过类似的项目以及解决方案是什么。

我正在参与创建利用 Kimball 星型模式方法的报告软件。整个团队（包括我）都没有使用过这项技术，所以我们是新手。
到目前为止，或系统中有几个维度和事实表。例如：
- DIM_Customer（客户维度表）
- DIM_BusinessUnit（业务单位维度表）
- FT_Transaction（事实表，每笔交易的粒度）
- FT_Customer（客户事实表，客户 ID 和截止日期在复合 PK 中）

这是 FT_Customer 的当前结构：
- customer_id #（客户 ID，复合 PK 的一部分）
- as_on_date #（观察日期，复合 PK 的一部分）
- waic (KPI)
- wat (KPI)
- waddl (KPI)
- wadtp ( KPI)
-aging_bucket_current (KPI)
-aging_bucket_1_to_10 (KPI)
-aging_bucket_11_to_25 (KPI)
- ... ...
字段 waic、wat、waddl 和 wadtp 与交易支付延迟有关。这些字段是通过针对按 customer_id 和 as_on_date 分组的 FT_Transaction 表的聚合查询计算的。
字段aging_bucket_current、aging_bucket_1_to_10 和aging_bucket_11_to_25 包含按付款延迟分类的交易数量。例如，aging_bucket_current 包含按时支付的交易数量，aging_bucket_1_to_10 包含延迟 1 到 10 天支付的交易数量……
此结构用于从 PHP Web 应用程序和 Cognos Studio 生成报告。我们讨论了重组 FT_Customer 表，以使其更适用于 Cognos 等外部系统。
FT_Customer 的新提议结构：
- customer_id #（客户 ID，复合 PK 的一部分）
- as_on_date #（观察日期，复合 PK 的一部分）
- kpi_id #（KPI 的 id，指向 DIM_KPI 维度表的外键，复合 PK 的一部分）
- kpi_value（值 KPI）
- ... ...
对于这个提案，我们将有额外的维度表 DIM_KPI：
- kpi_id #
-标题
此表将包含所有 KPI（wat、waic、waddl、老化桶...）。
FT_Customer 的第二个结构显然会比当前结构有更多的行。
FT_Customer 哪种结构更通用？
将两种结构保存在单独的表中是否可以接受？这显然会给 ETL 层带来额外的负担，因为有些工作会重复两次，但另一方面它会更容易生成各种报告。

提前感谢您的建议。

我正在实施 DataWarehouse 日期维度。根据我的情况，我必须将 10 月和 1 月之间的日子标记为Season_A4 月和 8 月之间的日子Season_B。

我创建了dimDate如下表：

我正在尝试对分层的维度进行建模，并且在每个级别上具有不确定数量的特征。下面是一个关于如何在数据源中构建表的示例

Product -> SubCategory 和 SubCategory -> Category 之间存在一对多关系。每个 Product/SubCategory/Category 还引用了它们各自的功能表。然而，特征的数量不是固定的，可能是 0。

我正在尝试构建的事实表需要处于产品级别，并且没有这些功能，我可以将这些中的每一个作为列创建一个维度，如下所示：

但随后所有功能都会丢失。

是否可以将维度保留在产品级别并保留每个层次结构中的所有功能？或者是否有必要制作一个包含层次结构中所有特征的所有组合的桥接表？我是否需要将级别分解为它们自己的维度（即 Dim_Product、Dim_SubCategory、Dim_Category）？每个层次结构级别也有固定的属性，所以如果单个维度是合适的选项，是否可以将这些属性展平并作为列包含在内？

我们有一个表格模型，它有 3 个事实和几个维度。

在这 3 个事实中，有 2 个是关于帐户和产品的。

与客户帐户相关的事实。有多少是活跃的，当前余额是多少，一开始的余额是多少等等。

Product Fact 是关于客户拥有的不同补充产品。他/她可能有也可能没有补充产品。现在这有诸如客户在不同产品中的欠款、回扣金额等事实。

现在他们都有 Dimension Account 作为共同的 Dim。

帐户和产品之间的关系是 1-M。如果一个帐户有补充产品，它可以是 1、2 和最大 3。如果没有，它是 1-0 :)

我们遇到的问题是，如果我们想通过 Account Dim 属性来分割这两个事实，我们只会得到具有补充产品的帐户。因为我相信表格模型适用于 INNER JOINS。在这种情况下，我想要 OUTER JOIN。由于我希望所有帐户都通过查询以及我匹配补充产品的位置然后是该产品的事实。

任何帮助表示赞赏。

我正在查看旧的数据仓库，并且在无事实事实表 (Fact_contact) 和 Dim_Incident 之间遇到了不寻常的 1:1 关系。

通常，Fact_Contact 用于记录案例/票证/查询。一些客户是匿名的；因此，存在用于不同计数的 uniqueCustRef 和 CustomerRef “事实”。

事实和维度表之间的 1:1 关系感觉不对。这是推荐的解决方案吗？目前，没有文档说明它为何如此设计。

谢谢你。

在数据建模中，一个维度是否可以接受另一个维度的代理键作为属性，还是应该始终是业务键？

我有一个项目维度，它有一个部门编号作为属性。我也有一个部门维度。Item Dimension 是否可以将 SK 保存到 Department Dimension 或仅保留业务 key？

维度表也可以变成事实表吗？例如，我有一个客户维度表，其中包含名称、性别等标准属性。

我需要知道今天、上个月、去年等使用 SSAS 创建了多少客户。

我可以使用客户键和日期键创建不露面的事实表，或者我可以使用相同的客户维度表，因为它已经具有这两个键。

将客户维度表用作事实和维度是否正常？

谢谢