« 適用分野と実装手段の組み合わせ戦略 | トップページ | 正規化崩しの目的は「高速化」だけではない »

2016.05.07

レコードの変更予約管理を合理化する

 取引先の社名が来月から変わることになったとしよう。取引先情報の管理者は、月末に残業して「取引先マスター保守」のアプリを開いて、項目値を変更することだろう。しかし、そのように牧歌的な態勢では対応しきれないケースもある。ここはやはり、将来に変更されることがわかった時点でその事実をさっさと登録し、規定のタイミングで自動更新できるようにしたい。どんなやり方が考えられるだろう。

 説明のために、そのように扱われる項目を「時限属性」と呼び、それ以外を「恒久属性」と呼んでおこう。「時限属性」には、タイミング指定で値が変化するとともに、過去の変更履歴が管理対象となるといった特徴がある。いっぽうの「恒久属性」については、値の変更要求があればその場で変更してかまわない。

 一般に、1個のテーブル上には時限属性と恒久属性とが混在するし、時限属性の値が変化するタイミングもバラバラである。まさにこれらの理由から、テーブルの本来の主キーと発効日とで複合主キーを構成するやり方(*1)には無理がある。たとえば取引先マスターを図1のようにすれば、データ構成上の無駄が多い。項目値が1個でも変われば新たなレコードを定義しなければいけない。取引先をいちいち日付指定で検索する羽目になるのもやっかいだ。

▼図1.主キーに発効日を組み込む
201605071

 かといって、図2のようにバカ正直に階層化するのも何やら大袈裟過ぎる。こういうテーブルをいくつも含むDBを扱うシステムは、いやになるほど複雑に違いない。

▼図2.属性毎に階層化する
201605072

 じっさいには多くのシステムでは、ターゲット(更新対象テーブル)に含まれる項目に制御項目を加えた「変更予約テーブル」を用意することで対処している(図3)。そこに変更予定を登録して、夜間処理においてその晩が変更予定日であるようなレコードを取り出して自動更新させるのである。

▼図3.変更予約テーブルをターゲット毎に用意する
201605073

 このやり方だと、本番システムの仕様が複雑化しないし、時限属性と恒久属性とを区別する必要もない。その意味では図1や図2のやり方よりも合理的ではある。しかし、ターゲットのレイアウトが変わるたびに変更予約テーブルを作り変える必要があるし、変更予約登録や自動更新用のアプリをターゲット毎に用意しなければいけない。他に良い方法はないものだろうか。

 そこで提案したいのが、図4のような汎用テーブルを用いるやり方だ。n個のターゲット(ここでは1,2の2個)には、二次識別子として「共通KEY」をあらかじめ組み込んでおく。そのうえで、ターゲットの特定レコード向けの変更予約を3,4に登録し、その内容にもとづいて指定タイミングで自動更新させるのである。

▼図4.汎用の変更予約テーブルを用意する
201605074

 では、3,4のテーブルに対してどんなフォームを用いて変更予約が追加されるのだろう。少し考えると、ターゲット毎に別々の登録用アプリを用意したうえで変更予約を追加しなければいけないような気がする。それだとアプリ作成の手間については、図3のやり方とたいして変わらない。

 じつは業務システム開発に特化した基盤を用いれば、登録用アプリをターゲット毎に用意する必要はない。図5で示したような汎用アプリを1個用意すれば済む。そのアプリは「テーブルID」とそのテーブル上の処理対象となるレコードの「共通KEY」の値をパラメータとして受け取ると、リポジトリからそのテーブルに含まれるフィールドの一覧を読み出し、さらに共通KEYでDBから各フィールドの現在値を読み出して表示する。そこでユーザは変更したいフィールドの値を上書きしてEnterする。すると、リポジトリに登録されている妥当性検査が動的に読み込まれ、変更値にもとづく「仮検査」が実行される。それで認可されたなら変更分のフィールドだけが「4.保守管理明細」に書き込まれる。

▼図5.変更予約登録機能と自動更新機能
201605075

 変更予約にもとづいて自動更新するバッチ処理についても、ターゲット毎に用意する必要はない。ここでも、指定されたテーブルに対する妥当性検査が動的に読み込まれるからだ。更新時点でのデータ状況にもとづく「本検査」で認可されたなら更新がなされ、保守管理見出しの「処理状況」は"受領済"として更新される。なんらかのエラーメッセージが返るような予約については、そのメッセージとともに"拒否済"として更新される。

 なお、このしくみでは「保守期日」を当日にすれば「即時更新」も出来るし、新規追加や削除も出来るようになっている。可変長文字やバイナリといったデータ型の扱いについての制約はあるものの、変更予約を合理化するための有力な選択肢になるだろう。

 ただし、このしくみを実現するためには「リポジトリ」が欠かせない。そこにはテーブルのメタ情報だけでなく、妥当性検査を含む「業務ロジック」までが格納されている。個々のアプリがそれらを必要に応じて取り出せるからこそ、このように革新的な仕掛けも実現できる。「業務ロジックをアプリに置いてはいけない」でも説明したが、業務ロジックを個々のアプリ上にハードコーディングするという旧弊が是認される限り、業務システム開発の発展は頭打ちである。そのことがこの例からもわかってもらえるだろう。


*1.「有効範囲」を伴うテーブルの話ではない点に注意してほしい。たとえば「期間別単価」のようなテーブルはここでは問題とされていない。その種のテーブルは「重量別単価」や「体積別単価」のように、基準値指定で範囲内から検索することが初めから想定されている。いっぽうこのエントリーで議論されているのは「未来のある時点で値が変化することがわかっている項目」をどう扱うかであって、両者は似て非なる問題である。

|

« 適用分野と実装手段の組み合わせ戦略 | トップページ | 正規化崩しの目的は「高速化」だけではない »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: レコードの変更予約管理を合理化する:

« 適用分野と実装手段の組み合わせ戦略 | トップページ | 正規化崩しの目的は「高速化」だけではない »