维度建模 - 模糊关系

Question

我一直在尝试解决一个问题，但到目前为止我还没有能够达到最优解。我有一个维度（Features），需要在另外两个维度（Actions和Sessions）中进行引用，这两个维度都从同一事实表（UserAction）中进行引用。这会产生歧义，我无法完成模式： （注：这是模型的一部分，而非整个模型） （包括桥接表以显示模型中具有多对多关系的复杂性）

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

- 操作属于此功能/功能区域 - 会话可以使用（拥有）此功能/功能区域

我需要完成的任务是能够通过会话筛选/切片Fact_UserActions，其中某些功能可用/不可用，然后分析诸如：

• 当拥有'A'特征时使用哪些功能（例如，某些特征之间的相关性被拥有，而其他特征则被使用）？
• 拥有特征但未使用的用户数量是多少？
• 特征被使用的频率是多少？（受到拥有它的会话人数的限制，即它实际上可以被使用的情况）

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

编辑：如果有帮助的话，我们想要得到的是这样的表格：

我们可以看到某个功能对整个人口以及拥有该功能的人口的影响。

- Zepee

---

我不知道业务逻辑是否合理，但是乍一看，我发现存在一个关系问题。Fact-UserAction和Bridge_SeasonToFeaturesOwned之间存在多对多的关系（对1和1对导致*-对*-），这是不被支持的。 - serdar

这不正是桥接表的用途吗？用于创建多对多关系？在这种情况下，将[操作]映射到[所属功能区域]和[会话]映射到[所拥有的功能]。 - Zepee

Answer 1

我认为你的问题在于你所处理的粒度不对。按照Kimball对星型模式的标准建议，应该始终找到最低的粒度，因为你总是可以向上聚合。

看一下你想要回答的所有问题——它们都涉及特性使用，但是你用来分析特性的事实表并不是在特性使用的层面。桥接表存在的目的是为了解决这个问题。

重要的是要记住，在大多数情况下，你的维度应该只通过事实表间接关联。有时候你需要一个桥接表，但相对而言比较少。

在不知道如何将其与模型的其余部分配合使用的情况下，很难提出建议性的架构，但是请考虑以下内容：

• 将Fact_UserAction替换为类似于Fact_FeatureUsage的内容。
• 在Fact_FeatureUsage中包含action_id、session_id和feature_id。
• 摆脱你的桥接表。

- Jo Douglass

---

关于事实表的粒度，这是一个有趣的观点。然而，我们对Action使用感兴趣，而一个Action恰好属于一个或多个“Feature”（实际上这些代表功能组或区域，对Action进行分类）。例如，Line.Plotted操作将属于Lines和Charts“Features”。我们目前解决问题的方案涉及2个事实表（其中一个是SessionLogged，其中包括会话中的功能所有权，然后我们间接地跨表计算度量..这让我感到不舒服，因为我们并没有真正按所拥有的特征切分ActionUsage事实。 - Zepee

请记住，这个答案完全基于回答你在这里提出的问题，这个问题非常关于特性使用报告。如果你有一些措施确实无法分解到特性使用级别，那么可能需要另一个事实。 - Jo Douglass

好的，让我们暂时忽略行动的较低层面。即使我们有一个包含feature_id的Fact_FeatureUsed（事实=使用功能），那么您如何将该事实与同一（或另一个）会话中拥有的Feature相关联？换句话说，我如何能够通过“Feature ABC已拥有”来切片特征使用事实表，以便我可以查看任何特征的用户在ABC所有者的上下文中的百分比？唯一的方法是拥有单独的Feature<Owned>维度吗？这使得很难推广“已使用的所有者的％”问题，而不需要大量手工制作的可视化效果。 - Zepee

我无法设置报告，并使用页面筛选器“Feature = ABC”获取“ABC所有者使用率= 45％”的显示，因为我必须在两个相同概念之间进行某种形式的单独映射。也许这就是答案。有一些额外的事实表，以一种使得动态回答这种特定类型问题变得容易的方式将Feature <Used>和Dim_Feature <Owned>链接在一起？（抱歉，我正在自己头脑风暴，请随意加入 :)） - Zepee

Answer 2

我会移除与Dim_Features的关联，然后将其隐藏。

然后我会创建两个新表格（在报告或数据视图中，转到建模选项卡并点击新建表格）。每个表格的DAX表达式可能如下：

Features (Actions) = 'Dim_Features'

Features (Sessions) = 'Dim_Features'

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

- Mike Honey

---

请查看此链接中的“调整复杂关系表的交叉筛选方向”部分：https://powerbi.microsoft.com/zh-cn/documentation/powerbi-desktop-create-and-manage-relationships/ - user5226582

根据你上面的模式，我不理解你如何认为你的输出表可以工作——单个事实行可以分配给两个不同的特征。 - Mike Honey

在上面的表格中，"Fact" 是用户操作。用户操作（例如在图表上画一条线）可以被认为属于层次结构中的多个特征 - 线条（与线条的交互），图表注释（与线条或其他形状的任何交互），图表（与图表的任何交互）等等。这就是为什么我们在操作和特征之间有这种多对多的关系。 - Zepee

假设您在同一可视化中的不同轴上拥有“Fact_UserAction”和“Dim_Features”。PowerBI应该通过“Dim_Actions”还是“Dim_Sessions”选择哪种关系路线？即使对于数据库模式而言这样做完全没有问题，但在PowerBI中不允许出现此类歧义。请在我发布的链接中搜索“ambiguous”和“ambiguity”。 - user5226582

@user5226582，是的，我知道存在歧义，这就是我想要解决的问题。Mike Honey，我明白你的意思了。我们试图使用UserAction事实来衡量不同粒度的操作和功能的使用情况！我们可以通过功能过滤UserAction，但我们不应该在那里测量功能使用情况，这指向一个新的Fact_FeatureUsed表。它还可以引用Session（+拥有的功能），但Feature（Used）绝对是一个独立的概念。现在我需要解决如何将它们映射在一起，以便我可以轻松地报告“相同”功能的所有者的使用情况。 - Zepee