資料庫正常化技巧(MS)

來源:互聯網
上載者:User
規範|正常化|技巧|資料|資料庫 資料庫正常化技巧

Luke Chung
FMS 總裁
2002年9月
適用於:

   Microsoft® Access

摘要:本文為開發人員提供了一些技巧,使用這些技巧可以在設計 Access 表時避免某些問題。本文適用於 Microsoft Access 資料庫 (.mdb) 和 Microsoft Access 項目 (.adp)。

目錄

簡介
理解您的資料
您需要什麼樣的資料?
您打算如何處理這些資料?
資料之間如何相互關聯?
隨著時間的推移資料會發生什麼樣的變化?
學習如何使用查詢
資料庫正常化概念
將唯一資訊儲存在一個地方
記錄是免費的,而新欄位非常昂貴
瞭解何時需要複製資料
使用沒有確切含義的欄位作為主鍵欄位
使用參考完整性
小結

簡介
在設計資料庫時,最重要的步驟是要確保資料正確分布到資料庫的表中。使用正確的資料結構,可以極大地簡化應用程式的其他內容(查詢、表單、報表、代碼等)。正確進行表設計的正式名稱是“資料庫正常化”。

本文簡要介紹資料庫正常化的基本概念和一些需要注意并力求避免的常見問題。

理解您的資料
在設計表之前,應明確您打算如何處理資料,還要瞭解隨著時間的推移資料會發生什麼樣的變化。您所做的假設將會影響最終的設計。

您需要什麼樣的資料?
設計應用程式時,關鍵要瞭解設計的最終結果,以便確保您準備好所有必需的資料並知道其來源。例如,報表的外觀、每個資料的來源以及所需的所有資料是否都存在。對項目損失最大的莫過於在項目後期發現重要報表缺少資料。

知道需要什麼樣的資料後,就必須確定資料的來源。資料是否從其他資料來源中匯入?資料是否需要清理或驗證?使用者是否需要輸入資料?

明確所需資料的類型和來源是資料庫設計的第一步。

您打算如何處理這些資料?
使用者是否需要編輯這些資料?如果需要,應如何顯示資料以便於使用者理解和編輯?有沒有驗證規則和相關的尋找表?要求對編輯和刪除保留備份的資料輸入有沒有相關聯的審核問題?需要為使用者顯示哪些摘要資訊?是否需要產生匯出檔案?瞭解這些資訊後,就可以想象欄位之間是如何相互關聯的了。

資料之間如何相互關聯?
將資料分組放入相關欄位(例如與客戶相關的資訊、與發票相關的資訊等),每個欄位組都代表要建立的表。然後考慮如何將這些表相互關聯。例如,哪些表具有一對多關聯性(例如,一個客戶可能持有多張發票)?哪些表具有一對一關聯性(這種情況下,通常會考慮將其組合到一個表中)?

隨著時間的推移資料會發生什麼樣的變化?
設計表之後,常常會由於沒有考慮時間的影響而導致以後出現嚴重問題。許多表設計在當時使用時效果非常好,但是,常常會因為使用者修改資料、添加資料以及隨時間的推移而崩潰。開發人員經常會發現需要重新設計表的結構來適應這些變化。表的結構發生變化時,所有相關的內容(查詢、表單、報表、代碼等)也必須隨之更新。理解並預測資料會隨時間推移發生哪些變化,可以實現更好的設計,減少問題的發生。

學習如何使用查詢
瞭解如何分析和管理資料同樣很重要。您應該深刻理解查詢的工作原理,理解如何使用查詢在多個表之間連結資料,如何使用查詢對資料進行分組和匯總,以及如何在不需要以正常化格式顯示資料時使用交叉資料表查詢。

好的資料設計的最終目標就是要平衡兩個需要:既要隨著時間的推移有效地儲存資料,又要輕鬆地檢索和分析資料。理解查詢的功能對正確設計表很有協助。

資料庫正常化概念
這部分介紹資料庫正常化所涉及的基本概念,而不是對資料庫正常化進行理論性的探討。如何在您的實際情況中應用這些概念可能會隨著應用程式需要的不同而有所變化。這部分的目的是理解這些基本概念、根據實際需要應用它們,並理解偏離這些概念將會出現哪些問題。

