Sql 事实表设计建议

为了简单起见，我有一个事务性系统，它记录医生和病人之间的即时消息。在医生和患者之间的每次治疗结束时，医生填写一份结果表，该表存储在DIMOUTPUTE表格中，如下所示：

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

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

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

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

跟踪消息的事实表

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

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

例如，它将位于一个维度中，即DimSession，保存所有会话的属性，如status，即UN应答。请注意，会话的其他属性（如参与者）可能在维度DimDoctor和DimPatient中

你还说，你想跟踪“结果”。这里有两种可能性。首先，将此信息保存在维度“会话”中。因此，您可以根据不同的结果筛选事实表。 另一种可能是事实表中的每个结果都有列。因此，您可以获得每个结果的会话量。这至少是可以衡量的。 这里需要考虑的是事实表的粒度。每节课或每天有一个条目吗？如果在事实表中有结果列，则每个会话一个条目可能不是最佳选择，因为您也可以通过过滤每个会话并在事实表上进行计数（*）来获得此信息

我想我需要为信息创建一个事实和另一个事实 对于整个会议来说，这是唯一的办法吗

我认为整个数据仓库不是你想要的。标准化的数据结构更适合您的需要

如果您想了解更多信息，可以使用谷歌搜索星型模式或雪花模式，如果您想了解数据仓库通常是如何实现的

一个非常短的星型模式

---

您已将此信息与数据仓库标签一起发布。你的仓库用例是什么？对于您收集的数据，您希望执行哪些类型的“读取”（仓储术语中的报告）操作？我们谈论的abt数据有多少？MBs，GBs，TBs，10秒的TBs，更多？