プログラミング

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

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

 

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

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

 

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

 

 

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

 

ただユーザー情報を保存するだけのような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が必要になるものを作る際には、ぜひ参考にしてみてくださいね。

 

注目の記事

目先の利益に気をつけろ!貧乏ビジネスという落とし穴
フリーランス
目先の利益に気をつけろ!貧乏ビジネスという落とし穴

  目先の利益を求めてしまい、来たるべきビジネスチャンスに対応できないというケースは貧乏ビジネスに陥る大きな要因になります。また、相手が下す評価に左右されてしまうことも、自らの評価を下げてしまったり、見積もりを作る上でも大きく影響を及ぼしてしまいます。   今回は「目先の利益に気をつけろ!貧...

トークン認証とサニタイズ編 PHPポケモン 38 コード配布あり
プログラミング
PHP,PHPポケモン,ポケモン
トークン認証とサニタイズ編 PHPポケモン 38 コード配布あり

構成の見直し PHPポケモンも38回となり、大分作り込みが出来てきました。ここ最近はコードの説明ばかりでデモページなども準備出来ていませんでしたが、それには內部側の問題点が多かったためです。今回はその辺りをキレイに解決できるよう、本格的な構成の見直しをします。   ちなみにですが、どれぐらいの見直...

有料ノートが公開停止!?プラットフォーム依存の危険性とは
雑記
note,YouTube,ブログ
有料ノートが公開停止!?プラットフォーム依存の危険性とは

  「いままでのnoteがいきなり公開停止になった」 「YouTubeであげていた人気動画が削除された」   規約変更、違反などを理由にこういった被害は年々増えています。自覚して悪意あるコンテンツを作っているユーザーであれば当然の結果だと言ってしまえば済むことですが、努力して収益化する糸口を見つけ...

AIが人類にもたらす驚異!深層学習が与える影響とは
ネットワーク
AI,ディープフェイク,深層学習
AIが人類にもたらす驚異!深層学習が与える影響とは

  海外の記事でAIについて記述した興味深いものが掲載されました。   今回は「AIが人類にもたらす驚異!深層学習が与える影響とは」について、上記サイトを参考にまとめましたのでご紹介します。 ※直訳ではありません、あくまで記事の内容を参考にして自らの考えを記述したものです     AIの驚異と...

PHPポケモン「野生ポケモン遭遇編」18
プログラミング
PHP,PHPポケモン,ポケモン
PHPポケモン「野生ポケモン遭遇編」18

  PHPポケモンが第18回にしていよいよバトルの第一歩、野生ポケモンとの遭遇編に突入です。 新しいコントローラーの作成と、バトル画面の作成、そしてポケモンデータの受け渡しなどを中心にご紹介します。   バトル画面の実装  ポケモンのゲームでも、野生ポケモンが現れるとバトル画面へ移管し...

引き継ぎ考慮のメッセージID重複回避編 PHPポケモン 58
プログラミング
PHP,PHPポケモン,ポケモン
引き継ぎ考慮のメッセージID重複回避編 PHPポケモン 58

今回のPHPポケモンでは内部の作り込みをしていきます。見た目への反映は無いので、プレイを楽しみにしている人や、ポケモンが好きで毎日チェックしてくれているような人は、ブラウザをバックしてもらって問題ありません。   それでは、前々回辺りから保留にしていた「メッセージIDに重複回避対策」についてです。 &...

フリーランスが見積書を作るときに押さえておきたい3つのポイント+α
フリーランス
フリーランス,仕事依頼,独立,見積書
フリーランスが見積書を作るときに押さえておきたい3つのポイント+α

  仕事の依頼がきたけど、どれぐらいの金額を提示すればいいかわからない   駆け出しのフリーランスや、これから独り立ちしようとしている人に多い悩みです。 今回はそういった方のために「フリーランスが見積書を作るときに押さえておきたい3つのポイント+α」についてご紹介します。     時給...

データベース定義は超重要!システム開発を始める前に知っておきたい構造と構成の考え方
プログラミング
MySQL,データベース,プログラミング学習
データベース定義は超重要!システム開発を始める前に知っておきたい構造と構成の考え方

  システムやアプリ開発をする場合、そのほとんどでデータベースを使用しますね。 それぞれのデータを連携させるためにも、その構造をどうするかは重要で、設計が甘ければシステムそのものの保守性はもちろん、想定していた仕組みを実現するのが難しくなることもあります。   今回は、これからデータベースを...

カテゴリ

SEO対策 イベント デザイン ネットワーク ビジネスモデル フリーランス プログラミング マーケティング ライティング 動画編集 雑記

タグ

5G Adobe AfterEffects AI ajax amazon Animate api artisan atom Automator AWS Bluetooth CSS CVR description EC-CUBE4 ECショップ ESLint Facebook feedly foreach function Google Google AdSense Honeycode htaccess HTML IEEE 802.11ax Illustrator Instagram IoT JavaScript jQuery jQuery UI keyword LAN Laravel Linux MacBook MAMP meta MLM MySQL NoCode note OS OSI参照モデル Paypal Photoshop PHP phpMyAdmin PHPポケモン PremierePro rss SEO SEO対策 Sequel Pro Skype SNS SSH Symfony TCP/IP title Toastr Trait Twig Twitter UCC V系 WAN WebSub Wi-Fi wiki Windows WordPress XAMPP xml Xserver YouTube YouTuber Zoom アーティスト アウトプット アクセス層 アニメーション アフィリエイト イーブイ インターネット インプット エンジニア オブジェクト指向 お金配り クリック単価 クリック数 コミュニケーション能力 コロナ コンサルティング サムネイル システムエンジニア スタートアップ スタイルシート スパム データベース ディープフェイク デザイナー デザイン テレワーク ナンパ ニュース ネットワークモデル ノマドワーク バナー ピカチュウ ビジネス フィード フリーランス ブロガー ブログ プログラマー プログラミング プログラミング学習 プログラミング教育 プロトコル ホームページ制作 ポケモン マークアップ マーケティング メール リモートワーク レンダリング 三井住友 三宮 仕事依頼 児童デイ 児童デイサービス 児童発達支援 公開鍵 初心者 助成金 勉強法 営業 広告 広告収入 必勝マニュアル 放課後等デイサービス 朝活 楽天 深層学習 無線LAN 独立 神戸 福祉 秘密鍵 翻訳 自己啓発 英語 見積書 計算機 読書 起業 迷惑メール 配列 銀の弾丸 集客 雑学力