將唯一資訊儲存在一個地方
大部分資料庫開發人員都理解資料庫正常化的基本概念。理想情況下,您希望將相同的資料存放區在同一個地方,並在需要引用時使用 ID 來進行引用。因此,如果某些資訊發生了變化,則可以在一個地方變更,而整個程式中的相應資訊也會隨之更改。

例如,客戶表會儲存每個客戶的記錄,包括姓名、地址、電話號碼、電子郵件地址以及其他特徵資訊。客戶表中可能包含唯一的 CustomerID 欄位(通常是 Autonumber 欄位),這個欄位即該表的主鍵欄位,其他表使用它來引用該客戶。因此,發票表可以只引用客戶的 ID 值,而不是在每張發票中儲存客戶的所有資訊(因為同一個客戶可能會持有多張發票),這樣利用客戶的 ID 值即可從客戶表中尋找客戶的詳細資料。使用 Access 中功能強大的表單(使用組合框和子表單),可以輕鬆地完成這項工作。如果需要修改客戶資訊(例如新增電話號碼),只需在客戶表中修改,應用程式中引用該資訊的任何其他部分都會隨之自動更新。

使用正確正常化的資料庫,通過簡單的編輯即可輕鬆處理資料隨時間推移而發生的更改。使用未正確正常化的資料庫,通常需要利用編程或查詢來更改多條記錄或多個表。這不僅會增加工作量,還會增加由於未正確執行代碼或查詢而導致資料不一致的可能性。

記錄是免費的,而新欄位非常昂貴
理想的資料庫應該只需要隨著時間的推移添加新的記錄,資料庫表應該能夠儲存大量記錄。但是,如果您發現需要增加更多欄位,則可能會碰到設計問題。

試算表專家經常會遇到上述問題,因為他們習慣於按照設計試算表的方式設計資料庫。設計經常隨時間變化的欄位(例如,年、季度、產品和銷售人員)需要在將來添加新欄位。而正確的設計應該是轉換資訊並將隨時間變化的資料放在一個欄位內,這樣就可以添加更多記錄。例如,只需建立“年”欄位,然後在該欄位中輸入各記錄相應的年份值即可,無需為每年建立一個單獨的欄位。

增加額外的欄位可能會產生問題,因為表結構的變化會對應用程式的其他部分產生影響。在表中添加更多欄位時,依賴該表的對象和代碼也需要更新。例如,查詢需要擷取額外的欄位,表單需要顯示這些欄位,而報表則需要包含這些欄位,等等。但是,如果資料已經正常化,則現有對象會自動檢索新資料,並正確計算或顯示這些資料。查詢功能尤其強大,因為它允許您按“年”欄位進行分組,以逐年顯示摘要(不管表中包含哪些年份)。

但是,資料正常化並不意味著不能顯示或使用隨時間而變化或依賴時間的欄位。需要瀏覽或顯示這類資訊的開發人員通常可以使用交叉資料表查詢來達到這一目的。如果您不熟悉交叉資料表查詢,應該學習如何使用它們。雖然它們與表有所不同(尤其是使用者無法編輯交叉資料表查詢的結果),但它們的確可以用於在資料表中顯示資訊(最多可以達到 255 個欄位)。如果要在報表中使用它們,則會更加複雜,因為報表需要包含額外的或不斷變化的欄位名。這就是為什麼大多數報表將資料作為獨立的分組(而不是獨立的列)顯示的原因。對於那些別無選擇的情況,您必須花時間去解決這個問題。希望所有人都能夠理解這種決定會隨著時間的變化對其他資源產生的影響。

這就是為什麼增加記錄是免費的(這是資料庫的巨大優勢)而增加欄位是如此昂貴的原因。如果資料庫設計正確,則可以適應各種各樣的變化。

瞭解何時需要複製資料
有時資料需要反正常化,以便儲存可能會隨時間變化的資訊。

在通過客戶 識別碼將發票連結到客戶表的簡單樣本中,我們可能需要保留開出發票時的客戶地址(而不是製作發票時的地址,因為客戶資訊在這兩個事件之間可能會有所變化)。如果開出發票時未保留客戶地址,而將來又必須更新客戶資訊,則可能無法確定發送某些發票的確切地址。這可能會導致非常嚴重的商業問題。當然,有些資訊(如客戶的電話號碼)可以不儲存。因此,應該有選擇地決定需要複製哪些資料。

