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

Question

您好我正在数据仓库上做一个项目，我不确定我是否正确建模我的数据仓库。我的数据仓库没有业务流程，因此我找不到相关信息。

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

库 - ＆gt;细胞 - ＆gt; pin - ＆gt;时间/功率

我有兴趣知道单元属性 - 定时/电源，以便我以后可以进行比较。

我应该在雪花模式中按仓库建模，其中我的事实表只包含库维度和日期维度的外键。然后将库尺寸进一步划分为单元尺寸，并将单元尺寸进一步划分为引脚尺寸，将引脚尺寸分为时序和功率尺寸

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

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

每当有新版本的库文件发布时，我将不断地使用这一大量数据

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

修改

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

层次结构如上所示。 不同的库将包含相同的单元，引脚和条件，只有时序和功率模板不同。

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

Answer 1

这在很大程度上取决于您使用的数据库技术，报告要求和ETL性能目标;以下是根据您的情况考虑的一些想法。你问题的答案中最直接的部分是在下面的olap部分。

英曼：
用于空间效率，etl速度和设计简单性;考虑使用基于实体的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个库到单元）并且你的测量是在时间/功率级别记录的那么雪花是一个存储数据的最佳方式（最小空间），但您可能仍需要构建视图＆＃39;所以你的设计似乎是你的OLAP工具集的明星（一些较新的olap引擎将允许这些设计）。将数据构建为星形将占用更多空间，但可以让您更轻松地发现n-n或n-1事件。

请记住，如果您计划报告较小的颗粒（在这种情况下，您在星形中表示的密钥，您的雪花将需要相同的密钥结构），您必须在事实表中保留最低级别的密钥，这只是空间效率的问题，不需要像在星星中那样复制每个单元格中的库信息。

[从评论中编辑] 根据评论和您提供的模型，一些想法：

• 事实表fk＆＃39; s也是该表的pk
• 模特说你没有在pin或模板上收集事实，只是提供信息。如果你有一个单元格的许多引脚/模板，可能会考虑不使用它们，因为它们会引入一个产品连接，在连接这些表时会产生重复的事实。但是，如果你可能会问一些不寻常的措施，请保留它们，我的细胞如何通过共同的针脚相关？＆＃39;或类似的分析。
• 设计表明库仅通过收集的事实与细胞相关。使这种关系（lib到单元格）动态化。

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