關(guān)系型數(shù)據(jù)庫：定義數(shù)據(jù)庫表格之間的關(guān)系

2024-07-21 02:36:56

字體：大中小

供稿：網(wǎng)友

　　設(shè)計關(guān)系型數(shù)據(jù)庫的重頭戲是把數(shù)據(jù)元素分別放進相關(guān)的表格里。一旦預(yù)備好開始操作數(shù)據(jù)，你就要依靠表格之間的關(guān)系把數(shù)據(jù)以有意義的方式聯(lián)系到一起。例如，（單獨的）訂單信息是沒有用的，除非你知道是哪個用戶下了訂單。到現(xiàn)在這個時候，你可能已經(jīng)意識到了，你沒有把客戶信息和訂單信息保存在同一個表格里。但是，你把訂單信息和客戶數(shù)據(jù)保存在兩個相關(guān)的表格里，然后使用這兩個表格之間的關(guān)系來同時查看每個訂單及其相對應(yīng)的客戶信息。假如說規(guī)范化的表格是關(guān)系型數(shù)據(jù)庫的基礎(chǔ)，那么關(guān)系就是其基石。
　　關(guān)系型數(shù)據(jù)庫設(shè)計系列
　　你現(xiàn)在正身處Builder.com關(guān)系型數(shù)據(jù)庫設(shè)計系列之中。本系列先前的幾篇相關(guān)文章是：
　　《關(guān)系型數(shù)據(jù)庫：理論背后的靈感》
　　《關(guān)系型數(shù)據(jù)庫：使用范式創(chuàng)建數(shù)據(jù)庫》
　　《關(guān)系型數(shù)據(jù)庫：應(yīng)用第一范式》
　　《關(guān)系型數(shù)據(jù)庫：實現(xiàn)規(guī)范化》
　　出發(fā)點
　　
　　下面這些數(shù)據(jù)要用在本文的示例中。使用Boyce-Codd范式（BCNF）來規(guī)范化數(shù)據(jù)的過程產(chǎn)生了七個關(guān)系表：
　　Books: {Title*, ISBN, PRice}
　　Authors: {FirstName*, LastName*}
　　ZipCodes: {ZIPCode*}
　　Categories: {Category*, Description}
　　Publishers: {Publisher*}
　　States: {State*}
　　Cities: {City*}
　　
　　現(xiàn)在是該說明這些表格之間是如何建立關(guān)聯(lián)的時候了。
　　
　　關(guān)系的類型
　　
　　你和你的家庭成員之間存在著多種關(guān)系。例如，你和你母親就是相關(guān)的。你只有一個母親，但是她可以有多個子女。你和你的兄弟姐妹是相關(guān)的——你可以有很多的兄弟和姐妹，當然，他們也有很多兄弟和姐妹。假如你結(jié)了婚，你和你的配偶就會有一個配偶——這是相互的——但是一次只有一個。數(shù)據(jù)庫的關(guān)系非常類似：它們是通過表格相關(guān)聯(lián)的。有三種類型的關(guān)系：
　　
　　一對一（One-to-one）：在關(guān)系的每一邊，這兩個表格都只有一條記錄。每個要害字的值都只和關(guān)系表里的一條記錄（或者沒有記錄）相關(guān)。它們就是一對配偶一樣——你可以結(jié)婚，也可以不結(jié)婚，但是假如結(jié)了婚，你和你的配偶就只能有一個配偶。大多數(shù)一對一的關(guān)系都是商業(yè)規(guī)則所要求的，而不是源自于數(shù)據(jù)的要求。在沒這樣商業(yè)規(guī)則限制的時候，你通常可以把兩個表格合并進一個表格，而且不會打破任何規(guī)范化的規(guī)則。
　　一對多（One-to-many）：主要害字表格只包含有一條記錄，這條記錄和關(guān)系表里的無記錄、一條記錄或者多條記錄相關(guān)。這種關(guān)系同你和你父母之間的關(guān)系很類似。你只有一個母親，但是你的母親可以有多個子女。
　　多對多（Many-to-many）：兩個表格里的每條記錄都可以和另一個表格里任意數(shù)量的記錄（或者無記錄）相關(guān)。例如，假如你有好幾個兄弟姐妹，那么你的兄弟姐妹也有好幾個兄弟姐妹。多對多的關(guān)系需要引入第三個表格，叫做聯(lián)系表（associate table或者linking table）因為關(guān)系型系統(tǒng)不能直接實現(xiàn)這種關(guān)系。
　　建立關(guān)系
　　
　　　
　　
　　在考慮建立關(guān)系表之間的關(guān)系之前，你可能需要非常熟悉數(shù)據(jù)。只有在熟悉數(shù)據(jù)之后，關(guān)聯(lián)會比你剛開始的時候更明顯。你的數(shù)據(jù)庫系統(tǒng)要依靠匹配兩個表格里的值來建立關(guān)系。假如匹配的話，系統(tǒng)會從這兩個表格里抽出數(shù)據(jù)來創(chuàng)建一個虛擬記錄。例如，你可能想要查看某個作者寫的所有書。在本文里，系統(tǒng)會匹配Books和Authors這兩個表格里的值。要記住在大多數(shù)時候，所產(chǎn)生的記錄是動態(tài)的，這就意味著對這條虛擬記錄的任何改動通常都會作用到底層的表格上，這一點非常重要。
　　
　　這些進行匹配的值都是主要害字值和外來要害字值。（關(guān)系模型并不要求關(guān)系要根據(jù)主要害字類來確定。你可以使用表格里的備選要害字，但是使用主要害字是大家認可的標準。）在（本系列的）第二篇文章里你已經(jīng)了解了主要害字——主要害字會唯一辨別表格里的每條記錄。外來要害字簡單地說就是一個表格在另一個表格里的主要害字。這樣看來，你要做的東西不多——只用簡單地把主要害字作為外來要害字添加到關(guān)系表里就行了。
　　
　　唯一需要注重的是，外來要害字字段的數(shù)據(jù)類型必須和主要害字的相同。但是有些系統(tǒng)可以答應(yīng)這條規(guī)則的一個例外，它們能夠答應(yīng)數(shù)字和自動編號（autonumbering）字段（例如SQL服務(wù)器Identity的access的AutoNumber）建立關(guān)系。此外，外來要害字的值可以是空（Null），盡管推薦的是：在沒有非凡原因的情況下，不要讓外來要害字為空。你有可能永遠都不會使用需要這項功能的數(shù)據(jù)庫。
　　
　　現(xiàn)在回到你的示例數(shù)據(jù)庫，并開始正確地輸入外來要害字。（請繼續(xù)在紙上打草稿——在你的數(shù)據(jù)庫系統(tǒng)里真正創(chuàng)建表格仍然是件很輕易的事情。在紙上糾正錯誤要輕易得多。）要記住，你正在把主要害字的值添加到關(guān)系表里。只用調(diào)用條目之間的關(guān)系就行了，而其他的就簡單了：
　　
　　書（book）和分類（category）相關(guān)。
　　書和出版商（publisher）相關(guān)。
　　書和作者（author）相關(guān)。
　　作者和郵政編碼（ZIP code）相關(guān)。
　　郵政編碼和城市（city）相關(guān)。
　　城市和州（state）相關(guān)。
　　
　　這一步不是一成不變的，你可能會發(fā)現(xiàn)在規(guī)范化的過程中加入外來要害字會更輕易一些。在把字段移動到一個新的表格時，你可能要把這個新表格的主要害字添加到原來的表格里，作為其為外來要害字。但是，在你繼續(xù)規(guī)范化剩余數(shù)據(jù)的時候，外來鍵經(jīng)常會發(fā)生改變。你會發(fā)現(xiàn)在所有這些表格被全部規(guī)范化之后，一次添加所有的外來要害字，這樣的效率會更高。

　　
　　現(xiàn)在讓我們一次操作一個表格，就從Books表格開始，它在這個時候只有三個字段。很明顯，Authors、Categories和Publishers表格的主要害字會被添加到Books里。當你完成的時候，Books表格就有了七個字段：
　　　關(guān)系型數(shù)據(jù)庫：定義數(shù)據(jù)庫表格之間的關(guān)系（圖一）

