【応用情報技術者試験】ER図の記号と解き方を徹底解説！データベースを得点源に変える学習法



応用情報技術者試験、午後のデータベース問題。多くの受験者が、まるで難解な暗号文のように見える「ER図（エンティティ関連図）」の前で、ペンが止まってしまった経験があるのではないでしょうか。

「記号の意味はなんとなく覚えたけど、問題文と結びつかない…」
「“1対多”はわかる。でも、なぜこの線には“〇”が付いて、あっちの線には付かないの？」

もしあなたが一つでも心当たりがあるなら、この記事はまさに、あなたのためのものです。

この学習記事のゴールは、単なる記号の暗記や解法パターンの紹介ではありません。あなたを長年悩ませてきたER図の本質を解き明かし、そのアレルギーを根本から治療すること。そして最終的には、苦手だったはずのER図をあなたの強力な「得点源」に変えることを目的とした、戦略的な学習ガイドです。

私たちは、「なぜ、この業務ルールが、この記号で表現されるのか？」という“思考のプロセス”を、具体的なシナリオに沿って、一つひとつ丁寧に解き明かしていきます。この記事を読み終える頃には、無機質に見えた記号たちが、まるで活き活きとした業務の物語を語りかけてくるように感じられるはずです。

さあ、私たちと一緒に、ER図という最強の武器を手に入れる旅に出かけましょう！

1. イントロダクション：なぜ、あなたのER図学習は「点」に繋がらないのか？

応用情報技術者試験の分厚い参考書を読み込み、データベースの章はマーカーでいっぱい。正規化の理屈も、リレーションシップの種類も、頭ではしっかり理解しているはず...。

それなのに、なぜか午後のデータベース問題になると、点数が伸び悩む。

特に、数ページにわたる長い問題文を読んだ末に現れる「下記の業務要件を満たすER図を完成させよ」という設問。ここで多くの受験者が、次のような壁にぶつかります。

• 問題文の日本語表現と、ER図の記号がうまくリンクしない。
• 解答・解説を読めば「なるほど、そうなるのか」と理解はできるものの、自力でその答えに辿り着ける気がしない。
• 自分の作ったER図が、本当に業務要件をすべて満たしているのか、確信が持てない。

この「わかる」と「できる」の間にある深い溝。その原因は、実はとてもシンプルです。それは、ER図の学習において、多くの人が「2段階の翻訳スキル」を体系的に訓練していないことにあります。

1. 【第1段階の翻訳】問題文の日常的な日本語を、抜け漏れのない厳密な「業務ルール」に変換するスキル。
2. 【第2段階の翻訳】その「業務ルール」を、ER図というデータベース世界の専門言語（記号）に正確に変換するスキル。

この記事は、この「思考の翻訳術」をあなたにインストールするために生まれました。単に記号の意味を一方的に解説するのではなく、具体的な業務シナリオ（ストーリー）を通じて、まるで隣にいるメンターが思考を実況中継するように、この2段階の翻訳プロセスを一つひとつ丁寧にトレースしていきます。

まずは肩慣らしに、ER図というものの「正体」から一緒に暴いていきましょう。

2. 結論ファースト：ER図とは「業務ルール」と「データベース」を繋ぐ共通言語である

さて、早速ですがこの記事の結論であり、最も重要なポイントからお伝えします。

ER図とは、一体何者なのでしょうか？小難しい定義は一旦忘れ、応用情報技術者試験を突破し、さらにその先の現場で活躍するためには、次のように理解してください。

ER図とは、
「業務のルール」をカタチにし、
「人とデータベース」とを繋ぐための共通言語である。

いかがでしょう？「ただの記号の集まり」と思っていたものが、少しだけ意味のあるものに見えてきませんか？

この「共通言語」という視点こそ、あなたのER図学習を劇的に変える鍵となります。

なぜ「共通言語」と言えるのか？

システム開発の現場には、経営者、現場の業務担当者、そして私たちIT技術者など、様々な立場の人が関わります。当然、使っている言葉も知識も異なります。

