連載

SQL

販売管理データベースの作成

１．販売管理システムの概要

　今回「人形の家」をJSP-HTML版からJava-Flash版に新しくバージョンアップしました。 最初のバージョンは画面のインターフェースからデータベースのアクセスまでを１つのJavaで記述したので、Webアプリ固有のデータのセッション管理でかなり時間をとられました。
今回はFlash Remotingを利用して画面のインターフェースをFlashで作成したために、Javaではデータベースのアクセス部分のみの軽い仕様になりました。 使用しているデータベースは大きな変更はありませんが、MySQLを3.0から4.0に変更したため参照整合性を利用した点が変わります。

　ここでの販売管理システムは商品(人形)の販売の顧客管理から受注管理までを行う単純なシステムなので、このシステムを基にしていろいろ他の仕様を追加・変更・削除していけば、固有のシステムになって行くと思いますので参考にして下さい。
　なお旧システムの解説はこちらを参照して下さい。

２．テーブルの種類と関連性

　通常データベースの設計をする場合は、作成するシステムに必要な項目（音、動作も含む）全てを洗い出し、 関連性のあるグループに分けていきます。このグループをテーブル（又は表）と呼びます。
　各テーブルは次のようなチェックを行い、項目名とその属性（テキストなのか数字なのか）を決めていきます。 このような作業を正規化といい、出来上がるものを正規表といいます。

• データの値が繰り返しなどの複数の値を持たないようにする。（表として格納できない。）
• データの重複を排除する。（繰り返しを持たないようにすると発生してくる。）
• データの値の間の従属関係を少なくする。（ある値が決まれば他の値が決まるという関係）

３．テーブルの参照整合性

　大体のテーブル仕様がまとまったら、関連するキー項目の間で参照整合性を保ったほうがいいかを検討します。
　例えば、ある顧客Xが3種類の商品を注文していた場合、顧客マスタに顧客Xとして１件、受注マスタには注文No1.として１件、受注明細ファイルには商品別に３件のデータがデータベースに存在します。 この時に顧客Xが取り消しを行った場合、顧客マスタと受注マスタの間と受注マスタと受注明細ファイルの間に参照整合性の設定があれば、 顧客マスタから顧客Xのデータを削除した時点で、関連する他の４件のデータが自動で削除されます。 設定していなければ、他の２つのテーブルで関連するキーを検索して削除しなければなりません。

　あまりプログラムのデバッグ中では整合性が保たれているほど弊害を生み、何回もデータの入力を繰り返さないといけなくなる場合があります。 単体でのデバッグが終了し、結合段階に入った時点（本番のデータ入力がされていない時）で設定する方がいいと思います。

　MySQLでは通常のテーブル作成では後から参照整合性を追加しようと思ってもできません。 テーブルの型で参照整合性の設定ができる、できないが決まるからです。ここでの５つのテーブル型は最初から参照整合性ができる InnoDB型にしておきます。