基本情報のER図｜主キーと多重度の読み方

基本情報技術者試験のデータベース分野で、ER図を見ると急に手が止まる人は多いかなと思います。四角や線が出てくるだけならまだよいのですが、主キー、外部キー、多重度、エンティティなどの言葉が重なると、どこから読めばよいのか迷いやすいですね。

この記事では、基本情報のER図を、暗記用語ではなく「表を作る前の地図」として読めるように整理します。SQLや正規化の細かい話に入りすぎず、試験問題でまず確認する順番、関係の数の見分け方、主キーと外部キーの考え方を中心に解説します。

基本情報のER図の基礎

ER図はデータの地図

ER図は、システムで扱うデータ同士の関係を図で表したものです。基本情報では、いきなり完成したSQL文を書くよりも先に、どのデータを分けて持つのか、どのデータ同士がつながるのかを読み取る場面で出てきます。私は、ER図を「表の完成形」ではなく「表を作る前の地図」と見るとかなり楽になると思っています。地図なので、最初から細かい列名を全部暗記するより、どのまとまりがあり、どのまとまりが線でつながっているかを見るのが先です。

たとえば、顧客、注文、商品というデータがあるなら、顧客と注文は関係し、注文と商品も関係します。ただし、顧客名や住所のような細かい項目まで一気に見ると混乱します。まずは「顧客というまとまり」「注文というまとまり」「商品というまとまり」がある、と大きく分けます。そのあとで、顧客は注文を何件持てるのか、注文は商品を何個含めるのか、という関係の数を確認します。

基本情報のER図で最初に見るべきなのは、箱の名前と線のつながりです。細かい属性やキーは、そのあとで確認すれば十分です。

見る場所	意味	試験での使い方
箱	データのまとまり	表の候補として考える
線	まとまり同士の関係	どの表を結合するか考える
線の端	関係の数	一対多か多対多かを判断する

ここを押さえると、ER図は急に読みやすくなります。図全体を眺めて「なんとなく難しそう」と感じるのではなく、箱、線、線の端という順番で分解するわけですね。特に基本情報の問題では、業務ルールの文章とER図がセットで出ることがあります。そのときも、文章中の名詞を箱に対応させ、動詞やルールを線に対応させる意識を持つと、図と問題文がつながりやすくなります。

さらに、ER図は「正解の図形を暗記する」テーマではありません。問題文にある業務ルールを、表にしやすい形へ整理するための道具です。だから、見慣れない題材でも、地図を見るように大きな構造から入れば対応できます。

エンティティは表の候補

エンティティは、管理したい対象や出来事のまとまりです。基本情報のER図では、四角形で表されることが多く、後でデータベースの表になる候補だと考えるとわかりやすいです。顧客、商品、注文、社員、部署、貸出、予約など、業務の中で何度も登場し、情報を記録したいものがエンティティになりやすいですね。

ただし、問題文に出てくる名詞をすべてエンティティにするわけではありません。たとえば「顧客の住所」は、住所そのものを独立して管理したいのでなければ、顧客エンティティの属性として扱うことが多いです。一方で「注文」は、顧客が行う行為ですが、注文日、注文番号、注文金額などを持つ重要な出来事なので、エンティティとして扱いやすいです。この違いがつかめると、ER図の箱がなぜ分かれているのか納得しやすくなります。

試験では、エンティティを「表の候補」として見るのが実用的です。箱があれば、そこには複数件のデータが入る可能性があります。顧客エンティティなら顧客データが何件も入り、商品エンティティなら商品データが何件も入ります。つまり、エンティティは一つのデータそのものではなく、同じ種類のデータを集める入れ物です。

• 独立して何件も登録されるものはエンティティ候補
• 番号や日付などの細かい情報は属性候補
• 行為でも記録が必要ならエンティティ候補
• 迷ったら「表にしたいか」で考える

ここで大切なのは、完璧な分類を最初から狙わないことです。基本情報の問題は、実務の設計レビューではなく試験問題です。問題文にある制約や図中の線から、もっとも自然なまとまりを選ぶことが目的になります。名詞を拾う、何件も発生するか見る、表にしたいか考える。この三段階で見るだけでも、エンティティの判断ミスはかなり減らせます。

属性は列の候補

