1981年ACM圖靈演講:關聯式資料庫：生產力的實用基礎

1981 年 ACM 圖靈獎演講於 1981 年 11 月 9 日，加州洛杉磯，ACM '81 大會發表

1981 年 ACM 圖靈獎由 ACM 主席 Peter Denning 於 1981 年 11 月 9 日在加州洛杉磯舉行的 ACM 年會上頒發給 IBM San Jose Research Laboratory 的 IBM Fellow Edgar F. Codd。這是協會授予對計算機領域做出技術貢獻的最高獎項。

Codd 因其「對資料庫管理系統的理論與實踐做出基礎性和持續性的貢獻」而被 ACM General Technical Achievement Award Committee 選中。作為關聯式模型的創始人，Codd 在關聯式代數、關聯式演算和關聯正規化的發展方面做出了進一步重要的貢獻。

Edgar F. Codd 於 1949 年加入 IBM，為 Selective Sequence Electronic Calculator 準備程式。從那時起，他在計算機領域的工作涵蓋了計算機的邏輯設計 (IBM 701 和 Stretch)、管理加拿大的一個計算機中心、領導開發第一個具有通用多程式能力的作業系統之一、為自我複製自動機的邏輯做出貢獻、開發用於軟體規範的高階技術、創建和擴展資料庫管理的關聯式方法，以及為關聯式資料庫的臨時使用者開發英語分析和綜合子系統。他也是 ACM Monographs Series 中早期的一本書《Cellular Automata》的作者。

Codd 在英國牛津大學獲得數學學士和碩士學位，並在密西根大學獲得計算機與通訊科學碩士和博士學位。他是 National Academy of Engineering (USA) 的成員，也是 British Computer Society 的Fellow。

ACM 圖靈獎每年頒發一次，旨在紀念為計算機科學做出重大貢獻的英國數學家 A. M. Turing。

關聯式資料庫：生產力的實用基礎

E. F. Codd IBM San Jose Research Laboratory

眾所周知，終端使用者對新應用的需求增長速度超過了資料處理部門實施相應應用程式的能力。解決這個問題有兩種互補的方法（而且這兩種方法都是必需的）：一種是讓終端使用者直接接觸儲存在計算機中的資訊；另一種是提高資料處理專業人員開發應用程式的生產力。鮮為人知的是，一項單一技術，關聯式資料庫管理，為這兩種方法提供了一個實用的基礎。本文將解釋原因。

在闡述這個生產力主題時，值得注意的是，現在是時候在關聯式和非關聯式資料庫系統之間畫出一條非常清晰的界線，以免「關聯式」標籤被誤導使用。畫出這條界線的關鍵是一個稱為「關聯式處理能力」的東西。

CR Categories and Subject Descriptors: H.2.0 [Database Management]: General; H.2.1 [Database Management]: Logical Design-data models; H.2.4 [Database Management]: Systems General Terms: Human Factors, Languages Additional Key Words and Phrases: database, relational database, relational model, data structure, data manipulation, data integrity, productivity

Communications February 1982 of Volume 25 the ACM Number 2

引言

人們普遍承認，在開發商業和工業應用的「運行代碼」方面存在生產力危機。終端使用者對新應用的需求增長速度超過了資料處理部門實施相應應用程式的能力。在六十年代末和七十年代初，計算機領域的許多人曾希望資料庫管理系統（通常簡稱為 DBMS）的引入能夠顯著提高應用程式設計師的生產力，因為它解決了他們在處理輸入和輸出檔案方面的許多問題。DBMS（以及資料字典）似乎在資料控制方面非常成功，它們確實將許多檔案處理細節從應用程式設計師的考慮範圍中移除。那麼為什麼它們未能提高生產力呢？

主要有三個原因： (1) 這些系統為應用程式設計師帶來了許多與其資料檢索和操作任務無關的概念，迫使他們在結構細節上思考和編碼在不必要的低層次（CODASYL DBTG 的「擁有者-成員集合」就是一個突出的例子）†； (2) 沒有提供同時處理多個記錄的命令——換句話說，DBMS 不支援集合處理，結果程式設計師被迫思考和編寫通常不必要的迭代迴圈（這裡我們使用「集合」一詞的傳統數學意義，而不是 CODASYL DBTG 的連結結構意義）； (3) 對於終端使用者直接與資料庫互動，特別是意外性質的互動，認識不足——假設查詢能力是可以隨時添加到 DBMS 的東西。

回顧六十年代末的資料庫管理系統，我們很容易觀察到，程式設計師的（邏輯）資料視圖與儲存中資料的（物理）表示之間沒有明確的區分。即使所謂的邏輯層次通常提供免於以儲存位址和位元組偏移表示的位置表達式，但許多面向儲存的概念仍然是這個層次不可或缺的一部分。

† CODASYL DBTG 擁有者-成員集合問題的關鍵在於，它將三個正交的概念結合在一個結構中：一對多關係、存在依賴性和應用程式需要遍歷的使用者可見連結結構。這三個概念中的最後一個對應用程式設計師施加了沉重且不必要的導航負擔，也對終端使用者構成了無法克服的障礙。

