DB設計|ECサイトのER図を作成する
ECサイト作成のため、ER図を作成しました。
一つずつ中身を確認します。
会員
必要な会員情報のカラムを作成しました。
退会ステータス
会員が退会する時、会員データを削除するのではなく、退会ステータスを true
にすることにします。これは、退会済みの会員の過去の注文履歴などを確認したい場面が想定できるからです。
配送先
会員が複数の配送先を作成できるようにしました。
カート内商品
会員が複数の商品を「カート内商品」として持つことができるようにしました。
また、1つの商品は複数の会員のカート内商品になりえます。
カート内商品に「個数」カラムを持たせることで、同じ商品を複数個カートに入れた時、無駄なデータを作成しなくて済みます。
元々、会員対商品 は 多対多 の関係です。(ある会員は複数の商品を持つことができ、ある商品は複数の会員に持たれることができます。)そのため、「カート内商品」は中間テーブルのような働きをしています。
商品
商品に必要な情報を記載しています。
ジャンルid
これは、ジャンルをマスターテーブルに分割したため、作成された外部キーです。
販売ステータス
販売ステータスには、「販売中」「売り切れ」があります。
ジャンル
商品のジャンルを表すマスターテーブルです。
注文
注文済みのデータを管理するテーブルです。
配送先宛名/郵便番号/住所/電話番号
これらは、注文時に紐づけられた配送先情報を管理するカラムです。
ここは「配送先」テーブルと紐づけることはできません。
理由は、会員が「配送先」テーブルの情報を編集した時に、「注文」テーブルの情報も書き換えられてしまうからです。
請求金額
これは「注文商品」から算出することができますが、残しておきましょう。「請求金額合計」、「送料」、「注文商品」の「購入時価格」の計算が合うかどうか確認するためです。
注文商品
注文の中には複数の商品が入っています。このような場合、「注文」と「注文商品」にテーブルを分けた方が賢明です。
購入時価格(税込)
購入前後で商品の価格が変更する可能性があるため、購入時価格を保持しておきましょう。また、この価格は税込価格にしておきべきです。税抜き価格にしてしまうと、正確な購入時価格がわからなくなってしまいます。
管理者
最後に管理者についてです。
今回作成するECサイトは小規模なものであり、管理者は1人であることが想定されています。そのため、他テーブルとのリレーションは不要です。
管理者が複数おり、「管理者Aの作成した商品データを取得する」ような動きが必要な場合は、リレーションが必要になります。
参照
Discussion