维度建模 - 模棱两可的关系答案

【问题标题】：Dimensional Modelling - ambiguous relations维度建模 - 模棱两可的关系
【发布时间】：2016-12-16 15:25:28
【问题描述】：

我一直在尝试解决一个问题，但到目前为止，我还没有达到我所说的最佳解决方案。我有一个维度（功能），需要在其他两个维度（操作和会话）中引用，而这些维度又是从同一个事实表（用户操作）中引用的。这会产生歧义，我无法完成架构：

（注意：模型的片段，而不是全部）（包括桥表以显示具有多对多关系的模型中增加的一些复杂性）

我认为问题可能在于 Dim_Features 在技术上在两个维度之间具有不同的含义，但我仍在尝试将其用作相同的含义？这意味着两者：

一个动作属于这个功能/功能区
会话具有此功能/功能区域可用（拥有）

我需要完成的是能够按某些功能可用/不可用的会话过滤/切片 Fact_UserActions，然后分析以下内容：

拥有功能“A”时使用哪些功能（例如，某些功能被拥有与其他功能被使用之间的相关性）？
拥有某项功能的用户有多少没有使用过？
功能的使用频率如何？（受拥有它的会话数量的限制，即它可以实际使用的地方）

关于我可能做错了什么或如何改进模型的任何想法？

编辑：如果它有帮助，我们想从中得到的东西是一张表格，例如：

我们可以在哪里看到某项功能对整个人群以及拥有该功能的人群的影响。

【问题讨论】：

我不知道业务逻辑是否合理，但快速浏览一下我发现了关系问题。 Fact-UserAction 和 Bridge_SeasonToFeaturesOwned 之间存在多对多关系（-to-1 和 1-to- 导致 -to-），这是不受支持的。
这不正是 Bridge 表的用途吗？建立多对多关系？在这种情况下，将 [操作] 映射到 [它所属的功能区域]，将 [会话] 映射到 [它拥有的功能]。

标签： powerbi dimensional-modeling

【解决方案1】：

我认为你的问题是你的工作方式不对。对于星型模式，Kimball 的标准建议是始终找到绝对最低的粒度，因为您始终能够聚合。

查看您希望能够回答的所有问题 - 它们都与功能的使用有关，但您用于分析功能的事实表并不处于功能使用级别。 Bridge 表的存在就是为了解决这个问题。

请务必记住，在绝大多数情况下，您的维度只能通过事实表间接关联。有时您需要一个 Bridge 表，但相对较少。

如果不知道它如何适应模型的其余部分，很难在此处提出建议的架构，但请考虑以下事项：

将 Fact_UserAction 替换为 Fact_FeatureUsage 之类的内容。
在 Fact_FeatureUsage 中有 action_id、session_id 和 feature_id。
摆脱您的 Bridge 表。

【讨论】：

事实表粒度上的有趣点。然而，我们对动作的使用感兴趣，并且一个动作恰好属于一个或多个“特征”（实际上这些代表特征组或区域，对动作进行分类）。例如。 Line.Plotted 动作将属于线条和图表的“功能”。我们目前对该问题的解决方案涉及 2 个事实表（一个是 SessionLogged，其中包括会话中的特征所有权，然后我们间接计算跨表的度量。这对我来说感觉不对，因为我们并没有真正切分 ActionUsage 事实按拥有的功能..
请记住，此答案纯粹是基于回答您在此处提出的问题，这与功能使用报告非常相关。如果您有一些确实无法分解为功能使用级别的措施，那么您可能需要另一个事实。
好的，让我们暂时忽略较低粒度的操作。即使我们有一个 Fact_FeatureUsed，其中有一个 feature_id（fact= feature used），那么你如何将该事实与该会话中拥有的相同（或另一个）功能联系起来？换句话说，我如何能够按“功能 ABC 已拥有”对功能使用事实表进行切片，以便在 ABC 所有者的上下文中查看任何功能的用户百分比？拥有单独的 Feature 维度的唯一方法是什么？如果没有大量手工制作的视觉效果，就很难概括“使用过的所有者百分比”这个问题
例如。我无法设置报告，并且在“功能 = ABC”上的页面过滤器显示“使用过它的 ABC 所有者的百分比 = 45%”。因为我必须制作某种形式的个人映射在两个相同的概念之间。也许这就是答案。是否有某种形式的额外事实表将 Feature 和 Dim_Feature 链接在一起，从而使这种特定类型的问题易于动态回答？（对不起，我正在和自己一起头脑风暴，请随时加入:)）

【解决方案2】：

我会删除与 Dim_Features 的关系，然后将其隐藏。

然后我将创建两个新表（在报告或数据视图中，转到建模功能区并单击新建表）。每个的 DAX 表达式将类似于：

Features (Actions) = 'Dim_Features'

Features (Sessions) = 'Dim_Features'

现在您拥有 Dimension 表的 2 个独立副本，您可以在“关系”窗口中为每个副本创建关系。

【讨论】：

这是我的建议之一，将功能作为 2 个单独的维度处理。这意味着它们彼此之间没有直接关系，并且很难清楚地报告每个功能的“使用过的所有者百分比”之类的内容（如果可能的话 - 除非我遗漏了什么）。这真的是唯一的出路吗？有没有更聪明的方法来组织我可能丢失的维度？
查看this link中的“为一组复杂的关系表调整交叉过滤器方向”部分
鉴于您上面的架构，我不明白您认为您的输出表可以如何工作 - 一个 Fact 行可以分配给 2 个不同的功能。
在上表中，Fact 是用户操作。用户操作（例如在图表上绘制一条线）可以被认为属于层次结构中的多个特征 - 线（与线的交互）、图表注释（与线或其他形状的任何交互）、图表（与图表的任何交互） ) 等。这就是为什么我们在动作和特征之间有这种多对多关系的原因。
想象一下，Fact_UserAction 和 Dim_Features 在同一视觉对象的不同轴上。 PowerBI 应该选择哪个关系路径，通过Dim_Actions，还是通过Dim_Sessions？ PowerBI 中不允许这种歧义，即使这对于数据库模式来说非常好。请在我发布的链接中搜索“歧义”和“歧义”。