要求程式設計師沿著存取路徑導航以達到目標資料（在某些情況下必須直接處理儲存中的資料佈局，在其他情況下必須跟隨指標鏈）對開發生產力造成了巨大的不利影響。此外，無法在儲存中稍微改變佈局而不必同時修改所有依賴於先前結構的程式。引入索引也可能產生類似的效果。結果是，投入了太多的人力進行持續（且可避免的）應用程式維護。

另一個後果是，這些系統的安裝通常非常緩慢，因為在啟動資料庫之前，需要花費大量時間學習系統並規劃資料在邏輯和物理層次的組織。這種預規劃的目標是「一次做好，一勞永逸」，以避免隨後需要改變資料描述，進進而迫使應用程式程式碼改變。當然，即使當時已知資料庫設計的健全原則（而當時當然不知道），這種目標也是一個幻覺。

為了展示關聯式資料庫管理系統如何避免上述三個陷阱，我們將首先回顧關聯式模型的動機並討論其一些特點。然後我們將對基於該模型的系統進行分類。在此過程中，我們將強調應用程式設計師的生產力，儘管終端使用者的好處同樣巨大，因為關於關聯式資料庫對終端使用者的價值已經說了很多並得到證明（參見 [23] 及其中引用的論文）。

動機

促成關聯式模型研究工作的最重要動機是提供資料庫管理（包括資料庫設計、資料檢索和資料操作）的邏輯和物理方面之間清晰明確的界線。我們將這稱為資料獨立性目標。

第二個目標是使模型結構簡單，以便所有類型的使用者和程式設計師都能對資料有共同的理解，從而能夠相互溝通關於資料庫的事情。我們將這稱為可溝通性目標。

第三個目標是引入高階語言概念（但不是特定的語法），使用戶能夠一次處理大量資訊。這意味著為集合導向處理提供基礎（即能夠在單一語句中表達同時處理多個記錄集合的能力）。我們將這稱為集合處理目標。

還有其他目標，例如為資料庫組織和管理提供健全的理論基礎，但這些目標與我們當前的生產力主題相關性較小。

關聯式模型

為了滿足這三個目標，有必要捨棄所有那些終端使用者不熟悉（例如，重複組、連結結構）的資料結構概念，並重新審視資料的位址定址。位置概念始終在計算機位址定址中扮演重要角色，從插線板位址定址，然後是絕對數字位址定址，相對數字位址定址，以及具有算術屬性的符號位址定址（例如，組合語言中的符號位址 A + 3； Fortran、Algol 或 PL/I 陣列 X 中元素的位址 X(I + 1, Y - 2)）。在關聯式模型中，我們用完全關聯式位址定址取代位置位址定址。關聯式資料庫中的每個資料都可以通過關係名稱、主鍵值和屬性名稱唯一地位址定址。這種形式的關聯式位址定址使用戶（是的，甚至程式設計師也一樣！）將 (1) 確定新資訊插入資料庫的細節位置和 (2) 在檢索資料時選擇適當的存取路徑留給系統。

關聯式資料庫中的所有資訊都由表格中的值表示（甚至表格名稱也至少在一個表格中以字串形式出現）。通過值而不是位置來位址定址資料，提高了程式設計師和終端使用者的生產力（序列中項目位置通常會改變，而且一個人很難跟蹤，尤其是當序列包含許多項目時）。此外，程式設計師和終端使用者都以相同的方式位址定址資料，這在很大程度上滿足了可溝通性目標。

選擇 n 元關係作為關聯式模型的單一聚合結構，是因為透過適當的運算子和適當的概念表示（表格），它滿足了上述所有三個目標。注意，n 元關係是一個數學集合，其中行的順序無關緊要。

有時會出現以下問題：為什麼稱它為關聯式模型？為什麼不稱它為表格模型？原因有二：(1) 在關聯式模型引入時，資料處理領域的許多人認為兩個或更多對象之間的關係（relationship）必須由連結資料結構表示（所以選擇這個名稱是為了反駁這種錯誤觀念）；(2) 表格比關係處於更低的抽象層次，因為它們給人一種位置（陣列類型）位址定址適用（這與 n 元關係不符）的印象，而且它們未能顯示表格的資訊內容與行順序無關。然而，即使存在這些小缺陷，表格仍然是關係最重要的概念表示，因為它們是普遍理解的。

順帶一提，如果一個資料模型被認為是關聯式模型的嚴肅替代方案，它也應該為資料庫實例提供一個清晰定義的概念表示。這種表示有助於思考正在考慮的任何操作的影響。這是程式設計師和終端使用者生產力的要求。這種表示很少（如果有的話）在那些使用實體和關係等概念的資料模型中討論，或在函數式資料模型中討論。這些模型通常甚至沒有任何運算子！然而，它們可能對在建立新資料庫過程中遇到的某些類型的資料類型分析有用，尤其是在確定初步非正式組織的非常早期階段。這引出了問題：什麼是資料模型？

當然，資料模型不僅僅是一種資料結構，許多人似乎這麼認為。主要資料模型以其主要結構命名是很自然的，但這並非全部。

