はじめに

プログラミング勉強中の👶です。
理解を深めるために日々の学びを記事にしています。
初心者の記事なので言い回しや記載に誤りがあるかも知れませんが、暖かく見守っていただけると幸いです。
(よろしければ間違いをコメントいただけると学び、励みになります！)

学んだこと

・ER図の書き方
・ECサイトのER図を実際に書いてみた（お遊び）

ER図とは

ER図は、「Entity Relationship Diagram」の略でデータベースの関係を体系化したものです。

ER図の構成

エンティティ：実体（登場人物や物、概念など）
アトリビュート：属性（エンティティの付加情報）
リレーション：エンティティ同士の関係性
カーディナリティー：エンティティ間の多重度

引用: 若手プログラマー必読！５分で理解できるER図の書き方５ステップ | NTTコミュニケーションズ法人のお客さま

ER図を設計する

下記の流れでデータベースを設計していきます。

エンティティを洗い出す
要件から属性を抜き出す
重複するもの（繰り返し項目）は分割する = データの正規化
外部キーで置き換える
マスタ項目を分割する
多重度を考える

完成はこんな感じになりました。

ER図に作成にはdraw.ioを使用しました。

1.エンティティを洗い出す
どんなテーブルがいるかな〜と考えます。

顧客関連:
　顧客(会員情報を登録する)
　配送先住所(注文者以外の配送先の登録用)
商品関連:
　商品(商品を登録する)
　商品ジャンル(検索機能実装する際の絞り込みに使用)
注文関連:
　カート商品(注文内容の仮の保管場所)
　注文商品(注文が確定した後の保存場所)
　
カート機能はDBでなくセッションに保存するという方法もあるようです。この場合、Webサイトから離れたり、セッションが切れるとカート内の情報が消えてしまいます。今回はWebサイトから離れていた場合もカート情報を記録しておくことを前提としました。
　
2. 要件から属性を抜き出す
3. 重複するもの（繰り返し項目）は分割する
4. 外部キーで置き換える
どんなカラムがいるかな〜と考えます。
意識したことは下記です。
実際にDBに使用することを意識して属性名を考えました。その際に命名の作法を調べて、具体的にどういう値なのか？が想像できる名前にしました。
プログラム上で処理できる項目は入れないようにする。
　例えば、商品エンティティに税込価格と税抜価格の両方を登録する必要があるでしょうか？私は不要と思います。プログラミング上で簡単に計算できるためDBに記録しておく必要がないと考えたためです。
　
また個人的に複数の商品を同時発注するための仕組みがイメージしづらく、苦戦しました。
注文の一連の流れを以下とします。

顧客が商品を選択して個数を登録する=>カート商品テーブルに保存 (商品名 x 個数)
顧客が注文を確定させる=>① 注文商品テーブルと②注文テーブルに注文内容を登録する
具体的には、① 注文商品テーブルにカート商品テーブルの内容を写します。また、どの商品が1回の注文の纏まりであるか判別するために注文id(後述の②注文テーブルの主キーidです)を副キーに登録します。②には主に注文に関する情報を記載します。どの商品がいくつ注文されたかについては、①注文商品テーブルでidで引き出せば問題なさそうですね。

5. マスタ項目を分割する
運用上、レコードの内容を変更する可能性があるものはマスタテーブルとして分割することがある。今回は、商品ジャンルをマスタ項目に設けました。

6. 多重度を考える
リレーションの確認をする。下記は推奨されないリレーションです。

1対1のリレーション：通常テーブルをまとめることができる
多対多のリレーション：正規化がうまくできず、整ったデータの持ち方ができない => 中間テーブルを作る

作ってみた感想

正直これが正解なのか・？という疑問はあります。実際のECサイトは値の変動や記録しておく値も多く、セール等もやっているので、もっと複雑なんだろうな。。と思いました。データベース設計の難しさに触れられたことは良い学びでした。
実際に運用されているデータベースも知りたいと思いました(好奇心と怖いもの見たさ)

終わり