前書き
データベースの知識がざっくりしているのでデータベース設計に苦戦しています。そこで各用語をおさらいしながら実際にデータベースの論理設計をしていき理解を深めるとともに、私のような初学者の方のお役に立つように記事に残したいと思います。
目次
①データベースの作成手順.
データベースの作成手順.
①画面設計.
②テーブル設計.
③カラム設計.
④テーブルの正規化.
⑤ER図の作成（テーブルとテーブルの関係性を可視化して関係性を分かりやすくする。正規化を行うとテーブルが増えて関係性が分かりにくくなるので).
⑥データベースの作成（①〜⑥で作成したデータベースの設計図を元に作成する).
画面設計とは
⇨どんな画面にするのかを決める＝viewの作成＝ユーザーさんが実際に見る画面のこと
↑何かしらの商品の注文を受ける注文書の画面を作成しようと思います.
なぜユーザーさんが見ている画面から作成するのか?
⇨それはその画面を操作するのはユーザーさんだからです。なのでユーザーさんにとって最も使い画面を先に作ってからデータベースの作成を行う.
ユーザーさんが実際に見る画面のことをUl（user interfaceという）
テーブル設計
⇨どんなテーブルが必要なのかを決めるのがテーブル設計.
どんなテーブルを作成すればよいかの方法.
⇨①画面設計で作成した画面は「何をするためのシステムかを考える」.
注文書なのだから注文をするための情報がデータベースに登録されるんだろうなと推測できる.
注文書を作成するためには「注文」というテーブルが必要そうと推測する
②5W1Hを考えてどんなテーブルが必要かを絞る
今回の注文書では「いつ」「誰が」「何を」注文するのだろうと考え、それらに該当するのは「注文日」に,「顧客」が,「商品」を,というように当てはめ、この該当するテーブルは必要そうと推測.
5W1Hとは＝when ,where, what,who,why,how
カラム設計
⇨テーブル設計したテーブルの中にはどんなカラムが必要なのかを考える.
↑これらのテーブルの中に
注文書の中の項目（氏名、電話番号、住所など）管理するべき情報をどのテーブルのカラムとして持たせるのかを考える.
管理するべき情報を各テーブルに配置するとこんな感じ↓.
注意:注文書の中の項目を各テーブルのカラムに追加するのはもちろんだが、ユーザーが見ている画面には表示しないけど管理すべき項目があったりする場合がある。そういった項目もどのテーブルの中のカラムに割り振るか考える必要がある。今回はそういった項目はない.
ここから作成したテーブルとカラムを再度見渡し今回必要なさそうなカラムやテーブルを見直す.
↓
注文日年月日というカラムは注文テーブルに移してもいいと判断し、注文日というテーブルは必要なさそうなので消す.
テーブルの正規化
→正規化とは１つのテーブルの中のデータの重複や無駄をなくすこと.
正規化の目的.
⇨①テーブルの独立性を高める.
②データ容量の削減をし、データ処理の効率も良くしユーザーが快適にサービスを利用するため.
正規系とは.
⇨正規化された後の状態のこと＝無駄や重複を取り除いた後の状態のこと
正規化の種類.
第一正規系〜第五正規系まである。この記事では第三正規系までを紹介するものとする.
正規化前（無駄を省く前の状態）.
⇨何がいけないのか？それは１つのフィールドに複数の値が入っている。上の例でいくと商品カラムの中の１つのフィールドにtシャツ、靴下、スニーカーが入っている。それの何がいけないのか？⇨データベースから情報を正確に取得できない。例えば田中太郎さんが注文したtシャツの情報を取得しようとした時にpcはtシャツ、靴下、スニーカーのうちどの商品を取得したらいいのかわからない。そこで解決策が↓
第一正規系.
⇨１つのフィールドに１つの値しか含まない状態にする.
第二正規系.
⇨第一正規系から部分関数従属を取り除いた状態.
部分関数従属とは？
⇨複数の主キーがある場合に主キーの一部（２つの主キーの内１つの主キー）によって決まる値のこと＝Aの値が決まるとBの値も決まることを部分関数従属.
具体的に例を挙げて見ていこう.
前提として先ほどのテーブル（第一正規系のとこで使用したテーブル）にもう１つ商品IDという主キーを追加し今注文ID と商品IDの２つの主キーがあります.
それぞれ注文ID と商品ID に従属している列があるか１つずつ見ていこう＝ それぞれ注文ID と商品ID＝A 、従属している列＝B
⇨Aが決まるとBが決まる列があるか探す.
まず注文IDの場合『注文日』『注文者』は注文ID に従属しているとわかる＝A(注文ID)が決まるとB（注文日、注文者）が決まる状態です.
なぜならばテーブルを見てわかる通り１行目の注文IDが001の時、注文日は2019/11/26日になり
２行目の注文ID も001の時、注文日は2019/11/26日になっています.
つまりA(001)の時、必ずB(2019/11/26日)になるということは,Aの値が決まるとBの値も決まる関係になっているので注文日は注文IDに従属しているとわかる。
同様に注文者も注文ID に従属しているとわかる、注文IDが001の時必ず田中太郎さんになるので、A =Bの関係が成り立つ.
商品IDと商品名も同様の見分け方で部分関数従属があるとわかる.
部分従属かどうかの見分け方.
A＝Bの関係になっている.
そもそもなぜ第二正規系にしないといけないのか＝なぜ部分関数従属を取り除かないといけないのか.
⇨それはデータベースに変更を加えられた際「簡単にデータの更新ができるようにするため」『データの整合性を保つため』.
どういうことかというと.
例えば.
このテーブルの商品ID A-002の商品名靴下→バッグに変更したい時を考えた場合.
２行目の商品ID A-002の靴下と５行目の商品ID A-002の靴下両方の靴下のフィールドをバッグに変更する必要がある。靴下をバッグに2回書き直すぐらいならいいですけどこれが１００個、２００個の靴下があった場合、靴下⇨バッグに変更する作業は大変です.
そこでデータベースに変更を加えたい場合１ヶ所変更すれば全部の箇所変更できたら便利そうです＝簡単にデータの更新ができたら良い.
また靴下⇨バッグに変更する際入力ミスを起こした際、例えば２行目の靴下→バッグ、５行目の靴下→バックなどにしてしまうと,
データベースが「あれ？A-002の商品名はバッグ、バックどっち？」といったようにどちらが正しい情報か判断できなくなる＝データの整合性が保てていない.
この２つの理由から正規化する必要がある.
第二正規系にするためにすること.
⇨部分関数従属する属性を別テーブルとして切り出してやればいい.
今回の場合
商品ID と商品名と単価を別テーブルに取り出す。
と部分関数従属が解消され商品名が変わっても１ヶ所修正すれば全ての行に変更が加えられるので管理が楽になる. またデータの整合性も保たれる.
第三正規系.
⇨推移的関数従属を取り除いた時の状態.
推移的関数従属とは.
⇨Aが決まるとBが決まり、Bが決まるとCが決まること.
例
上のテーブルでは{ 会社ID, 社員ID } → { 部署ID } → { 部署名 }の順番で値が決まる.
{ 会社ID, 社員ID } = A
{ 部署ID } = B
{ 部署名 } = C
このテーブルの何がいけないのでしょうか？
⇨それは一時的に誰も存在していないけど部署としては存在しているという状態をテーブルに反映できていない状態.
例えば 実は事務と言う部署があるが誰も経理に存在していないみたいなものを表現できていない.
解決策は推移的関数従属が起きている部分を別のテーブルに切り出す.
元のテーブルに外部キーを残しテーブルを分割することで事務という部署があるが誰も今はその部署に存在していないということが表現できるようになる
少し長くなってきたので実際に注文書を例に次回正規化を行いたいと思います
1回目アクセス時にユーザーの情報をwebサーバーの中に保存するとともにcookieを作成しcookieの中にもユーザーの情報などを保存しユーザーにcookieを渡す.