属性は、エンティティが持つ具体的な情報です。顧客エンティティなら顧客番号、氏名、住所、電話番号などが属性になります。商品エンティティなら商品番号、商品名、単価、分類などですね。表で考えると、エンティティが表の候補、属性が列の候補です。ER図では属性まで細かく書かれる場合もあれば、エンティティ同士の関係だけを中心に示す場合もあります。

基本情報で属性を見るときは、「この情報はどの表に置くのが自然か」を考えます。注文日を商品エンティティに置くと、商品ごとに注文日が固定されるような変な構造になります。注文日は注文が発生した日なので、注文エンティティに置くのが自然です。このように、属性は意味の近いエンティティへ置くのが基本です。暗記というより、データが何を説明しているのかを読む感覚ですね。

また、同じ属性を複数の表に持たせると、更新漏れや矛盾が起こりやすくなります。基本情報では正規化の考え方ともつながる部分です。顧客名を注文表にも商品表にも毎回持たせるのではなく、顧客表に置いて顧客番号で参照する、という考え方が外部キーにつながっていきます。

属性の例	置き場所の考え方	注意点
顧客名	顧客を説明する情報	注文ごとに重複させない
注文日	注文を説明する情報	商品側へ置かない
単価	商品を説明する情報	価格変更履歴が必要なら別設計もある

試験では、属性を細かく設計しきるよりも、明らかに置き場所がおかしいものを見抜く力が重要です。問題文で「注文ごとに記録する」「商品ごとに設定する」「顧客ごとに管理する」のような表現があれば、それぞれの属性の置き場所を判断するヒントになります。列名を丸暗記するのではなく、何を説明する情報なのかを読むようにしましょう。

主キーと外部キーの役割

主キーは、表の中の1行を一意に見分けるための項目です。顧客表なら顧客番号、商品表なら商品番号、注文表なら注文番号のようなものですね。同じ顧客名の人が複数いる可能性を考えると、氏名だけでは1人を確実に特定できません。そのため、試験では番号やIDのように重複しない項目が主キーになりやすいです。

外部キーは、別の表の主キーを参照するための項目です。注文表に顧客番号を持たせると、その注文がどの顧客のものかを示せます。ここで注文表の顧客番号は、顧客表の主キーである顧客番号を参照する外部キーです。主キーが「自分の表の行を見分ける目印」だとすると、外部キーは「別の表とつながるための目印」と考えると覚えやすいです。

基本情報のER図では、この主キーと外部キーを見れば、どちらが親でどちらが子かを判断しやすくなります。顧客と注文なら、顧客1件に対して注文は複数件あり得ます。すると、複数件発生する注文側に顧客番号を持たせるのが自然です。つまり、一対多の多側に外部キーが入ることが多い、という見方ができます。

複合キーが出てきても、考え方は同じです。複数の項目を合わせて1行を特定するだけで、「一意に見分ける」という主キーの役割は変わりません。まず役割で見てから、1項目なのか複数項目なのかを確認しましょう。

もちろん、実務では複合キーや代理キーなど、もう少し細かい設計もあります。ただ、基本情報の学習段階では、まず主キーと外部キーの役割を混ぜないことが大切です。主キーは自分を見分ける、外部キーは相手を参照する。この二つの役割を分けて読めれば、ER図から表構造を想像しやすくなります。

多重度は関係の数

多重度は、エンティティ同士が何件対何件で関係するかを表すものです。基本情報のER図で迷う原因の多くは、この多重度にあります。顧客と注文なら、1人の顧客は複数の注文を行えますが、1件の注文は通常1人の顧客に属します。この場合は一対多です。社員と部署なら、1つの部署に複数の社員が所属し、1人の社員は1つの部署に所属するというルールなら、これも一対多です。

一方で、学生と科目のように、1人の学生が複数の科目を履修し、1つの科目にも複数の学生がいる場合は多対多です。多対多はそのまま表にしにくいため、中間表を作る考え方につながります。ここを理解しておくと、ER図だけでなく、SQLの結合や正規化の問題もかなり読みやすくなります。

多重度を読むときは、問題文を片方向ずつ声に出すように確認するとミスが減ります。「1人の顧客は何件の注文を持てるか」「1件の注文は何人の顧客に属するか」という形です。両方向を一度に考えると混乱しやすいので、片方ずつ見ます。

関係	例	考え方
一対一	社員と社員証	片方1件に相手も1件
一対多	顧客と注文	親1件に子が複数
多対多	学生と科目	両方から見て複数

