關係與維度數據庫有什麼不同？

我想了解OLAP和數據倉庫，並且我對關係和維度建模之間的差異感到困惑。維度建模基本上是關係建模，但允許冗餘/非規範化的數據？關係與維度數據庫有什麼不同？

例如，假設我有（產品，城市，＃銷售）的歷史銷售數據。據我所知，以下將是一個關係點的觀點：

 
Product | City | # Sales 
Apples, San Francisco, 400 
Apples, Boston, 700 
Apples, Seattle, 600 
Oranges, San Francisco, 550 
Oranges, Boston, 500 
Oranges, Seattle, 600

儘管下面是更多的三維點的視圖：

 
Product | San Francisco | Boston | Seattle 
Apples, 400, 700, 600 
Oranges, 550, 500, 600

但似乎這兩種觀點仍然會以相同的星型模式實現：

 
Fact table: Product ID, Region ID, # Sales 
Product dimension: Product ID, Product Name 
City dimension: City ID, City Name

直到你開始添加一些額外的細節到每個維度的差異開始雨後春筍般冒出來它不是。舉例來說，如果你想跟蹤的區域爲好，關係型數據庫傾向於有一個單獨的區域表，以確保一切歸一化：

 
City dimension: City ID, City Name, Region ID 
Region dimension: Region ID, Region Name, Region Manager, # Regional Stores

雖然維庫將允許非規範化，以保持區域數據在城市維度內，以便更容易地分片數據：

 
City dimension: City ID, City Name, Region Name, Region Manager, # Regional Stores

這是正確的嗎？

來源

2010-05-09 grautur

閱讀OLTP和OLAP之間的差異。 http://datawarehouse4u.info/OLTP-vs-OLAP.html – Oded 2010-05-09 18:08:31

是的，我已經閱讀了差異。我感到困惑的部分是當某些事情提到OLAP通常涉及維度而不是關係型數據庫時。尺寸是否僅僅指「非標準化+星形/雪花」方面？或者還有「關係型」明星/雪花模式嗎？ – grautur 2010-05-09 18:37:55

星型模式確實位於數據的關係模型和數據的維度模型的交集處。它實際上是一種從維度模型開始，將其映射到SQL表中的方式，它與從關係模型開始的SQL表有點類似。

我說有點相似，因爲許多關係設計方法導致歸一化設計，或至少幾乎標準化的設計。星型模式將與完全正常化有重大偏差。

每次偏離完全正常化都帶來隨之而來的數據更新異常。（我包括關於插入，更新和刪除操作的統一體）。這些異常與您開始使用的數據模型沒有任何關係。

有關OLTP與OLAP的評論與此處相關。在這兩種情況下，更新異常對性能和/或編程難度會有不同的影響。

除了SQL數據庫中的星型模式之外，還有一些尺寸數據庫產品，它們以物理形式存儲數據，該物理形式對於該產品是唯一的。使用這些產品，您看不到明星架構，因爲您看到直接實現維度模型以及可能是產品特有的接口。其中一些接口允許OLAP操作完全點擊。

就像您對問題的一個偏離，我曾經構建了一個星型模式作爲支持基於事務的應用程序的OLTP數據庫和Cognos PowerPlay內的數據庫之間的中間步驟。使用標準的ETL技術，從OLTP數據庫到星型模式，然後從星型模式到數據立方體的組合傳輸實際上超過了從OLTP數據庫到數據立方體的直接傳輸。這是一個意外的結果。

希望這會有所幫助。

來源

2010-05-09 21:02:04

在簡單的話OLTP規範化的數據庫被設計成具有的視圖最優「事務」點。數據庫被標準化以最佳地適用於事務處理系統。當我說交易系統我的意思是..getting數據庫結構，其中的所有事務性操作喜歡刪除，插入，更新的設計狀態和選擇的優化是平衡在任何時間點給所有的人都等於或最佳的重要性..因爲它們在交易系統中同樣重要。

這是什麼標準化的系統提供..minimal的新條目更新可能的數據更新，最小的插入可能，一個地方刪除類別刪除等（如新的產品類別）......這一切都是可能的，我們一分支創建主表.....但這是以「選擇」操作延遲爲代價..但正如我所說的（標準化）不是所有操作的最有效模型..「最佳」...說了我們得到了其他方法來提高數據獲取速度..如索引等

另一方面維數模型（主要用於數據倉庫設計）..意味着重視只有一種操作即數據選擇...和數據倉庫一樣..數據更新/插入定期發生..以及它的一次性成本。因此，如果試圖調整規範化的數據結構，以便只有選擇是在任何時間點最重要的操作...我們將最終得到一個非規範化（我會說部分非規格化）..維星結構。

所有的外鍵一個一個地方，事實 - 沒有尺寸標註連接（即主掌握表連接）..雪花代表相同的尺寸
- 理想的設計，事實只能攜帶號碼..measures或外鍵
- 尺寸用於承載描述和非可聚合信息
- 數據冗餘被忽略......但在極少數情況下，如果尺寸本身增長過多.snowflake設計被視爲選項..但仍然是可以避免的

有關詳細信息，請閱讀有關此主題的詳細書籍。

來源

2010-08-20 10:25:04 Vijender

我最近剛剛閱讀了關於維和關係數據模型之間的差別，因爲我們主要是在我的業務使用關係模型我們存儲的企業級數據倉庫（EDW）。

據史蒂夫·霍伯曼在他的著作「數據模型化繁爲簡」的2種型號之間的區別是這樣的：

關係數據模型捕獲對業務運作的如何部分的業務解決方案，又名業務流程
多維數據模型捕獲業務需要回答有關問題的細節是做得如何

它可以說，關係模型也可以作爲賴以爲基礎回答商業問題，但在戰術層面。「由於信貸持有，客戶x有多少訂單處於未履行狀態？「但區別在於報表問題需要表中的」本地穀物「以及何時可以用匯總數據回答報告問題。

在上面的2個示例中，它們實際上都是維數據建模因爲這兩張表都沒有將銷售訂單存儲在其「原生穀物」中，因此不會捕獲創建銷售訂單的業務流程。兩張表之間的唯一區別在於第二張表中的城市維度換成事實表

來源

2013-10-11 21:56:23 codemagic

我認爲你有最好的答案，我會補充一點，即使你需要統計數據，即使你在關係模型中嘗試了所有的調整，最終你也會接近一個星型模式，也就是有許多外來的摘要（事實）表按鍵 – delmalki 2016-12-07 19:31:17

我發現我在http://www.orafaq.com/node/2286上發現的描述在從關係角度來到星型模式時非常有幫助

考慮一個完全標準化的數據模型。現在想想正好相反的情況，你完全去規範你的關係數據模型，這樣你就只有一個平坦的記錄，就像一個寬行的big'ol電子表格。現在從這個平坦的記錄中稍微備份一下，這樣您的數據模型只有兩層;一張大桌子和一張大桌子指向的小桌子。這是一個STAR模式。因此，一個真正的星形數據模型有兩個屬性，它總是兩層深，而一個真正的星形模型總是隻包含一個作爲模型焦點的大表。

來源

2017-05-19 09:50:58

關係與維度數據庫有什麼不同？

回答

相關問題