データベース定義は超重要！システム開発を始める前に知っておきたい構造と構成の考え方

１対１の紐付け

最初はネットショップで考えてみましょう。

購入者ユーザーのアカウント情報1つに対して、配送先住所を1つだけ登録ができるとします。

これが1対1の関係です。

まず１つの方法として、お客さん情報テーブル内に配送先住所のカラムを用意するという方法があります。

これなら、必ず１対１という関係が成立します。

ですがこの場合、お客さん情報テーブル内のカラムが多くなりすぎて可視性が悪くなってしまうというデメリットがあります。

なのでそれを解消するためにも、それぞれ独立させたテーブルを用意するという方法をとりましょう。

こうすれば、各テーブルのカラム数も少なくなるので可視性が良くなりますね。

ですが、ただテーブルを分けてしまうと、どの住所がどのお客さんのものかがわからなくなります。そうならないために、配送先住所テーブル内に【お客さん情報ID】というカラムを持たせます。

こうすれば、お客さん情報を取得した際にはそのIDを使って配送先住所テーブルから該当の住所を判別することができますし、配送先住所側からでもどのお客さんのものなのかがわかります。

今後もお客さん情報と配送先住所の関係が１対１のままであれば、わざわざ分ける必要はありませんが、もし将来的に配送先住所を複数登録できるような構成にするのであれば、テーブルを分けておくことでリニューアル時のデータ引き継ぎでかかる負担も軽減されます。

１対Ｎの紐付け

先ほどのネットショップの例をそのまま使いましょう。

楽天通販を使ったことがある人であればわかるかも知れませんが、配送先住所を複数登録することができます。これは、お客さん１人に対して配送先住所が複数（N）紐付いているため１対Nの関係が成立します。

１対Nの場合、それを１つのテーブルで管理することは困難なため、先ほど紹介したようにお客さん情報テーブルと配送先住所テーブルの２つを用意します。

女性のお客さんが青背景のお客さん情報ID、男性は緑背景のお客さん情報IDに結び付きます。こうすることでお客さん１人に対して複数の住所をもたせることができました。

住所が増えたとしても、その住所が持っているお客さん情報IDカラムに対象のIDを入れるだけなので、制限をかけなければいくらでも住所を登録することができます。

１対１と違う点は、保有するIDが逆になるとその可視性は悪くなるということです。

１対１の場合は、お客さん情報で配送先住所IDを持っていたとしてもさほど変わりませんでしたが、１対Nの場合は住所が追加されるに合わせてカラムを増やすことは原則としてできないので、もし保有させる場合は配列のような形式で１つのカラムに複数の値を格納することになってしまいます。

普段データベースを触っていない人であれば、少し理解しづらいかも知れませんが、実際に試してみるとその問題点がすぐにわかるはずです。

このように、どちらが相手のIDを持つべきかということも考えなければなりません。

１対Nの関係を親と子で表す場合、１が親でNが子にあたります。原則として子（N）が親のIDを保有すると考えておきましょう。

Ｎ対Ｎの紐付け

最後はN対Nの関係をご紹介します。多数対多数というのはどういった状態を表すのか、お客さんと購入商品の関係で見てみましょう。

お客さんは複数、商品であるケーキも複数あります。どのお客さんがどのケーキを購入したかの関係を表す場合、どちらにIDを持たせても成立しませんね。

なぜなら、１対Nで説明したNG例と同じように、どちらのテーブルへ保存しようとしても、カラムを増やすか、配列のように１つのカラムへ複数の値を保存する必要があるからです。 

なので、N対Nの関係を結びつけるためには、更にテーブルを１つ用意することで解決させます。

真ん中のお客さん購入商品テーブルにはお客さん情報と商品それぞれのIDだけを保存します。

そうすることで、お客さん情報からでもお客さん購入商品テーブルを経由することで商品テーブルにたどり着くことが可能になります。※逆も可

実際に商品の購入情報を保存する際は、注文情報などを経由することになるので、今回のようなネットショップを作る際にはわざわざこのようなテーブルを準備することはないでしょう。ですが、注文情報テーブルがその役割を担っていたり、カート情報テーブルがその役割を担っていたりと、構造上は何か別のテーブルに置き換えられることになっていることがほとんどです。