最小件数にも注意すると、より丁寧に読めます。たとえば、顧客はまだ注文していない可能性があるのか、注文は必ず顧客に属するのか、という条件です。基本情報では最大件数の判断が中心になりやすいですが、空欄補充や設計の妥当性を問う問題では、必須か任意かもヒントになります。

試験で大事なのは、記号の形だけを暗記しないことです。ER図の表記法は教材によって少し違うことがありますが、問題文に書かれた業務ルールは共通して読めます。多重度は、記号を見る前に文章で確認する。これを習慣にすると、知らない図の表記が出ても落ち着いて対応しやすくなります。

基本情報のER図の解き方

問題文から名詞を拾う

基本情報のER図問題を解くときは、図を先に細かく読むより、問題文から名詞を拾うところから始めるのがおすすめです。顧客、商品、注文、社員、部署、貸出、予約など、業務上管理したい対象を線で引いていきます。名詞を拾うだけなら難しくありませんし、エンティティ候補を早く見つけられます。

次に、その名詞が本当にエンティティになるかを確認します。単なる属性なら、独立した箱ではなく、どこかのエンティティの列として扱います。たとえば「注文日」は名詞っぽく見えますが、通常は注文の属性です。「顧客住所」も、住所を独立して管理する問題でなければ、顧客の属性です。逆に「貸出」や「予約」は行為ですが、履歴として何件も発生するため、エンティティになることがあります。

この段階では、問題文に出てくる動詞もヒントになります。「顧客が注文する」「社員が部署に所属する」「学生が科目を履修する」のような文は、エンティティ同士の関係を表しています。名詞で箱を作り、動詞で線を考える。この流れで読むと、ER図が文章の内容とつながります。

拾った名詞は、すぐに確定しなくて大丈夫です。最初は候補としてメモし、後から属性に下げたり、中間表として扱ったりします。問題文を一度で完璧に分類しようとすると時間を使いすぎるので、候補を広めに出してから絞る方が実戦向きです。

基本情報の出題範囲全体を確認したい場合は、基本情報技術者試験の出題範囲を解説した記事も合わせて見ると、データベース分野をどこに位置づければよいか整理しやすいです。ER図だけを孤立して勉強するより、テクノロジ系の中の一テーマとして扱うと負担が減ります。

一対多を先に決める

ER図の関係を読むときは、一対多を先に決めると進めやすいです。基本情報の問題では、一対多の関係がよく出ます。顧客と注文、部署と社員、分類と商品、著者と書籍など、片方が親のような役割を持ち、もう片方が複数件ぶら下がる形ですね。

一対多を見分けるコツは、「1件のAに対してBは何件あり得るか」「1件のBに対してAは何件あり得るか」を片方向ずつ確認することです。顧客1人に対して注文は複数件あり得ます。一方で、注文1件が複数の顧客に属することは通常ありません。この場合、顧客から注文へ一対多です。多側である注文表に、顧客を参照する外部キーを持たせるのが自然になります。

この判断ができると、外部キーの置き場所もかなり読みやすくなります。多側の表は、どの親に属するのかを示す必要があります。だから、注文表には顧客番号、社員表には部署番号、商品表には分類番号のような外部キーが置かれやすいです。もちろん問題文のルールが最優先ですが、基本の型として覚えておくと便利です。

図の線の向きや記号が気になったときも、まず文章に戻りましょう。図だけで判断しようとすると、表記法の違いに引っ張られます。文章で一対多を確認できれば、記号はその確認として使えます。

注意したいのは、現実世界の感覚だけで判断しないことです。たとえば「社員と部署」は、多くの教材では1人の社員が1つの部署に所属する前提で扱います。しかし、問題文で兼務や複数所属が明示されていれば多対多に近くなります。試験では、一般論より問題文の条件を優先しましょう。

多対多は中間表で分ける

多対多は、ER図で特にひっかかりやすい関係です。学生と科目、注文と商品、社員と資格のように、片方から見ても複数、反対側から見ても複数になる関係ですね。この関係をそのまま一つの外部キーで表そうとすると、1つのセルに複数の値を入れたくなったり、同じ情報を何度も重複させたくなったりします。

