情報処理試験を勉強していると、「関係データベースって何？普通のデータベースと何が違うの？」と疑問に感じる場面が必ずあります。
結論から言えば、関係データベースは現代のITシステムで最も広く使われているデータ管理の仕組みであり、IPA試験でも全区分で繰り返し問われる最重要テーマです。
対象試験と出題頻度
関係データベース（RDB）は、ITパスポート・基本情報技術者・応用情報技術者のすべてで出題されるテーマです。
「表・行・列の用語対応」「他のデータベースモデルとの違い」「主キー・外部キーの役割」など、出題の切り口が幅広く、データベース分野の土台となる知識です。
詳細をクリックして確認
ITパスポート
基本情報技術者
応用情報技術者
★★★★★
ランクS（超重要）絶対に覚える必要あり
用語の定義
関係データベース（RDB：Relational Database）とは、一言で言うと
「データを2次元の表（テーブル）で管理し、表どうしを列の値で関連付けるデータベース方式」
のことです。
イメージとしては、「Excelのワークシートが複数枚あり、シート間がIDで紐づいている状態」です。
Excelで「顧客一覧」「注文一覧」「商品一覧」のシートを作り、顧客IDや商品IDを使ってシート間のデータを結び付けた経験がある人は多いはずです。
関係データベースはまさにこの構造をシステムとして厳密に管理する仕組みです。
📊 関係データベースの基本情報
| 項目 | 内容 |
|---|---|
| 英語名 | Relational Database（RDB） |
| 提唱者 | E.F.コッド（1970年、IBM） |
| 理論的背景 | 集合論・述語論理に基づく関係モデル |
| 操作言語 | SQL（Structured Query Language） |
| 代表的な製品 | Oracle Database、MySQL、PostgreSQL、SQL Server |
解説
なぜ「表」でデータを管理するのか
関係データベースが登場する以前は、「階層型」や「ネットワーク型」と呼ばれるデータベースが主流でした。
これらはデータ同士をポインタ（アドレス）で直接つないで管理するため、構造変更やデータ検索のたびにプログラムの大幅な修正が必要でした。
1970年にIBMのE.F.コッドが発表した関係モデルは、データの物理的な格納方法と論理的な構造を分離し、すべてを「表」という統一された形式で扱うことを提案しました。
これにより、データ構造の変更がプログラムに波及しにくくなり、SQLという標準言語で誰でも同じ方法でデータ操作できる環境が整いました。
表の構成要素：テーブル・行・列
関係データベースの構造を理解するうえで、用語の対応関係を正確に押さえることが不可欠です。
関係モデル（理論側）と関係データベース（実装側）では呼び方が異なるため、以下の対応を確実に覚えてください。
📊 関係モデルと関係データベースの用語対応
| 関係モデル（理論） | 関係データベース（実装） | 意味 |
|---|---|---|
| 関係（リレーション） | 表（テーブル） | データの集合全体 |
| タプル | 行（レコード） | 1件のデータ |
| 属性（アトリビュート） | 列（カラム／フィールド） | データ項目の種類 |
| 定義域（ドメイン） | データ型 | 値の取り得る範囲・形式 |
図解：関係データベースのテーブル構造
具体例として「社員」テーブルを見てみましょう。
テーブル名：社員
| 社員ID（主キー） | 氏名 | 部署ID（外部キー）🔗 | 入社年 |
|---|---|---|---|
| 001 | 田中太郎 | D01 | 2020 |
| 002 | 鈴木花子 | D02 | 2021 |
| 003 | 佐藤一郎 | D01 | 2022 |
テーブル名：部署
| 部署ID（主キー）🔑 | 部署名 |
|---|---|
| D01 | 営業部 |
| D02 | 開発部 |
読み方ガイド：
🔑 主キー … その表の中で行を一意に特定する列（重複・空値は不可）
🔗 外部キー … 他の表の主キーを参照する列（ここが「つなぎ役」）
オレンジ背景のセル が一致することで、田中太郎 → D01 → 営業部 のように所属先がわかる
主キーと外部キー
表と表を関連付ける仕組みの中心が「主キー」と「外部キー」です。
主キー（Primary Key）：表の各行を一意に識別するための列です。値の重複とNULL（空値）は許されません。先ほどの例では「社員ID」「部署ID」がそれぞれの表の主キーです。
外部キー（Foreign Key）：他の表の主キーを参照する列で、表間のリレーション（関連）を作ります。社員テーブルの「部署ID」は部署テーブルの主キーを参照しており、これが外部キーです。
主キーと外部キーの関係
社員テーブル
社員ID 🔑主キー
氏名
部署ID 🔗外部キー
部署テーブル
部署ID 🔑主キー
部署名
具体例：田中太郎の所属部署はどう分かる？
社員テーブルの1行
社員ID：001
氏名：田中太郎
部署ID：D01
部署テーブルの1行
部署ID：D01
部署名：営業部
「営業部」所属！
※ 外部キーには参照先テーブルの主キーに存在する値しか入れられない（参照整合性制約）
→ 社員テーブルに「D99」を入れようとしても、部署テーブルにD99がなければエラーになる
他のデータベースモデルとの比較
関係データベースの特徴を明確にするには、他のモデルとの違いを整理するのが近道です。
| モデル名 | データ構造 | 特徴 |
|---|---|---|
| 関係モデル | 2次元の表 | SQLで柔軟に検索・結合可能。現在の主流 |
| 階層モデル | 木構造（ツリー） | 親子関係をポインタで結合。多対多の表現が困難 |
| ネットワークモデル | 網構造（グラフ） | 多対多を表現可能だが構造が複雑 |
| NoSQL（参考） | キーバリュー/ドキュメント等 | 大量データの高速処理向き。スキーマが柔軟 |
では、この用語が試験でどのように出題されるか見ていきましょう。
💡 関係データベースの核心を3行で
・データを2次元の表で管理し、表間を列の値（主キー・外部キー）で関連付ける
・関係モデルの「関係＝表」「タプル＝行」「属性＝列」「ドメイン＝データ型」の対応を覚える
・階層型（木構造）・ネットワーク型（網構造）との構造の違いで区別できるようにする
試験ではこう出る！
関係データベースは、IP・FE・APの午前問題でデータベース方式の基礎知識として繰り返し出題されています。出題パターンは大きく3つに分かれます。
📊 過去問での出題実績
| 試験回 | 出題内容 | 問われたポイント |
|---|---|---|
| FE H25秋 午前 問29 |
関係データベースのデータ構造として適切な説明を選ぶ | ・正解は「データを2次元の表によって表現する」 ・階層型（ポインタ結合）やオブジェクト指向（カプセル化）がひっかけ |
| FE H22春 午前 問29 |
関係データベースの説明として適切なものを選ぶ | ・正解は「データを表として表現し、表間は列の値で関連付けられる」 ・ポインタで結合（階層型）、リンクで結合（ネットワーク型）がひっかけ |
| FE R2免除 問26 |
関係モデルと関係データベースの用語対応を問う | ・正解は「関係は表に対応付けられる」 ・属性の順序やタプルの重複に関する違いがひっかけ |
| IP R6 問60 |
関係データベースの構成要素（表・レコード・フィールド）の用語穴埋め | ・「表→レコード→フィールド」の包含関係を問う ・用語の対応を正確に覚えていれば即答できる |
| IP R4 問83 |
行と列の表形式で表すデータベースモデルを選ぶ | ・正解は「関係モデル」 ・階層モデル、ネットワークモデル、オブジェクトモデルがひっかけ |
📝 IPA試験での出題パターン
パターン1：「データ構造の説明を選べ」
4つのデータベースモデルの説明文が並び、関係データベースに該当するものを選ぶ形式。ひっかけは「ポインタで結合」（階層型）、「リンクで結合・網構造」（ネットワーク型）。キーワード「2次元の表」「列の値で関連付け」が見えたら関係データベースで確定です。
パターン2：「関係モデルとの用語対応を選べ」
理論上の用語（関係・タプル・属性・ドメイン）と実装上の用語（表・行・列・データ型）の対応を問う形式。FE H28春 問26 / R2免除 問26で出題。「関係＝表」の対応さえ覚えていれば正解にたどり着けます。
パターン3：「構成要素の包含関係を埋めよ」
IP R6 問60のように、表・レコード・フィールドの階層関係を穴埋めする形式。ここだけは確実に押さえてください。「表 ⊃ レコード（行）⊃ フィールド（列の値）」の入れ子構造が分かれば即答です。
試験ではここまででOKです。正規化やSQLの詳細は別の出題範囲になるため、この記事では深追いは不要です。
【確認テスト】理解度チェック
ここまでの内容を理解できたか、簡単なクイズで確認してみましょう。
Q. 関係データベースのデータ構造の説明として、最も適切なものはどれでしょうか？
- A. 親レコードと子レコードをポインタで結合し、木構造でデータを管理する。
- B. レコード間の関係をリンクで表現し、木構造だけでなく網構造も表現できる。
- C. データを2次元の表によって表現し、表間は列の値を用いて関連付けられる。
正解と解説を見る
正解：C
解説：
関係データベースは、データを2次元の表で管理し、複数の表を列の値（主キーと外部キー）で関連付ける方式です。FE H25秋 問29やFE H22春 問29で繰り返し出題されている定番の論点です。
選択肢Aは階層型データベースの説明です。階層型はデータをツリー構造で管理し、親子関係をポインタでつなぎますが、多対多の関連を表現できない制約があります。選択肢Bはネットワーク型データベースの説明です。ネットワーク型は階層型の制約を緩和して網構造を扱えますが、構造が複雑になりやすく、現在は主流ではありません。
よくある質問（FAQ）
Q. 関係データベースとRDBMS（関係データベース管理システム）は何が違いますか？
関係データベースは「データを表形式で管理する仕組み・概念」を指し、RDBMSはその概念を実際に動かすためのソフトウェア製品を指します。OracleやMySQL、PostgreSQLはすべてRDBMSです。試験問題では「関係データベース」と「RDBMS」が混在して出題されますが、概念と製品の違いを理解していれば混乱しません。
Q. NoSQLデータベースと関係データベースはどちらを使うべきですか？
用途次第です。データの整合性が最優先される業務システム（銀行、受発注管理など）では関係データベースが適しています。一方、SNSのタイムラインや大規模ログ収集のように、柔軟なスキーマや水平スケーリングが求められる場面ではNoSQLが有利です。IPA試験では「関係データベースが適さないケース」としてAP R5春 問26でドキュメント型データベースとの比較が出題されています。
Q. 「正規化」は関係データベースとセットで覚える必要がありますか？
セットで覚えるべきです。正規化はテーブル設計の冗長性を排除して更新時の不整合を防ぐ手法で、関係データベースの運用に欠かせない考え方です。ただし、正規化自体は独立した出題テーマ（第1～第3正規形の判別問題など）として扱われるため、まず本記事で関係データベースの構造を理解し、その後に正規化を学ぶ順序が効率的です。
Q. 排他制御やトランザクションは関係データベースだけの仕組みですか？
排他制御やトランザクション管理は関係データベースに限った仕組みではありませんが、ACID特性（原子性・一貫性・独立性・耐久性）を厳密に保証する設計は関係データベースの大きな強みです。NoSQLの多くはACID特性を緩和してパフォーマンスを優先するBASEモデルを採用しており、この対比が応用情報レベルで問われることがあります。
