服务
我刚开始进行数据仓库建模，需要帮助进行问题建模。
让我告诉您事实：我处理飞行数据（航空数据），因此，我有两个链接在一起的Excel（事实）文件，一个是“订单”文件，另一个是“服务”文件。
我已经看到了一些尺寸（时间，位置等）。但是，我想知道如何设计我的数据仓库，因为我有两个由orderId链接在一起的事实文件。
我考虑过，由于我有两个事实表，所以星型和雪花模式在我的情况下不起作用，并且银河模式需要具有相同的尺寸，但我将其阻止，是因为我放置了订单表作为维度而不是事实表，或者我宁愿将服务表作为维度，但这是事实表。我有点困惑。
如何设计模型？
首先意识到在星型模式中，连接更多的事实表不是问题-参见讨论here。
因此，第一个抽奖将简单地跟随您的具有提供的原始尺寸的两个事实表。
Order在一个上下文中是事实表，在另一上下文中是service表的维度表。
根据您期望的查询，您可能会发现对service表中的order表的去规格化某些维度很有用。因此，服务将定义出发日期，到达日期等尺寸。
这将在ETL作业的加载时完成。
我会以某种方式小心地使度量规范化]从order到service-这将基本上消除整个order表。
如果这是服务金额的多余总和，则度量标准收集的总金额
不会有问题，您可以放心地删除它。但是您需要确定航班数
或运输的人数-在[[order事实表中更好地定义了这些度量；您不能简单地在每个service的N行中复制它们。A解决方法
是可能的，如果您为每个order定义一个main service，并且那些度量仅在此行中定义-在其他行中，该值为NULL。如果天真地查询，例如，可能会导致意外的结果。有关每种服务的航班数。因此，基本上，我将从两个事实表开始，并对服务的某些维度进行非规范化，如果这将有助于优化查询，则
。服务
服务
事实。将两个事实结合在一起总是一个坏主意。性能太差了。您总是最好将尺寸从Order更改为Services
。不要忘记在列名称中包含维的上下文，并为此上下文提供相应的角色扮演维视图。例如。 OrderArrivalCity，OrderDepartureDate，OrderDepartureTime。[您也可以自己获得Ralph Kimball的The Data Warehouse Toolkit副本服务