SQL與關聯式數據庫理論：如何編寫健壯的SQL代碼(原書第2版)（簡體書）

對于數據庫管理與開發人員來說，使用SQL時會到處遭遇困難和陷阱。只有深入理解關系理論，并將理論應用于實踐，才能避免這些困難和陷阱。本書作者深入闡述了關系理論，以嚴謹的態度對SQL與關系理論進行詳盡而深入的對比、討論和思考，并且使用大量示例和練習展示怎樣才能將關系理論正確地應用到SQL中，得到健壯的SQL代碼，為高級數據庫開發人員提供大量常見SQL問題的解決之道。
本書回答了如下問題：
為什么恰當的列命名非常重要？
數據庫中的null會讓你得到錯誤的答案。為什么？你又能做什么？
是否可以通過編寫一個SQL查詢找到在同一個部門每次任職都不足6個月的員工？
雖然SQL支持“量化比較”，但是最好不要使用。為什么？怎樣避免使用？
雖然約束至關重要，但大多數SQL產品都沒有恰當地對其提供支持。怎樣解決此種境況？
關系模型是在40多年前提出的，自那以后，數據庫理論和實踐一直在發展，本書作者利用數十年的研究給出了最新的SQL理論。

C．J．Date 是關系數據庫技術領域中非常著名的獨立撰稿人、講師、學者和顧問。他最著名的著作是《數據庫系統導論》，這本書已經銷售了大約85萬冊，并被世界范圍內的幾百所大學作為教材采用。他同時也是許多數據庫管理書籍的作者，包括國內引進出版的下列作品：《數據庫設計與關系理論》、《數據庫、類型和關系模型》和《深度探索關系數據庫:實踐者的關系理論》等。Date先生于2004年被選入計算行業名人堂（the Computing Industry Hall of Fame）。他因具有一流的將復雜的技術專題用一種清晰且很容易理解的方式加以解釋的能力而享有盛譽。

關系數據庫領域的經典之作，關系數據領域泰斗級人物40年經驗的結晶！

