我是数据仓库实践的新手，在学术练习的背景下，我想使用所选兴趣领域的数据集创建一个星形模式。因此，我和我的同学选择了一个国家一年中发生的车祸数据集。
问题是，在很多情况下(如果不是最多的话)，涉及的汽车不止一辆。因此，如果我选择将"事故"事件作为事实表，并将"驾驶员"、"汽车"、"伤亡"、"地点"、"意外事件"等作为维度，当维度"车辆"、"驾驶员"one_answers"伤亡"是多值的时，如何在星形模式中转换这些事件？例如，我可以有3辆车参与，3名司机和7名伤亡人员。考虑到星形模式的使用是强制性的。
此外，据我所知，事实表在测量中通常会有数值。它是否也有分类变量作为测量？
尺寸建模中一个非常重要的概念是晶粒。Ralph Kimball(如果你在学习维度建模，你会一次又一次地遇到他的工作)强调，从尽可能低的粒度进行建模非常重要。这使您能够以尽可能多的方式对数据进行切片和骰子，从最低粒度到任何更高粒度进行汇总。
很多时候，当你发现其中一个问题时，一切似乎都是多对多的，问题实际上是你为有问题的事实表选择了错误的粒度。向Nick.McDermaid(他在评论中建议了这种粒度变化)道歉，"个人参与事故"的粒度比"事故"低，因此将事实表的粒度降低到至少那个级别——并创建事故维度——非常有意义。
不过，这可能不是最低粒度；例如，如果您的数据集跟踪受伤情况，则每个参与者可能都有多处受伤。因此，在这种情况下，事实表中的"受伤"可能会更好——你需要在受伤维度中有一行显示"没有受伤"，以防包括那些没有受伤的参与者。因此，你应该做的第一件事不是决定你的事实表是什么，而是筛选数据，并试图找出你的最低粒度是什么；一旦你做到了这一点，你就应该很好地掌握你的事实表将围绕什么建模，以及你需要哪些维度。
维度建模可能有点难解决，因为有多种方法可以做事情，而最正确的方法往往看起来不太明显，尤其是当你从一个习惯于更规范数据结构的背景中移动时。我建议首先尝试使用最基本的表类型来建模，即尽量避免雪花表、桥接表等，看看你是否能想出一个避免这些技巧的解决方案。通常情况下，这将导致更好的模型(即导航更简单、查询性能更好、可用于回答更多问题的模型)。
尼克.麦克德迈德关于尝试不同事物的建议也很可靠，因为它可以帮助你摆脱最初的假设。有时有多种潜在的设计——有必要对它们进行彻底思考，以决定哪种是最好的。
我不得不在我的公司为这件事建模。
事件&车辆各自为政。你需要一个事实事件&FactSincidentAvehicle。这允许您关联与事件相关的属性(日期、位置、类型)以及事件中每辆车的属性。
Incident维度几乎是一个退化的维度，只包含一些IncidentID属性，如Police Report Number。
"事故车辆"维度也只有一些仅针对该事故的车辆的属性，例如车辆是否被牵引。如果您的数据允许发生非车辆事故(例如，绊倒和跌倒)，您将需要在您的维度中记录"无车辆"以及"未知"车辆。
事故车辆人员是捕捉该特定事故的人员和车辆之间关系的又一粒谷物。垃圾维度对于持有标志(Y、N、Unk)问题很有用，例如受伤、被引用、所有者、驾驶员等。
这种方法非常有效，允许一个事件有0到多辆车和1到多人，并允许同一个人和/或车辆参与多个事件(用于车队/员工记录)。
最常见的方法是使用桥接表http://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/multivalued-dimension-bridge-table/