ITパスポート 令和4年度 問65：データベース・関係データベースに関する問題

答えは a「従業員番号」 です。

主キーとは、表の中の1行（＝1人ぶんのデータ）を“ピタッと1つに特定できる目印”のこと。出席番号みたいに、絶対にかぶらない番号です。

従業員番号は『重複なし＝1人に1つ』と条件に書いてあるので、これなら誰のデータか必ず1人に決まります。だから主キーにぴったり。

👉 覚え方：主キー＝『絶対かぶらない、その人だけの番号』。

ほかの選択肢：c 従業員名は“同姓同名がいてもOK”なのでかぶる→ダメ／d 部門コードは1部門に複数人いるのでかぶる→ダメ／b 番号だけで決まるのに部門コードまで足すのはムダ（余計な情報入り）。

なぜこれが正解か

正解は a（従業員番号）。主キーは、表の各行（レコード）を一意に識別でき、かつ重複・NULLがない列。条件(1)『各従業員は重複のない従業員番号を一つもつ』より、従業員番号だけで1行を必ず特定できる。よって主キーとして最も適切。

各選択肢の解説

• b 従業員番号＋部門コード：従業員番号単独で一意に決まるため、部門コードを加えるのは冗長。主キーは必要最小限の列で構成すべき（部門コードは余分）。
• c 従業員名：条件(2)で同姓同名が許されるため重複し得る。一意に識別できないので不可。
• d 部門コード：条件(4)で一つの部門に複数名が所属＝重複するため、行を一意に特定できない。

覚え方・ひっかけ注意

主キーの条件は『一意・重複なし・NULLなし、かつ最小限』。bのように一意な列にさらに別の列を足したくなるのがひっかけ＝余計な属性は不要。dの部門コードは部門表側では主キーになるが、従業員表では“1対多の多側”なので主キーにならない点を区別する。

理論的背景

関係データベース（RDB：Relational Database）の主キー（Primary Key：PK）は、テーブル内の各行（レコード）を一意に識別するための列または列の組み合わせであり、以下の2つの必須条件を満たす。①一意性（Uniqueness）：同じ値が2行以上存在しないこと。②非NULL性（Not Null）：NULL（未定義）値を持たないこと。

本問の条件分析では「(1) 各従業員は重複のない従業員番号を一つもつ」という条件が主キー候補（Candidate Key）として従業員番号を確定させる十分条件となる。「(2) 同姓同名の従業員がいてもよい」という条件は従業員名が主キーになれない（一意性を満たさない）ことを明示している。

選択肢bの「従業員番号と部門コードの組み合わせ」が不正解である理由は、主キーの原則に「最小性（Minimality）」があるためである。従業員番号単独で一意性が保証されるのに、部門コードを追加しても一意性が向上しない。最小の属性で一意性を確保できる列（超キーの中で最小のもの）を主キーとして選ぶのが設計原則であり、これを「最小超キー」または「候補キー」という。

実務での使われ方

実際のデータベース設計では、自然キー（Natural Key：ビジネス上意味を持つ値）とサロゲートキー（Surrogate Key：人工的に生成したID）の選択が設計上の重要な判断点となる。本問の従業員番号は自然キーであるが、実務では番号の変更（社員番号体系の変更）・再利用・意味の変化などのリスクから、INT型またはUUID型の自動採番サロゲートキー（AUTO_INCREMENT・SERIAL）を主キーとして採用し、従業員番号をUNIQUE制約付きの別列として管理するパターンが多い。

正規化（Normalization）との関係でも主キーは重要な役割を持つ。第1正規形（1NF）では原子値・主キーの設定が要件となり、第2正規形（2NF）では非キー属性が主キー全体に関数従属することを要求する（部分関数従属の排除）。本問で「従業員番号と部門コード」を複合主キーにした場合、「部門名・所在地」が部門コードのみに関数従属する部分従属が発生し、2NFを満たさない設計となる点でも複合主キーが不適切であることが確認できる。これが問題文の設計で従業員表（従業員番号・従業員名・部門コード・生年月日・住所）と部門表（部門コード・部門名・所在地）を分離した正規化の理由である。

試験での位置づけ

ITパスポートの関係データベース分野で「主キーの条件（一意性・非NULL・最小性）」と「主キーとして使える列の識別」は最頻出テーマである。本問のひっかけポイントは「従業員名（c）」は同姓同名の可能性から一意性が保証されない点と、「従業員番号と部門コード（b）」は最小性の原則に反する余分な組み合わせである点の識別にある。正解を絞る手順として「各選択肢が一意性・非NULL・最小性を満たすか」を条件1〜5を使って検証することが論理的なアプローチとなる。

基本情報技術者（FE）では、主キー・外部キー・候補キー・代替キー・スーパーキーの区別、関数従属（A→Bの表記）、第1〜第3正規形の定義と正規化の実施手順が問われる。さらに結合演算（INNER JOIN・LEFT OUTER JOIN・CROSS JOIN）・射影（SELECT列）・選択（WHERE条件）などの関係演算と、SQLの基本構文（SELECT・FROM・WHERE・GROUP BY・HAVING・ORDER BY）の詳細が重要な出題領域である。データベーススペシャリスト試験（DB）では正規化の理論（BCNF・第4・第5正規形）・インデックス設計・実行計画の最適化まで深掘りされる。

選択肢の発展補足

選択肢dの「部門コード」が主キーになれない理由は条件(4)「一つの部門には複数名の従業員が所属する」から明らかであり、同一部門コードを持つ従業員が複数存在するため一意性が保証されない。部門コードは部門表（部門コード・部門名・所在地）の主キーとしては適切であり（条件(3)：重複なし）、従業員表においては外部キー（Foreign Key）として機能し、従業員と部門の1対多の関係を表現するために使われる。

外部キー制約（FOREIGN KEY CONSTRAINT）は参照整合性（Referential Integrity）を保証し、従業員表の部門コードが必ず部門表に存在する値のみ設定できるよう制約する。この制約により「存在しない部門に所属する従業員データ」が挿入されるのを防ぎ、データの一貫性を維持する。実務では「孤立した外部キー値（親レコードが削除されても子レコードが残る状態）」はデータ品質問題の原因となるため、カスケード削除（ON DELETE CASCADE）またはセット NULL（ON DELETE SET NULL）等の参照動作を設計段階で明示することが重要である。