DWH - 数据仓库 - 设计答案

【问题标题】：DWH - Data warehouse - designDWH - 数据仓库 - 设计
【发布时间】：2017-07-19 11:03:10
【问题描述】：

我正在尝试为报告系统设计 DWH，并想向专业人士询问他们对最佳设计的看法。

它更复杂，但为了简单起见，假设以下场景：

每个客户都有“汽车组”
有“一组待办事项”要与每个客户核对，并且
可能有与每个客户相关的“电话”

在我们的数据库中，每个主题（客户 - 汽车 - 待办事项 - 电话）的数据都存储在一个表中。 Customer 表与（汽车 - 待办事项 - 呼叫）表具有一对多关系，如图所示

我正在考虑让报告系统设置以下维度和事实表： - DIM_Customer - DIM_Car - DIM_To-do - DIM_Call - Fact_ALL

正如我提到的，它更复杂无论如何，我现在被卡住了，因为不清楚如何聚合我的事实表 --> 因为有一组汽车和一组待办事项和多个电话

DIM_Customer_ID DIM_Car_ID DIM_To-do_ID DIM_Call_ID Cars_Count To-dos_Count Calls_Count

Q1：在每个（汽车、待办事项、呼叫）维度和事实表之间使用桥接表 --> 其粒度是“每个客户每组汽车每组待办事项”每组呼叫的dos，对吗？还有其他更简单或更好的解决方案吗？如何解决这样的基数？
Q2：在 Db 中，每个 Customer 都有一个唯一的 ID --> 是否可以使用这个 customer_ID 来连接维度表和事实表？或者不建议这样做，因为 dim 和事实表现在没有（PK-FK）连接（customer_ID 仅作为 DIM_customer 中的 PK，但作为其他 DIM 中的 FK）......我只是想让它尽可能简单

Q3：有没有更好或更多定位的 DWH 设计

这是我的第一个 DWH 设计，如果有任何愚蠢的想法，请见谅 :)

谢谢

【问题讨论】：

您是否有特定的理由只创建一个事实表？调用和待办事项可能适合同一个事实表，但它们只是微弱相关，对于汽车来说，快照类型的事实表更合适。此外，汽车是否会随着时间的推移在群体（和客户）之间移动？
不，他们没有。此外，用户 x 仅被视为一次 --> 用户 x 只能拥有一次一组汽车 - 下次将其视为新用户。也许多个事实表不是一个坏主意，然后将它们全部加入，但是真的有必要吗？
“全部”事实听起来不正确。事实应该是对某些业务流程或关系的度量，而不仅仅是一个中心表。如果包含事实使其变得更加复杂，那么您的报告系统最好保持原样，而不是将其更改为伪维度。我想，电话和待办事项本身可能就是事实，而且你可以有一个事实来模拟人与汽车之间的关系。

标签： etl data-warehouse

【解决方案1】：

与往常一样，驱动问题应该是“我要衡量/汇总什么？”和“我要如何对数据进行切片和切块？”。它们分别为您提供事实表和维度表。

事实表

如果您只想衡量客户拨打了多少电话以及完成了所需的待办事项列表，那么单个事实表（Fact_Event 或类似的）将为您提供很好的服务。添加 Call 和 Todo 键，并为不适用的维度输入键 0 或 -1（该维度记录中的所有字段均为“N/A”）。

另一方面，如果 Todos 有大量步骤在不同时间完成，并且您想衡量步骤之间的进度和提前期，则将它们存储在包含完整列表的单独事实表中更有意义的日期键根本不适用于呼叫。

在所有情况下，您都将链接到 Car 和也许（请参阅下一部分）客户维度及其两个键。

维度表

在您的评论中，您声明每个客户只出现一次，只有一组汽车。这使得他们在客户采用这种类型的解决方案时相当不合常规，因为有关（返回）客户的购买选择和支持需求（成本）的信息被认为非常有价值。

在这种情况下，最简单的场景是只有一个维度，称为 Car 或 Car_Customer。然后，该维度将包含汽车详细信息、组标识和所有相关的客户详细信息。如果您的普通客户有 1 到 5 辆汽车，他们的详细信息只会重复那么多次，这比有多个连接更可取。

因为有一个很好的层次结构，报表用户在按客户、汽车或任何组合组织数据时不会有任何问题。

如果您最终确定您有回头客（即使他们总是在源系统中新鲜输入），您可以在 ETL 中添加客户匹配/合并例程，然后单独的客户维度更有意义。

只有当客户拥有多个汽车和/或汽车在不同时间可以是不同的汽车组时，作为单独维度的汽车组（或合同？）才有意义。在这种情况下，我建议仅通过事实表链接它，并在那里添加一个 Group 键。维度之间的桥接表是可能的，但可能会变得混乱。

替代方案：不要使用维度模型

您拥有的数据似乎不适合维度模型，该模型的设计理念是将经常重复的数据（如客户详细信息和产品详细信息）放入行数较少的宽维度表中，而留下事实表窄，允许在高行数下获得良好的性能。

在您的情况下，汽车似乎是唯一经常重复的实体，即使从您描述的模型中也不清楚。将表格建模为类似于第一张图片中的源模型更有意义，即使使用相同的唯一 ID，添加报告所需的额外标志、描述和类别。

只有当您想要跟踪这些表（例如 Cars）随时间的变化时，您才需要引入维度逻辑。

【讨论】：

【解决方案2】：

您似乎误解了事实表应该是什么。事实是对在事件发生时发生的事件的度量。

作为您示例的一个子集，假设 FactCarPurchase 包含诸如 DimCustomer 的 Count、Mileage、PurchaseDate、PurchasePrice 切片等度量，您可以查看每位客户的平均汽车数量或一位客户的汽车数量，或平均英里数由客户驱动，或客户的总支出。通过 DimCars 进行切片将启用诸如 AverageMileage/AveragePurchasePrice 或 CountOfCars by Make/Model 之类的度量。

事实捕获有关事件的度量“事实”。您通常会有多个事实表，除非您的模型非常小，否则单个事实不太可能链接到每个维度。

首先，首先描述您要衡量的内容（购买事件、旅行事件、维修事件），然后确定哪个维度与事实相关联是有意义的。此外，这种关系可能会经历多个维度和事实。例如，如果您想知道客户一年的维修费用，您的模型可能如下所示：

dCustomer dCars dDate

【讨论】：