「正規化って何のために行うの？」
と疑問をいだいている方も多いと思います。
熟練の開発者がデータベースを作成すると、データ構造はほとんど同じ形になります。
それはルールに基づいて設計しているからです。
そのルールが正規化です。
正規化を勉強することで
というメリットがあります。
正規化は一度覚えれば長年開発で役に立ちます。
コスパ最強の知識の一つなのでぜひ勉強してください。
この内容はスキップして大丈夫です。
読み進めた時にわからない単語がありましたら参考にしてください。
本文ではわかりやすく書いていますのでわからなくても大丈夫です。
| 第一正規形 | ・繰り返しの項目を持たない。 |
| 第二正規形 | ・第一正規形の条件を満たす ・すべての非キー属性が候補キーに完全関数従属する。 |
| 第三正規形 | ・第二正規形の条件を満たす。 ・すべての非キー属性が候補キーに推移的関数従属しない。 |
| ボイスコッド正規形 |
| 候補キー | 特定の１行を確定できる１つもしくは複数の項目の組合せ。 候補キーの値に、Null(空)のデータは不可。 |
| 主キー | 候補キーの一つを主キーと呼ぶ。 |
| 関係関数従属 | Aが決まると、Bが一つに決まる事。 A -> B と書く |
| 部分関数従属 | 候補キーの一つに関係関数従属している事。 |
| 完全関数従属 | すべての非キー項目が候補キーに部分関数従属していないこと。 |
| 推移的関数従属 | A -> B -> C の時、CはAに推移的関数従属している。 |
次の注文書をサンプルにして説明します。
XYZ会社にノートと鉛筆を発注したときの注文書です。
第一正規形は表に繰り返しの項目をもたない形です。
「行」と「列」の繰り返しがなくなるように変換します。
次の手順で第一正規化を行います。
項目名とデータをすべて書き出します。
Excelでは次のようなデータを書く人が多いと思います。
列に注目して、繰り返しがなくなるようにします。
もし下のように項目を書き出した人の場合、
黄色の項目が繰り返してます。
上の図のように、商品データを縦に持つように変換してください。
RDB(関係データベース)は項目の追加と削除は不得意です。
表の項目を一度決めたら列の追加はめったに行いません。
商品を一度に100個買う人が出た場合、100 x 3の300項目追加しないといけなくなります。
このような事が起きないように列の繰り返しをなくします。
次に「行」の繰り返しをなくす作業にとりかかります。
データベースでは、Excelのセルの結合のようにデータを持つことができません。
空白の項目のデータを埋めてデータベースの持ち方に変換します。
赤色が追加で記入したデータです
RDBはデータは同じ行のデータしか見れません。
上下の行のデータを参照できないのです。
そのため同じ行だけを見た時に意味が通じるようにします。
行のデータを見ると黄色の項目の「注文番号、業者名、住所」が繰り返しているのがわかります。
黄色項目と緑の項目をわけて、「注文書ヘッダ」と「注文書明細」の表を作ります。
表を2つにわけると2つの表のデータの関係性がわからなくなります。
「注文書明細」表に「注文書ヘッダ」表の主キー「注文番号」を追加します。
こうすることで、ノートをどこの業者から買ったか知りたい時に「注文番号」から調べられます。
これで第一正規化が終了です。
主キーを元に表を分割します。
主キーというのは重複のないデータの項目の事をいいます。
例えば都道府県の名前は主キーです。
同じ名前の県はないからです。
人の名前は主キーにはなりません。
同姓同名の人がいる可能性があるからです。
このような主キーの項目を探して、別の表に分割する作業が第二正規化と第三正規化です。
第二正規化：主キーの項目内に分割できる項目がない状態
第三正規化：主キー以外の項目にも分割できる項目がない状態
重複しない値の主キーを探します。
「注文書ヘッダ」表で、業者名は主キーなるでしょうか？
同じ業者に何回も発注したら、業者名は複数でてきます。
一行に特定できないので業者名は主キーとは違います。
このように考えると主キーは
・注文書ヘッダ表：「注文番号」
・注文書明細表 ：「注文番号」「商品名」
となります。上の図の青色の項目です。
「注文書明細表」は「注文番号」「商品名」の2つセットで主キーとなります。
このことを複合キーといいます。
関係関数従属とはAが決まるとBの値が決まることをいいます。
チェックするのは複合キーのテーブルだけで大丈夫です。
その理由は主キーが1つの項目というのは、すでに分割済みのためです。
「注文書ヘッダ」表は注文番号が決まると業者名が特定できるということからです。
「注文書明細」表の主キー「注文番号」と「商品名」に着目します。
この２つの項目の全部の組合せを書き出します。
| 項目の組合せ | 検討対象 | 説明 |
|---|---|---|
| 注文番号、商品名 | 対象外 | すでに「注文書明細表」表としては分割済みのため対象外 |
| 注文番号 | 対象外 | 「注文書ヘッダ」表としてすでに分割済みのため対象外 |
| 商品名 | 検討対象 | 商品名が決まると確定する項目がないか確認が必要 |
このように整理したことで、商品名を確認すればいいことがわかります。
次に候補キーの「商品名」と他の項目の一覧を書き出します。
商品名のノートを考えたときに、
・数量が１つに決まるか？
・単価が1つに決まるか？
と一つずつ考えていきます。
整理した結果「単価」が「商品名」に関係関数従属することがわかります。
| 候補キー | 関係する項目 | 結果 | 確認結果 |
|---|---|---|---|
| 商品名 | 数量 | 関係なし | 注文数量は1個だったりも5個だったりも考えられる。 商品名が決まったからといって数量が同じ値になるとは言えない。 |
| 商品名 | 単価 | 関係関数従属 | 商品名が決まると単価が決まる。 |
商品名と単価を別の表に分けると下記のようになります。
これで第二正規化が終了です。
主キー以外の項目の組合せを書き出し、一つずつ検討していきます。
主キー以外の項目が2つ以上あるのは「注文書ヘッダ」表のみなので、
「注文書ヘッダ」表に注目します。
| 候補キー | 項目 | 結果 | 確認結果 |
|---|---|---|---|
| 業者名 | 住所 | 関係関数従属 | 業者名が決まると住所が１つに決まる |
| 住所 | 業者名 | 関係なし | 東京都にたくさんの業者がいるので違う |
「業者名」と「住所」の関係性が確認できたので、別表に切り出します。
これで第三正規化が終了です。
「業者名」から見た「住所」だけでなく、逆から見て「住所」から「業者名」も確認してください
正規化の手順は以上です。
第一正規化では「行」と「列」の繰り返しをなくします。
第二正規化と第三正規化では、Aが決まるとBが1つに決まる項目を別の表にします。
項目の組合せを全部書き出すのはたいへんですが、
慣れないうちは１つずつ手順にそって作業するといいでしょう。
回数をこなすことで、徐々に手順を省略してもデータベースの設計をできるようになります。
次の章では現場でのテーブル設計方法を解説します。
正規化は基本の知識で大切です。でも少し難しいと思いませんでしたか？
実際にはもっと手を抜いて設計します。
そして手を抜いた方がいいシステムになります。
その点を説明していきます。