« スクリプトエンジンの可能性 | トップページ | 「個別案件」ではプログラミングの可能性を生かせない »

2009.08.17

「動的参照関係」を手なづける

 テーブル関連の「参照関係」には「静的」なものと「動的」なものとがある。後者はどういうわけかデータモデリングの参考書の中でほとんど取り挙げられないが、一定以上複雑なデータベースシステムであればふつうに現れる。開発者にとっては避けて通れないデータ構造だ。

 「動的参照関係」が何かを見る前に、通常の参照関係である「静的参照関係」を確認しておこう。たとえば次のようなデータモデルがあるとする。

 [A] {a}, b
 +
 |
 └―…[C] {c}, a, d

 このモデルは「テーブルC上に置かれたaをキーとしてテーブルAにアクセスし、A上の項目であるbの値を手に入れる」という操作手順を含意する。この関係はまた「Cのaは、テーブルA上で規定されている値をとらねばならない」、および「そのレコードを参照するC上のレコードが1件でも存在しているのであれば、[A]のレコードの削除は許されない」という制約をともなう(それぞれを更新制約、削除制約と呼んでおく)。以上は「静的参照関係」の例だ。

 ここで、{b,d}を識別子とするテーブル[BD]を導入する。そして「C上のdの値と、関連するA上のbの値の『組み合わせ』が[BD]に存在していなければならない」という更新制約があるとする。この場合、モデルは次の形になる。

 [A] {a}, b
 +
 |
 └―…[C] {c}, a, d, (b)
 ┌―…
 |
 +
 [BD] {b, d}, e

 [C]と[BD]との間の参照関係に注目してほしい。[BD]に対する外部キーは、[C]上のdとカッコ書きで示されているbとの組み合わせだ。

 [C]上にbを置くと、通常は正規化違反とみなされる。bはaに関数従属する項目なので、cを識別子とする[C]の上に本来は載せてはならない。しかし、この場合のbはdとともに[BD]に対する外部キーを構成する論理的な項目(継承属性)であるゆえに、モデルとしては許容される(カッコ書きされているのはそのためで、その種の項目を筆者は「継承属性」または「導出属性」とみなして通常の「固有属性」と区別している)。もちろんこのモデルを実装する際、bはあくまでもAから動的に読み込まれるべき項目なので、C上に物理的に置いてはならない。

 そういうわけなので、実際のデータ処理において[C]上のレコードから[BD]へアクセスするためには次の手順を踏む必要がある。

(1)[C]上のaで[A]にアクセスしてbの値を手に入れる
(2)[C]上のdとbの値の組み合わせで[BD]へアクセスする

 このように、動的な操作を伴いながら成立している参照関係が「動的参照関係」である。

 動的参照関係においては参照テーブルへのアクセス手順が複雑なので、削除制約も必然的に複雑だ。たとえば、BDのレコードを削除する場合、システムは上記の逆の手順をたどって、該当するCレコードが存在するかどうかをチェックしなければいけない。それが1件でも存在すれば削除は許可されない。

 具体例で説明しよう。「有効期間」を含むデータ構造には動的参照関係がひんぱんに現れる。たとえば、受注日において有効な掛率が設定されるという業務要件にもとづく次のようなモデルがあるとする。

 [顧客] {顧客C}, 掛率クラス,...
 +
 |
 └―…[受注] {受注№}, 受注日, 顧客C, 商品№,(掛率クラス),(単価発効日),...
 ┌―…
 |
 +
 [商品期間掛率] {商品№, 掛率クラス, 単価発効日}, 期間掛率, 単価失効日

 [受注]から[商品期間掛率]への外部キーは、固有属性の「商品№」と継承属性の「掛率クラス」および、導出属性(継承属性の仲間)の「単価発効日」との組み合わせとなる。「単価発効日」は、受注日を用いて[商品期間掛率]上の複数レコードを探索することで値が決定される項目である。つまりこれは、参照先テーブルそのものを調べなければそこに対する外部キーの値が定まらないという例なのである。

 この場合でも、[商品期間掛率]上のレコードを削除する場合、対応する有効な受注レコードが存在するかどうかを探索して、1件でも存在すれば削除を禁止しなければいけない。読者はその一般的なバリデーション過程が単純でないことを想像できるだろうか。

 静的参照はDBMSのレベルで実装可能であるが、動的参照に関しては、DB付属のトリガー機能なりアプリ側の機能なりを用いて実装する必要がある。削除の際のバリデーションも含めてゴリゴリなコーディングが必要となってしまうため、開発基盤のレベルで動的参照を手軽に扱えるしくみがほしい。

 筆者が開発中の開発基盤においては、静的参照だけでなく動的参照もテーブルの拡張定義として登録できるようになっている。正規形を崩すことなく、コーディング不要で更新制約と削除制約までをフレームワークが自動的に監視してくれるようにしたい。たいへん便利なので、業務アプリ用開発基盤の評価項目のひとつとして動的参照関係の扱いを含めてほしいものだと手前味噌なことを考えている。

|

« スクリプトエンジンの可能性 | トップページ | 「個別案件」ではプログラミングの可能性を生かせない »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/87674/45956710

この記事へのトラックバック一覧です: 「動的参照関係」を手なづける:

« スクリプトエンジンの可能性 | トップページ | 「個別案件」ではプログラミングの可能性を生かせない »