Relation 是一組欄位固定、由若干列構成的資料集合。列（row）指橫向的一筆資料，欄（column）指縱向的一個位置——這是台灣的用法，簡體中文的 SQL 資料多半用「行」指這裡的列、用「列」指這裡的欄，兩套剛好對調。資料表是它的一種，而查詢過程中產生的中間結果也是——outer join 產出的那一份就是，它比來源表多了幾列補 NULL 的。

這個詞值得單獨認一次，因為中文的「關係」在日常語言裡指人或事物之間的聯繫，與這裡的意思無關。它是 relation 的譯名，指的是那個集合本身。

概念位置

把中間結果也當成關係，多層查詢才讀得動。 書店的 FROM 顧客 LEFT JOIN 訂單 走完之後，得到的那一份有姓名與訂單編號兩種欄位、四列（佳穎兩列、宗翰與雅文各一列而訂單編號是 NULL）。它沒有對應的資料表，沒有名字，也不會被寫進磁碟——而後續的 WHERE、GROUP BY 全部對它操作，不對原本那兩張表操作。

這個性質讓查詢可以層層套疊：一個連接的輸出可以當下一個連接的輸入，子查詢的輸出可以當外層的來源。也因為每一層的輸入與輸出都是同一種結構，query optimizer 才有重排的空間——只要最後產出的關係一樣，中間怎麼組合都合法。

Outer join 是這組運算裡的一個，它產出的關係比來源表多了補 NULL 的那些列。

可觀察訊號與例子

判斷現在處理的是不是還是原表，看列數與欄位。連接之後列數可能變多（一列配到多列就複製一次）、欄位是兩邊合起來的、還可能出現來源表裡沒有的空缺。三者任一成立就表示已經離開原表了。

設計責任

多層查詢的判讀方式是逐層檢查每一層的欄位與列，而不是想像最後那一張表。把每個 JOIN 都想成「兩張表配對」在第三張表之後就失準，因為那時左邊已經是前兩層累積出來的關係。