數據庫倉庫設計：事實表和維表

我正在用RDBMS構建一個窮人的數據倉庫。我已經確定的關鍵 '屬性' 被記錄爲：數據庫倉庫設計：事實表和維表

性別（真/假）
人口分類（A，B，C等）
出生地
出生日期
重量（每日記錄）：正在錄製

我的要求其實是能夠運行「OLAP的查詢，讓我：

「切片和切塊」
「鑽取向上/向下」中的數據和
通常，能夠從不同的角度

查看數據關於此主題的區域讀取了後，普遍的共識似乎是，這最好使用維度表而不是標準化表來實現。

假設這個斷言是真的（即解決方案最好使用事實和維度表來實現），我想在這些表的設計中尋求一些幫助。

'自然'（或明顯的）尺寸：

日期維度
地理位置

其中有層次的屬性。

性別（真/假）
人口分類（A，B，C等）

我掙扎的原因：但是，我與如何建模以下字段掙扎這些領域是：

他們沒有明顯的等級屬性，這將有助於聚集（AFAIA） - 這表明他們應該在事實表
他們大多是靜態的或很少改變 - 這表明他們應該在維度表中。

也許我上面使用的啓發式過於粗糙？

我會舉幾個例子來說明我希望在數據倉庫中進行的分析類型 - 希望能夠進一步闡明事情。

我想按性別和人口統計分類彙總和分析數據 - 例如回答如下問題：

男性和女性的體重在不同人口統計分類中的比較如何？
哪個人口統計分類（男性和女性）顯示本季度體重增幅最大。

等

任何人都可以澄清性和人口分類是否是事實表的一部分，或者它們是否是（我懷疑）維表？

另外假設他們是維度表，有人可以詳細說明表結構（即字段）？

的 '明顯' 的架構：

CREATE TABLE sex_type (is_male int); 
CREATE TABLE demographic_category (id int, name varchar(4));

可能不是正確。

來源

2010-05-29 morpheous

不確定爲什麼你覺得使用RDBMS是窮人的解決方案，但希望這可能有所幫助。

表dimGeography和dimDemographic是所謂的微型尺寸;它們允許基於人口統計和地理位置進行切片，而無需加入dimUser，還可以在測量時捕捉用戶當前的人口統計和地理位置。

順便提一句，在DW世界的時候，冗長 - Gender = 'female', AgeGroup = '30-35', EducationLevel = 'university', etc.

來源

2010-05-29 13:23:24

星型模式搜索是維恩圖交點的SQL等價物。如您的示例查詢清楚顯示，SEX_TYPE和DEMOGRAPHIC_CATEGORY是您要搜索的設置，因此必須是維度。

至於表格結構，我認爲你的SEX_TYPE設計是錯誤的。對於初學者來說更容易，更直觀，給

where sex_type.name = 'FEMALE'

的基礎上設計查詢比

where sex_type.is_male = 1

此外，在現實世界中的性別不是一個布爾值。大多數應用程序也應該收集UNKNOWN和TRANSGENDER，這對健康/醫療應用程序來說無疑是正確的，這正是你所做的。此外，如果您有任何女性同事，這將避免一些令人不快的辦公室爭論。

編輯

「我想到的是如何處理例新sex_types和人口類別尚未在數據庫」

有不一個時尚數據倉庫中有外鍵。但是它們提供了有用的元數據，查詢優化器可以使用這些元數據來推導出最有效的搜索路徑。當需要處理大量數據和即席查詢時，這一點尤爲重要。處理新的維度值總是會很難，除非您的源系統向您提供通知。這真的取決於你的設置。

來源

2010-05-29 07:56:06 APC

感謝您的意見。現在我已經知道SEX_TYPE和DEMOGRAPHIC_CATEGORY是尺寸。這對我來說是新的領域，所以我可能不得不再問幾個看似平庸的問題。請耐心等待。從上面，我的理解是我需要在事實表中有SEK_TYPE和DEMOGRAPHIC_CATEGORY中的PK的FK。你能證實這一點嗎？（我正在考慮如何處理數據庫中尚未存在的新的sex_types和人口統計類別）。 – morpheous 2010-05-29 08:55:07

您打算使用哪種OLAP /表示層工具？這些通常具有自己的功能來支持多維數據集，層次結構，聚合等的構建。

正常形式通常是靈活高效的數據倉庫的最佳基礎，儘管市場有時非規範化以支持特定的報告要求。在沒有任何其他信息的情況下，我建議你的目標是確保你的數據庫至少是Boyce-Codd/5th Normal Form。

來源

2010-05-29 10:05:49 sqlvogel

一般來說，所有的數字量和措施是在事實表（或多個）列。那麼其他一切都是維度屬性。他們所屬的維度是相當務實的，取決於數據。

除了您已收到的建議，我看到沒有提及退化尺寸。在這些情況下，事實上需要存儲不同事實的發票號或序列號時間戳等事項，否則維度表將與事實表一起變爲1-1。

您的案例中的關鍵設計決策可能是分析與年齡相關的數據，如果研究正在進行。因爲人們的年齡隨着時間的推移而變化，他們會在某個時候轉移到另一個年齡段。取決於這些組是否在研究開始時是固定的，這可能決定你想要如何聚合。我不一定說你應該有一個組維度並逐步完善，但是你可能需要在ETL期間確定正確的年齡/人口統計維度。但這取決於最終用途（或者同時適用於從事實錶鏈接的二維角色 - 初始人口統計數據，從不變化，以及當前的人口統計數據將隨着時間而改變）。

類似的事情可能適用於地理。儘管通過分析當前地理區域的變化，你顯然可以追蹤一個人的地理位置，但是維度DW的要點是要將所有相關維度直接與事實相關聯（通常可以通過網絡實體 - 關係模型 - 在ETL時間被鎖定）。這種冗餘使傳統RDBMS中的維度模型的分析更加快速。

請注意，很多這不適用於像Teradata這樣的大規模並行DW，對於星型模式表現不佳 - 它們喜歡將所有數據規範化並鏈接到相同的主索引，因爲它們的主索引通過處理單元分發數據。

來源

2010-05-30 14:22:55

數據庫倉庫設計：事實表和維表

回答

相關問題