《SQL Story》摘錄五——關系真相
2024-07-21 02:09:04
供稿：網友
中國最大的web開發資源網站及技術社區，
關系的真相
長期以來，我們習慣了稱關系型數據庫中的表為二維表。因為它有行和列，很容易我們就可以把它同一個二維平面聯系起來，但事實上，這并非關系型數據庫的初衷，也并非符合關系模型的設計。其實長久以來，我對此也只有一個很模糊的概念，對平面表的觀點雖有懷疑，卻一直無從驗證。直到有一天，翻出一本老書——《關系數據庫》（石樹剛、鄭振楣編著，清華大學出版社，1993年），這本老書沒有什么流行的新噱頭，卻滿滿當當地凈是數學理論。這本書讀起來并不是很誘人，不過的確很嚴謹，澄清了我的很多不明之處。也激勵我找來各種權威材料重頭學起。薄薄一本書，定價只有9.9元，想想這應當是我在上學時，從舊書攤上買的，可能當時只花了不到五元錢。這肯定是我買的性價比最高的一本書了。
在此，我不想從別人書中抄出大段原話，拼出一篇文字，有這工夫還不如上網回貼子更有成就感，我寧愿將我的心得，用并不嚴密，但盡可能易懂的語言寫下。讓朋友們先對關系模型有個基本概念，使眾多像我這樣非科班出身的讀者多少了解一下事實真相，不至于在工作中有所不便。如果你想真正掌握關系型數據庫的數學模型，請讀一讀這本不流行的老書《關系數據庫》。當然，還有很多新近的正規教材也寫得很不錯，比如現在在我手邊的《database system concepts》（機械工業出版社）和《sql-3 參考大全》（機械工業出版社）。前兩本寫得更嚴謹一些，后一本是譯得不太好，有些關鍵地方讀著莫名其妙，不過總得來說還是本難得的好書。
言歸正傳，現在我們說說關系型數據庫到底是怎么一回事。我們先看一個表：
x y z
------------------
0 0 0
1 1 1
0 0 1
0 1 1
……
這個表存儲一個三維空間內的一些點。我們可以很清楚地看到，每一個完整的行，才代表一個點。僅定位某行某列，它并不能表達這個表所定義的信息結構。當我們向這個表中插入或刪除數據，它仍代表三維空間內的點集。但如果我們增加一列t（time)呢？那一切全變了，它不再是三維空間了，現在，這個表中存儲的是四維的信息了（讀過相對論的朋友應當了解，相對論中的時空就是一個四維坐標系）。刪除一列呢？比如z列，現在我們面對的就是x-y 平面了，這是一個二維坐標系。也就是說，在表中刪除或增加或修改若干列，并不會改變這個表所代表的意義。而修改或增刪列，就會改變表的結構，表所代表的意義也就不同于以前了。表的行和列，并不是平等的！我們不能簡單地把它理解為一個平面！相反，我認為，將表的結構理解為一個代數空間更合適，這樣，表中的每一行是這個代數空間中的一個點，那么當前表中的信息就形成了這個空間中的一個點集。當然，這個集合還可有其它的約束條件，下面我們從關系模型說起。
在嚴格意義上的關系模型中，一個關系模式，包括關系名、有限屬性集、屬性值域、屬性列到值域的映射、完整性約束和屬性間依賴。對應數據庫中的結構，通常一個關系模式對應一個或多個表和視圖。這些表和視圖有其各自包括的列，而列有列名、列的數據類型、表和視圖的主鍵約束、外鍵約束、檢查、斷言、觸發器（在sql server2000中，已可以在視圖中定義索引和觸發器，再加上視圖本身的 sql腳本，視圖以可以定義為一個完整的關系模式）。一個簡單的關系模式可以只由一個表構成，而多個元組（表或視圖）組成的關系，其相互的關聯由外鍵和觸發器來完成。在這個定義中，關系中的各個列（也就是說關系的模式）可以有很強的依賴性。比如某些列有主鍵約束，另一些列有引用外鍵。而行與行之間（也就是說關系之間）的依賴只存在于兩種情況——外鍵和觸發器。其中外鍵可以表達為模式上的（也就是列之間的）依賴。例如以下訂單系統，它由客戶表，訂單表和
create table customers(
customerid int not null,
firstname char(20),
lastname char(20),
city varchar(30),
constraint pk_customer primary key(customerid)
)
create table goods(
id int not null,
name char(20) not null,
number int,
price money,
constraint pk_good primary key(id))
create table orders(
orderid int not null,
customerid int not null,
orderdate datetime,
constraint pk_order primary key(orderid),
constraint fk_customer foreign key (customerid)
references customers(customerid))
create table items(
itemsid int not null,
orderid int not null,
number int not null
constraint pk_item primary key(itemsid),
constraint fk_good foreign key (itemsid)
references goods(id),
constraint fk_order foreign key (orderid)
references orders(orderid)
)
以上一表中，一位客戶可以有多張訂單，訂單的訂戶依賴客戶表。一張訂單可以有多個條目，明細條目又依賴于訂單和商品的存在。這四個表就構成一個關系模式，四個表都有其主鍵，表中的其它列依賴于主鍵列。表之間的外鍵引用則構成了表之間的依賴關系。由此聯接起了整個模式。每一個完整的訂單，包括orders表中的訂購信息和items表中的明細，形成一個關系。而一個用戶和他的訂單，又可以形成一種新的關系，這些關系的模式，可以由sql語句來表達，這里不詳細講了，朋友們可以試一下，很簡單的聯接查詢而已。我們可以看到，這個典型的關系中，信息的內容之復雜，遠遠超出了“幾個二維平面表”所能定義的?！皫в袕娂s束條件關聯的若干代數空間點集”可能更好一些。甚至，我們還可以在其上定義更強的約束，比如用一個觸發器保證用戶的訂購數在某一范圍內。當我們增刪訂單，存貨甚至客戶時，由于強有力的約束存在，保證了每個關系仍是完整的?？闪械亩x本身就是關系模式的一部分，如果我們改變或增刪了列，修改的是整個模式。至少一個代數空間，被我們改變了。這也就是行和列的區別。當然，只定義一個表，不給它加以任何約束，在技術上是允許的，但這樣的表不能稱為一個關系。它甚至不能保證最基本的關系完整性。如以前的文章所示，這樣的表輕易就可以插入重復數據，而這些不能互相區別的數據并不能給我們更多的信息。這種沒有約束的表在實用中應當嚴格限制于臨時表，不應在其它任何場合出現。
希望讀了這篇文章的朋友，能夠不再犯我當初常初的錯誤，建立一個又一個沒有任何約束的表，存入不可靠的數據。我們應當把信息的結構和關系模型直接表達在數據庫的設計中，這才是關系型數據庫的意義所在。這一次幾乎沒有可執行的代碼，可能讀者們會有意見。不過真心祝大家能理解我的意思，在關系型數據庫的世界中更輕松自如地工作。如果您有批評、表揚、指導，我在這里專心地聽取，謝謝您的支持。我在書中專注于sql server 和interbase，希望有oracle或db2等其它數據庫系統的高手與我合作，完成本書的不同版本內容，與我分享勞動的艱辛和成功的喜悅。
