新手來看:如何設計數據庫結構
有一定啟發的，前面几段就不用看了，重點在後面。

本文為開發人員提供了一些技巧，使用這些技巧可以在設計 Access 表時避免某些問題。本文适用于 Microsoft Access 數據庫 (.mdb) 和 Microsoft Access 項目 (.adp)。 

　　簡介

　　在設計數據庫時，最重要的步驟是要确保數據正确分布到數據庫的表中。使用正确的數據結構，可以極大地簡化應用程序的其他內容（查詢、窗体、報表、代碼等）。正确進行表設計的正式名稱是“數據庫規范化”。

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

　　理解您的數據 
　　在設計表之前，應明确您打算如何處理數據，還要了解隨著時間的推移數據會發生什么樣的變化。您所做的假設將會影響最終的設計。

　　您需要什么樣的數據？ 
　　設計應用程序時，關鍵要了解設計的最終結果，以便确保您準備好所有必需的數據并知道其來源。例如，報表的外觀、每個數據的來源以及所需的所有數據是否都存在。對項目損失最大的莫過于在項目後期發現重要報表缺少數據。

　　知道需要什么樣的數據後，就必須确定數據的來源。數據是否從其他數據源中導入？數據是否需要清理或驗証？用戶是否需要輸入數據？

　　明确所需數據的類型和來源是數據庫設計的第一步。

　　您打算如何處理這些數據？ 
　　用戶是否需要編輯這些數據？如果需要，應如何顯示數據以便于用戶理解和編輯？有沒有驗証規則和相關的查找表？要求對編輯和刪除保留備份的數據輸入有沒有相關聯的審核問題？需要為用戶顯示哪些摘要信息？是否需要生成導出文件？了解這些信息後，就可以想象字段之間是如何相互關聯的了。

　　數據之間如何相互關聯？ 
　　將數據分組放入相關字段（例如与客戶相關的信息、与發票相關的信息等），每個字段組都代表要建立的表。然後考慮如何將這些表相互關聯。例如，哪些表具有一對多關系（例如，一個客戶可能持有多張發票）？哪些表具有一對一關系（這种情況下，通常會考慮將其組合到一個表中）？

　　隨著時間的推移數據會發生什么樣的變化？ 
　　設計表之後，常常會由于沒有考慮時間的影響而導致以後出現嚴重問題。許多表設計在當時使用時效果非常好，但是，常常會因為用戶修改數據、添加數據以及隨時間的推移而崩潰。開發人員經常會發現需要重新設計表的結構來适應這些變化。表的結構發生變化時，所有相關的內容（查詢、窗体、報表、代碼等）也必須隨之更新。理解并預測數據會隨時間推移發生哪些變化，可以實現更好的設計，減少問題的發生。

　　學習如何使用查詢 
　　了解如何分析和管理數據同樣很重要。您應該深刻理解查詢的工作原理，理解如何使用查詢在多個表之間鏈接數據，如何使用查詢對數據進行分組和匯總，以及如何在不需要以規范化格式顯示數據時使用交叉表查詢。

　　好的數據設計的最終目標就是要平衡兩個需要︰既要隨著時間的推移有效地存儲數據，又要輕松地檢索和分析數據。理解查詢的功能對正确設計表很有幫助。

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

　　將唯一信息存儲在一個地方 
　　大部分數據庫開發人員都理解數據庫規范化的基本概念。理想情況下，您希望將相同的數據存儲在同一個地方，并在需要引用時使用 ID 來進行引用。因此，如果某些信息發生了變化，則可以在一個地方進行更改，而整個程序中的相應信息也會隨之更改。

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

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

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

　　電子表格專家經常會遇到上述問題，因為他們習慣于按照設計電子表格的方式設計數據庫。設計經常隨時間變化的字段（例如，年、季度、產品和銷售人員）需要在將來添加新字段。而正确的設計應該是轉換信息并將隨時間變化的數據放在一個字段內，這樣就可以添加更多記錄。例如，只需創建“年”字段，然後在該字段中輸入各記錄相應的年份值即可，無需為每年創建一個單獨的字段。

　　增加額外的字段可能會產生問題，因為表結構的變化會對應用程序的其他部分產生影響。在表中添加更多字段時，依賴該表的對象和代碼也需要更新。例如，查詢需要獲取額外的字段，窗体需要顯示這些字段，而報表則需要包含這些字段，等等。但是，如果數據已經規范化，則現有對象會自動檢索新數據，并正确計算或顯示這些數據。查詢功能尤其強大，因為它允許您按“年”字段進行分組，以逐年顯示摘要（不管表中包含哪些年份）。

