« 基本設計を分担してはいけない | トップページ | 「論理設計」にこだわる利点 »

2015.10.27

DBの複雑さとアプリの複雑さ

 複雑なデータモデルは原則的に複雑なUIを導くが、工夫次第でモデルの複雑さをUIでカバーすることも可能である。ただしそれによってアプリ側の仕様が複雑化するようではいけない。DB側にあえて複雑さを寄せることでUIがシンプルに済む、そんなやり方を探ろう。

 以前の記事でも説明したように、たとえばロットのトレーサビリティを確保するために、必ずしもデータモデルを複雑にする必要はない。ふつうならば取引にともなうロットの内訳を保持するための「出荷ロット明細」のようなテーブルが必要になるが、それなしでロットの内訳を管理することは可能である(「トレーサビリティを確保するための便法」参照)。

 いっぽう、ロットの内訳をDBのレベルで保持せざるを得ないケースもある。「モデリングの標準問題から学べること」で説明した「花束問題」などはその例で、未来の花の廃棄数を計算するためにロット毎(入荷単位)の在庫数を管理する必要がある。では、そのときにDB構造の複雑化にともなってUIも複雑化せざるを得ないのだろうか。じつはこれにも便法がある。

 「花束問題」のデータモデルを見てほしい。受注見出しのレベルで「花束」の商品№を指定すると、その材料となる「単品」の内訳が受注明細として部品展開される。そして出荷時に花を結束して、単品のどのロットを組み合わせたかが報告される。その結果が出荷ロット明細である。

▼ロットの内訳をともなう複雑なモデル
151027b

 ふつうに考えたら、UIもこのモデルにしたがって複雑になる。具体的には、受注見出しと受注明細の親子関係に対応するフォーム(パネル)、さらに受注明細と出荷ロット明細の親子関係に対応するフォームとを別々に用意して、ロットの内訳データを保守する形になる。

 なお、これらの「親・子・孫関係」にある3テーブルを同時に保守できるようなフォームを想定できないわけでもない。しかしそれではゴリゴリにプログラミングする羽目になる。システムの保守性が低下するのでそれは避けたいし、じっさいその必要はない。

 次図を見てほしい。拙作のOSS開発基盤X-TEA Driverでの実装例なのだが、UIは受注見出しと受注明細の親子関係にもとづくフォームとしてあるだけだ。あたかも出荷ロット明細が存在しないかのような形で済んでいる。

▼ロットの内訳を文字列操作するシンプルなUI
151027a

 なぜこのようにシンプルなUIで済んでいるのだろう。フォーム上の明細項目「ロット内訳」の入力値を構文検査し、適正な場合にはそれを文字列操作してロット№毎の内訳を取り出し、さらにその情報にもとづいて出荷ロット明細を更新する――そのためのロジックがシステムに組み込まれているからだ。

 そのロジックによって、図の赤枠で囲った入力値は「31番ロット4本と32番ロット6本のカスミ草」と解釈される。やろうと思えば、ロット管理対象の単品とロット管理対象外(固定値のロット№をとる)の単品とを混在させて報告する形式さえ実現可能だ。

 ここで重要なのは、この一連のロジックが上掲のアプリに組み込まれているわけではないという点だ。このアプリも、他のアプリと同様にノンコーディングで簡単に作れる「うすっぺら」なもので、そのどこを探しても上述のロジックは書かれていない。じつはそのロジックは、受注明細の拡張定義に含まれるスクリプトとして組み込まれている。つまり、アプリの仕様としてではなく、意図的にDB側の仕様として配置されているのである。

 これは合理的な実装方針だ。システムの保守性の悪さはおもに「管理対象となる仕様要素がアプリ(機能定義)側に偏在する」ことで生じる。とくにJava等を使って手作業でコーディングされたりすればてきめんである。多くのシステムが、アプリを記述するための大量のコードの下であえいでいる。DB側の仕様を複雑にすることでアプリのコード量を減らせるのであれば、それはぜひともやったほうがいい。

 じっさいにそれが可能という話だ。そのためにはまず、アプリの仕様を様式化・類型化して、アプリをノンコーディングで作れるようにする。同時に、従来アプリの上に盛られていた仕様をテーブル側で保持できるようにする。結果的にアプリは「うすっぺらでありきたり」な要素に縮退し、システム全体の見通しが良くなる。さらに生産性や保守性が劇的に向上して、非効率な人海戦術や分業が不要になる。

 この革新的態勢の背景には、システムの複雑さに関する経験則がある。同一のシステム要件にもとづくのであれば、(意図的に無駄の多い形に作られない限り)システム全体の複雑さには「保存則」が成り立つ。つまり、「システム定義の3要素(DB構成、機能構成、業務構成)」の中のある要素をシンプルに済まそうと思えば、他の2要素が自動的に複雑化する。

 この認識は、「全体の複雑さの下限があるのなら、せいぜい保守性の良好な形で複雑さを配置すればよい」という気づきをもたらす。ではどの要素に複雑さを寄せるべきかというと、機能構成以外の要素(DB構成や業務構成)を狙えばよい。なぜならこれらのうちもっとも保守に手間がかかるのが、他でもない機能構成だからだ。

 複雑なシステム要件というものは、上述したように与件として避けられないもので、それを取り込むために機能構成を複雑にする方針をとるべきではない。システムの保守性を高めるために、アプリのあり方ではなく、DBや業務のあり方を複雑にすることを画策しよう。開発基盤はその意図に応えてくれるものでなければならない。

|

« 基本設計を分担してはいけない | トップページ | 「論理設計」にこだわる利点 »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: DBの複雑さとアプリの複雑さ:

« 基本設計を分担してはいけない | トップページ | 「論理設計」にこだわる利点 »