創建數據庫表即是一種學識也同樣是一種技巧。用戶需求方面的豐富知識是任何數據庫項目的首要需求。第3 章中將討論把數據庫設計規則應用于創建Access表的細節問題。同時，我們還要關注一下創建基本Access 表所需的步驟。在以下各部分內容中，用戶還可以學習到向Access數據庫添加表的過程，包括相對比較復雜的選擇適當數據類型以及在表中分配各個字段的問題。

在決定使用Access 工具向數據庫添加表前，先在紙上規劃表是個不錯的辦法。將很多表，尤其是一些小表添加到數據庫之前并不需要事先考慮太多問題。畢竟，設計一個包含例如城市和州等查詢信息的表并不需要大量的規劃工作。然而，更為復雜的實體(例如客戶和產品)通常需要大量的思考和工作來實現。

盡管可以通過人機對話，而不是事先考慮的方式來創建表，但仔細規劃數據庫系統仍然是個不錯的辦法。用戶可以在以后進行更改，但是這么做很費時: 一般來說，如果不在開始時進行完善的規劃，系統將變得相對難以維護。在開始之前，應該了解一下袤的設計過程。

在以下各部分內容中，我們將在創建新數據庫時研究Access 添加的新空白表。了解向Access數據庫添加新表的步驟非常重要。相對以前版本的Access. 添加表所需的步驟發生了巨大的改變，因此甚至經驗豐富的開發人員也很希望閱讀以下各部分的內容。

2.4.1 命名約定的重要性

隨著數據庫規模和復雜性不斷增加，為數據庫中的對象建立命名約定的需求日益增大。像大家所了解的那樣，對象名稱的更改傳播到了整個數據庫。即使打開"名稱宇段更正選項"選項("office按鈕" -> "Access 選頂"->"當前數據庫" -> "名稱宇段更正選項")，Access也只能糾正最為明顯的名稱更改。更改表的名稱事實上會中斷所有使用表信息的查詢、窗體和報表。最好的方法就是在開始建立Access 數據庫時采用合理的對象名稱以及使用命名約定，并且在整個項目過程中堅持該命名約定。

Access 對數據庫對象名稱分配的約束非常有限.因此，費全有可能將兩個明顯不同的對緣(例如，窗休和報表，或者表和宏)命名為同一個名稱(由于表和查詢在數據庫占了同一個命名空間，所以不能將表和查詢命名為同一名稱〉。

盡管像Contact 和Order 這樣簡單的名稱已經夠用，但隨著數據庫規模和復雜性的不斷增加，用戶可能會對某個特定名稱是指哪個對象感到困惑。例如，本書中還包含了通過代碼和宏來操作數據庫對象。在使用Access 2007 內建的編程語言Visual Basicfor Applications (VBA) 時，已引用的對象之間不能存在模糊和海淆。將窗體和報表同時命名為Contact 會造成用戶或者代碼的混淆。

最簡單的命名約定就是在對象名稱前加上表明對象類型的3 個字符或者4 個字符的字符串。

使用該約定后，表名稱前會加上tbl 而查詢名稱前會加上qry。窗體、報表、宏和模塊的前綴分別為frm 、rpt 、mcr 和bas 或者modo本書中最復雜的對象名稱出現在混合大小寫中: tblBookOrders 、tblBookOrderDetails等。大多數人都認為相對于全部為大寫或者全部為小寫的名稱八例如TBLBOOKORDERS 或者tblbookorderdetails1，混合大小寫名稱中出現的字符更易于理解和記憶。

而且有時我們會對數據庫對象使用非正式的引用。例如，在前一個例子中包含聯系人信息表的正式名稱為tblContactss ，而對該表的非正式引用可能會是"聯系人表"。

大多數情況下，用戶還會看到數據庫對象的正式名稱。應用程序開發人員所面臨的挑戰之一就是提供一個無縫的并且能夠隱藏所有支持用戶界面的數據管理和數據存儲實體的用戶界面。用戶可以輕松地通過控制出現在窗體、報表和其他用戶界面組件的標題欄和表面的文本來隱藏數據結構和界面成分的實際名稱。

利用Access 許可的長對象名稱為表、查詢、窗體和報表賦予描述性的、內容充實的名稱。對于為什么要在Contactlnformation 同樣易于理解和識別時要把表名稱限定為Conlnfo ，這一點并沒有具體的理由。

當然，描述性的名稱以可以走向極端。但是在同樣可以將窗體命名frmUpdatelnfo 時將其命名為frmUpdateContactlnformation 并無意義。相對于短名稱而言，長名稱更容易出現拼寫錯誤或者被讀錯，需要對此做出判斷。

最后，盡管Access 允許使用空格，但應該盡可能地避免空格的使用。空格并不能增加可讀性，卻會造成重大的問題，特別是在升遷到客戶端-服務器環境或者同時使用OLE 和其他應用程序時。

即使不打算將Access 應用程序擴展到客戶端·服務器或者將OLE 或者DDE 自動化功能合并到應用程序中，還是應該培養不要在對象名稱中使用空格的習慣。