Web Analytics Made Easy - StatCounter

工業大学生ももやまのうさぎ塾

うさぎでもわかるをモットーに大学レベルの数学・情報科目をわかりやすく解説! 数式が読み込まれない場合は1回再読み込みしてみてください。

【基本情報対策】うさぎでもわかるソフトウェア工学 Part05 ER図

こんにちは、ももやまです。

今回は、データベースの論理設計で使われるER図について説明します。

具体的には、

  • ER図の読み方
  • 多重度の説明、読み方
  • ER図から実際にテーブルを作成する方法

 の3つについて説明しています。

 

 

前回のソフトウェア工学に関する記事はこちら!

www.momoyama-usagi.com

1.なぜER図が必要なのか

何かしらのデータを格納するデータベースを設計するとします。

しかし、いきなりデータベースの構造や仕様*1を設計するのはかなり難しいです。

 

そこで、「データベース上でデータをどうやって管理するか」を決める論理設計の前に、現実の世界をどのようにしてデータベース内に構築するかを決める概念設計を行います。

f:id:momoyama1192:20200726203238g:plain

 

この概念設計の際によく使われるのがER図(ERD、実体管理図)なのです!

(実際には、ER図を書く前に、管理するデータに矛盾や重複が発生しないように正規化を行います。正規化の仕方についてはこちらから。)

 

次の章からは、ER図の読み方、書き方について説明していきます。

 

2.ER図の設計例

ER図では、人間が他のものと区別してする実体(エンティティ)と実体同士の相互関係を表す関連(リレーション)の2つを使って、データの構造を図に表します。

(※基本情報などの情報処理試験でER図の問題が出てくるとき、なぜかエンティティやリレーションのようなカタカナ表記で出てくることが多いので、カタカナ表記も頭に入れておくことを強くおすすめします。)

 

ER図の書き方には、様々な書き方があります。

今回は、ER図の元祖であるPeter Chen記法と、実世界や試験でもよく使われるIE記法の2つをメインに説明したいと思います。

(1) Peter Chen記法

Peter Chen記法では、以下のような記号を用いて属性、実体、関連を表します。

f:id:momoyama1192:20200726203101g:plain

実際にER図を用いてデータの構造を表したものが下となります。

f:id:momoyama1192:20200726203050g:plain

早速、このER図の意味を読み取っていきましょう。

 

(i) 実体と属性

まず、実体と属性の関係を見てみましょう。

f:id:momoyama1192:20200726203105g:plain

例えば実体「学生」には、「学生番号」、「所属」、「名前」という3つの属性がありますね。

このように、実体が持つ性質を抽出していき、属性としていくことで実体と属性を抽出することができます。

 

もし、C言語を書いたことがある人は「構造体の名前」が実体、「構造体のメンバ(構造体の中にあるそれぞれの変数)」が属性と考えるとわかりやすいかもしれません。

(ii) 実体と関連

次に、実体と関連の関係を見てみましょう。

下の図は、学生と科目には「履修」という相互関係があることを示しています。

このように、2つの実体をひし形で挟むことにより、関連があることを示すことができます。f:id:momoyama1192:20200726203111g:plain

ここで、ひし形の横にNとMというよくわからないものが書かれていると思った人もいるかもしれません。

このNやMは、多重度と呼ばれ、それぞれの実体が何個の関連を持つかを表しています。

(iii) 関連に属性を持たせる

実体に属性を持たせることができることは先ほど説明しました。

同じようにして、関連にも属性を持たせることができます

 

例えば、下の図の場合、関連「履修」に属性「成績」を持たせていることが読み取れます。

f:id:momoyama1192:20200726203117g:plain

