数据仓库架构设计 - 如何改进架构模型

我必须为旅行社创建数据仓库。我是第一次这样做。我已经学习了关于星型，雪花和星座模式的基础知识以及关于创建数据警报的基础知识。我想问一下，如果这个设计总体上是好的，那么可以改变什么呢？数据仓库架构设计 - 如何改进架构模型

这里是我的尺寸层次：

这里是我achived现在（在MySQL Workbench中创建模式）：

2017-04-02 anton86993

你能更具体地说明你在哪些方面遇到困难吗？你的图表是否显示了你在昏暗中的所有领域？另外我不认为付款类型应该包括年/月/日/小时/分 – Rich

我不是一个很大的分维的粉丝。一旦您开始介绍这些数据库设计，它们就像标准的[OLTP]（https://en.wikipedia.org/wiki/Online_transaction_processing）一样。这消除了星形模式提供的许多优点。例如：通过可视化工具的数据（如[PowerBI]（https://powerbi.microsoft.com/en-us/），[QlikView]（http://www.qlik.com/en-gb）等）更喜欢[Kimball]推荐的扁平尺寸表（https://en.wikipedia.org/wiki/Dimensional_modeling）。 –

想指出前两个评论是基于以前版本的问题。 – Rich

以下是基于修订后的问题的新答案。这个设计有很多你可能想看的东西。这里有几个指针但不是完整的列表：

你的DimTime维度应该是什么粒度？通常情况下，日期/日期粒度具有日期维度，但在表格中它看起来像星期几。
如果这对于分析销售或满意度评估时的重要性，您可以创建一个单独的每日时间维度。
忠诚事实似乎是一段时间内客户行为的总结 - 应该是几周？如果是这样，你可以去一周的额外维度
为什么付款类型有几秒钟的时间呢？这似乎并不正确 - 付款类型不是每天都要花费几秒钟的时间。也许这是你缺少时间维度，付款类型应该是分开的？
产品维度是否应具有区域层次结构？你是否说如果产品在不同的城市，产品是不同的？你可能想再看一遍。

我相信其他的建议可以找到，祝您的课程好运！

来源

2017-04-04 13:13:57 Rich

1.我们希望从一年的开始日期，一个季度，一个月，一周，然后一周的一天，没有时间的一天; 2.我想这仅仅是为了教育目的而不是在现实生活中的实施，所以它不必如此详细:)。我猜这很好。我们想在最大的一天检查客户的忠诚度，因为它是旅行社。 4. PaymentType没有秒。它有分钟然后PaymentId或我不明白它; 5.在我的国家我们有省份，所以我想它应该被称为省而不是地区我是对吗？ – anton86993

1.我同意，你不需要每天的时间，但它至少应该是'约会'。 4.为什么分钟？付款类型是一种付款方式 - 与分钟无关，我想！ 5.产品不是地区性的，就是我所说的。祝你学习好 – Rich

采取DimClient作为例。你有一个很好的代理键。接下来，您需要填写有关客户的所有内容（包括clientID），然后还包括地区，城市，地区和国家/地区。当你拥有所有内容时，该维度就完成了。

您可以通过ClientKey将它链接到Fact表中，因此您需要将该Key作为外键放入Fact表中。

通过与其他维度类似的过程，填充维度和事实，并且您将处于良好状态。你不需要subdimensions来反映你的hiearchies：维度是非规范化的。

编辑：这个问题本来是完全不同的，因此上面的答案与其原始形式相关。

来源

2017-04-02 14:09:33 Rich

为什么我应该在这里创建星型模式而不是雪花？我们的讲师告诉我们要更像规范化的模式（雪花）。为什么？ – anton86993

我不知道你的讲师为什么要你这样做，但如果你想要好的分数，你应该可以做他们说的！如果你想用Kimball风格做一个尺寸模型，你应该尽可能地避免雪花（标准化），因为这会降低以尺寸方式做事的好处。如果您想要雪花，请使用代理键创建子维度，然后使用维度中的外键将其链接到它们，如“正常”标准化模型。如果您有特定的问题，非常乐意提供帮助 - 只需询问。 – Rich

只要我回家，我会做到这一点，并在这里显示我的结果:) – anton86993

数据仓库架构设计 - 如何改进架构模型

回答

相关问题