一個資料模型 [9] 至少包含以下三個組成部分： (1) 資料結構類型的集合（資料庫構建塊）； (2) 運算子或推理規則的集合，可以應用於 (1) 中列出的任何資料類型的有效實例，以從這些結構的任何部分以任何期望的組合方式檢索、衍生或修改資料； (3) 通用完整性規則的集合，這些規則隱含或顯式地定義了一致的資料庫狀態或狀態變化或兩者——這些規則是通用的，因為它們適用於使用此模型的任何資料庫（順帶一提，它們有時可以表達為插入-更新-刪除規則）。

關聯式模型在這種意義上是一個資料模型，並且是第一個被定義的此類模型。我們不打算在這裡提供關聯式模型的詳細定義——原始定義出現在 [7] 中，改進的定義在 [8] 的第 2 和 3 節中。其結構部分包括域、各種程度的關係（以表格作為其主要概念表示）、屬性、元組、候選鍵和主鍵。在主要表示下，屬性變為表格的列，元組變為行，但就資料庫表格而言，沒有一個列跟隨另一個或一行跟隨另一個的概念。換句話說，這些表格中列的從左到右順序和行的從上到下順序是任意且無關緊要的。

關聯式模型的操作部分由關係代數運算子（選擇、投影、連接等）組成，這些運算子將關係轉換為關係（因此將表格轉換為表格）。

完整性部分包括兩個完整性規則：實體完整性和參考完整性（有關後者的近期發展，請參見 [8, 11]）。在資料模型的任何特定應用中，可能需要施加進一步的（資料庫特定的）完整性約束，從而定義更小的一致資料庫狀態或狀態變化集合。

在關聯式模型的發展中，結構、操作和完整性方面之間始終存在著緊密的耦合。如果結構被單獨定義，它們的行為屬性就沒有被固定下來，無限的可能性會出現，導致無休止的推測。因此，像 CODASYL 和 ANSI 這樣試圖在獨立委員會中開發資料結構定義語言 (DDL) 和資料操作語言 (DML) 的嘗試產生了許多誤解和不兼容，這並不令人意外。

關聯式處理能力

關聯式模型不僅要求關聯式結構（可以視為表格），而且還要求一種稱為關聯式處理的特定集合處理。關聯式處理意味著將整個關係作為運算元處理。其主要目的是避免迴圈，這是終端使用者獲得生產力的絕對要求，也是應用程式設計師提高生產力的明確助推器。

關聯式代數的 SELECT 運算子（也稱為 RESTRICT）以一個關係（表格）作為運算元，並產生一個由第一個關係中選定的元組（行）組成的新關係（表格）。PROJECT 運算子也將一個關係（表格）轉換為一個新關係，但這次由第一個關係中選定的屬性（列）組成。EQUI-JOIN 運算子以兩個關係（表格）作為運算元，並產生一個由第一個關係的行與第二個關係的行串接而成的第三個關係，但僅限於第一個關係中的指定列和第二個關係中的指定列具有匹配值的情況。如果列中的冗餘被移除，該運算子稱為 NATURAL JOIN。下文中，我們使用「join」（連接）一詞來指代 equi-join 或 natural join。

關聯式代數，包括這些運算子及其他，旨在作為一種能力的衡量標準。它並非旨在成為所有關聯式系統都應遵循的標準語言。關聯式模型的集合處理目標旨在通過一種至少具有關聯式代數能力且不使用迭代或遞迴語句的資料子語言來實現。

關聯式代數的大部分可衍生能力僅通過 SELECT、PROJECT 和不受任何關於預定義支援物理存取路徑的實現限制的 JOIN 運算子獲得。一個系統具有不受限制的 join 能力，如果它允許進行 join，其中任何一對屬性都可以匹配，只要它們定義在同一個域或資料類型上（對於我們目前的目的，域是語法的還是語義的，資料類型是弱類型還是強類型並不重要，但對於某些情況，請參見 [10]）。

偶爾會發現一些系統，其中 join 僅在要匹配的屬性具有相同名稱或由某種類型的預定義存取路徑支援時才被支援。此類限制顯著削弱了系統從基礎關係中衍生關係的能力。這些限制因此降低了系統處理終端使用者意外查詢的能力，並減少了應用程式設計師避免編寫迭代迴圈的機會。

因此，我們說一個資料子語言 L 具有關聯式處理能力，如果關聯式代數的 SELECT、PROJECT 和不受限制的 JOIN 運算子所指定的轉換可以在 L 中指定，而無需訴諸迭代或遞迴命令。

一個資料庫管理系統要被稱為關聯式，它必須支援： (1) 沒有使用者可見導航連結的表格； (2) 至少具有這種（最小）關聯式處理能力的資料子語言。

這意味著一個不支援關聯式處理的 DBMS 應該被視為非關聯式。這種系統可能更適合稱為表格式 (tabular)，前提是它支援沒有使用者可見表格之間導航連結的表格。這個術語應該取代 [8] 中使用的「半關聯式」術語，因為表格式系統（其中程式設計師自行導航）與關聯式系統（其中系統為其導航，即系統提供自動導航）在實現複雜性上有很大差異。

