事实表设计建议答案

【问题标题】：Fact Table Design Suggestions事实表设计建议
【发布时间】：2012-02-28 19:26:41
【问题描述】：

为了简单起见，我有一个事务系统，用于记录医生和患者之间的即时消息。在医生和患者之间的每次会话结束时，医生填写一个结果表，该表存储在一个 DimOutcome 表中，如下所示：

DimOutcome
----------
PK_OutcomeKey
OutcomeCategory1
OutcomeCategory2
OutcomeCategory3
...

我正在寻找设计跟踪消息的事实表的最佳方法。需要考虑的一件事是，有时聊天会话可能会无人接听（即非工作时间联系），然后可以跟进。

考虑到我需要跟踪每个聊天会话的 DimOutcome，设计 FactMessage 的理想方式是什么。

我想我需要为消息创建一个事实，为整个会话创建另一个事实，这是唯一的方法吗？我还想跟踪每条消息与总会话之间的时间量？

【问题讨论】：

您已使用数据仓库标签发布此内容。您的仓储用例是什么？对于您收集的这些数据，预计会有哪些类型的“读取”（仓储术语中的报告）操作？我们在谈论多少数据？ MB，GB，TB，10 TB，更多...？

标签： sql sql-server data-modeling data-warehouse

【解决方案1】：

将跟踪消息的事实表

首先，请注意，事实表中通常包含可以聚合、测量的事实的数据。维度用于过滤事实表中的数据。其他一切在数据仓库中都没有多大意义。也许规范化的数据库模型会更好地满足您的需求。

需要考虑的一件事是，有时聊天会话可能无人接听

例如，这将在一个维度中，即 DimSession，包含所有会话的属性，例如状态，即未回答。请注意，会话的其他属性（例如参与者）可能位于维度 DimDoctor 和 DimPatient 中。

您还说过，您想跟踪“DimOutcome”。这里有两种可能性。首先，将此信息保存在维度“会话”中。因此，您可以过滤事实表以获得不同的结果。另一种可能性是您的事实表中的每个结果都有列。这样你就有了每个结果的会话数量。这至少是可以衡量的。您在这里必须考虑的是事实表的粒度。每个会话或每天有一个条目吗？如果您在事实表中使用结果列，则每个会话一个条目可能不是最佳选择，因为您还可以通过过滤每个 DimSession 并在事实表上执行 COUNT(*) 来获得此信息。

我想我需要为消息创建一个事实，而另一个对于整个会话，这是唯一的方法吗？

我认为这整个数据仓库并不是您想要的。规范化的数据结构会更好地满足您的需求。

如果您想了解更多相关信息，请在 Google 上搜索星型架构或雪花架构（如果您想了解数据仓库通常是如何实现的）。

一个非常短的星型模式...

【讨论】：