« サブシステムを「使い捨てる」ためのアーキテクチャ | トップページ | キレイなコードでも仕様書の代わりにはならない »

2010.02.04

妥当性検査をDB側に集約する

 テーブルフィールドの妥当性検査をどこに配置するかは、DBシステムの開発において重要な問題である。大別してプログラム側に置く流儀とDB側に置く流儀とがあるが、基本的に後者が正しい。

 なぜなら、どのプログラムで実行されるかに関わらず同じ検査がなされるとしたら、その仕様はフィールド固有の属性とみなされるからだ。たとえそのフィールドに対する妥当性検査を実行するプログラムが1個しかないとしても、そのように考えるべきである。フィールド固有の属性については、テーブル側の定義情報を読めばひととおりわかるようでなければいけない。以前にも書いたように「カエサルのものはカエサルへ、DBのものはDBへ」の原則で、フィールドの扱われ方に関する仕様はテーブル上に集約したほうがよい。

 では次のような妥当性検査があったらどうだろう。「テーブルA上の関連レコードのフィールドBの値がナントカの場合、テーブルC上のフィールドDが取る値はナントカでなければならない」 これは「他のテーブル上のフィールド値との組み合わせ」において妥当性が評価される例だ。フィールド値単独で完結する検査や「同一テーブル上のフィールド値の組み合わせ」であれば、当該テーブル定義上に置くことに疑問の余地はない。しかし「他のテーブル上のフィールド値との組み合わせ」にもとづく妥当性検査の場合、どこに配置したらよいのだろう。

 異なるテーブル上のフィールドが「出会う場所」はどこか。プログラム域である。ゆえに、その種の妥当性検査はプログラム仕様上で記述せざるを得ない――そのように考えられることがあるが、じつはそうでもない。

 上の例は、「テーブルCのレコードを読み書きする際には、テーブルA上のフィールド値が参照される必要がある」という事情を示唆している。いっぱんに「あるテーブルのレコードが読み書きされる際に、いかにも参照されそうなテーブル/フィールド群」を、そのテーブル毎の固有の属性として想定できる。これはテーブルの「動的仕様」とでも呼べる側面で、そのような仕様の一種として「他テーブルのフィールドとの組み合わせにもとづく妥当性検査」は分類可能である。ようするに、案外多くの妥当性検査がDB側の仕様として取り込めるということだ。

 設計情報をそのような方針に従って記述することには何の支障もない。どんどんやればよい。問題は、実装時にどうなるかだ。妥当性検査をせっかくDB側の仕様として一元的に記述したのに、実装時にはプログラム上に分散してマニュアルコーディングするはめになった、なんて悲しすぎる。

 実装用フレームワークは、そんな事態を避けるためにも存在している。設計の姿と実装の姿を一致させる(一致しているように見せる)ことは、フレームワークが果たすべき重大な役割である。だから妥当性検査が単純であろうが複雑であろうが、フレームワークにおいてテーブル定義の拡張要素として盛り込めるようでなければいけない。フレームワークが管理するデータ処理プログラムは、テーブル定義を何らかの形で参照しながらフィールドに対する妥当性検査を実行すればよい。

 ただしその場合、プログラムが無駄なテーブル読込操作をしないように制御されなければいけない。下手をすれば、1トランザクションで同一レコードに対する読込操作が何度も起きたり、使われもしないフィールド値を得るための無駄な読込操作が起きてしまう。以前に「動的参照関係」やこれにもとづく削除検査の必要に関する話を書いたが、それもこれも含め、フレームワーク側で暗黙的に配慮されるべきややこしい事情は想像以上に多い。

 しかし、個別案件毎のプログラミングの労苦が減るのであれば、フレームワークをプログラミングする労苦は引き受けたほうがよい。どんなにややこしい配慮であろうと、形式化できさえすれば自動化できる――これこそがプログラミングの醍醐味だ。そして、その旨みを「個別案件の開発」ではなく「フレームワークの開発」において求めることで、プログラミングから受ける見返りはより大きくなる。これこそ「レバレッジ・プログラミング」である。

|

« サブシステムを「使い捨てる」ためのアーキテクチャ | トップページ | キレイなコードでも仕様書の代わりにはならない »

コメント

仮想フィールドを使用した妥当性検査の類のものですよね?
幸三先生の3番弟子のHH。
いまだに教えて頂いたデータモデリングやってます。

投稿: HH | 2010.02.11 23:33

おやおや、しばらくですー。自分に弟子がいるなんて初耳だなあ(^^;

投稿: わたなべ | 2010.02.12 19:05

お世話になっております。
だいぶ古いエントリーですが、今更ながら質問させてください。
妥当性検査をDB側に集約するのは、同じことを色んなところに書かない為ですよね。では、同じ妥当性検査を複数のテーブルに適用したい場合は、どうなるのでしょうか?結局は、同じことを複数個所に書くことになるのでしょうか?
何かお考えがあれば教えて頂きたいです。
よろしくお願いいたします。

投稿: くまきち | 2017.10.09 15:33

くまきちさん

「なんとか数量」というフィールドがあって、これは複数のテーブルに載っているのだけれども、同じ妥当性検査があてがわれる、という例ですよね。「そのフィールドがどのテーブルに載っていようが適用される妥当性検査」については「テーブルレベル」ではなく「フィールドレベル」の定義要素として登録すればいいことになります。

ただし、フィールドレベルの妥当性検査を登録できる開発環境は多くありません。私は昔、そのような環境で開発していたのですがあんまり使いませんでした。便利そうですが案外使われない機構なのかもしれません。

投稿: わたなべ | 2017.10.10 18:57

いつも勉強させて頂いてます。
またまた質問ですが、動的参照関係を用いた妥当性検査の実例は、コンセプトウェアの何れかのモデルに含まれていたりしますか?
理屈は理解したのですが、実際に設計書としてどのように表現するかに興味があり、お聞きしました。

実際は、動的参照関係を使っていなくても、組み合わせにもとづく妥当性検査の仕様を渡辺さんはどのように表現するか知りたかったのです。
いかがでしょうか?

投稿: くまきち | 2017.11.30 19:50

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 妥当性検査をDB側に集約する:

« サブシステムを「使い捨てる」ためのアーキテクチャ | トップページ | キレイなコードでも仕様書の代わりにはならない »