數據倉庫 - 隨時間儲存獨特數據

基本上我們正在爲我們的軟件構建一個報告儀表板。我們正在爲客戶提供查看基本報告信息的能力。數據倉庫 - 隨時間儲存獨特數據

例子：（我已經刪除了我們的實際系統的複雜性了這個例子中的99％，因爲這應該還是跨越什麼，我試圖做得到）

一個例子指標是.. 。在特定時間段內查看的獨特產品的數量。也就是說，如果5個產品在一個月的過程中被客戶每次查看100次。如果您運行該月份的報告，則應該僅查看所查看產品的數量爲5。

對於如何在任何時間範圍內查詢數據以及如何返回所查看產品的唯一數量，有何建議？爲了這個例子...可以說有一條規則是應用程序不能直接查詢源表，我們必須將摘要數據存儲在不同的數據庫中並從那裏查詢。

作爲一個附註，我們有很多其他度量標準，我們正在存儲，我們存儲每天聚合。但是由於唯一性問題，這個特定的度量標準是不同的。

我個人認爲這是不可能的。我們目前的解決方案是，我們提供4個預先計算的時間範圍，其中受指標影響的指標可用。如果您使用自定義時間範圍，則該指標不再可用，因爲我們沒有預先計算的數據。

2017-08-24 chadwin

我想知道......而不是保存彙總數據的其他地方，怎麼樣界定返回的計數VIEW項目（或任何摘要數據）並在視圖上應用日期範圍過濾器？或者甚至更好...定義一個存儲過程，該存儲過程根據源數據上的日期範圍（作爲參數傳遞）應用SELECT語句。 – Sparrow

我們需要預先分析並存儲這些數據，因爲我們正在運行數百萬行數百萬行，所以每次客戶運行報表時都要隨時生成此數據將需要很長時間。在客戶端基礎上，只需要幾秒鐘，這並不壞。但是這些數據也被用於基準測試（將一個客戶端與其他客戶端進行比較），當一次爲成千上萬的客戶端運行時，需要很長的時間才能實時計算。使用我們的預製數據庫，其他度量標準只需要幾分之一秒的時間來彙總數千個客戶端。 – chadwin

您正在使用哪種數據倉庫方法，Inmon或Kimball？ – Eli

你的問題是你試圖改變事實表的粒度。這是無法完成的。

你最好的選擇是我認爲你現在正在做的事 - 在一天，一週和一個月的穀物中定義聚合事實表以支持你的性能約束。

您可以簡單地通過建議您的用戶這將比標準聚合速度更慢來解決自定義時間範圍。例如，想知道的在星期二銷售的獨特的產品計數，用戶可以寫這樣的查詢，在一些性能損失爲代價的：

select distinct dim_prod.pcode 
     ,count(*) 
from fact_sale 
     join dim_prod on dim_prod.pkey = fact_sale.pkey 
     join dim_date on dim_date.dkey = fact_sale.dkey 
where dim_date.day_name = 'Tuesday' 
group by dim_prod.pcode

查詢也對每天彙總，而不是被寫入事實上，因爲它會掃描更少的數據，它會運行得更快，甚至可以滿足您的需求

來源

2017-08-26 22:31:25

根據您提供的信息，我認爲您試圖衡量'一個月內查看的獨特產品數量（例如）'。

不確定您是否使用Kimball方法來設計您的事實表。我相信在Kimball方法中，建議您積累快照事實表以滿足這樣的要求。

我可能會宣講到轉化（在這種情況下道歉），但如果沒有，那麼我會放你走，通過下面的鏈接，專家已經詳細解釋這一概念： http://www.kimballgroup.com/2012/05/design-tip-145-time-stamping-accumulating-snapshot-fact-tables/

我也有包括來自金博爾另一鏈路，這解釋了不同類型的事實表的詳細：

http://www.kimballgroup.com/2014/06/design-tip-167-complementary-fact-table-types/

希望有所詳細解釋的概念。更樂意回答任何問題（給我最大的能力）

乾杯尼西

來源

2017-08-29 11:01:45

數據倉庫 - 隨時間儲存獨特數據

回答

相關問題