企業(yè)旅行者的姓名字段還沒有成為最小的可能單元，從而破壞了1NF（First Normal Form）原則。這些旅行者可以是單獨的游客而非公司。不過解決這個問題也很簡單，我們可以創(chuàng)建兩個字段：FirstName和LastName，然后做出些有關定義。 新的客戶表也有個性質比較嚴重的問題：接受零售服務的客戶很可能是需要FirstName和LastName字段的個人。為了簡化示例，我們不妨規(guī)定以下一條商務規(guī)則：所有的客戶都是公司，所以在目前階段還不需要解決這個問題。出于簡單的目的，我們只引入了這一條商務規(guī)則，把客戶限定為企業(yè)而非個人，這樣就不再需要進一步地設計了。 地址信息破壞了2NF（Second Normal Form）規(guī)則。地址字段和其他完整說明客戶的所有字段而非地址字段都存在依附性。所以，某些開發(fā)人員可能會取消新表中的地址字段。不過那樣做的話，假如數(shù)據(jù)表按照BCNF規(guī)則規(guī)范化（Boyce-Codd Normal Form）則可能引入額外的數(shù)據(jù)表。在這種起來下，你可以引入地址、城市和州等數(shù)據(jù)表來遵守以上規(guī)則。此外，客戶還可能具有多個地址，比如說，一個地址專門用來通郵；一個地址專門用來寄送票據(jù)和日程表信息等等。 客戶表中的打折和傭金字段也有問題，它們倒沒有違反什么規(guī)范化規(guī)則，但是這類字段很多往往會是空白?？兆侄坞m然也沒什么壞處，但最好還是盡量避免出現(xiàn)這樣的情況。事實上，太多的空白往往是出現(xiàn)規(guī)范化錯誤的信號。所以，就我們的例子來說，兩個字段都完全說明了主鍵而且不會與其他非鍵字段形成明顯的依附關系。不過，由于可能出現(xiàn)空白字段的緣故，我們還是把這些字段移到一個新表，通過客戶標識每條記錄，然后給傭金或者折扣標記百分比。 客戶只會有一個電話號碼嗎？假如不是這樣，客戶表內當前的電話號碼字段就破壞了1NF規(guī)則：禁止出現(xiàn)多值字段。那就是說，一個字段內不答應輸入多個電話號碼。所以電話號碼字段也必須移到一個新表中來，這樣就需要一個電話號碼表。解決的辦法是從客戶表中刪除電話號碼字段然后創(chuàng)建一個只有電話號碼的新表。 規(guī)范化還是不規(guī)范化 假如我們的目標是老實遵守BCNF原則，那么地址表的規(guī)范化（Normalizing）就是必須考慮的問題，我們需要按照客戶類型來標識每一地址：商務、服務交付等等。第1步是從客戶表中刪除地址字段，然后根據(jù)圖B所顯示的初始列表創(chuàng)建新的地址表。但我們還必須接著解決州和城市字段之間的依附性問題。
Microsoft SQL Server 2000提供了UDF（用戶定義函數(shù)）這種語言擴展，而它并沒有受到其他競爭產(chǎn)品的支持。微軟公司在特立獨行方面可不是唯一的家伙。Oracle的NESTED TABLE語法以及MySQL之流都提出了相當數(shù)量的個性擴展，比如后者的ENUM、SET列類型等。
