データベース定義は超重要!システム開発を始める前に知っておきたい構造と構成の考え方
2020年6月20日 (最終更新日:2020/6/20 14:42)

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

 

システムやアプリ開発をする場合、そのほとんどでデータベースを使用しますね。

それぞれのデータを連携させるためにも、その構造をどうするかは重要で、設計が甘ければシステムそのものの保守性はもちろん、想定していた仕組みを実現するのが難しくなることもあります。

 

今回は、これからデータベースを使ってシステムやアプリの開発をしようと考えている方や、現在プログラミングを学習中の人を対象に「システム開発するなら覚えておきたいデータベース構造」について、基礎的な考え方をご紹介します。

 

 

テーブルの紐付けはこう考える

 

ただユーザー情報を保存するだけのようなDBを作るだけであれば、テーブルを作ってそこに項目分のカラムを作成し、一つずつ保存するだけでも支障はありません。ですが、せっかくDBを使うのであれば、情報を紐付けしたり各情報を連携させて管理させることで、そのメリットが見いだせるようになります。

 

そうするためにも、どういったテーブル構造で紐付けをするかはとても重要なのです。

今回は、その中でも初歩的な11からNNの考え方までを一つずつご紹介します。

 

 

1対1の紐付け

 

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

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

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

 

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

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

 

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

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

 

 

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

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

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

 

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

 

 

1対Nの紐付け

 

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

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

 

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

 

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

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

 

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

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

 

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

 

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

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

 

 

N対の紐付け

 

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

 

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

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

※場合によっては、複数の値を持たせるために配列をJSON形式にして1つのカラムに保存する方法も確かに存在します。ですが、可視性はもちろんデータを取り出す処理や関連付けが難しいといったデメリットがあるため、本当に必要な状況でしか採用されないと考えておいた方が良いでしょう。

 

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

 

 

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

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

 

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

 

 

まとめ

 

いかがだったでしょうか。

今回はデータベース定義における初歩的な関連付けを3つ紹介しました。

もし自分でアプリ開発をしたり、業務システムのようなDBが必要になるものを作る際には、ぜひ参考にしてみてくださいね。

 

Copyright © 2016-2020 YQUAL All Rights Reserved.