【SC試験・午前1】データベースを攻略！正規化・E-R図・SQL・ACID特性の頻出パターン完全ガイド

「この表は第2正規形までしか満たしていない。第3正規形にするために分割すべき列はどれか」

午前1（科目A-1）のデータベースは、こうした問題が毎回のように顔を出します。ネットワークのような計算問題は少なく、表と関数従属を「読む」力で決まる分野です。つまり、覚える量が少ないわりに得点が安定する、コストパフォーマンスの高い領域だということです。

なお、IPAの発表によると、2026年度から試験区分の名称が変更される予定です。SC試験では午前Ⅰが科目A-1、午前Ⅱが科目A-2、午後が科目Bという呼び方になり、あわせてCBT方式へ移行する予定とされています（出題範囲・出題数・試験時間に変更はないとされています）。制度変更の詳細は「【2026年度版】情報処理安全確保支援士試験のCBT化で何が変わる？科目A/科目Bの新名称と対策の変え方」で解説しています。いずれも現時点では予定であり確定情報ではありません。本記事では検索でたどり着きやすい「午前1」の呼称を主軸にしつつ、新名称を併記して進めます。

筆者はインフラエンジニアとしてサーバーの設定作業を担当し、その後CIOとして社内の情報資産の管理に携わりました。データベースは、業務システムの中で最も機密情報が濃く集まる場所です。誰にどの表を見せるか、更新履歴をどう残すか、障害でトランザクションが途中で切れたときに何が起きるか。試験に並ぶ用語は、そのまま情報管理の設計論と地続きです。

本シリーズの全体戦略は導入記事「元CIOが実践するスタミナ温存術！「コスパ極振り」最短エスケープルート・完全版ロードマップ」に、前回のネットワークは「ネットワークを攻略！OSI参照モデル・サブネット計算・伝送時間の頻出パターン完全ガイド」にまとめています。本記事はテクノロジ系の第6回にあたります。

この記事で学べること

• 午前1のデータベース分野で「取る問題」と「捨てる問題」の線引き
• 主キー・候補キー・外部キーと参照制約の違いを、判断できるレベルで整理する方法
• 非正規形から第3正規形までの正規化を、関数従属をたどって機械的に進める手順
• E-R図の読み方と、多対多の関連を連関エンティティで分解する定石
• SELECT文の評価順序、WHEREとHAVINGの使い分け、内部結合と外部結合の違い
• トランザクションのACID特性と、障害回復（ロールバック・ロールフォワード）の考え方
• 共有ロックと専有ロックの両立性、デッドロックの発生条件と対処

午前1のデータベースは「正規化・SQL読解・ACIDと排他制御」で取り切る

はじめに投資先を決めます。データベースは製品ごとの実装差が大きい分野ですが、午前1で問われるのは製品に依存しない理論部分だけです。深追いする価値のある論点は多くありません。

午前1は30問中18問で通過する試験

午前1は30問出題され、100点満点中60点以上で通過します。つまり18問取れば十分です。テクノロジ系・マネジメント系・ストラテジ系の全分野から出題されるため、1分野で満点を狙う必要はありません。過去問の傾向を見る限り、データベースからの出題はおおむね2問前後です。この2問を確実に取るために必要な準備は、後述する4つの型に絞り込めます。

取る問題：正規化、キー、SQLの読解、ACIDと排他制御

優先して押さえるのは次の4つです。

1つ目は正規化です。 第1正規形から第3正規形までの定義と、与えられた表をどこまで正規化できているか判定する手順。ここは毎年のように問われます。

2つ目はキーと制約です。 主キー、候補キー、外部キー、参照制約。用語の定義を問う問題が単独で出ます。

3つ目はSQLの読解です。 SELECT文を読んで結果表の行数を答える、あるいは目的の結果を得る文を選ぶ形式。書く力ではなく読む力が問われます。

