《SQL Story》摘錄五——關係真相 (轉)

《SQL Story》摘錄五——關係真相 (轉)[@more@] 

關係的真相

長期以來，我們習慣了稱關係型中的表為二維表。因為它有行和列，很容易我們就可以把它同一個二維平面聯絡起來，但事實上，這並非關係型資料庫的初衷，也並非符合關係模型的設計。其實長久以來，我對此也只有一個很模糊的概念，對平面表的觀點雖有懷疑，卻一直無從驗證。直到有一天，翻出一本老書——《關聯式資料庫》（石樹剛、鄭振楣編著，清華大學出版社，1993年），這本老書沒有什麼流行的新噱頭，卻滿滿當當地淨是數學理論。這本書讀起來並不是很誘人，不過的確很嚴謹，澄清了我的很多不明之處。也激勵我找來各種權威材料重頭學起。薄薄一本書，定價只有9.9元，想想這應當是我在上學時，從舊書攤上買的，可能當時只花了不到五元錢。這肯定是我買的價效比最高的一本書了。

在此，我不想從別人書中抄出大段原話，拼出一篇文字，有這工夫還不如上網回貼子更有成就感，我寧願將我的心得，用並不嚴密，但儘可能易懂的語言寫下。讓朋友們先對關係模型有個基本概念，使眾多像我這樣非科班出身的讀者多少了解一下事實真相，不至於在工作中有所不便。如果你想真正掌握關係型資料庫的數學模型，請讀一讀這本不流行的老書《關聯式資料庫》。當然，還有很多新近的正規教材也寫得很不錯，比如現在在我手邊的《DATABASE SYSTEM CONCEPTS》（機械工業出版社）和《-3 參考大全》（機械工業出版社）。前兩本寫得更嚴謹一些，後一本是譯得不太好，有些關鍵地方讀著莫名其妙，不過總得來說還是本難得的好書。

言歸正傳，現在我們說說關係型資料庫到底是怎麼一回事。我們先看一個表：

X Y Z

------------------

0 0 0

1 1 1

0 0 1

0 1 1

……

這個表一個三維空間內的一些點。我們可以很清楚地看到，每一個完整的行，才代表一個點。僅定位某行某列，它並不能表達這個表所定義的資訊結構。當我們向這個表中插入或刪除資料，它仍代表三維空間內的點集。但如果我們增加一列T（time)呢？那一切全變了，它不再是三維空間了，現在，這個表中儲存的是四維的資訊了（讀過相對論的朋友應當瞭解，相對論中的時空就是一個四維座標系）。刪除一列呢？比如Z列，現在我們面對的就是X-Y 平面了，這是一個二維座標系。也就是說，在表中刪除或增加或修改若干列，並不會改變這個表所代表的意義。而修改或增刪列，就會改變表的結構，表所代表的意義也就不同於以前了。表的行和列，並不是平等的！我們不能簡單地把它理解為一個平面！相反，我認為，將表的結構理解為一個代數空間更合適，這樣，表中的每一行是這個代數空間中的一個點，那麼當前表中的資訊就形成了這個空間中的一個點集。當然，這個集合還可有其它的條件，下面我們從關係模型說起。

在嚴格意義上的關係模型中，一個關係，包括關係名、有限屬性集、屬性值域、屬性列到值域的對映、完整性約束和屬性間依賴。對應資料庫中的結構，通常一個關係模式對應一個或多個表和檢視。這些表和檢視有其各自包括的列，而列有列名、列的資料型別、表和檢視的主鍵約束、外來鍵約束、檢查、斷言、（在2000中，已可以在檢視中定義和觸發器，再加上檢視本身的 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語句來表達，這裡不詳細講了，朋友們可以試一下，很簡單的聯接查詢而已。我們可以看到，這個典型的關係中，資訊的內容之複雜，遠遠超出了“幾個二維平面表”所能定義的。“帶有強約束條件關聯的若干代數空間點集”可能更好一些。甚至，我們還可以在其上定義更強的約束，比如用一個觸發器保證使用者的訂購數在某一範圍內。當我們增刪訂單，存貨甚至客戶時，由於強有力的約束存在，保證了每個關係仍是完整的。可列的定義本身就是關係模式的一部分，如果我們改變或增刪了列，修改的是整個模式。至少一個代數空間，被我們改變了。這也就是行和列的區別。當然，只定義一個表，不給它加以任何約束，在技術上是允許的，但這樣的表不能稱為一個關係。它甚至不能保證最基本的關係完整性。如以前的文章所示，這樣的表輕易就可以插入重複資料，而這些不能互相區別的資料並不能給我們更多的資訊。這種沒有約束的表在實用中應當嚴格限制於臨時表，不應在其它任何場合出現。

希望讀了這篇文章的朋友，能夠不再犯我當初常初的錯誤，建立一個又一個沒有任何約束的表，存入不可靠的資料。我們應當把資訊的結構和關係模型直接表達在資料庫的設計中，這才是關係型資料庫的意義所在。這一次幾乎沒有可的程式碼，可能讀者們會有意見。不過真心祝大家能理解我的意思，在關係型資料庫的世界中更輕鬆自如地工作。如果您有批評、表揚、指導，我在這裡專心地聽取，謝謝您的支援。我在書中專注於SQL Server 和InterBase，希望有或2等其它資料庫系統的高手與我合作，完成本書的不同版本內容，與我分享勞動的艱辛和成功的喜悅。