第1章: SQLとは何か — 宣言的言語とリレーショナルモデルの本質

SQLを一言で言うと

SQL（Structured Query Language）とは、リレーショナルデータベースに対して「欲しい結果」を宣言的に記述する問い合わせ言語です。 1974年にIBMのDonald ChamberlinとRaymond Boyceが発表した「SEQUEL」が原型で、1986年にANSIによって標準化されて以降、 商用DB・オープンソースDB・分析エンジンを問わず事実上の標準として君臨し続けています。

2026年時点でもSQLはStack Overflow Developer Survey 2024で使用言語の第4位（51.0%）、 DB-Engines Rankingの上位4つ（Oracle, MySQL, SQL Server, PostgreSQL）はすべてSQL系。 NoSQLやグラフDBの台頭を経てなお、主要な分散DB（CockroachDB, TiDB, Spanner, Amazon Aurora DSQL）と OLAPエンジン（Snowflake, BigQuery, DuckDB, ClickHouse）はSQLを第一級の問い合わせインターフェースに据えています。

宣言的(Declarative) vs 手続き的(Imperative)

SQLの最大の特徴は、「WHAT（何が欲しいか）」だけを書き、「HOW（どう取るか）」は書かないという点にあります。 この設計哲学が、半世紀にわたってSQLを第一線で戦わせ続けてきた最大の武器です。

同じ問い「30歳以上のユーザの平均年齢」を、手続き的に書いた場合とSQLで書いた場合を比べてみましょう。

# 手続き的なコード(Python) — HOWを全て記述する
total = 0
count = 0
for user in users:
    if user.age >= 30:
        total += user.age
        count += 1
avg = total / count if count > 0 else None

-- SQL — WHATだけを記述する
SELECT AVG(age) FROM users WHERE age >= 30;

SQLはループも条件分岐も明示せず、「平均を出して欲しい」という結果だけを述べています。 どうやってデータを読むか（インデックスを使うのか、並列で処理するのか、集約を先にするのか）は、 DBMSの「オプティマイザ」が自動で決定します。

graph LR
    A["SQL文 (WHAT)"] --> B["Parser"]
    B --> C["Optimizer<br/>(HOWを決定)"]
    C --> D["Executor"]
    D --> E["結果"]
    style A fill:#3b82f6,color:#fff
    style C fill:#8b5cf6,color:#fff
    style E fill:#14b8a6,color:#fff

リレーショナルモデル — SQLの数学的基盤

SQLの土台は、1970年6月にE. F. Coddが論文「A Relational Model of Data for Large Shared Data Banks」で提唱したリレーショナルモデルです。 Codd以前のデータベースは階層型（IBM IMS）やネットワーク型（CODASYL）で、 アプリケーションはデータの物理配置（ポインタ）に縛られていました。 Coddはこれを集合論と述語論理の用語で再定義し、物理的な格納方法からアプリケーションを解放しました。

基本語彙 — 関係・タプル・属性

SQLで日常的に使う「テーブル・行・列」という言葉は、実はリレーショナルモデルの数学的概念を実装視点に読み替えたものです。 両者の対応を押さえておくと、関係代数の議論にすんなり入れます。

集合としての関係 — 順序も重複も無い

純粋なリレーショナルモデルでは、関係は集合であり、行の順序も重複も存在しません。 SQLは実用上この制約を緩め、重複を許す「マルチセット(bag)」を採用していますが、 これは実装上の妥協であり、理論とのズレを生みます（`SELECT DISTINCT` や `UNION` vs `UNION ALL` の存在理由）。

graph TD
    subgraph "関係 users"
      T1["(1, Alice, 30)"]
      T2["(2, Bob, 25)"]
      T3["(3, Carol, 42)"]
    end
    subgraph "属性 (スキーマ)"
      A1[id: INTEGER]
      A2[name: TEXT]
      A3[age: INTEGER]
    end
    A1 -.-> T1
    A2 -.-> T1
    A3 -.-> T1

閉包性と合成可能性 — なぜSQLは短く書けるのか

リレーショナルモデルが持つ最も強力な性質が「閉包性 (closure)」です。 関係代数の演算子（選択σ、射影π、結合⋈、和∪など）はすべて「関係を入力し、関係を出力する」。 つまり演算の結果もまた関係なので、その結果を次の演算の入力にできます。

これは次の2つの強力な帰結をもたらします。

1. 合成可能性 (composability): 複雑なクエリを、単純な演算の合成として表現できる
2. 書き換え可能性: 代数法則（可換律・結合律・分配律）を使って、同じ結果を返す別の計算順序に変換できる → これがオプティマイザの理論的根拠

-- サブクエリは「関係を返す式」なので、テーブルが書ける場所ならどこにでも置ける
SELECT name
FROM (
  SELECT * FROM users WHERE age >= 30         -- ここが関係を返す
) AS adults                                     -- それを次の演算の入力にする
WHERE name LIKE 'A%';

なぜSQLは半世紀君臨し続けるのか

1974年の誕生から2026年まで52年、NoSQLの挑戦もグラフDBの台頭も、SQLを玉座から引きずり下ろせていません。 その理由は単なる「先行者優位」ではなく、SQL自体が持つ3つの構造的優位性にあります。

NoSQLの製品は「水平スケーラビリティ」や「柔軟スキーマ」を武器にSQLを攻撃してきましたが、 その多くが最終的にはSQL-likeな問い合わせ言語（CQL, N1QL, PartiQL）を追加する道を辿りました。 これは「宣言的+集合的+合成可能」という問い合わせモデルの優秀さが、データモデルを越えて普遍的であることの証左です。

第1章のまとめ

• SQLは宣言的言語。WHATを書けばHOWはオプティマイザが決める
• 基盤はE. F. Codd (1970) のリレーショナルモデル。関係=テーブル、タプル=行、属性=列
• 関係代数の閉包性が、サブクエリやCTEの合成可能性と、オプティマイザの書き換え最適化を同時に可能にしている
• SQLが半世紀君臨する理由は数学的基盤・物理独立性・ISO標準化・実行モデル進化の4点セットの構造的優位

次章では、この設計哲学がどのような歴史的な試行錯誤から生まれたのかを追います。 Codd vs SEQUEL、QUEL vs SQLの論争を経て、SQLがどう事実上の標準に育ったのか、半世紀の年表を一気に辿ります。