E-R図の記号問題は怖くない。問題文の「動詞」から読み解く、エンティティ関連の法則

応用情報技術者試験の午後問題では、いくつかの選択科目の中から、得意な分野や対策しやすい分野を選んで解答します。その中でも「データベース」は、多くの受験生にとって有力な選択肢の一つです。

ただ、データベースの問題、特にE-R図の記号を問う問題で、確信を持って解答できていますでしょうか。「なんとなく」で記号を選び、正解かどうか不安に感じた経験がある方も少なくないかもしれません。

なぜIPAは、このE-R図の問題を出題し続けるのでしょうか。

それは、このスキルが、応用情報技術者に求められる本質的な能力と深く関わっているからです。試験要綱によれば、応用情報技術者には「システムの企画・要件定義、アーキテクチャの設計において、システムに対する要求を整理し、適用できる技術の調査が行える」ことが期待されています。

まさに、顧客や利用者の要望が書かれた文章から、データの関係性を正確に読み解き、E-R図という設計図に落とし込む作業は、この「要求を整理する」能力そのものと言えます。

この記事では、E-R図の記号問題を解くために必要な、問題文の論理的な読解方法を解説していきます。単なる記号の暗記に頼るのではなく、その背景にある考え方を理解することで、応用力が身につき、データベース設計の面白さにも繋がるはずです。

それでは、一緒にその具体的な解き方を見ていきましょう。

それでは早速、この記事の結論からお伝えします。

E-R図の記号問題を解くために、本当に必要なことは何なのか。

それは、「問題文の日本語から、モノとモノの関係（1対1, 1対多など）と、その存在が必須か任意かを正確に読み解く力」です。

もう少しシンプルに言うと、「日本語の読解力」が全てだ、ということです。

試験で問われる様々な記号（|や○、鳥の足など）は、この読解の結果を表現するための「道具」にすぎません。道具の使い方（記号の意味）を覚えることはもちろん大切ですが、それ以前に「何を表現したいのか」を問題文から正しく読み取れなければ、宝の持ち腐れになってしまいます。

この記事では、この最も重要となる「読解力」を身につけるための具体的な方法を、順を追って解説していきます。

まずは、その「道具」である記号にはどんな種類があるのか、全体像から見ていきましょう。

記号を分解して理解する

E-R図でエンティティ（モノ）同士をつなぐ線には、その関係性を表すための記号が付きます。試験で最もよく使われるIE記法では、この記号はたった2つの要素の組み合わせで成り立っています。

線の「エンティティに近い側」と「遠い側」、それぞれの記号の意味さえ分かれば、もう混乱することはありません。

1. エンティティに近い側の記号 → 存在の【必須 or 任意】を表す

• |（一本線）: 必須 (Mandatory)。相手側のエンティティが存在することを意味します。
• ○（まる）: 任意 (Optional)。相手側のエンティティが存在しない場合もあることを意味します。

2. エンティティから遠い側の記号 → 関係の【数】を表す

• |（一本線）: 1 (One)。相手側のエンティティはただ1つです。
• <（鳥の足）: 多 (Many)。相手側のエンティティが複数ありうることを意味します。

【チートシート】4つの基本パターン早わかり図解

この2つの要素を組み合わせた、4つの基本パターンを見ていきましょう。これさえ押さえれば、どんな関係性も読み解けます。

それでは、E-R図の記号を決定づける「日本語の読解術」を4つのステップに分けて解説します。以下のシンプルなビジネスルールを例に考えていきましょう。

【ビジネスルール例】
・ある会社では、1人の社員は、必ずいずれか1つの部署に所属する。
・1つの部署には、複数の社員が所属している。ただし、新設された部署には、まだ誰も所属していない場合もある。

ステップ1：エンティティ（名詞）を見つける

まず、文章中に出てくる「モノ」や「情報のカタマリ」、つまり名詞に着目します。
例：「社員」「部署」「会社」
ここでは「社員」と「部署」の関係性をモデル化したいので、この2つをエンティティとして抽出します。

• エンティティ： [社員] , [部署]

ステップ2：リレーション（動詞）を捉える

次に、エンティティ間を繋ぐ動詞を探します。
例：「所属する」
これが [社員] と [部署] の関係性（リレーション）になります。

ステップ3：多重度（1 or 多）を翻訳する【最重要】

ここが核心部分です。関係性を両側から見て、それぞれ「1」なのか「多」なのかを判断します。

①「部署」側から「社員」を見る

