« クラス図とデータモデルはどうちがう? | トップページ | 業者の設計スキルをハダカにする »

2018.01.25

おそ松なデータベース

 既存システムの仕様を調べる時、似たようなテーブルがやたらとあって困惑することが少なくない。主キーが同じテーブルがいくつもあるのだが、それらがわざわざ分かれている理由がわからない。関係者に尋ねても、誰もその意図を説明できなかったりする。そのようなDBを「おそ松DB」と呼びたい。五つ子のようにそっくりなテーブルがゴロゴロしているからである。

 おそ松DBが生み出される理由は、じつははっきりしている。「危うい『プロセス指向』が廃れない理由」で説明したPOA(プロセス指向アプローチ)で設計されるからだ。POAではアプリ設計が先行し、そのアプリを動作させるためにテーブルが用意される。「アプリの適切な動作を支えるために、データ(ファイルやテーブル)がある」というシステム観だ。

 ただし、主キーが同じテーブルが複数あることそのものが悪いわけではない。同じ主キーを持つテーブルとして、ある種の属性群が切り出されることはある。たとえば生産管理システムにおいて「品目」に対して「製造品属性」と「購入品属性」と「販売品属性」の3つの「サブタイプ」を置くのはまともなやり方だ(図1)。品目が製造品である場合にだけ、それを製造するために管理すべき情報を別テーブルで保持する。この場合なら、主キーが品目IDであるようなテーブルが4つ置かれることになる。「四つ子」ということになるが、それぞれ明確な個性と存在意義を持っているので、分かれていることにきちんとした理由がある。

図1.スーパータイプとサブタイプの主キーは同一
Image180124

 いっぽうPOAで複数のテーブルが似たり寄ったりになるのは、そのように高尚な意図からではない。たとえばこんな調子で設計されるためだ。「タコヤキに対するA処理」が必要であることがわかったので、そのロジックやUIが検討され、その仕様に添うように「タコヤキAテーブル」が設計される。他に「タコヤキに対するB処理」が要ることもわかったので、その仕様と「タコヤキBテーブル」が設計される。その後に「タコヤキに対するC処理」が必要になったので、(たいていコピペで)「タコヤキCテーブル」が追加される。扱われるタコヤキ情報としては同一なので、切り出されるテーブル群の主キーは当然似てくる。

 結果的に、タコヤキ管理システムは図2のようになる。それぞれのアプリ毎に専用の出力テーブルが用意され、それらの間をタコヤキ情報がアプリを介して加工されつつ流れてゆく形だ。

図2.POAが生み出すタコヤキ管理システム
Image180124b

 POAはCOBOL時代に定着したレガシーな設計スタイルなのだが、今でも生き残っているどころがむしろ多勢である。ただし昔から「POAで設計しよう」と考える設計者がいたわけではない。もともと"POA"の呼称は、DOAの提唱者がそれまでのやり方を批判して言い始めた「蔑称」のようなものだった。ようするに芯のない「無手勝流」であって、何も考えないでシステム設計をやれば、自然におそ松くんの大行進になるという話なのである。今でもよく見られるのはそのためだ。

 換言すれば、POAは「アプリ=データ構造」の考え方で、その究極形が「Excel」である。アプリとデータ構造を分けて考える必要がないゆえに、Excelは素人でもとっつきやすいが、複雑なデータ構造を扱えない。非常に複雑なデータ構造を扱わざるを得ない業務システムについてはどうか。アプリとデータ構造とを分けて構想しなければ、システム仕様が無駄に複雑化する。そんな開発現場がプロ用のエンジニアリングツールを使わずに、素人が好むExcelで仕様管理しているのは偶然ではない。彼らもまた、アプリとデータ構造を分離して考えることができないのだろう。

 いっぽうのDOA(データ指向アプローチ)では、アプリとデータ構造は別問題として扱われる。まずタコヤキ情報を管理する必要があることがわかったなら、タコヤキ情報がデータモデリングされる(*1)。タコヤキを含めた広域のデータモデル(データ構造)が明らかになったら、必要な処理ロジックやUIを検討する。結果的にタコヤキ管理システムは、DBとして統合されたタコヤキ情報を核として、アプリがそれを囲むように配置される形をとる(図3)。システム全体のあり方は「扱われるデータの形」によって規定されることになる。