4つ目はトランザクションです。 ACID特性の各文字が何を指すか、共有ロックと専有ロックの両立性、デッドロックの発生条件。ここも定型です。

捨てる問題：関係代数の厳密な記法とインデックス構造の内部

逆に、時間をかけない領域も決めておきます。関係代数（射影・選択・結合・商）の記号を使った厳密な式変形、B+木やハッシュインデックスの内部構造、分散データベースの透過性の分類、データウェアハウスのスタースキーマ設計といった論点は、午前1では出題頻度が低いわりに理解に時間がかかります。名前と一言の説明だけ押さえて、出たら勘で選ぶ判断で構いません。2相コミットも、後述する程度の概要で十分です。

情報の格付けから始めた権限設計

CIOだった頃、社内の機密情報の格付けが未整備で、情報分類の定義そのものから着手しました。区分を決めるだけで多くの時間を要し、そのうえで誰にどのデータへのアクセス権を与えるかを設計しました。この作業の中心にあったのが、業務システムのデータベースです。表の単位で権限を切るのか、行や列の単位まで絞るのか。試験に出てくるビューやGRANTは、この設計を実現するための道具そのものでした。用語として暗記するより、「誰に何を見せるかを制御する仕組み」として捉えたほうが記憶に残ります。

関係データベースの基本構造：表とキーで全部が決まる

正規化もSQLも、土台は「表・行・列」と「キー」です。ここが曖昧なまま先へ進むと、正規化の判定で必ず詰まります。

関係モデルの用語と現場の呼び方

関係データベースは、データを2次元の表（テーブル）で表現します。理論上の用語と、実務での呼び方は次のように対応します。

• 関係（リレーション）＝表（テーブル）
• タプル（組）＝行（レコード）
• 属性＝列（カラム、フィールド）
• 定義域（ドメイン）＝その列が取りうる値の範囲

試験問題は理論用語で書かれることがあるので、両方の言い方に反応できるようにしておきます。なお、関係モデルでは同じ行が重複して存在せず、行や列の並び順に意味はないと定義されています。

候補キー・主キー・外部キー

キーの定義は、次の順で押さえると混乱しません。

候補キー（candidate key）は、行を一意に識別できる属性または属性の組み合わせのうち、余分な属性を含まない最小のものです。1つの表に複数存在しえます。

主キー（primary key）は、候補キーの中から1つ選んで指定したものです。主キーを構成する属性はNULLを取れません（実体保全性）。候補キーのうち主キーに選ばれなかったものは代替キーと呼ばれます。

外部キー（foreign key）は、他の表の主キー（または候補キー）を参照する属性です。外部キーの値は、参照先の表に存在する値かNULLでなければなりません。この決まりが参照制約（参照保全性）です。

参照制約と削除時の動作

参照制約があるとき、参照されている側の行を削除しようとすると整合性が崩れます。この場合の動作として、削除を拒否する（RESTRICT / NO ACTION）、参照している行も連鎖的に削除する（CASCADE）、外部キーをNULLにする（SET NULL）といった選択肢があります。午前1では「部門表の行を削除したとき、社員表の行はどうなるか」という形で問われます。連鎖削除は便利に見えますが、実務では思わぬ範囲のデータが消えるため、慎重に選ぶ設定です。

NULLの扱いという落とし穴

NULLは「値が未定・不明」を表す特別な状態で、ゼロや空文字とは異なります。ここから3つの罠が生まれます。

• NULL同士の比較は真にならない。列 = NULL では判定できず、列 IS NULL を使う
• 集約関数はNULLを無視する。COUNT(列名) はNULLの行を数えないが、COUNT(*) は行数そのものを数える
• 主キーにはNULLを設定できないが、外部キーには設定できる場合がある

COUNT(*) と COUNT(列名) の差は、SQLの結果を答える問題で狙われる定番です。

正規化：更新時異状を消すための分解手順

正規化は、データの重複を減らして更新時の不整合を防ぐための表の分解手順です。手順自体は機械的なので、覚えるより「たどり方」を身につけます。

