慧音、この「E-R図」ってなに？
慧音、この「E-R図」ってなに？
E-R図か。
データベース系の問題でよく出てくるやつだな。
「でーたべーす」？
ああ。
様々なデータを集めて、管理しやすいようにしたものだ。
省略して「DB」とも読んでいるな。
「ディービー」ね。
外の世界の開発者の中には「デービー」と読んでいる者もいるようだな。
「D」と「B」のアルファベットの発音が似ているため、わざと「デー」と
言っているようだ。
ふうん。
で、それと「E-R図」と、どんな関係があるの？
ああ、そうだったな。
データベースと言っても、「どんなデータを集めるのか」を事前に決めておかないといけないなんだ。
また、「どんな風に管理するのか」なども決めておかないといけない。
このような作業を「データベース設計」と一般的に呼んでいる。
ううん、なんだか難しそうね。
そうだな、たとえ話をしようか。
外の世界における「学校」について、データベース設計を考えていこう。
「学校」には、そこに通っている「生徒」がいる。そして、授業を教える「先生」がいるわけだ。
さあ、他には何があると思う？
ええっと、確か………「試験」があるんだったよね。
授業をどれだけ理解しているかを確認するため、だったっけ。
そうだな、いいぞ妹紅。
あとは、「どの教師がどんな授業を担当しているか」や「誰がどんな試験を受けて、結果はどうだったのか」など、
そんな情報もあると、管理しやすくなるな。
………と、こんな風に考えながらデータベースのざっくりとした形を作っていくんだ。
学校一つとっても、意外と出てくるものなのね。
まあ、実際は学校の規模や作りたいデータベースによってかなり異なってくるだろうがな。
さて、このように考えて、以下のようなデータベースを設計したとしよう。
ねえ慧音、色が違うのは何か理由があるの？
それに、下線が引いてあるのと引いてないのがあるよ？
うむ、では一つずつ説明していこう。
緑色がついているのは「テーブル」といって、「データの集まり、入れ物」のようなものだ。
一般的にその名前は、「何のデータの集まりか」が分かりやすいものにする。
確かに、一目見ただけでなんとなく想像できるね。
続いて水色のものは「列」や「カラム」といって、テーブルの中身がどんな項目になっているか、
を表すものだ。
なるほど、「科目」テーブルには「科目コード」と「科目名」という列があるのね。
次に、下線の意味だが、「主キー」を表している。
「主キー」？
「主キー」というのは、「行」を一意に、つまり1行だけに絞れる列のことだ。
この説明では分かりにくいだろうから、例を出そう。
たとえば、誰かが落としたスペルカードがあったとする。さて、どうやって誰のものか見分ける？
どうやって、って………。
名前ぐらい書いてあるでしょ、所有者の名前が。それで分かるよ。
そのとおり。ということは逆に言えば、
「名前がなければ誰のものか分からない」＝「一意に決まらない」ということだ。
この「名前」にあたるものが、「主キー」と言われるものだ。
つまり、「主キーさえ決まれば、他の列の値が全て特定できる」ってこと？
その通りだ。そして、その性質ゆえに「重複と空値(NULL値)は許されない」。
特定できなくなるからな。
学校で、1つのクラスに「出席番号1番」が二人いたらおかしいだろう？
重複は分かったけど、「ヌル値」？ってなに？
うむ、「ヌル」とも「ナル」とも読むがな。
NULLは一般的には「なにもない」ことを表す。
そもそも「なにもない」ところから特定なぞできないからな、だから禁止されている。
なるほどねえ。
………あれ、そういえば慧音、いつまでたっても「E-R図」の話が出てこないんだけど？
そうだな、元々はいきなり「E-R図」から入るつもりだったが、
中の人が「せっかくだからDBから説明しようかな」などという、いらぬお節介をしてしまったからな。
そもそもこの講座が必要な人にとっては、上記の説明は「釈迦に説法」だったことだろう。
それでは、少し休憩を挟んで、本題に入るとするか。
りょうかーい。
さて、話が長くなってしまったが、E-R図の話をしよう。
E-R図の「E」と「R」だが、Eを「Entity（実体）」と言い、Rを「Relationship（関連）」と言う。
「実体」とは、先ほどの「テーブル」と同じだと思ってくれれば良い。
つまり、「E-R図」とは「テーブルごとの関連を表した図」だということだ。
テーブル毎の関連………分かるような分からないような。
まあ、それは後で説明しよう。
そして、「E-R図」はその関連を矢印で表す。
矢印の向きによって、「1対1」「1対多」「多対多」の関連を表すことができるんだ。
え？
「1」とか「多」ってなに？
そうだな………たとえば、妹紅を例にしよう。
妹紅は、「スペルカード」を持っている。つまり、「妹紅」という実体と「スペルカード」という実体は、関連があるということになる。
まあ、スペルカードは私も持ってはいるが………それは置いておこう。
さて妹紅、お前の持っているスペルカードは、1枚だけだろうか？
まさか、そんなことないよ。
「火の鳥 -鳳翼天翔-」でしょ、「パゼストバイフェニックス」でしょ、「フジヤマヴォルケイノ」でしょ、それから………
ああ、それぐらいでいい。
つまり「スペルカード」というくくりで考えた場合、妹紅「1人」に対して、スペルカード「複数枚」という関連になるわけだ。
これが「1対多」という関係だ。
ちなみに、E-R図で表すとこうなる。
ふむふむ。「1」のものから「多」のものに矢印が引かれるのね。
自分を「1」としたときに、相手が「1」なのか「複数」なのかを考えればやりやすいわね。
でも、「多対多」って、どんな状態なの？
うむ、それはだな………そうだ、上の表を使うとしよう。
「担当科目」というテーブルに着目して欲しい。
これは「誰がどの科目を担当しているか」を表している表だが、もしこのテーブルが存在していなかったら、どうなる？
え？
そりゃ、「ある教師の担当科目はどれか」が分からなくなっちゃうね。
それだけじゃないぞ。
「この科目の担当者は誰か」も分からなくなる。つまり、1度に2つも不明点が出来上がってしまう。
このままでは困るので、次のようにデータベースの構成を変えたとしよう。
あ、「科目」テーブルに「担当教員番号１」「担当教員番号２」「担当教員番号３」が増えて、
「教員」テーブルに「担当科目コード１」「担当科目コード２」「担当科目コード３」が増えたね。
………たぶん、データベースに詳しい人ならこの辺で色々と突っ込みたい衝動にかられているかと思うが、
とりあえず目をつぶっていて欲しい。
中の人によると、「多対多」の説明をするための表が、これぐらいしか思いつかなかったらしい。
慧音、誰と話してるの？
ん？ああ、あらかじめ一部の読者へのお詫びをな。
それはともかく、これでひとまず問題は解決だ。
さて、ここでもう一度、「科目」と「教員」の関連を考えてみることにしよう。
ああ、そっか、テーブルの形が変わっちゃったから、考え直さないといけないんだ。
えっと………「科目」テーブルから見た場合「科目コード」が「教員」テーブルの「担当科目コード1」「担当科目コード2」「担当科目コード3」に
複数存在できることになるから、1対多の関係になるね。
うん、そうだ。
では、「教員」テーブルから見た場合はどうだろうか？
うーん………あ。
これもさっきと同じなんだ。「教員」テーブルから見た場合、
「教員番号」が「科目」テーブルの「担当教員番号１」「担当教員番号２」「担当教員番号３」に複数存在するから、
やっぱりこっちも1対多の関係になるんだ。
その通りだ。
このように、両方のテーブルから見て、共に「1対多」になる場合、「多対多」の関係にある、という。
ちなみに、図で表すとこうなるな。
なるほど、両方に矢印が引かれるわけね。
………ただ、この「多対多」は、DB設計の面から見て、あまりよろしくない場合が多い。
え、なんで？
今さっき変更した「科目」テーブルと「教員」テーブルの構成を見てくれ。
「科目」テーブルの「担当教員番号１〜３」は、ある科目を担当する教員を最大3人まで登録するために設けられたものだ。
「教員」テーブルの「担当科目コード１〜３」も同じ目的だ。
うん、複数登録できるから便利だよね。
………本当にそう思うか、妹紅？
「最大3人（科目）まで登録できる」とは逆に言えば、「3人（科目）までしか登録できない」
ということだぞ？
え？でも、3人ぐらい登録できれば十分じゃない？
うん、ひょっとしたら十分かもしれない。だが、その保証はどこにもない。
また、いまは大丈夫でも、今後「やっぱり増やそう」となるかもしれない。
DBの設計というのは、一度決めると後から変更するのは大変な手間が掛かる。
安易に「これでいいだろう」などと決めてはいけないものなんだ。
け、慧音、ちょっと怖いよ。
む、そ、そうか？
どうも何かが乗り移ったらしいな。先日食べた中の人の黒歴史だろうか。
まあ、今回は「3人では足りない」としよう。
だからといって、列をいくつも増やしていくのも面倒だ。100も200もあったら大変だ。
………お腹壊さないようにね。
でも、そっか、「多対多」だと、データベースの設計が大変になるんだね。
うむ、そういうことだな。
まあ、実際のデータベースは「仕事のやりやすい形」を目指して設計するのでこの限りではないが、
一般的にはあまりおすすめできない形だろう。
なので普通は、最初に考えたような形にするということだな。
なるほどね。
さあ、本題の中の本題、「E-R図の矢印の引き方」について説明しようか。
なんだか、ここまで来るのに長かったね。
本来はこの話だけをするつもりだったのだがな。
「あ、E-R図の説明するならデータベースについてもちょっと触れておこうかな」からはじまり、
「どうせなら基礎から説明かな」などと考えるうちに今のような形に………
まったく、計画性がないにもほどがあるな。
ま、まあまあ。それで、E-R図の矢印の引き方ってどうするの？
実体、つまりテーブル同士の関連が分からないといけないんでしょ？
それに、さっき「テーブル同士の関連」について後で説明する、って言ってたけど………。
うむ、ちゃんと説明するぞ。
………とはいえ、「E-R図の矢印の引き方」については、既に近い話をしているのだがな。
え？どういうこと？
さっき、「多対多」の話をしただろう？
そのときに「科目」テーブルの項目が「教員」テーブルに複数あり、
「教員」テーブルの項目が「科目」テーブルに複数あるから「多対多」だという結論になっただろう。
うん、そういう話だったね。
実はこの「他のテーブルに同じ項目がある」ということがポイントなんだ。
たとえば「学生」テーブルの主キーは「学籍番号」となっているな。
そうだね。
つまり、同じ「学籍番号」は「学生」テーブルに1つしか存在しないんだよね。
うむ、その通りだ。そしてここからが大事なのだが、「試験」テーブルを見て欲しい。
主キーは「学籍番号」「科目コード」の2つだ。
つまり、「学籍番号」だけでは一意に決まらないということになる。
ということは、どういうことになるかな？
え、えっと………「学籍番号」だけでは決まらないということは………あッ！！
もしかして「試験」テーブルには、「学籍番号」が複数存在できる、ってこと！？
素晴らしい！！その通りだ。
「学生」テーブルには1つしか存在できない「学籍番号」が「試験」テーブルには複数存在する………
これこそが「1対多」の関係であるといえる。
そっかあ。
あるテーブルの主キーが、他のテーブルに存在したら、それが「関連がある」って言えるんだ。
だいぶ分かってきたようだな。
そして、その主キーが、他のテーブルでは複数存在できるとしたら、それは「1対多」となる。
ちなみに「1体1」の場合は、「お互いのテーブルの主キーになっている」状態と言えるだろうな。
さて、それらを確認したところで、今回のデータベースをE-R図にすると、こうなる。
「学生」「試験」「科目」の関連はさっき話したとおりだね。
あとは、「教員」から「担当科目」への矢印と、「科目」から「担当科目」への矢印があるんだね。
ああ、「担当科目」には「教員」の主キーである「教員番号」と
「科目」の主キーである「科目コード」が複数存在できるからな。
………さて、以上が「E-R図の矢印のひき方」だが、理解してもらえただろうか。
ポイントは「他のテーブルに、主キーと同じ項目があるかどうか」だね。
まあ、厳密に言えばこういう見分け方は誤っているのかもしれないが、
あまりにもE-R図が苦手だという人にとっては、理解するきっかけになれば幸いだ。
以上でひとまず講座を終わるが、感想や誤りの指摘などは随時募集しているぞ。
特に、中の人は思い込みで書くことが多いからね〜。
でも、あんまり厳しいこと書くと凹んじゃうかもしれないから程々にねっ。
それでは、「慧音先生の情報処理技術者試験対策講座」今回はこの辺で。
まったね〜♪
うむ、また会える日を楽しみにしているぞ。
それでは、また。