第1章
做好準備
My soul, sit thou a patient looker-on;
Judge not the play before the play is done;
Her plot hath many changes; every day
Speaks a new scene; the last act crowns the play.
——Francis Quarles: Emblems (1635)
SQL的關系化方法是本書的主題，或主題之一。當然，如果要充分地探討這個問題，僅僅探討SQL本身的內容是不夠的，還需要涉及關系理論的相關內容。盡管這一說明顯然適用于全書，但它特別適用于這第1章。所以，相對而言，本章只有很少的部分來講述關于SQL的內容。我所要做的就是回顧（在大多數情況下希望你無論如何也要掌握的）背景知識。之所以這樣做是因為，要建立一個起始點，或者說是為書中的后續內容奠定基礎。不過，就算如我所愿，你已經熟悉了本章內容，我也誠摯地建議你不要略過本章。你應該知道你需要知道的一切（如果你能夠了解我的用意的話）；尤其是，你需要確定自己具有理解本書后續章節內容的所有預備知識。事實上，我建議你在全書中都不要因為自以為熟悉某個主題而略過對該主題的討論。比方說，你真的絕對確定自己知道關系理論術語 “鍵”（Key）或者“連接”（join）注1指的是什么嗎？
1.1 關系模型被嚴重地誤解了
任何學科的專業人士都需要知道自己所在專業的基礎。所以，如果你是數據庫領域的專家，就需要知道關系模型，因為它是數據庫領域的基礎（至少是基礎的主體）。當今，不論是商業化的應用培訓還是學術化的理論課程，任何課程都至少提到關系模型的內容，但是大多數教學從結果上看都很糟。可以確定的是，數據庫領域中的大多數人并沒有很好地理解關系模型。造成這種情形的可能原因包括：
脫離實踐的關系模型教學。就是說，至少對于初學者，理解關系模型知識的關聯性或關系模型所要解決的問題是很難的。
授課的教師本身并沒有充分理解或意識到關系模型知識內容的重要性。
在實踐中更可能存在的問題：就根本沒教關系模型，授課中取而代之的是SQL語言，或者SQL語言的一些方言（比如Oracle的SQL方言）。
所以這本書的目標讀者就是那些數據庫實踐人員，他們接觸過關系模型，但仍然缺乏本應具有的全部知識（尤其是SQL實踐人員）。這本書絕不是針對初學者而寫的；不過，它也不是一個進修課程。具體而言，我可以確定你確實知道一些關于SQL的知識，但是請容我在此冒昧地說一句，如果你關于關系模型的知識僅僅來源于你所掌握的SQL知識，那么恐怕你并很好地理解關系模型，而且你所知道的還有可能是錯的。我認為：SQL和關系模型不是一回事。這一點怎么強調都不過分不夸張地說，下面是一些SQL并不十分明確的關系化問題（下面的列表并不是全部的列表）：
數據庫、關系及元組的確切含義；
關系值和關系變量的區別；
謂詞和命題的關聯性；
屬性名稱的重要性；
完整性約束的關鍵角色；
信息原理及其重要性。
所有這些問題以及其他很多問題，都在這本書中進行了闡述。
我再說一遍：如果你對于關系模型的知識僅僅來源于你對于SQL的知識，那么你所知道的有可能是錯的。所以，你在閱讀本書過程中可能會得到一個結論：你不得不進行一些反學習（unlearning，即把以前學習到的錯誤知識忘掉并重新學習正確的知識，避免以前的錯誤知識產生不利影響——譯者注）。不幸的是，反學習是非常困難的。
1.2 關于術語的一些說明
在1.1節的關系化問題列表中，你可能意識到我使用了形式化術語“關系”（relation）、“元組”（tuple）及“屬性”（attribute）。SQL當然不使用這些術語，取而代之的是更“用戶友好的”術語：“表”（table），“行”（row），“列”（column）。只要有助于使知識更易于理解，我通常都會贊同使用更“用戶友好的”術語。然而，就當前的情況而言，我（遺憾地）認為它們沒有使知識更易于理解，而是曲解了知識并實際上損害了真正理解的形成。真相是，關系并不是表，元組并不是行而屬性也并不是列。盡管在某些非正式上下文中對術語的曲解（即關系是表，元組是行而屬性是列——譯者注）是可被接受的（事實上我自己也經常如此），但是我要說：只有當我們全都理解“用戶友好的”術語只是對于真相的近似而不能抓住事實本質時，它才是可接受的。換個說法：如果你確實理解真實情況，那么合理地使用“用戶友好的”術語是一個不錯的想法，但是如果以學習和領會真實情況為第一要義的話，你需要使用正式的術語。因此，在這本書中，我將會使用正式用語（至少在我講述與SQL相對的關系模型時會是如此），并在合適的時機為這些正式術語給出精確定義。相反，在SQL上下文中，我會使用SQL的專用術語。
關于術語的另外一點是：盡管我已經說過SQL試圖簡化一個術語集合，但我必須強調的是，它使另外一個術語集合復雜起來。我指的是SQL對于術語“運算符”（operator）、“函數”（function）、“過程”（procedure）、 “程序”（routine）和“方法”（method）的使用，所有這些本質上代表同一個事物（即使有差別也微乎其微）。在這本書中我會全程使用術語“運算符”；比如，我會明確地將“=”（等值比較）、“:=”（賦值）、“+”（加）、DISTINCT、JOIN、SUM和GROUP BY（等等）都稱作運算符。
需要注意的是，說到SQL，請允許我提醒你（如前言所述）：除非是在極為有限的幾個上下文中，否則本書中的SQL指的都是標準版本的SQL語言。注2
然而：
標準所用的術語有時并不適合使用。此時，我一般會使用我自己的術語。比如，我會使用“表表達式”（table expression）代替SQL標準中的術語“查詢表達式”（query expression），這是因為：首先，這種表達式表示的值實際是表而不是查詢；其次，查詢并不是使用這種表達式涉及的唯一上下文（事實上，SQL標準中確實使用了術語“表表達式”，但是用的很不恰當；具體來說， “表表達式”在標準中用來指代SELECT表達式中SELECT子句后面的部分）。
緊接著上一點，（不論是從我的觀點還是從標準的觀點出發）在SQL中并不是所有的“表表達式”在其本應合法的所有上下文中都是合法的。尤其是，盡管一個顯式JOIN調用肯定表示一個表，但它不能作為獨立的（stand alone）表表達式出現（即，不能獨自出現在嵌套查詢中的最外層），也不能作為構成子查詢的括號內部表表達式出現（參見第12章）注3。請注意，這些說明適用于書中很多單獨的討論，但不斷地重復這些說明是很乏味的，我也不會那么做（不過，在第12章的BNF語法部分我會再次提及它們）。
我忽略了SQL標準中被認為是晦澀難懂的部分，尤其是那些不是SQL標準所謂的核心SQL部分或是與關系化處理本身無緊密聯系的部分。這些內容的具體例子包括：分析或窗口（OLAP）函數，動態SQL，臨時表，以及用戶自定義類型的細節。
出于某些原因，我使用了不同于SQL標準的注釋風格。具體來說，我使用由“/*”及“*/”分隔符包圍的斜體字符串來顯示注釋。