點擊上方藍色字關注我們~

Access是一個基于數據庫的開發設計工具，用它甚至可以開發出一整套的基于數據庫的應用管理軟件，所以使用時就必須遵循一定的開發設計流程，不像和它同屬MicrosoftOffice辦公系統軟件的其它組件如Word、Excel等，可隨時隨意的打開新文件及輸入數據，而必須進行一定的設計才能使用。

而表是Access中其它對象的根源，所有其它對象的設計開發都圍繞表中的數據而進行，所以表的設計至關重要。

當開發進行到一定程度的時候，如果要對表的設計做出改動，和其相關的所有內容都需要同樣進行修改，耗時耗力，甚至需要完全重新設計，由此可見初期正確建表的重要性。

本文針對剛接觸Access的初學者，講述了一些建表的基本原理和規范，讓大家少走一些彎路，盡量避免由于初期建表不正確造成的效率不高、后續開發困難，甚至因此造成需要全部推倒重來。

在實際應用中，尤其是剛接觸Access的朋友，如果之前沒有數據庫的相關理論知識的話，就會感到很茫然，不知如何下手。最可能的情況就是憑感覺隨意建表，結果造成完全達不到想要的結果或者效率不高，乃至后繼的開發無以為繼，甚至需要全部推倒重來。

建議大家找一些關系數據庫理論方面的書看看，因為Access就是一個關系數據庫。在這里由于篇幅所限，只能簡單的說一下在Access中建表的一些基本原理規范及要點。

先聲明一下兩個名詞的含義：表是列和行組成的，在Access中列被稱為字段，行被稱為記錄(大部分關系數據庫也都是這么叫的)。請記住這兩個名詞，以后會頻繁的用到

構造數據庫必須遵循一定的原理規則，而Access是一個關系數據庫系統，所以使用Access就要遵循關系數據庫的原理規則：范式(NormalForm)。

目前按照國際標準，一共有6種范式，除第一范式外，其它范式都是在滿足前一范式的基礎上而定義的，也就是說，符合第三范式的必定符合第二范式，符合第二范式的必定符合第一范式，以此類推。不過一般來說我們只要規范化到第三范式就足夠了，其它范式不常用到，這里就不做解釋和討論了。

第一范式(1NF)：數據庫表中的字段都是單一屬性，不可再分。

第一范式是最低的規范化要求，第一范式要求數據表不能存在重復的記錄，即存在一個無重復主索引(主鍵)。第一范式的第二個要求是每個字段都不可再分，即已經分到最小，關系數據庫的定義就決定了數據庫滿足這一條。主鍵不一定是某一個字段，也可以是多個字段的組合，不過一般都是設為一個字段，這樣在使用時相對簡單。主鍵要求它基于的字段不允許重復、不允許有空值。

滿足第一范式的關系模式有許多不必要的重復值，并且在添加、修改、刪除記錄時可能會導致異常。為了避免數據冗余和消除異常，就引出了第二范式(2NF)。?

第二范式(2NF)：在第一范式的基礎上，其它所有的字段都完全地依賴于主鍵字段。

為了說明問題現舉一個例子來說明：有一個庫房存儲的庫有四個字段(零件號碼，倉庫號碼，零件數量，倉庫地址)，這個庫符合第一范式，其中“零件號”和“倉庫號”構成主關鍵字。但是因為“倉庫地址”只完全依賴于“倉庫號碼”，即只依賴于主關鍵字的一部分，所以它不符合第二范式。

這樣首先存在數據冗余，因為倉庫數量可能不多。其次，存在如果更改倉庫地址時，如果漏改了某一記錄，存在數據不一致性。再次，如果某個倉庫的零件出完了，那么這個倉庫地址就丟失了，即這種關系不允許存在某個倉庫中不放零件的情況。

我們可以用投影分解的方法消除部分依賴的情況，而使關系達到第二范式的標準。方法是從關系中分解出新的表，是每個表中所有的非關鍵字都完全依賴于各自的主關鍵字。我們可以分解成兩個表(零件號碼，倉庫號碼，零件數量)和(倉庫號碼，倉庫地址)，這樣就完全符合第二范式了。

第三范式(3NF)：如果一個關系屬于第二范式，且其它字段不傳遞依賴于主鍵，則它滿足第三范式。

從第二范式中消除傳遞依賴，就是第三范式。比如有一個表(姓名，工資等級，工資額)，其中姓名是關鍵字，?此關系符合第二范式，但是因為工資等級決定工資額，這就叫傳遞依賴，它不符合第三范式，我們同樣可以使用投影分解的辦法分解成兩個表：(姓名，工資等級)，(工資等級，工資額)。?

以上就是關系數據庫的最基本的三范式規則，只有從理論上理解了，才會更容易在實際應用中理出頭緒。后面我們會再用一篇文章說一些要點和技巧。

愛我,請給我好看

總結

以上是生活随笔為你收集整理的vfp如何比较两张表的关键字重复_Access开发中建表的基本原理和规范（上）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。