數據倉庫立方體中應用了哪些數據結構和算法？

嗨，傑夫。看看星型模式鏈接的圖10。採取零售業務的沃爾瑪將擁有數萬億的SalesFact行。如果不是彙總表TimeDimension和StoreDimension，則對SalesFact的查詢永遠不會結束。彙總表回答了大部分常見問題。實際的數據存儲與設計數據倉庫無關，因此大多數查詢都由彙總表來回答。現在構建和維護彙總表，這需要定期運行批處理進程。 – 2010-05-23 23:13:37

摘要事實不存儲在維度中。那些事實只是聚合在不同的粒度上（可能有不同的維度），但它們仍然存儲在事實表中。 – 2010-05-24 05:31:33

在星型模式數據庫，事實通常是獲取並存儲在最好的穀物。

因此，讓我們的SalesFact例如，從圖10中http://www.ciobriefings.com/Publications/WhitePapers/DesigningtheStarSchemaDatabase/tabid/101/Default.aspx

眼下，糧食是產品，時間（每天粒度），商店。假設您希望按月預彙總（這個特定示例不太可能需要預彙總，但如果銷售是由客戶詳細說明的，則按分鐘預彙總可能是必要的）。

然後，你將有一個SalesFactMonthly（或添加糧食歧視現有的事實表，因爲尺寸是相同的 - 有時在聚合，你可能實際上失去了尺寸就像你可以失去糧食，例如，如果你只是想要由商店而不是按產品）。

ProductID 
TimeID (only linking to DayOfMonth = 1) 
StoredID 
SalesDollars

而你也這樣做會得到：

INSERT INTO SalesFactMonthly (ProductID, TimeID, StoreID, SalesDollars) 
SELECT sf.ProductID 
    ,(SELECT TimeID FROM TimeDimension WHERE Year = td.Year AND Month = td.Month AND DayOfMonth = 1) -- One way to find the single month dimension row 
    ,sf.StoreID 
    ,SUM(sf.SalesDollars) 
FROM SalesFact AS sf 
INNER JOIN TimeDimension AS td 
    ON td.TimeID = sf.TimeID 
GROUP BY td.Year, td.Month

在立方體會發生什麼事是你基本上細粒度明星和預聚集在一起 - 但每個實現是專有的 - 有時你可能不即使在立方體中有最細的數據，也無法報告。但是，您可能希望將數據切片的每種方式都需要存儲在該顆粒中，否則無法以這種方式進行分析。

來源

2010-05-24 14:51:45

數據倉庫立方體中應用了哪些數據結構和算法？

回答

相關問題