正規化しないと何が起きるか

1つの表に何もかも詰め込むと、次の3つの異状（アノマリ）が起きます。

• 更新時異状：同じ部門名が100行に重複していると、部門名の変更で100行すべてを直す必要があり、一部を直し漏らすと矛盾する
• 挿入時異状：まだ社員が1人もいない部門を登録できない（社員の行がないと部門を書けない）
• 削除時異状：最後の社員を削除すると、その部門の情報まで消えてしまう

正規化の目的は、この3つを構造で防ぐことです。「重複をなくす」という説明だけで覚えると、なぜそうするのかを問う問題で迷います。

第1正規形：繰返し項目をなくす

1つのセルに複数の値が入っている状態（繰返し項目）を排除し、すべての値を単一の値にした形が第1正規形（1NF）です。たとえば「受注番号・商品名1・商品名2・商品名3」のような横並びの列や、1つのセルに「A,B,C」と詰め込んだ状態を、行を分けて表現し直します。

第2正規形：部分関数従属をなくす

第1正規形であり、かつ主キー以外の属性が主キーの一部だけで決まる関係（部分関数従属）を持たない形が第2正規形（2NF）です。

関数従属とは「Aが決まればBが一意に決まる」という関係で、A → B と書きます。主キーが複数属性の複合キー（たとえば「受注番号＋商品コード」）のとき、「商品コード → 商品名」のように主キーの一部だけで決まる属性があれば部分関数従属です。この属性を別表（商品表）に切り出します。

主キーが単一属性なら、部分関数従属は原理的に発生しません。第1正規形なら自動的に第2正規形を満たします。この点も出題されます。

第3正規形：推移的関数従属をなくす

第2正規形であり、かつ主キー以外の属性が別の主キー以外の属性によって決まる関係（推移的関数従属）を持たない形が第3正規形（3NF）です。

「社員番号 → 部門コード」かつ「部門コード → 部門名」であれば、社員番号から部門名が間接的に決まっています。これが推移的関数従属です。部門コードと部門名を部門表として切り出し、社員表には部門コードだけを外部キーとして残します。

判定の手順は3ステップで固定する

問題を解く手順は毎回同じです。

1. 主キーを特定する（何が決まれば行が一意になるか）
2. 主キーの一部だけで決まる属性がないか探す（あれば第2正規形未満）
3. 主キー以外の属性から決まる属性がないか探す（あれば第3正規形未満）

「この表は第何正規形か」という問いは、この3ステップを上から順に当てるだけで答えが出ます。なお、ボイスコッド正規形（BCNF）や第4・第5正規形は午前1ではまず出ません。名前だけ知っていれば十分です。

正規化しすぎるとどうなるか

正規化を進めると表の数が増え、必要なデータを取り出すために結合が増えて性能が落ちます。そのため実務では、参照頻度の高い項目をあえて重複して持たせる非正規化を行うことがあります。試験では「正規化の目的は何か」を問われるので理論どおりに答えますが、現場では性能とのトレードオフがあることも知っておくと、午後の事例を読むときに納得感が違います。

E-R図：実体と関連の読み方

E-R図（Entity Relationship Diagram）は、データの構造を設計段階で表現する図です。午前1では「読む」問題が中心で、描く力までは求められません。

エンティティ・アトリビュート・リレーションシップ

エンティティ（実体）は、管理対象となるモノやコトです（社員、部門、受注など）。表に対応します。アトリビュート（属性）は、エンティティが持つ性質です（社員番号、氏名）。列に対応します。リレーションシップ（関連）は、エンティティ間のつながりです（社員は部門に所属する）。

カーディナリティ：1対1、1対多、多対多

関連には多重度（カーディナリティ）があります。

• 1対1：1つの社員に1つの社員証。どちらかの表に相手の主キーを外部キーとして持たせる
• 1対多：1つの部門に複数の社員が所属する。「多」の側（社員表）に「1」の側の主キーを外部キーとして持たせる
• 多対多：1人の社員が複数のプロジェクトに参加し、1つのプロジェクトに複数の社員が参加する

