DB設計の正規化 メリットとデメリット

DBを作成する際には、データの関連性や重複保存などで問題が起きて後から構成のやり直しにならないよう、事前にきちんと設計する必要がある。そこで出てくるのが「正規化」の考え。これをきちんと自分の知識にするためにまとめよう。

●なぜ正規化が必要か

　「データが壊れないようなDB設計にするため」

　DBに保存したデータがDBの構成のせいで壊れてしまうことがありうる。DBの外部化をしていなかったせいで、一つしかないカテゴリのデータを削除したために、それ以降そのカテゴリはなかったものとなってしまう。これはデータが壊れると表現できる。これを防ぐためにきちんと設計を行う。

①第一正規形

　重複する情報をなくす。

　レシート情報のように一つの会計の中に複数の取引がある時、行の中に細分化された行が必要になる。この重複した形はDBでは再現できないので、横一列に表現できるようにしないといけない。レシート番号などの重複する情報は分割したり、合計金額などの算出できる情報は無くしてしまう。

 　また、ある生徒の履修データで、class1,class2,class3.......と一人の生徒情報の行に対してClassのカラムを延々と追加していく構成のDBはよくない。Classテーブルを別に作って、意味合いの重複するカラムをなくす。

②第三正規形（第二も含む） 

　複数の行で重複するレコードは、それが更新されたら全ての行のレコードを書き直さなければいけない。下の例で言えば、Mathを正しくMathmaticsに直す必要が出た時、たろうと三郎のレコードを一個ずつ直す必要がある。それは面倒。複数の行でダブっているレコードは別テーブルにまとめて、アソシエーションで呼び出せるようにする。そうすれば、変更も一度で済む。

　また、ジローが退学したとすると、Englishの授業もなくなる。強化としてなくなることはないのに、ジローに連動してデータが壊れてしまうことになる。これを防ぐためにもClassは独立したテーブルでデータ管理をしなくてはいけない。

 

　はじめに使ったレシートのDBを第三正規形に直すなら

　このようにテーブルを３つにわけて考える。

●正規化のデメリット

　第三正規形のようにテーブルを分割していくと問題もある。テーブル数が増えるとそれだけSQL（データベース言語）への実行アクセスが増えるので処理が重くなる。

　例えば、上記の会計データのDBでは、商品の在庫数とかの管理はしていない。が、もし作るとしたら、入荷数の値さえあれば、販売数をひいて算出できるので、わざわざ在庫数のカラムを作る必要はない。（第一正規形の考え）でも計算処理があるので、そこで処理が重くなる。もし在庫数カラムを作っておけば、そこからデータを取るだけなので処理は軽い。

　処理速度以外にも、テーブル数が増えればそれだけ管理は見辛くなる。

　これらのデメリットがある。この側面を踏まえつつ、ちょうど良いデータベースの設計をしていくのである。