RDBMS

概要

RDBMS（Relational Database Management System）は、データを行と列からなる表（テーブル）で管理し、表同士の関係（リレーション）によって現実の世界を写し取るデータベース管理システムです。たとえばECサイトなら「顧客」「商品」「注文」をそれぞれ表として持ち、「この注文はどの顧客のものか」を表と表のつながりで表現します。操作にはほぼすべての製品で共通の言語であるSQLを使います。

PostgreSQL、MySQL、SQLite、Oracle Database、SQL Serverなどが代表的な実装で、銀行の勘定系からWebサービスのユーザー管理まで、半世紀近くにわたって業務システムの中核であり続けています。Webアプリケーションを作るとき、サーバの裏側でデータを永続化する場所として最初に候補に挙がるのがRDBMSです。

RDBMSの強みは「データの正しさを守る仕組み」が言語とエンジンの両方に組み込まれていることです。トランザクションによる更新の保護、制約による不正データの排除、正規化を前提とした設計技法など、数十年かけて磨かれた道具立てがそろっています。

なぜ生まれたか

RDBMS以前の1960年代、データベースの主流は階層型やネットワーク型と呼ばれるモデルでした。これらはデータ同士をポインタでつなぐ構造で、「このデータを取るにはこの経路をたどる」というアクセス手順そのものをプログラムに書く必要がありました。データの持ち方を変えると、それを使うプログラムもすべて書き直しになり、変化に非常に弱かったのです。

1970年、IBMの研究者エドガー・F・コッドが「データを数学の集合論に基づく『関係（リレーション）』として扱えば、物理的な格納方法とデータの論理的な意味を分離できる」というリレーショナルモデルを提唱しました。利用者は「何が欲しいか」だけを宣言し、どうやって取り出すかはシステムが決める——この発想により、データ構造の変更にプログラムが引きずられる問題が大きく緩和されました。この理論を実装したのがRDBMSであり、問い合わせを宣言的に書くための言語としてSQLが生まれました。

詳細

テーブル・キー・リレーション

RDBMSではデータの種類ごとにテーブルを定義します。テーブルの各列には型（整数、文字列、日付など）と制約を宣言でき、たとえば「メールアドレスは重複禁止」「年齢はNULL不可」といったルールをデータベース側で強制できます。アプリケーションのバグでおかしなデータが混入するのを、最後の砦として防いでくれるわけです。

各行を一意に識別する列を主キー（primary key）と呼び、他のテーブルの主キーを参照する列を外部キー（foreign key）と呼びます。「注文テーブルの customer_id 列は顧客テーブルの id を参照する」と宣言しておけば、存在しない顧客を指す注文は作れなくなります（参照整合性）。この主キーと外部キーのつながりこそがリレーショナルモデルの核心で、SQLのJOINによって複数の表を組み合わせた問い合わせが可能になります。

整合性を守る仕組み

RDBMSのもう一つの柱がトランザクションです。複数の更新を「全部成功か、全部なかったことに」という単位にまとめ、途中の失敗や同時アクセスによるデータ破壊を防ぎます。この保証の性質を整理した語彙がACIDで、RDBMSが業務システムで信頼され続ける最大の理由がここにあります。

問い合わせが遅いときの主要な道具がインデックスです。RDBMSは受け取ったSQLを解析して実行計画（どのインデックスを使い、どの順で表を読むかの手順書）を立てるオプティマイザを内蔵しており、開発者は EXPLAIN 文でその判断を確認しながら性能をチューニングします。

こうした部品を組み合わせた、RDBMSの内部のおおまかな構成は次のとおりです。クライアントは「何が欲しいか」をSQLで宣言するだけで、その先の取り出し方はすべてRDBMS側が引き受けます。

設計と実務での位置づけ

テーブル設計では「同じ事実を二か所に書かない」ことを原則にテーブルを分割する正規化が基本になります。設計→SQLでの操作→インデックスによる性能改善、という一連の流れが、RDBMSを使う開発の基本サイクルです。

代表的な実装には、それぞれ性格があります。PostgreSQLは機能の豊富さと標準準拠で近年のWeb開発の第一候補になることが多く、MySQL（およびMariaDB）は長らくWebの定番として実績が厚く、SQLiteはサーバ不要の組み込み型でモバイルアプリやテスト環境に広く使われています。アプリケーションからはORMを介して操作することも多く、その場合もRDBMSの仕組みの理解が性能問題の解決に直結します。

一方で、RDBMSは単一ノードでの整合性保証を前提に設計されているため、書き込みを複数台に分散する水平スケーリングは苦手です。この制約から、整合性を緩めて分散に振り切ったNoSQLという選択肢が生まれました。とはいえ大半のアプリケーションではRDBMSが依然として最初の選択であり、「まずRDBMSで設計し、明確な理由があるときだけ他を検討する」のが実務の定石です。