››
テクノロジ系 45 問のうち、この章は **4〜6 問**ほどの出題があります。「ECサイトの注文情報はどこにどう保存されているの?」「銀行振込で停電が起きたらお金は消える?」「会員名簿で名前が重複したらどうやって区別するの?」といった、データを整理して蓄積し、複数人で共有するしくみを扱う章です。
現代の IT システムでは**データは事業の資産であり、データベースはその金庫**に相当します。試験では 主キー・正規化・SQL の基本・ACID 特性の 4 つが定番論点。SQL は構文を暗記するのではなく、「何をするための文か」を読み解く力が問われます。
シラバス Ver.6.5 中分類 21「データベース」は 4 つの小分類:
| 小分類 | 項目 | 本章の対応節 |
|---|---|---|
| 54 | データベース方式 | 1 節 |
| 55 | データベース設計 | 2 節 |
| 56 | データ操作(SQL) | 3 節 |
| 57 | トランザクション処理 | 4 節 |
この章を読み終えた時点で、以下ができるようになっていることを目指します。
試験では: 「主キーが満たすべき制約は?」「この処理は ACID のどれ?」のような**定義の細部を問う問題が定番。SQL はSELECT 文を読んで結果を推測するタイプが出るので、構文の暗記より意味読解**を練習する。
EC サイトの商品一覧、SNS の投稿履歴、会社の給与情報、銀行の口座残高——これらはすべてデータベースに格納されています。昔は Excel で管理していた規模の情報も、ユーザ数・取引数が増えると Excel では破綻します。複数人が同時に更新しても矛盾しない「金庫」が必要で、それが DB とそれを管理する DBMS です。
データベース(DB)は、複数の利用者・アプリケーションから共有して利用できるよう整理・蓄積されたデータの集合。管理するソフトウェアが DBMS(Database Management System)です。一見「ファイルにデータを保存する」だけに思えますが、多人数で同時に読み書きしても壊れないのが DBMS の強み。
具体例: 銀行の ATMは全国数万台が同じ口座データを見ています。A さんが引出しを始めた瞬間、B さんが同じ口座に入金しても、データが壊れず正しく反映される。このためには**排他制御・トランザクション・障害回復**などの高度な仕組みが必要で、それを担うのが DBMS です。
| 機能 | 内容 |
|---|---|
| データの一貫性維持 | 複数ユーザーが同時更新しても矛盾しないようにする |
| アクセス制御 | ユーザーごとに権限を設定(GRANT/REVOKE) |
| トランザクション管理 | 処理の確定(COMMIT)と取消し(ROLLBACK) |
| 障害回復 | ログを使ってクラッシュ時にデータを復元 |
データベースには複数の種類があり、扱うデータの構造と用途で使い分けます。関係データベース(RDB)は整然とした表形式データに強く業務の大半で使われ、NoSQLはソーシャル投稿のような非定型データに、KVSはキャッシュや単純検索に適します。試験では RDB が中心、**NoSQL/KVS は補足的**に覚えます。
| 種類 | 特徴 | 代表例 | 用途 |
|---|---|---|---|
| **[[関係データベース | かんけいデータベース]]**(RDB) | 表形式、SQL で操作、ACID 特性 | Oracle、MySQL、PostgreSQL |
| NoSQL | 非関係型、スケーラビリティ重視 | MongoDB(ドキュメント型) | SNS・ビッグデータ |
| KVS(Key-Value Store) | キーと値の対で格納、超高速 | Redis、memcached | キャッシュ・セッション |
| グラフ DB | ノードとエッジで関係を表現 | Neo4j | SNS の人間関係・レコメンド |
頻出: 試験では RDB が 90% 以上の論点。NoSQL/KVS は「RDB の弱点(超大規模データ・非構造データ・超高速)を補う選択肢」という位置付けで理解する。
**関係データベース(RDB)は2 次元の表でデータを管理する方式。各表には列(何を記録するか)と行(1 件分のデータ)があり、表同士を結合(JOIN)して複雑な情報を取り出せます。この節では表の構成要素・キー・設計手法(正規化・E-R 図)を扱います。試験ではキーの制約と正規化の目的**が頻出です。
RDB の**表は Excel のシートと似た 2 次元構造。ただし、各列にデータ型が決まっている**(数値列に文字列は入れられない)ことと、重複行が論理的に許されない点が違います。用語は複数の呼び方があり(行=レコード=タプル 等)、試験ではすべての呼び方で出題されるので整理しておきます。
| 用語 | 別名 | 意味 |
|---|---|---|
| 表 | テーブル、リレーション | データを格納する 2 次元構造 |
| 行 | レコード、タプル | 1 件分のデータ |
| 列 | カラム、フィールド、[[属性 | ぞくせい]] |
| NULL | — | 値が存在しない状態(0 や空文字とは違う) |
引っかけ: NULL は「値がない」状態で、0 や空文字「""」とは別。たとえば「未記入の住所欄」は NULL、「0 円」は 0、「空の文字列」は ""。SQL で NULL を比較するには
= NULLではなくIS NULLを使う(NULL は何とも等しくない)。
キーは「行を識別したり、表と表をつなぐための列」。主キーは**社員番号のような一意な ID**、外部キーは**別の表を参照するためのリンク**。この 2 つのキーで、表同士を正しく結合する仕組みが成り立ちます。
| キー | 役割 | 制約 |
|---|---|---|
| **[[主キー | しゅキー]]**(PK、Primary Key) | 各行を**一意に識別** |
| **[[外部キー | がいぶキー]]**(FK、Foreign Key) | 他表の主キーを参照 |
| **[[候補キー | こうほキー]]** | 主キーになり得るキー群(複数存在可) |
| 複合キー | 複数列の組合せで主キーにする | 1 列では一意にならない場合 |
[社員表] [部署表]
社員ID | 氏名 | 部署ID 部署ID | 部署名
-----|-------|------- ----|-----
101 | 佐藤 | 10 10 | 営業部
102 | 鈴木 | 20 20 | 開発部
103 | 田中 | 10 30 | 人事部
社員表の「部署ID」は部署表の主キーを参照する**外部キー**。存在しない部署ID(例: 99)は登録できません(参照整合性制約)。
E-R 図(Entity-Relationship Diagram)は、データベース設計で使われる**概念モデル図。実装の前段階で、「どんな情報を記録し、それらがどうつながるか」を視覚化します。顧客・注文・商品のような現実世界のエンティティ(実体)を四角形で表し、関連**を線で結びます。M:N(多対多)関係は実装時に中間テーブルで分解するのが定石です。
E-R 図の例(社員 ↔ 部署)
エンティティ 主キー(PK)/ 外部キー(FK) 社員 #社員 ID(PK)/ 部署 ID(FK)/ 氏名 部署 #部署 ID(PK)/ 部署名 関連: 「所属する」 N : 1
= 多数の社員 が 1 つの部署 に所属する関係。M:N の場合は中間テーブルで分解する。
| 要素 | 表現 |
|---|---|
| エンティティ | 四角形 |
| リレーションシップ | 四角形を結ぶ線 |
| カーディナリティ(多重度) | 1:1 / 1:N / M:N |
**M:N 関係**は通常 2 つの 1:N に分解して「中間テーブル」で実装します。
頻出引っかけ: 「学生」と「履修科目」の関係は M:N(1 人の学生が複数科目を履修、1 つの科目に複数学生)。これを RDB で実装するには「履修」中間テーブルを作って M:1 + 1:N に分解する。
正規化は「同じ情報を複数の場所に重複させない」ようにテーブル設計を整える手法。重複があると**更新時に不整合が起きやすい**(例: 顧客の住所を 10 箇所持つと、引っ越した時に 10 箇所すべて更新漏れなく変更する必要がある)。段階的に第 1 → 第 2 → 第 3 正規形と進めて、**データの重複を排除**します。
| 正規形 | 内容 |
|---|---|
| **[[第 1 正規形 | だい 1 せいきがた]]** |
| **[[第 2 正規形 | だい 2 せいきがた]]** |
| **[[第 3 正規形 | だい 3 せいきがた]]** |
具体例(第 1 正規形): 「顧客表」に「購入商品」列があって、1 セルに「商品 A、商品 B、商品 C」とカンマ区切りで入っているのは 非正規。これを**顧客表と購入表に分離**し、1 顧客 1 商品 = 1 レコードにするのが第 1 正規形。
ポイント: IT パスポートでは**正規化の目的(重複排除と更新異常防止)**を押さえれば十分。各正規形の具体的条件は応用情報レベル。「正規化とは何のためにやるか」を日本語で説明できれば OK。
索引(インデックス)は、特定の列に対して検索を高速化する補助データ構造。書籍の巻末の索引と同じ発想で、「どの値がどの行にあるか」を別途記録しておいて探すのを速くします。使いどころを間違えると逆効果で、検索は速くなるが書込みは遅くなるというトレードオフがあります。
SQL(Structured Query Language)は**関係データベースの標準言語。1970 年代に IBM で開発され、現在はほぼすべての RDB 製品で共通の言語として使われています。構文は英語に近く、SELECT 何を FROM どこから WHERE 条件 のように自然言語に近い形で書けるのが特徴です。試験ではSELECT 文の読解**が最頻出。
| 分類 | 略称 | 主なコマンド | 用途 |
|---|---|---|---|
| データ定義言語 | DDL | CREATE、ALTER、DROP | 表の作成・変更・削除 |
| データ操作言語 | DML | SELECT、INSERT、UPDATE、DELETE | データの読み書き |
| データ制御言語 | DCL | GRANT、REVOKE | 権限の付与・剥奪 |
覚え方: Definition(定義)・Manipulation(操作)・Control(制御)の 3 分類。表そのものを作る = DDL、表の中身を読み書き = DML、アクセス権限 = DCL。
SELECT 文は「どの列を、どの表から、どんな条件で取り出すか」を書く命令。試験ではSELECT 文を読んで結果を予測するタイプの問題が出題されます。構文を暗記するのではなく、**各句の役割**を理解するのがコツです。
-- 全列取得
SELECT * FROM 社員;
-- 特定列のみ
SELECT 氏名, 部署ID FROM 社員;
-- 条件で絞込み
SELECT * FROM 社員 WHERE 部署ID = 10;
-- 並べ替え
SELECT * FROM 社員 ORDER BY 社員ID;
-- グループ集計
SELECT 部署ID, COUNT(*) AS 人数
FROM 社員
GROUP BY 部署ID;
-- 結合(JOIN)
SELECT 社員.氏名, 部署.部署名
FROM 社員
JOIN 部署 ON 社員.部署ID = 部署.部署ID;データを**追加・更新・削除**する命令は INSERT / UPDATE / DELETE の 3 つ。特に UPDATE / DELETE の WHERE 句忘れは実務でも大事故になります。WHERE なしの UPDATE は全行更新、**WHERE なしの DELETE は全行削除**なので、実行前に必ず条件を確認します。
-- 挿入
INSERT INTO 社員 (社員ID, 氏名, 部署ID) VALUES (104, '山田', 20);
-- 更新
UPDATE 社員 SET 部署ID = 30 WHERE 社員ID = 104;
-- 削除
DELETE FROM 社員 WHERE 社員ID = 104;引っかけ: UPDATE 社員 SET 部署ID = 30 (WHERE なし)を実行すると、全社員の部署 ID が 30 に書き換わる。これは実務で起きる大事故の典型。試験でも「この SQL の影響範囲は?」と問われることがある。
SELECT 文の **WHERE 句で使える演算子・関数。比較・論理・範囲・パターン・NULL 判定・集約**の 6 分類を覚えると、大半の SQL 問題が読めるようになります。特に LIKE のワイルドカード(%, _)は頻出です。
| 種類 | 例 | 備考 |
|---|---|---|
| 比較 | =, <>, <, >, <=, >= | <> は「等しくない」 |
| 論理 | AND、OR、NOT | 条件の組み合わせ |
| 範囲 | BETWEEN、IN | WHERE age BETWEEN 20 AND 30 |
| パターン | LIKE(% は任意の文字列、_ は任意の 1 文字) | WHERE name LIKE '田%' |
| NULL 判定 | IS NULL、IS NOT NULL | = NULL は動かない |
| 集約関数 | COUNT、SUM、AVG、MAX、MIN | GROUP BY と併用 |
頻出: LIKE のワイルドカード。
%= 任意の文字列(0 文字以上)、_= 任意の 1 文字。「田で始まる名前」はLIKE '田%'、「A で始まり 3 文字」はLIKE 'A__'。
トランザクションは「複数の操作をまとめて 1 つの処理として扱う」仕組み。たとえば銀行振込は「A 口座引落し」と「B 口座入金」の 2 つの操作で成り立ちますが、**片方だけ成功するとお金が消えたり増えたりして困ります。両方成功 or 両方取消**を保証する仕組みがトランザクションです。
トランザクションは「分割できないデータ更新の単位」。1 つでも失敗したら**全部なかったことにするのが基本ルール。例: 銀行振込で「A 口座から 1,000 円引落し」→「B 口座に 1,000 円入金」の 2 操作は、両方成功して初めて振込完了**。途中で失敗したら A の残高を元に戻し、振込をなかったことにします。これを保証するのが ACID 特性(次節)です。
ACID(アシッド)は、トランザクションが満たすべき**4 つの性質の頭文字。銀行・証券・医療のようなデータの正しさが命**のシステムでは必須です。近年のクラウドネイティブな NoSQL では一部を緩めた BASE 特性が使われることもありますが、RDB では ACID が基本です。
| 頭文字 | 性質 | 意味 | 例 |
|---|---|---|---|
| A | 原子性(Atomicity) | 全部成功 or 全部取消し(中途半端なし) | 銀行振込の引落し+入金は両方成功 |
| C | 一貫性(Consistency) | 処理前後でデータの整合性を保つ | 制約違反の状態にはならない |
| I | 独立性(Isolation) | 並行実行中のトランザクションが干渉しない | 他者の途中データは見えない |
| D | 耐久性(Durability) | コミット後のデータは障害があっても失われない | 停電後もログから復元可能 |
| 特性 | 英語 | 意味 |
|---|---|---|
| 原子性 | Atomicity | 全部成功か全部取消しかのどちらか(中途半端なし) |
| 一貫性 | Consistency | 処理前後でデータの整合性が保たれる |
| 独立性 | Isolation | 並行実行中のトランザクションが互いに干渉しない |
| 耐久性 | Durability | コミット後のデータは障害があっても失われない |
頻出引っかけ: 原子性は「全か無か」(All or Nothing)。銀行振込で引落しだけ成功して入金が失敗するような中途半端は許されない。**耐久性はコミット後**の話で、コミット前に停電したら ROLLBACK されるのは原子性の領域。「コミット直後に障害が起きてもデータが消えない」のが耐久性。
トランザクションを**確定するのが COMMIT、取消しが ROLLBACK。COMMIT されたデータは耐久性が保証され、以降は障害があっても消えません(耐久性 = Durability)。エラー時に ROLLBACK することで原子性**(All or Nothing)を守ります。
BEGIN; -- トランザクション開始
UPDATE 口座 SET 残高 = 残高 - 1000 WHERE 口座ID = 'A';
UPDATE 口座 SET 残高 = 残高 + 1000 WHERE 口座ID = 'B';
COMMIT; -- 確定(耐久性が保証される)
-- 途中でエラーが起きたら
ROLLBACK; -- 取消し(原子性を守る)複数ユーザが同じデータに同時アクセスする状況は、RDB では日常茶飯事。何も制御しないとデータの不整合が起きます(同時に同じ口座から引出しすると二重引出しが発生する等)。これを防ぐのが排他制御(ロック)。読取りは複数人 OK、書込みは 1 人だけというのが基本方針です。
| 方式 | 内容 |
|---|---|
| ロック | データに「鍵」をかけて他の更新を待たせる |
| 共有ロック(読取りロック) | 複数トランザクションで**同時に読める** |
| 専有ロック(書込みロック) | 1 トランザクションのみ(他は待たされる) |
| デッドロック | 複数トランザクションが**互いの待機で永久に進まない**状態 |
引っかけ: デッドロックは、T1 が A をロック → T2 が B をロック → T1 が B も欲しがり待ち → T2 が A も欲しがり待ち、で**永久に解消しない**。DBMS は検出して片方を強制終了で対処する。
サーバがクラッシュしたり停電が起きた場合も、DBMS は**データを復元します。未完了のトランザクションは ロールバック(取消し)、コミット済みで反映前のものは ロールフォワード(再適用)で整合性を保ちます。普段からログ(ジャーナル)**を取っておくことが前提です。
| 方式 | 内容 | 使いどころ |
|---|---|---|
| ロールバック | トランザクション実行中の障害 → 変更を取消し | 未 COMMIT の障害 |
| ロールフォワード | コミット済みの変更を**障害後に再適用** | COMMIT 済だがディスク未反映 |
| バックアップ | 定期的にデータ全体を別媒体に保管 | 大規模障害・誤操作 |
頻出: ロールバック(取消し)vs ロールフォワード(再適用)。方向が逆。未完了 → ロールバック、コミット済 → ロールフォワード。
SQL の分類を即答できるようにトレーニング:
出典シラバス: ITパスポート試験シラバス Ver.6.5(2026年1月・IPA公開)