| 問題 | 問題点 |
|---|---|
| 追加 | トランザクションが実行する前に、マスタ情報を登録できない |
| 更新 | 何件も修正しないといけない。修正漏れの危険性がある |
| 削除 | 不要な注文書を削除した時に、必要なデータがなくなってしまう危険性がある |
詳細説明
注文情報をサンプルとして、追加、更新、削除時に正規化をしていない時の問題を説明します。
正規化前の状態サンプル
正規化後の状態
追加時の問題
未登録のマスタ登録
来月「消しゴム」を買う事が決まりました。単価は300円です。
正規化前の表を見ると、まだ注文前なのでデータ登録できません。
データベースを持っているのに、手元の紙に記録しないというおかしな事が発生します。
一方で正規化後のテーブルを見ると商品マスタテーブルがあります。
ここに事前に登録することが可能です。
付加情報の登録の手間
XYZ会社に追加の注文をすることになりました。
正規化していない状況ですと、また住所を登録しないといけません。住所を確認して登録する手間がかかります。
また過去の注文データの住所を確認した時に、注文書ごとに異なっていたらどちらがあっているのかわかりません。
正規化後の形で持っていれば、業者名さえ知っていれば最新の住所を使う事ができます。
更新
４月１日付で業者の住所が千葉に変わりました。
新規の注文書を発行する時には新しい住所を使う事になりました。
正規化前の状態ですと未発注のデータをすべて書き換えないといけません。
データ修正が大変なのと変更し忘れる危険性があります
削除
鉛筆を注文するのをとりやめて、その行を削除しました。
正規化しないとこちらのデータとなります
来月になって、鉛筆を発注することになりました。
鉛筆の単価を入力しようとしましたが、データがなくて調べ直さないといけないことがわかりました。
このように思いもかけずに必要なデータまで消してしまうという事が発生します。
まとめ
第三正規化までする事によって、データ更新する上での様々なリスクを避けることができます。
テーブルのレイアウトを設計する時に
・注文をキャンセルした時は大丈夫か？
・注文前に商品のデータを入れられるか？
など１つ１つ例外を考えるのはとてもたいへんです。検討漏れが発生し、トラブルが起きやすくなります。
第三正規化まですれば、実際の業務がどんなものでも、基本的なリスクを避けることができます。
注文情報、組織情報、受注情報、出荷情報など実務の中身を知らなくても、正規化さえ知っていれば、問題が起きにくいテーブル設計ができます。
正規化はシステム開発で役立つ知識なので、ぜひ勉強していきましょう。
