サービス設計②
概要
前回の記事で、オリジナルアプリの企画、要件定義が完了しました。今回は引き続きデータベース設計に取り掛かりたいと思います。
サービス設計の手順
まず、このアプリはどんな画面があるのか、どのように遷移するのかを考え、まとめていきます。
画面遷移図
画面遷移図とは、どの画面でどんな操作をしたらどのページに移動するかを図に表記したものです。
まずは、アプリで必要な画面を洗い出します。
・サインイン/サインアップページ
・トップページ（メンター一覧を表示）
・メンター詳細ページ
・メンター情報編集ページ
・決済ページ
洗い出した項目をもとに画面遷移図を作成すると以下のようになります。
DB設計
DB設計とは、開発で使用するDB（データベース）の表を設計することです。
具体的に考える項目は、テーブル、カラム、アソシエーションなどです。
設計手順としては、まず保存する項目の洗い出し、それを管理するにはどのようなテーブルがあれば良いかを考え、テーブル同士の関連を考えていきます。
エンティティ
エンティティとは、サービスで扱われるデータ自体のことです。
今回作成するアプリの主な機能は以下の3つです。
・ユーザー管理に関する機能
・メンターのプロフィールに関する機能
・決済に関する機能
エンティティはテーブルと等しい粒度で決める必要があるため、可能なかぎり異なるジャンルの情報は混ぜないようにしましょう。
正規化
正規化とは、データベースの構造を効率的でシンプルな形にすることです。正規化には段階があり、以下の工程を辿ります。
非正規形：何もしていない状態
第一正規形：重複するカラムを分離する
第二、第三正規形：情報が混在するエンティティを分離する
今回のアプリで正規化を行うと、テーブルは以下の3つが必要だということがわかります。
・usersテーブル（ユーザーの情報）
・profileテーブル（メンターの情報）
・ordersテーブル（決済の情報）
制約
制約とは、データを扱う際に制限をかけることです。制約はバリデーションと異なり、データベースに直接設定するので、あとで変更すると手間がかかります。
NOT NULL制約
NOT NULL制約は、テーブルの属性値にNULL（空の値）が入らないように制限する制約です。
マイグレーションファイルのオプションにnull: falseを記述して設定します。
t.型 :カラム名, null: false
一意性制約
一意性制約は、テーブル内で重複するデータを禁止する制約です。emailの保存に使うことが多いです。
主キー制約
主キー制約は、そのデータが空になることがなく、かつ重複していないことを保証する制約です。主キーに対して、NOT NULL制約と一意性制約の両方を設定するのと同義になります。Railsではテーブルを作成する時、主キー制約はidカラムに自動で設定されます。
外部キー制約
外部キー制約とは、外部キーの対応するデータが必ず存在しなくてはならないという制約です。例えば、user_idというカラムには、外部キー制約を付けるべきです。usersテーブルのidが主キーであり、そのidで判別できるレコードと関連付けを行う場合に使用します。オプションに、foreign_key: trueと記述することで設定できます。
t.型 :カラム名, foreign_key: true
ER図
ER図とは、DBのテーブルなどを図に表記したものです。
表で記述するよりも関連付けがイメージしやすくなります。
今回のアプリをER図に表すと、以下のようになります。
この図から、以下の関係性が読み取れます。
・1人のユーザーは、1つのプロフィールと多くの決済情報を持つことができる。
・1つのプロフィールは、1人のユーザーに紐付き、多くの決済情報を持つことができる。
・1つの決済情報は、1人のユーザーと1つのプロフィールに紐付く。
以上でサービス設計の大枠は完了しました。ここからやっと開発の段階に入ります。