　　但是，數據規范化并不意味著不能顯示或使用隨時間而變化或依賴時間的字段。需要瀏覽或顯示這類信息的開發人員通常可以使用交叉表查詢來達到這一目的。如果您不熟悉交叉表查詢，應該學習如何使用它們。雖然它們与表有所不同（尤其是用戶無法編輯交叉表查詢的結果），但它們的确可以用于在數據表中顯示信息（最多可以達到 255 個字段）。如果要在報表中使用它們，則會更加复雜，因為報表需要包含額外的或不斷變化的字段名。這就是為什么大多數報表將數據作為獨立的分組（而不是獨立的列）顯示的原因。對于那些別無選擇的情況，您必須花時間去解決這個問題。希望所有人都能夠理解這种決定會隨著時間的變化對其他資源產生的影響。

　　這就是為什么增加記錄是免費的（這是數據庫的巨大優勢）而增加字段是如此昂貴的原因。如果數據庫設計正确，則可以适應各种各樣的變化。

　　了解何時需要复制數據 
　　有時數據需要反規范化，以便保存可能會隨時間變化的信息。

　　在通過客戶 ID 號將發票鏈接到客戶表的簡單示例中，我們可能需要保留開出發票時的客戶地址（而不是制作發票時的地址，因為客戶信息在這兩個事件之間可能會有所變化）。如果開出發票時未保留客戶地址，而將來又必須更新客戶信息，則可能無法确定發送某些發票的确切地址。這可能會導致非常嚴重的商業問題。當然，有些信息（如客戶的電話號碼）可以不保存。因此，應該有選擇地決定需要复制哪些數據。

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

　　因此，雖然規范化可以將相同的數據很好地保存在一個地方并能簡化編輯工作，但某些情況下卻不需要這些優勢。如果以後由于歷史原因需要數據的快照，則必須從一開始就在數據庫中設計好。否則，一旦數據被覆蓋就無法再找回。

　　使用沒有确切含義的字段作為主鍵字段 
　　為了提高效率，每個表都應該有一個主鍵字段。主鍵字段定義了在表中的唯一性，并由索引在其他字段中使用，以提高搜索性能。例如，客戶表可以包含為每個客戶定義唯一編號的 CustomerID 字段。為了便于討論，假定表中包含多個字段，而不僅僅是簡單的單一表查找（例如國家/地區列表）。

　　一般來說，主鍵字段應具有如下特征︰ 

應該只包含一個字段
可以將多個字段定義為表的主鍵字段，但最好是使用一個字段。首先，如果需要使用多個字段來定義唯一性，則需要占用更多的空間來存儲主鍵。其次，表中的其他索引還必須使用主鍵字段的組合，這樣所占用的空間比使用一個字段所占用的空間要多。最後，在表中標識記錄需要獲取字段組合。使用一個 CustomerID 字段定義客戶比使用其他字段組合要好得多。  
應該為數字類型
Access 提供的 AutoNumber 字段類型是一個 Long Integer（長整數），非常适用于主鍵字段。這些值可以自動保証每個記錄的唯一性，同時也支持多用戶數據輸入。  
不會隨時間而改變
主鍵字段不應該隨時間而改變。一旦標識了主鍵字段，就應該永遠不變（象社會保障號一樣）。更改過的主鍵字段將很難再使用歷史數據，因為其中的鏈接被破壞了。  
應該沒有确切含義
要确保主鍵字段不會隨時間而更改，它應該沒有确切含義。沒有确切含義的主鍵值在其他數據不完整時也非常有用。例如，您可以指定一個客戶編號，而無需該客戶的完整地址。應用程序的其余部分可以很好地工作，您也可以在檢索記錄時添加信息。如果表中使用了國家/地區字段或其他您沒有的標識字段作為主鍵的一部分，則很可能會導致無法使用應用程序。 
　　鑒于上述原因，我們建議在大部分表中使用 AutoNumber 字段作為主鍵字段。通過使用組合框和隱藏列，可以將字段綁定到 AutoNumber 字段并將其隱藏，使用戶無法看到。

　　使用引用完整性 
　　對表進行定義并理解各表是如何關聯的之後，請确保添加引用完整性來鞏固各表之間的關系。這樣可以避免錯誤地修改鏈接字段而留下孤立的記錄。Microsoft Jet 數據庫引擎支持复雜的引用完整性，允許用戶進行級聯更新和刪除。一般情況下，不應修改 ID 字段。因此，級聯更新用得較少，但級聯刪除卻非常有用。

　　例如，如果發票表与訂單表相關聯，其中的一張發票可能有無限多個訂單（明細項），并且每個訂單記錄包含它所鏈接的發票編號，則可以使用級聯刪除操作來刪除發票記錄，并自動刪除所有相應的訂單記錄。這樣可以避免出現沒有相應發票記錄的訂單記錄。

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