背景
我正在设计数据库(使用 STAR 模式)。
有三个表要建模:products,tests,states。
该数据库将用于存储对产品进行的测试结果(非常简化)。可以有许多测试指向单个产品,但每个测试都是唯一的(它们不在产品之间共享)。此外,我需要在进行测试时记录产品的当前状态。让我们假设产品的状态描述了它的当前位置和所有者,它们经常变化。这很可能涉及 SCD lvl 2 - 跟踪状态变化的历史并能够定位产品连同它的所有测试以及它在这些测试中的状态。
问题
我不完全确定如何为这个问题建模。将每个测试存储在 FACT 表中似乎很明显。然后,该表将包含数千个事务。另一方面,也会有成百上千的产品,所以我应该把它们放在第二个 FACT 表中。然后,还会有成千上万的状态变化,所以为了记录它们的整个历史,我还需要将它们保存在... FACT 表中?有人告诉我,FACT 表通常用于存储多行数据,但另一方面,该模型中的 DIM 在哪里?
我也不知道如何为这些表之间的关系建模。产品-状态是 1:* 关系。产品-测试也是 1:*。最后,states - tests也是 1:* 。然后,我会将产品链接到状态,然后将状态链接到测试(products 1<-* states 1<-* tests),这将允许我找到特定产品的所有状态和所有测试(在所有状态或选择状态)。你怎么看?这里的问题是,当我不断添加states时,我有两个选择:要么在products表中继续复制产品(添加“recorded_timestamp”列),要么在states表中使用 SCD lvl 2,用一个 FK,但这会有效地使产品表变暗!
这里的任何帮助将不胜感激。
所以第一个问题是:你确定你需要使用星型模式吗?在许多不同质量水平的仓库中工作后,我发现星型模式是:1. 不灵活 2. 难以使用(大量连接) 3. 对时间序列来说真的很糟糕。
您描述事物(产品、产品状态、测试)的方式以及跟踪时间点的需要会产生类似这样的东西(派对/测试的轻微修饰):
如果您需要获取某个测试的状态,这可以通过一个简单的连接来实现,它可以封装在一个视图中,这样用户就不必担心逻辑是否正确:
首先,“star”和“fact”都不是缩写,“dimension”也不是缩写,所以它们不应该全部大写。“事实表”之所以这样称呼,是因为它们包含事实。“星型模式”在以图形方式表示时(对某些人来说)类似于星型,以防有许多维度描述一个事实。
一个产品不可能是一个事实,所以它是一个维度。状态可能是事实,也可能不是事实,因此您应该更加仔细地查看该实体以确定它的真实情况。测试当然是事实。
根据您决定的状态,您的模型将是两点“星”,以产品和状态为维度,或者是单腿雪花。你也可以发现state和test的结合确实是一个事实,那么你最终会得到一个单点的“star”。
如果有人最终遇到与我类似的问题 - 这就是我解决它的方法。
首先,按照其他答案中的建议,我将我的产品放在一张昏暗的桌子上,并将我的测试(测试结果)放在一个事实中。现在的问题是如何存储状态(产品状态变化的历史)。
假设产品的状态由随时间变化的属性 A、B 和 C 定义。我们希望记录更改的历史并将测试结果及时与任何特定状态相关联。
我为此使用了小尺寸。三个 mini-dim 表(用于 A、B 和 C)都连接到主事实表(测试)。通过这种方式,我们始终知道特定测试与哪个状态相关。
为了跟踪状态变化的历史,我还将这些 mini-dims 连接到一个无事实的事实表(它还具有诸如有效、过期、当前等属性)。
这似乎解决了这两个问题。如果它没有真正完成工作,现在将尝试构建它并更新这个答案。