2013-09-24 70 views
0

我正在處理聯繫歷史事實表的數據倉庫事實表設計。我目前的架構看起來是這樣的:設計事實表以允許簡單的最近檢測事實類

[FK] DateKey INT 
[FK] TimeKey INT 
[NK] CustomerNK INT 
[NK] CustomerPhoneNK INT 
[FK] ContactTypeKey INT 
[FK] ContactResultKey INT 
[BK] ContactRefBK INT 
    ContactTS DATETIME 
    Counter INT (=1) 

我的一個應用要求是要找到在ContactType尺寸的選擇列表最近ContactResultContactType維度具有ContactClass屬性,該屬性將用於標識要過濾的值的範圍。

上述結構讓我得到ContactClassContactType選擇的所有聯繫信息,我可以處理該列表以獲取最新的值。

問題是,任何人都可以建議對上述內容進行修改,以使特定ContactClass最近的聯繫事件更簡單嗎?目前這是一個事務性事實表,但如果能改善可用性,我會很樂意改變這一點。

此操作將針對多種客戶(200K +)進行相當頻繁的運行,因此性能非常重要。該操作將在Web界面的C#代碼中完成,因此在此情況下,BI Tool特定的解決方案對我無用。

到目前爲止,我想出的唯一想法是累計事實表,它只記錄每個ContactClass的最新記錄。任何改進這個選項將不勝感激。

回答

0

如果性能很重要,並且批處理是一個選項,那麼您可以預先計算並在事實或聯繫人類型維度中保存「最新聯繫人」屬性。

這兩個操作都要求您更新歷史事實記錄以將其設置爲「不再是最新聯繫人」,但如果您預先計算此屬性,則會獲得更好的性能。

我會傾向於將該屬性添加到維度,並更新歷史SK的事實以反映不是「最新聯繫人」的維度成員。

有一些想法,有可能是一個聰明的方式來做這個更新。

+0

謝謝。它有助於確認我已經在想什麼 - 預先計算數據將是最好的選擇。考慮到最終用戶可能對聯繫人類的最後一次聯繫和最後一次聯繫都感興趣,我將爲每個聯繫人構建一個單獨的事實表,並在ETL過程中從聯繫人事實表中更新它。 – Corey

+0

我會建議,而不是另一個事實表,只是將其保存到現有的事實表或維度,但我沒有真正與整個設計相交。祝你好運! –

0

如果性能是關鍵,那麼我認爲最新聯繫人的其他事實表就好了。畢竟,這就是數據集市的用途 - 預集合數據以實現快速性能。它不是一個累積的快照,它通常在時間維度上有幾個外鍵來衡量事件之間的時間跨度。

看起來像200k +不是一個非常大的數字,所以你可能能夠以一種更簡單的方式實現相同的事情與視圖。我可能有列錯,但這樣的事情會非常快,在地方索引:

SELECT ContactTypeKey,MAX(ContactTs) FROM factContact GROUP BY ContactTypeKey

然後該視圖可用於通過ContactTypeKey和ContactTs返回事實表以返回ContactResult。這假設您的表名稱爲factContact,並且ContactTs確定最近的等等。實際上,您可能需要加入日期維度才能計算最近的維度,並且您可能需要按更多維度進行分組,或者可能需要加入contactType維度和由ContactClass分組。我有時會使用這種策略,但很難說它在這裏應用得有多好。