1986年的論文，2025年的MongoDB。中間隔了39年，文檔數(shù)據(jù)庫的核心理論居然早就被人算透了。

這篇論文叫《非第一范式關(guān)系數(shù)據(jù)庫理論》，作者M(jìn)ark A. Roth。當(dāng)時關(guān)系數(shù)據(jù)庫剛統(tǒng)治世界，所有人都在追求第一范式（1NF）——把數(shù)據(jù)拆成扁平的二維表，消滅一切嵌套結(jié)構(gòu)。Roth卻反著來：嵌套怎么了？嵌套才是自然狀態(tài)。

MongoDB的工程師可能沒讀過這篇論文，但他們做出來的東西，幾乎就是論文的復(fù)刻。

10行變2行：1NF的冗余有多荒唐

Roth在論文里舉了個經(jīng)典例子。假設(shè)你要存員工信息：姓名、孩子、技能。按1NF的規(guī)矩，孩子和技能得拆成獨(dú)立表，或者拉成笛卡爾積的扁平表。

結(jié)果是10行數(shù)據(jù)，Smith出現(xiàn)4次，Jones出現(xiàn)6次。孩子的信息重復(fù)，技能的信息重復(fù)，連員工名字都重復(fù)。更新的時候漏改一行？數(shù)據(jù)就臟了。

非第一范式（?1NF）直接把結(jié)構(gòu)嵌起來：2個文檔，完事。孩子是個數(shù)組，技能是個數(shù)組，技能下面的考試記錄還是個數(shù)組。三層嵌套，零冗余。

Roth把這種結(jié)構(gòu)叫"數(shù)據(jù)庫模式"（database scheme）——屬性可以是標(biāo)量（零階），也可以是關(guān)系值（高階）。聽起來像面向?qū)ο螅?986年還沒流行這詞。Roth的動機(jī)很純粹：省空間、省操作、符合直覺。

MongoDB的文檔模型，本質(zhì)上就是Roth的"數(shù)據(jù)庫模式"的工業(yè)實現(xiàn)。

$unwind、$group、$lookup：論文里的算子活了

Roth的論文不只是定義了數(shù)據(jù)結(jié)構(gòu)，還設(shè)計了一套代數(shù)操作。嵌套關(guān)系怎么查詢？怎么聚合？怎么連接？他全寫好了。

MongoDB的聚合管道，幾乎一一對應(yīng)：

$unwind——把嵌套數(shù)組展開成扁平流，對應(yīng)論文的"unnest"操作。$group——按字段聚合，對應(yīng)"nest"的逆過程。$lookup——跨集合連接，對應(yīng)嵌套關(guān)系的"join"。集合操作（并、交、差）——論文里也有專門的代數(shù)定義。

這不是巧合。2010年MongoDB發(fā)布聚合框架時，工程師面對的是和Roth相同的問題：怎么在嵌套結(jié)構(gòu)上跑關(guān)系代數(shù)？Roth的論文提供了現(xiàn)成的數(shù)學(xué)基礎(chǔ)。

一個細(xì)節(jié)：Roth的論文里，嵌套關(guān)系的屬性可以是"關(guān)系值"（relation-valued），也就是屬性本身是個表。MongoDB的數(shù)組 of 文檔，正好對應(yīng)這個概念。數(shù)組不是事后補(bǔ)丁，是理論的一等公民。

為什么SQL繞了39年的彎路

1NF的暴政持續(xù)了幾十年。Oracle、MySQL、PostgreSQL，全都把嵌套結(jié)構(gòu)當(dāng)成異端。JSON字段是后來才加的，而且用起來像二等公民——不能索引、不能高效查詢、不能參與連接。

Roth早就指出了1NF的三個問題：冗余存儲、更新異常、查詢復(fù)雜。但SQL的慣性太大。標(biāo)準(zhǔn)委員會、企業(yè)客戶、遺留系統(tǒng)，層層綁架。直到移動互聯(lián)網(wǎng)爆發(fā)，數(shù)據(jù)模型越來越像JSON，文檔數(shù)據(jù)庫才殺回來。

MongoDB的成功常被說成"開發(fā)者體驗好"。但這句評價太輕了。它的底層是扎實的代數(shù)理論，只是包裝成了工程師喜歡的樣子。

論文里有個概念叫"V-relation"——值關(guān)系，允許屬性取空集。MongoDB的稀疏文檔、動態(tài)模式，正好對應(yīng)這個設(shè)計。不是MongoDB發(fā)明了靈活模式，是Roth證明了靈活模式在數(shù)學(xué)上自洽。

換句話說，MongoDB的"無模式"不是偷懶，是有理論背書的工程選擇。

4NF的替代方案：Roth的野心更大

原文標(biāo)題提到"替代4NF"。這值得展開。

數(shù)據(jù)庫范式從1NF跑到4NF，是為了消除各種異常：插入異常、刪除異常、更新異常。但每升一級范式，表就拆得越碎，查詢時連接越多。4NF要求消滅多值依賴，實踐中往往過度設(shè)計。

