star schema[轉帖]

數據倉庫這麼多年來發展的成果，我認爲恐怕最重要的要算star schema了，能夠說它是整個數據倉庫的基石。

star schema主要的思想在於將咱們關心的數據和用於描述數據的屬性分隔開來。實際的數據存放於Fact table中，從不一樣角度來描述數據的屬性放到不一樣的dimension table中。好比，一個sales數據倉庫能夠這樣設計，每一筆銷售記錄，應該會包含銷售的產品，銷售的客戶，銷售的供貨商，銷售的時間，銷售的數量和得到的收入等。當咱們要分析整個公司的全部銷售記錄時，毫無疑問，咱們最關心的是一共銷售了多少？一共得到了多少收入？而後更進一步，在某個時間段內銷售了多少？來自哪家供貨商的產品的銷售額最大？面向哪一種客戶的銷售額最大？哪一種產品的銷售額最大？等等。

從上面咱們關心的這些問題咱們能夠看到，對於銷售的數量和金額這類具體的數字型的數據，一般是咱們分析的對象，而對於像時間，產品，客戶，供貨商，咱們但願從這些不一樣的角度來獲得數字型數據的一個統計結果。因此，咱們將數字型的數據存放在fact table中，將時間，產品，客戶，供貨商存放在不一樣的dimension table中，天然，在fact table和dimension table之間存在一個主-外鍵的關聯，各個dimension table之間則沒有關係。由此咱們能夠獲得以下的一個star schema:

 

star schema之因此叫star schema，就是因爲上面這個圖形的形狀來的，fact table處於中間的位置，dimension table圍成一圈，每一個dimension table和fact table關聯。

fact table中除了區分每條記錄的主鍵（fact table的主鍵頗有多是全部dimension table的外鍵組合起來的一個組合主鍵），鏈接每一個dimension table的外鍵外，就只有咱們關心的數字型數據，因此fact table中的每條記錄，有個專門的術語稱之爲度量(measurement)，由於咱們利用數據倉庫作統計分析的時候，這些數據就是統計分析的一個個基本單位，也就是度量值。

除了star schema，最出名的要算從star schema中衍生出來的snowflake schema了。雪花模型就是在星模型的基礎上，對dimension table作規範化後等到的模型，因爲每一個dimension table因爲規範化可能獲得許多的小表，雪花模型比起星模型就更加複雜，查詢的時候也須要關聯更多的表。

oracle在文檔中說，除非你有很是特別的緣由，推薦此採用star schema來進行數據倉庫的架構設計。