我在 DW 设计方面相当陌生，并且正在使用 DW 对某些 IT 基础架构进行建模。
此时的主要问题/问题是如何对驱动器信息建模。
我们将收集有关文件和文件夹的聚合数据，以及物理驱动器上的单独数据。驱动器信息将至少包括总空间和可用空间，并且每周更新几次。
需要回答的业务问题之一是驱动器使用的趋势如何随时间变化。驱动器信息也将用于下至文件/文件夹级别的层次结构。
我现在可以看到的选项是：
DRIVE作为维度 实施- 简化层级设计
- 这会导致报告出现问题吗？仅报告维度上的时间限制数据对我来说似乎违反直觉
- 有一个你知道每次刷新数据时都会改变的维度似乎也有问题
DRIVE作为事实表实施- 简化报告
- 使层次结构复杂化（？）——我也将使用它
Drive来将数据映射回特定的服务器或计算机。可以将事实表用作层次结构中的中间层吗？我不认为是。
DRIVE作为事实和维度实施- 事实将仅包含键、日期和空间上的事实
- 维度将包括其他非附加数据，例如它所在的计算机等。
- 似乎解决了这两个问题，但这是反模式吗？
我希望我会有一个 drive_usage 事实表，其中包含指向快照时间维度、驱动器维度、计算机维度以及该时刻有关驱动器的各种数字事实的链接。
驱动器尺寸应该没有任何定期变化 - 我想这取决于您对驱动器的定义 - 它是物理驱动器还是逻辑单元或什么。也许您的“C”驱动器有一个序列号，它被替换了——然后该维度将过期并添加一个新的维度。这些关于维度的东西并不是真正的“事实”，它们是属性。这不会影响报告，因为计算机 X、驱动器 C 的数据具有连续性。类似地，如果计算机 X 从双核升级到四核，那么维度就会发生变化（假设事实表中没有跟踪超出内核数量的内容，例如主板修订版）。驱动器的容量将在事实表中，因此随着时间的推移对其进行的更改只是具有新日期的新事实。有时您甚至可以将成员资格的更改建模为事实。也就是说，如果有一天物理驱动器 1-5 在逻辑驱动器 C 中，然后物理驱动器 1-6 在下一天在逻辑驱动器 C 中，这可能只是物理驱动器成员资格事实表中的事实更改。这些就是一些人所说的无事实事实表，因为唯一的事实是行的存在显示成员资格——除了总计或计数之外没有什么可做的。
当您进入文件夹时，根据您尝试通过汇总实现的目标，对层次结构进行建模可能会更加棘手。
在不是普通场景的领域中，DW 建模有很多技巧。