上述關聯式 DBMS 的定義有意地為提供的服務留下了很大的自由度。例如，不要求支援完整的關聯式代數，也不要求支援關聯式模型的兩個完整性規則（實體完整性和參考完整性）。一個關聯式系統完整支援模型的這兩個部分，使其有資格稱為完全關聯式 [8]。雖然我們不知道今天有任何系統符合完全關聯式的資格，但有些系統已經非常接近，毫無疑問很快就會符合。

在圖 1 中，我們說明了各種關聯式和表格式系統之間的區別。對於每個類別，S 框中的陰影程度旨在顯示該類別成員對關聯式模型結構要求的忠實程度。類似的說明適用於 M 框對於操作要求，以及 I 框對於完整性要求。

m 表示最小關聯式處理能力。c 表示關聯式完整性（一種與沒有空值的二值一階謂詞邏輯對應的能力）。當操作框 M 完全陰影時，這表示一種能力，與 [8] 中定義的完整關聯式代數對應（具有單一類型空值的三值謂詞邏輯）。除了完全關聯式之外，每個類別的完整性框中的問號表明目前關聯式系統對完整性的支援不足。需要加強對域和主鍵的支援 [10]，以及 [14] 中討論的那種功能。

請注意，關聯式 DBMS 可以以任何方便的方式打包其關聯式處理能力。例如，在 Relational Technology, Inc. 的 INGRES 系統中，QUEL [29] 的 RETRIEVE 語句包含了所有三個運算子（選擇、投影、連接）在一個語句中，這樣就可以獲得任何一個運算子或它們任何組合的相同效果。

在關聯式模型的定義中，有幾項禁令。舉兩個例子：排除使用者可見的表格之間導航連結，資料庫資訊不得在基礎關係中通過元組的順序表示（或隱藏）。我們的經驗是，實施非關聯式系統的 DBMS 設計師不輕易理解和接受這些禁令。相比之下，使用者熱情地理解並接受這些禁令帶來的學習和使用便利性提高。

順帶一提，美國國家標準協會的關聯式任務組最近發布了一份關於開發關聯式資料庫系統標準可行性的報告 [4]。這份報告對十多個關聯式系統的功能進行了啟發性的分析，其作者清楚地理解關聯式模型。

圖 1. DBMS 分類。

S = 結構
M = 操作
I = 完整性

表格式
(之前稱為
半關聯式)
    ┌─────┐
S   │     │
    └─────┘
    ┌─────┐
M   │     │
    └─────┘
    ┌─────┐
I   │  ?  │
    └─────┘

最小關聯式
     g-
     %
     ┌─────┐
S    │     │
     └─────┘
     ┌─────┐
M    │  m  │
     └─────┘
     ┌─────┐
I    │  ?  │
     └─────┘

關聯式完整
      ,~
      72
      ┌─────┐
S     │     │
      └─────┘
      ┌─────┐
M     │  c  │
      └─────┘
      ┌─────┐
I     │  ?  │
      └─────┘

完全關聯式
      c = 關聯式完整性
      m = 最小關聯式處理能力
      ┌─────┐
S     │     │
      └─────┘
      ┌─────┐
M     │     │
      └─────┘
      ┌─────┐
I     │     │
      └─────┘

統一關聯式特性

為了具有廣泛的適用性，大多數關聯式 DBMS 都有一個可以與一個或多個常用程式設計語言（例如，Cobol、Fortran、PL/I、APL）介面的資料子語言。我們將後者稱為主語言。關聯式 DBMS 通常至少支援一種面向終端使用者的資料子語言——有時甚至幾種，因為這些使用者的需求可能不同。有些人喜歡 QUEL 或 SQL [5] 等字串語言，而另一些人則喜歡 Query-by-Example [33] 的螢幕導向二維資料子語言。

現在，一些關聯式系統（例如，System R [6]、INGRES [29]）支援一種可以在兩種模式下使用的資料子語言：(1) 在終端互動式使用，以及 (2) 嵌入在由主語言編寫的應用程式中。這種雙模式資料子語言有很強的論點： (1) 有了這種語言，應用程式設計師可以在終端上單獨調試他們希望包含在應用程式中的資料庫語句——使用 SQL 開發應用程式的人聲稱雙模式功能顯著提高了他們的生產力； (2) 這種語言顯著增強了程式設計師、分析師、終端使用者、資料庫管理人員等之間的溝通； (3) 這兩種模式使用的語言之間無謂的區別給那些必須在兩種模式下工作的使用者帶來了不必要的學習和記憶負擔。

這個功能對於生產力的重要性表明，關聯式 DBMS 應該根據它們是否擁有這個功能來分類。因此，我們將支援雙模式子語言的關聯式 DBMS 稱為統一關聯式 (uniform relational)。因此，統一關聯式 DBMS 在終端使用者介面和應用程式程式設計介面都支援關聯式處理，並且使用兩種介面通用的資料子語言。

所有其他關聯式 DBMS 的自然術語是非統一關聯式 (non-uniform relational)。一個非統一關聯式 DBMS 的例子是 TANDEM ENCOMPASS [19]。使用這個系統，在終端上互動式檢索資料時，使用關聯式資料子語言 ENFORM（一種具有關聯式處理能力的語言）。在編寫程式來檢索或操作資料時，使用 Cobol 的擴展版本（一種不具有關聯式處理能力的語言）。這兩個使用層級的共通之處是結構：表格之間沒有使用者可見的導航連結。

