« 「仕様書プログラミング」とその運命 | トップページ | コンテキスト・ダイアグラムを描こう »

2014.01.17

システムの仕様情報を正規化する

 「DB構造の正規化」は業務システム設計の眼目である。それはデータ項目間の関数従属性をDB構造に反映させるために必要な配慮であり、これを怠ると、データの矛盾やアプリの複雑化にともなう保守性の低下といったさまざまな問題が生じる。いわゆる「正規化崩し」を行うにせよ、基準となる正規形の認識なしでは失敗する。以上は事実として広く知られるようになった。

 ところが「システムの仕様情報」を正規化することの重要性はほとんど認識されていない。従来の仕様書の分厚い束には、記述の重複やそれゆえの矛盾があちこちに埋まっている。DB構造だけでなく仕様情報の構造についても、関数従属性にしたがって"one fact in one place"の形に正規化される必要がある。何のためか。矛盾を除くとともに、仕様の作成・保守コストを最小化するためだ。

 たとえば「テーブルT」のフィールドとして「XX単価」と「XX数量」があって、それらを掛け合わせることで「XX金額」が得られるものとする。この計算過程は仕様要素としてどこに置けばいいのだろう。

 従来の発想では、XX金額やその計算過程は「テーブルTを利用するアプリの仕様」として記述されていた。そんなアプリが3つあれば、3つの仕様書上に個々に記述される。これは正規化違反である。重複して置かれた仕様の間で遅かれ早かれ矛盾が生じる。

 システムを利用するにあたって「XX金額」が必要であり、その値は「XX単価」と「XX金額」とを掛け合わせて得られる――この業務ルールは、本来であれば「テーブルTの仕様」として1回だけ記述しておけば済む。仕様の体系を正規化するとはそういうことだ。

 この考え方はさらに過激な構想に向かう。上述のテーブルTが次図のようなテーブル関連をともなっているとしよう(下線は主キー)。

[A]、b、c


└─…[D]、a、e、f
    +
    |
    └─∈[T]d、t、XX単価、XX数量、(XX金額)、(e)、(b)

 この図では、テーブルT上に「導出属性」としてXX金額が置かれている。他にもテーブルDの項目eや、テーブルAの項目bが「継承属性」として置かれている(*1)。これは、アプリでテーブルTを利用する際にそれらの項目が問題にされ得ることを示している。これらの項目の扱いについては、テーブルの仕様の一環として記述されればよい。

 ここで、テーブルTの特定レコードを読み取ってパネル表示する「機能F」があるとして、その仕様書を想像してみよう。パネル上で、キーであるd、tの他に、XX単価、XX数量、XX金額、e、bを表示したいとする。上述したように、機能Fの仕様書にわざわざ「XX単価とXX数量を掛け合わせてXX金額とする」と書く必要はない。なぜならそれらはテーブルTの仕様書で既に述べられているからだ。

 同様に、継承属性である項目eやbについても、それらがどのように検索されるか(SQL文やテーブル関連に関する説明等)を、機能Fの仕様書に書き込む必要はない。なぜなら、それらについてはテーブルTの仕様として1回語られていれば済むからだ。それを個々のアプリの仕様書上で書いてしまうことは正規化違反である。いちいち書けば、重複して置かれた仕様の間で遅かれ早かれ矛盾が生じる。

 また、「テーブルTの更新にともなうデータ処理」についても同様である。たとえば、テーブルTの更新にともなって「在庫計上」が起こるとする。この場合、在庫更新が必要である旨やその手順については、テーブルTの仕様として書き込んでおけばよい。機能Fの仕様として位置づけてはいけない。

 この議論については補足が要りそうだ。テーブルTが機能Fだけによって更新されると考える限り、その理由は理解しにくい。しかしたとえばマルチデバイスなシステムにおいて、複数のクライアントアプリによってテーブルTが更新されることがあり得る。その際、それらのアプリの仕様書毎に在庫更新の云々を書き込むべきではない。いちいち書けば、重複して置かれた仕様の間で遅かれ早かれ矛盾が生じる。

 さらに、以前の記事でも取り上げたように、「どのアプリで扱われようが、数値がマイナスならば赤字で示す」といったルールも、データ項目自身の仕様として位置づけられるべきだ。アプリ毎にいちいち書けば、重複して置かれた仕様の間で遅かれ早かれ矛盾が生じる(ってしつこい)。

 このように正規化を徹底することで、どんなメリットがあるのだろう。まず容易に想像できるように、記述すべき仕様の総量が最小化される。とくに従来はアプリの仕様として取り扱われていた仕様要素の量が著しく減少するため、アプリが単純・小型化するとともに類型化される。結果的に、システム開発における仕様書作成の総コストが削減される。

 じつはその先に、さらに喜ばしい効果が待っている。ここまで配慮できれば、仕様書プログラミング(仕様書にもとづくプログラミング)を不要にするところまで、あと一歩なのだ。

 すなわち、テーブルとアプリの仕様書を、専用のCADツールやインタプリタによって可読な形に様式化する。するとテーブルとアプリの仕様を相互参照できるので、不整合の心配をせずにCADツール上で大胆に仕様変更できるようになる。そしてインタプリタを起動すれば、テーブルとアプリの仕様が直交的に統合され、最新仕様のアプリとして立ち上がる。この枠組みが、私の言う「仕様書駆動アーキテクチャ(SDA,Spec Driven Architecture)」で、その実装例が拙作のOSS基盤XEAD Driverである。

 正規化のノウハウを含むデータ指向アプローチ(DOA)を「RDBのテーブル設計のための知識体系」として理解しておくのは、間違いではないがもったいない。私はこれまで、その知識がNoSQLやシステム間インタフェースの設計等、さまざまな局面で役立つことを繰り返し経験してきた。そしてそれは「アーキテクチャの革新」にさえ役に立つ。ソフト技術者にとっての基礎的・汎用的スキルとして、データ指向アプローチを習得しておかない手はない。

*1.「導出属性」とは他の属性から計算できる項目のこと。「継承属性」とは多重度1の関連テーブル上に存在する項目のこと。通常の属性(固有属性)と区別するために、それらはカッコ付きで示してある。いずれも主キーに推移的に関数従属する属性ではあるが、固有属性と区別した形であえて載せることがある。


◆イベントのお知らせ
IT勉強宴会@名古屋2014/02/15(土)「ジェネレーティブ・プログラミングの世界」の中で、仕様書駆動アーキテクチャと、その上で実装された生産管理システムについて解説します。中京地区にお住まいの技術者の皆さま、ふるってご参加ください。

|

« 「仕様書プログラミング」とその運命 | トップページ | コンテキスト・ダイアグラムを描こう »

コメント

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: システムの仕様情報を正規化する:

« 「仕様書プログラミング」とその運命 | トップページ | コンテキスト・ダイアグラムを描こう »