《視圖更新與關系資料庫理論》——1.6 小結

本節書摘來自異步社群出版社《視圖更新與關系資料庫理論》一書中的第1章，第1.6節，作者：【美】c.j. date（達特），更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

抛磚引玉到此就要告一段落了。我們所用到的這個例子非常簡單，從中得出的結論也是顯而易見的。而其實我是想通過這個例子引出下面的理念，就是根據實際的定義把視圖看作與特定的表相附生的基表，這對于整體考慮如何解決視圖更新的問題是很有建設性的。我認為它不僅具有建設性，而且是一種“邏輯上正确”的方法。[8]總體思路如下。

1．視圖定義表達式包含了某些特定的限制。例如，視圖ls（“london suppliers”）的視圖定義表達式表明了ls等同于表s中city值為london的限制。

2．這種限制反過來表明了特定的補償性操作（如那些為了避免違反完整性限制，而需要在使用者自行請求的更新之外進行的操作）。舉例來說，正如前面講到的，表s、ls和nls的限制就代表相應的級聯删除和級聯插入。

這裡我要強調第2點——這點很重要，就是在某些狀況下，補償性操作可以由相關視圖的定義表達式決定。換句話說，這樣的操作不需要顯式指定，也不需要給已經超負荷的dba[9]增加工作負擔。對于這個問題和其他在本章中引出的問題，我都會在後面的章節進行更詳細的探讨。

最後，如果你像大多數人一樣跳過了前言直接開始閱讀第1章，那麼現在是時候翻回去閱讀前言了，這對你繼續閱讀下面的章節會很有幫助。前言包含了本書的整體結構，同時還闡明了将要在下面的章節使用的重要的技術性假設，是以需要你對它們有所了解。　　

[1]　我在本章這個介紹性的章節使用sql和sql風格的文法是因為大家都對它比較熟悉，盡管它并不是我喜歡的風格，并且（更重要的是）事實上它可能會讓這個抛磚引玉的例子更不容易解釋清楚。

[2]　在本書中我都使用未經認證的“鍵”這個詞來表示候選鍵，而不是一個特定的主鍵。實際上，在第2章中就會介紹到的“tutorial d”對于主鍵和其他鍵在文法上并沒有差別。但是，由于大家使用習慣的原因，我在圖例中都使用雙下畫線來表示主鍵屬性，如圖1.1所示。

[3]　我在前言的時候就聲明過，在本書中我将使用《sql and relational theory》作為簡寫來引用我的另一本書《sql and relational theory: how to write accurate sql code》（第2版，奧萊利出版，2012）。

[4]　正是由于這個原因，更真實一點版本的視圖ls很可能會去掉city屬性。在這裡我選擇不這樣做，是為了讓這個例子更簡單易懂。

[5]　曾經有一位審閱者問我，為什麼我在這裡要選擇“補償性操作”這個詞。當時我自己認為這個答案很明顯，不過為了以防萬一，我還是在這裡做一個說明：之是以我把這些操作稱為“補償性”的，是因為它們都會導緻第2次更新發生來補償第1次的效果（當然是大體上來講）。

[6]　級聯删除通常都被認為是使用一個特定的外鍵限制，但是補償性操作的概念其實更加通用，并且适合很多種限制。

[7]　我假設有些使用者“可能”會被允許進行這樣的操作，如果他或她在操作被拒絕的時候能夠接受錯誤資訊顯示的隻是“因為系統就是這麼說的”，而沒有更進一步的解釋。關于這一點的進一步讨論詳見第4章。

[8]　 在此感謝david mcgoveran，他在多年前啟發我思考這些問題。

[9]　 dba=database administrator，也就是資料庫管理者。

本文僅用于學習和交流目的，不代表異步社群觀點。非商業轉載請注明作譯者、出處，并保留本文的原始連結。