《視圖更新與關系資料庫理論》——2.3 一緻性限制

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

每個關系變量都受制于一系列一緻性限制，我們也可以把它們簡稱為限制。首先，我們在“關系和關系變量”這一節中已經知道，任何一個給定的關系變量都被限制為一個确定的類型（具體來說，是一個确定的關系類型），也就是說，在定義關系變量的時候，這個類型也就确定了。例如，我們再來看看供應商關系變量s的定義。11[11]

如你所見，這個定義清晰地表明了關系變量s屬于類型relation {sno char, sname char, status integer, city char}。而且，具體來看它還表明了屬性sno、sname、status和city分别是char、char、integer和char這幾種資料類型。注意：後一種限制—給每個獨立屬性的限制，有時候被稱為“屬性”限制，本段就是一個很好的例子。

我再次重申一遍，任何一個關系變量（任何一個屬性更是如此）都被限制為某種類型。但是關系變量同時也會被很多其他的限制所限制，這些限制通常都是使用tutorial d的表達式明确寫出constraint聲明進而實作的。12[12]下面舉幾個簡單的例子希望能幫助大家了解（如果你需要更多的解釋說明，請參閱《sql and relational theory》）。

現在“第三宣言”中要求所有的限制都必須在聲明邊界上被滿足（“立即檢查”）。換句話說，從邏輯上講，對于任何有潛在可能會違反“宣言”的聲明，在它限制時都會被立刻重新檢查一次。13[13]或者我們也可以說得有趣一點，它們是“在分号處”被檢查的。是以，與sql标準版本或其他特定的sql産品不同，一緻性檢查從來都不會被推遲到執行結束或者執行commit（送出）操作的時候。

最後請注意，有時為了友善，我們對于給定的關系變量r的“全局”限制，這裡要強調是針對“關系變量”的全局限制，指的是所有涉及到關系變量r的限制的邏輯and（與）。而有時為了友善，我們對于給定的資料庫的“全局”限制，這裡要強調是針對“資料庫”的全局限制，指的是所有涉及到該資料庫中任意關系變量的限制的邏輯and（與）。

更新每次都是集合更新

盡管這個觀點盡人皆知，但還是值得我們再次強調，在關系模型中的每次更新都是集合更新（更好的說法是：每次都是“關系”更新）。我們換句通俗點的話來說，insert操作給目标關系變量插入了一系列數組，delete操作将一系列數組從目标關系變量中删除。而更廣義地來講，關系指派将一系列數組值賦給了目标關系變量。當然，我們經常會這麼說（例如）“插入某某數組”，确實，我在這本書裡也會時不時這樣說，但是這種說法确實是很不嚴謹（雖然比較友善）的。不論如何，這裡我要說的重點在于一緻性限制的檢查要在“所有的”更新步驟（包括與之相關的補償性操作，如果有的話）全部完成後進行。換句話說也就是從邏輯上講，一個集合級别的更新一定不能被當作一系列單獨數組級别的更新來對待。

兩個重要的原則

現在我要在此特别強調2個重要的原則，這2個原則對于鞏固更新（尤其包括視圖更新）的概念非常重要。第1條原則也被稱為黃金法則。

定義：黃金法則規定所有的資料庫都不能違反它自己的全局資料庫限制。

顯然，由此條法則我們可以立刻推導出下面的規則：所有的關系變量都不能違反它自己的全局關系變量限制。簡單來講，就如同我所強調過的，限制必須在聲明邊界上被滿足。我再次重申，請尤其注意，這條法則無論是對視圖，還是對基礎關系變量，都同樣适用。

第2條原則被稱為“指派原則”。

定義：“指派原則”規定當值v被賦給變量v之後，比較表達式v=v的結果必須為ture。

這條原則适用于所有的指派操作，實際上，相信你也察覺到了，它基本上就是指派本身的“定義”，不過就本文而言，它尤其能夠适用于關系指派。當然也請再一次注意，這條法則無論是對視圖，還是對基礎關系變量，都同樣适用。