こんにちは！Seiyaです
ここでは要件定義とER図の説明を実際の例を用いて作成していきます。
要件定義
要件定義は実際どのような機能をつけるかなどを決める最重要フェーズです。ここ決めないと何も決まらないのでしっかり考えていきましょう。今回は以下のような形で実装していきます。
Beauty_Healthの概要
美容・健康商品を対象としてECサイト+利用者自身も情報発信できるSNS
販売設定について
- 送料は商品価格と別とする。
- 注文はいくらでも受け付ける。制限はなし。
- 税率は10%。
- 配送先は自分以外のところに送ってもOKとする。
- 支払方法は銀行振込orクレジットカードの2種類とする。
注文状況
注文状況をステータスとして置くことで状況を把握できるようにする。
| ステータス | 説明 |
| 着金待ち | 注文時のデフォルト |
| 着金確認 | 確認したタイミングで更新 |
| 発送準備 | すべての商品の準備が完了したら更新 |
| 発送済み | 発送したら更新 |
商品状況
商品を発送する準備をステータスとして置くことで状況を把握できるようにする。
| ステータス | 説明 |
| 確認待ち | 注文時のデフォルト |
| 準備中 | 注目状況のステータスが着金確認時に更新 |
| 準備完了 | 準備が完了した段階で更新 |
実装機能
共通
ヘッダーをログイン前、会員ログイン後、管理者ログイン後でそれぞれ表示を変更させる。
ヘッダーに検索フィールドを作る。
会員側
- 会員は登録、ログイン・ログアウトできるようにする。また退会機能も実装する。
- ログインはメールアドレスとパスワードのみで行う。
- 名前などをログイン後にヘッダーに表示させる。
- トップページと商品の一覧はログインなしでも見れるようにする。
- カート内で個数変更を行える。
- カートへ商品追加するにはログインする必要がある。
管理者側
- 事前にメールアドレスとパスワードを登録しておく。
- 商品の追加と編集、全商品の閲覧ができる。
- 商品の販売中か中止を切り替えられる。
- 会員登録しているユーザーの情報を変更できる。
- 注文状況と商品状況のステータスを変更できる。
SNS
- 投稿機能(タイトルと本文)
- いいね
- コメント
ER図
今回のBeauty_Healthを構築するにあたり、必ずデータベースが必要になります。そこでまずはER図を作成して全体像を捉えていきましょう。
会員
会員情報で必要になるのは「会員id」「姓」「名」「姓(カナ)」「名(カナ)」「紹介文」「生年月日」「郵便番号」「住所」「電話番号」「メールアドレス」「パスワード」「退会ステータス」「作成日時」「更新日時」になります。
管理者
管理者情報で必要になるのは「管理者id」「メールアドレス」「パスワード」「作成日時」「更新日時」になります。管理者はメールアドレスとパスワードのみでログインするのでこれらの情報のみ問題ないです。
カートアイテム
カートアイテム情報で必要になるのは「カートアイテムid」「会員id」「商品id」「個数」「作成日時」「更新日時」になります。会員idと商品idは外部キーとして会員テーブル、商品テーブルからデータを参照できるようにするために使います。
注文
注文情報で必要になるのは「注文id」「会員id」「配送先(郵便番号)」「配送先(住所)」「配送先(宛名)」「送料」「合計金額(送料込み)」「支払方法」「注文ステータス」「作成日時」「更新日時」になります。
注文詳細
注文詳細情報で必要になるのは「注文詳細id」「注文id」「商品id」「注文価格(税込)」「個数」「商品状況ステータス」「作成日時」「更新日時」になります。
配送先
配送先情報で必要になるのは「会員id」「郵便番号」「住所」「宛名」「作成日時」「更新日時」になります。
商品
商品情報で必要になるのは「商品id」「ジャンルid」「商品名」「商品説明」「価格(税抜)」「商品ステータス」「作成日時」「更新日時」になります。
ジャンル
ジャンル情報で必要になるのは「ジャンルid」「ジャンル名」「作成日時」「更新日時」になります。
投稿
投稿情報で必要になるのは「投稿id」「会員id」「タイトル」「本文」「作成日時」「更新日時」になります。
いいね
いいね情報で必要になるのは「いいねid」「会員id」「投稿id」「作成日時」「更新日時」になります。
コメント
コメント情報で必要になるのは「コメントid」「会員id」「投稿id」「コメント」「作成日時」「更新日時」になります。
ER図
上記の内容を図にすると以下になります。
リレーションシップ(Relationship)
エンティティ同士の関係性を示すもの。例えば, ユーザーと投稿はそれぞれ関係を持っています。もしなかったら誰が投稿したかわかりませんよね。
カーディナリティ(多重度)
リレーションシップの詳細を示すものです。例えば,ユーザーと投稿は1:Nの関係ですね。ユーザー一人でいくつかの投稿を持っています。
ER図を作成する上でのポイント
- 作成前に要件は絶対に見ましょう。
- 重複カラムがないか確認しましょう。他のエンティティから引っ張れるかもしれません。
テーブル定義書と詳細設計
お疲れ様です。ここではテーブル定義書と詳細設計の方を作成していきます！
テーブル定義書とはER図の内容を詳細に書かれたものです。詳細設計はルーティング周りについて書かれたものになります。
テーブル定義書
Customers
| カラム名 | 説明 | PK | FK | データ型 | NotNull | AUTOINCREMENT | INDEX | DEFAULT | 備考 |
| id | 会員id | ○ | integer | ○ | ○ | ○ | |||
| last_name | 姓 | string | ○ | ||||||
| first_name | 名 | string | ○ | ||||||
| kana_last_name | 姓(カナ) | string | ○ | ||||||
| kana_first_name | 名(カナ) | string | ○ | ||||||
| birthday | 生年月日 | date | ○ | ||||||
| post_code | 郵便番号 | string | ○ | ||||||
| address | 住所 | string | ○ | ||||||
| telephone_number | 電話番号 | string | |||||||
| メールアドレス | string | ○ | |||||||
| encrypted_password | パスワード | string | ○ | ||||||
| is_deleted | 退会ステータス | boolean | ○ | False | Trueの時退会済み | ||||
| created_at | 作成日時 | datetime | ○ | now | |||||
| update_at | 更新日時 | datetime | ○ | now |
addresses
| カラム名 | 説明 | PK | FK | データ型 | NotNull | AUTOINCREMENT | INDEX | DEFAULT | 備考 |
| id | id | ○ | integer | ○ | ○ | ○ | |||
| last_name | 姓 | string | ○ | ||||||
| first_name | 名 | string | ○ | ||||||
| kana_last_name | 姓(カナ) | string | ○ | ||||||
| kana_first_name | 名(カナ) | string | ○ | ||||||
| birthday | 生年月日 | date | ○ | ||||||
| post_code | 郵便番号 | string | ○ | ||||||
| address | 住所 | string | ○ | ||||||
| telephone_number | 電話番号 | string | |||||||
| メールアドレス | string | ○ | |||||||
| encrypted_password | パスワード | string | ○ | ||||||
| is_deleted | 退会ステータス | boolean | ○ | False | Trueの時退会済み | ||||
| created_at | 作成日時 | datetime | ○ | now | |||||
| update_at | 更新日時 | datetime | ○ | now |
