日程調整アプリのデータベース設計〜ワイヤーフレーム編

前回は日程調整アプリを作るために要件整理をしました。
okerra.hatenablog.com

今回は具体的にどのような画面にするかを考えていき、そこからデータベースのエンティティや属性を抽出してリレーションシップのモデルを完成させることをゴールとします。そのためまずはワイヤーフレームを作ります。

ボトムアップ分析

　ボトムアップ分析は既にシステムがある場合や、どのような表示をするかの画面情報を基にデータベース設計をしていく手法です。メリットは画面情報から情報を抽出するだけなので漏れなく抽出しやすいことのようです。
　その反面ボトムアップ分析だけでは既存のシステムにはあるが、今回の案件で新しく追加された要件などは確実に漏れてしまうので必ずトップダウン分析と両方の実施が必要とのことでした。

ワイヤーフレームの作成

使用するTool

画面設計とデータベース設計はDraw.ioというフローチャートやオフィスのレイアウトなど図を作成できるツールを使用します。
Flowchart Maker & Online Diagram Software

画面イメージ

実際に作った画面がこれです。これをベースにモデルを作っていきます。

エンティティの抽出

画面からまずエンティティになりそうな情報を抽出しました。

リソース系エンティティ

• イベント
• 参加者

イベント系エンティティ

• 開催する
• 回答する

属性の抽出

リソース系エンティティの属性を抽出する際の観点は、

エンティティを具体的に説明する情報を洗い出す

イベント系エンティティの属性を抽出する際の観点

だれが、いつ、何を、どのくらい、いくらという観点で情報を洗い出す

回答エンティティ(Answer)

• ある開催の（PK,FK)
• ある候補日に（PK,FK)
• ある参加者が（PK,FK)
• 出欠情報を

識別キーもこの３つがないと出欠情報を一意に特定できないので、おそらくこれは合っている気がします。

開催エンティティ(Hold)

• あるイベントを(PK,FK)
• ある日に

うーん。開催エンティティは何かコレジャナイ感、、、そんな匂いがします。
開催エンティティが不要な気がするし、少なくともイベントエンティティと統合した方が良さそう。
あと開催候補日のエンティティがいることにも気づいたため以下のように変更しました。

これを日本語にして読んでみます。

【参加者】が複数【回答する】、複数の【開催候補日】を持った【イベント】に

さっきよりかは悪くない。ただカーディナリティがなんかまだ違う気がします。。。
ただ気がつけば8時間続けて作業しておりご飯も食べてなかったので今日はこれにて終了。