基本情報 2022 サンプル問題 問22：テクノロジ系に関する問題

答えは b「従業員は，同時に複数の部署に所属してもよい」 です。

この図は「部署と従業員の関係」を表しています。図の数字（多重度）は「何人いてOKか」のルール：

• 部署の側「1..＊」＝従業員は1つ以上の部署に所属する（複数OK！）
• 従業員の側「0..＊」＝部署には0人以上の従業員が所属する（誰もいない部署もOK）

だから「1人の従業員が複数の部署に所属していい」のが正解です。兼務している人をイメージするとピッタリ。

👉 覚え方：「＊（アスタリスク）＝何個でも」「0..＊＝いなくてもOK」「1..＊＝最低1つは必要」。

ほかの選択肢：a 数の一致は読み取れない／c「0..＊」＝0人もOKなので所属ゼロの部署もアリ／d 従業員側が「1..＊」なので、どこにも所属しない人はダメ。

なぜこれが正解か

正解は b。UML クラス図の関連（association）における多重度（multiplicity）の読み方：

• 部署側「1..＊」 ＝ 1人の従業員が所属する部署は 1個以上（複数所属可）
• 従業員側「0..＊」 ＝ 1つの部署に所属する従業員は 0人以上（不在可）

したがって従業員は複数部署を兼務できることが図から読み取れる。

各選択肢の解説

• a：従業員数と部署数の一致は多重度からは導けない。
• c：部署側の「0..＊」により所属従業員ゼロの部署も許される（記述と逆）。
• d：従業員側の「1..＊」により部署に所属しない従業員は許されない（記述と逆）。

覚え方・ひっかけ注意

多重度は『自分の反対側を見る』のがコツ。「部署」側に書かれた数字は「1人の従業員から見た部署の数」を表す（自分が読みたい側の反対側の端に書かれた数字を読む）。`1`／`0..1`／`1..＊`／`0..＊`／`＊` の意味を確実に。`＊` 単独は `0..＊` と同義。

理論的背景

UML（Unified Modeling Language）クラス図の関連（association）は、クラス間の構造的関係を表す。多重度は関連の各端に記され、参加インスタンス数の制約を表現する。本問は M対N（多対多）関係の典型例。

表記法（UML 2.x 標準）：

• `1` ＝ ちょうど1
• `0..1` ＝ 0または1（オプション）
• `1..＊` ＝ 1以上（必須＋複数）
• `0..＊`（または `＊`）＝ 0以上（オプション＋複数）
• `2..5` のように範囲指定も可

実務での使われ方

• 概念データモデリング：要件定義フェーズで業務エンティティ間の関係を可視化。
• DB 論理設計への変換：M対N 関連は中間テーブル（連関エンティティ／associative entity）で実装。本問なら `所属(従業員ID, 部署ID, 開始日, ...)` テーブルを作成。
• ORマッパー実装：JPA の `@ManyToMany`、Rails の `has_many :through` 等、フレームワークの関連定義に直結。
• 拡張：所属に「開始日・役職」等の属性が必要なら関連クラス（association class）で表現。

試験での位置づけ

基本情報のシステム開発（要件定義・設計）分野で頻出。UML 13種類の図（クラス図、ユースケース図、シーケンス図、アクティビティ図、状態遷移図 等）の使い分けと、ER 図（IE記法／IDEF1X記法）との対応が問われる。応用情報・データベーススペシャリストでは汎化／集約／コンポジション等の関連種別、ナビゲーション可能性（矢印）、関連クラスまで深く出題される。

選択肢の発展補足

• 多重度の例外パターン：`{ordered}`（順序保持）、`{unique}`（重複不可、デフォルト）、`{bag}`（重複可）等の制約も標準でサポート。
• 集約 vs コンポジション：集約（白菱形）は「全体／部分の弱い関係」（部分の独立存在可）、コンポジション（黒菱形）は強い関係（全体消滅で部分も消滅）。
• 本問の M対N 関連は DB 第3正規形では分解必須となるため、論理設計の正規化問題と組み合わせて出題されやすい。