"1つの部署には、複数の社員が所属している。"

この「複数の」という日本語が、「多」を意味するキーワードです。したがって、[部署]から見た[社員]の数は「多（<）」になります。

②「社員」側から「部署」を見る

"1人の社員は、必ずいずれか1つの部署に所属する。"

こちらは「1つの」と明記されていますね。これが「1」を意味するキーワードです。したがって、[社員]から見た[部署]の数は「1（|）」になります。

これで、[部署](1) 対 [社員](多) の「1対多」リレーションであることが確定しました。

ステップ4：任意性（必須 or 任意）を翻訳する

最後に、その関係が「必ず存在する」のかどうかを判断します。これも両側から見るのがコツです。

①「社員」にとって「部署」は必須か？

"1人の社員は、必ずいずれか1つの部署に所属する。"

「必ず」とありますね。これは、所属部署のない社員は存在しない、という意味です。よって、社員にとって部署は「必須（|）」です。

②「部署」にとって「社員」は必須か？

"...新設された部署には、まだ誰も所属していない場合もある。"

この一文が決定打です。「場合もある」ということは、社員が一人もいない部署が存在しうる、ということです。よって、部署にとって社員は「任意（○）」です。

【結論】完成したE-R図

ステップ1〜4の結果を統合すると、以下のE-R図が完成します。

• 部署から見て、社員は「0件以上（任意 ○ で 多 <）」
• 社員から見て、部署は「1件（必須 | で 1 |）」

[部署] ---○<---||--- [社員]

このように、日本語のルールを一つ一つ分解して当てはめていけば、論理的に正しいE-R図を導き出せるのです。

理論を学んだら、次は実践です。ここでは「大学の履修登録」をテーマにした、応用情報で頻出のパターンを含む典型的な問題例を使って、セクション4で学んだ思考法を試してみましょう。

問題例：履修登録ルールの読解

【履修登録に関するルール】
1. 学生は、複数の科目を履修登録できる。一方で、新入生など、まだ1科目も登録していない学生もいる。
2. 科目は、複数の学生によって履修登録される。ただし、新設された科目など、まだ誰にも登録されていない科目もある。
3. どの「履修登録」情報も、必ず1人の学生と1つの科目に対応する。
4. 講師は、複数の科目を担当することがある。まだ担当を持たない講師もいる。
5. 1つの科目は、必ず1人の講師によって担当される。

思考トレース

ステップ1：エンティティを見つける

まず、ルールに出てくる名詞からエンティティを抽出します。
[学生]、[科目]、[講師] はすぐに見つかりますね。

ここで重要なのが、ルール1と2です。「学生」と「科目」は、互いに「多対多」の関係（1人の学生が複数の科目を、1つの科目が複数の学生に）になっています。このような「多対多」の関係は、直接線で結ぶのではなく、「関連エンティティ」と呼ばれる、いわば「間を取り持つエンティティ」を間に置くのがデータベース設計の定石です。

今回は、ルール3に「履修登録」という、まさにそのためのエンティティが示唆されています。

• エンティティ： [学生]、[科目]、[講師]、[履修登録]

ステップ2〜4：関係性を読み解く

それでは、各エンティティ間の関係を「両側から」見ていきましょう。

【結論】完成した関係性のまとめ

これらの分析結果を統合すると、各エンティティ間の関係性は以下のようになります。「多対多」の関係が、「履修登録」エンティティを介して二つの「1対多」の関係に分解されている点に注目してください。

このように、一見複雑なルールでも、一つずつ丁寧に「翻訳」していけば、正解にたどり着くことができます。特に「多対多」の関係を見つけ、それをつなぐ「関連エンティティ」に注目する視点は、応用情報技術者試験では非常に重要です。

これまでは、すでにある出題パターンをマスターすることに焦点を当ててきました。しかし、一歩先を見据えることで、より盤石な応用力を身につけることができます。E-R図の基本原則は変わりませんが、試験で題材となるビジネスシナリオは、IT業界のトレンドを反映して進化する可能性があるからです。

ここでは、今後出題されるかもしれない、いくつかの新しい傾向を予測してみます。

予測1：非機能要件との融合

今後の問題では、単にビジネスルールが提示されるだけでなく、データモデルの設計に影響を与えるような非機能要件（性能、セキュリティ、監査要件など）が盛り込まれる可能性があります。