關(guān)系型數(shù)據(jù)庫：定義數(shù)據(jù)庫表格之間的關(guān)系（圖一）

　　要記住，Authors表格里的主要害字是一個基于姓和名字段的復(fù)合要害字。所以你必須要把這個兩個字段都添加到Books表格里。要注重，外來要害字字段名的結(jié)尾包含有FK這個后綴。加入這個后綴有助于提高可讀性和自我歸檔。通過名稱這種方式來區(qū)別外來要害字會讓追蹤它們更簡單。假如主要害字和外來要害字的名稱不同，這沒有關(guān)系。
　　
　　這里出現(xiàn)了三種關(guān)系：Books和Authors、Books和Categories，以及Books和Publishers。這三種關(guān)系中的兩種所存在的問題可能沒有那么明顯：
　　
　　Books和Authors之間的關(guān)系：一本書可以有多個作者。
　　Books和Categories之間的關(guān)系：一本書可以被歸入多個類。
　　　
　　
　　
　　這兩者的關(guān)系是多對多的關(guān)系。先前我告訴過你，表格不能直接實現(xiàn)這樣的關(guān)系，而需要第三個聯(lián)系表來實現(xiàn)。（Books和Publishers的關(guān)系是一對多的關(guān)系，就像現(xiàn)在所說的這樣是沒有問題的。）
　　
　　這兩個剛發(fā)現(xiàn)的多對多關(guān)系將需要一個聯(lián)系表來包含來自每個表格的主要害字，并將其作為外來要害字。新的聯(lián)系表是：
　　BooksAuthorsmmlink
　　TitleFK (FK) Books.Title one-to-many
　　ISBNFK (FK) Books.ISBN one-to-many
　　FirstNameFK (FK) Authors.FirstName one-to-many
　　LastNameFK (FK) Authors.LastName one-to-many
　　
　　BooksCategoriesmmlink
　　TitleFK (FK) Books.Title one-to-many
　　ISBNFK (FK) Books.ISBN one-to-many
　　CategoryFK (FK) Categories.Category one-to-many
　　
　　沒有必要更改Categories、Authors或者Publishers表格。但是，你必須把FirstNameFK、LastNameFK和CategoryFK這三個外來要害字從Books里移走：
　　Books
　　Title (PK)
　　ISBN (PK)
　　Price
　　PublisherFK (FK) Publishers.Publisher one-to-many
　　
　　現(xiàn)在，讓我們轉(zhuǎn)到Authors表格上來，它現(xiàn)在有兩個字段。每個作者都和ZIPCodes表格里郵政編碼的值相關(guān)。但是，每個郵政編碼會和多個作者相關(guān)。要實現(xiàn)這種一對多的關(guān)系，就要把ZIPCodes表格的主要害字添加進Authors表格作為外來要害字：
　　Authors
　　FirstName (PK)
　　LastName (PK)
　　ZIPCodeFK (FK) ZIPCodes.ZIPCode one-to-many
　　
　　至此，你已經(jīng)預(yù)備好了處理剩下的地址部分了。看到它們被分在不同的表格里是很讓人希奇的，但是這是遵照BCNF正確規(guī)范化數(shù)據(jù)的結(jié)果。每個郵政編碼的值只會有一個對應(yīng)的城市值和州值。每個城市和州的值只會被輸入進其對應(yīng)的表格里一次。ZIPCodes和Cities表格需要外來要害字字段來實現(xiàn)這些關(guān)系：
　　ZIPCodes
　　ZIPCode (PK)
　　CityFK (FK) Cities.City one-to-many
　　
　　Cities
　　City (PK)
　　StateFK (FK) States.State one-to-many
　　
　　States
　　State (PK)
　　
　　從一個到九個
　　
　　最后，你有了九個表格：Books、Authors、Categories、Publishers、ZIPCodes、Cities、States、BooksAuthorsmmlink和BooksCategoriesmmlink。圖A是這個示例表格數(shù)據(jù)庫最終的圖形形式。很難想像一個簡單的數(shù)據(jù)表格會被分成九個表格。
　　
　　圖A
　　關(guān)系型數(shù)據(jù)庫：定義數(shù)據(jù)庫表格之間的關(guān)系（圖二）

關(guān)系型數(shù)據(jù)庫：定義數(shù)據(jù)庫表格之間的關(guān)系（圖二）

　　原來的表格現(xiàn)在需要九個表格
　　
　　由于這個示例數(shù)據(jù)庫很簡單，你可能會問這些關(guān)系有什么作用。看起來你仍在保存冗余的數(shù)據(jù)，只不過形式不同罷了——通過外來鍵來實現(xiàn)。這是因為我們的表格現(xiàn)在只有很少幾個字段。試想一下有十幾個字段的表格。需要承認的是，你仍然需要把表格的主要害字作為外來要害字保存進關(guān)系表里，但是至多可能最多增加一到兩個字段。比較一下為這個表格里的每一條記錄都添加十幾個條目的情形吧。

上一篇：虛擬文件系統(tǒng)(VFS)簡介：管理Quota的函式

下一篇：RH9下最簡單的WebMail的實現(xiàn)方案