问题标签 [kimball]

给定一个 SAM（软件资产管理系统），其资产有 150 多个类别（服务器、网络、台式机、笔记本电脑、扫描仪、路由器等），每个类别都有自己的属性，

应该如何减少维数？根据 Kimball 的说法，维度的数量应该保持在 20-25，但即使我会考虑为每个家庭创建一个维度（=资​​产类别集），仍然会有 70+ 个维度 + 其他维度。

我遵循了 kimball 方法，但问题是我没有在星型模式之前创建数据集市。现在我的问题是我可以在 SSAS 中创建数据集市，还是必须在 kimball 方法中的模式之前创建这些集市？

更多信息：我正在我的 FYP 中为零售店建造一个仓库。

我想知道是否有人可以阐明以下内容。

我目前正致力于在金融领域建立一个金博尔数据仓库，特别是在养老金行业。

目前，我们正在努力将估值业务流程整合到一个计划中。

要求是将所有估值（无论产品如何）存储在单个 FACT 表中以进行报告。养老金可以持有许多不同类型的产品（投资组合、证券、财产等），因此我们决定走创建超类型和子类型维度的路线。产品将有一个包含公共字段的超类型，然后每个产品都有一个包含更多详细信息的子类型维度。

我们目前遇到的问题是，可以在投资组合中持有证券，但另一方面，投资组合可能不持有任何投资但仍包含价值（可能取决于我们如何存储基础数据）。

我们不想在投资组合的事实表中创建一条估值线，如果它有基础投资，我们只是希望显示基础投资，但以某种方式将其与投资组合联系起来。如果投资组合没有我们知道的基础投资，我们希望在 FACT 表中存储一行，其中仅包含投资组合的价值，这将直接作为产品表的关键。

有人对此有什么建议吗？

这是数据如何保存在源系统中的结构。带有样本数据的表格

这是我提出的设计，所有投资维度都可以互换，产品维度是核心，但是由于基础投资控股和投资组合之间没有联系，所以这个设计失败了。估值模型

使用 Fact UpdatedFact中的 Portfolio Key 更新模型

我很难将维度表（递归/分层）连接到事实表，因为有需要处理的问题/问题：

• 维度表属于父子关系结构
• 从原始表开始，它一直在增长

对这种表进行非规范化是不适合的，因为新的实体类型进来了，它会影响维度结构。

这种类型的最佳方法是什么？请提供一个示例以及连接事实和维度后的查询语句是什么。

只是想看看是否有其他人处理过这个问题以及如何处理。

我正在构建一个星型模式 DW，目前正在构建我的维度表。它们中的大多数都很好，因为描述都有 ID，例如我有一个“动作类型描述”和一个“动作类型 ID”，我可以使用它们来构建我的 dimActionType 维度。

我的问题是一些描述字段没有相应的业务密钥 - 例如，我有一个“组角色”描述但没有业务 ID。将其放入 DimGroup 表的最佳做法是什么？我可以将不同的组角色选择到具有自动增量的表中，但是我如何将我的事实表加入到这个表中？

欣赏任何想法/想法

我正在编写季度报告。报告应如下所示：

所以例如

这里的问题是我正在使用关系星型模式，其中一个事实是半加性的，另一个是加性的，因此它们在时间维度上的行为不同。

就我而言，我使用的是 Cognos 分析，但我认为这个问题适用于任何 BI 工具。处理这个问题的最佳做法是什么？我确定我可以提出一些 sql 查询，将这两个表组合成一个表，报告从中读取，但这似乎不是最佳实践，或者是吗？另一种方法是在 BI 工具中创建一些度量，我不是这种方法的忠实拥护者，因为它似乎是最不可持续的方法，而且我不熟悉它。

我不确定 Kimball Data-Warehouse 文献中是否回答了这个问题——我找不到答案。

假设您有一个表，其中包含几个 SCD2 感知列和一些 SCD1 列。问题很简单：当 SCD1 列发生更改时，哪些记录会更新？

您是否更改所有记录，当前记录和所有历史记录？还是只更改最近的（打开的）记录？我倾向于“全部”，而我所有的同事都坚持“仅最近”。

我可以给出我意见的唯一原因是，COUNT(DISTINCT ...)当我在业务键列或 SCD1 列上运行它时，我希望给出相同的结果。

考虑一下，有两种特殊情况：如果记录没有当前版本，如果最近的记录超出范围并且没有新实例怎么办？如果我使用我的 SCD2 逻辑来准备将来会自动激活的记录怎么办？

如果我只更新最新的开放版本，那意味着我在第一个特殊情况下不会更改任何内容，而在另一种情况下，我需要更改所有未来（准备好的）记录。想一想……我相信“全部”是正确的答案。

谁能指出一个著名的白皮书网站（如 Kimball，Microsoft）给出答案？

我一直想知道 AdventureworksDW 的 FactInternetSale 表是不是一个累积快照表。它里面有一个 ShipDateKey。

根据 AdventureWorks OLTP 文档，它说 SalesOrderHeader 的 ShipDate 是“订单被运送给客户”的日期。我将这一行解释为，当订单发货时，发货日期将被更新。

这也意味着 DW FactInternetSale 中的行也需要更新。发货日期标志着订单的一个重要里程碑，这显然是累积快照事实表的行为。

那么这个表是否应该被认为是一个累积快照事实表呢？如果是这样，那么没有真正的事务事实表有什么问题吗？

在 Kimball 的数据仓库工具包书中，在这类问题中，他将 Order 事务事实表和 Shipping Fact 表严格分开，而 Order Transaction Fact 表只包含下单时记录的信息，而不会更新。Order Transaction Fact 表中的日期始终是预期日期，而不是实际日期。运输事实表包含物品的真实运输日期。之后有一个累积的快照事实表，其中包含订单的所有重要里程碑。不仅是发货日期，还有其他重要的里程碑……通过重要里程碑的日期，我们当然可以知道订单的当前状态。

在我个人看来，我认为不包含当前状态的订单事实表是完全没用的。知道订单总量但不知道有多少来自已履行（已发货）的订单以及有多少来自未履行的订单有什么意义？根据我的经验，用户（数据分析师）总是会一直使用累积快照表来完成他们的工作，因为“当前状态”的搜索谓词在他们的查询中永远不会缺席。

在我的现实世界中，我通常将这个Order（信息）事实表设计为一个累加的快照，跳过事务事实表（就像Kimball所做的那样，严格分离事物），因为我觉得这很耗时，没有用. 事务事实表通常只是对订单执行的操作（例如：运输）。

你怎么看？

在“The Datawarehouse Toolkit”中，作者多次切换他们的日期外键名称：

• 有时他们使用“日期密钥（FK）”
• 其他时候，他们根据事实命名它，例如“发票日期密钥（FK）”

为什么以及何时会发生这种情况？当同一事实中有多个日期时？当同一过程中有多个事实时？

当这种情况发生时，是否应该使用角色扮演日期维度？如果是这样，那会不会阻止 BI 工具在多个事实之间进行聚合？（因为他们有不同的日期维度、角色）

我正在阅读 Ralph Kimball 关于数据仓库和维度建模的书，在第 6 章中，有关于维度角色扮演的这一部分。

有时您会发现与每笔交易相关的其他日期，例如订单请求的发货日期。每个日期都应该是事实表中的一个外键...... 但是，您不能简单地将这两个外键连接到同一个日期维度表。SQL 会将这种双向同时连接解释为要求两个日期相同，这不太可能。

我不确定我是否理解最后两句话。如果事实表中的两个日期具有不同的值，这是否意味着您不能多次加入日期维度？为什么？