逆方向バリデーションを自動化する

　バリデーション（入力値の妥当性検査）の仕様を「テーブルの拡張定義」とみなして、アプリではなくＤＢ側に置く。これによってさまざまな効果がもたらされるが、その中で今回取り上げたいのは「逆方向バリデーションが自動化される」という利点だ。逆方向バリデーションはこれまで、個々の案件において場当たり的に対処されてきたグレーゾーンであった。これが自動化されることで、問題を構造的に扱えるようになる。

　まず、「逆方向バリデーション問題」の様相を確認しておこう。たとえば、(1)の商品テーブル上には「販売まるめ数」があって、受注テーブルの「受注数」はその倍数値でなければいけないとする。この場合、受注データの保守アプリにおいて、販売まるめ数が'10'である商品Ａの受注数として'55'を指定するとエラーである。55は10の倍数ではないからだ。

(1)受注数は販売まるめ数の倍数であること

[商品] 商品id、商品名、販売まるめ数
＋　　　00001　商品Ａ　　10（20に変更することを許す?）
｜
└―…[受注] 受注id、受注日、商品id、受注数、出荷状況...
　　　　　　000123 20xx/05/12 00001　　50　　未出荷

　では、(1)で例示したような受注データを追加した後で、商品Ａの販売まるめ数を'10'から'20'に変更すべき必要が生じたらどうなるか。既存の受注データの受注数50は、20の倍数ではない。そのようなデータ状況をもたらす変更要求を、商品メンテナンスアプリは受け入れるべきか否か――これが「逆方向バリデーション問題」である。この例のように、複数のテーブルが関わるバリデーションには「正方向」だけでなく「逆方向」の側面がある。

　変更を受け入れるべきかどうかの選択肢にはいくつかある。経験上、以下のYが適切とみなされることが多いだろうとは言えるが、ケースバイケースである。

X:関連する受注の状態によらず変更は許される

Y:関連する受注の状態によって変更は許される

Z:関連する受注の状態によらず変更は許されない

　正しい仕様がいずれであるにせよ、逆方向バリデーションはこれまで、保守アプリや別途のバッチ処理に手作業で組み込まれてきた。コードの重複感や変に込み入った感じがあるうえに、少なくとも私の経験では場当たり的に対処されてきた。「よく考えたら逆方向の整合性チェックも要るよなぁ」みたいないい加減なノリでそれは組み込まれた。

　双方向バリデーションを同等に扱うために、「逆方向」の仕様検討もなんらかの形で強制されたほうがいい。それも「設計標準」あたりで注意喚起するだけでは十分ではなく、開発基盤によって強制されるべきだ。そのためにどうすればいいか。次のようなしくみを盛り込めばよい。

　まず、ＤＯＡ（データ中心アプローチ）の基本テーゼである「データのカプセル化」の指針にしたがって、バリデーションルールをテーブルの仕様として組み込めるようにする。データ保守アプリの実行時にその仕様が動的に注入されることで、個々のデータがバリデートされる。上の例では、まるめ数と受注数との制約関係は「受注テーブルの仕様」として登録され、「受注メンテナンス」等のアプリにそのルールが組み込まれて検査される。ここまではわりとよく聞く話だと思う。

　さらに、データ保守アプリには、「参照元テーブル（更新対象テーブルを参照しているテーブル）」上のバリデーションルールが自動的に（動的に）注入されたらいい。「商品メンテナンス」を例とすれば、商品の参照元である受注テーブル上のバリデーションルールが組み込まれ、商品テーブルの新しいまるめ数の値に対して既存の受注データとの整合性が保たれているかどうかが検査される。

[商品] 商品id　（バリデーションルール）
＋　　　　　　　　｜
｜　　　　　　　　↓注入　＜正方向＞
｜　┌────────────┐
｜　│　　商品メンテナンス　　│
｜　└────────────┘
｜　　　　　　　　　　　↑注入　＜逆方向＞
｜　　　　　　　　　　　｜
└―…[受注] 受注id　（バリデーションルール）

　すると何が起こるか。商品メンテナンス上でまるめ数を変更すると「既存の受注データと不整合が生じるため、まるめ数の変更は許されません」といったエラーメッセージが返る。これはアプリの動きとして正しいのかもしれないし、そうでないのかもしれない。いずれにせよ、開発者は逆方向バリデーションを意識せざるを得なくなる。そこで必要ならば、受注テーブル側のバリデーションを「受注数は販売まるめ数の倍数であること」ではなく「受注数が変更された場合、その値は販売まるめ数の倍数であること」とするといった調整を施せばよい（その場合、商品メンテナンスはまるめ数の変更を許すだろう。なぜなら受注数は変更されていないから）。最悪その調整を忘れていたとしても、不整合を引き起こす更新要求が素通りすることはない。

　注意してほしいのはこのしくみが、バリデーションルールをテーブル側の仕様として組み込んだゆえにこそ、実現可能となっている点だ。つまりバリデーションルールは、アプリから引き剥がされることで初めて、開発基盤によって「正方向」にも「逆方向」にも適用可能な操作要素になる。もしアプリ側の仕様として組み込んでしまえば、逆方向バリデーションの仕様として適宜抽出・操作することはほとんど不可能だ（注）。

　なお、逆方向バリデーションを自動化するために克服すべき課題がある。参照元がとくに多いテーブルの場合、逆方向バリデーションに時間がかかる点だ。とはいえマシンの性能は良くなるばかりだし、ロジック上も工夫の余地がある。たとえば、チェックオンリー（更新ボタンではなくEnterを押す操作）のときには逆方向バリデーションを実行させないとか、変更された項目から影響を受けるバリデーションだけを選択的に実行させるといった工夫もできる。

　拙作の開発基盤XEAD Driverでは、逆方向バリデーションが進行している間、パネルの右下に「クロスチェック中」と示されたプログレスバーが現れる（下図）。たいていは一瞬で消えてしまうので気づかれないのだが、商品テーブルに対しては参照元が２０個以上関連しているため、商品保守パネルではプログレスバーの動きを視認できる。事情を知らなければ「ナンダコレハ」だろうが、この記事を読んだ方であれば「アアコレカ」と思ってもらえるだろう。「オオスゴイ」と感心されそうにないほど地味なのが悲しいのだが。

本ブログでの関連記事：
バリデーションの双方向性問題を解く

注：ＤＢＭＳ付随のトリガーにバリデーションが組み込まれた場合でも、同様の問題が生じる。この意味においても、開発基盤上で実装されたトリガーのほうが使い勝手が良い。参考記事：開発基盤のトリガーとＤＢＭＳのトリガー