要件定義してデータベース設計をする

要件定義をしよう

最初に、アプリケーションを作る際に必要と考えられる機能を洗い出そう。

設計の際に、システムの設計を最初にする派閥と、データベースの設計をする派閥があるのだが、どちらにしろ実装するべき機能を洗い出しリスト化することは必要である。システム設計先行派閥の場合はクラスを考えるのに、データベース設計先行派閥の場合はデータのカラムやデータ型やデータベース同士の連携を考えるのに必要な情報になります。

要件定義は利用者目線で作る

プログラムファーストな要件定義をするのではなく、機能要件非機能要件で分けてやりましょう。

機能要件非機能要件ってなーに

機能要件は一般ユーザーや管理者ユーザーに与えられる機能です。実際にアプリケーションに実装する機能内容をいいます。 非機能要件はアプリケーションを構成する要素をどうしようかっていうやつです。つまるところ、セキュリティどうしようかーとか、レスポンスとか、動作するプラットフォームについて書きます。

データベースの設計は表をばらして作る

非正規形

DB設計の禁忌を犯している冒涜的なDBのことです。 DB設計の禁忌は単純に言えば

• 1つのセルに1つのデータしか入れてはいけない
• 主キーが作れない データベースのことを指します。

第一正規形

Excelなどの表は、いわゆる第一正規形とよばれます。関連するデータをすべて並べて表示されてる状態です。

第二正規形

第一正規形のテーブルを、関連してるデータに切り分けてデータベースをつくることです。 図書館で例えるならば、本のデータと、借りてるユーザーは本のデータは本のデータだけをまとめたテーブルを作れます。ユーザーもまたしかりです。すなわち、オブジェクトごとにテーブルを作成して管理しましょうっていう状態です。

第三正規形

第二正規形になったテーブルの中にさらに切り分けれそうなカラムがあったらそれをテーブルにして…と管理している状態です。本のデータで例えるならば、ジャンルというデータをテーブルに切り分けたり、出版社を切り分けたりすることです。 これにより、本のテーブルには、ジャンルテーブルの主キーや出版社テーブルの主キーが外部キーとして使われます、外部キーは存在しないデータをしていできないのでヒューマンエラーを防げます。複数列に何度も出てくるかもしれないデータを切り分けることで、データの変更が起きた時の修正が楽になります。

正規化したデータの利点

ヒューマンエラーの減少

外部キーで参照できないデータはエラーが出て使いようがないので、外部キー参照してるカラムは入力エラーよっぽど起きません。

データ変更範囲の縮小

検索バーから検索してデータ置換せずに済みますやったね。