事實表設計建議

爲了使事情變得簡單，我有一個交易系統，記錄醫生和病人之間的即時消息。在結束時，醫生和病人之間的每個會話的醫生填寫存儲在一個DimOutcome表看起來像這樣一個結果的形式：事實表設計建議

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

我在尋找設計事實表的最佳方法，其將跟蹤消息。需要考慮的一件事是，有時聊天會話可能無法解答（即無法聯繫），然後可以跟進。

什麼是設計一個FactMessage的理想方式，考慮到我需要每一個聊天會話跟蹤DimOutcome。

我想我需要爲信息創建一個事實，另一個用於整個會話，這會是唯一的出路？我還想跟蹤每封郵件和整個會話之間的時間長短？

來源

2012-02-28 schone

您已將此數據倉庫標籤發佈。什麼是您的倉儲用例？預計您收集的這些數據有哪些「讀取」（倉儲行話報告）操作？我們在說什麼數據abt？ MBs，GBs，TBs，10s TBs，更多......？ – Kashyap 2012-02-28 20:32:07

事實表將跟蹤消息

首先，要知道，在一個事實表通常有數據，即可以聚合，測量的事實。維度用於過濾事實表中的數據。其他一切在數據倉庫中都沒有多大意義。也許規範化的數據庫模型會更適合您的需求。需要加以考慮

的一件事是，有時聊天會話可以置之不理

這例如將是一個維度，即DimSession，拿着一樣的狀態的所有會話屬性，即未答覆。請注意，會話的其他屬性（如參與者）可能在維度DimDoctor和DimPatient中。

你也說了，你要跟蹤的「DimOutcome」。這有兩種可能性。首先，將這些信息保存在維度「會話」中。所以你可以過濾你的事實表以獲得不同的結果。另一種可能性是您的事實表中每個結果都有列。這樣您就可以獲得每個結果的會話數量。那至少會是可衡量的。這裏要考慮的是事實表的粒度。每個會話或每天是否有一個條目？如果您在事實表中有結果列，則每個會話一個條目可能不是最好的選擇，因爲您也可以通過按DimSession進行過濾並在事實表上執行COUNT（*）來獲得此信息。

我想我需要爲整個會話創建一個事實消息和另一個，這是唯一的方法嗎？

我認爲這整個數據倉庫的東西是不是你在找什麼。規範化的數據結構會更好地滿足您的需求。

如果你想知道更多一點，如果你想獲得一個想法，數據倉庫是如何實現的，通常谷歌的星型模式或雪花模式。

一個很短的星型模式...

A very shortened star schema structure

來源

2012-02-28 11:26:41 fancyPants

事實表設計建議

回答

相關問題