为了使事情变得简单，我有一个交易系统，记录医生和病人之间的即时消息。在结束时，医生和病人之间的每个会话的医生填写存储在一个DimOutcome表看起来像这样一个结果的形式：事实表设计建议
DimOutcome
----------
PK_OutcomeKey
OutcomeCategory1
OutcomeCategory2
OutcomeCategory3
...
我在寻找设计事实表的最佳方法，其将跟踪消息。需要考虑的一件事是，有时聊天会话可能无法解答（即无法联系），然后可以跟进。
什么是设计一个FactMessage的理想方式，考虑到我需要每一个聊天会话跟踪DimOutcome。
我想我需要为信息创建一个事实，另一个用于整个会话，这会是唯一的出路？我还想跟踪每封邮件和整个会话之间的时间长短？
事实表将跟踪消息
首先，要知道，在一个事实表通常有数据，即可以聚合，测量的事实。维度用于过滤事实表中的数据。其他一切在数据仓库中都没有多大意义。也许规范化的数据库模型会更适合您的需求。需要加以考虑
的一件事是，有时 聊天会话可以置之不理
这例如将是一个维度，即DimSession，拿着一样的状态的所有会话属性，即未答复。请注意，会话的其他属性（如参与者）可能在维度DimDoctor和DimPatient中。
你也说了，你要跟踪的“DimOutcome”。这有两种可能性。首先，将这些信息保存在维度“会话”中。所以你可以过滤你的事实表以获得不同的结果。 另一种可能性是您的事实表中每个结果都有列。这样您就可以获得每个结果的会话数量。那至少会是可衡量的。 这里要考虑的是事实表的粒度。每个会话或每天是否有一个条目？如果您在事实表中有结果列，则每个会话一个条目可能不是最好的选择，因为您也可以通过按DimSession进行过滤并在事实表上执行COUNT（*）来获得此信息。
我想我需要为整个会话创建一个事实消息和另一个 ，这是唯一的方法吗？
我认为这整个数据仓库的东西是不是你在找什么。规范化的数据结构会更好地满足您的需求。
如果你想知道更多一点，如果你想获得一个想法，数据仓库是如何实现的，通常谷歌的星型模式或雪花模式。
一个很短的星型模式...
您已将此数据仓库标签发布。什么是您的仓储用例？预计您收集的这些数据有哪些“读取”（仓储行话报告）操作？我们在说什么数据abt？ MBs，GBs，TBs，10s TBs，更多......？ – Kashyap 2012-02-28 20:32:07