TechCommitの週末勉強会「データベース設計をやってみよう」に参加しました。
今日やる部分
論理設計
・必要なデータを洗い出す(エンティティの抽出)=概念(スキーマ)設計
・RDBで扱える形にする(正規化&ER図作成)
論理設計の順番
・エンティティを定義
→データに必要な登場人物たち
→顧客、商品とか
・エンティティに対する詳細を定義
→登場人物たちが持っている個性
→顧客なら、名前・性別・年齢とか
・正規化&ER図作成
上記の内容を元に実践編の課題が出たのでざっくりとやってみました。
実践編
「プレゼント選びの参考になるようなサービスを作る」
★構想★
・過去にプレゼントした事のあるものは選んでほしくない
・予算は決めたい
・妻や娘にふさわしいものを提案してほし
・他の人がどんな人に何をプレゼントしたのかも参考にしたい
・コンシェルジュを選びたいので、コンシェルジュプロフィールや口コミがあるといい
・コンシェルジュに頼む場合
→一方的に提案してもらうプラン
→Zoomで会話しながら提案してもらうプラン
補足
コンシェルジュさんにプレゼント選びに参考にしたいのは、
〇性別
〇年齢
〇過去にプレゼントしたもの
〇他
上記の内容から、必要と思われるテーブルを洗い出してみた
登場する人と物
・プレゼントを買いたいユーザー
・プレゼントを受け取る人
・提案するコンシェルジュ
・プレゼント
・過去にプレゼントした事のあるものは選んでほしくない
→プレゼントを受け取った人をユーザーと商品で紐づけて管理できるようにしたい
・予算は決めたい
→プレゼントしたい商品に金額を持たせてあげる
・妻や娘にふさわしいものを提案してほし
→レコメンド機能…年齢や性別を定義してそれに該当するようにしてあげればよさそう
・他の人がどんな人に何をプレゼントしたのかも参考にしたい
→上の内容で作ったテーブルで管理できそう
・コンシェルジュを選びたいので、コンシェルジュプロフィールや口コミがあるといい
→コンシェルジュテーブルで管理してあげればよさそう
・コンシェルジュに頼む場合
→提供プランは後から変更する場合やコンシェルジュ個別に設定できるようにしたいので提供プランテーブルを作りたい
上記の内容から下記のテーブルを定義してみた
【ユーザーテーブル】
| 列名 | PK | FK | |
|---|---|---|---|
| 会員番号 | customer_id | 〇 | |
| 名前 | name | ||
| 年齢 | age | ||
| 性別 | sex | ||
| メールアドレス | |||
| パスワード | password | ||
| お気に入りコンシェルジュ | concierge_id | 〇 |
【コンシェルジュテーブル】
| 列名 | PK | FK | |
|---|---|---|---|
| コンシェルジュID | concierge_id | 〇 | |
| 名前 | name | ||
| 年齢 | age | ||
| 性別 | sex | ||
| メールアドレス | |||
| 会員番号 | customer_id | 〇 | |
| 口コミ | review | ||
| 提供プラン | plan | 〇 |
【提供プランテーブル】
| 列名 | PK | FK | |
|---|---|---|---|
| コンシェルジュID | concierge_id | 〇 | |
| 提供プラン | plan |
【プレゼントしたい相手テーブル】
| 列名 | PK | FK | |
|---|---|---|---|
| プレゼントしたい相手ID | present_id | 〇 | |
| 名前 | name | ||
| 年齢 | age | ||
| 性別 | sex | ||
| 会員番号 | customer_id | 〇 | |
| 受け取った商品 | goods | 〇 | |
| 受け取った日付 | day |
【プレゼントした商品テーブル】
| 列名 | PK | FK | |
|---|---|---|---|
| プレゼントしたい相手ID | present_id | 〇 | |
| 受け取った商品 | goods | 〇 | |
| 受け取った日付 | day |
【商品テーブル】
| 列名 | PK | FK | |
|---|---|---|---|
| 商品ID | goods | 〇 | |
| 商品名 | goods_name | ||
| 値段 | price |