CUBE 運算子：一個 SQL 子句就一次算完 N 個維度上所有的 group-by，而且結果仍是一個關聯。
分析工作習慣同時沿多個維度做彙總，但 SQL 只有五個聚合函式與 GROUP BY，產出的是零維或一維聚合，因此一張六維交叉分析表得手寫成 64 個 GROUP BY 的 64 路 UNION。本論文定義 CUBE 運算子，一句敘述就算出 N 個分組欄位所有子集合的聚合；同時定義其不對稱的退化形式 ROLLUP，只產生逐層變粗的小計，僅比核心 group-by 多出 N 列。為了讓這些超級聚合（super-aggregate）列仍然是關聯式的，作者在每個分組欄位的定義域上多加一個 ALL 值，用來代表該次聚合所涵蓋的集合，於是 cube 就是一個普通的關聯，可以和其餘 SQL 自由組合。在計算面，論文把聚合函式分成 distributive、algebraic、holistic 三類，並指出前兩類可以把核心 group-by 的暫存區（scratchpad）逐層往上折疊成超級聚合，而不必重新掃描原始資料表。這套設計幾乎立刻被採用：SQL Server 6.5 當時已出貨 CUBE 與 ROLLUP，SQL 標準也吸收了這套語法。
1990 年代中期，決策支援的工作流程是一個 extract-visualize-analyze 迴圈：先把彙總後的資料從 SQL 資料庫抽出成檔案或資料表，再放進試算表或視覺化工具呈現，然後據此擬定下一個查詢。這個迴圈的視覺化端早就以 N 維方式思考——Excel 樞紐分析表、內建交叉分析的報表工具、Microsoft Access 的 TRANSFORM-PIVOT 運算子、Essbase 的多維陣列——但資料庫端只有 COUNT、SUM、MIN、MAX、AVG，以及每個群組只回傳一列的 GROUP BY。各家廠商各自以互不相容的方式補洞：Red Brick 加了 Rank、N_tile、Ratio_To_Total 與累積型聚合，Informix Illustra 與 IBM DB2 Common Server 則讓使用者以 Init、Iter、Final 三個 callback 註冊新的聚合函式。聚合也絕非冷門需求——論文自己對標準基準測試的統計顯示，TPC-D 的 16 個查詢裡就有 27 個聚合與 15 個 GROUP BY，連 OLTP 基準測試裡都出現聚合。真正缺的，是一個在形狀上與下游工具同樣是 N 維的關聯式運算子。
cube 運算子把 N 個聚合屬性各視為 N 維空間的一個軸：先用一般的 GROUP BY 算出核心（core），再把所有以 ALL 取代某個分組欄位子集合而得的超級聚合 UNION 進來。這些子集合正是分組欄位的冪集合，共 2^N 種分組，其中 2^N - 1 種屬於超級聚合。關鍵在於結果是一個與核心同 schema 的關聯，因此 cube 的輸出可以再被 SELECT、被 JOIN、被嵌進更複雜的非程序式分析程式，而不只是報表工具的一個功能。由於結果列數是各維度 (Ci + 1) 的乘積，只要維度基數夠大，cube 其實只比核心 group-by 稍大一點。
論文沒有把 schema 撐成 2^N 個欄位，而是在每個維度的定義域上多加一個 ALL 值，用來標示這一列是超級聚合。依照 Joe Hellerstein 的建議，ALL 不該讀成「未知」，而該讀成該次聚合所涵蓋的那個集合，所以 Model.ALL 就等於集合 {Chevy, Ford}。這個讀法正好定義了關聯運算子在 cube 輸出上的語意——等於、大小比較與 IN——而 ALL() 函式會回傳其背後的集合，套用在任何一般值上則回傳 NULL。作者也坦承這等於把 SQL 拖進巢狀關聯的世界，讓關聯本身成為值，並直言這對關聯式系統是一大步，而非免費午餐。
對 drill-down 報表而言完整的 cube 是殺雞用牛刀，而且部分結果根本沒有意義：當分組屬性彼此函數相依，例如年、週、日，多數 cube 格子毫無意義。因此 ROLLUP 只產生那條線性的超級聚合鏈，從最右邊的欄位開始逐一換成 ALL，一路到總計，使得 N 維 roll-up 只在答案集合中多加 N 列，而非指數級的列數。它的答案集合天然是循序的，這正是 running sum、running average 這類累積型聚合所需要的，而完整 cube 本質上是非線性、多維的。這也正是論文開頭那張 Sales by Model by Year by Color 報表的形狀。
GROUP BY、ROLLUP 與 CUBE 之間有一組簡潔的代數：ROLLUP 的 CUBE 還是 CUBE，GROUP BY 的 ROLLUP 還是 ROLLUP。因此論文把三者排進同一個複合子句、能力最強的放在最內層——對某些欄位 group by、對某些欄位 roll up、對其餘欄位 cube——於是一句敘述就能對 manufacturer 分組、對年月日 roll up、再對 color 與 model 做 cube。因為這是 GROUP BY 的語法擴充而非新敘述，最佳化器看到的是一個聚合運算子，而不是 64 個彼此無關查詢的 UNION。同一套擴充也把分組清單一般化成可帶 AS 相關名稱的運算式，直方圖至此才真正能直接寫出來。
本論文最歷久不衰的貢獻，是依「部分聚合需要攜帶多少狀態」來分類聚合函式。若存在某個 G，使得把子聚合再聚合就能得到正確答案，該函式即為 distributive，COUNT、SUM、MIN、MAX 都屬此類，其中 COUNT 對應的 G 是 SUM。若子聚合可以用固定大小的 M-tuple 概括、再由函式 H 收尾，則為 algebraic：平均值攜帶 sum 與 count，標準差、MaxN、MinN 與質心也是同樣道理。若狀態大小沒有常數上界，則為 holistic，例如中位數、眾數與 rank。只有前兩類能從較低維度的結果推出超級聚合，而不必回頭讀原始資料；同一個性質也正是分割式與平行聚合能夠成立的原因。
作者承認，資深 SQL 實作者一定會對 NULL 之外再多一個非值感到恐懼：ALL 需要新關鍵字、需要在欄位定義與系統目錄中加上 ALL NOT ALLOWED 屬性，還要在各比較運算子中處理特例。於是他們提出極簡替代方案：本該放 ALL 的地方改放 NULL、不實作 ALL()，並加入一個布林函式 GROUPING()，當 select 清單中的元素是超級聚合佔位符時回傳 TRUE。範例中的總計因此變成 (NULL, NULL, NULL, 941, TRUE, TRUE, TRUE)，而不是 (ALL, ALL, ALL, 941)。這正是 Microsoft SQL Server 6.5 實際出貨的設計，也是 SQL 標準最後採納的設計。
cube 的答案常常需要既非分組欄位、也非聚合值的欄位——例如部門編號旁邊的部門名稱——而現行 SQL 並不允許。論文主張，只要這種 decoration 欄位對聚合欄位函數相依，就可以出現在 SELECT 清單中；而當超級聚合的 tuple 已不足以決定它時，就回傳 NULL：指定了 nation 時 continent 會填入值，但 nation 為 ALL 的列上 continent 就是 NULL。接著論文為周邊的設計模式命名：中央一張記錄事件細節的 fact table，加上為各維度提供屬性與聚合粒度的側表，每個維度一張表稱為 star schema，粒度本身再拆開則稱為 snowflake schema。論文也提醒，這些粒度實際上構成的是 lattice 而非純階層，因為日可以巢狀於週，週卻無法乾淨地巢狀於月、季或年。
CUBE 先對 select 清單中所有屬性做一次標準 GROUP BY，得到 cube 的核心。接著把整個 cube 的每個超級聚合 UNION 進來，被摺疊掉的欄位以 ALL 取代；對 N 個屬性而言，這會產生 2^N - 1 種超級聚合分組。若各維度基數為 C1 到 CN，結果關聯的列數就是各 (Ci + 1) 的乘積，每個定義域多出來的那個值即 ALL：範例中 2 個車款、3 個年份、3 種顏色的 18 列 SALES 表，會變成 3 x 4 x 4 共 48 列的 cube。ROLLUP 則是同一套構造，只保留那條「從最右邊欄位起逐一換成 ALL」的 tuple 鏈。
聚合函式透過三個 callback 與一塊私有 scratchpad handle 掛進系統，設計取自 Informix Illustra 與 IBM DB2 Common Server：Init（start）配置並初始化 handle，Iter（next）把一個值折進去，Final（end）由儲存的狀態算出結果並釋放 handle。以 Average 為例，handle 中的 count 與 sum 初始化為零，每遇到一個非 null 值就把 count 加一、把值加進 sum，最後以 sum 除以 count。較進階的系統還允許聚合函式宣告計算成本，好讓查詢最佳化器盡量減少呼叫昂貴函式的次數。這套 callback 設計（成本宣告除外）後來成為 SQL 標準草案的一部分，也是使用者自訂聚合能套用在 cube 上的前提。
最簡單的 cube 演算法是一開始就為每個 cube 格子各配置一個 handle。當 tuple (x1, x2, ..., xN, v) 進來時，Iter(handle, v) 會被呼叫 2^N 次——每個座標在每個位置上不是 xi 就是 ALL 的格子各一次。所有輸入 tuple 處理完後，系統再對 cube 中 (Ci + 1) 乘積個格子逐一呼叫 Final。若基底資料表基數為 T，這總共是 T x 2^N 次 Iter 呼叫；對 holistic 聚合而言，這也是論文所知的唯一方法，而 roll-up 則有對應的 order-N 演算法。
對 distributive 函式來說，從核心 group-by 而非從基底資料表推算超級聚合便宜得多，可把 Iter 呼叫次數約略降低 T 倍。把核心存成一個各軸大小為 Ci + 1 的 N 維陣列，再逐一投影掉一個維度，就得到每一片低一維的切片：CUBE(ALL, x2, ..., xN) = F({CUBE(i, x2, ..., xN) | i = 1..C1})。做 N 次這樣的計算即可得到所有 N-1 維超級聚合，然後一次少一個維度地重複下去，直到全部為 ALL 的那一格。若某個低維格子可由兩片切片中的任一片推得——以交叉分析表來說，就是聚合最底下那一列或最右邊那一欄——兩者答案相同，因此演算法應沿基數較小的那個軸聚合。
algebraic 聚合無法用已完成的子聚合「值」往上疊，因為超級聚合需要的是中間狀態——平均值背後的 sum 與 count，而不是平均值本身。因此 cube 演算法為核心的每個格子各保留一個 handle（這本來就是 group-by 運算的一部分），核心算完後，再把這一整組 handle 交給各個 N-1 維的超級聚合。這需要一個新的 callback：Iter_super(&handle, &handle)，把右邊的子聚合 scratchpad 折進左邊的超級聚合 scratchpad。每一層的 handle 再往上傳給更高層的超級聚合，如此反覆直到 (ALL, ALL, ..., ALL) 那一格算完並呼叫 Final；「先沿較小基數聚合」的排序原則在每一層都適用。
若聚合結果放得進記憶體，就用以聚合欄位為鍵的陣列或雜湊表，每個項目存一個聚合值；若維度值是長字串，則維護一張雜湊符號表把每個字串映射成整數，讓值變得稠密，cube 便能存成 N 維陣列。若放不下，就退回標準 group-by 機制——以排序或 hybrid hashing 把相同值聚在一起，再用循序掃描聚合；ROLLUP 特別適合排序，因為使用者通常本來就要排序過的答案。超級聚合通常比核心小上好幾個數量級，所以即使核心放不進記憶體，超級聚合多半仍放得下。稀疏的核心只該物化非 null 的格子，並以雜湊或 B-tree 建索引；當來源資料橫跨多顆磁碟或多個節點時，各分割先平行聚合，再以與 algebraic／distributive 折疊完全相同的邏輯合併部分結果。
SQL Server 6.5 約半年的實地經驗顯示，客戶會把 cube 算出來存起來，再對底層資料表定義 trigger，讓資料變動時動態更新 cube——這帶出了計算章節沒有回答的問題。以 max 為例，insert 很簡單：走訪涵蓋這筆新記錄的 2^N 個超級聚合格子，取現值與新值的較大者；而且可以提早結束，因為一個值只要輸掉一次比較，在所有較低維度也會輸。delete 就不同了：刪掉目前的最大值，會迫使 2^N 個格子重新尋找全域最大值，看起來得重算整個 cube，所以 max 對 SELECT 與 INSERT 是 distributive，對 DELETE 卻是 holistic。論文因而提出 SELECT、INSERT、DELETE 各自有一組正交的 distributive／algebraic／holistic 階層，指出 COUNT 與 SUM 在三者下皆為 algebraic 故易於維護，其餘則留作待研究的課題。
CUBE、ROLLUP、GROUPING SETS 與 GROUPING() 幾乎原封不動地進入 SQL:1999，如今出現在 DB2、Oracle（另加 GROUPING_ID 以區分多欄位情況）、SQL Server、PostgreSQL 9.5 之後、MySQL 的 WITH ROLLUP、Hive、Spark SQL、BigQuery、Snowflake 與 DuckDB——分析師今天敲的語法，就是這篇論文寫下的語法。distributive／algebraic／holistic 三分法更完全跳出 OLAP，成為思考部分聚合與聚合下推的通用語彙：MapReduce 的 combiner、Spark 的 reduceByKey 與 aggregateByKey、Flink 的 AggregateFunction（createAccumulator、add、merge、getResult），本質上就是本論文 Init、Iter、Iter_super、Final 介面的化名。近似 sketch——計算相異值的 HyperLogLog、估計分位數的 t-digest 與 KLL——最好理解為業界對論文避開的 holistic 類別所給的答案：把 holistic 函式轉成狀態有界的 algebraic 函式。維護章節提出的物化問題則開啟了一整條研究線：Harinarayan、Rajaraman 與 Ullman 的貪婪式 view selection、Agrawal 等人的 PipeSort 與 Overlap 演算法、BUC 與 Dwarf，以及增量物化檢視表維護的一般理論。在商業上，cube 抽象成為一個產品類別，從 Arbor Essbase、Microsoft OLAP Services，一路到 Apache Kylin 與 Apache Druid，都以與此處描述相近的方式預先計算 cuboid。即使是放棄預算 cube 的欄式資料倉儲，也保留了這篇論文所確立的詞彙：維度、度量、roll-up、drill-down、star schema 與 snowflake schema。
“The novelty is that cubes are relations. Consequently, the cube operator can be imbedded in more complex non-procedural data analysis programs.”
“A six dimension cross-tab requires a 64-way union of 64 different GROUP BY operators to build the underlying representation.”
“Aggregate function F() is holistic if there is no constant bound on the size of the storage needed to describe a sub-aggregate.”