星型模式设计的一般理解

Posted 2023-03-29

【中文标题】星型模式设计的一般理解

【英文标题】：General understanding of star schema design

【发布时间】：2010-09-23 14:03:36

【问题描述】：

所以，我想我明白在维度中放入什么，在事实表中放入什么，以及如何实现这一点。 现在我遇到了问题，我有这个维度“产品”和一个维度“产品属性”。我不得不拆分它，否则我在“产品”中的自然键将不再是唯一的。我问了这个 this question.

所以我的“productProperties”维度表应该如下所示： 颜色 |材料 |尺寸

1.)为了实现这一点，我必须创建“颜色”、“材质”、“尺寸”等值的所有可能排列，对吧？

这将远远超过 2 亿行，因此我决定将其拆分。 我现在有一个维度“颜色”，它实际上由“颜色”、“颜色前”、“颜色后”列组成。

2.) 我想这很好，但是维度“大小”呢？它只包含“代理键”和“值”列？

我已经阅读了“退化维度”（在我的另一个问题中给出的阅读建议中），这意味着在事实表中将“单列维度”设为一列。这对我来说似乎有点不切实际，因为我最终会在我的事实表中增加大约 5-6 列。

如果我应该这样做怎么办？

3.) 这些退化维度是事实表中主键的一部分吗？

最重要的问题： 我的事实表中将包含产品条目，这些条目与我的维度中的每一列或根本不匹配所有维度都不匹配。意思是，我可能有一个条目/产品，它具有“color”属性，但没有“colorFront”或“colorBack”属性。 由于我创建了“color”、“colorFront”和“colorBack”的每一个排列，当尝试填充我的事实表时，我将获得多个代理键，如果产品只有属性“color”会导致我的重复事实表，对吧？

4.) 那么在查询我的事实表时，我是否必须过滤掉这些重复项？或者这根本就错了？

我当然可以将维度“颜色”拆分为三个维度。但随后我将在某些列中获得具有 NULL 值的条目。完全不使用某些维度的条目/产品也是如此。

5.) 如何处理那些 NULL 值？

提前感谢您的帮助。

【参考方案1】：

每个维度都有：

主键（DateKey，TimeKey，ProductKey，...） 业务密钥（FullDate、ProductFullName、ColorNaturalKey、...） 值为“未知”的行（Key = 0，BusinessKey = '未知'，所有其他 = 'n/a'） 值为“n/a”的行（Key = -1，BusinessKey ='n/a'，所有其他 = 'n/a'）

在Color 表中，Color、ColorFront 和ColorBack 列的值都为“n/a”和“unknown”——因此这些列应包含在排列中。这样维度表中总有一行可以指向。

您可以通过将SizeValue 移动到事实表中并删除dimSize 来选择使大小成为退化维度。

【讨论】：

如果同一个 productkey 有不止一种尺码，那么 SizeKey 必须是事实 PK 的一部分，我可以同时选择同一件衬衫的 XL 和 XXL 码……一个用于我和一个给我的兄弟。我可以购买相同产品密钥的两种不同颜色。我几乎总是买不止一种颜色的同一件衬衫。颜色也应该是 PK 的一部分。事实上，如果 Fact 表中有一个不属于 PK 的 FK，那么它就是在描述一个现有的 Dimension，并且可能应该在那里。

@Stephanie 没错，复合主键的选择应该更加谨慎。根据您的评论修改了模型。

@Damir 如果我没有 ColorNaturalKey，我是否应该将其拆分为类似于 dimMaterial 的尺寸？

@tombom - 您需要某种业务（自然）键才能在加载期间获取主键。所以发明一个，例如'c=blue-f=blue-b=na'就可以了。

@tombom -- 业务（自然）键唯一标识维度行描述的对象（实体）。例如，Color = blue; ColorFront = blue; ColorBack = blue 和 Color = blue; ColorFront = blue; ColorBack = na 是两个不同的颜色实体，具有不同的自然键。您还可以将前后颜色作为键移动到事实表中，以获得 ColorKey、FrontColorKey 和 BackColorKey；然后从维度中删除列。

【参考方案2】：

1) 谁告诉你的：

所以我的“productProperties”维度表应该是这样的：颜色 |材料 |尺寸

要么错了，要么你误解了。

这个想法被称为“垃圾维度”。并且它不必一开始就包含笛卡尔积。它可以像任何其他维度一样加载。如果事实表中需要组合而不是维度中需要组合，则添加它。开始使用笛卡尔坐标很方便，但您最好知道，当添加新颜色时，您必须重新进行笛卡尔坐标。最好在需要时加载而不用担心。

2) 好的，现在我已经阅读了您的整个问题，并意识到您正在阅读有关维度建模的内容，但看起来您正在浏览它。

退化维度类似于采购订单号。这不是事实。你不能求和。但它也不是一个维度，因为关于 PO123210413 没有什么需要说的了。它不是任何地方的 FK。

【讨论】：

我的整个 ETL 过程看起来像这样，我检索在我的源数据库中创建或修改的行并将它们存储在我的数据仓库中的适当表中。之后，我重建我的尺寸或相应地更改或添加列。我这样做是因为我认为维度是描述元素。所以最终用户可以例如查询产品，如果结果不混淆，给定产品 wast purchased yet. Thought that he may be confused if he wasnt 能够浏览产品（因为尚未购买）。这不是好习惯吗？

嗯，这是倒退...如果您没有新维度值的 FK，如何向事实表添加行？如果你有 1 = 红色，2 = 蓝色，当添加第一件黄色衬衫时，事实表中的 FK 会是什么？

每次 ETL 流程运行时，我都会重建我的维度（或者更确切地说添加/更改新创建/修改的行）。因此，在事实表中插入黄色衬衫是没有问题的。