分层建模数据仓库——雪花还是星星？

Question

您好，我正在做一个关于数据仓库的项目，但我不确定我是否正确地为我的数据仓库建模。我的数据仓库不在业务流程中，因此我找到的信息很少。

基本上我有很多库文件，每个库文件包含许多单元信息，每个单元包含许多引脚信息，每个引脚包含时序和功率信息。 不同的库文件基本上包含相同数量的单元和引脚结构，只是时序/功率信息不同

库 -> 单元 -> 引脚 -> 时序/电源

我有兴趣了解单元格属性-timing/power，以便我以后进行比较。

我是否应该在雪花模式中按仓库建模，其中我的事实表仅包含库维度和日期维度的外键。然后库维度又分为cell维度，cell维度又分为pin维度，pin维度又分为时序维度和功率维度

或者在我的事实表包含库、单元格、引脚、时间、功率和日期维度的外键的星型模式中？

我担心的是我的数据非常大，因为我有大约 200 个库文件，每个库文件包含大约 20k 单元，每个单元包含几个引脚，每个引脚包含一些时序和电源信息。因此总尺寸很大，即 200 x 20,000 x 4 x 4

每当有新版本的库文件发布时，我都会不断地输入这一庞大的数据集

可以给我建议哪个更好吗？dfdf

编辑：

Library A
   Cell A
      Pin A1
        Condition A11
           riseTimingTemplate
           fallTimingTemplate
           risePowerTemplate
           fallPowerTemplate

层次结构如上所示。 不同的库会包含相同的单元格、引脚和条件，只是时序和电源模板不同。

假设我的事实粒度是特定单元格的时间和功率值
所以我的维度会有库、单元格、引脚、条件、risingTimingTemplate、fallTimingTemplate、risePOwerTemplate 和 fallPowerTemplate，所有链接到事实表是否正确？

Answer 1

这在很大程度上取决于您使用的数据库技术、您的报告要求和 ETL 性能目标；根据您的上述情况，这里有一些想法需要考虑。对您的问题的回答最直接的部分在下面的 olap 部分。

英曼：
为了空间效率、等速度和设计简单性；考虑使用基于实体的 Inman 设计。对于您的示例，这可能是每个实体的一个表，其中事实直接存储在表上，在层次结构中通过表之间的简单键/fk 链接链接。例如，您可能有上面提到的 4 个表。将这些表与自然键链接以避免依赖于排序顺序或其他基于随机机会的键，以防您需要将先前加载的数据与当前负载进行比较。对于时间不流畅的事实，这也可以更节省空间。但是，如果时间序列或其他序列必须平滑，这是一种权衡，因为报告可能更难以满足任何平滑要求。

金博尔：
在这种情况下使用 Kimball 模型的一个很好的例子是当有许多不同的事实但都在同一粒度时。混合不同粒度的事实使数据模型的构建和使用更加复杂。我在您的示例中将粒度定义为单元级别的事实，然后假设每个表之间存在 1-n 关系，则功率级别的事实位于不同的粒度上。在 Inman 设计中，您可能只是在实体上存储测量值，而在 Kimball 设计中，您通常会将事实与维度分开，这会创建额外的表格来保存这些测量值。

OLAP：
如果您将 OLAP 技术用于查询引擎，这会稍微复杂一些。大多数将需要数据模型作为星型模式。大多数引擎不允许雪花定义，因为当您在相关维度表之间存在 n-1 或 n-n 关系时，它会冒“产品连接”的风险。如果不小心处理，n-n 维表的结果可能是重复的事实行，当这些重复出现在数据中时，如果仅通过加入那些 n-n 维来查询导致值过高，则很难解决这些问题。 ** 如果您可以保证外部尺寸始终为 1-1 或 1-n（意味着 1 个库到 x 个单元，但绝不是 2+ 个库到一个单元）并且您的测量是在时间/功率级别记录的，那么雪花是存储数据的好方法（最小空间），但您可能仍需要构建“视图”，因此您的设计似乎是 OLAP 工具集的明星（一些较新的 olap 引擎将允许这些设计）。将您的数据构建为星形将占用更多空间，但可以让您更轻松地发现 n-n 或 n-1 个事件。

请记住，如果您打算报告较小的粒度，则必须保留事实表中最低级别的键（在这种情况下，您在星号中表示的键，您的雪花将需要相同的键结构） ，这只是空间效率的问题，不需要像在星星中那样在每个单元格处复制图书馆信息。

[从 cmets 编辑] 基于 cmets 和您提供的模型，一些想法：

• 事实表 fk 也是该表的 pk
• 模型说您没有收集关于图钉或模板的事实，从而使这些只是信息性的。如果您在一个单元格中有许多引脚/模板，可能会考虑不使用它们，因为它们会引入一个产品连接，在连接这些表时会创建重复的事实。但是，如果您可能会问“考虑到一些不寻常的措施，我的细胞如何通过共同的引脚相关联？”，请保留它们。或类似类型的分析。
• 设计表明库仅通过收集的事实与单元格相关。使这种关系（lib 到单元）动态化。

最后一个关于日期维度的提示：日期的 pk 可以是格式化的 # 基于日期/时间集合的详细级别（即：20150101 可能是 2015 年 1 月 1 日的键，添加第二个时间表如果您需要时间，否则日期表将在存储中快速扩展。使 ETL 构建速度更快，您甚至可以跳过对基本日期数据的日期表的联接）