« 「XEADインテグレータ」の開発 | トップページ | 高い心肺能力でもカゼ »

2007.02.24

内部記述から外部記述へ

 昔話だが、システム設計のヒントになると思うので書いてみる。筆者はIBMのAS400で育った技術者である。今では関わる機会がとんと減ったが、データベースシステム開発のノウハウを得るために、AS400とその系列マシンは素晴らしいインフラであったとしみじみ思う。OSと一体になったDBMSの安定度や使いやすさはピカイチだった。コンピュータ上の諸問題よりも業務上の諸問題により注意を向けられる、ユーザーにも開発者にも優しい環境だった。

 AS400はS/38(システム38。サンパチと呼ばれていた)の後継機である。そして、S/38にはS/36(システム36。サブロク)という"兄弟機"があった。"兄弟機"と呼んだのは両機が併行して活躍した時代が長かったからなのだが、それでも、後発のS/38は多くの点で優れていた。

 S/38はメモリ空間とディスク空間が論理的に一体になっているという、80年代のマシンらしからぬ先進的なアーキテクチャを備えていた。そして、このマシンが登場したときの謳い文句のひとつが「外部記述」だった。そのとき突然、S/36を使っていた開発者たちは、自分たちがそれまで「内部記述」という特殊な枠組みでプログラミングしていたことに気づかされたのである。

■「内部記述」の問題

 つまり、S/36を使う開発者は、プログラムの「内部」でテーブル(AS400系のマシンでは「ファイル」と呼ばれる)の様式を記述する必要があった。たとえば、商品テーブルのレコード長は200桁でその12桁目から64桁目を「商品名」とするといった調子で、データ処理に必要なフィールドをプログラム上で定義するのである。

 筆者はプログラマとして、この方式を嫌いなわけではなかった。たとえば、フィールドの値をコピーするときに、コピー対象となるフィールド群を含む長いセグメントとして定義してコピー先に移送するようなことをする。プログラマがレコード上のフィールドを自由に切り出せたので、うまく使えば素晴らしくシンプルにコーディングできた。じっさい今でも「S/36でのプログラミングは楽しかった」と懐かしがる人がいるほどだ。

 しかし、この方式は長い目で見るといろいろと弊害があった。

 まず、テーブルの仕様変更にともなう手間が大きい。何かの事情でテーブルのフィールド構成が変わると、そのテーブルを利用するすべてのプログラム中のテーブル定義をいちいち変更しなければいけない。たとえば上述の「商品名」が10桁伸びたとすると、関連するすべてのプログラムの商品名の切り出し位置について、12桁目から74桁目に変更するだけでなく、それ以降のフィールド定義の位置も丁寧に10ずつずらしてやる必要がある。

 ずらすやり方を取る代わりに、テーブル上に「フィラー(FILLER)」と呼ばれる100桁くらいの空白セグメントをあらかじめ用意しておくテクニックもよく使われた。たとえば、商品名の伸びた分の10桁を「フィラー」上に「商品名2」などとして組み込むことにして、これをもともとの商品名と結合したうえで使うのである。チマチマと項目の桁位置をずらすよりはマシでも、面倒なことに変わりはないし、どっちにしてもカッコ悪すぎる。

 2つ目の問題として、上記と関連するが、テーブル定義がプログラム毎に矛盾し得る点が挙げられる。あるプログラムでは52桁の商品名が、別のプログラムでは62桁として定義されていたとしても、DBMSは何も警告してくれない。もちろん、テーブルの仕様変更のたびに上述の手順をしっかり踏んでおけばそのような問題は起こらないのだが、いろいろな理由から不整合が生じてバグの温床となった。

■「外部記述」の革新性

 こういった悩みを解決したのが「外部記述」だった。外部記述方式において、フィールド定義は個々のプログラムの内部ではなく、データベース自身が保持するテーブル管理情報の一部とされた。つまり、フィールド定義が「プログラムの中に個別に記述される時代」から「プログラムの外に一元的に記述される時代」が始まったのである。

 要するに、データ項目定義の置き場が個々プログラムからテーブルへ移っただけのことだ。考えてみれば、フィールド定義がデータベース上で一元的に管理されるというのはまっとうな話で、データ項目定義が本来の場所に「正規化」されただけの話と言っていい。しかし、インパクトは大きかった。意識レベルの変化としてとくに重要だったのが「テーブル定義はプログラムの仕様と独立して成立する」というDOA的な認識だった。

 それまでも、S/36のプログラマたちは「ファイル定義書」などと呼ばれるテーブルのフィールド構成を記した膨大な紙の資料を、プログラム仕様書とは別に維持してはいた。しかし、いかんせん「紙」なので、それをファイルの一元的な定義と認めるには無理があった。紙の資料に連綿と鉛筆で書き込まれていた定義情報がデジタル化されてテーブルオブジェクトと一体になったときに、「テーブル定義はプログラムの仕様と独立して成立する」の認識は本来的に正しい、進むべき方向としてオーソライズされたのである。

 「外部記述」のデータベースを搭載していたS/38は、80年代末にAS400として生まれ変わる。同じ頃に筆者は、AS400の上で稼働するCASEツールを使って開発するようになった。そのツールがまた、さらに徹底した外部記述的な枠組みを備えていた。

 まず、フィールド毎の妥当性検査までがテーブル定義の一部として取り込まれた。イントラネットのアプリからアクセスされようが、社外のWEBブラウザからアクセスされようが、DBMS自身が更新要求を受け取って、テーブル定義中の検査ロジックにもとづいてエラーメッセージを返すなり、要求を受け入れるなりできるようになったのである。さらに、トリガーファンクションをテーブルに貼り付けられるようになったし、テーブル上の数量項目を多重度1のテーブルに対して自動的に集計できるようになったし、「導出属性」を仮想フィールドという名前でテーブル上に置けるようにもなった。

 このように、筆者が関わるデータベースは外部記述を充実させる方向に、絵に描いたように発展していった。「内部記述」の時代には、システムの仕様は基本的にプログラムの中に記述されていた。データベースは「プログラム同士が連係する過程で処理結果を一時的、または永続的に保存する場所」でしかなかった。ところが「外部記述」の時代になると、データベースこそがシステムの仕様を理解する出発点となった。イエス・キリストは「カエサルのものはカエサルに返しなさい」と言ったが、筆者が関わるデータベースはことごとく「データの仕様はデータベースに返しなさい」と要求し続けたのである。

 この経験が、筆者のDOA的システム観を決定づけた。データの仕様を限りなくデータベース側に凝集させる。そのためには、その土台としてスタティックなデータ構造を押さえることが先決である。データベース設計の重要性に気づくのは時間の問題だった。

|

« 「XEADインテグレータ」の開発 | トップページ | 高い心肺能力でもカゼ »

コメント

 すごいカルチャーショックがあったのが良くわかりました。

 データベースが処理の結果を格納するものではなく、業務そのものであると認識された原体験ですね。プログラムとはデータベースを正しくする(整合性をとる)ためだけにあると認識した瞬間、パラダイムシフトが起こります。

 それを経験しないと本当の設計は出来ないのですが、一度経験してしまうと当たり前になり回りに伝えるのは難しいです。

投稿: HAT | 2007.02.24 15:26

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: 内部記述から外部記述へ:

« 「XEADインテグレータ」の開発 | トップページ | 高い心肺能力でもカゼ »