連関エンティティの説明のまえに、こんにちわ

こんにちわ。お昼もお茶ですね。まだまだ新米の京茶華です。

本日はデータベース設計をしている中でよく使う、
「連関エンティティ(中間テーブル)」について語ってみます。

具体例

まず、具体例ですが


ユーザーがマイページを持っていて、そこにプロフィール情報を書き込むような、
よくあるサイトを思い浮かべてみてください。


そういう時、たいていの場合

・名前
・生年月日
・性別
・住所
・メールアドレス
・趣味
.....etc.......


のような情報を登録すると思います。


この時、

名前や生年月日は、ひとりのユーザーに一つしかありません。
当たり前ですね！


そういう時は、そのままデータベースに入れてしまいます。自然ですね！


そうやって、「ああ、なんだ、簡単じゃないか！」と思って作業を進めていると
ぶつかります。


「趣味」です・・・


趣味はひとりのユーザーにとって一つとは限らないですよね！

要するに、N:N の関係です。


スポーツも音楽も本も・・・好きっていうことになると


それ用のカラムをどんどん増やしていかなければなりません！大変！


しかしここで少し頭を使って、「趣味カラムの中にコンマ区切りで連結すればいいんだ！」


とかを思いつき、趣味カラムの中に唖然とする位カンマ区切りの趣味がどんどん連結されて格納されたとしても、


その一瞬は楽でも、後々、JOIN できない！とか、いちいち LIKE で検索して取り出さないといけない！とか。。。


問題が発生し始めます。


その時に やっと本題！「連関エンティティ」を利用したら便利ですよ！

連関エンティティ利用方法

よし、連関エンティティを利用しよう！ということで

まず、上の例でいうと、


member テーブル がありますよね！


そのなかの member_id はまず、ユーザーにとって固有のものですよね。


なので、趣味をどんどん追加していっても便利に利用できる中間テーブル


「member_hobby テーブル」を作成して


user_hobby TABLE

| member_hobby_id | member_id | hobby_id |


とします。

hobbyテーブルには
| hobby_id | hobby_contents |


としてデータを持っておくことで

連関エンティティを利用し、

快適に JOIN も SELECT も行えてしまいます！便利ですよね！


この場合、hobby_id と member_id の組み合わせによって

member_hobby は一意のものとなります。


なお、hobby_id と member_id にはそれぞれ外部キーを設定します。


このように連関エンティティや外部キーを用いるデータベースを


RDB(リレーショナルデータベース)といいます。


複数のテーブルが「関係(リレーション)」で結ばれ、相互連結可能であり、


関係に対して「制限・射影・結合・和・差・交わり」などの関係代数演算（集合演算を含む）ないし関係論理演算を行うことで結果を取り出します！



現在、最もポピュラーなデータベース設計です！