当時 （1980年代） は、まさに、リレーショナル・データベース が マーケット に現れてきた時代で、システム の生産性・保守性を向上するために、（コッド 関係 モデル の示した） 「データ 正規形」 が謳われていた時代でした。実務上、「one fact, one place」 が呪文のように唱えられました。データ の重複を排除して、「minimal cover （必要最小限の データ 量）」 で 「安定した （stable）」 データ 構造を作ることが、データベース 設計の目的とされました。_{（参考 2）}その時流の起点になった コッド 関係 モデル は、1970年代に、公表されていました。その モデル が実地に導入されるようになったのが 1980年代でした。当時、私は、日本に、リレーショナル・データベース を導入・普及する仕事をしていました。そして、コッド 関係 モデル の宣教をしていました。

　当時から すでに 20数年の時が進みました。その 20数年のあいだ、コッド 関係 モデル を実地に適用してきて、われわれが直面した問題点は、「データ 正規形」 そのものを作ることではなくて──勿論、「データ 正規形」 を作ることは絶対の前提なのですが、「データ 正規形」 を作ることは、モデル を学習すれば、さほど難しい作業ではないのであって──、データ のあいだに生じている 「制約・束縛」 を網羅して記述するという点でした。データ 間の 「制約・束縛」 を網羅的に検証する手続きを示した データ・モデル を私は いまだかつて 知らない。でも、データ 間の 「制約・束縛」 を網羅的に記述することは、実地の システム 作りでは、生命線です。だから、私は、「箱と線」 で描いた大雑把な データ 構成図など信用していないし、トップダウン 手法で システム を作ることができるなどと思ってもいない。数十年を費やして整えられてきた──そして、環境に適応するように、つねに、修正されて続けている──事業過程・管理過程のなかで、神経網のように張りめぐらされている 「データ 間の制約・束縛」 を網羅的に記述することは至難の ワザ です。ただ、その至難の ワザ を われわれ システム・エンジニア は実現しなければならない。そうしなければ、システム が 「信用できる情報」 を生成できないから。

　データ 正規形を作ることは、あくまで前提であって、最終目的ではない。データ 正規形──あるいは、無矛盾な 「形式的構成」 と云っても良いでしょうが──を作る目的は、データ のあいだに成立している 「制約・束縛」 を検証する点にある （あるいは、逆に、「成立していない」 ことをも明らかに検証できる点にある） ということに対して、われわれは、もっと注意を払うべきでしょう。

　
（参考 1）
「バベル の塔」 は、旧約聖書の創世記 第 11章に現れる巨塔です。人びとが天にも届く塔を建てようとしたので、神が人間の高慢さに怒って、言語を混乱させて、塔の完成を妨げた、という話です。

（参考 2）
日本では、データベース 設計を重視して、「データ が一次的であって、プログラム は二次的である」 と考えている考えかたを 「DOA （Data-Oriented Approach」 と言ってきました。欧米では、そういう言いかたはない──欧米では、ジェームス・マーチン 氏が唱えた 「Information Engineering」 という言いかたが使われています。

　さて、私は、世間では、いわゆる 「DOA」 の本山のひとつに みなされているようです。たしかに、1980年代、私は、いわゆる 「DOA」 に属していました。しかし、1990年代の後半から、私の考えかたは変わってきて、私は 「モデル・言語・意味」 という テーマ を追究するようになって、いわゆる 「DOA」 とは違う路線を歩んできました。そのとき以来、私の学習対象は、数学基礎論・言語哲学のほうに向かっています。私は、プログラミング の技術を直接に研究対象にしていないという意味では、プログラミング・パラダイム で仕事していないのですが、そうかといって、「DOA」 の流派であるというふうに見られることに対して、若干の抵抗感を覚えています。私の今の関心事は、事業過程・管理過程のなかで使われている 「情報」 の 「意味」 解析にあるのであって、データベース 設計そのものには、昔 抱いていたほどの興味がない──勿論、データベース 設計は、いまでも、仕事の いちぶにしていますが。
　私の今の仕事を一言で言えば、「論理的意味論」 の追究にある、と言っても良いかもしれない。

　
　（2008年 7月16日）