隨之而來的一個問題是：如何將具有關聯式處理能力的資料子語言與只能一次處理一條記錄的語言（即，不能將記錄集合作為單一運算元處理的語言）進行介面？為了解決這個問題，我們必須將以下兩個操作分開：(1) 定義要衍生的關係；(2) 將衍生的關係呈現給主語言程式。

一種解決方案（在 Peterlee Relational Test Vehicle [31] 中採用）是將衍生的關係轉換為一種檔案形式，可以使用主語言語句逐條記錄讀取。在這種情況下，記錄的傳遞委託給相關主語言使用的檔案系統。

另一種解決方案（由 System R 採用）是將記錄的傳遞控制在資料子語言語句下，進而控制在關聯式 DBMS 優化器下。SQL（System R 的資料子語言）的查詢語句 Q 可以嵌入在主語言程式中，使用以下類型的語法（為了說明原因，語法與 SQL 不完全相同）：

DECLARE C CURSOR FOR Q

其中 C 代表程式設計師選擇的任何名稱。這樣的語句將一個名為 C 的遊標與定義表達式 Q 相關聯。由 Q 定義的衍生關係中的元組通過命名的遊標一次一個地呈現給程式。每次執行此遊標的 FETCH 操作時，系統會從衍生關係中傳遞下一個元組。傳遞順序由系統決定——除非定義衍生關係的 SQL 語句 Q 包含 ORDER BY 子句。

重要的是要注意，在衍生關係上移動遊標時，程式設計師並非在導航到某些目標資料。衍生關係本身就是目標資料！是由 DBMS 決定衍生關係應該在遊標控制掃描之前整體物化還是掃描期間分段物化。在任何一種情況下，都是系統（而不是程式設計師）選擇生成衍生資料的存取路徑。這顯著減輕了程式設計師的負擔，從而提高了他們的生產力。

對關聯式系統的懷疑

對關聯式資料庫管理方法的實用性從來不乏懷疑。其中大部分懷疑源於缺乏理解，部分源於對基於關聯式模型的眾多理論研究的恐懼 [1, 2, 15, 16, 24]。態度似乎是：如果它是理論的，它就不可能是實用的，而不是歡迎理論基礎以提供健全性。幾乎所有非關聯式 DBMS 缺乏理論基礎是它們「ungepotchket」性質的主要原因。（這是一個意第緒語單詞，其中一個意思是「修補好的」）。

另一方面，提出以下兩個問題似乎是合理的： (1) 關聯式系統能否提供我們期望從其他 DBMS 獲得的服務範圍？ (2) 如果 (1) 的答案是肯定的，這樣的系統能否與非關聯式 DBMS 表現一樣好？†

我們將逐一探討這些問題。

服務範圍

一個完整的 DBMS 提供以下功能：

資料儲存、檢索和更新；
用戶可存取的資料描述目錄；
事務支援，以確保一系列資料庫更改全部或無一體現在相關資料庫中（有關事務技術的最新總結，請參見 [17]）；
故障（系統、媒體或程式）時的復原服務；
並行控制服務，以確保並行事務的行為與按某個順序運行時相同；
授權服務，以確保所有資料存取和操作都符合對使用者和程式指定的約束 [18]；
與資料通訊支援集成；
完整性服務，以確保資料庫狀態和狀態變化符合指定規則。

七十年代初期開發的某些關聯式原型遠未提供所有這些服務（可能是有正當理由的）。然而，現在已經有一些關聯式系統作為軟體產品提供，除了最後一項服務外，所有其他服務都提供了。這些產品的現有版本在提供完整性服務方面確實較弱，但這一點正在迅速得到彌補 [10]。

某些關聯式 DBMS 實際上提供了比非關聯式系統更完整的資料服務。以下是三個例子。

第一個例子是，關聯式 DBMS 支援從資料庫中提取所有有意義的關係，而非關聯式系統僅在存在靜態預定義存取路徑時支援提取。

作為某些關聯式系統提供的附加服務的第二個例子，考慮視圖 (views)。視圖是通過表達式或命令序列定義的虛擬關係（表格）。雖然不直接由實際資料支援，但視圖對使用者來說就像一個額外的基礎表格，並且與其他基礎表格保持最新和完整性狀態。視圖對於允許應用程式和終端使用者與恆定的視圖結構互動非常有用，即使基礎表格本身在邏輯層面發生結構變化時也是如此（前提是相關視圖仍然可以從新的基礎表格中定義）。它們也用於限制程式和使用者的存取範圍。非關聯式系統要麼完全不支援視圖，要麼只支援更原始的對應物，例如 CODASYL 子模式。

作為第三個例子，一些系統（例如，SQL/DS [28] 及其原型前身 System R）允許在事務進行中動態地對資料的邏輯和物理組織進行各種更改——這些更改很少需要重新編寫應用程式。因此，程式維護負擔較少，使程式設計師可以更具生產力地從事開發而不是維護。SQL/DS 之所以能夠實現這一點，是因為系統對存取路徑選擇具有完全控制權。

