参照整合性の問題に絡んで、前回でも少し触れた「レコード定着時期の問題」に触れておきましょう。
- 過去が変わる矛盾 -
商品の販売（受注）記録のテーブルには、「商品IDをキーに参照した商品テーブルの単価」が記録されています。これは、既に販売あるいは受注を終えた「過去の情報」です。従って、この情報は将来にわたって変更されることがあってはなりません。
ある受注情報を記録した後、その商品の販売単価が改定されたとします。販売情報のテーブルが商品テーブルとのリレーションを保ったままだと、この「単価改定」の影響が「過去の販売情報」にまで影響を及ぼしてしまいます。
昨日単価1,000円で販売した商品が、今日単価1,050円に値上げされたとしても、昨日の販売単価が変わってはなりません。この矛盾は、ダイアグラムの参照整合性制約では回避できません。これを防ぐには、取引が確定した段階でいち早く販売情報のレコードを定着してしまう以外にありません。
これまでに何度か説明してきましたが、定着とは「リレーションを断ち切り、参照先テーブルから導出した値を固定的に記録する」ことです。リレーションがなくなれば、1,000円の商品単価は永久に1,000円のままとなります。
- できるだけ頻繁に定着する -
この定着のタイミング設定（定着時期をいつにするか）が、アプリケーション設計にとって微妙な問題となります。１件の販売あるいは受注を終えたらすぐに定着するのか、一定時間が経過してから複数の販売（受注）結果をまとめて定着するのか……。
正解はありません。業務内容やアプリケーションの目的によって、定着のタイミングは異なります。ただ、できるだけ早めにこまめに定着した方がよいことは、言うまでもありません。
また、基本的に商品単価の改訂などマスターテーブルの保守作業は、受注を受け付けている営業時間内には行わず、営業関係の処理が停止している時間帯に実行するのが一般的です。そうすれば、（上述の問題を回避する目的だけから見れば）定着は１日に１回でも構わなくなります。
但し、通常は販売（受注）処理でレコードを定着した後、商品の在庫を減らすなどの関連する処理を行うことになりますから、１日１回の定着では、その日まる１日正確な在庫数が把握できなくなります。
基本的に取引情報の定着処理は、成立したらその都度実行するのが最も安全です。
データベースの側でテーブルに対する処理を保存し、各種アプリケーションから利用する手段として、ビューとダイアグラムを紹介しました。
データベースの側に保存してアプリケーションから利用できる機能には、この他にストアドプロシージャがあります。ストアドプロシージャはテーブルの関連付けやレコードを抽出のような個々のテーブルに対する処理ではなく、データベース全体に対する自動化を目的とした機能です。
ストアドプロシージャでレコードの抽出や削除、追加などの処理を組み上げても構いませんが、あまり小さな処理をたくさん作ると、アプリケーションのレベルではかえって混乱を招きます。
ストアドプロシージャはデータベースの側に保存される小さな汎用プログラムであって、テーブルを作成したり、テーブルの内容を丸ごと他のテーブルに移し替えるなど、基本的にはデータベース全般に関わる保守と管理を目的とするものです。上手く使うと非常に便利ですが、頼りすぎると無意味になったり返って手間がかかったりします。
ストアドプロシージャについては、回を追って紹介していきましょう。
 サンプルファイル (LZH形式 994KB)
 |
|
|