1対多のとき外部キーがどちらの表に付くかは、頻出の引っかけです。外部キーは常に「多」の側に置くと覚えてください。

多対多は連関エンティティで分解する

多対多の関連は、関係データベースの表としてそのままでは表現できません。そこで両者の主キーを持つ新しいエンティティ（連関エンティティ、交差エンティティ）を作り、1対多の関連2つに分解します。社員とプロジェクトの間に「参加」という表を作り、社員番号とプロジェクトコードの組を主キーにする形です。この表には「参加開始日」のような、その組み合わせ固有の属性を持たせることもできます。

SQLの基本：午前1は読めれば解ける

SQLは、書けるようになる必要はありません。与えられた文を読んで、どんな結果表になるかを追えれば得点になります。

SELECT文の評価順序

SQLは書く順序と評価される順序が異なります。この順序を知っているかどうかで、WHEREとHAVINGの問題の正答率が変わります。

1. FROM（対象の表を決める。結合もここ）
2. WHERE（行を絞り込む）
3. GROUP BY（行をグループにまとめる）
4. HAVING（グループを絞り込む）
5. SELECT（列を選ぶ。集約関数の値もここで確定）
6. ORDER BY（並べ替える）

WHEREとHAVINGの違い

評価順序が分かれば違いは明快です。WHEREはグループ化される前の個々の行を絞り込み、HAVINGはグループ化された後のグループを絞り込みます。したがって、WHEREの中に集約関数（SUM、COUNTなど）は書けません。集約結果で絞るならHAVINGを使います。「部門ごとの平均給与が50万円以上の部門を抽出する」ならHAVING、「給与が50万円以上の社員だけを対象に集計する」ならWHEREです。

集約関数とGROUP BY

主な集約関数はCOUNT、SUM、AVG、MAX、MINです。GROUP BYで指定した列の値ごとにグループを作り、グループ単位で集約します。GROUP BYを使ったとき、SELECT句に書けるのは原則としてGROUP BYで指定した列と集約関数だけです。前述のとおり、集約関数はNULLを無視して計算します。AVGの分母もNULL以外の件数になる点に注意してください。

結合：内部結合と外部結合

内部結合（INNER JOIN）は、結合条件に一致する行だけを結果に残します。外部結合（OUTER JOIN）は、一致しない行も残し、相手側の列にNULLを埋めます。左外部結合なら左側の表の行がすべて残り、右外部結合なら右側の表の行がすべて残ります。

「部門に所属していない社員も含めて一覧を作る」といった要件では外部結合が必要です。結果表の行数を答える問題では、内部結合か外部結合かで答えが変わるため、まずJOINの種類を確認する癖をつけてください。

副問合せとEXISTS

SELECT文の中に別のSELECT文を入れるのが副問合せです。IN は副問合せが返す値の集合に含まれるかを判定し、EXISTS は副問合せの結果が1行でも存在するかを判定します。NOT EXISTS は「存在しない」条件の表現に使われ、「すべての〜を満たす」という全称条件を書くときの定番です。午前1では、副問合せの結果を先に求めてから外側を読む、という手順で追えば解けます。

ビューとアクセス権：DCLの位置づけ

SQLはDDL（CREATE、DROP、ALTER）、DML（SELECT、INSERT、UPDATE、DELETE）、DCL（GRANT、REVOKE、COMMIT、ROLLBACK）に分類されます。この分類自体が出題されます。

セキュリティの観点で重要なのがビューです。ビューは実表から必要な行・列だけを取り出した仮想の表で、利用者にはビューだけを参照させることで、見せたくない列（給与、個人情報など）を隠せます。権限付与はGRANT、剥奪はREVOKEです。最小権限の原則をデータベース上で実装する手段が、このビューとGRANTの組み合わせだと理解しておくと、午後の事例でも効きます。