そこで使うのが中間表です。学生と科目なら、学生表と科目表の間に履修表を作ります。注文と商品なら、注文表と商品表の間に注文明細表を作ります。中間表には、それぞれの表の主キーを参照する外部キーを置き、必要に応じて数量や登録日など、その関係に属する属性を持たせます。

基本情報のER図では、「多対多を見たら中間表を考える」と覚えておくと強いです。特に注文と商品は、1件の注文に複数の商品が含まれ、1つの商品は複数の注文に含まれます。このままだと多対多なので、注文明細のような中間エンティティが必要になります。

多対多の例	中間表の例	中間表に入りやすい属性
学生と科目	履修	履修日、成績
注文と商品	注文明細	数量、販売単価
社員と資格	保有資格	取得日、有効期限

中間表は、二つの表をつなぐだけでなく、関係そのものの情報を持てる点も重要です。注文と商品の関係なら数量、学生と科目の関係なら成績のように、どちらか片方の表だけには置きにくい属性があります。

中間表を作る理由は、図をきれいにするためだけではありません。後でSQLで集計したり、正規化で重複を減らしたりするためにも必要です。多対多を中間表で分けられるようになると、ER図、表設計、SQLの結合が一本の流れとして見えてきます。ここは得点につながりやすいので、例をいくつか自分で作って練習するとよいですね。

SQLと正規化へつなげる

ER図は、単独で終わるテーマではありません。基本情報では、SQL、正規化、テーブル設計とつながります。ER図でエンティティを表に落とし込み、属性を列にし、主キーと外部キーを決める。その結果として、SQLで結合できる表構造が見えてきます。つまりER図は、データベース問題の入口のような位置づけです。

たとえば、顧客表と注文表が顧客番号でつながっているなら、SQLでは顧客番号を使って結合できます。商品表と注文明細表が商品番号でつながっているなら、注文ごとの商品名や数量を取り出せます。このように、ER図で線として見えていたものが、SQLではJOINの条件として現れるわけです。図とSQLを別々に暗記するより、外部キーでつながるから結合できる、と考える方が自然です。

正規化とも関係します。属性の置き場所を間違えると、同じデータが何度も出てきたり、更新漏れが起こったりします。顧客名を注文表に毎回書くより、顧客表にまとめて顧客番号で参照する方が管理しやすいです。これは正規化の考え方にも近いですね。

SQLや正規化をもう少し詳しく確認したい場合は、基本情報技術者試験のSQL・データベース問題を解説した記事で、正規化や結合の流れを合わせて復習するとつながりが見えやすくなります。

• ER図の箱は表の候補として見る
• 属性は列の候補として見る
• 主キーと外部キーはJOINの手がかりになる
• 重複が多い構造は正規化の観点で見直す

この流れで学ぶと、データベース分野の知識がバラバラになりにくいです。ER図で構造を読む、正規化で重複を減らす、SQLで必要な情報を取り出す。基本情報のデータベース対策では、この三つをつなげて覚えるのが効率的かなと思います。

基本情報のER図まとめ

基本情報のER図は、最初は記号が多く見えて難しく感じます。ただ、読む順番を決めればかなりシンプルです。まず箱を見てエンティティを確認し、次に属性をどこへ置くかを考え、主キーと外部キーで表同士のつながりを読み、最後に多重度で一対多か多対多かを判断します。この順番を守るだけで、図全体を一気に理解しようとして混乱する状態から抜けやすくなります。

特に大事なのは、多重度を問題文から読むことです。記号だけを丸暗記すると、表記が少し違う問題で止まります。ですが、「1件のAに対してBは何件あるか」「1件のBに対してAは何件あるか」と片方向ずつ読めば、関係の数は判断しやすくなります。多対多なら中間表を作る、一対多なら多側に外部キーを置く。この型を使えるようにしましょう。

学習するときは、ER図だけを眺めるより、短い業務例を自分で表にする練習が効果的です。顧客が商品を注文する、学生が科目を履修する、社員が部署に所属する、というような例を使って、箱、線、主キー、外部キー、多重度を順番に書き出してみてください。慣れてくると、基本情報のデータベース問題でも、どこから読めばよいか迷いにくくなります。

なお、出題範囲やシラバスの最新情報は、IPA公式の試験要綱・シラバスページで確認できます。学習の全体像をつかみたい方は、基本情報のテクノロジ系勉強法も合わせて読むと、データベース分野の優先度を決めやすいです。正確な情報は公式サイトをご確認ください。