在非關聯式系統中，這種更改通常需要停止所有其他資料庫活動，包括正在進行的事務。然後資料庫將暫停運行，直到組織更改完成並完成任何必要的重新編譯。

† 應該記住，非關聯式系統始終使用相對低層次的資料子語言進行應用程式程式設計。

效能

自然地，如果關聯式系統的性能緩慢，人們會猶豫使用它們。人們經常通過比較這些系統執行複雜事務所需的時間與非關聯式系統執行極簡單事務所需的時間來得出關於關聯式系統性能的錯誤結論。要進行公平的性能比較，必須在相同的任務或應用程式上比較這些系統。我們將提出論點來證明關聯式系統應該能夠成功地與非關聯式系統競爭。

良好的性能取決於兩個因素：(1) 系統必須支援面向性能的物理資料結構；(2) 高層次語言的資料請求必須編譯成與普通應用程式程式設計師手寫產生的代碼至少一樣好的低層次程式碼序列。

論點的第一步是，用 Cobol 級語言編寫的程式可以在包含生產資料的大型資料庫上高效執行，這些資料以表格形式結構化，並且表格之間沒有使用者可見的導航連結。論證的這一步由以下資訊支持 [19]：截至 1981 年 8 月，Tandem Computer Corp. 已製造並安裝了 760 個系統；其中 700 多個系統正在使用 Tandem ENCOMPASS 關聯式資料庫管理系統來支援包含生產資料的資料庫。Tandem 已將其自己的製造資料庫交給 ENCOMPASS 管理。ENCOMPASS 不支援資料庫表格之間的連結，無論是使用者可見的（導航）連結還是使用者不可見的（存取方法）連結。

論證的第二步是，假設我們採用上述安裝中的應用程式，並將資料庫檢索和操作語句替換為具有關聯式處理能力的資料庫子語言（例如，SQL）中的語句。顯然，要使用這種高層次語言獲得良好性能，必須將其編譯成目標碼（而不是解釋），而且必須使該目標碼高效。

System R 及其產品版本 SQL/DS 使用編譯。1976 年，Raymond Lorie 開發了一個巧妙的預編譯和後編譯方案，用於處理存取路徑的動態變化 [21]。它也處理了早期（因此高效）的授權和完整性檢查（後者尚未實施）。這個方案要求以一種相當特殊的方式編譯嵌入在主語言程式中的 SQL 語句。這個編譯步驟將 SQL 語句轉換為源程式中適當的 CALLs，並包含目標碼的存取模組。這些模組隨後儲存在資料庫中，以供運行時使用。這些存取模組中的程式碼由系統生成，以優化主要操作的序列和存取路徑的選擇，從而提供運行時效率。完成預編譯步驟後，應用程式將由相關主語言的常規編譯器編譯。如果在隨後的任何時間，移除了一個或多個存取路徑並嘗試運行程式，則在存取模組中保留了足夠的源資訊，使系統能夠重新編譯一個利用現有存取路徑的新存取模組，而無需重新編譯應用程式。

順帶一提，相同的資料子語言編譯器用於從終端互動提交的臨時查詢，以及在程式執行期間動態生成的查詢（例如，從互動提交的參數）。編譯完成後，這些查詢立即執行，除了最簡單的查詢外，性能優於解釋器。

存取模組的生成（無論是在初始編譯還是重新編譯階段）都需要一個相當複雜的優化方案 [27]，該方案利用了系統維護的統計資訊，這些資訊通常不是程式設計師能知道的。因此，只有在最簡單的事務中，普通應用程式程式設計師才有可能在生成高效程式碼方面與此優化器競爭。任何競爭嘗試都必然會降低程式設計師的生產力。因此，為額外的編譯時開銷付出的代價似乎非常值得。

假設兩種情況下都採用非連結的表格結構，我們可以預期 SQL/DS 在許多簡單情況下會生成與普通手寫程式碼相當的程式碼，在許多複雜情況下則更優。許多商業事務極其簡單。例如，可能需要查找特定鐵路貨車的記錄以找出其位置，或者查找某人儲蓄帳戶的餘額。如果支援適當的快速存取路徑（例如，雜湊），像 SQL、QUEL 或 QBE 這樣的高層次語言沒有理由導致這些簡單事務的運行時程式碼比低層次語言效率低，即使這些事務很少利用高層次資料子語言編譯器的優化能力。

未來發展方向

如果我們要將關聯式資料庫作為生產力的基礎，我們需要知道關聯式系統可能有哪些發展。

讓我們先討論近期發展。在某些關聯式系統中，需要加強對 [10] 中建議的域和主鍵的支援。如前所述，所有關聯式系統都需要改進關於自動遵守完整性約束的能力。需要放寬（在理論上可能的情況下）對更新 join 類型視圖的現有約束，並且在這個問題上正在取得進展 [20]。需要支援外連接 (outer joins)。

