データベースの歴史

このレッスンで分かること

階層型 → ネットワーク型 → RDB → NoSQL → NewSQL の流れ

各時代がどんな課題を解こうとしたのか

いま使う技術がどの世代の遺産を受け継いでいるのか

データベースの歴史とは

階層型・ネットワーク型から RDB、NoSQL、NewSQL までの流れを辿る。本レッスンでは、データベースの歴史の基本から実際の使いどころまでを整理し、現場で迷わず使える形に落とし込みます。

1960 年代：階層型データベース

最初期のデータベースは 階層型 でした。IBM の IMS が代表で、データを木構造で表現します。アポロ計画の部品管理にも使われました。

問題は 柔軟性のなさ です。親子関係が固定されているため、「ある社員が複数の部署に所属する」といった多対多の関係を表現できませんでした。

1970 年前後：ネットワーク型データベース

階層型の制約を緩めたのが ネットワーク型 で、CODASYL モデルとも呼ばれます。子が複数の親を持てるようになりましたが、データ構造とアクセスパスが密結合で、スキーマ変更が地獄でした。

1970 年：リレーショナルモデルの登場

IBM 研究所の E.F.Codd が「A Relational Model of Data for Large Shared Data Banks」という論文を発表し、世界が変わります。Codd の主張は「データを集合論的な関係 (relation) として扱えば、アクセスパスとデータを分離でき、宣言的に問い合わせられる」というものでした。

diagram (will load when visible)

これを実装したのが System R（IBM）と Ingres（UCB）です。System R から SQL が生まれ、Ingres は PostgreSQL の祖先になります。1979 年には Oracle（当時は Relational Software 社）が、SQL を実装した初の商用リレーショナル DB として登場しました。

1980 - 1990 年代：RDB の覇権

1986 年に SQL が ANSI 標準化され、業界が一気に RDB に収束しました。Oracle、DB2、SQL Server、MySQL、PostgreSQL が出揃い、20 年以上「データベース = RDB」という時代が続きます。

SQL クエリ

SELECT name FROM users WHERE id = 1;

この宣言的な書き方は、いまでも同じです。「何が欲しいか」を書き、「どう取るか」は DBMS に任せる という発想は当時革命的でした。

2000 年代：Web 規模の壁と NoSQL

2000 年代後半、Google や Amazon が直面したのは「1 台の RDB に収まらない規模」でした。アクセスは秒間数百万、データは数十ペタバイト。垂直スケール（マシンを強化）には限界があります。

そこで生まれたのが NoSQL です。Google は BigTable を発表し、Amazon は Dynamo 論文で結果整合性を世に広めました。これらを参考に Cassandra、MongoDB、Redis、Riak、CouchDB が次々と登場します。

合言葉は CAP 定理 でした。一貫性 (Consistency)、可用性 (Availability)、分割耐性 (Partition tolerance) のうち、ネットワーク分断時には 2 つしか選べないというものです。多くの NoSQL は AP（可用性と分割耐性）を選び、強整合性を諦めました。

2010 年代：NewSQL の登場

NoSQL を使ってみた現場の声は「JOIN がない」「SQL で書きたい」「ACID が欲しい」でした。「スケールも欲しいし SQL も欲しい」という欲張りな要件に応えたのが NewSQL です。

Google Spanner、CockroachDB、TiDB、YugabyteDB などが代表です。これらは内部で コンセンサスアルゴリズム (Raft や Paxos) を使い、分散環境でも ACID を保証します。

NoSQL は「スケールのために整合性を捨てた」。NewSQL は「分散合意で整合性を取り戻した」。

各世代から受け継いだもの

階層型 → 木構造の発想は XML や JSON の DB に
ネットワーク型 → グラフ DB の祖先
RDB → SQL という共通言語と正規化理論
NoSQL → 水平分散・スキーマレス・結果整合性
NewSQL → 分散環境での ACID と SQL 互換

やってみよう

SQLite で CREATE TABLE を実行し、Codd のリレーショナルモデルを体感する
Redis を立て SET key value を試し、KVS の単純さを味わう
TiDB Cloud の無料プランで分散 SQL を触ってみる

よくある質問

Q. このトピックは実務でどう役立ちますか？

A. DB のクエリ最適化、API 設計、データ構造の選択など、設計判断の根拠になります。表面的にライブラリを使うだけでなく「なぜそれが速いのか」を理解できると、性能問題を未然に防げます。コーディング面接でも頻出のテーマです。

Q. 計算量はどう求めれば良いですか？

A. ループのネストごとに掛け算する、再帰なら漸化式から解く、というのが基本です。Big-O 表記は定数倍と低次の項を無視するため、n の指数（n²、n log n など）に注目してください。最悪・平均・最良の 3 つを意識すると説得力が増します。

Q. 覚えるべき定番アルゴリズムは何ですか？

A. 二分探索、クイックソート/マージソート、BFS/DFS、ダイクストラ、DP の基本問題（フィボナッチ・ナップサック）が必修です。これらを「白紙から書ける」状態にすると、応用問題が一気に解けるようになります。

次のレッスン

次は エンティティ関係モデル (ER) で、階層型・ネットワーク型から RDB、NoSQL、NewSQL までの流れを辿るを学びます。

事前確認 — 進む前に次の 3 つができることを確認しましょう。

データベースの歴史の要点を自分の言葉で説明できる
このレッスンの最小コード (または操作手順) を見ずに書ける
練習問題やクイズで間違えた箇所を読み直して理解した

理解度チェック (30 秒)

Q. データベースの歴史とは何か、1 文で説明してください。

この章のポイント

A. 本文の「このレッスンで分かること」または冒頭の説明文を見直し、自分の言葉で要約できれば OK。詰まったら本レッスンの最初の H2 セクションを読み返してみましょう。

関連レッスン