U
「データベース設計なんてIT系の話でしょ？」と思っていませんか。実は診断士試験では毎年コンスタントに出題され、正規化・ER図・SQLの基礎を押さえるだけで確実に得点できます。今日は図解とたとえ話で完全攻略します。
データベースの種類と特徴
データベースとは「データを体系的に格納・管理・検索できる仕組み」です。ファイルにバラバラに保存するのではなく、構造化して管理することで、複数のシステムが共有・更新できるようになります。企業の情報システムはほぼ必ずデータベースを中核に持っており、診断士として情報戦略を語るうえで不可欠な知識です。
データベースには複数の種類がありますが、試験で中心となるのはリレーショナルデータベース（RDB）です。それぞれの特徴を比較しておきましょう。
| 種類 | 構造の特徴 | 代表的な製品・用途 | 試験での出題 |
|---|---|---|---|
| リレーショナル型（RDB） | 表（テーブル）形式。行と列で管理。SQLで操作 | Oracle・MySQL・PostgreSQL | ◎ 最頻出。正規化・SQLが毎年出題 |
| 階層型 | ツリー構造（親子関係）。上位から下位へ一方向にのみたどれる | IBM IMS（旧来の大型システム） | △ 定義問題で稀に登場 |
| ネットワーク型 | メッシュ構造。複数の親を持てる。階層型の制限を緩和 | IDMS（古い業務システム） | △ 階層型との比較問題 |
| オブジェクト指向型 | オブジェクト単位で管理。メソッドも保持できる | db4o・ObjectDB | △ 概念問題 |
| NoSQL（非リレーショナル） | キー・バリュー/ドキュメント/グラフ型など多様な形式 | MongoDB・Redis・DynamoDB | ○ 近年増加中。RDBとの使い分け問題 |
リレーショナル型が主流になった理由は「データの冗長性排除・整合性保証・SQLによる標準化」の3点です。異なるベンダーのDBでも共通のSQL言語で操作できる標準化は、システム開発コストを大幅に下げました。一方でNoSQLはビッグデータ・高速書き込み・非構造化データの処理に強みを持ち、SNSやIoTシステムで活用が広がっています。
ER図（実体関連図）の構成要素とカーディナリティ
ER図（Entity-Relationship Diagram）は、データベースの論理設計を視覚化するための図です。「どんなデータが存在し、どう関係しているか」を設計段階で整理するために使います。プログラムを書く前にER図を描くことで、後から設計変更が発生するリスクを大幅に減らせます。
管理対象となる「もの」や「こと」。長方形で表す。
例：顧客・商品・注文・社員
→ テーブルに対応する
エンティティ間の関係。ひし形または線で表す。
例：「顧客が注文する」「商品が注文に含まれる」
→ 外部キーや中間テーブルに対応
エンティティが持つ特性。楕円で表す。
例：顧客ID・氏名・生年月日
→ テーブルの列（カラム）に対応
エンティティを一意に識別する属性。下線で表す。
例：顧客ID・注文番号
→ NULL不可・重複不可の制約が付く
外部キー（Foreign Key）
外部キーは別テーブルの主キーを参照する列です。テーブル間の関係を実装する際の核心的な仕組みです。例えば「注文テーブル」の「顧客ID」列が「顧客テーブル」の「顧客ID（主キー）」を参照する場合、「注文テーブルの顧客ID」が外部キーになります。外部キー制約を設定すると、「顧客テーブルに存在しない顧客IDを注文テーブルに登録できない」という参照整合性が自動的に保証されます。
カーディナリティ（多重度）
カーディナリティとは、エンティティ間に「何対何の関係があるか」を示すものです。ER図を読む際の最重要ポイントです。
| 記法 | 意味 | 具体例 | テーブル設計での対応 |
|---|---|---|---|
| 1:1（一対一） | 一方の1レコードに対し、他方も1レコード対応 | 社員と社員証（一人に一枚） | 同じテーブルに統合 or 外部キーをどちらかに置く |
| 1:N（一対多） | 一方の1レコードに対し、他方は複数レコード対応 | 顧客（1）と注文（N） | 「多」側のテーブルに外部キーを置く |
| M:N（多対多） | 両方向に複数の対応 | 学生（M）と授業（N） | 中間テーブル（関連テーブル）を作成して2つの1:Nに分解 |
M:N関係は直接テーブル設計できないため、中間テーブルを使って2つの1:N関係に分解します。
例：「学生と授業」→「学生テーブル」「授業テーブル」「受講テーブル（学生ID・授業ID・成績）」の3テーブルに分解。受講テーブルの主キーは「学生ID＋授業ID」の複合主キーになります。
M:Nを中間テーブルで分解する問題は試験で頻出です。「注文と商品」「学生と科目」「社員とプロジェクト」のパターンで練習しておきましょう。
ER図の読み取り問題では、線の端にある記号（「1」「N」「M」または鳥の足型のクロウズフット記法）でカーディナリティを読み取ります。「社員は複数の部署に所属できるか」「一つの注文に複数の商品が含まれるか」という現実の業務をそのまま図で表現しているので、業務の常識で判断できます。試験本番でも「この業務では1:Nか？M:Nか？」と自問自答すれば正解に辿り着けます。
正規化の手順——第1〜第3正規形の定義と具体例
正規化とは「データの冗長性（同じデータを複数箇所に持つ無駄）を排除し、データの整合性を保ちやすくするためにテーブルを分解する作業」です。正規化しないまま運用すると、次の3種類の異常が発生します。
- 更新時異常：同じデータが複数行にあり、片方だけ更新して矛盾が生じる
- 挿入時異常：他のデータがないと新しいデータを挿入できない
- 削除時異常：削除したくないデータまで一緒に消えてしまう
正規化を理解するための例題テーブル
以下の「注文テーブル」を正規化していきましょう。このテーブルは「1つの注文に複数の商品が含まれる」ケースを想定しています。
| 注文ID | 顧客ID | 顧客名 | 商品ID | 商品名 | 単価 | 数量 |
|---|---|---|---|---|---|---|
| 001 | C01 | 山田太郎 | P01 | ノートPC | 80,000 | 2 |
| 001 | C01 | 山田太郎 | P02 | マウス | 2,000 | 1 |
| 002 | C02 | 佐藤花子 | P01 | ノートPC | 80,000 | 1 |
問題点：「山田太郎」という顧客名が2行に重複。顧客名を変更したとき1行だけ更新し忘れると矛盾が生じます（更新時異常）。「ノートPC・80,000円」という商品情報も2行に重複しています。これらを正規化で解決します。
定義：すべての属性が原子値（それ以上分解できない単一の値）を持ち、繰り返しグループが存在しない
問題のパターン：1つのセルに「商品ID：P01,P02」とまとめて入っているケース
解決：各商品を別の行に分ける。上の例はすでに1NFを満たしています。
主キー：注文ID＋商品ID（複合主キー）
1NFを満たさない典型例：「趣味」欄に「読書・テニス・料理」と複数の値が入っている
定義：1NFを満たし、かつすべての非キー属性が主キー全体に関数従属している（複合主キーの一部への部分従属がない）
問題：主キーは「注文ID＋商品ID」ですが…
・「顧客名」は「注文ID」だけに従属（部分関数従属）
・「商品名・単価」は「商品ID」だけに従属（部分関数従属）
解決：部分従属する属性を別テーブルに分離する
→ 注文テーブル（注文ID, 顧客ID）
→ 注文明細テーブル（注文ID, 商品ID, 数量）← 主キーのみに従属
→ 顧客テーブル（顧客ID, 顧客名）
→ 商品テーブル（商品ID, 商品名, 単価）
定義：2NFを満たし、かつ非キー属性が他の非キー属性に関数従属していない（推移的関数従属がない）
問題の例：社員テーブル（社員ID, 部署ID, 部署名）
「部署名」は「部署ID」に従属 → 「部署ID」は「社員ID」に従属
→「社員ID → 部署ID → 部署名」という推移的従属が発生
解決：部署テーブル（部署ID, 部署名）を別テーブルに分離
→ 社員テーブル（社員ID, 部署ID）
→ 部署テーブル（部署ID, 部署名）
| 正規形 | 解消する問題 | キーワード | 試験頻度 |
|---|---|---|---|
| 第1正規形（1NF） | 繰り返しグループ・複数値属性 | 原子値・単一値 | ◎ |
| 第2正規形（2NF） | 部分関数従属 | 複合主キーの一部への従属 | ◎◎ |
| 第3正規形（3NF） | 推移的関数従属 | 非キー属性間の従属関係 | ◎◎ |
| ボイスコッド正規形（BCNF） | 候補キーへの従属漏れ | 決定項が必ず候補キー | △ |
関数従属とは——正規化の数学的基礎
「属性AがBを決定する（A→B）」とは、Aの値が決まるとBの値が一意に決まる関係です。例えば「顧客ID → 顧客名」は顧客IDが決まれば顧客名も決まるという関数従属です。逆に「顧客名 → 顧客ID」は成立しません（同姓同名の人がいる可能性があるため）。この一方向性が関数従属の本質です。
SQLの基本文——SELECT・JOIN・GROUP BY
診断士試験ではSQLの深い知識よりも「何をするための命令か」を理解していれば十分です。各句の役割を体系的に整理します。
基本SELECT文の構造
SELECT 列名1, 列名2 -- ⑥ どの列を取得するか FROM テーブル名 -- ① どのテーブルから（最初に実行） WHERE 条件式 -- ② どんな条件で絞るか（集計前の行絞り込み） GROUP BY グループ化の列 -- ③ 何でグループ化するか HAVING 集計後の条件 -- ④ 集計結果の絞り込み（集計後の絞り込み） ORDER BY 並び替えの列 -- ⑤ どの順で並べるか
記述する順序と実行順序が異なることが重要です。WHEREは「集計前」、HAVINGは「集計後」という違いを必ず覚えてください。
| SQL句・コマンド | 役割 | 使用例 | 試験でのポイント |
|---|---|---|---|
| SELECT | 取得する列を指定 | SELECT 氏名, 売上 | SELECT * は全列取得。SELECT DISTINCTで重複排除 |
| FROM | 対象テーブルを指定 | FROM 顧客テーブル | 複数テーブルのJOIN時に重要 |
| WHERE | 行の絞り込み条件（集計前） | WHERE 売上 > 100000 | LIKE演算子（パターン一致）・BETWEEN・IN・IS NULL |
| INNER JOIN | 共通キーで2つのテーブルを内部結合 | FROM A INNER JOIN B ON A.id=B.id | 内部結合=両方に存在する行のみ取得 |
| LEFT OUTER JOIN | 左テーブル全行＋右テーブルの一致行 | FROM A LEFT JOIN B ON A.id=B.id | 外部結合=一方に存在しない行もNULLで保持 |
| GROUP BY | 特定列でグループ化して集計 | GROUP BY 部署ID | COUNT・SUM・AVG・MAX・MINの集計関数と組み合わせる |
| HAVING | GROUP BY後の集計結果を絞り込み（集計後） | HAVING COUNT(*) > 5 | WHEREとHAVINGの違いが最頻出！ |
| ORDER BY | 結果の並び順を指定 | ORDER BY 売上 DESC | ASC=昇順（小→大）、DESC=降順（大→小） |
JOINの種類——図解で理解
両方のテーブルに存在するレコードのみ結果に含む。最も基本的な結合。「顧客テーブルと注文テーブルを結合して注文した顧客だけ取得」
左テーブルの全レコードを保持。右テーブルに対応がなければNULL。「全顧客リストに注文情報をつける（注文なしの顧客もNULLで表示）」
右テーブルの全レコードを保持。左テーブルに対応がなければNULL。LEFT JOINで左右のテーブルを入れ替えたものと同等。
両テーブルの全レコードを保持。対応がない側はNULL。「全顧客と全注文を取得し、どちらにも存在しないものをNULLで表示」
WHERE：GROUP BY の「前」に実行される。個々の行に対する絞り込み。集計関数は使えない。
HAVING：GROUP BY の「後」に実行される。グループ（集計結果）に対する絞り込み。
例：「売上合計が100万円以上の部署」→ HAVING SUM(売上) >= 1000000
例：「売上が50万円以上の行を集計対象にしたい」→ WHERE 売上 >= 500000（集計前の行絞り込み）
サブクエリ（副問合わせ）
SELECT文の中に別のSELECT文を入れ子にしたものをサブクエリと言います。「平均売上より高い売上の社員を抽出する」ような場合に使います。内側のSELECT（サブクエリ）が先に実行され、その結果を外側のSELECTが使います。試験では「WHERE 売上 > (SELECT AVG(売上) FROM 売上テーブル)」のような形式で出題されます。
インデックスの仕組みと効果
テーブルの特定列に対して索引を作成し、検索を高速化する仕組みです。本の巻末の索引と同じ発想で、「どのページに何が書いてあるか」を先に索引で調べることで、全ページをめくらずに目的のデータに到達できます。データが1,000万行あっても、インデックスがあれば数十ミリ秒で検索できます。
インデックスなしの場合、SQLはテーブルの全行を先頭から順に走査します（フルテーブルスキャン）。1,000万行のテーブルで「顧客ID=12345」を探すためにすべてを確認する必要があります。インデックスがあると、B木構造（バランスド・ツリー）を使って対数時間（O(log n)）でアクセスできます。
| 観点 | インデックスあり | インデックスなし |
|---|---|---|
| SELECT（検索）速度 | ◎ 大幅に高速（特に大きなテーブル） | △ テーブルが大きいほど遅い |
| INSERT/UPDATE/DELETE速度 | △ やや遅くなる（索引の更新が必要） | ◎ 速い |
| ストレージ使用量 | △ 索引データ分だけ追加で必要 | ◎ 必要最小限 |
| 適した列 | WHERE句・JOIN条件・ORDER BY で頻繁に使う列 更新頻度が低くカーディナリティが高い列 | 更新頻度が高い列 カーディナリティが低い列（例：性別フラグ） |
インデックスが効果的な条件・効果がない条件
- WHERE句で等価比較や範囲比較（=、<、>、BETWEEN）
- JOIN条件の結合キー列
- ORDER BY や GROUP BY で使う列
- 選択性が高い列（カーディナリティが大きい列：顧客ID・注文番号など）
- WHERE句で関数を使った場合（WHERE UPPER(名前) = ‘YAMADA’）
- 前方一致以外のLIKE検索（LIKE ‘%太郎’）
- 選択性が低い列（性別・フラグ類：どうせ半数の行がヒットする）
- テーブルの行数が極端に少ない場合
トランザクション管理とACID特性
「1つの論理的な処理単位」として扱う一連のSQL操作のことです。銀行振込を例にとると、「A口座から1万円を引く」「B口座に1万円を足す」という2つの操作は、必ず両方成功するか両方失敗するかでなければなりません。片方だけ成功するとお金が消えたり増えたりしてしまいます。この「不可分な処理のまとまり」がトランザクションです。
トランザクションの正しさを保証するための4つの性質がACID特性です。これは頭文字を取った略語で、試験では各特性の英語名・日本語名・意味の3点セットで問われます。
| 頭文字 | 英語名 | 日本語名 | 意味 | 具体例 |
|---|---|---|---|---|
| A | Atomicity | 原子性 | トランザクション内のすべての操作は「全て成功」か「全て失敗（ロールバック）」のどちらか。中途半端な状態は許されない | 振込中にシステム障害→両方の更新を取り消す（ロールバック） |
| C | Consistency | 一貫性 | トランザクション前後でデータは常に整合した状態（定義された制約や整合性ルール）を保つ | 残高がマイナスにならない制約が常に満たされる |
| I | Isolation | 独立性（隔離性） | 並行して実行される複数のトランザクションは互いに干渉しない。他のトランザクションの途中状態を見えないようにする | 同時に2人が同じ在庫を注文しても矛盾が起きない |
| D | Durability | 耐久性（永続性） | コミット（確定）したトランザクションは、その後に障害が起きても消えない。永続的に記録される | コミット後に停電→再起動後もデータは保持される |
コミットとロールバック
トランザクション内の全操作を確定させること。コミット後はデータが永続化される（Durabilityの保証）。コミットを実行するまでは他のトランザクションから変更が見えない（Isolationの保証）。
トランザクション内の操作を全て取り消してトランザクション開始前の状態に戻すこと。エラー発生時に自動実行される場合が多い。Atomicityを実現するための仕組み。
排他制御（ロック）
複数のトランザクションが同時に同じデータを更新しようとすると、データの整合性が崩れます。これを防ぐのが排他制御です。ロックは「このデータを今私が使っているから他は触らないで」という旗印です。
| ロックの種類 | 特徴 | 他トランザクションとの関係 | 用途 |
|---|---|---|---|
| 共有ロック（Sロック） | 読み取り専用のロック | 他の共有ロックとは共存可能。排他ロックとは競合 | SELECTのみ実行する場合 |
| 排他ロック（Xロック） | 読み書き両方をロック | 他のすべてのロックと競合（自分しかアクセスできない） | UPDATE・DELETE・INSERT時 |
試験対策——頻出論点の総まとめ
診断士試験での出題パターンを分類し、確実に得点できる論点を整理します。過去問を分析すると、正規化の判定・ER図のカーディナリティ・ACID特性が最も頻繁に出題されています。
| 出題パターン | 主な論点 | 正解の決め手 |
|---|---|---|
| 正規化の判定 | 「このテーブルは第何正規形か」「どの属性が問題か」 | 部分関数従属（2NF）か推移的従属（3NF）かを見極める |
| ER図の読み取り | カーディナリティの識別・M:Nの分解 | 「顧客1人が複数注文できる→1:N」を業務常識で判断 |
| SQL穴埋め | 適切な句・演算子の選択 | WHEREとHAVINGの使い分け・JOINの種類 |
| ACID特性の組合わせ | 各特性の正しい説明の選択 | Isolation=独立性（隔離性）の日本語が揺れるので英語名で覚える |
| インデックスの効果 | 検索速度向上・更新速度低下のトレードオフ | 「更新頻度が高い列にインデックスを設定すると更新が遅くなる」 |
| トランザクション管理 | コミット・ロールバック・デッドロック | ロールバック=Atomicity保証、コミット=Durability保証 |
正規化の各形式——1行で覚える定義
1NF（第1正規形）：「繰り返しグループを排除」→ 各セルに1つの値（原子値）
2NF（第2正規形）：「部分関数従属を排除」→ 複合主キーの一部への従属を別テーブルに分離
3NF（第3正規形）：「推移的関数従属を排除」→ 非キー属性間の従属関係を別テーブルに分離
ACID：Atomicity（原子性）・Consistency（一貫性）・Isolation（独立性）・Durability（耐久性）
特に2NFと3NFの違いは頻繁に問われます。2NF＝複合主キーが前提・部分従属が問題、3NF＝単純主キーでも発生・非キー間の従属が問題と覚えておくと区別しやすいです。
よくある質問（FAQ）
データベース設計・ER図・正規化は、経営情報システムの中でも得点しやすい分野です。正規化の各形式の定義（1NF：繰り返し排除、2NF：部分従属排除、3NF：推移的従属排除）とACID特性（原子性・一貫性・独立性・耐久性）を正確に覚えることで、確実に2〜3点を確保できます。ER図はカーディナリティを業務の常識で判断し、M:Nは中間テーブルで分解するという原則を押さえておきましょう。SQLのWHEREとHAVINGの使い分け、インデックスのトレードオフも頻出論点です。丁寧に理解を積み重ねて、本試験で確実に得点につなげてください。