• 人と人を繋ぐ：「顧客が商品を注文する」という単純な業務一つとっても、「一度に複数商品を注文できる？」「注文履歴のない顧客はいる？」など、無数のルールが潜んでいます。これらを口頭や文章だけで完璧に共有するのは困難です。ER図は、そうした複雑な業務ルールを誰の目にも明らかな「図」という形で示すことで、関係者間の認識のズレを防ぐ「人と人との共通言語」の役割を果たします。
• 人とデータベースを繋ぐ：そして最も重要なのが、ER図はそのままデータベースのテーブル設計図になるという点です。ER図に描かれたエンティティ（箱）はテーブルに、アトリビュート（箱の中身）はカラム（列）に、そしてリレーション（線と記号）はテーブル間の関連付け（外部キー制約など）に変換されます。つまり、ER図は「人とデータベースとの共通言語」でもあるのです。

ER図を「暗記すべき試験の対象」から「業務を深く理解し、最適なデータベースを設計するための強力なツール」へと視点を切り替えること。これが、すべての始まりです。

この『共通言語』というパワフルな視点を手に入れた上で、次の章ではいよいよ具体的なER図の解剖に取り掛かりましょう！

3. 大図解：ER図の全体像と仕組みを“ECサイト”で見てみよう

「ER図は共通言語である」という視点、掴んでいただけたでしょうか？

では、その言語がどのような文法で成り立っているのか、全体像を把握していきましょう。どんなに複雑に見えるER図も、突き詰めればたった3つの基本パーツの組み合わせでできています。

ここでは、皆さんに馴染み深い「ECサイトの顧客と注文」を題材に、この3大要素を一つずつ見ていきましょう。

1. エンティティ（Entity）：管理したいデータの「かたまり」

エンティティとは、システムで管理したい「モノ」や「コト」を表す、いわばデータのかたまりです。応用情報技術者試験の問題文に出てくる名詞の多くは、エンティティの候補となります。

今回のECサイトの例では、「顧客」と「注文」が主要なエンティティにあたります。ER図では、これらを四角い箱で表現します。

（Point：エンティティは、最終的にデータベースの「テーブル」になります）

エンティティの中身：アトリビュートと主キー

エンティティの箱の中には、そのエンティティが持つ具体的な情報、すなわちアトリビュート（属性）を記述します。例えば、「顧客」エンティティは「氏名」や「メールアドレス」といったアトリビュートを持ちます。

そして、アトリビュートの中でも、他のデータと絶対に重複しない、その一件を特定するための唯一の項目を「主キー（Primary Key）」と呼び、下線を引いて示します。

（Point：アトリビュートはテーブルの「カラム」に、主キーは「主キー制約」が設定されるカラムになります）

2. リレーション（Relation）：エンティティ間の「関係性」

リレーションとは、その名の通りエンティティとエンティティの関係性を表します。「顧客」と「注文」の間には、「（顧客が）注文する」という関係がありますよね。ER図では、この関係性をエンティティ間を結ぶ一本の線で表現します。

3. カーディナリティ（Cardinality）：関係性の「数」と「ルール」

ここがER図の最重要ポイントです。カーディナリティ（多重度）とは、リレーションの線の両端にくっついている記号のことで、エンティティ間の関係が「1対1」なのか、「1対多」なのか、それとも「多対多」なのか、その数とルールを厳密に定義します。

「顧客」と「注文」の関係を考えてみましょう。

• 一人の顧客は、ECサイトで何度も買い物ができます。つまり、複数の注文を持つことができます。（これを「多」と考えます）
• 一方、一つの注文は、必ず特定の一人の顧客によって行われます。複数の顧客が一つの注文を共有することはありません。（これを「1」と考えます）

この関係は「1対多」となり、ER図では以下のように表現します。応用情報技術者試験で主流のIE記法では、「多い側」に鳥の足のような記号（<）をつけます。

おっと、鳥の足（<）の他に、縦線（|）も出てきましたね。実はこの記号には、さらに「その関係が必須なのか、それとも任意なのか」という、もっと深い意味が隠されているのです。

この記号の本当の意味こそが、ER図を完全にマスターする鍵となります。次の章で、この記号の謎を徹底的に解き明かしていきましょう！

4. なぜ？がわかる深掘り解説：記号の本当の意味をマスターする

お待たせしました。いよいよER図の心臓部、カーディナリティ記号の謎解きに挑みます。ここをマスターすれば、応用情報技術者試験のデータベース問題は、もはやあなたの得点源に変わります。

IE記法で使われる記号は、線の端につく「形」と「数」の組み合わせです。

• 線の形（関係の条件）：
  • |（一本線）：必須 (Mandatory) を意味します。「絶対に存在しなければならない」という強い制約です。
  • ○（まる）：任意 (Optional) を意味します。「存在しなくてもよい（ゼロでもOK）」という緩やかな条件です。
