みなさん、こんにちは!つむぎです。
ちまたでは、消費税率10%への開始年月日が取り沙汰されていますが、今日はそんな時に役に立つかもしれないAccessのチップス「正規化くずしが必要な時って、こんな時!」というお話しのパート①を。
みなさんがAccessの書籍を購入されてお勉強される時、必ずと言っていいほど、「正規化」についての説明があると思います。
ここでちょっと、「正規化」についての復習をば。。。
☆そもそも、正規化ってなに?
テーブルの関係性を失う事なく、中にあるデータの重複性やムダを少なくし、項目同士の更新が効率よく行えるように、テーブルを分解する事を正規化と言います。
いろいろなテーブルで同じ項目が重複していると、データの修正・追加・削除の時に整合性が取れなくなる場合があります。
重複したデータを持つとデータ容量が大きくなり、データベースの処理も遅くなります。
このようなことを避けるために、それぞれのテーブルで重複した項目は、番号(コード)だけを持ち、番号(コード)と名称のテーブルを別に持つように分解します。
一般的に解説されている正規化は、第1正規形~第3正規形のことです。
☆第1正規形~第3正規形の分解規則ってこんな感じ!
正規形 | 説明 |
第1正規形 |
第1正規化では、繰り返しの部分を複数のレコードにして、繰り返しを排除します。 |
第2正規形 |
第2正規化では、部分関数従属(主キー項目の一部によって、値が決定する関係)する項目を分離します。 |
第3正規形 |
第3正規化では,主キー以外のキーに関数従属(一方の値が決まると他の項目の値も一意に決まる関係)する項目を分離します。 |
詳しい正規化の手順は、詳しく解説してくれているサイトでご確認くださいませ。
例えば、一般的な商品を売るお店のデータを、第3正規形にまでしたのが下記の例です。
(画像クリックで、拡大されます♪)
データとしては、「商品マスタ」「伝票テーブル」「伝票明細クエリ」。
「伝票明細」に関しては、実際の運用時に使用する「伝票明細クエリ」の形で説明します。
※ここではわかりやすくするため、「メーカー情報」や「お客さま情報」は除いています。
☆各データの説明
①「商品マスタ」→[商品コード][商品名][商品単価]から構成されるテーブル
②「伝票テーブル」→[伝票番号][日付]から構成されるテーブル
③「伝票明細クエリ」→「商品マスタ」+「伝票テーブル」+「伝票明細テーブル」が連携して構成されるクエリ
・[伝票番号]は、「伝票テーブル」と連携
・[商品コード]は「商品マスタ」と連携して、「商品マスタ」から[商品名][商品単価]を参照
・[商品ごとの金額]は、「商品マスタ」から参照された[商品単価]、クエリ内に直接1+[消費税率]を記述したもの、そして「伝票明細テーブル」内の[数量]を掛けあわせて、計算で算出
→[商品単価]×(1+[消費税率])×[数量]
こちらのお店では、上記の設計で何年も前から伝票を管理しています。
計算で使用されている[消費税率]は、現在8%設定です。
こちらのお店では、消費税が8%になったタイミングで商品単価も変更して、現在使用しているのは変更した新単価です。
さてある日、店長さんが「消費税率が5%の時のある商品の単価を調べよう!」と思いました。
「あれ?おかしいな?消費税が5%の時の伝票の計算が、8%になってる。単価も新単価になってる。あれ?あれ?」
さあ、大変!そうなんです!
上記のような設計で運用してしまうと過去の履歴が書き換えられてしまって、過去のデータを調べられなくなるんです!
そして、[消費税率]はクエリの計算式の中で固定化されていますから、[消費税率]の変更に対応できません!
実際、この形で引用されている企業さんは思っていた以上に多く、この前の消費税率5%→8%への変更時には、クエリの計算式で個別に対応する事例が頻発しました。
そして、今回の消費税率10%の先送り。
「つむぎ」では、上記の設定変更を依頼いただいたお客さまには、[2015/10/01→10%]に自動的に変更になるように設定させていただいたのですが、今回もし先送りされるとなると、この設定を見直さないと[2015/10/01]以降の金額の計算がおかしくなってしまいます。
上記のような設計の弊害は、こんな形でもあらわれるんですね!
一般的に、「正規化」を行うことは利点が多いです。
実際の現場では、得てして「一部の正規化をくずすこと」が必要になってきます。
次回は、上記の事例をもとに、実際の現場で役立つ「正規化くずし」をした設計例をご紹介します。