ER図とは?
ER図もしくはERDとは
"Entity Relationship Diagram"のこと
DB設計において
「テーブルとテーブルを線でつなぎ、中身の種類と関係性見やすくしたもの」
と思っていただければ大丈夫です。
プログラミング学習者の方であればどこかで”鳥の足”みたいな先端で図表が結ばれたものを見たことがあるかもしれません。
それがERDもしくはER図。
簡素なものですがたとえば下のような図です。
ER図のリレーション表記法一覧
これだけだと少しわかりにくいかもしれないので簡単な例をいくつかみてみましょう。
例1: １ 対 多
ユーザーログイン機能とツイートが出来る簡単なアプリケーションがあるとします。
データベースにはusersテーブルとtweetsテーブルの２つのテーブルが下図のようにあります。
このテーブル間の関係性としては1対多となります。
user→→tweet
1人のuserに対してtweetの数は0か多
(※単なる"多"ではなく、"0か多(0以上)"として考えるのは一つもtweetをしないことも可能だからです)
tweet→→user
1つのtweetは必ず誰かuser1人が作成したもの。つまり、あるユーザーに属しているので下記の表記になります。
例2 1 対 1
例１にprofilesテーブルとimagesテーブルをプラスしたもの
user→→profile
profile→→user
userから見ると
user1人に対してprofileは１つなので1対1の関係となる。
逆も同じでprofile側から見ると
必ずuser１人に所属していると考えるので
tweet→→image
tweetから見たimageは
1tweetに対して最大1枚imageを持てるとし、
imageのないtweetもあるとするとリレーションは"０か1"となる
image→→tweet
imageから見たtweet。
一方でimageは1tweetに必ず所属していると考えるので図のような関係性になります。
1対多 ~制約がある場合~
tweetに対してimageの最低枚数に制約がある場合
"1か多"とは １対１もしくは1対複数のとき
例えば
オークションやフリーマーケットサイトでは１つの商品に対して画像が最低１枚は必要なのでこちら。１対１でも１対多でもOKな場合です。
単なる "多" とは 必ず1対複数、つまり２つ以上は必要
例えば
メッセージアプリなどでグループをつくるとなったらグループ内にメンバーが２人以上は必要ですよね。そんなときはこの表記になります。
one and only oneなど厳密な制約を持たせる関係性もありますが、今回は大まかによく使われる基本的なもののみを取り上げました。気づいたところがあれば、随時更新いたします。