• 線の数（関係の数）：
  • |（一本線）：「1」 を意味します。
  • <（鳥の足）：「多」 を意味します。

この組み合わせによって、4パターンの基本表現が生まれます。これを「カーディナリティの魔法陣」として覚えましょう！

どうでしょうか？「1対多」と漠然と覚えるのではなく、「0以上か、1以上か」「1か、多か」を意識することが重要です。では、実際の業務シナリオでこの魔法陣をどう使うのか見ていきましょう。

シナリオ1：「社員」と「部署」の関係

ある会社の業務ルールが以下だとします。

• ルールA：社員は、必ずどこか1つの部署に所属する。
• ルールB：部署には、社員が1人も所属していない場合もある（例：新設されたばかりの部署）。

この日本語を、ER図の言葉に翻訳します。

• ルールAの翻訳：「ある社員」から見て、所属する「部署」は？ → 必ず1つ存在する。 → 記号は ―|―
• ルールBの翻訳：「ある部署」から見て、所属する「社員」は？ → 0人以上存在する。 → 記号は ―○<

これを繋ぎ合わせると、以下のER図が完成します。

シナリオ2：「多対多」の関係と「連関エンティティ」による解消

では、応用問題です。「注文」と「商品」の関係はどうなるでしょう？

• 1回の注文で、複数の商品を買うことができます。（注文から見て商品は「多」）
• 1つの商品は、複数の注文で買われる可能性があります。（商品から見て注文は「多」）

これは「多対多」の関係です。しかし、このままではデータベースのテーブルとして表現しづらいため、「どの注文で、どの商品が、何個売れたか」を管理するための中間テーブル（連関エンティティ）を挟んで、2つの「1対多」に分解します。それが「注文明細」エンティティです。

分解すると、関係はこうなります。

• 「注文」と「注文明細」：1回の注文には、1つ以上の明細が必ず含まれる。
• 「商品」と「注文明細」：1つの商品は、0個以上の明細に登場する（まだ一度も売れていない商品もある）。

これをER図にすると、以下のようになります。

このように、業務ルールを一つひとつ「魔法陣」の記号に翻訳していくことで、どんな複雑な関係も正確に図に落とし込むことができるのです。

5. 厳選過去問と思考トレース：思考のプロセスを実況中継！

理論は完璧ですね！では、その知識を使って、実際の試験問題をどう攻略するのかを見ていきましょう。

ここでは、応用情報技術者試験で出題されそうな典型的なシナリオ（フィットネスクラブの会員管理）を題材に、問題文の日本語をER図に翻訳していく思考のプロセスを、ステップ・バイ・ステップで実況中継します。

【想定問題】フィットネスクラブの予約管理システム

あるフィットネスクラブでは、会員制のクラス予約システムを導入することにした。システム化にあたり、以下の業務ルールが定められている。

業務ルール

• ルール1：クラブには複数の「会員」が在籍し、複数の「クラス」（ヨガ、エアロビクス等）が開催される。
• ルール2：会員は、希望するクラスを「予約」することができる。
• ルール3：会員になったばかりで、まだ一度も予約をしたことがない会員もいる。
• ルール4：一つの予約は、必ず一人の会員によって行われる。
• ルール5：まだ誰からも予約されていない、開催予定のクラスもある。
• ルール6：一つの予約は、必ず一つのクラスに対して行われる。

思考トレース開始！

Step 1：エンティティ（名詞）を抜き出す

まず、問題文から主要な「名詞」を抜き出し、管理すべきデータの固まり（エンティティ）を特定します。この問題では、ルール1と2から「会員」「クラス」「予約」の3つがエンティティの候補として浮かび上がりますね。

Step 2：エンティティ間の関係性を考える

次に、これらのエンティティがどう関係しているか考えます。

• 会員はクラスを「予約」する。
• クラスは会員に「予約」される。

ここで重要なのは、「会員」と「クラス」が直接関連するのではなく、「予約」というエンティティを介して関係している点です。これは、前章で学んだ「多対多」の関係性を解消する典型的なパターンです。（一人の会員は複数のクラスを予約でき、一つのクラスは複数の会員から予約されるため、「予約」エンティティが中間に入ります）

Step 3：業務ルールをカーディナリティ（記号）に翻訳する

