Edgar F. Codd 如何讓資料不必綁死在儲存方式？關聯模型、資料獨立性與 SQL 前史

Edgar F. Codd 在 1970 年論文提出關聯資料模型，核心是讓應用程式不必綁死資料的儲存方式；SQL 與後來的資料庫產品則是團隊共同完成的工程。

本文會依序區分 1970 年模型、System R、SQL／SEQUEL 與後來的 12 rules，避免把整段歷史歸給一個人。

先講結論：Edgar F. Codd 以關聯模型與資料獨立性改變資料庫設計：應用程式不必綁死底層儲存方式，查詢可以透過關係與集合運算表達；SQL、System R 與後來的資料庫產品則是團隊共同完成的工程。

Q：Edgar F. Codd 是誰？ A：他是提出關聯式資料模型的電腦科學家，影響資料庫理論、設計、正規化與查詢語言發展。

Q：關聯模型在做什麼？ A：它用關聯、欄位、鍵與集合／關係運算表示資料和查詢，讓應用程式不必直接暴露底層檔案與儲存結構。

Q：資料獨立性是什麼？ A：應用程式不必因資料如何儲存、索引或重新組織而大幅改寫，讓邏輯資料模型與物理實作可以分層演進。

Q：正規化為什麼重要？ A：它依函數相依拆分資料，減少重複與插入、更新、刪除異常；代價可能是需要更多查詢組合與連接。

Q：SQL 和 Codd 的關係是什麼？ A：Codd 提出理論模型；SQL／SEQUEL、System R 與標準化則由後續研究與工程團隊發展，兩者相關但不是單人作品。

Q：關聯和一般表格完全相同嗎？ A：不完全相同。關聯模型有集合、欄位、鍵與相依性的語意限制；實作資料庫還可能加入 NULL、排序、索引和產品特有行為。

Q：關聯模型如何支援可靠查詢？ A：明確的資料模型、鍵、約束與查詢運算讓系統能檢查資料規則，也讓不同儲存策略在相同邏輯介面下替換。

Q：這套思想和今日 AI 資料平台如何連結？ A：資料獨立性、查詢抽象與約束仍有價值，但向量、非結構化資料、分散式一致性與模型服務也需要額外資料模型與工程取捨。

Q：圖片與文章的關係是什麼？ A：圖片是 Edgar F. Codd、關聯模型、資料獨立性、正規化與 SQL 前史的 YOLO LAB 原創路線圖，不是 IBM System R 的官方截圖。

增量補充：模型、語言與引擎要分開看

IBM 的歷史資料把 Codd 1970 年的關聯模型描述為：讓使用者不必知道資料庫的物理藍圖，也能存取與管理資料。這正好支持本文對「資料獨立性」的解釋；但關聯模型、SQL 語言、查詢最佳化器與實際資料庫產品仍是不同層次，不能把一篇論文直接等同於完整商業系統。來源：IBM — The relational database。

因此，分析一個資料系統時可以分三問：資料如何被抽象？人如何描述要查什麼？引擎如何在索引、記憶體、並行與成本限制下執行？這三問能保留 Codd 的理論突破，也不會忽略後續工程團隊把模型變成可用產品所付出的工作。

先看 5 個重點

Codd 的核心問題是 data independence：儲存表示改變，不應迫使上層應用程式一起重寫。
relation 常以 table 呈現，tuple 常對應 row，attribute 常對應 column；這些是實作上的對照，不應把數學語義簡化成畫面上的表格。
1970 年論文提出 n-ary relations、normal form 與 universal data sublanguage 等概念。
後來的 Codd 12 rules 是評估「fully relational」的歷史檢核框架，不是 1970 年論文的全部，也不是現代產品的保固書。
System R 把關聯模型推進成可測試的工程系統；Don Chamberlin 與 Raymond Boyce 參與 SEQUEL／SQL，Patricia Selinger 發展 cost-based optimizer，SQL、索引與交易等產品能力則由後續團隊共同完成。

Codd 在 1970 年要解決什麼？

在關聯模型出現以前，資料系統常要求程式知道資料的樹狀或網路式結構，甚至知道如何沿著儲存中的連結找到資料。IBM 對 Codd 論文的摘要指出，這會讓資料表示一改變，終端使用者活動和應用程式也被迫受到影響。

Codd 的切入點是把「資料是什麼」和「機器怎麼存」分開。上層只需要面對可描述的關係與值；底層可以因查詢、更新、報表流量或資料成長而調整。這就是 physical data independence（實體資料獨立性）的方向；logical data independence（邏輯資料獨立性）則指外部使用方式與邏輯結構之間的隔離。兩者都在保護應用程式不必因底層變更而全面重寫。

