システム開発で言うテーブルの正規化とは、
データをルールに従って、利用しやすい形にすることです。
テーブルの正規化については、これまでの記事でも説明しています。
コツは「繰り返し入力する可能性のあるものは、別のテーブルに分ける」ということでしたね。
テーブルを正規化することで、同じデータを何度も入力する手間が省けます。
正規化されたテーブルは、ほとんどの列が数字になります。
数値を入力、選択するだけなので、文字列の場合より入力ミスが防げます。
それに数字のほうが文字列より、データベースへの保存時の容量が少なくて済むメリットがあります。
前回、売上伝票の鑑部を表形式にするところまでやりました。
でもこの状態では、まだテーブルが正規化されていません。
繰り返し入力される可能性のある列が、いくつもあるからです。
まず、伝票Noは重複することが無いので、そのままでOKです。
日付は重複しますが、これだけは例外的にOKです。
普通の会社では、同じ日にいくつも伝票が発生します。
するともちろん、日付が重複します。
でも業務システム側で、当日の日付を自動入力することは簡単ですし、
カレンダーから選択できるようにすることも可能です。
だから日付を別テーブルに分ける必要は無いのです。
次は顧客名です。
伝票は1回の買い物ごとに発生します。
同日でも別日でもいいのですが、同じお客様が何度も買い物をする可能性は十分ありますよね。
だから顧客名は、重複するデータということになります。
顧客マスターテーブルを別に作ったほうが良いわけです。
承認印と係印はどうでしょうか？
本来、紙の伝票では、社員が印鑑を押すところです。
社員名が入っていますよね。
同じ社員が複数の売上伝票に押印ことは十分考えられます。
社内では仕事の役割や役職が決まっているはずなので、
同じ社員が何度も押すと考えるほうが普通です。
だからこの部分は、重複するデータです。
ということは、社員マスターテーブルを別に作ったほうが良いわけです。
以上の事から、売上伝票の鑑部のテーブルを正規化すると、
・売上伝票(鑑部)
・顧客マスター
・社員マスター
の各テーブルができます。
売上伝票には、数字が入力されている点がポイントです。
日付は表示形式だけの問題です。数字と記号で入力することも可能。
このように正規化されたテーブルでは、メインのテーブルには、ほとんど数字が並ぶことになります。
必要に応じて、他のテーブルを参照すれば、顧客名や社員名が分かります。
また結婚などによって、社員の姓が変わった場合でも、社員マスター側を変更するだけで済み、メインの売上伝票には影響しないのもメリットです。
これがリレーショナルデータベースの考え方です。