インフラエンジニアだった頃、個人事業でシステム開発も請けていた時期がありました。そこで無料で使えたMySQLには本当に世話になり、SQLの書き方は基本的にMySQLで覚えたと言っても過言ではありません。その後、会社の仕事ではOracleやSQL Serverを扱うことになりましたが、書き方で困ることはほとんどありませんでした。管理ツールや独自関数は製品ごとに違っても、ANSI標準に沿った基本的なSELECT・結合・集約の書き方は変わらないからです。一度覚えれば製品を問わず使い回せるという意味で、関係データベースの知識は投資効率が非常に高い分野だと思っています。午前1のために覚えるSQLは、そのまま実務に持っていけます。

トランザクションとACID特性：途中で止まっても矛盾させない

トランザクションは、分割できない一連の処理の単位です。銀行口座の振込であれば「Aから引き落とす」「Bへ入金する」の2つで1組であり、片方だけが成立してはいけません。

ACIDの4文字

• 原子性（Atomicity）：トランザクション内の処理は、すべて実行されるか、まったく実行されないかのどちらかになる。途中で失敗すればロールバックで元に戻す
• 一貫性（Consistency）：トランザクションの前後で、データベースの整合性制約が保たれる
• 独立性・隔離性（Isolation）：複数のトランザクションを同時に実行しても、結果は逐次実行したときと同じになる。互いの途中経過は見えない
• 耐久性（Durability）：コミットしたトランザクションの結果は、その後に障害が起きても失われない

午前1では、4つの説明文からどの特性かを選ばせる問題が定番です。特に原子性と一貫性、独立性と一貫性を取り違えやすいので、「原子性＝全部かゼロか」「独立性＝同時実行しても干渉しない」「耐久性＝コミット後は消えない」と短い言葉で紐づけておきます。

コミットとロールバック、そしてログ

トランザクションの正常終了がコミット、取り消しがロールバックです。DBMSは更新の前後の値をログファイルに記録しており、この記録は更新をデータベースに反映する前に書き出されます（ログ先書き出し）。ログがあるおかげで、障害時に2種類の回復が可能になります。

• ロールバック（後退復帰）：コミット前に障害が起きたトランザクションを、更新前の値（更新前ログ）で元に戻す。戻す先はそのトランザクションの開始時点で、途中まで書き込んでいた更新はすべて取り消される
• ロールフォワード（前進復帰）：コミット済みだがディスクに反映しきれていないトランザクションを、更新後ログで再現する

チェックポイントは、その時点までの更新をディスクに書き出して記録する処理で、回復時にログをさかのぼる範囲を限定するために使われます。したがってロールフォワードの対象になるのは、チェックポイント後にコミットが完了したトランザクションです（チェックポイント時点までにコミットまで終わっていた更新は、すでにディスクへ反映されているので回復は不要です）。「コミット済みならロールフォワード、未コミットならロールバック」という対応を押さえれば、この論点は取れます。

2相コミットは概要だけ

複数のデータベースにまたがるトランザクションでは、全体を一括で確定させる必要があります。2相コミットは、第1相で各サイトにコミット可能かを問い合わせ（準備）、全サイトが可能と答えた場合のみ第2相で実際にコミットを指示する方式です。1サイトでも不可なら全サイトをロールバックします。午前1ではこの2段階の流れが説明できれば十分で、障害時のブロッキングまで踏み込む必要はありません。

排他制御：ロックとデッドロック

独立性を実現する仕組みが排他制御です。ここは仕組みが単純なわりに、毎回同じ形で出題されます。

共有ロックと専有ロック

• 共有ロック（読み取りロック）：読むためのロック。同じデータに対して複数のトランザクションが同時にかけられる
• 専有ロック（排他ロック、書き込みロック）：更新するためのロック。ほかのどのロックとも同時にかけられない

