最終更新日：2026年8月11日
fe fe-technology database
まず結論
関係データベース（RDB）とは、データを2次元の表として扱うデータベースです。
その土台になっている考え方が関係モデルです。
基本情報技術者試験では、まず次の対応を押さえます。
関係データベース
→ データを表で表す
関係
→ 表
属性
→ 列
組
→ 行
定義域
→ 属性が取り得る値の集合
試験中に「データを2次元の表によって表現する」と出てきたら、関係データベースを疑います。
さらに、関係モデルの性質として次の点も重要です。
属性の並び順
→ 意味なし
組の並び順
→ 意味なし
属性名
→ 関係内で一意
定義域
→ 複数属性で共有できる
直感的な説明
関係データベースは、見た目だけなら表計算ソフトの表に近い形で考えると分かりやすいです。
たとえば、次のような商品表を考えます。
| 商品番号 | 商品名 | 価格 |
|---|---|---|
| P001 | ノート | 200 |
| P002 | ペン | 150 |
このとき、
表全体
→ 関係（テーブル）
商品番号・商品名・価格
→ 属性（列・カラム）
P001・ノート・200
→ 組（行・レコード）
と考えます。
初心者のうちは、まず次の対応だけでも十分です。
表
→ テーブル
行
→ レコード
列
→ カラム
その上で、試験では「関係・組・属性」という関係モデルの用語に言い換えられることがある、と整理します。
定義・仕組み
関係データベースと関係モデル
関係データベースは、関係モデルに基づいてデータを管理するデータベースです。
関係モデルでは、データを表として表現します。
| 関係モデルの用語 | 表との対応 | 意味 |
|---|---|---|
| 関係 | 表 | データの集合 |
| 属性 | 列 | データの項目 |
| 組 | 行 | 1件分のデータ |
| 定義域 | データ型・値の範囲 | 属性が取り得る値の集合 |
たとえば、次の属性を考えます。
注文数
在庫数
どちらも整数を取るなら、同じ整数の定義域を使えます。
注文数 → 整数
在庫数 → 整数
したがって、複数の属性が同じ定義域を持っても問題ありません。
表どうしはキーで関連付ける
関係データベースでは、複数の表を分けて管理し、必要に応じて関連付けます。
たとえば、社員表と部署表を考えます。
社員表
社員番号 / 氏名 / 部署番号
部署表
部署番号 / 部署名
ここで、部署表の部署番号を主キーにし、社員表の部署番号を外部キーとして持たせれば、社員がどの部署に所属しているかを関連付けられます。
主キー
→ その表の1行を一意に識別する
外部キー
→ 別の表の主キーを参照して表どうしを関連付ける
主キー・外部キーは関係データベースを理解するうえで重要ですが、今回のような基本問題では、まず「2次元の表」が最初の判断ポイントです。
属性の並び順に意味はない
関係モデルでは、属性は名前によって識別します。
そのため、列の位置が変わっても、同じ属性名と値の対応を保っていれば、関係の意味は変わりません。
商品番号、商品名、価格
と、
価格、商品番号、商品名
は、表示順が違うだけです。
組の並び順にも意味はない
組は集合として扱われるため、行の順番にも意味はありません。
P001、ノート、200
P002、ペン、150
と、
P002、ペン、150
P001、ノート、200
は、並び順が違うだけで同じ関係です。
SQLで表示順を決めたい場合は、ORDER BYを使います。
SELECT 商品番号, 商品名, 価格
FROM 商品
ORDER BY 価格;
これは関係そのものに順序があるのではなく、表示時に順序を指定しているだけです。
属性名は関係内で一意
同じ関係の中では、属性名は一意でなければなりません。
商品番号
商品名
価格
のように、それぞれを区別できる名前を付けます。
属性は、属性名によって識別します。
属性
＝ 属性名 ＋ 定義域
と考えると分かりやすいです。
このテーマは基本情報技術者試験のデータベース分野に含まれます。公式の出題範囲は、IPA：基本情報技術者試験から確認できます。
科目Aでどう出る？
科目Aでは、関係データベースそのものの説明や、関係モデルの性質を説明した選択肢から正しいものを選ばせる形で出題されます。
まず「何で表すか」を見る
類似する説明が並んだら、次のように切り分けます。
| 問題文・選択肢の表現 | 判断 |
|---|---|
| データを2次元の表で表す | 関係データベース |
| 親子レコードをポインタで結ぶ | 階層型データベース |
| タグでデータの構造や意味を表す | XML・HTMLなどのマークアップ言語 |
| データと手続きを一体化する | オブジェクト指向のカプセル化 |
試験中は、次の4行まで縮めると判断しやすくなります。
親子・木構造
→ 階層型データベース
タグ
→ マークアップ言語
データ＋手続き
→ オブジェクト指向
2次元の表
→ 関係データベース
関係モデルの性質も問われる
| 選択肢の表現 | 判断 |
|---|---|
| 属性の並び順に意味がある | 誤り |
| 組の並び順に意味がある | 誤り |
| 属性名は関係内で重複できる | 誤り |
| 定義域は属性ごとに異ならなければならない | 誤り |
| 複数属性が同じ定義域を使える | 正しい |
| 属性には名前が必要 | 正しい |
| 同じ組が重複して存在する | 関係モデルでは原則として認めない |
試験中の判断手順
1. まず「何でデータを表すか」を見る
2. 「2次元の表」なら関係データベースを疑う
3. 関係モデルの用語なら、関係・属性・組・定義域を対応させる
4. 順序や属性名に関する説明なら、関係モデルの性質で判断する
どんな場面で使う？
業務データの管理
関係データベースは、顧客、商品、注文、社員などの業務データを表として整理するときに使います。
顧客表
商品表
注文表
注文明細表
のようにデータを分け、主キーや外部キーで関連付けます。
SQLによるデータ操作
関係データベースでは、SQLを使って検索・追加・更新・削除を行います。
SELECT 商品名, 価格
FROM 商品;
SQLの結果では列や行が順に表示されますが、関係モデル上では、その並び順は本質ではありません。
正規化やキー設計の前提
主キー、外部キー、正規化などを理解するには、関係・属性・組の考え方が前提になります。
属性
→ 何を管理するか
組
→ 1件分のデータ
主キー
→ 組を一意に識別する
関係データベースの基本が分かったら、データベースの正規化やER図へ進むと、表をどう設計するかまで学習をつなげられます。
よくある誤解・混同
関係データベースは「表どうしに関係があるデータベース」という意味だけ
表どうしを関連付けることも重要ですが、まず基本は関係モデルに基づき、データを表として扱うことです。
試験で「2次元の表」と出たら、関係データベースを疑います。
データと手続きを一体化するのが関係データベース
これはオブジェクト指向のカプセル化の説明です。
データを表で表す
→ 関係データベース
データと手続きを一体化
→ オブジェクト指向
表には列の順番があるので、関係にも順番がある
表示上は列が左から右に並びますが、関係モデルでは属性名によって識別します。
したがって、属性の順番を入れ替えても、関係の意味は変わりません。
行の順番が違えば別の関係になる
組の並び順にも意味はありません。
順番を指定して表示したい場合は、SQLのORDER BYを使います。
同じ定義域を使う属性は作れない
作れます。
注文数：整数
在庫数：整数
のように、複数の属性が同じ定義域を共有できます。
まとめ（試験直前用）
- 関係データベースは、データを2次元の表として表す
- 関係は表、属性は列、組は行、定義域は取り得る値の集合
- 「親子・木構造」は階層型、「タグ」はマークアップ、「データ＋手続き」はオブジェクト指向
- 属性と組の並び順には意味がない
- 主キーは行を一意に識別し、外部キーは表どうしの関連付けに使う