データベース

データベース（DB） とは、大量のデータを整理して蓄積し、効率的に検索・更新できるようにしたデータの集まりです。データベースを管理するソフトウェアを DBMS（Database Management System） といいます。

DBMSを使うことで、次のようなメリットがあります。

• データの共有 — 複数のユーザーやアプリケーションから同時にアクセスできる
• データの一元管理 — 重複を排除し、整合性を保って管理できる
• セキュリティ管理 — アクセス権限を設定してデータを保護できる
• 障害復旧 — バックアップやログから障害時にデータを復旧できる

データベースの種類

ITパスポート試験では 関係データベース（RDB） が中心です。

スキーマ（データベースの構造定義）

データベースの構造を定義したものを スキーマ といいます。スキーマは3層に分かれています。

3層に分けることで、ある層を変更しても他の層への影響を最小限に抑えられます（データ独立性）。例えば、物理的な格納方法を変更してもアプリケーションのプログラムを修正する必要がありません。

関係モデルの基本用語

RDBではデータを テーブル（表） で管理します。

例: 社員テーブル

ER図（Entity-Relationship Diagram）

ER図 はデータベースの設計図です。データの実体（エンティティ）と実体間の関連（リレーションシップ）を図で表現します。

リレーションシップには カーディナリティ（多重度） があります。

SQL（Structured Query Language） は関係データベースを操作するための標準的な言語です。データの検索・追加・更新・削除からテーブルの定義まで、データベースに対するあらゆる操作をSQLで行います。

SQLは大きく3つに分類されます。

SELECT文（データの検索）

データを検索するための最も基本的なSQL文です。

基本構文:

• SELECT 列名 FROM テーブル名 — 指定した列のデータを取得
• SELECT * FROM テーブル名 — すべての列のデータを取得
• WHERE 条件 — 条件に合うデータだけを絞り込む
• ORDER BY 列名 ASC/DESC — 昇順（ASC）/降順（DESC）に並べ替え

例: 社員テーブルから部署IDが「D01」の社員を氏名の昇順で検索

SELECT emp_name FROM employee WHERE dept_id = 'D01' ORDER BY emp_name ASC

条件の指定（WHERE句）

集約関数と GROUP BY

集約関数 はデータをまとめて計算するための関数です。

GROUP BY はデータをグループ化して集約関数を適用します。

例: 部署ごとの社員数を集計

SELECT dept_id, COUNT(*) FROM employee GROUP BY dept_id

HAVING はGROUP BYでグループ化した結果に対して条件を指定します（WHEREはグループ化前の条件）。

例: 社員が3人以上いる部署を表示

SELECT dept_id, COUNT(*) FROM employee GROUP BY dept_id HAVING COUNT(*) >= 3

INSERT / UPDATE / DELETE

UPDATEとDELETEで WHERE句を省略すると全行が対象 になるため、注意が必要です。

VIEW（ビュー）

SELECT文の結果を仮想的なテーブルとして保存したものが VIEW（ビュー） です。VIEW自体は実データを持たず、アクセスのたびに元のテーブルからデータを取得します。

• セキュリティ — 特定の列だけを公開し、機密データを隠す
• 利便性 — 複雑なSELECT文をVIEWとして定義しておけば、簡単に再利用できる

INDEX（インデックス）

INDEX（インデックス） はテーブルの特定の列に対する索引（目次）です。書籍の索引と同じ原理で、データの検索を高速化します。ただし、INSERT/UPDATE/DELETE時にインデックスの更新コストが発生するトレードオフがあります。検索が多いテーブルにはインデックスが有効ですが、更新が頻繁なテーブルでは逆効果になることもあります。

JOIN（結合）

複数のテーブルを関連づけてデータを取得する操作です。

例: 社員テーブルと部署テーブルを結合して、社員名と部署名を取得

SELECT e.emp_name, d.dept_name FROM employee e INNER JOIN department d ON e.dept_id = d.dept_id

