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

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

盡管可以通過人機(jī)對話，而不是事先考慮的方式來創(chuàng)建表，但仔細(xì)規(guī)劃數(shù)據(jù)庫系統(tǒng)仍然是個(gè)不錯(cuò)的辦法。用戶可以在以后進(jìn)行更改，但是這么做很費(fèi)時(shí): 一般來說，如果不在開始時(shí)進(jìn)行完善的規(guī)劃，系統(tǒng)將變得相對難以維護(hù)。在開始之前，應(yīng)該了解一下袤的設(shè)計(jì)過程。

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

2.4.1 命名約定的重要性

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

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

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

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

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

而且有時(shí)我們會(huì)對數(shù)據(jù)庫對象使用非正式的引用。例如，在前一個(gè)例子中包含聯(lián)系人信息表的正式名稱為tblContactss ，而對該表的非正式引用可能會(huì)是"聯(lián)系人表"。

大多數(shù)情況下，用戶還會(huì)看到數(shù)據(jù)庫對象的正式名稱。應(yīng)用程序開發(fā)人員所面臨的挑戰(zhàn)之一就是提供一個(gè)無縫的并且能夠隱藏所有支持用戶界面的數(shù)據(jù)管理和數(shù)據(jù)存儲(chǔ)實(shí)體的用戶界面。用戶可以輕松地通過控制出現(xiàn)在窗體、報(bào)表和其他用戶界面組件的標(biāo)題欄和表面的文本來隱藏?cái)?shù)據(jù)結(jié)構(gòu)和界面成分的實(shí)際名稱。

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

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

最后，盡管Access 允許使用空格，但應(yīng)該盡可能地避免空格的使用?？崭癫⒉荒茉黾涌勺x性，卻會(huì)造成重大的問題，特別是在升遷到客戶端-服務(wù)器環(huán)境或者同時(shí)使用OLE 和其他應(yīng)用程序時(shí)。

即使不打算將Access 應(yīng)用程序擴(kuò)展到客戶端·服務(wù)器或者將OLE 或者DDE 自動(dòng)化功能合并到應(yīng)用程序中，還是應(yīng)該培養(yǎng)不要在對象名稱中使用空格的習(xí)慣。