(2) IE記法 (Crow's Foot)

IE記法では、以下のような記号を用いて属性、実体、関連を表します。

実体と属性を1つにまとめて書くのがポイントです。

f:id:momoyama1192:20200726203056g:plain

※紫色で示されている記号  が鳥の足に見えるのでCrow's Feet(カラスの足)記法とも言われます

※多重度の読み方が少し特殊なので、後程説明したいと思います。

 

 

実際にIE記法を用いて先程Peter Chen記法で出てきたデータの構造を表したものが下となります。

f:id:momoyama1192:20200726203046g:plain

Peter Chen記法で出てきた「属性を持っている関連」もエンティティ(実体)とみなして記述するのがポイントです*2

f:id:momoyama1192:20200726203225g:plain

 

3.多重度(カーディナリティ)

ER図では、それぞれの実体が何個関連を持つのかを多重度(カーディナリティ)という形で表します。

(多重度の考え方はクラス図と同じです。)

 

ER図で出てくる多重度には、「1対1」、「1対多(1対N)」、「多対多(N対M)」の3種類があります。

f:id:momoyama1192:20200727004954g:plain

 

ここからは、3つの対応関係「1対1」、「1対多(1対N)」、「多対多(N対M)」がどのような意味なのかを説明していきます。

(1) 1対1

1対1とは、どちらの実体からももう一方の実体を一意に特定できる状態のことを表します。

専属の家庭教師のような関係が「1対1」です。

 

例えば、下のような教員と学生の関係があるとします。

f:id:momoyama1192:20200727004958g:plain

この場合、

  • ある1人の教員は、1人の学生を指導する
    (つまり、教員が分かれば指導している学生も一意に特定できる)
  • ある1人の学生は、1人の教員に指導してもらう
    (つまり、学生がわかれば指導してもらっている教員も一意に特定できる)

ことがわかります。

 

余談ですが、今の日本の結婚制度は一夫一妻制、つまり1人の夫に対して1人の妻が、1人の妻に対して1人の夫と結婚する「1対1」の結婚関係を結ぶ制度になっていますね。

(2) 1対多

1対多とは、ある一方の実体Aからもう一方の実体Bを一意に特定することはできるが、もう一方の実体Bからは実体Aを一意に特定することができない状態です。

学校や塾(個別指導を除く)の「先生」と「学生」のような関係が「1対多」です。

 

例えば、下のような教員と学生の関係があるとします。

f:id:momoyama1192:20200727005002g:plain

この場合、

  • ある1人の教員は、たくさんの学生を指導する
    (つまり、教員が分かっても指導している学生がたくさんいるため、一意に特定できない)
  • ある1人の学生は、1人の教員に指導してもらう
    (つまり、学生がわかれば指導してもらっている教員も一意に特定できる)

ことがわかります。

 

余談ですが、一部の国の結婚制度は一夫多妻制、つまり1人の夫に対してたくさん(0人以上)の妻が、1人の妻に対して1人の夫と結婚する「1対多」の結婚関係を結ぶ制度になっていますね。

(もちろん一妻多夫制でも「1対多」の結婚関係になります。)

(3) 多対多

多対多とは、ある一方の実体Aからもう一方の実体Bを一意に特定することはできないし、逆に実体Bから実体Aも一意に特定することができない状態です。

 

例えば、下のような教員と学生の関係があるとします。

f:id:momoyama1192:20200727005007g:plain

この場合、

  • ある1人の教員は、たくさんの学生を指導する
    (つまり、教員が分かっても指導している学生がたくさんいるため、一意に特定できない)
  • ある1人の学生も、たくさんの教員に指導してもらう
    (つまり、学生が分かっても指導してもらっている教員がたくさんいるため、一意に特定できない)

ことがわかります。

 

余談ですが、多夫多妻制、つまり1人の夫に対してたくさん(0人以上)の妻が、1人の妻に対してたくさんの夫と結婚する「多対多」の結婚関係を結ぶ制度がある国はない気がします。人間ではなく他の動物ならあったかもしれませんが。

他の記法での多重度の書き方

Peter Chen記法以外のERで「1対1」、「1対多」、「多対多」を記述する方法をまとめました。

f:id:momoyama1192:20200726203156g:plain

※ IE記法での多重度の書き方は、下のほうでより詳しく説明します。

4.IE記法での多重度の書き方

IE記法では、多重度を書く際に1やNのような数字や変数を使わず、専用の記号が使われます。

基本的には、

  • 0(〇を書く)
  • 1( | を書く)
  • たくさん(<か>を書く*3

の3つの基本表記が使われます。

 

ただし、IE記法では0を含むか含まないかを厳密に書くために基本表記の記号を2つ組み合わせた下のような多重度の表記が使われることが多いです。

f:id:momoyama1192:20200726203220g:plain

 

IE記法で多重度を表した例が下の図となります。

(Twitterのアカウント、ツイート、投稿画像の関係をIE記法でまとめたものです。)

f:id:momoyama1192:20200726203230g:plain

※本来は画像は4枚まで投稿できるのですが、IE記法の説明のために1枚までにしています。

 

5.多重度とリレーションスキーマの導出

(ここからはソフトウェア工学というよりはデータベースに関するお話になります。)

多重度を把握することで、ER図からリレーションスキーマ(テーブルを何個用意し、それぞれのテーブルに何を格納するか)を決めることができます。

 

ここでは、「1対1」、「1対多」、「多対多」それぞれの関連からリレーションスキーマを決める方法について説明します。

(1) 1対1のとき

1対1の関係の例としてTwitterにおける「ユーザー」と「プロフィール」の関係を例にし説明します。

f:id:momoyama1192:20200726203144g:plain

まず、

  • ユーザーの属性(ユーザーID、アカウント名、パスワード)を保存するテーブル
  • プロフィールの属性(プロフィールID、本文)を保存するテーブル

の2つを作ります。

 

1対1の場合、次に2つのテーブルをリンク(関連付け)させるために2つのテーブルのどちらか(もしくは両方)に*4、もう一方の主キー属性*5となる属性を追加します。

f:id:momoyama1192:20200726203150g:plain

今回の例の場合、

  • テーブル「プロフィール」にユーザーIDを追加
  • テーブル「ユーザー」にプロフィールIDを追加

することで2つのテーブルをリンクさせることができます。

 

なお、上のように2つのテーブルをリンクさせるために追加した他の表の主キーのことを外部キーと呼びます。

(プロフィール内にある「ユーザーID」もしくはユーザー内にある「プロフィールID」が外部キーとなります。)

(2) 1対多のとき

1対多の関係の例としてTwitterにおける「ユーザー」と「ツイート」の関係を例にし説明します。

f:id:momoyama1192:20200726203134g:plain

まず、

  • ユーザーの属性(ユーザーID、アカウント名、パスワード)を保存するテーブル
  • ツイートの属性(ツイートID、ツイート本文)を保存するテーブル

の2つを作ります。

 

1対多の場合、ある一方の実体Aからもう一方の実体Bを一意に特定することはできるが、実体Bからは実体Aを一意に特定することができない状態でしたね。

 

そのため、次に2つのテーブルをリンク(関連付け)させるために、多の方(今回の場合はリレーション)に1の方の主キー属性となる属性を追加します。

f:id:momoyama1192:20200726203140g:plain

なお、関連づけのために追加した属性は外部キーとなります。上の例の場合、テーブル「ツイート」にあるユーザーIDが外部キーとなります。

 

(間違えて1の方に主キー属性を追加すると、多の実体(今回の場合はツイート)を一意に特定することができないため、テーブルをリンクすることができない。)

(3) 多対多のとき

多対多の関係の例として先程出てきた「学生」と「科目」の関係を例にし説明します。

f:id:momoyama1192:20200726203124g:plain

まず、

  • 学生の属性(学生番号、所属、名前)を保存するテーブル
  • 科目の属性(科目番号、科目名)を保存するテーブル

の2つを作ります。

 

多対多の場合、ある一方の実体Aからもう一方の実体Bを一意に特定することはできないし、逆に実体Bから実体Aも一意に特定することができない状態でしたね。

 

そのため、1対1や1対多のように「別のテーブルの主キー属性となる属性」を追加するだけでは、2つのテーブルをリンクすることができません。

(多対多の場合、一意に特定ができないため、リンクができない)

 

そこで、関連(履修)を保存する新たなテーブルを作り、合計3つのテーブルとします。

 

3つ目のテーブルに、2つのテーブルの主キー(学生番号、科目番号)を追加し、さらに履修が持っている属性(成績)も追加することで、学生と科目の2つのテーブルをリンクさせることができます。

f:id:momoyama1192:20200726203129g:plain

(3つ目の表を作り、無理やり「学生と履修」の1対多の関係、「履修と科目」の多対1の関係を作ることで多対多の関係を「1対多」か「多対1」に分解していると思ってください。)

 

なお、関連づけるためにテーブル「履修」に追加した「学生」と「成績」は外部キーとなります。

多対多の場合、外部キーが少なくとも2つ必要な点に注意が必要です。

 

 

 

6.少し特殊な記法

ER図で使われる特殊な記法

  • 弱実体
  • 汎化関係

について確認しておきましょう。

(基本情報では出ないのでスキップしてOKです。)

(1) 弱実体

結ばれている関連自体が消滅すると同時に消える実体であることを強調する場合には、実体の枠を2重線で書きます。

f:id:momoyama1192:20200726235859g:plain

クラス図でいうコンポジションがほぼ同じような働きを持っています。

 

ただし、弱実体にするためには関連の消滅と同時に実体も消滅するようにするために、もう一方の実体が持っている主キーの属性(上の場合は科目の主キーの属性)を追加する必要があります。

 

(2) 継承

ある上位の実体の具体的な例を下位の実体と考えます。

このとき、下位の実体が上位の実体の属性を引き継いで使う機能のことを継承と呼び、下のような記号であらわされます。

f:id:momoyama1192:20200727001811g:plain

継承を行うことで、下位の実体は改めて属性を定義することなく、上位の実体の属性を使うことができます。

ただし、上位の実体の属性を追加するために、上位の実体が持っている主キーの属性を下位の実体にも追加する必要があります。

(例えば味噌ラーメンの例であれば、ラーメンが持っている主キーの属性を味噌ラーメンにも追加することで継承を実現できます。)

 

(継承は、オブジェクト指向にも出てくる重要な概念なので頭に入れておきましょう。)

7.練習問題

では、基本情報や応用情報の午前の問題でER図に関する知識を復習しましょう。

練習1

ER図の説明のうち、適切なものはどれか。

[基本情報技術者平成24年秋期 午前問26]

ア:エンティティタイプ間には、1対多、多対多などのリレーションシップがある。
イ:エンティティタイプ間の関連は、参照側から被参照側への方向の矢印線で表現する。
ウ:エンティティタイプには属性をもたせないで、リレーションシップタイプに属性をもたせる。
エ:エンティティタイプの中に関連先のエンティティ名を記述することによって、リレーションシップを表す。

練習2

ER図に関する記述として、適切なものはどれか。

[基本情報技術者平成24年春期 午前問28]

ア:関係データベースの表として実装することを前提に作成する。
イ:業務で扱う情報をエンティティ及びエンティティ間のリレーションシップとして表現する。
ウ:データの生成から消滅に至るデータ操作を表現できる。
エ:リレーションシップは、業務上の手順を表現する。

練習3

顧客は一般に複数の銀行に預金するものとして、顧客と銀行の関連を、E-R図で次のように表現する。このモデルを関係データベース上に"銀行"表、"口座"表、"顧客"表として実装する場合の記述として、適切なものはどれか。

f:id:momoyama1192:20200727005012g:plain

[応用情報技術者平成22年春期 午前問29]

ア:"銀行"表から"口座"表へのカーディナリティは多対1である。
イ:"銀行"表中に参照制約を課した外部キーがある。
ウ:"口座"表から"顧客"表へのカーディナリティは1対多である。
エ:"口座"表には二つ以上の外部キーがある。

 

8.練習問題の答え

解答1

解答:ア

[それぞれの選択肢ごとの解説]

ア:エンティティタイプ間には、1対多、多対多などのリレーションシップがある
→ 正しい。他にも「1対1」のリレーションシップもある。

イ:エンティティタイプ間の関連は、参照側から被参照側への方向の矢印線で表現する。
→ 誤り。矢印線ではなく、ただの線。

ウ:エンティティタイプには属性をもたせないで、リレーションシップタイプに属性をもたせる。
→ 誤り。エンティティタイプも属性は持たせている。(というかエンティティタイプをメインに属性を持たせている。)

エ:エンティティタイプの中に関連先のエンティティ名を記述することによって、リレーションシップを表す。
→ 誤り。リレーションシップは2つのエンティティを線で結ぶことで表す。

解答2

解答:イ

[それぞれの選択肢ごとの解説]

ア:関係データベースの表として実装することを前提に作成する。
→ 引っ掛け選択肢。確かにER図は関係データベースの表として実装することが多いが、前提ではない!!

イ:業務で扱う情報をエンティティ及びエンティティ間のリレーションシップとして表現する。
→ 大正解。

ウ:データの生成から消滅に至るデータ操作を表現できる。
→ 誤り。これはDFDの説明。DFDについてはこちらの記事をご覧ください。

エ:リレーションシップは、業務上の手順を表現する。
→ 誤り。リレーションシップは、エンティティ同士の相互関係を表す。

解答3

解答:エ

銀行と顧客の関係は多対多なので、関係データベース上に実装する際には、銀行と顧客の表だけでなく、2つの主キーを格納した顧客の表も実装する必要がある。

(銀行と顧客をリンクさせるために2つの主キーを格納した別の表を用意する必要がある)

 

具体的には、

  • 銀行の表(属性:銀行の主キー、…)
  • 顧客の表(属性:顧客の主キー、…)
  • 口座の表(属性:銀行の主キー、顧客の主キー、…)

の3つの表が必要。

 

ここで、銀行と口座、口座と銀行のカーディナリティを調べる。(選択肢アとウの正誤を確認するために)

3つの表の関係をIE記法(っぽい)ER図で書くと、下のようになる。

f:id:momoyama1192:20200727010308g:plain

よって、銀行と口座は「1対多」の関係に、口座と銀行は「多対1」の関係になる。

 

ここで、選択肢を見ていこう。

[それぞれの選択肢]

ア:"銀行"表から"口座"表へのカーディナリティは多対1である。
→ 1対多の間違い。

イ:"銀行"表中に参照制約を課した外部キーがある。
→ 間違い。外部キー(表と表を関連づけるために他の表の主キーを参照する列のこと)は銀行ではなく、"口座" 表中にある。

ウ:"口座"表から"顧客"表へのカーディナリティは1対多である。
→ 多対1の間違い。

エ:"口座"表には二つ以上の外部キーがある。
→ 正しい。銀行と顧客の2つの表を関連づけるまえに銀行の主キー、顧客の主キーと最低でも2つ以上の外部キーを用意する必要があるため。

 

9.さいごに

今回は、データベースの論理設計で使われるER図について説明しました。

どちらかというとソフトウェア工学というよりはデータベースの記事でしたね…。

 

ちなみに、Part07で説明する「クラス図」はER図の拡張版みたいなものなので、ER図を頭に入れておくことでクラス図の理解が少し楽になるかもしれません。

 

次回は、オブジェクト指向についての説明をしていきたいと思います。

*1:データベースがどんなデータを格納するかの構造、仕様を定めたものをスキーマと呼びます。なんだか難しそうに聞こえますが、

*2:IE記法では属性を書かないため、属性を持っている関連がある場合にはこのように実体とみなして記述する必要がある。

*3:左側の関連で使う場合は > を、右側の関連で使う場合は < を書きます。

*4:どちらの実体からももう一方の実体を一意に特定できるので。

*5:テーブル内の行を一意に識別できる属性のこと。IDや番号が用いられることが多い。