luke chung
fms 總裁
2023年9月
適用於：
microsoft® access
摘要：本文為開發人員提供了一些技巧，使用這些技巧可以在設計 access 表時避免某些問題。本文適用於 microsoft access 資料庫 (.mdb) 和 microsoft access 專案 (.adp)。
目錄
在設計資料庫時，最重要的步驟是要確保資料正確分布到資料庫的表中。使用正確的資料結構，可以極大地簡化應用程式的其他內容（查詢、窗體、報表、**等）。正確進行表設計的正式名稱是「資料庫規範化」。
本文簡要介紹資料庫規範化的基本概念和一些需要注意並力求避免的常見問題。
在設計表之前，應明確您打算如何處理資料，還要了解隨著時間的推移資料會發生什麼樣的變化。您所做的假設將會影響最終的設計。
設計應用程式時，關鍵要了解設計的最終結果，以便確保您準備好所有必需的資料並知道其**。例如，報表的外觀、每個資料的**以及所需的所有資料是否都存在。對專案損失最大的莫過於在專案後期發現重要報表缺少資料。
知道需要什麼樣的資料後，就必須確定資料的**。資料是否從其他資料來源中匯入？資料是否需要清理或驗證？使用者是否需要輸入資料？
明確所需資料的型別和**是資料庫設計的第一步。
使用者是否需要編輯這些資料？如果需要，應如何顯示資料以便於使用者理解和編輯？有沒有驗證規則和相關的查詢表？要求對編輯和刪除保留備份的資料輸入有沒有相關聯的審核問題？需要為使用者顯示哪些摘要資訊？是否需要生成匯出檔案？了解這些資訊後，就可以想象字段之間是如何相互關聯的了。
將資料分組放入相關字段（例如與客戶相關的資訊、與發票相關的資訊等），每個欄位組都代表要建立的表。然後考慮如何將這些表相互關聯。例如，哪些表具有一對多關係（例如，乙個客戶可能持有多張發票）？哪些表具有一對一關係（這種情況下，通常會考慮將其組合到乙個表中）？
設計表之後，常常會由於沒有考慮時間的影響而導致以後出現嚴重問題。許多表設計在當時使用時效果非常好，但是，常常會因為使用者修改資料、新增資料以及隨時間的推移而崩潰。開發人員經常會發現需要重新設計表的結構來適應這些變化。表的結構發生變化時，所有相關的內容（查詢、窗體、報表、**等）也必須隨之更新。理解並**資料會隨時間推移發生哪些變化，可以實現更好的設計，減少問題的發生。
了解如何分析和管理資料同樣很重要。您應該深刻理解查詢的工作原理，理解如何使用查詢在多個表之間鏈結資料，如何使用查詢對資料進行分組和彙總，以及如何在不需要以規範化格式顯示資料時使用交叉表查詢。
好的資料設計的最終目標就是要平衡兩個需要：既要隨著時間的推移有效地儲存資料，又要輕鬆地檢索和分析資料。理解查詢的功能對正確設計表很有幫助。
這部分介紹資料庫規範化所涉及的基本概念，而不是對資料庫規範化進行理論性的**。如何在您的實際情況中應用這些概念可能會隨著應用程式需要的不同而有所變化。這部分的目的是理解這些基本概念、根據實際需要應用它們，並理解偏離這些概念將會出現哪些問題。
大部分資料庫開發人員都理解資料庫規範化的基本概念。理想情況下，您希望將相同的資料儲存在同乙個地方，並在需要引用時使用 id 來進行引用。因此，如果某些資訊發生了變化，則可以在乙個地方進行更改，而整個程式中的相應資訊也會隨之更改。
例如，客戶表會儲存每個客戶的記錄，包括姓名、位址、**號碼、電子郵件位址以及其他特徵資訊。客戶表中可能包含唯一的 customerid 字段（通常是autonumber字段），這個欄位即該錶的主鍵字段，其他表使用它來引用該客戶。因此，發票表可以只引用客戶的 id 值，而不是在每張發票中儲存客戶的所有資訊（因為同乙個客戶可能會持有多張發票），這樣利用客戶的 id 值即可從客戶表中查詢客戶的詳細資訊。使用 access 中功能強大的窗體（使用組合框和子窗體），可以輕鬆地完成這項工作。如果需要修改客戶資訊（例如新增**號碼），只需在客戶表中修改，應用程式中引用該資訊的任何其他部分都會隨之自動更新。
使用正確規範化的資料庫，通過簡單的編輯即可輕鬆處理資料隨時間推移而發生的更改。使用未正確規範化的資料庫，通常需要利用程式設計或查詢來更改多條記錄或多個表。這不僅會增加工作量，還會增加由於未正確執行**或查詢而導致資料不一致的可能性。
理想的資料庫應該只需要隨著時間的推移新增新的記錄，資料庫表應該能夠儲存大量記錄。但是，如果您發現需要增加更多字段，則可能會碰到設計問題。
電子**專家經常會遇到上述問題，因為他們習慣於按照設計電子**的方式設計資料庫。設計經常隨時間變化的字段（例如，年、季度、產品和銷售人員）需要在將來新增新字段。而正確的設計應該是轉換資訊並將隨時間變化的資料放在乙個欄位內，這樣就可以新增更多記錄。例如，只需建立「年」字段，然後在該字段中輸入各記錄相應的年份值即可，無需為每年建立乙個單獨的字段。
增加額外的字段可能會產生問題，因為表結構的變化會對應用程式的其他部分產生影響。在表中新增更多字段時，依賴該錶的物件和**也需要更新。例如，查詢需要獲取額外的字段，窗體需要顯示這些字段，而報表則需要包含這些字段，等等。但是，如果資料已經規範化，則現有物件會自動檢索新資料，並正確計算或顯示這些資料。查詢功能尤其強大，因為它允許您按「年」字段進行分組，以逐年顯示摘要（不管表中包含哪些年份）。
但是，資料規範化並不意味著不能顯示或使用隨時間而變化或依賴時間的字段。需要瀏覽或顯示這類資訊的開發人員通常可以使用交叉表查詢來達到這一目的。如果您不熟悉交叉表查詢，應該學習如何使用它們。雖然它們與表有所不同（尤其是使用者無法編輯交叉表查詢的結果），但它們的確可以用於在資料表中顯示資訊（最多可以達到 255 個字段）。如果要在報表中使用它們，則會更加複雜，因為報表需要包含額外的或不斷變化的欄位名。這就是為什麼大多數報表將資料作為獨立的分組（而不是獨立的列）顯示的原因。對於那些別無選擇的情況，您必須花時間去解決這個問題。希望所有人都能夠理解這種決定會隨著時間的變化對其他資源產生的影響。
這就是為什麼增加記錄是免費的（這是資料庫的巨大優勢）而增加欄位是如此昂貴的原因。如果資料庫設計正確，則可以適應各種各樣的變化。
有時資料需要反規範化，以便儲存可能會隨時間變化的資訊。
在通過客戶 id 號將發票鏈結到客戶表的簡單示例中，我們可能需要保留開出發票時的客戶位址（而不是製作發票時的位址，因為客戶資訊在這兩個事件之間可能會有所變化）。如果開出發票時未保留客戶位址，而將來又必須更新客戶資訊，則可能無法確定傳送某些發票的確切位址。這可能會導致非常嚴重的商業問題。當然，有些資訊（如客戶的**號碼）可以不儲存。因此，應該有選擇地決定需要複製哪些資料。
需要複製資料的另乙個例子是填寫發票的明細項。**單通常用於挑選客戶訂購的商品。我們可以只儲存**單 id，而 id 指向包含產品說明、**和其他詳細資訊的**單。但是，產品說明和**會隨著時間而改變。如果不將資料從**單複製到明細表中，將來則無法準確地重新列印原始發票。如果您尚未收到付款，問題將非常嚴重。
因此，雖然規範化可以將相同的資料很好地儲存在乙個地方並能簡化編輯工作，但某些情況下卻不需要這些優勢。如果以後由於歷史原因需要資料的快照，則必須從一開始就在資料庫中設計好。否則，一旦資料被覆蓋就無法再找回。
為了提高效率，每個表都應該有乙個主鍵字段。主鍵字段定義了在表中的唯一性，並由索引在其他欄位中使用，以提高搜尋效能。例如，客戶表可以包含為每個客戶定義唯一編號的 customerid 字段。為了便於討論，假定表中包含多個字段，而不僅僅是簡單的單一表查詢（例如國家/地區列表）。
一般來說，主鍵欄位應具有如下特徵：
鑑於上述原因，我們建議在大部分表中使用autonumber字段作為主鍵字段。通過使用組合框和隱藏列，可以將字段繫結到autonumber欄位並將其隱藏，使使用者無法看到。
對錶進行定義並理解各表是如何關聯的之後，請確保新增引用完整性來鞏固各表之間的關係。這樣可以避免錯誤地修改鏈結欄位而留下孤立的記錄。microsoft jet 資料庫引擎支援複雜的引用完整性，允許使用者進行級聯更新和刪除。一般情況下，不應修改 id 字段。因此，級聯更新用得較少，但級聯刪除卻非常有用。
例如，如果發票表與訂單表相關聯，其中的一張發票可能有無限多個訂單（明細項），並且每個訂單記錄包含它所鏈結的發票編號，則可以使用級聯刪除操作來刪除發票記錄，並自動刪除所有相應的訂單記錄。這樣可以避免出現沒有相應發票記錄的訂單記錄。
資料庫規範化
規範化 normalization 是資料庫系統設計中非常重要的乙個技術。資料庫規範化能夠讓資料庫設計者更好地了解組織內部當前的資料結構，最終得到一系列的資料實體。資料庫規範化通過對資料庫表的設計，可以有效降低資料庫冗餘程度。在進行資料庫規範化的時候，我們有一系列的步驟需要遵循。我們把這些步驟稱作正...
資料庫規範化大全
er圖是一種關聯式資料庫邏輯設計的一種方法。normalization 正規化 是另一種 關係型資料庫的邏輯設計的方法。normal forms 正規化 1nf 2nf 3nf bcnf 4nf 5nf 1.不好的資料庫會出現的問題 a.修改異常 anomaly b.刪除異常 c.插入異常 d.資料...
資料庫規範化（二）
資料庫的設計正規化是資料庫設計所需要滿足的規範，滿足這些規範的資料庫是簡潔的 結構明晰的，同時，不會發生插入 insert 刪除 delete 和更新 update 操作異常。反之則是亂七八糟，不僅給資料庫的程式設計人員製造麻煩，而且面目可憎，可能儲存了大量不需要的冗餘資訊。正規化說明 1.1 第一...