こんにちは！ぱかぱかです！
今日は前回の記事で要件を詰めていた飲食店を記録するアプリ「グルメノート」のデータ設計を行いたいと思います。
radish-se.hatenablog.com
radish-se.hatenablog.com
前回のまとめ
・アプリの目的、システム方式・構成、画面と機能、操作フローを決めた！
・カラーパレットを使って多少マシなデザインを作った！
データ設計とは
前回の記事でも述べた通り要件定義すらまともにやったことがない私、データ設計なんてなおさらよくわかっていません…
OSS-DB Silverを取得するなどDBについて勉強する機会はあったのですが、設計となるとまた話は別ですよね。
以下の動画と記事を見ながら、なんちゃってデータ設計を進めていきたいと思います！
記事によるとデータベース設計における手順は以下の通り。
手順1. 要件定義を行う【概念設計】
手順2. エンティティを抽出する【概念設計】
手順3. ER図を作成する【概念設計】
手順4. ER図をRDBのテーブルに変換する【論理設計】
手順5. 正規化を行う【論理設計】
手順6. 性能要件を確認する【物理設計】
手順7. インデックスを作成する【物理設計】
手順8. データ格納領域を決める【物理設計】
今回の目標は手順3. ER図を作成する【概念設計】までとします！
手順1. 要件定義を行う【概念設計】
作成しようとしているデータベースで「どのようなデータをどう管理したいのか」を明確にすることからスタートこれにはデータベースを使用する対象の業務を詳細に分析し、必要な要件を洗い出すことが不可欠でしょう。
なるほど…というわけで、どのようなデータをどう管理したいのか考えます。
ここでまず、現状の画面構成を眺めてみます。
ふむ…まず画面から読み取れる必要そうな情報とその例を列挙してみましょう。
・店名：天下一品
・場所：東京
・ジャンル：ラーメン
・登録日：2023年10月15日
・メモ：佐藤さんおすすめ
・写真：ラーメンの画像
・評価：★★★☆☆
・訪問日：2023年10月15日
・シーン：女子会
・感想：初めてきた。めっちゃ濃い。
行った店リスト、行きたい店リスト、お気に入り店リストと3つのリストがあるけど、結局表示する情報が異なるだけで似たような情報を共有してそう。
あとは今後サーバで情報を管理することを考えると、ユーザ情報も別で持っておく必要がありそう。
手順2. エンティティを抽出する【概念設計】
エンティティといえば「ある目的のためにまとめられたデータのかたまり」で、もっと分かりやすく言えば「データベースにおけるテーブル」というイメージをもっていただけると分かりやすいでしょう。
今回の場合エンティティとしては何を定義すれば良いでしょうか…
なんのテーブルを作ればよさそうかなという観点で列挙してみます。
・飲食店
・場所
・ジャンル
・訪問記録（訪問日ごとに評価や感想を持つ）
・シーン
・ユーザ
中間テーブル
・行った店
・行きたい店
・お気に入り店
とりあえずこんなもんかな…？