• 出題傾向： 例えば、「監査証跡として、注文ステータスのあらゆる変更を履歴として記録すること」や、「検索性能を向上させるため、商品の要約情報を非正規化して別途保持すること」といった要件です。
• 問われる能力： この場合、[ステータス変更履歴]のようなエンティティを追加したり、性能向上のためにあえて非正規化（冗長性を持たせる設計）を検討したりする必要が出てきます。単に「何を」保存するかだけでなく、システム全体の目的を達成するために「どのように」保存すべきかを考える応用力が試されます。

予測2：「イベント」や「ログ」エンティティの増加

IoTのようにシステムが相互接続したり、セキュリティ意識が高まったりする中で、出来事（イベント）やログをモデル化する重要性は増しています。

• 出題傾向： 「商品」や「社員」といった具体的なモノだけでなく、[ユーザーログイン]、[センサー測定値]、[API呼出ログ] のような、形のない「イベント」をモデル化する問題です。
• 問われる能力： イベントと、それを引き起こしたエンティティとの関係性を見抜く力が必要です。例えば、[ユーザーログイン]エンティティは、[ユーザー]エンティティと「多対1」の関係になります。これは、システムの振る舞いを時系列で追跡・分析するという、現実世界のニーズを反映したものです。

予測3：関連エンティティの複雑化

前のセクションの「履修登録」エンティティは、「学生」と「科目」をつなぐシンプルな橋渡し役でした。今後は、この橋渡し役自体が、より多くの重要な属性を持つようになるかもしれません。

• 出題傾向： 多対多を解消するための関連エンティティが、最終成績、登録日時、支払い状況といった、関係性そのものを説明するための属性を持つようになります。
• 問われる能力： その属性が、どのエンティティに属するべきかを正しく判断する力が問われます。関連エンティティが単なる繋ぎ役ではなく、それ自体が重要なデータを持つ一つの独立したエンティティであることを、より深く理解しているかが試されるでしょう。

これらのシナリオは少し複雑に見えるかもしれませんが、これまで解説してきた4ステップの思考法（エンティティ発見 → 関係性把握 → 多重度翻訳 → 任意性翻訳）が、これらを解くための最も確実な土台であることに変わりはありません。

E-R図の作成は、データベース設計という大きな旅の一部にすぎません。ここで学んだ知識が、他の重要な知識とどのようにつながっているのか。その全体像を地図のように俯瞰することで、一つ一つの知識がより深く、立体的に理解できるようになります。

ここでは、ビジネスの世界のあいまいな「要求」が、いかにして具体的なデータベースの「テーブル」になるのか、そのプロセスを追いかけてみましょう。

CREATE TABLE 履修 (
    履修ID INT PRIMARY KEY,
    学生ID INT NOT NULL,
    科目ID INT NOT NULL,
    FOREIGN KEY (学生ID) REFERENCES 学生(学生ID),
    FOREIGN KEY (科目ID) REFERENCES 科目(科目ID)
);

このように、E-R図はデータベース設計全体のプロセスの中で、「ビジネス要求を論理的な形に変換する」という非常に重要な役割を担っています。この繋がりを意識することで、なぜE-R図を学ぶ必要があるのか、その価値をより深く感じていただけたのではないでしょうか。

E-R図の考え方は分かってきたけれど、いざ問題を目の前にするとどこから手をつけていいか分からない…という方もいるかもしれません。ここでは、そんなあなたのために、E-R図を無理なく、しかし確実にマスターするための3ステップ学習プランを提案します。

ステップ1：【基礎固め】「1対多」の関係をマスターする

まずは、データベースで最も基本かつ頻繁に登場する「1対多」の関係に集中しましょう。いきなり全てを理解しようとせず、的を絞るのが早期習得のコツです。

• フォーカス：「1つの部署に、複数の社員が所属する」のような、シンプルな「1対多」の関係性だけを見抜く練習をします。
• アクション：この段階では、「必須か任意か（|か○か）」は一旦無視してOKです。「1」と「多（鳥の足）」の記号を正しく置くことだけに集中してください。身の回りにある関係（例：先生と生徒、国と都市など）をE-R図で表現してみるのも良い練習になります。
• ゴール：問題文から「1対多」の関係性を即座に見つけ出し、自信を持ってモデル化できるようになる。

ステップ2：【応用】「必須 or 任意」の区別を意識する

「1対多」の骨格を掴めるようになったら、次はその関係性に「必須（|）」か「任意（○）」か、という味付けを加えていきます。

