相同实体的维度和事实?

JNK*_*JNK 8 data-warehouse dimension

我是 DW 设计的新手,正在研究 DW 以对某些 IT 基础架构进行建模。

此时的主要问题/问题是如何对驱动信息建模。

我们将收集文件和文件夹的汇总数据,以及物理驱动器上的单独数据。驱动器信息将至少包括总空间和可用空间,并且每周更新数次。

需要回答的业务问题之一是驱动器的使用随时间的变化趋势如何。驱动器信息也将用于向下到文件/文件夹级别的层次结构中。

我现在可以看到的选项是:

  1. DRIVE作为维度 实施

    • 简化层次结构设计
    • 这会导致报告问题吗?仅报告维度上的限时数据对我来说似乎违反直觉
    • 您知道每次刷新数据时都会更改的维度似乎也有问题
  2. DRIVE作为事实表实施

    • 简化报告
    • 使层次结构复杂化(?) - 我还将使用Drive将数据映射回特定的服务器或计算机。可以将事实表用作层次结构中的中间级别吗?我不认为是。
  3. 实施DRIVE既是事实和维度

    • 事实将只包含空间上的关键、日期和事实
    • Dimension 将包括其他非可加性数据,例如它在什么计算机上等。
    • 似乎解决了这两个问题,但这是一种反模式吗?

Cad*_*oux 6

我希望我会有一个 drive_usage 事实表,其中包含指向快照时间维度、驱动器维度、计算机维度以及有关该驱动器的各种数字事实的链接。

驱动器维度中可能没有任何定期更改 - 我想这取决于您对驱动器的定义 - 它是物理驱动器还是逻辑单元或什么。也许你的“C”驱动器有一个序列号,它被替换了——然后维度将过期并添加一个新维度。这些关于维度的事情并不是真正的“事实”,它们是属性。这不会影响报告,因为计算机 X、驱动器 C 的数据具有连续性。类似地,如果计算机 X 从双核升级到四核,那么维度会发生变化(假设事实表中没有跟踪超出内核数量的内容,例如主板修订版)。驱动器的容量将在事实表中,因此随着时间的推移对它的更改只是具有新日期的新事实。有时,您甚至可以将成员资格更改建模为事实。即,如果某一天物理驱动器 1-5 位于逻辑驱动器 C 中,然后物理驱动器 1-6 下一次位于逻辑驱动器 C 中,则这可能只是物理驱动器成员资格事实表中的事实更改。这些就是一些人所说的无事实事实表,因为唯一的事实是行显示成员资格的存在——除了总计或计数之外,没有太多可做的。

当您进入文件夹时,根据您尝试使用汇总实现的目标,对层次结构建模可能会更加棘手。

在非普通场景的领域中,DW 建模有很多艺术。