如何从 Excel 转移到设计数据仓库模型答案

【问题标题】：How to move from Excel to designing a Data Warehouse Model如何从 Excel 转移到设计数据仓库模型
【发布时间】：2020-09-04 12:57:31
【问题描述】：

我刚开始使用数据仓库建模，我需要帮助来建模问题。

让我告诉你事实：我处理飞行数据（航空数据），所以我有两个 Excel（事实）文件，链接在一起，一个文件“订单”，另一个文件“服务”。

“订单”文件列出了每个航班的摘要（订单 ID、出发日期、到达日期、出发城市、到达城市、收取的总金额等）
“services”文件列出了航班提供的服务（orderId、服务名称、数量、金额/数量等）具有 1-n 关系（订单-服务），每个订单有 n 个服务

我已经看到了一些维度（时间、位置等...）。但是，我想知道如何设计我的数据仓库，因为我知道我有两个通过 orderId 链接在一起的事实文件。

我考虑了一下，星型和雪花模式在我的情况下不起作用（因为我有两个事实表）并且星系模式需要有共同的维度，但我阻止它，是我下订单表作为维度而不是事实表，或者我应该将服务表作为维度，但这些是事实表。我有点困惑。

如何设计我的模型？

【问题讨论】：

Flight 是您的主要事实表。 Service 也是一个支持 Flight 的事实表，尽管有些人可能想要跨航班查询服务。支持 Flight 的维度表也应该支持 Service。
好的，但是我该如何保留两个表之间的关系呢？由于每个订单（航班）都有多项服务
将这两张表合二为一，保留订单ID和订单信息。如果总金额可以通过对服务金额求和来计算，那么去掉总金额字段。
好主意RADO，看来能解决问题，让我想想

标签： data-modeling data-warehouse business-intelligence modeling

【解决方案1】：

首先要意识到，在 星型模式中，连接更多的事实表不是问题 - 请参阅讨论 here。

因此，第一次绘制将简单地跟随您的两个具有原生提供的维度的事实表。

Order 在一个上下文中是 事实表，在另一个上下文中是 service 表的维表 .

根据您的预期查询，您可能会发现service 表中order 表的order 表的某些维度非规范化 很有用。因此服务将定义出发日期、到达日期等维度。

这将在 ETL 作业的加载时完成。

我会以某种方式小心地将措施非规范化从 order 到 service - 这将基本上消除整个 order em> 表。

如果这是服务金额的多余总和，那么衡量收集的总金额不会有问题 - 您可以放心地摆脱它。

但您需要确定航班数量或运送人数 - 这些衡量标准最好在订单事实表中定义;您不能简单地将它们复制到每个服务的 N 行中。

解决方法 是可能的，如果您为每个订单定义一个 主要服务 并且这些措施仅在此行中定义 - 在其他行的值为 NULL。如果天真地查询，这可能会导致意想不到的结果，例如每个服务的航班数量。

所以基本上我会从两个事实表开始，然后对服务的某些维度进行非规范化，如果这有助于优化查询。

【讨论】：

也许我无法了解全局。总而言之，您告诉我，为了保持两个“表”之间的联系，我必须仅对某些维度进行非规范化？不是所有的人？我认为这不会解决问题，因为我最终会得到两个链接在一起的事实表......将它们全部合并到一个大的“服务”事实表中不是更好吗？
@LougEagle 最好的方法是发布两个表的架构和预期的查询。基本上我是在告诉对所有有助于优化查询的维度进行非规范化，并且在非规范化度量时要小心。

【解决方案2】：

我将从一个服务事实表开始。这一事实将包括您可能与 Order 关联的所有维度，包括 OrderId 的退化维度。

一旦确定了这一事实并且某些信息产品正在使用它，请返回订单并重新评估它，以查看是否有任何未满足的报告需求或问题服务事实很难回答。

将两个事实结合在一起总是一个坏主意。性能很糟糕。在您的情况下，您最好将维度从 Order 带到 Services。不要忘记在列名中包含维度的上下文以及此上下文的相应角色扮演维度视图。例如。 OrderArrivalCity、OrderDepartureDate、OrderDepartureTime。

您还可以为自己获取一份 Ralph Kimball 的The Data Warehouse Toolkit

【讨论】：