優化技術正在顯著改進，因此我們可以合理預期性能的進一步提升。在某些產品中，例如 ICL CAFS [22] 和 Britton-Lee IDM500 [13]，已經實施了特殊的硬體支援。特殊硬體可以在某些類型的應用程式中提高性能。然而，在大多數處理格式化資料庫的應用程式中，軟體實現的關聯式系統可以在性能上與軟體實現的非關聯式系統競爭。

目前，大多數關聯式系統不為工程和科學資料庫提供任何特殊支援。顯然需要這種支援，包括與 Fortran 的介面，並且可以預期會實現。

關聯式系統中的目錄已經由額外的關係組成，可以使用相同的查詢語言像查詢資料庫的其餘部分一樣進行查詢。一個可以且應該迅速到位的自然發展是將這些目錄擴展為成熟的活動字典，以提供額外的在線資料控制。

最後，在近期，我們可以預期出現適用於關聯式系統的資料庫設計輔助工具，無論是在邏輯層面還是物理層面。

從長遠來看，我們可以預期對分佈在通訊網路上的關聯式資料庫提供支援 [25, 30, 32]，並且以這樣的方式進行管理，使應用程式和互動式使用者能夠操作資料：(1) 就像所有資料都儲存在本地節點一樣——位置透明性 (location transparency)；(2) 就像資料沒有在任何地方複製一樣——複製透明性 (replication transparency)。上述三個專案都基於關聯式模型。其中一個重要原因是，關聯式資料庫在規劃如何將資料庫分佈在計算機系統網路上時提供了極大的分解靈活性，並為動態組合分散資訊提供了強大的重組能力。相比之下，CODASYL DBTG 資料庫由於擁有者-成員導航連結的糾纏，很難分解和重組。這一特性使得 CODASYL 方法極難適應分佈式資料庫環境，並很可能證明是其失敗的原因。使用關聯式模型的第二個原因是它為從節點到節點傳輸資料請求提供了簡潔的高層次資料子語言。

正在進行的擴展關聯式模型以形式化方式捕獲更多資料含義的工作，預計將導致將這種含義納入資料庫目錄，以便將其從應用程式中排除，並使這些程式更加簡潔和簡單。這裡，我們當然指的是以系統能夠理解並據此行動的方式表示的含義。

正在開發改進的理論來處理缺失資料和不適用資料（例如，參見 [3]）。這項工作應該會改進對空值的處理。

目前，關聯式資料庫最適合結構相當規律或同質的資料。我們能否在處理異質資料的同時保留關聯式方法的優勢？此類資料可能包括圖像、文本和各種事實。預期會得到肯定的答案，並且關於這個主題的一些研究正在進行，但還需要更多研究。

需要大量的研究來實現資料庫語言和程式設計語言的和解。Pascal/R [26] 是這方面工作的一個很好的例子。正在進行的研究一方面側重於將抽象資料類型納入資料庫語言 [12]，另一方面側重於將關聯式處理納入程式設計語言。

結論

我們提出了一系列論點，支持關聯式資料庫技術能顯著提高終端使用者和應用程式設計師生產力的主張。這些論點圍繞著關聯式模型中定義並在關聯式資料庫管理系統中實現的資料獨立性、結構簡單性和關聯式處理能力。所有這三個特性都簡化了開發應用程式以及從終端提交查詢和更新的任務。此外，第一個特性傾向於使程式在資料庫的組織和描述變化面前仍然可用，從而減少了通常用於程式維護的工作量。

那麼，為什麼本文的標題顯示關聯式資料庫僅為提高生產力提供了基礎，而不是完整的解決方案呢？原因很簡單：關聯式資料庫僅處理應用程式和終端使用者互動中的共享資料組成部分。還有許多互補技術可以幫助處理其他組成部分或方面，例如，支援關聯式處理和改進資料類型檢查的程式設計語言、了解更多正在使用的語言的改進編輯器等。我們使用「基礎」一詞，是因為與共享資料的互動（無論是通過程式還是終端）代表了許多資料處理活動的核心。

關聯式方法的實用性已通過正在運行的測試和生產安裝得到證明。因此，借助關聯式系統，我們現在可以期待我們最初都曾希望 DBMS 能夠提供的生產力提升。

致謝：我要感謝 IBM Research, San Jose 的 System R 開發團隊開發了一個完整的統一關聯式原型，該原型包含了眾多語言和系統創新；感謝 IBM Laboratory, Endicott, N.Y. 的開發團隊以專業的方式將 System R 轉化為產品形式；感謝大學、硬體製造商、軟體公司和使用者安裝的各種團隊，他們設計和實施了可運行的關聯式系統；感謝 IBM Yorktown Heights, N.Y. 的 QBE 團隊；感謝英格蘭 IBM Scientific Centre 的 PRTV 團隊；以及許多將關聯式模型作為基礎的資料庫理論貢獻者。特別要感謝在早期階段看到值得支持的東西的極少數同事，特別是 Chris Date 和 Sharon Weinberg。最後，是 Sharon Weinberg 提出了本文的主題。

Received 10/81; revised and accepted 12/81

參考文獻

