如何設計資料庫 2 ？（芮）

資料規範化

• 僅有好的rdbms並不足以避免資料冗餘，必須在資料庫的設計中建立好的表結構。表設計後，很可能結構不合理，出現資料重複儲存，簡稱資料的冗餘，這對資料的增刪改查帶來很多後患，所以我們需要審核是否合理，就像施工圖設計後，還需要其他機構進行審核圖紙是否設計合理一樣。

• 如何審核呢？需要一些有關資料庫設計的理論指導規則，這些規則業界簡稱資料庫的正規化。dr e.f.codd 最初定義了規範化的三個級別，正規化是具有最小冗餘的表結構。這些正規化是：

– 第一正規化(1st nf －first normal fromate)

– 第二正規化(2nd nf－second normal fromate)

– 第三正規化(3rd nf－ third normal fromate)

• 如果每列都是不可再分的最小資料單元（也稱為最小的原子單元），則滿足第一正規化（1nf）。第一正規化的目標是確保每列的原子性。

• 如果乙個關係滿足1nf，並且除了主鍵以外的其他列，都依賴於該主鍵，則滿足第二正規化（2nf）。第二正規化要求每個表只描述一件事情，確保表中的每列，都和主鍵相關。

• 如果乙個關係滿足2nf，並且除了主鍵以外的其他列都不傳遞依賴於主鍵列，則滿足第三正規化（3nf）。第三正規化確保每列都和主鍵列直接相關，而不是間接相關。

下面我們來看個形象的例子吧！假設某建築公司要設計乙個資料庫。公司的業務規則概括說明如下：

• 公司承擔多個工程專案，每一項工程有：工程號、工程名稱、施工人員等

• 公司有多名職工，每一名職工有：職工號、姓名、性別、職務（工程師、技術員）等

• 公司按照工時和小時工資率支付工資，小時工資率由職工的職務決定（例如，技術員的小時工資率與工程師不同）

• 公司定期制定乙個工資報表，如圖

-1所示圖-

1某公司列印的工資報表

圖-2某公司的專案工時表 1

.表中包含大量的冗餘，可能會導致資料異常：

• 更新異常

例如，修改職工號

=1001的職務，則必須修改所有職工號=

1001的行

• 新增異常

若要增加乙個新的職工時，首先必須給這名職工分配乙個工程。或者為了新增一名新職工的資料，先給這名職工分配乙個虛擬的工程。（因為主關鍵字不能為空）

• 刪除異常

例如，1001號職工要辭職，則必須刪除所有職工號＝1001的資料行。這樣的刪除操作，很可能丟失了其它有用的資料

2．採用這種方法設計表的結構，雖然很容易產生工資報表，但是每當一名職工分配乙個工程時，都要重複輸入大量的資料。這種重複的輸入操作，很可能導致資料的不一致性。

我們用第二正規化規範一下：

我們再用第三正規化規範一下，是不是明晰了很多？！

規範化和效能的關係

• 為滿足某種商業目標，資料庫效能比規範化資料庫更重要

– 通過在給定的表中新增額外的字段，以大量減少需要從中搜尋資訊所需的時間

– 通過在給定的表中插入計算列（如成績總分），以方便查詢

• 進行規範化的同時，還需要綜合考慮資料庫的效能。資料庫的三大正規化和資料庫的效能有時是矛盾的。

打個比方：大家都知道，環境保護非常重要，西方總是拿環保問題和中國刁難，說中國為了發展不顧環境保護、生態自然等。可中國目前的經濟實力不夠強大，如果人都吃不飽，空談環保還有什麼用呢？所以我們只能是在保持地區經濟發展的前提下，盡量注重環保問題。這就是一種折中處理問題的典型。本例同樣如此：為了滿足三大正規化，我們在規範化**時就會拆分出越來越明細的**。但客戶喜歡綜合的資訊，為了滿足客戶，我們又需要把這些表通過連線查詢還原為客戶喜歡的綜合資料。這和從一張表中讀出資料相比，大大影響了資料庫的查詢效能。所以有時為了效能，需要做適當折中，適當犧牲規範化的要求，來提高資料庫的效能。再如：在成績表中新增一列－「成績總分」，屬於資料冗餘，因為總分在查詢時可由各門成績求出來。但頻繁查詢成績總分，並希望儲存下來，所以有時表中就乾脆新增總分這一列。

如何設計資料庫 2 ？（芮）

如何設計資料庫 2

如何設計資料庫

如何設計資料庫 1 ？

相關推薦