我的任务是为客户创建一个数据仓库。所涉及的表格并没有真正遵循那里的传统示例（产品/订单），所以我需要一些帮助才能开始。客户端本质上是案件的处理中心（类似于法律案件）。每天，都有新的案例被输入到“案例”表下的数据库中。每列都包含一些与案例相关的信息。在处理案例时，将使用与案例相关的事件填充额外的一对多表。这些事件表有很多，示例表可能是：（case-open、case-dept1、case-dept2、case-dept3 等）。这些表中的每一个都有一个映射回“案例”表的 caseid。还涉及一些查找表。
目前，报告需求涉及暴露各个阶段的瓶颈，并且对于流程的某些区域，粒度为小时级别。
我可能在这里问的太多了，但我正在寻找有关如何设置 Dim 和 Fact 表或您可能有的任何其他建议的方向。
事实表是案例事件，它是“无事实的”，因为它没有数值。维度可能是时间、事件类型、案例，可能还有其他一些，具体取决于系统中的其他数据。
您需要将事件表合并到一个事实表中，并标有“事件类型”维度。吞吐量/瓶颈报告正在计算给定案例中特定事件类型组合的事件时间之间的差异。
报告应计算事件事件时间，并可能将它们放入直方图中。您还可以标记某些类型的事件组合并将标签应用于感兴趣的事件。然后可以根据这些事件记录时间，这将允许使用 OLAP 工具对时间进行切片和切块操作。
如果您想对生命周期进程中的某些阶段进行基准测试，您将有一个表格，其中包含案例类型、事件类型 1、事件类型 2、基准时间。
通过一些按摩，您可能能够使用数据挖掘工具包甚至是简单的回归分析来发现案例属性和事件事件时间 (YMMV) 之间的相关性。
我建议你看看 Kimball 的书，尤其是这本书，它应该有一些例子让你思考你的问题领域的应用程序。
在任何情况下，您都需要确定维度模型是否合适。很有可能使用不同的索引或摘要等来处理 3NF 数据库“企业数据仓库”。
没有看到你当前的模式，真的很难说。听起来你最终会得到几个明星模型，它们有一些一致的尺寸将它们联系在一起。因此，您可能将案例尺寸作为您的一致尺寸之一。来自其他表的事实实际上是既链接到符合标准的维度也链接到适用于事实的任何其他维度的事实表，因此，例如，如果在 case-open 中有一个员工 ID，它将链接到符合员工标准的维度，来自案例开放事实表。这个符合标准的维度可能会从您的几个辅助事实表中链接多次。
Kimball 的建模方法相当简单，可以像食谱一样遵循。您需要首先识别所有事实，将它们分组到事实表中，识别每个事实表上的各个维度，然后根据需要将它们分组到维度表中，并确定每个维度的类型。
与开发的任何其他方面一样，您必须从最终需求（“用户故事”，如果您愿意的话）向后处理问题。仓库最保守的方法是简单地表示事务数据库的副本。从那里，在需求的指导下，可以进行某些优化以增强某些数据访问模式的性能。然而，我认为重要的是，将这些视为优化，而不是假设数据仓库自动必须是每个事实的每个可能维度的复杂爆炸。我的经验是，对于大多数目的，直接表示对于 90% 以上的分析查询来说已经足够甚至是理想的了。对于其余部分，首先考虑索引、索引视图、附加统计信息或其他可以在不影响结构的情况下进行的优化。然后，如果需要聚合或其他冗余结构来提高性能，请考虑将它们分成一个“数据集市”（至少在概念上），它提供原始事实与其冗余之间的分离。最后，如果需求过于流动并且聚合需求过于繁重而无法以这种方式有效运行，那么您可能会考虑数据的大规模爆炸，即星型模式。不过，再次将其限制为数据的最小横截面。如果需求太流动并且聚合需求太重而无法以这种方式有效运行，那么您可能会考虑数据的大规模爆炸，即星型模式。不过，再次将其限制为数据的最小横截面。如果需求太流动并且聚合需求太重而无法以这种方式有效运行，那么您可能会考虑数据的大规模爆炸，即星型模式。不过，再次将其限制为数据的最小横截面。
这就是我想出的本质。感谢NXC
EventID TimeKey CaseID
EventID 事件描述
时间键
RegionID RegionDesc
CaseID 区域ID
这可能是在您考虑问题之前选择解决方案的情况。并非所有数据仓库都适合星型模式模型。我没有看到您在这里汇总任何数据。到目前为止，我们有一个无事实的事实表和至少一个快速变化的维度（案例）。
看看我目前所看到的，我认为这个数据库中的中心实体应该是这样的。试图把事件放在中间似乎是不对的。尝试以不同的方式看待它。或许，案例、事件和案例事件要开始。