両立性は次のとおりです。共有ロックと共有ロックは両立します。共有ロックと専有ロックは両立しません。専有ロックと専有ロックも両立しません。「両立するのは読み取り同士だけ」と覚えれば、この表は再現できます。

ロックの粒度

ロックをかける単位（データベース全体、表、ページ、行）を粒度といいます。粒度を粗くすると管理は簡単ですが、待ちが増えて同時実行性が下がります。粒度を細かくすると同時実行性は上がりますが、ロックの管理コスト（オーバーヘッド）が増えます。このトレードオフはそのまま出題されます。

デッドロックの発生条件と対処

デッドロックは、複数のトランザクションが互いに相手のロック解放を待ち続け、どちらも進めなくなる状態です。トランザクションAが資源1をロックしたまま資源2を要求し、トランザクションBが資源2をロックしたまま資源1を要求すると発生します。

予防策の定番は、すべてのトランザクションで資源をロックする順序を統一することです。順序が同じなら、待ち合いの循環が生まれません。発生してしまった場合は、DBMSが検出し、いずれかのトランザクションを強制的にロールバックして解消します。「ロック順序の統一」は午前1でも午後でも答えとして使えるので、必ず押さえてください。

2相ロッキングと分離レベル

2相ロッキングプロトコルは、トランザクションを「ロックを獲得していく成長相」と「ロックを解放していく縮退相」に分け、一度解放を始めたら新たな獲得をしない方式です。これにより直列化可能性が保証されます。

分離レベルは、緩いほうから READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE の4段階です。SERIALIZABLEは3つの異常をすべて防ぎますが、待ちが増えて性能は落ちます。1段階緩めたREPEATABLE READではファントムリードが起こりえます。さらに緩めたREAD COMMITTEDではノンリピータブルリードが加わり、最も緩いREAD UNCOMMITTEDではダーティリードまで起こりえます。緩いほど同時実行性は上がる代わりに異常が増える、というこの対応で問われます。

3つの異常の中身は次のとおりです。ダーティリードは未コミットのデータを読んでしまう現象、ノンリピータブルリードは同じ行を2回読むと値が変わっている現象、ファントムリードは同じ条件で2回検索すると行数が変わる現象です。名称と現象の対応を問う形で出題されます。

SC試験での出題パターンと対策

最後に、この分野の投資回収の仕方を整理します。

午前1で狙われる論点

繰り返し問われるのは次の形です。

• 「この表は第何正規形か」「第3正規形にするための分解として適切なものはどれか」
• 「外部キーの説明として適切なものはどれか」「参照制約に違反する操作はどれか」
• 「このSQL文の実行結果の行数はどれか」「目的の結果を得るSQL文はどれか」
• 「ACID特性のうち〇〇の説明はどれか」
• 「デッドロックの発生を防ぐ方法として適切なものはどれか」
• 「ロールフォワードによって回復されるトランザクションはどれか」

いずれも解法が短く固定されています。ネットワークのような計算が不要なぶん、確認する順序さえ決めておけば安定して取れる分野です。

学び始めの人がつまずく3つのポイント

1つ目は、正規化を「重複を消すこと」とだけ覚えることです。 目的は更新時異状の防止であり、重複の削減はその手段です。目的を問う問題で選択肢が割れたとき、この差が効きます。

2つ目は、WHEREとHAVINGの混同です。 「集約する前か後か」という一点で決まります。評価順序を書き出せば迷いません。

3つ目は、ロールバックとロールフォワードの取り違えです。 「コミット済みは前進、未コミットは後退」と機械的に紐づけます。ログの更新前・更新後のどちらを使うかまでセットで覚えると、選択肢の言い換えに強くなります。

講師時代、新卒エンジニアに確認問題を解かせていて間違いが多かったのは単位変換でした。データベース分野に計算はほとんどありませんが、「定義を1つ取り違えると全体が崩れる」という構造は同じです。定義があやふやなまま問題演習に進まないことが、結局は近道になります。

