具有大部分半加性事实的建模场景

Posted 2023-03-29

【中文标题】具有大部分半加性事实的建模场景

【英文标题】：modeling scenario with mostly semi-additive facts

【发布时间】：2018-03-01 18:36:48

【问题描述】：

我正在学习维度建模并尝试创建模型。我正在考虑一个对酒店进行评分的社交媒体平台。该平台有以下数据：

酒店信息：名称和地址 用户可以给酒店打分（1-5 分） 用户可以编写 cmets 平台存储cmets的日期 酒店可以通过评论回复并存储日期 平台存储每个评分等级的总数（即：所有评分1分，所有评分2分等） 平台存储用户信息：性别、姓名、总票数和地址

首先，我尝试定义哪些信息属于维度或事实表 （这里我也查了一下哪个是加法/半加法/非加法）

我意识到我的示例有点困难，因为很难确定它属于事实表还是维度。

我想听听一些建议。有人会同意我的模型吗？

这就是我的建模方式：

酒店信息->酒店维度 用户评分 -> 附加事实 - 因为我可以将它们与所有维度聚合 用户评论 -> 半添加剂？ – 因为我可以将它们与日期维度聚合（我不知道我的论点是否正确，但我知道我每天都会有新的 cmets，这对我来说是一个将它存储在事实表中的原因 以评论形式回答 -> 与用户 cmets 相同的处理方式 评论日期->维度 所有投票的总数 (1/2/3/4/5) -> 半加法事实 - 汇总它们没有意义，因为它已经是总数，但我会得到平均值 用户信息性别和姓名、地址->用户维度 用户信息：总票数 -> 可以是维度或事实。这取决于它改变的频率。如果它经常变化，我将它存储在一个事实中。如果不是那么频繁，那么维度

我还有疑问，希望有人能帮助我：

我的问题：我应该创建两个日期维度，还是可以将两个信息存储在一个日期维度中？

第二个问题：每个用户和酒店只有一个地址。是否有论据，以在自己的层次结构中分离地址维度？我可以创建与用户维度和地址维度的 1:1 关系吗？

【问题讨论】：

维度建模是纯粹的数据库建模。出于这个原因，我将用 ERD 替换 UML。

【参考方案1】：

对于您的模型，它看起来经过深思熟虑，但这里有一些想法：

用户评论（以及对 cme​​ts 的回答）：它们是要捕获的事件（正如您所提到的，每天都有新事件）所以是事实，评论者的维度、评论类型、日期和度量是至少一个“计数”是可加的。但是您不想将大文本存储在事实中，因此您可以将其单独放在与事实 1:1 的维度中，以应对需要查询评论本身的情况。

如您所说，所有投票的总数（1/2/3/4/5）已经汇总，主要是为了性能。从原始数据本身来看，总计应该很容易，因此可能根本不值得存储它们。您还可以考虑使用列（酒店 A 有 5 个“1”票和 4 个“2”票）来更新酒店维度，以便于过滤和分类。

用户信息：总票数：它是关于用户的事实信息（维度），它取决于您是否总是只想“找出”某个人，或者您是否可能使用它来过滤其他人信息（即向我显示投了 10-20 票的用户的所有评论）。在这种情况下，您可以将总数存储在用户维度中（和/或条带，例如 10-20、20-30 的“评论数量范围”）。如果需要，您可以经常更新维度，但您是对的，它仍然只能作为事实存在。

对于日期维度，如果“grain”是“day”，那么您只需要一个维度，您可以从多个事实中引用它。

至于地址，你说得对，双方都有争论！许多人将地址分成他们自己的维度，从使用它们的其他维度引用。 Kimball 建议您可以在必要时在后台执行此操作，但希望每个维度都有自己的一组地址列（但要尽可能一致地建模）。

【讨论】：

感谢您的详细解释。你的方法很有趣！我仍然对您的建模有疑问： 1. 用户评论：为什么不在事实表中添加大文本？是因为性能的原因吗？ （例如：事实表加载时间更长？）还是有其他原因？因为两个表中的文本长度都会很长（事实和暗淡）

2. Total Number of all votes：考虑到，你的意思是这样的维度表吗？具有以下列的 DIM 酒店：名称 |地址 | 5_积分 | 4_积分 | 3_点等？如果数字发生变化，您的意思是更新数字将被替换或添加新数字？如果值经常变化，是否应该将其添加到事实表中？

SO 不是就多个方面进行长时间对话的好地方。

所以为了简短起见，1) 是的，应该避免使用文本事实来表现事实。应保留事实表以替代键和措施。 2）是的，就是这样（但取决于你的需要）。是的，号码将被替换。您应该有事实表，但根据您的需要，您也可以/而不是拥有用于查询的维度的统计信息。与往常一样，答案是“视情况而定”，通常这取决于如何最好地满足查询要求。我可以推荐从 Kimball 资源中学习。