本節書摘來自異步社區出版社《視圖更新與關系數據庫理論》一書中的第2章，第2.1節，作者：【美】C.J. Date（達特），更多章節內容可以訪問云棲社區“異步社區”公眾號查看。
2.1 關系和關系變量
每一個關系都有一個“關系頭”和一個“關系體”，其中關系頭是一系列狀態和特征，而關系體則是符合關系頭的一系列數組。讓我們再次使用“供應商與零部件”數據庫（如圖2.1所示，與第1章的圖1.1完全一樣），供應商關系的關系頭是{SNO CHAR, SNAME CHAR, STATUS INTEGER, CITY CHAR}的集合，我們假設在這里確定屬性SNO、SNAME、STATUS和CITY分別被定義為CHAR、CHAR、INTEGER和CHAR這幾種數據類型，而這個關系的關系體是對于供應商S1、S2、S3、S4和S5的數組的集合。這里要注意，每個數組都符合特定對應的關系頭的要求，因為它們每個都只包含一個值，分別對應屬性SNO、SNAME、STATUS和CITY（并且沒有其他內容）。注意：其實更準確，也是更正確的說法應該是每個數組都“擁有”特定對應的關系頭，因為在一個關系中，數組是應當有關系頭的。
每個關系也都擁有（或者說屬于）一個特定的“類型”，而這個特定的類型其實完全是由特定的關系頭決定的。因此，我們在Tutorial D中表示一個給定的關系的類型時，其實就是關鍵詞“RELATION”后面跟著適用的關系頭。舉例來說，供應商關系的類型就是：
RELATION { SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR }
接下來我要說，關系本身和關系變量之間存在著邏輯差異[3]。現在我們再來看一下圖2.1。這張圖呈現了3個關系，也就是說，這3個關系有可能在特定的時間里同時存在于數據庫中。但是，如果我們換個時間再來看數據庫的話，很有可能我們看到的就是其他的關系。換句話說，S、P和SP都是變量，準確地說是關系變量，它們跟其他變量一樣，值會隨時變化。那么既然它們是具體的關系變量，那么在給定的時間內，它們的值就是關系值。不過要注意，對于一個給定的關系變量來說，合法的值必須都屬于同樣的關系類型，例如，這些值必須都有相同的關系頭，而這個關系類型和關系頭也因此被看作這個關系變量的類型和頭。
為了更全面地闡述前面提到的想法和理念，我們假設關系變量S擁有和圖2.1所示相同的值，我們再假設現在要刪除在倫敦的供應商的數組。
DELETE ( S WHERE CITY = ‘London’ ) FROM S ;
關系變量S現在應改變成如下的樣子。
從概念上來講，S原來的值（當然是個關系值）已經被一個新的值（另一個關系值）整體替換掉了。現在我們來看，原來的值（有5個數組）和新的值（有3個數組）似乎看起來很像，但是其實它們是完全不同的值。我們用“DELETE”作為剛才操作語句的縮寫[4]，實際上在這里它等價于下面的“關系賦值”。
S := S WHERE NOT ( CITY = ‘London’ ) ;
或者等價于：
S := S MINUS ( S WHERE CITY = ‘London’ ) ;
那么經過所有這些賦值操作會發生什么呢？我們會看到（a）在右側的源表達式是需要運算的，而（b）運算得出的值就會被賦給等式左側的目標變量，于是就會產生我們剛剛講過的效果。
因此DELETE是一個特定關系賦值的縮寫，當然，對于INSERT和UPDATE來說也是相似的，它們從本質上來說也是對于特定的關系賦值的一個縮寫。從邏輯上來講，實際上關系賦值是我們唯一真正需要的更新操作（這是我在下一節要重點說明的觀點）。
綜上所述：關系本身和關系變量之間存在著邏輯差異。也正因為如此，我在之后也會很謹慎地區分它們二者，當我用“關系值”這個詞的時候我就是在指關系的值，而當我說“關系變量”這個詞的時候指的就是關系的變量。不過，我大多數時間還是會用“關系”作為“關系值”的簡稱（就好像我們用“整數”來作為“整數值”的縮寫一樣）。并且我大多數時間會用“relvar（關系變量，譯者注）”來作為“關系變量”的縮寫，例如，我會說“供應商與零部件”數據庫包含3個“關系變量”（更具體一點來說，是3個“真實”或基礎關系變量，之所以這么說是為了把它們和“虛擬”關系變量或者視圖區分開）。
基礎關系變量定義
下面是Tutorial D對于目前例子中使用的3個關系變量的定義，以供后面參考引用。
VAR S BASE RELATION{ SNO CHAR , SNAME CHAR , STATUS INTEGER , CITY CHAR }KEY { SNO } ;
VAR P BASE RELATION{ PNO CHAR , PNAME CHAR , COLOR CHAR , WEIGHT RATIONAL , CITY CHAR }KEY { PNO } ;
VAR SP BASE RELATION{ SNO CHAR , PNO CHAR , QTY INTEGER }KEY { SNO , PNO }FOREIGN KEY { SNO } REFERENCES SFOREIGN KEY { PNO } REFERENCES P ;
出于本書的目的，我選擇忽略Tutorial D在目前定義中并不包含明確的FOREIGN KEY語法的這個事實。