Roth的路線完全不同：不拆表，改數(shù)據(jù)結(jié)構(gòu)。用嵌套關(guān)系直接表達(dá)多值依賴，既保留范式化的好處，又避免連接的代價。

論文里的Figure 3-1，畫的是一個嵌套關(guān)系模式。把它和MongoDB的集合定義并排放，幾乎能逐行對應(yīng)。ename是標(biāo)量，Children是文檔數(shù)組，Skills是嵌套更深的數(shù)組。Exams嵌在Skills里，三層深度。

這種結(jié)構(gòu)在SQL里要拆四張表：employees、children、skills、exams。查詢一個員工的完整信息？四個JOIN。MongoDB呢？一個find，投影一下就行。

Roth在1986年就證明了：嵌套關(guān)系的表達(dá)能力不低于扁平關(guān)系，而且操作代價更優(yōu)。但工業(yè)界花了30年才跟上。

一個冷知識：對象數(shù)據(jù)庫為什么死了

90年代有過一陣對象數(shù)據(jù)庫熱潮，GemStone、ObjectStore、Versant，名字現(xiàn)在都沒人記得。它們也想解決嵌套數(shù)據(jù)的問題，但做法太激進(jìn)：把內(nèi)存里的對象圖直接持久化，拋棄了關(guān)系代數(shù)。

結(jié)果是查詢語言一團(tuán)糟，優(yōu)化器做不出來，性能被SQL吊打。Roth的論文其實給過正確答案：保留關(guān)系代數(shù)，擴(kuò)展它，而不是扔掉它。

MongoDB的聚合管道就是這條路線。$match、$project、$sort，全是關(guān)系操作。只是操作的對象從行變成了文檔，從標(biāo)量變成了嵌套結(jié)構(gòu)。

對象數(shù)據(jù)庫死了，文檔數(shù)據(jù)庫活了。區(qū)別不在于嵌套不嵌套，而在于有沒有扎實的代數(shù)基礎(chǔ)。Roth的論文提供了這個基礎(chǔ)，MongoDB的工程師重新發(fā)現(xiàn)了它——或者至少，獨(dú)立 converged 到了同樣的設(shè)計。

有個細(xì)節(jié)挺有意思。Roth的論文引用了一篇1982年的日文論文，作者是K. Tanaka。那篇論文更早提出了非第一范式的想法，但用日語寫的，國際學(xué)術(shù)界沒注意到。Roth把它挖出來，用英文重寫，搭好了完整的理論框架。

學(xué)術(shù)圈的傳播延遲，和工業(yè)圈的采納延遲，疊加出了39年的時差。

現(xiàn)在的MongoDB工程師，有多少讀過Roth的論文？我猜不多。但聚合管道的每一個操作符，都在執(zhí)行論文里的數(shù)學(xué)定義。$unwind不是魔法，是unnest。$group不是黑科技，是aggregate with grouping。

這像是建筑工人沒讀過結(jié)構(gòu)力學(xué)，但蓋的樓正好符合力學(xué)原理。工程直覺和數(shù)學(xué)理論，有時候會在終點(diǎn)相遇。

1986年的論文，現(xiàn)在還在arXiv上能下到。39頁，定義、定理、證明，標(biāo)準(zhǔn)的學(xué)術(shù)格式。最后一節(jié)是"Future Work"，Roth列了幾個開放問題：遞歸查詢、完整性約束、分布式實現(xiàn)。

遞歸查詢后來有了$graphLookup。完整性約束MongoDB加了Schema Validation。分布式？那是另一個故事了，CAP定理的戰(zhàn)場。

Roth在2000年代初離開了學(xué)術(shù)界，去了工業(yè)界。他的LinkedIn停更在2015年。不知道他有沒有用過MongoDB，有沒有意識到自己的理論變成了幾十億市值產(chǎn)品的地基。

如果文檔數(shù)據(jù)庫早點(diǎn)流行，Roth的名字會不會像Codd一樣家喻戶曉？歷史沒有如果。但讀他的論文，你能感覺到一種錯位：正確的想法，生在了錯誤的時間。

現(xiàn)在MongoDB的文檔里，從來沒提過Roth。宣傳材料講"為開發(fā)者設(shè)計"，講"靈活的數(shù)據(jù)模型"，不講代數(shù)、不講范式、不講1986年的那篇論文。這也沒錯，工程師不需要知道理論來源，就像用哈希表不需要知道Knuth。

但知道來源之后，你看MongoDB的眼神會變。那些"自然而然"的設(shè)計選擇，原來都有出處。$unwind的命名有點(diǎn)怪？unnest更怪，但至少誠實。數(shù)組嵌套的限制、聚合管道的執(zhí)行順序、內(nèi)存使用的邊界條件——全能在論文里找到原型。

最后留個開放問題：如果你的數(shù)據(jù)天然是嵌套的，你會為了迎合SQL的范式，硬拆成十幾張表，還是直接用文檔模型，讓結(jié)構(gòu)跟著數(shù)據(jù)走？Roth在1986年投了后者一票，39年后，大多數(shù)新系統(tǒng)也這么選了。但銀行核心交易、財務(wù)總賬這些場景，SQL still rules。是場景真的不同，還是慣性還沒打破？