Beeri, C., Bernstein, P., Goodman, N. A sophisticate's introduction to database normalization theory. Proc. Very Large Data Bases, West Berlin, Germany, Sept. 1978.
Bernstein, P.A., Goodman, N., Lai, M-Y. Laying phantoms to rest. Report TR-03-81, Center for Research in Computing Technology, Harvard University, Cambridge, Mass., 1981.
Biskup, J.A. A formal approach to null values in database relations. Proc. Workshop on Formal Bases for Data Bases, Toulouse, France, Dec 1979; published in [16] (see below) pp 299-342.
Brodie, M. and Schmidt, J. (Eds), Report of the ANSI Relational Task Group., (to be published ACM SIGMOD Record).
Chamberlin, D.D., et al. SEQUEL2: A unified approach to data definition, manipulation, and control. IBM J. Res. & Dev., 20, 6, (Nov. 1976) 560-565.
Chamberlin, D.D., et al. A history and evaluation of system R. Comm. ACM, 24, 10, (Oct. 1981) 632-646.
Codd, E.F. A relational model of data for large shared data banks. Comm. ACM, 13, 6, (June 1970) 377-387.
Codd, E.F. Extending the database relational model to capture more meaning. ACM TODS, 4, 4, (Dec. 1979) 397-434.
Codd, E.F. Data models in database management. ACM SIGMOD Record, 11, 2, (Feb. 1981) 112-114.
Codd, E.F. The capabilities of relational database management systems. Proc. Convencio Informaciò Llatina, Barcelona, Spain, June 1-12, 1981, pp 13-26; also available as Report 3132, IBM Research Lab., San Jose, Calif.
Date, C.J. Referential integrity. Proc. Very Large Data Bases, Cannes, France, September 9-11, 1981, pp 2-12.
Ehrig, H., and Weber, H. Algebraic specification schemes for data base systems. Proc. Very Large Data Bases, West Berlin, Germany, Sept 13-15, 1978, 427-440.
Epstein, R., and Hawthorne, P. Design decisions for the intelligent database machine. Proc. NCC 1980, AFIPS, Vol. 49, May 1980, pp 237-241.
Eswaran, K.P., and Chamberlin, D.D. Functional specifications of a subsystem for database integrity. Proc. Very Large Data Bases, Framingham, Mass., Sept. 1975, pp 48-68.
Fagin, R. Horn clauses and database dependencies. Proc. 1980 ACM SIGACT Symp. on Theory of Computing, Los Angeles, CA, pp 123-134.
Gallaire, H., Minker, J., and Nicolas, J.M. Advances in Data Base Theory. Vol 1, Plenum Press, New York, 1981.
Gray, J. The transaction concept: virtues and limitations. Proc. Very Large Data Bases, Cannes, France, September 9-11, 1981, pp 144-154.
Griffiths, P.G., and Wade, B.W. An authorization mechanism for a relational database system. ACM TODS, 1, 3, (Sept 1976) 242-255.
Held, G. ENCOMPASS: A relational data manager. Data Base/81, Western Institute of Computer Science, Univ. of Santa Clara, Santa Clara, Calif., August 24-28, 1981.
Keller, A.M. Updates to relational databases through views involving joins. Report RJ3282, IBM Research Laboratory, San Jose, Calif., October 27, 1981.
Lorie, R.A., and Nilsson, J.F. An access specification language for a relational data base system. IBM J. Res. & Dev., 23, 3, (May 1979) 286-298.
Maller, V.A.J. The content addressable file store--CAFS. ICL Technical J., 1, 3, (Nov. 1979) 265-279.
Reisner, P. Human factors studies of database query languages: A survey and assessment. ACM Computing Surveys, 13, 1, (March 1981) 13-31.
Rissanen, J. Theory of relations for databases--A tutorial survey. Proc. Symp. on Mathematical Foundations of Computer Science, Zakopane, Poland, September 1978, Lecture Notes in Computer Science, No. 64, Springer Verlag, New York, 1978.
Rothnie, J.B., Jr, et al. Introduction to a system for distributed databases (SDD-1). ACM TODS, 5, 1, (March 1980) 1-17.
Schmidt, J.W. Some high level language constructs for data of type relation. ACM TODS, 2, 3, (Sept 1977) 247-261.
Selinger, P.G., et al. Access path selection in a relational database system. Proc. 1979 ACM SIGMOD International Conference on Management of Data, Boston, MA, May 1979, pp 23-34.
---. SQL/Data system for VSE: A relational data system for application development. IBM Corp. Data Processing Division, White Plains, N.Y., G320-6590, Feb 1981.
Stonebraker, M.R., et al. The design and implementation of INGRES. ACM TODS, 1, 3, (Sept. 1976) 189-222.
Stonebraker, M.R., and Neuhold, E.J. A distributed data base version of INGRES. Proc. Second Berkeley Workshop on Distributed Data Management and Computer Networks, Lawrence-Berkeley Lab., Berkeley, Calif., May 1977, pp 19-36.
Todd, S.J.P. The Peterlee relational test vehicle--A system overview. IBM Systems J., 15, 4, 1976, 285-308.
Williams, R., et al. R*: An overview of the architecture. Report RJ3325, IBM Research Laboratory, San Jose, Calif., October 27, 1981.
Zloof, M.M. Query by example. Proc. NCC, AFIPS Vol 44, May 1975, pp 431-438.