需要複製資料的另一個例子是填寫發票的明細項。報價單通常用於挑選客戶訂購的商品。我們可以只儲存報價單 ID,而 ID 指向包含產品說明、價格和其他詳細資料的報價單。但是,產品說明和價格會隨著時間而改變。如果不將資料從報價單複製到明細表中,將來則無法準確地重新列印原始發票。如果您尚未收到付款,問題將非常嚴重。

因此,雖然正常化可以將相同的資料很好地儲存在一個地方並能簡化編輯工作,但某些情況下卻不需要這些優勢。如果以後由於曆史原因需要資料的快照,則必須從一開始就在資料庫中設計好。否則,一旦資料被覆蓋就無法再找回。

使用沒有確切含義的欄位作為主鍵欄位
為了提高效率,每個表都應該有一個主鍵欄位。主鍵欄位定義了在表中的唯一性,並由索引在其他欄位中使用,以提高搜尋效能。例如,客戶表可以包含為每個客戶定義唯一編號的 CustomerID 欄位。為了便於討論,假定表中包含多個欄位,而不僅僅是簡單的單一表尋找(例如省/地區列表)。

一般來說,主鍵欄位應具有如下特徵:

應該只包含一個欄位
可以將多個欄位定義為表的主鍵欄位,但最好是使用一個欄位。首先,如果需要使用多個欄位來定義唯一性,則需要佔用更多的空間來儲存主鍵。其次,表中的其他索引還必須使用主鍵欄位的組合,這樣所佔用的空間比使用一個欄位所佔用的空間要多。最後,在表中標識記錄需要擷取欄位組合。使用一個 CustomerID 欄位定義客戶比使用其他欄位組合要好得多。  
應該為數字類型
Access 提供的 AutoNumber 欄位類型是一個 Long Integer(長整數),非常適用於主鍵欄位。這些值可以自動保證每個記錄的唯一性,同時也支援多使用者資料輸入。  
不會隨時間而改變
主鍵欄位不應該隨時間而改變。一旦標識了主鍵欄位,就應該永遠不變(象社會保障號一樣)。更改過的主鍵欄位將很難再使用曆史資料,因為其中的連結被破壞了。  
應該沒有確切含義
要確保主鍵欄位不會隨時間而更改,它應該沒有確切含義。沒有確切含義的主索引值在其他資料不完整時也非常有用。例如,您可以指定一個客戶編碼,而無需該客戶的完整地址。應用程式的其餘部分可以很好地工作,您也可以在檢索記錄時添加資訊。如果表中使用了省/地區欄位或其他您沒有的識別欄位作為主鍵的一部分,則很可能會導致無法使用應用程式。
鑒於上述原因,我們建議在大部分表中使用 AutoNumber 欄位作為主鍵欄位。通過使用組合框和隱藏列,可以將欄位綁定到 AutoNumber 欄位並將其隱藏,使使用者無法看到。

使用參考完整性
對錶進行定義並理解各表是如何關聯的之後,請確保添加參考完整性來鞏固各表之間的關係。這樣可以避免錯誤地修改連結欄位而留下孤立的記錄。Microsoft Jet 資料庫引擎支援複雜的參考完整性,允許使用者進行串聯更新和刪除。一般情況下,不應修改 ID 欄位。因此,串聯更新用得較少,但串聯刪除卻非常有用。

例如,如果發票表與訂單表相關聯,其中的一張發票可能有無限多個訂單(明細項),並且每個訂單記錄包含它所連結的發票編號,則可以使用串聯刪除操作來刪除發票記錄,並自動刪除所有相應的訂單記錄。這樣可以避免出現沒有相應發票記錄的訂單記錄。

小結
我們希望您能儘快將這些資料庫設計概念應用到您的應用程式設計中,從而最大程度地減少問題,減少未實現此類設計時需要進行的修正。祝您好運。

Luke Chung 是 FMS Inc. 的創始人兼總裁。FMS Inc. 是業界領先的第三方產品供應商,其產品適用於 Microsoft Access 使用者和開發人員。


相關文章

E-Commerce Solutions

Leverage the same tools powering the Alibaba Ecosystem

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。