设计星形/雪花模式数据库

Question

我必须设计并构建一个星形/雪花模式数据库，该数据库将保存有关公司员工的数据 - 特别是支付给员工的费率。这是我第一次尝试这种模式类型，我不确定事实表的哪些部分应该是单独的维度表。

我不完全理解拥有这种模式的实际好处，在这种类型的数据库上执行查询实际上容易得多吗？还是仅与性能有关？

下面我附上了我的数据库模式的项目。我想知道我应该修改什么才能使其成为该数据库的最佳版本。我还有两个问题：

1. rate 列应该只是事实表中的一个值吗？还是应该是一个dim_rate 表的外键？
2. 日期维度呢？它们应该只是特定表中的值吗？或者它们应该总是外键？如果它们应该是外键，那么对于每种类型的日期应该有一个 dim_date 表还是一个表？

作为问题 2 的示例，让我们看一下 dim_employee 表以及 employment_date 和 end_of_employment 列。我将这些日期作为 dim_employee 表中的值，但我可以想到如何处理这些数据的其他 2 个版本：dim_date 表的外键或 fact_start_of_employment 的单独事实表和fact_end_of_deployment。我知道我将需要不同类型的报告，例如显示有多少人开始工作并在不同的日期间隔（例如 2020 年 12 月）离开公司的报告。老实说，在这一点上，我不知道哪个选项在未来是最好和最容易使用的。

正如我所说的 - 我很乐意对这个模式提出任何建设性的批评，即使这意味着完全重新设计它。

Answer 1

我会合并两个事实表，因为我认为比率和位置之间有很强的关系。但这就是我在不了解所有细节的情况下查看这些数据的方式。

我还将创建一个日期维度和一个 form_of_employment 维度。

这将导致 4 个维度：

• dim_employee
• dim_date
• dim_position
• dim_form_of_employment

以及包含这些列的单个事实表： fact_assignment

• employee_id
• date_id
• position_id
• form_of_employment_id
• 评价
• 学生

此设置为您的报告生成了适当的星标和非常简单的 SQL

Answer 2

对于每个 BI 或报告系统，您都有一个设计表格并根据该设计构建表格的过程。这个过程称为维度建模。其他人称之为数据仓库设计，这是同一回事。维度建模是思考和设计包括表及其关系在内的数据模型的过程。如您所见，维度建模过程中不涉及任何技术，这一切都发生在您的脑海中，最终在纸上绘制草图。维度建模不是表格相互连接的图表，而是这样做的过程。

Star Schema 是设计用于报告的数据模型的最佳方式，使用此类模型您将获得最佳性能和灵活性。

在这种情况下，员工维度将是 Historical Dimension or Slowly Changing Dimension :

您可以使用 bridge table。 在经典的维度模式中，附加到事实表的每个维度都有一个与事实表的粒度一致的值。但是在许多情况下，维度是合法的多值。 就像你的例子一样，一个员工可以有很多职位：