設計について考える

2021年9月5日 03:22

大枠としては基本設計とDB設計がある

基本設計

要件定義の内容を開発に必要な内容にまとめる

「画面」や「画面遷移の流れ」をまとめていく

そこから実際に書くべきコードを洗い出す詳細設計を行う

要件定義や基本設計の情報をもとに、ユーザーが行う操作に対して行われる処理を全て書き出します。その上で実際どのようなコードを書くか当てはめていく。

Ruby on Railsであれば「ルーティングはどういったものがあるか、対応するコントローラーとそのアクションはどういったものになるか、モデルは ~」といった内容を表にまとめると良いでしょう。

また、画面遷移図という各ページの移動の相関図を作っておくと、チームでの開発での共有や自分のチートシートとしても利用できる

↓画面遷移図の例

DB設計とは開発で使用するDBの表を設計することです。具体的には「テーブル」や「カラム」、「アソシエーション」などです。

サービスで扱われるデータ自体をエンティティと言いますが、そのエンティティを洗い出し、それらのテーブル設計とリレーションを考える必要があります。エンティティを考えるポイントとしてはデータが登録されるときに注目すると、わかりやすいです。

エンティティの分類や関連付けを行い、模型のように表します。

モデリングされたDBへさらに詳細な設計をしていきます。まずはテーブルの情報を利用しやすい形に変える「正規化」をおこないましょう

データベースの構造を効率的でシンプルな形にします。

設計の際には入力されるデータに制約をかけることによって、悪質なユーザーの入力や意図しない入力によるエラーを未然に防いでくれます。

t.型 :カラム名, null: false

このようにテーブルのカラム名の後に書くことによって、null（空欄）の状態で保存されるのを防ぐ機能があります。

テーブル内で重複するデータを禁止する制約です。emailカラムに行えば、同じemailが登録できなくなります。

例としては主に各テーブルのidカラムの項目が主キーに該当します。主キー制約は１、主キーのデータが空になることはない２、重複していないことを保証する。なのでNOT NULLと一意性制約の両方がデフォルトでついています。

また、Railsでテーブルを作成する際、主キー制約はidカラムとして自動で設定されます。

外部キーとは、関連する他のテーブルのレコードの主キーを値とする項目のことです。
そして、外部キー制約とは、外部キーのデータに対応するレコードが必ず存在することを保証する制約です。

t.references :カラム名,  foreign_key: true

このように設定ができます。ちなみにカラム名にuserと打ち込むとテーブルのカラムにはuser_idと入力されます。

チェック制約は、値が保存される際に条件を満たしているかチェックできる制約です。
たとえば、userのニックネームが6文字以下になるような条件を加えれば、それ以上のニックネームが保存されることはありません。

DBのテーブルなどを図で表記したものです。

特徴は、表で記述するよりも関連付けがイメージしやすいことです。

この記事が気に入ったらサポートをしてみませんか？