もう1つ、先の話として触れておきます。データベースの設計そのものは、慣れてしまえばそれほど難しいものではありません。骨が折れるのは、試験で設計そのものを問われたときです。そうした区分の過去問を解いた限りでも、長い要件を読み込んで表とキーの形に落としていく作業は相当な負荷でした。逆に言えば、午前1で問われる正規化やキーの判定は、その読解作業のうち一番基礎になる部分だけを取り出したものです。ここを定義レベルで固めておくほど、後で効いてきます。

SC試験本体（午前2・午後）への接続

データベースの知識は、SC試験の本体で次のように効いてきます。

まずSQLインジェクションです。攻撃者の入力によって意図しないSQL文が組み立てられる仕組みは、正しいSQL文の構造を知らなければ理解できません。対策としてのプレースホルダ（プリペアドステートメント）がなぜ有効かは「SQLインジェクション対策はプレースホルダが正解｜プリペアドステートメントの仕組み・静的/動的の違い・エスケープとの差を完全解説」で詳しく解説しています。

次にアクセス権設計です。ビューとGRANT/REVOKEは、最小権限の原則をデータベース層で実装する手段です。午後問題では「アプリケーションが使うDBアカウントに管理者権限が付与されていた」といった設定不備が指摘対象になります。

さらにログと監査です。トランザクションログは障害回復のための仕組みですが、誰がいつ何を更新したかという監査証跡の観点でも問われます。加えて、保存データの暗号化やテスト環境で使うデータのマスキング（匿名加工）も、データベースを起点とした頻出テーマです。

午前1のデータベースは、この本体の議論を読み解くための共通言語だと考えてください。

【演習】データベース 理解度チェック（全10問）

午前1では、正規化の判定、キーと制約の定義、SQLの実行結果、ACID特性、排他制御が定型で問われます。午後では、SQLインジェクションやDBアカウントの権限設定不備といった形で、同じ知識が事例の中に埋め込まれて登場します。定番の引っかけは、WHEREとHAVINGの取り違え、外部キーを「1」の側の表に置いてしまう誤り、ロールバックとロールフォワードの逆転の3つです。以下の練習問題で本記事の理解度を確認してみましょう。

まとめ：データベースは「表を読む型」を持てば安定して取れる

午前1のデータベースは、範囲が狭く出題の形が固定された、投資効率の高い分野です。正規化は「主キーを決めて、部分関数従属を探し、推移的関数従属を探す」の3ステップ。SQLは評価順序をたどる。トランザクションは「全部かゼロか」「コミット済みなら前進、未コミットなら後退」。排他制御は「両立するのは読み取り同士だけ」。この4つの型を持って問題に向かえば、初見の表やSQL文でも手が止まりません。

CIOとして情報資産の格付けとアクセス権の設計に取り組んだとき、最終的に行き着いたのは「どの表の、どの列を、誰に見せるか」という一点でした。ビューもGRANTも正規化も、突き詰めればそのための道具です。試験の用語として暗記するのではなく、機密情報が集まる場所をどう設計し、どう壊さずに運用するかという問いとして捉えてください。SC試験の午後でDBアカウントの権限設定不備やSQLインジェクションの事例に出会ったとき、その視点がそのまま解答の根拠になります。

次回は第7回として、システム開発技術（開発手法・テスト技法）を扱います。ウォータフォールとアジャイル、モジュール分割、ホワイトボックステストとブラックボックステスト。午前1では用語の定義と技法の選択が中心で、ここもデータベースと同じく暗記量の少ない得点源です。

本記事は情報処理安全確保支援士（SC）試験対策を目的として作成しています。

参考資料

• IPA 情報処理技術者試験・情報処理安全確保支援士試験 出題範囲・シラバス（一部改訂について）
• IPA 情報処理技術者試験 過去問題
• IPA 安全なウェブサイトの作り方
• IPA 「情報処理安全確保支援士試験（レベル4）」シラバス（Ver.2.1）