妥善設計的資料庫可讓您存取最新且正確的資訊。 正確的設計是達成有效運用資料庫之目標的重要關鍵，因此需要投注時間來了解良好的設計原則是非常合理的做法。 最後，您才極有可能得到符合您需求的資料庫，而且能夠輕鬆適應變化。
本文提供規劃桌面資料庫的指導方針。 您將了解如何決定所需的資訊、如何將該資訊分成適當的資料表和資料行，以及這些資料表如何彼此相互關聯。 建立第一個桌面資料庫之前，您應先閱讀本文。
本文內容
需要認識的一些資料庫詞彙
Access 將您的資訊整理為資料表：資料列與資料行的清單，使人聯想起會計師的帳簿或試算表。 在簡單的資料庫中，您可能只有一個資料表。 對於大部分的資料庫，您則需要多個資料表。 例如，您可能有一個儲存產品相關資訊的資料表，一個儲存訂單相關資訊的資料表，以及一個含有客戶相關資訊的資料表。
更確切地說，每個資料列都稱為「記錄」，而每個資料行則稱為「欄位」。 記錄是有意義且一致的方式，可結合某種相關資訊。 欄位是單一的資訊項目 (每筆記錄中顯示的項目類型)。 例如，在 [產品] 資料表中，每個資料列或每一筆記錄都保存與一個產品有關的資訊。 每個資料行或欄位都保存關於該產品的某些資訊類型，例如產品的名稱或價格。
什麼是良好的資料庫設計？
某些原則可引導您進行資料庫設計程序。 首要原則是，重複的資訊 (也稱為冗餘資料) 非常不妥，因為這會浪費空間且增加造成錯誤和不一致的可能性。 次要原則是，資訊的正確性和完整性至關重要。 如果資料庫包含不正確的資訊，從資料庫提取資訊的任何報表也會包含不正確的資訊。 所以，您根據這些報表所做出的任何決策就會受到誤導。
因此，以下是良好的資料庫設計原則：
-
將資訊分成主體型資料表以減少冗餘資料。
-
視需要提供 Access 所需資訊，將資料表中的資訊聯結在一起。
-
協助支援及確保資訊的正確性與完整性。
-
適應資料處理和報表需求。
設計程序
設計程序包含下列步驟：
-
決定資料庫的用途
這有助於讓您為其餘步驟做好準備。
-
尋找及整理所需的資訊
收集您可能要在資料庫中記錄的所有資訊類型，例如產品名稱與訂單號碼。
-
將資訊分成多個資料表
將資訊項目分成主要實體或主體，例如 [產品] 或 [訂單]。 每個主體就會變成資料表。
-
將資訊項目轉成資料行
決定您要在每個資料表中儲存哪些資訊。 每個項目都會變成欄位，而且在資料表中會顯示為資料行。 例如，[員工] 資料表可能包含 [姓氏] 和 [雇用日期] 等欄位。
-
指定主索引鍵
選擇每個資料表的主索引鍵。 主索引鍵是用來唯一識別每個資料列的資料行。 可能的範例為 [產品識別碼] 或 [訂單識別碼]。
-
設定資料表關聯性
查看每個資料表，並且決定一個資料表中的資料如何與其他資料表中的資料關聯。 視需要將欄位新增到資料表或建立新資料表以釐清關聯性。
-
讓您的設計更完善
分析設計中的錯誤。 建立資料表並新增幾筆範例資料的記錄。 看看是否能夠從資料表獲得您想要的結果。 視需要調整設計。
-
套用正規化規則
套用資料正規化規則，確認資料表的結構是否正確。 視需要調整資料表。
決定資料庫的用途
建議您在紙張上寫下資料庫的用途，包括其目的、預期的使用方式，以及使用資料庫的人員。 例如，針對家庭型商務所用的小型資料庫，您可以撰寫簡單的內容，像是「客戶資料庫保存客戶資訊清單，用於產生郵件和報表的用途」。 如果資料庫較為複雜或是有許多人使用 (通常發生在企業環境中)，用途可以是一個簡單的段落或更多內容說明，而且應包含每個人使用資料庫的時機和方法。 重點是建立完善的任務聲明，這樣就能在設計程序中隨時參考。 建立此聲明可協助您在做出決策時專注於目標上。
尋找及整理所需資訊
若要尋找及整理所需資訊，請從現有的資訊開始著手。 例如，您可能會將訂購單記錄在總帳中，或者將客戶資訊以書面表單的形式放在檔案櫃中。 收集這些文件並列出每種顯示資訊的類型 (例如，在表單上填寫的每個方塊)。 如果您沒有任何現有表單，請試想您必須設計表單來記錄客戶資訊。 您想要在表單上放入哪些資訊？ 您想要建立哪些填寫方塊？ 識別並列出每個項目。 例如，假設您目前將客戶清單保存在索引卡上。 檢查這些卡片顯示的每張卡片上，是否都保存了客戶名稱、地址、市/鎮、縣/市、郵遞區號和電話號碼。 這些項目每個都代表資料表中的潛在資料行。
準備這份清單時，不用擔心第一次製作是否不夠完美。 而是列出您想到的每個項目。 如果有其他人要使用資料庫，也請徵詢他們的想法。 您可以稍後再微調清單。
接下來，考慮您可能想要從資料庫產生的報表或郵件類型。 例如，您可能想要依地區顯示銷售量的產品銷售報表，或顯示產品庫存量的庫存摘要報表。 您可能也想要產生可傳送給客戶的套印信件，以宣佈銷售活動或提供優惠方案。 在您的腦海中設計報表，想像報表的樣子。 您想要在報表上放入哪些資訊？ 列出每個項目。 對套印信件以及您預期建立的任何其他報表採取同樣的做法。
思考您可能想要建立的報表和郵件，可協助您識別資料庫中需要的項目。 例如，假設您提供客戶可選擇加入 (或退出) 定期電子郵件更新的機會，而您想要列印那些已加入者的清單。 若要記錄該資訊，則需將 [傳送電子郵件] 資料行新增到客戶資料表。 對於每個客戶，您可以將欄位設為 [是] 或 [否]。
這項傳送電子郵件訊息給客戶的需求，表示要記錄的另一個項目。 一旦您知道客戶想要接收電子郵件訊息後，您也需要知道要傳送到哪個電子郵件地址。 因此，您必須記錄每個客戶的電子郵件地址。
建構每個報表或輸出清單的原型，並考慮產生報表所需的專案是很有意義的。 例如，當您檢查表單字母時，可能會想到一些事項。 如果您想要包含適當的問候語，例如「Mr」、「女士」或「Ms」字串，以開始問候語，您必須建立問候項。 此外，您通常可能會以「親愛的 Smith 先生」而不是「親愛的先生」來寫一封信。 Sylvester Smith 先生」。 這表示您通常會想要將姓氏與名字分開儲存。
務必記得的重點是，您應將每筆資訊細分成可用資訊的最小部分。 就姓名的情況來說，若要備妥姓氏以供使用，則需將姓名分成兩個部分 ([名字] 和 [姓氏])。 例如，若要依姓氏排序報表，將客戶的姓氏分開儲存則會有所幫助。 一般而言，若要根據資訊項目排序、搜尋、計算或報告，您應該將該項目放在自己的個別欄位中。
思考您可能希望資料庫回答的問題。 例如，特色產品上個月達到多少銷售量？ 您 最適合客戶 的居住地為何？ 最暢銷產品的供應商是誰？ 預測這些問題可協助您將注意力集中於要記錄的額外項目上。
收集此資訊後，就可以進行下一步了。
將資訊分成多個資料表
若要將資訊分成多個資料表，請選擇主要實體或主體。 例如，尋找及整理產品銷售資料庫的資訊後，初步清單看起來可能像這樣：
此處顯示的主要實體為產品、供應商、客戶和訂單。 因此，從這四個資料表開始進行是很合理的做法：一個用於產品相關事實、一個用於供應商相關事實、一個用於客戶相關事實，以及一個用於訂單相關事實。 雖然這樣的清單還不完整，但是個好的起點。 您可以繼續讓這份清單更完善，直到獲得您適用的設計為止。
當您第一次檢閱項目的初步清單時，您可能會想將它們全部放在單一資料表中，而不是上圖顯示的四個資料表中。 此處將說明為何這是個不明智的構想。 思考一下以下所示的資料表：
在此案例中，每個資料列都包含產品與其供應商的相關資訊。 因為您會有許多來自同一個供應商的產品，供應商名稱與地址資訊必須重複許多次。 這會浪費磁碟空間。 請將供應商資訊只記錄在個別的 [供應商] 資料表中一次，然後將該資料表連結到 [產品] 資料表，這會是比較好的解決方案。
當您需要修改供應商相關資訊時，此設計的第二個問題也會發生。 例如，假設您需要變更供應商的地址。 因為地址會顯示在許多地方，您可能不小心在一個地方變更地址，但卻忘了在其他地方變更地址。 將供應商的地址只記錄在一個地方就能解決問題。
設計資料庫時，請務必嘗試每個事實只記錄一次。 如果您發現自己在多個位置重複相同的資訊 (例如特定供應商的地址)，請將該資訊放在個別的資料表中。
最後，假設 Coho Winery 只供應一個產品，而且您想要刪除該產品，但保留供應商名稱與地址資訊。 您要如何刪除產品記錄，才不會造成供應商資訊遺失？ 您無法這麼做。 因為每一筆記錄都包含產品相關事實以及供應商相關事實，所以您無法刪除一個卻同時保留另一個。 若要將這些事實分開保存，您必須將一個資料表分割為二：一個資料表用於產品資訊，而另一個資料表用於供應商資訊。 刪除產品記錄應該只會刪除產品相關事實，而不會刪除供應商相關事實。
一旦您已選擇資料表所代表的主體後，該資料表中的資料行應該只會儲存主體的相關事實。 例如，產品資料表應該只儲存產品的相關事實。 因為供應商地址是供應商的相關事實 (而不是產品的相關事實)，它就屬於供應商資料表。
將資訊項目轉成資料行
若要決定資料表中的資料行，請決定您需要追蹤資料表中記錄的哪些主體相關資訊。 例如，針對 [客戶] 資料表，[名稱]、[地址]、[市/鎮-縣/市-郵遞區號]、[傳送電子郵件]、[問候語] 和 [電子郵件地址] 是構成資料行清單的一個好起點。 資料表中的每筆記錄都會包含一組相同的資料行，因此您可以儲存每筆記錄的 [名稱]、[地址]、[市/鎮-縣/市-郵遞區號]、[傳送電子郵件]、[問候語] 和 [電子郵件地址] 資訊。 例如，地址資料行包含客戶的地址。 每筆記錄包含一個客戶的相關資料，而地址欄位則包含該客戶的地址。
一旦您已決定每個資料表的一組初步資料行後，您就可以進一步改善資料行。 例如，以兩個個別的資料行 (名字和姓氏) 來儲存客戶名稱是很合理的做法，這樣您就可以排序、搜尋資料行，以及只在這些資料行上編製索引。 同樣地，地址實際包含了五個個別的元件 (地址、市/鎮、縣/市、郵遞區號以及國家/地區)，而且將它們儲存在個別的資料行也是合理的做法。 例如，如果您想要執行搜尋、篩選或依縣/市排序營運狀況，則需將縣/市資訊儲存在個別的資料行。
您也應考慮資料庫是否保存來自國內的資訊，還是也有國際的資訊。 例如，如果您計劃儲存國際地址，建立一個 [地區] 資料行 (而不是 [縣/市] 資料行) 會是比較好的做法，因為該資料行能夠同時適應國內的縣/市和其他國家/地區的區域。 同樣地，如果您要儲存國際地址，[郵遞區號] 會比 [郵政編碼] 更合理。
以下清單顯示決定資料行的一些祕訣。
-
不包含計算資料
在大多數的情況下，您不應將計算結果儲存在資料表中。 您可以改為讓 Access 在您要查看結果時執行計算。 例如，假設有一份 [已訂購產品] 報表，該報表顯示資料庫中每個產品類別的訂購量小計。 不過，任何資料表中都沒有 [訂購量] 小計資料行。 反而是 [產品] 資料表包含了 [訂購量] 資料行，該資料行儲存了每個產品的訂購量。 每當您列印報表時，Access 都會使用該資料計算小計。 小計本身不應儲存在資料表中。
-
將資訊儲存為其最小的邏輯部分
您可能想要有一個全名的單一欄位，或產品名稱及其產品描述的單一欄位。 如果您在欄位中合併多種資訊，之後擷取個別事實則會變得很困難。 請嘗試將資訊細分為多個邏輯部分；例如為名字和姓氏建立個別的欄位，或為產品名稱、類別和描述建立個別的欄位。
一旦您已改善每個資料表中之資料的資料行後，您就可以選擇每個資料表的主索引鍵。
指定主索引鍵
每個資料表應包含一個或一組資料行，並且能夠唯一識別資料表中儲存的每個資料列。 這通常是一個唯一的識別碼，例如員工識別碼或序號。 以資料庫術語來說，此資訊稱為資料表的「主索引鍵」。 Access 使用主索引鍵欄位讓來自多個資料表的資料快速產生關聯，並為您整合資料。
如果您在資料表中已有唯一識別碼 (例如唯一識別型錄中每個產品的產品編號)，您可以使用該識別碼做為資料表的主索引鍵，但前提是此資料行中的值在每筆記錄中都須不同。 您不能重複主索引鍵中的值。 例如，請勿使用人名做為主索引鍵，因為人名並非唯一。 您可以在同一個資料表中輕鬆擁有兩個具有相同名字的人。
主索引鍵一律必須有一個值。 如果資料行的值在某個時間點可以變成未指派或未知 (遺失的值)，則無法用來做為主索引鍵中的元件。
您一律應選擇其值不會變更的主索引鍵。 在使用多個資料表的資料庫中，資料表的主索引鍵可以用來做為其他資料表中的參照。 如果主索引鍵變更，該變更也必須套用到參照該索引鍵的所有位置。 若要降低主索引鍵可能變成與參照它的其他資料表不同步的機率，可使用不會變更的主索引鍵。
通常會使用任意、唯一的數字做為主索引鍵。 例如，您可能為每筆訂單指派唯一的訂單號碼。 訂單號碼的唯一用途是識別訂單。 一旦指派後，絕對不會變更。
如果您想不到一個或一組可構成良好主索引鍵的資料行，請考慮使用具有 [自動編號] 資料類型的資料行。 當您使用 [自動編號] 資料類型時，Access 會自動為您指派值。 此類識別碼不含事實；不包含描述所代表之資料列的事實資訊。 不含事實的識別碼非常適合用來做為主索引鍵，因為它們不會變更。 包含資料列相關事實的主索引鍵 (例如電話號碼或客戶名稱) 比較有可能變更，因為事實資訊本身可能會變更。
1.設為 [自動編號] 資料類型的資料行通常會構成良好的主索引鍵。 沒有兩個產品識別碼是相同的。
在某些情況下，您可能想要一起使用兩個或兩個以上的欄位，提供資料表的主索引鍵。 例如，儲存訂單明細項目的 [訂單詳細資料] 資料表會在它的主索引鍵中使用兩個資料行：[訂單識別碼] 與 [產品識別碼]。 當主索引鍵採用多個資料行時，這就稱為「複合索引鍵」。
針對產品銷售資料庫，您可以為每個資料表建立 [自動編號] 資料行以用來做為主索引鍵：用於 [產品] 資料表的 [產品識別碼]、用於 [訂單] 資料表的 [訂單識別碼]、用於 [客戶] 資料表的 [客戶識別碼]，以及用於 [供應商] 資料表的 [供應商識別碼]。
建立資料表關聯性
現在您已將資訊分成多個資料表，您需要有意義地再次整合資訊的方法。 例如，下列表單包含來自多個資料表的資訊。
1. 此表單的資訊來自 [客戶] 資料表...
2. ...[員工] 資料表...
3. ...[訂單] 資料表...
4. ...[產品] 資料表...
5. ...以及 [訂單詳細資料] 資料表。
Access 是一種關聯式資料庫管理系統。 在關聯資料庫中，您將資訊分成個別、主體型資料表。 接著，您視需要使用資料表關聯性整合資訊。
建立一對多關聯性
思考一下此範例：在產品訂單資料庫中建立 [供應商] 和 [產品] 資料表。 供應商可提供任何產品數量。 由此可知，[供應商] 資料表中會顯示任何供應商，而 [產品] 資料表中會顯示許多產品。 因此，[供應商] 資料表和 [產品] 資料表之間的關聯是一對多關聯性。
若要在資料庫設計中表示一對多關聯性，可以將關聯「一」端的主索引鍵，新增到關聯「多」端的資料表中做為其一或多個其他資料行。 以此案例為例，您可以將 [供應商識別碼] 資料行從 [供應商] 資料表新增到 [產品] 資料表。 Access 就可以在 [產品] 資料表中使用供應商識別碼，找出每個產品的正確供應商。
[產品] 資料表中的 [供應商識別碼] 資料行稱為「外部索引鍵」。 外部索引鍵是另一個資料表的主索引鍵。 [產品] 資料表中的 [供應商識別碼] 資料行是外部索引鍵，因為它也是 [供應商] 資料表中的主索引鍵。
您建立主索引鍵和外部索引鍵的配對，藉此提供聯結關聯資料表的基礎。 如果您不確定哪些資料表應共用共同的資料行，識別一對多關聯性可確保包含的兩個資料表確實需要一個共用的資料行。
建立多對多關聯性
思考一下 [產品] 資料表與 [訂單] 資料表之間的關聯性。
單筆訂單可以包含多項產品。 另一方面，單項產品也可以出現在許多訂單上。 因此，[訂單] 資料表的每一筆記錄，在 [產品] 資料表中都可以包含許多筆記錄。 而針對 [產品] 數據表中的每一筆記錄，[訂單] 數據表中可以有許多筆記錄。 這種關聯類型稱為多對多關聯，因為對於任何產品來說，都可以有許多訂單;而對於任何訂單，都可以有許多產品。 請注意，若要偵測數據表之間的多對多關聯性，請務必考慮關聯的兩端。
訂單和產品這兩個數據表的主題具有多對多關聯性。 這會顯示問題。 若要了解問題，請想像如果您嘗試透過將 [產品標識符] 字段新增至 [訂單] 數據表來建立兩個數據表之間的關聯，會發生什麼情況。 若要每筆訂單有一筆以上的產品，每個訂單的 [訂單] 數據表中需要一筆以上的記錄。 您會重複與單一訂單相關之每一列的訂單資訊，導致設計效率低下，導致數據不正確。 如果您將 [訂單標識符] 字段放在 [產品] 資料表中，則會遇到相同的問題—每個產品的 [產品] 數據表中都會有一筆以上的記錄。 如何解決此問題？
解決方法為建立稱為「聯合資料表」的第三個資料表，將多對多關聯性分成兩個一對多關聯性。 將兩個資料表中的主索引鍵都插入到第三個資料表。 如此一來，第三個資料表就會記錄關聯中每一個出現的項目或執行個體。
[訂單詳細資料] 資料表中的每筆記錄代表一筆訂單上的一個明細項目。 [訂單詳細資料] 資料表的主索引鍵包含兩個欄位：[訂單] 和 [產品] 資料表中的外部索引鍵。 單獨使用 [訂單識別碼] 欄位無法用來做為此資料表的主索引鍵，因為一筆訂單可以有多個明細項目。 一筆訂單上的每個明細項目的 [訂單識別碼] 會重複，因此欄位不包含唯一值。 單獨使用 [產品識別碼] 欄位也不可行，因為一個產品會出現在多筆不同的訂單上。 但是將兩個欄位一起使用，一定會為每筆訂單產生唯一的值。
在產品銷售資料庫中，[訂單] 資料表和 [產品] 資料表彼此並不直接相互關聯。 而是透過 [訂單詳細資料] 資料表間接關聯。 訂單與產品之間的多對多關聯性在資料庫中會使用兩個一對多關聯性表示：
-
[訂單] 資料表和 [訂單詳細資料] 資料表具有一對多關聯性。 每筆訂單可以有多個明細項目，但每個明細項目只會連結到一筆訂單。
-
[產品] 資料表和 [訂單詳細資料] 資料表具有一對多關聯性。 每個產品都可以有多個與它關聯的明細項目，但每個明細項目只會參照一個產品。
從 [訂單詳細資料] 資料表，您可以決定特定訂單上的所有產品。 您也可以決定特定產品的所有訂單。
納入 [訂單詳細資料] 資料表後，資料表和欄位清單看起來可能像這樣：
建立一對一關聯性
另一種關聯性類型是一對一關聯性。 例如，假設您需要記錄一些產品的特別補充資訊，但該資訊很少需要用到或只適用於一些產品。 因為您不會經常需要該資訊，而且因為將資訊儲存在 [產品] 資料表會導致在每個不適用的產品中有空白區域，所以請將該資訊放在個別的資料表中。 和 [產品] 資料表一樣，您使用 [產品識別碼] 做為主索引鍵。 此補充資料表和 [產品] 資料表之間的關聯性是一對一關聯性。 針對 [產品] 資料表中的每筆記錄，在補充資料表中會存有單一相符記錄。 當您確實識別此類關聯性時，兩個資料表都必須共用共同的欄位。
當您在資料庫中偵測到一對一關聯性的需求，請考慮您是否可以將兩個資料表中的資訊整合到一個資料表中。 如果您基於某些原因不想要這麼做 (也許因為它會產生很多空白區域)，下列清單說明如何表示您設計中的關聯性：
-
如果兩個資料表有相同的主體，您可能可以在兩個資料表中使用相同的主索引鍵，藉此設定關聯性。
-
如果兩個資料表都含有具備不同索引鍵的不同主體，請選擇其中一個資料表 (兩者中的任何一個)，然後在另一個資料表中插入其主索引鍵做為外部索引鍵。
決定資料表之間的關聯性有助於確保您擁有正確的資料表和資料行。 當一對一或一對多關聯性存在時，包含的資料表必須共用共同的一或多個資料行。 當多對多關聯性存在時，則需使用第三個資料表來表示關聯性。
讓設計更完善
一旦您擁有所需的資料表、欄位和關聯性後，您應建立並使用範例資料填入資料表，然後嘗試使用資訊：建立查詢、新增記錄等。 這麼做有助於突顯潛在問題，例如您可能需要新增您在設計階段期間忘了插入的資料行，或者您可能有一個資料表應分割成兩個資料表以移除重複資料。
看看您是否可以使用資料庫取得所需的答案。 建立表單和報表的草稿，看看它們是否顯示您預期的資料。 尋找不需要的重複資料，並且如果找到了任何重複資料，請更改設計以消除重複資料。
當您嘗試使用初始資料庫時，您可能會發現有改善的空間。 以下是一些檢查的要點：
-
是否忘了任何資料行？ 若是如此，該資訊是否屬於現有的資料表？ 如果是有關另一個項目的資訊，您可能需要建立另一個資料表。 為您需要追蹤的每個資訊項目建立一個資料行。 如果無法從其他資料行計算資訊，該資訊可能需要新的資料行。
-
因為可以從現有的欄位計算資料行，因此是否有任何不必要的資料行？ 如果可以從其他現有的資料行計算資訊項目 (例如從零售價計算折扣價)，通常直接計算會比較好，並且避免建立新的資料行。
-
您是否在其中一個資料表中重複輸入了重複的資訊？ 若是如此，您可能需要將資料表分成兩個具有一對多關聯性的資料表。
-
您的資料表是否含有許多欄位、數量有限的記錄，以及個別記錄中的多個空白欄位？ 若是如此，請考慮重新設計資料表，減少欄位並增加記錄。
-
每個資訊項目是否都已細分成可用資訊的最小部分？ 如果您需要報告、排序、搜尋或計算資訊項目，請將該項目放在它自己的資料行中。
-
每個資料行是否包含資料表之主體的相關事實？ 如果資料行不包含資料表之主題的相關資訊，則它是屬於不同的資料表。
-
透過共同的欄位或透過第三個資料表，是否已呈現資料表之間的所有關聯性？ 一對一和一對多關聯性需要共同的資料行。 多對多關聯性需要第三個資料表。
讓 [產品] 資料表更完善
假設產品銷售資料庫中的每個產品歸入一般類別，例如飲料、佐料或海鮮。 [產品] 資料表可能包含顯示每個產品類別的欄位。
假設在檢查及改善資料庫設計後，您決定儲存類別描述及其名稱。 如果您將 [類別描述] 欄位新增到 [產品] 資料表，您必須重複每個歸入該類別之產品的每個類別描述，這並不是良好的解決方案。
比較好的解決方案是讓 [類別] 成為要追蹤的資料庫的新主體，並具備它自己的資料表及它自己的主索引鍵。 接著，您可以將主索引鍵從 [類別] 資料表新增到 [產品] 資料表做為外部索引鍵。
[類別] 和 [產品] 資料表具有一對多關聯性：一個類別可以包含一個以上的產品，但一個產品只能屬於一個類別。
當您檢閱資料表結構時，請注意重複的群組。 例如，請考慮包含下列資料行的資料表：
-
產品識別碼
-
名稱
-
產品識別碼 1
-
名稱 1
-
產品識別碼 2
-
名稱 2
-
產品識別碼 3
-
名稱 3
在這裡，每個產品都是重複的資料行群組，與其他的不同處只有在資料行名稱結尾加入一個編號。 當您看到以這種方式編號的資料行時，您應重新檢閱設計。
這類設計有一些缺點。 針對入門者，此設計會強制設定產品數量的上限。 當您超過該上限，則必須在資料表結構中新增新的資料行群組，這是主要的系統管理工作。
另一個問題是，這些擁有低於產品數量上限的供應商會浪費一些空間，因為額外的資料行會呈現空白。 此類設計最嚴重的缺點是，它會讓許多工作變得難以執行，例如依產品識別碼或名稱進行資料表的排序或索引編製。
每當您看到重複的群組時，請密切檢閱設計，並考慮將該資料表分割為二。 在以上範例中，使用兩個資料表 (一個用於供應商、一個用於產品) 是比較好的做法，並且以供應商識別碼連結。
套用正規化規則
您可以套用資料正規化規則 (有時簡稱為正規化規則)，做為設計的下一步。 您使用這些規則確認資料表的結構是否正確。 將規則套用到資料庫設計的程序稱為「正規化資料庫」，或簡稱為「正規化」。
在您已顯示所有資訊項目並達到初步設計後，正規化就會相當實用。 其概念在於協助您確保已將資訊項目分成適當的資料表。 但正規化無法確保您擁有要做為開始的所有正確資料項目。
您連續套用規則，在每個步驟確保設計達到所謂的「正規表單」。 有五個廣泛採用的正規表單 (第一個正規表單到第五個正規表單)。 本文闡述前三個，因為它們就是大多數資料庫設計所需。
第一個正規表單
第一個正規表單指定資料表中的每個資料列和資料行交集存在單一的值，而且絕對不會有值清單。 例如，您不能有一個名為 [價格] 的欄位，而您在其中放入一個以上的 [價格]。 如果您將每個資料列和資料行的交集視為儲存格，每個儲存格只能保存一個值。
第二個正規表單
第二個正規表單要求每個非索引鍵資料行完全以整個主索引鍵為依據，而不是只以該索引鍵的一部分為依據。 當您有包含一個以上資料行的主索引鍵時，即適用此規則。 例如，假設您有包含下列資料行的資料表，其中 [訂單識別碼] 和 [產品識別碼] 形成主索引鍵：
-
訂單識別碼 (主索引鍵)
-
產品識別碼 (主索引鍵)
-
產品名稱
此設計違反第二個正規表單，因為 [產品名稱] 是以 [產品識別碼] 為依據，但不以 [訂單識別碼] 為依據，因此它不會以整個主索引鍵為依據。 您必須移除資料表中的 [產品名稱]。 它屬於不同的資料表 ([產品])。
第三個正規表單
第三個正規表單要求不只每個非索引鍵資料行必須以整個主索引鍵為依據，也要求以非索引鍵資料為彼此的依據。
另一種說法是，每個非索引鍵資料行都必須以主索引鍵為依據，而且只有主索引鍵。 例如，假設您有包含下列資料行的資料表：
-
產品識別碼 (主索引鍵)
-
名稱
-
SRP
-
折扣
假設 [折扣] 以建議零售價 (SRP) 為依據。 此資料表違反第三個正規表單，因為非索引鍵資料行 (折扣) 是以另一個非索引鍵資料行 (SRP) 為依據。 不以資料行為依據表示您應該可以變更任何非索引鍵資料行，而不會影響任何其他資料行。 如果您變更 SRP 欄位中的值，[折扣] 也會隨之變更，因此違反了該規則。 在此案例中，應將 [折扣] 移至索引鍵位於 SRP 上的另一個資料表。
