如何為事實表建模

Question

我將創建一個星型模式中包含事實和維度的數據倉庫。

我要回答的業務問題通常是：

• 我們在第一季度賣了多少錢？
• 我們在第一季度賣給女性多少錢？
• 我們在第一季度向30-35歲之間的女性出售了多少錢？
• 我們在第一季度向居住在紐約的30-35歲女性出售了多少錢？

• 我們在第一季度向居住在紐約的30-35歲女性出售了多少錢？

• 去年我們賣了多少錢在類別衣服上？

• 去年我們賣出藍色牛仔褲產品多少錢？
• 去年，我們向居住在澳大利亞的40-42歲之間的男性出售了多少件藍色牛仔褲產品？

我正在考慮一個小時的粒度（指定年，月，日，小時，季度，日期名稱，月名稱等）的日期維度，也正在考慮產品維度和用戶維度。

我想知道是否可以使用單個事實表來回答這些問題，或者是否適合創建多個事實表？ 我正在考慮一個表，例如：

事實銷售

DimDate-fk到包含有關日期（例如季度，星期幾，年，月，日）信息的表

DimProduct-fk到包含有關產品信息的表，例如（產品名稱）

DimUser-fk到包含有關用戶信息（例如（年齡，性別）的信息）的表

TotalSales-特定日期，產品和用戶的所有銷售額的總和。

另外，如果我想衡量展位的總銷售額（金額）和總銷售數量？ 創建具有相同維度但使用TotalNumberOfSales代替事實的新事實表是否合適？

感謝所有我能得到的輸入。

Answer 1

我認為您在正確的軌道上。 上面的所有問題都應該僅使用覆蓋銷售的一個事實表即可回答。

我認為應該一開始就不進行匯總，而后在需要時匯總。 考慮到一筆交易可以包含多個產品和多個項目，因此我將其組織如下：交易中每種產品的事實行（通常是發票上的行，因此我將其稱為“訂單行”或“銷售線”），可能還有三個計數器屬性：

• NumItems項目數，即3（如果客戶購買了三個相同的產品）。
• NumLines （“訂單行”的數量）應始終為1。在以后聚合數據時count(*)在SQL中已經有sum(NumLines)而不是count(*)大獲成功）或添加更正項（ NumLines = -1 ）。
• NumSales小數，因此可以求和以得出銷售數量（即，如果銷售涉及三種不同產品並因此包含三個訂單行，則為0.333）。

現在，要獲得正確的計數會遇到一個問題，即“涉及黑衣服的銷售數量”。 我們在以前的工作場所遇到了這個問題-我確信必須為此存在一些“最佳實踐”，我們通過在事實表（或TransactionID ）中引入SaleID並進行count(distinct SaleID) 。 缺乏優雅，但有效。

在我們的設置中，我們有幾個貨幣屬性-最重要的是，一個屬性是收入（支付了所售商品所產生的直接成本后的剩余收入），另一個是營業額（客戶為該商品支付的價格）。 營業稅或增值稅可能會增加更多的復雜性。 一個人可以只用一個money屬性就能實現，然后將銷售分成事實表中的多行，但我想我會建議在銷售行事實表中有多個money列。 事實表中的所有內容均以“基礎貨幣”（在我們的情況下為歐元）計算，然后我們有了一個匯率維度來跟蹤確切的金額。

我認為具有包含一天中時間的日期維度是沒有意義的。 在我以前的工作中，我將倉庫保存在postgres中，並且即使沒有日期維度，我實際上也做得很好-盡管日期維度被認為是“最佳業務實踐”，但我發現從性能角度而言，對於我們所有的目標，我們都能獲得更好的性能通過使用標准的postgres日期函數，而不是拖動日期維度。 我玩了很多，最后我認為最理想的方法是將日期和時間分成兩個不同的屬性。 （時區和夏時制讓我頭疼很多……）

Answer 2

我同意tobixen-您的方向正確。

我建議您閱讀Ralph Kimball的書“數據倉庫工具包”，特別是有關零售的一章-它詳細介紹了銷售事實。

日期維度就像具有日歷表一樣-您可以根據季度，會計月份以及其他特定於日期的業務進行拆分。 我通常同時保留日期鍵和時間戳記數據類型，因此我們可以使用“財政日歷”執行操作。 如果您需要將表的粒度保持在該級別，則需要一個單獨的“時間”維度，例如每天需要幾個小時或幾分鍾的存儲桶。我懷疑您是否需要每小時使用。

這就是我要做的：

聲明事實表的粒度：

每條訂單行1行

請注意，谷粒如何不包含任何不能唯一標識行的內容。

訂單行的尺寸屬性：

Date
Time (if needed, and bucketed by hour/minute etc)
Product
Customer

訂單行的退化尺寸（這些是與交易相關的代碼）：

Order Number
Order Line Number

一些樣本度量：

Item Price at time of Sale (optional, may be useful in some situations)
Discount Amount
Sale Dollars

這應該回答所有這些問題。

對於總數，對維度的屬性進行過濾后，簡單的COUNT / SUM應該可以正常工作。

您應該考慮到客戶維度是最難建模的模型之一，Kimball在其書中整整一章專門介紹了客戶維度。