ここが腕の見せ所です！一つひとつのルールを、前章の「魔法陣」を使って記号に翻訳していきましょう。

■「会員」と「予約」の関係性

• ルール3の翻訳：「ある会員」の視点から「予約」を見ます。「まだ一度も予約をしたことがない会員もいる」とあるので、予約は0件以上ですね。使う記号は ―○< です。
• ルール4の翻訳：「ある予約」の視点から「会員」を見ます。「必ず一人の会員によって行われる」とあるので、会員は1件必須です。使う記号は ―|― です。

■「クラス」と「予約」の関係性

• ルール5の翻訳：「あるクラス」の視点から「予約」を見ます。「まだ誰からも予約されていないクラスもある」ので、予約は0件以上です。記号は ―○< を使います。
• ルール6の翻訳：「ある予約」の視点から「クラス」を見ます。「必ず一つのクラスに対して行われる」ので、クラスは1件必須です。記号は ―|― です。

Step 4：ER図を組み立てて完成！

さあ、翻訳したパーツを組み合わせてER図を完成させましょう。

いかがでしたか？このように、問題文の日本語を一つずつ分解し、冷静に「必須か任意か」「1か多か」を判断していけば、迷うことなく正解のER図を導き出すことができるのです。

6. 未来を予測する出題予想：次は「サブスクリプションモデル」が狙われる！？

過去問のパターンをマスターすることはもちろん重要です。しかし、応用情報技術者試験は、常に現代のビジネストレンドを反映した問題を好んで出題します。

そこで、ここでは一歩先を見据え、次に出題が予想されるテーマとして「サブスクリプション（SaaS）モデル」のデータモデリングを考えてみましょう。

出題シナリオ予測：「SaaSプロダクトの契約管理」

あなたが開発を担当するのは、法人向けのSaaSプロダクト。このプロダクトには複数の料金プランがあり、顧客企業はいずれかのプランを契約してサービスを利用します。この業務を管理するためのER図を考えてみましょう。

キーとなるエンティティ

• 顧客：サービスを契約する法人企業。
• プラン：「フリープラン」「スタンダードプラン」「プレミアムプラン」など、サービスの料金プラン。
• 契約：どの顧客が、どのプランを、いつからいつまで利用するかを管理する。これが多対多を解消する連関エンティティになります。
• 請求：各契約に対して、毎月発行される請求情報。

ER図はこうなる！出題予想図

上記の業務をER図にすると、おそらくこのようになります。

なぜこの形になるのか？思考をトレース

• 「顧客」と「契約」：一社の顧客は、過去に解約して再契約するなど、複数の契約履歴を持つ可能性があります。そのため、「契約」は0件以上（―○<）。一方で、一つの「契約」は必ず一社の顧客に紐づきます（―|―）。
• 「プラン」と「契約」：一つのプランは、多くの顧客から契約される可能性があります。まだ誰も契約していない新プランもあるかもしれません。そのため、「契約」は0件以上（―○<）。一方で、一つの「契約」は必ず一つのプランに基づきます（―|―）。
• 「契約」と「請求」：一つの契約（例えば年間契約）に対して、請求は複数回（毎月）発生します。契約したからには、最低1回は請求が発生するはずです。そのため、「請求」は1件以上（―<）。一方で、一つの「請求」は、必ず一つの契約に紐づきます（―|―）。

このように、現代的なビジネスモデルも、これまで学んだ「業務ルールを記号に翻訳する」という基本原則を適用すれば、何も恐れることはありません。試験本番で初見のテーマが出ても、「まずはエンティティを特定し、関係性とルールを一つずつ翻訳していこう」と冷静に対処できるようになります。

7. 知識を体系化する関連マップ：点と点を線で結び、全体像を掴む

ER図の読み書きは、もはやマスターしたも同然ですね。しかし、なぜ私たちはこんなにもER図を重要視するのでしょうか？それは、ER図がデータベース設計という壮大な物語の、まさに「序盤のクライマックス」だからです。

ここでは、「正規化」「外部キー」「参照整合性」といった、あなたがこれまで個別に学んできたであろう重要キーワードが、ER図とどう結びつくのかを一枚のマップで示します。

このように、ER図は単なるお絵描きではなく、データの品質と一貫性を保証するための、データベース設計プロセス全体の根幹をなす非常に重要な工程なのです。

8. あなただけの学習ロードマップ：3つのステップでER図を完全制覇！