• フォーカス：ステップ1で見つけた「1対多」の関係に、「必ず存在するのか、しない場合もあるのか」という条件を加えます。
• アクション：「社員のいない部署は存在しても良い？」「部署に所属しない社員は存在しうる？」といった問いを自分に投げかけ、問題文のルールからその答えを探す練習をします。「～の場合がある」「必ず～」といったキーワードに注目する癖をつけましょう。
• ゴール：関係性の両側について、それぞれが必須なのか任意なのかを論理的に判断し、記号を使い分けられるようになる。

ステップ3：【発展】「多対多」と「関連エンティティ」を攻略する

いよいよ応用情報の問題で差がつく「多対多」の関係です。しかし、ステップ1と2が身についていれば、もう怖くありません。

• フォーカス：「1人の学生が複数の科目を履修し、1つの科目も複数の学生に履修される」といった「多対多」のパターンを認識する練習をします。
• アクション：「多対多」を見つけたら、それを2つの「1対多」の関係に分解するための「関連エンティティ（例：履修）」を間に置く、という定石パターンを徹底的に練習します。分解してしまえば、あとはステップ2で学んだ知識を適用するだけです。
• ゴール：複雑に見える「多対多」のルールを、関連エンティティを使ってシンプルな「1対多」の組み合わせに分解し、正しくモデル化できるようになる。

このロードマップに沿って学習を進めれば、E-R図に対する苦手意識は、いつの間にか「得意分野」へと変わっているはずです。

ここまでの知識がしっかりと身についたか、腕試しをしてみましょう。応用情報技術者試験で出題されそうな、2つの異なるシナリオを用意しました。まずは自力でE-R図を考えてから、答えと解説を確認してみてください。

チャレンジクイズ 1：レンタルビデオ店の貸出管理

【貸出ルール】
・会員は、複数のビデオを同時に借りることができる。もちろん、1本も借りていない会員もいる。
・当店では、同じタイトルのビデオを複数本所蔵している。それぞれのビデオ実物（ビデオテープやディスク）は、ユニークな管理番号で識別される。
・1本のビデオ実物は、同時に1人の会員にしか貸し出すことはできない。また、棚に在庫として置かれている（誰にも貸し出されていない）ビデオ実物もある。

【問題】[会員] と [ビデオ実物] のエンティティ間のリレーションシップを、IE記法で示してください。

チャレンジクイズ 2：Webショッピングサイトの注文管理

【注文ルール】
・1回の注文で、複数の種類の商品を同時に購入できる。
・商品は、複数の異なる注文で購入されうる。
・注文には、必ず1種類以上の商品が含まれる。
・まだ一度も注文されたことのない商品もある。

【問題】[注文] と [商品] のエンティティ間のリレーションシップを、IE記法で示してください。（ヒント：「多対多」の関係になります）

最後までお疲れ様でした！この記事で解説したE-R図の読解術は、もうあなたのものです。最後に、学んだことの核心部分をチェックリストとしてまとめました。試験本番で迷ったとき、このリストを思い出してください。

最終チェックリスト＆まとめ

1. これは「暗記」ではなく「翻訳」問題である
   最も重要な心構えです。記号の形に惑わされず、問題文の日本語（ビジネスルール）を正確に読み解くことに集中しましょう。
2. 記号は「必須/任意」と「1/多」の組み合わせにすぎない
   線のエンティティに近い側が「存在するかどうか（|か○か）」、遠い側が「数（|か<か）」。この2つの組み合わせでしかない、とシンプルに考えましょう。
3. 思考の4ステップを徹底する
   ①エンティティ（名詞）を見つけ、②リレーション（動詞）を捉え、③多重度と④任意性を必ず両側から確認する。このプロセスが、あなたを正解へ導く確実な道筋です。
4. 「多対多」を見たら、まず分解する
   応用情報技術者試験で頻出の「多対多」の関係を見つけたら、焦らずに「関連エンティティ」を間に置く定石パターンを思い出してください。複雑な関係が、2つのシンプルな「1対多」の関係に分解されます。
5. E-R図は、データベース設計の「上流」である
   ここで作成するE-R図が、後の「正規化」や「SQLでのテーブル作成（外部キー制約など）」の全ての土台となります。この繋がりを意識すれば、データベース分野全体の理解が深まります。

E-R図のスキルは、単に試験をパスするためだけのものではありません。顧客の要望をシステムの形にする、ITエンジニアの根幹をなす「設計力」そのものです。この知的なパズルを解き明かす楽しさを、ぜひあなたの自信に変えて、学習を続けていってください。

応援しています！