[轉]資料標準化

newknight發表於2013-12-30

資料標準化

資料庫設計人員的任務是以這樣一種方式構造資料,採用該方式可消除不必要的重複並提供到所有必要資訊的快速搜尋路徑。精煉表、鍵、列和關係以建立高效資料庫的過程稱為“標準化”。標準化並不只適用於關係檔案:它還是索引檔案的常見設計活動。

標準化是個複雜過程,具有許多特定規則和不同強度等級。就其完整定義而言,標準化是放棄重複組、最小化冗餘、消除部分依賴項的複合鍵以及分隔非鍵屬性的過程。簡言之,標準化規則可以總結為一句話:“每個屬性(列)必須是有關鍵、整個鍵且僅鍵的一個事實。”每個表應只描述一種實體型別(如人、地點、客戶訂單或產品項)。

標準化的一些好處是:

·         資料完整性(因為沒有冗餘、被忽視的資料)。

·         優化的查詢(因為標準化的表生成快速、有效的聯接)。

·         更快的索引建立和排序(因為表中列較少)。

·         更快的 UPDATE 效能(因為每個表的索引更少)。

·         改善的併發解析(因為表鎖影響的資料少了)。

可以通過遵守以下簡單經驗法則來標準化大多數簡單資料庫:包含重複資訊的表應劃分為單獨的表以消除重複。

例如,您的新應用程式是供某書商使用的,他必須跟蹤每本書的相關資訊,包括下列資料。

·         作者姓名。

·         作者地址。

·         作者電話。

·         書名。

·         ISBN(國際標準書號)。

·         出版年代。

·         出版商名稱。

·         出版商地址。

·         出版商電話。

可以只建立一個表,對於所列出的每個資料項均有一個欄位。但仔細檢視這些資料,很明顯這樣的表包含很多冗餘。例如,許多作者寫了不止一本書,因此對於每個書名,作者和出版商資訊將重複很多次。如果將所有這些欄位均放入一個表,將會有許多容易引起混亂和重複的項。

使用標準化的原則,您可將資料劃分為四個組:“作者”(Authors)、“作者書名”(AuthorsTitles)、“書名”(Titles) 和“出版商”(Publishers),如下表所示。

Authors

AuthorsTitles

Titles

Publishers

au_id(鍵)

au_id(外來鍵)

ti_isbn(鍵)

pu_id(鍵)

au_name

ti_isbn(外來鍵)

ti_title

pu_name

au_address

ti_yearpublished

pu_address

au_phone

pu_id(外來鍵)

pu_phone


鍵提供一種建立表關係的方法。例如,
AuthorsTitles 表建立 Authors Titles 表之間的多對多關係(一個作者可能寫很多書,而一本書可能由多個作者撰寫)。使用 AuthorsTitles 表,您可以查詢一個作者寫的每個書號(使用 au_id),還可以確定哪個(哪些)作者寫了某本書(使用 ti_isbn)。

值得注意的是,不用建立 AuthorsTitles 表,另一種可能的方法是向 Titles 表新增 au_id 屬性,但該選項僅當假定每本書只有一個作者時才可行。進一步考慮另一個假設:將 pu_id 屬性放入 Titles 表假設每本書由一個出版商出版。如果同一本書由多個公司出版,那麼為每個單獨的出版商向 Titles 表插入附加的 Title 行將使資料重複,導致該表不是標準化的表。此類設計備選項要求仔細評估這些內容:業務資料的含義,應用程式預期的查詢型別,可能的多使用者併發問題,以及一個表上有很多索引而可能產生的效能問題。

評估標準化設計備選項時,需要了解還有各種技術可以用來特意使資料庫非標準化。為什麼要這樣做呢?您會因為發現效能問題或希望簡化特殊報告而特意使資料非標準化。效能問題源自這樣一類生產查詢,這些查詢需要太多耗時且大量使用磁碟的表聯接。特殊報告是關於允許終端使用者執行非結構化查詢;未經訓練的終端使用者可能不清楚如何從多個相關表獲取資訊。

非標準化技術包括複製資料,提供摘要資料,將表拆分為水平或垂直分割槽以及建立非標準化檢視來簡化報告(這是一種聰明的選擇,可原封不動地保留標準化的資料庫)。

作為非標準化的一個示例,請考慮客戶地址的情況。客戶表通常會包含以下屬性:姓名、街道、城市、省/州和郵政編碼。雖然城市和省/州可以直接從郵政編碼確定,因而可以通過從每個客戶的資料中移除城市和省/州來標準化客戶表,但通常的做法是保留地址非標準化。

使地址非標準化的原因有以下幾個:

·         地址用在很多地方(查詢、報表、信封、客戶支援螢幕),非標準化可避免應用程式中到處新增大量的地址重建程式碼。

·         基於地址的查詢使用的 SQL 語法簡單得多。

·         地址錯誤限制到單個客戶。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10009036/viewspace-1065519/,如需轉載,請註明出處,否則將追究法律責任。

相關文章