報告非規範化與規範化數據庫

我們正在構建報告應用程序，其中我們將每天傾銷大量數據。目前我們有兩個數據模型用於運營和另一個報告。報告非規範化與規範化數據庫

報表數據模型中的幾列存在於操作表中。如果操作數據模型得到更新，我們可以如何確保報告數據模型進行類似的更改，那麼更新的成本又會是多少？

例子：

Report Table - 
    user_name 
    organisation_name 
    event_name 
    etc 10 more col. 

User Table - 
    id 
    name 
    .. 

Organisation Table - 
    id 
    name

讓我們考慮報告表包括1萬條記錄，並組織名稱得到改變，這種改變需要在報告表中反映出來。改變細節的頻率可能是平均的。

因此，我們有兩個選擇規範化的數據庫 -
這將節省報告表更新用，但查詢處理將需要更長的時間。非規範化數據庫 - 這將有助於我們指導更快的查詢處理，但它會涉及到維護它的複雜性。

請指教，我們該走哪條路？我們的數據量非常高，報告數據高度細化。

來源

2017-08-30 RockStar

一些查詢可能會更快，有些人可能會比較慢。「不成熟的優化是萬惡之源。」 – philipxy

唯一的選擇確實是歸一化數據庫。爲什麼？

優點：

更容易維護。
由於您將擁有大量數據，規範化的數據庫將需要更少的磁盤空間！爲什麼？因爲我們不是每次用他的用戶名代表用戶，我們說平均需要10個字符，而是使用他的id，並且只用2或3個字符。在很遠的範圍內，這是一個巨大的差異。

「較慢」的查詢實際上並不是真的很慢。唯一的弱點是，你必須多編一些代碼。但是，你編碼一次，數據庫永遠保持。

來源

2017-08-30 08:16:52 campovski

你的規範化的例子是引入一個代理鍵。除少數情況外，代理鍵與標準化無關。規範化是將複雜謂詞分解爲基本事實類型，同時保留數據中的依賴關係，其目標是通過消除冗餘和數據異常來確保一致性。存儲空間和性能不是邏輯模型的問題。 – reaanb

我認爲這個問題並沒有問什麼是標準化或什麼是標準化，但爲什麼要使用標準化。更簡單的維護帳戶（數據一致性等） – campovski

「非規範化」這個詞的問題在於它沒有具體說明您將使用哪些設計原則。一個更好的計劃是採用一個特定的設計方案，一個不會導致完全標準化的數據庫，但這有一定的作用。

相當廣泛使用的設計方案是星型模式或近似變型雪花模式。這兩種模式已用於報告數據庫，以及數據集市和數據倉庫。

在我處理星型模式的每一種情況下，數據都是從一個或多個其他數據庫複製而來的，並且這些源數據庫被標準化。源數據庫用於OLTP（聯機事務處理），而星型模式用於OLAP（聯機分析處理）目的，包括報告。

定期（如每天一次）將數據從OLTP存儲傳輸到OLAP存儲的過程稱爲ETL（提取，傳輸和加載）。這本身就是一門藝術，並且有些工具可以用來促進ETL。如果您想構建自己的ETL過程，還可以學習一些技巧。

有兩個數據庫，一個用於OLTP，另一個用於OLAP的模式可以讓您在兩種不同的上下文中獲得兩種不同設計模式的好處。維護兩個不同的數據庫的成本幾乎是維護兩個數據庫的兩倍，並且您還必須管理傳輸過程。

所有這些都不能爲您的問題給出明確的答案，但它確實爲您提供了一些用於在網絡上搜索相關項目的流行語。

來源

2017-08-30 10:46:19

第一個問題：

讓我們考慮報告表包括1萬條記錄，和組織名稱得到改變，這種改變需要報告表中得到體現......

.. 。更新的費用會多少？

它應該很低，因爲我們不需要更新「報表」。您只需要更新維度表，並且這是爲什麼：

請考慮不製作由報告工具直接讀取的「報告表」。請考慮使用星型模式（其中一個「非規範化」選項）。該報告將通過在運行時將維度加入維度來生成。

請參見銷售星型模式的這個實體關係圖（ERD）： https://upload.wikimedia.org/wikipedia/en/f/fe/Star-schema-example.png

讓我們想象一下維基文章中的例子ERD是爲擁有不同的品牌專賣店一家公司的數據倉庫，所以他們的名字會彼此不同。

因此，讓我們將「store_name」列添加到DIM_STORE表中，並僅添加到DIM_STORE表中。 FACT_SALES表保持不變。

當商店更改其名稱時，我們更新DIM_STORE.store_name列。

DIM_STORE和FACT_SALES加入store_id，允許我們從DIM中獲取當前的商店名稱。

商店很少更改它們的名稱，但是當它發生時，報告用戶通常希望記錄此更改。這種尺寸更新稱爲緩變尺寸（SCD）。

本Wiki文章解釋的SCD： https://en.wikipedia.org/wiki/Slowly_changing_dimension

FYI，SCD 1型和2是常用的。我更喜歡Type 2，因爲它保留了歷史記錄，但是爲您的報告要求選擇最好的一個。

的ERD來源於此維基文章星型架構： https://en.wikipedia.org/wiki/Star_schema

第二個問題：

如果運行數據模型得到更新，我們如何確保上報數據模型做出類似的改變

如果表結構在源系統發生變化，那麼你將^ h可以相應地手動更新您的加載過程和數據倉庫表。在某些情況下，這可能涉及重新加載所有數據。

代理鍵：密切相關的問題，代理鍵是必要的維護的SCD： http://www.bidw.org/datawarehousing/what-is-surrogate-key/

在上的SCD維基文章supplier_key是由數據倉庫或ETL prcess產生的代理鍵，並且supplier_code類似於來自事務性源數據庫的organization_id（或Wiki文章中有關星型模式的store_id）。

我覺得這些概念需要一些研究和重新閱讀消化，所以我希望你不要着急的事情。如果做得對，他們需要大量時間進行規劃和設計，但以後會節省大量開發時間。

來源

2017-10-10 00:41:52

報告非規範化與規範化數據庫

回答

相關問題