おめでとうございます！あなたは既に、ER図を読み解くための「地図」と「コンパス」を手に入れました。あとは、実際にその道を歩み、目的地である「ER図の完全マスター」に到達するだけです。

ここでは、知識を確実な得点力に変えるための、3ステップ学習ロードマップを提案します。

Step 1：【基礎固め編】記号の「気持ち」を言葉にする（所要時間：30分）

まずはウォーミングアップです。セクション4の「カーディナリティの魔法陣」をもう一度見返してください。そして、4つの記号（―|―, ―○|, ―<, ―○<）それぞれが、どのような業務ルールを表しているのかを、あなた自身の言葉で説明する練習をしてみてください。

例：「―<は、『俺の相手は最低1人はいないとダメなんだ！複数人いてもいいけどね！』って言ってるんだな」のように、記号を擬人化してみるのも効果的です。単なる暗記から、「気持ちを理解する」フェーズへと移行しましょう。

Step 2：【実践トレーニング編】小さなシナリオで「書く」練習（所要時間：1〜2時間）

次に、いきなり過去問に飛びつくのではなく、身近なテーマでER図を「書く」練習をします。これが最も重要なステップです。以下のテーマについて、自分でエンティティと業務ルールを定義し、ER図を作成してみましょう。

• 図書館の貸出管理（利用者、書籍、貸出記録）
• 大学の履修登録（学生、講義、履修登録）
• ブログシステム（投稿者、記事、カテゴリ）

Point：完璧な答えを出すことが目的ではありません。「業務ルールを定義し、それを記号に翻訳する」という、頭の動かし方を体に覚えさせることがゴールです。

Step 3：【本番攻略編】過去問で「読んで、書く」を反復実践（所要時間：過去問5年分）

基礎体力と実践力が身についたら、いよいよラスボス（過去問）との対決です。

1. 「読む」練習：解答にER図が載っている問題を使い、まずER図だけを見ます。そして、「なぜこのエンティティ間は―○<なんだろう？」と、図から業務ルールを逆算するトレーニングをします。これにより、記号への理解が飛躍的に深まります。
2. 「書く」練習：次はいよいよ、問題文の要件を読んでER図を作成する本番形式の演習です。これまで学んだ「2段階の翻訳スキル」をフル活用し、時間を計って解いてみましょう。

この3ステップを順番に踏むことで、あなたはもうER図の前で立ち止まることはありません。自信を持って、次の最終チェックに進んでください！

9. 理解度チェック＆チャレンジクイズ：最後の腕試し！

さあ、これまでに身につけた全ての知識とスキルを総動員して、最後のチャレンジに挑みましょう。以下の業務ルールを読んで、ER図を作成してみてください。紙とペンを用意して、まずは自力で解いてみることを強くお勧めします！

【チャレンジ問題】図書館の貸出管理システム

ある図書館の貸出管理システムを設計します。業務ルールは以下の通りです。

業務ルール

• ルール1：図書館には複数の「利用者」と、多数の「書籍」がある。
• ルール2：利用者は、気になる書籍を「貸出記録」として借りることができる。
• ルール3：利用者登録をしたばかりで、まだ一冊も本を借りたことがない利用者もいる。
• ルール4：一つの貸出記録は、必ず一人の利用者に紐づく。
• ルール5：図書館に受け入れたばかりで、まだ誰にも貸し出されたことのない書籍もある。
• ルール6：一つの貸出記録は、必ず一冊の書籍に対して作成される。

準備はいいですか？あなたの答えが決まったら、下の「解答・解説を見る」をクリックして答え合わせをしてみてください。

10. 最終チェックとまとめ：ER図は、もはや君の武器だ

ここまで本当にお疲れ様でした！もしあなたがこの記事を最初から最後まで、一つひとつ思考をトレースしながら読み進めてくれたなら、もうあなたにとってER図は「難解な暗号」ではなく、「ビジネスを語る言葉」に変わっているはずです。

最後に、この冒険で手に入れた5つの秘宝を、最終チェックリストとして授けます。

応用情報技術者試験の合格は、もちろん大きな目標です。しかし、このER図を読み解く力は、合格の先、あなたがITプロフェッショナルとして活躍する上で、必ずあなたの助けとなる強力な武器となります。

自信を持って、試験に臨んでください。そして、実務の世界で、素晴らしいデータベースを設計してください。

あなたの挑戦を、心から応援しています！