正規化 とは、テーブルの設計を見直して、データの重複や不整合を排除するプロセスです。正規化を行うことで、データの更新時に生じる問題（更新時異常）を防止できます。

正規化を行わないと、以下のような問題が発生します。

• 挿入時異常 — 関連データがないと新しいデータを追加できない
• 更新時異常 — 同じ情報が複数箇所にあるため、一部だけ更新すると不整合が生じる（例: 顧客名が注文テーブルの全行にコピーされていると、顧客名を変更する際に全注文行を更新しなければならず、1行でも更新漏れがあるとデータ不整合が発生する）
• 削除時異常 — データを削除すると、別の必要な情報も一緒に消えてしまう

正規化のステップ

関数従属 とは「列Aの値が決まれば列Bの値が一意に決まる」関係です。例えば「社員ID → 氏名」は関数従属です。

正規化の具体例

非正規形のテーブル（注文データ）:

商品が繰り返しになっているため、正規形ではありません。

第1正規形（繰り返しの排除）:

繰り返しを行に展開しました。しかし顧客名が注文IDだけに依存（部分関数従属）しています。

第2正規形（部分関数従属の排除）:

注文テーブル:

注文明細テーブル:

第3正規形（推移的関数従属の排除）: 商品名→単価の推移的従属を排除する場合は、さらに商品テーブルを分離します。

正規化の目的と注意点

正規化はデータの整合性を高めますが、過度な正規化はテーブル数が増えて結合（JOIN）が多くなり、パフォーマンスが低下する場合があります。実務では性能を考慮して、あえて正規化を崩す 非正規化（逆正規化） を行うこともあります。

判断基準の目安:

• 更新が多いシステム → 正規化を重視（データ不整合を防ぐ）
• 読み取り中心で高速応答が必要なシステム → 非正規化を検討（JOINを減らして高速化）

トランザクション とは、データベースに対する一連の操作をひとまとめにした処理単位です。例えば銀行の振込では「Aの口座から引き落とし」と「Bの口座に入金」の2つの操作が1つのトランザクションです。どちらか一方だけが実行されると、お金が消えたり二重に発生したりしてしまいます。

ACID 特性

トランザクションが満たすべき4つの性質を ACID特性 といいます。

トランザクションが正常に完了した場合は コミット（COMMIT） で結果を確定します。途中でエラーが発生した場合は ロールバック（ROLLBACK） で開始前の状態に戻します。

排他制御（ロック）

複数のトランザクションが同じデータに同時にアクセスすると、データの不整合が発生する可能性があります。これを防ぐために 排他制御（ロック） を行います。

デッドロック

2つ以上のトランザクションが互いに相手のロック解放を待ち続ける状態を デッドロック といいます。

例:

• トランザクションAがテーブルXをロック → テーブルYのロック待ち
• トランザクションBがテーブルYをロック → テーブルXのロック待ち
• 互いに永遠に待ち続ける → デッドロック

DBMSはデッドロックを検知すると、一方のトランザクションを強制的にロールバックして解消します。検知方法としては、ロックの待ち合わせ関係を 待ちグラフ として監視し、循環（AがBを待ち、BがAを待つ）が検出されたら一方をロールバックします。また、一定時間ロック待ちが続いた場合にタイムアウトで解消する方式も一般的です。

障害復旧

データベースの障害に備えて、バックアップ と ログ（ジャーナル） を記録しておきます。

バックアップの種類

フルバックアップは復旧が最も速いですが、バックアップに時間がかかります。増分バックアップはバックアップは速いですが、復旧時にはすべての増分を順番に適用する必要があります。

RPO と RTO

バックアップ戦略を決定する際の重要な指標が RPO と RTO です。

RPO を短くするほど頻繁なバックアップやリアルタイムレプリケーションが必要になり、RTO を短くするほど高速な復旧手段（冗長構成等）が必要になります。両方ともコストとのトレードオフです。