こんにちは、いちのです!
前回の画面仕様に続いて、今回はこれから作るアプリケーションで使うDBの構造を考えていきます。
ここから大分システム作ってる感出てきますね!
DB設計の手順
まずはDBのつくりを考えていくための全体の流れをざっくりと。
- エンティティをあらいだす
- エンティティの中身を考える
- ER図を作る
これを書くためにいくつかDB設計の方法を検索してみましたが、めんどくs私では細かいところをうまく説明できないので、私が個人的にやるときはこうするかなーというのを書いてみることにしました。
詳しい解説を見てきちんとやりたい方は、丁寧に説明して下さってるサイトがたくさんあるので検索してみてください。(おすすめサイトがあれば教えてくれると大喜びします。)
1.エンティティをあらいだす
エンティティとか横文字使ってかっこつけてますが、まあ、データベースに何を保存したいかをまずは大きなくくりで考えるイメージです。要するに必要なテーブルを考えるってことです。
今回例として私が作ろうとしているタスクアプリで考えてみましょう。
ユーザー情報
ログイン機能を作るからには必須になるものです。
セッションとかのことはまずはあまり考えないことにします。ただユーザー情報があって、メアドとパスワードを入力すればログインできるイメージです。
タスク情報
アプリの主な機能のため、タスクを保存しておくところも必要ですね。
タスクの名前やスケジューリング間隔あたりを保存することになりそうです。
タスクいつやったか情報
そのタスクを前回やってからの日数を表示したいということは、いつタスクを実行したかを保存しておく必要があります。ただのタスクアプリなら必要ないかもしれませんが、私が今回わざわざ自分で作ってる理由、「どうしてもほしい機能」なので作ります。
- ユーザーテーブル
- タスクテーブル
- やった日テーブル
まずはこの3つのテーブルが必要そうです。足りないものに気づいたら後でこっそり追記します。
2.エンティティの中身を考える
DB設計の解説サイト様を見ていると、よく「エンティティの定義」なんて書いてあるやつだと思います。さっき考えた各テーブルに、具体的に何を保存するかを考えていく作業です。
まずは私が会社に勤めていた頃に覚えた、DBを設計するうえで大事なこと。
- 一意(他のデータと被ることがない)のID
- そのデータが登録された日時、更新された日時
これが全テーブルにあると扱いやすく、問題が起きた時の原因を探るのにも役立ったりします。
そんなことを踏まえつつ作っていきます!
ユーザーテーブル
ID | long | 主キー |
メールアドレス | varchar(200) | ログインに使うため必須 |
名前 | varchar(50) | 主に表示用 |
パスワード | varchar(10) | ログインにつかう |
登録日時 | datetime | 最初に登録された日時 |
更新日時 | datetime | 最後に更新された日時 |
タスクテーブル
ID | long | 主キー |
ユーザーID | long | ユーザーテーブルと紐づけて、誰のデータかわかるようにする |
タスク名 | varchar(30) | タスクの名前30文字まで |
タスク頻度区分 | int | 0:○日おき 1:毎週○曜日 2:毎月○日 3:1回だけ というかんじで登録しておいて、アプリケーション側で表示や処理を振り分ける |
タスク頻度値 | int | 5日おきなら5、毎週日曜日なら0、月曜なら1、毎月12日なら12 というかんじで数値を登録する 1回だけで繰り返さないならnull |
警告を出す超過日数 | int | 日数を数字で |
登録日時 | datetime | 最初に登録された日時 |
更新日時 | datetime | 最後に更新された日時 |
やった日テーブル
ID | long | 主キー |
タスクID | long | タスクテーブルと紐づけて、どのタスクのデータかわかるようにする |
やった日 | datetime | やった日を、一応時刻も登録 |
登録日時 | datetime | 最初に登録された日時 |
更新日時 | datetime | 最後に更新された日時 |
あんまり細かい説明もなしに考えたものを書き連ねてみました。
私は開発してる途中で不足に気づく未熟者ですが、慣れてくると実際に作る時の処理の流れをイメージしながら何が必要かを考えられると思います。
ER図を作る
DB設計の解説サイト様をみていると、ER図を作る前に正規化という作業をしているようですが、多分私が面倒くさがりなので正規化までした状態のものを「エンティティの定義」の中で作ってしまっていると思います。多分、本当は順を踏んでエンティティを定義してから正規化をした方が丁寧でミスの少ないものができるのかと思います。
で、ER図です。テーブルとテーブルがどういう関係で繋がっているか等を図で表すものです。
今回は主キーと外部キーがわかる程度のものにします。めんどくさいから・・・。

こんなかんじで。ER図の書き方や記号の意味等はこれまた詳しいサイト様たくさんありますので、探してみてください。私のは何か間違ってる可能性も十分あるのであまり過信せず、参考程度に見て頂けたら幸いです・・・!
ちなみにこのER図はこちらの記事を参考に

こちらのツールで作ったものです。
始めて使いましたが、すごい!使いやすい!ブラウザで作れるなんて・・・!
最近は便利なものがたくさんありますね。
まとめ
詳しい説明もなしにさらっと書いてある部分が多々ありますが、ざっと手順をおってみました。
ここでそれぞれを詳しく掘り下げて説明する予定はないので、詳しくは検索して探してみてくださいね。
DB設計がしっかりしていればしているほど、開発を始めた時に頭がとても楽になります。
今回はこの程度のものしか作らないし・・・と私は油断して割と適当に作っているので、開発段階で困ることになるかもしれません・・・笑
不足があったら適宜修正します。
もし気になることがあれば、問合せフォームからご指摘いただけると助かります。