図3.DOAが生み出すタコヤキ管理システム
Image180124c

 手順としては、POAでは「どんなアプリやUIが必要か」の問いから始まるが、DOAでは「扱われるデータはどんな形をしているか」の問いから始まる。これだけの違いで、成果物は天と地ほどに違ってくる。たとえばPOAで設計されたDBには、DOAで設計した場合の3倍以上のテーブルが含まれていたりする。だからテーブル数が妙に多いだけで、おそ松DBであることを予想できたりする。

 では、なぜ我々はPOAではなくDOAで考えるべきなのか。コードを減らして開発・維持コストを削減するためだ。システムの開発・維持コストの大部分は、人間様がプログラムを読んだり書いたりするための手間で占められている。また、プログラムが多いほどシステム全体の保守性や可読性が低下する。無駄にテーブルが分かれていたりすれば、オンライン系がシンプルに済んだとしても、テーブル間の整合性を維持するためのロジックが複雑化する。とくにデータ量が多い場合には、バッチ処理系の保守や実行に時間がかかって運用の足を引っ張る。けっきょくアプリ毎に安直にテーブルを増やしてゆくやり方では、別の何かにしわ寄せしながら、先送りにされる問題をいたずらに増やすだけなのだ。

 いっぽうDOAでDB設計すれば、業務要件の多くの部分がアプリ仕様ではなくデータ構造に変換される。これにともなって仕様の配置様式が最適化され、プログラミングされる要素が減る。同時にデータ構造が形式化されるため、複雑なロジックを持つアプリも作りやすいし、なにより作成を自動化しやすい。誰も見たことのない先鋭的なソフトウエアを生み出すためであれば、丁寧にプログラミングするやり方がベストであることは間違いない。しかし、DBを核とする業務システムのような、カテゴリーとして成熟したソフトウエアを生み出すには、要件をさまざまに形式化することでプログラミングを大幅に省力化できる。われわれがITのパワーを活用して開発業務を合理化するためにはまさにそういった工夫が必要で、DOAはそのための鍵だ。

 それほど良いやり方なのであれば、業界が一丸となってDOAでやればよさそうなものだが、そうは問屋がおろさない。POAは開発態勢を、プランテーションにおける綿花栽培のような労働集約型にしてしまう。それゆえ、工数商売を旨とするベンダーにとってPOAは「事業の中核テクノロジー」である。じっさい彼らにとっておそ松(お粗末)DBやExcel仕様書は、「過剰な工数」という金の卵を産み続けるガチョウであって、どんなに批判されても手放せない。それでワリを食うのは、過剰なコストを払わされる顧客と、非効率を強制されることで年々無能化してゆく技術者たちだ。


*1.データモデルの作成が標準化されているとしても、その開発現場がDOAを実践しているとは限らない。「クラス図とデータモデルはどうちがう?」で書いたように、クラス図がデータモデルとして提出されていたりするからだ。また、そもそも適切にデータモデリングするには訓練も適性も要るからだ。とはいえデータモデルを見れば、DBがDOA的発想で設計されたかどうかはわかる。「おそ松DB」だったりすれば、もう気の毒なくらいにバレバレになる。

|

« クラス図とデータモデルはどうちがう? | トップページ | 業者の設計スキルをハダカにする »

コメント

御意。今携わっている案件はまさにそれです。(ウハウハ)

投稿: TOM | 2018.01.26 10:23

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: おそ松なデータベース:

« クラス図とデータモデルはどうちがう? | トップページ | 業者の設計スキルをハダカにする »