relation、tuple、attribute 與 table 有什麼關係？

可以先用工程師熟悉的方式理解：一個 relation 可以用 table 呈現；每一筆 tuple 像 row；每個 attribute 像 column。關聯模型真正重要的地方，是資料之間的關係以值和集合的方式表達，而不是要求程式沿著某一條固定指標或巢狀路徑走到底。

這種抽象帶來兩個好處。第一，查詢可以描述「要什麼」，而不是逐步指示「先走哪個節點、再跳哪個連結」。第二，資料庫可以在不改變上層意圖的情況下選擇更有效率的執行計畫。這不表示物理層不重要；索引、儲存、記憶體、並行與成本估算，仍決定同一個查詢能不能在合理時間內完成。

1970 年論文的貢獻，不只是「把資料變成表格」

IBM Research 保存的原始論文記錄了幾個關鍵詞：n-ary relations、normal form，以及用來處理資料操作的 universal data sublanguage。它同時討論 redundancy 與 consistency，顯示 Codd 關心的不只是介面是否好看，而是資料模型如何減少重複、維持一致性並支援不同使用方式。

因此，將 Codd 的貢獻說成「發明 table」太窄。更準確的說法是，他提出一個可以用形式化關係描述資料的模型，並把應用程式不應依賴內部儲存方式這件事，提升成資料庫設計的核心問題。

Codd 和 SQL 的關係：模型先出現，產品工程接著發生

Codd 沒有單獨發明 SQL。IBM 的關聯資料庫歷史把 1970 年論文之後的 System R 列為重要工程階段：Don Chamberlin 和 Raymond Boyce 參與 SEQUEL／SQL 的發展，Patricia Selinger 建立 cost-based optimizer，其他成員則處理 compiler、查詢計畫與產品化。IBM DB2 以及後來的商業資料庫，都是這條路線上由多人推進的結果。

這個區分對讀者很重要。關聯模型回答「資料應如何被抽象與理解」；SQL 提供一種可操作的查詢語言；資料庫引擎再把查詢翻譯成具體的執行計畫。三者互相連接，卻不是同一個歷史事件。

Codd 的 12 rules 是什麼？

Codd 在 1985 年又提出 12 rules（實際編號從 Rule 0 到 Rule 12），作為檢查一個產品是否足夠「fully relational」的歷史框架。這些規則把 information、guaranteed access、null、catalog，以及 physical、logical、integrity、distribution independence 等要求放在同一張檢核表中；保留的原始文章轉錄也特別說明，規則是在保護使用者的應用程式投資，不是替 1970 年模型增加另一套資料語法。

今天引用 12 rules 時要加上邊界：它更像理想型與評估工具，不是宣告某個產品只要通過就自動可靠。交易、權限、備份、分散式故障、成本和查詢效能，仍然需要個別工程設計。

為什麼 data independence 仍然重要？

今天的資料系統經常需要換儲存引擎、加索引、分割資料、調整複寫或處理新的查詢負載。如果業務程式把每個物理細節都寫死，任何底層調整都會變成跨團隊的大型修改。Codd 的抽象提醒工程師：先定義資料和業務操作，再讓實作層負責在約束內找出有效率的方式。

這不等於所有底層差異都能被隱藏。資料量、延遲、交易隔離、故障恢復、成本與一致性，最後都會回到系統設計。資料獨立性是降低耦合的方向，不是取消工程現實的魔法。

常見誤讀與限制

第一，關聯式資料庫不是「每種資料都只能放在一張表」。實務上會用多個 relation、constraint、view、index、transaction 與 query planner 共同組成系統。

第二，SQL 的普及不代表所有 SQL 方言或產品行為完全相同。讀者要區分關聯模型、SQL 標準和個別資料庫的擴充。

第三，Codd 的模型解決的是資料表示與操作的抽象問題，不會自動解決權限、備份、分散式故障、資料治理或錯誤的 schema 設計。把「有 relational database」直接等同「資料可靠」，仍然是過度推論。

Codd 留下的工程遺產

Codd 最重要的問題不是「表格是不是最潮」，而是：當系統變大、資料持續成長、儲存方式不斷變動時，上層使用者和應用程式能否繼續用穩定的方式理解資料？關聯模型、SQL 與 System R 的歷史共同示範了抽象如何變成產業基礎；它也提醒我們，成功的技術通常是模型、語言、最佳化器、產品團隊與使用者需求一起完成的。

Edgar F. Codd 如何讓資料不必綁死在儲存方式？關聯模型、資料獨立性與 SQL 前史