anti-computer

　
　昨今、世上では、「DOA （Data-Oriented Approach、データ中心アプローチ）対 OO （Object-Oriented、オブジェクト指向）」ということが論点になっているそうです。DOA だとか OO だとか、というキーワードを使って議論すれば、無限後退に陥ることになるでしょう（笑）。なぜなら、DOA も OO も、「広義の」概念であって、DOA に限って言えば、「（アルゴリズムを考慮しないで）データの観点から構造を考える（データの独自性）」ということにしか過ぎないから。DOA といえば、ER 手法を思い浮かべますか、それとも、コッド正規形を思い浮かべますか。私は、コッド正規形を思い浮かべます。

　DOA として、ER 手法を思い浮かべるなら、OOA なり OOD が、（アルゴリズムを切り離して）モノの構造を考えれば、「外見上」、DOA も OO も相違点がないように見えるでしょうね。だから、（コンピュータ雑誌のなかで）「ER 手法は OO と同じである」とか「DOA は OO にふくまれる」などという「おおざっぱな（いいかげんな）」意見が出てくるのでしょう（苦笑）。

　OO は、タイプ理論（階の関係、クラス概念）を前提にして述語論理を使う手法です。DOA は、コッド正規形を例にすれば、述語論理とセット概念を使う手法です。クラス概念とセット概念は似ていますが--現象的にも、ほぼ、同じ構造に見えますが--、数学的に、定義が、全然、違う。A (u) を任意の集合論的論理式とすれば、{ u ｜ A (u) } は、ZF の公理系（セット概念）から得られない。{ u ｜ A (u) } を集合（セット）と区別して、クラス（class）と呼ぶ。セット概念では、述語に対して量化記号は付与されない。セット概念を扱う集合論が ZF の公理系であり、クラスを扱う集合論が BG の公理系である。したがって、それぞれ、べつの公理系です。セット・アット・ア・タイム法（RDB）は、ZF の公理系を前提にして、直積集合を使っています。

　[ 注意 ]
　ただし、ZF の公理系で証明される論理式は BG の公理系でも証明されるし、BG の公理系で証明される集合論的論理式は ZF でも証明できる。
　したがって、数学的に、セットもクラスも本質的には同じと観るか、あるいは、自己自身をメンバーとしないセット全体から構成されるセットはあり得ないが、そういうセット全体から構成されるクラスはあり得るので、セットとクラスは違うと判断するか（クラスは集合よりも大きいと判断するか）、、、。
　クラス概念が混迷した理由は、「クラス」が 2つの意味で使われているからである。1つは、概念の階層構造のなかで使われるクラス概念であり、もう 1つは、数学的な集合概念のなかで扱われるクラス概念である。
　「性質」と「クラス」の関係も、微妙な対応関係にある。数学的には、外延が同じモノの区別は論点にならないが、概念の階層構造のなかでは、「性質の帰属性（あるいは、非帰属性）」が論点になる。
　タイプ理論のタイプ [ W ∈ ｛W｝] が、概念の階層構造のなかで--概念の抽象化のなかで--「暗に」使われているが、この使用には、日常的な自然さある。というのは、（クワインによれば）「段階的構成の隠喩に合致しているからである」。階層の途中にでてくる・それぞれのモノをクラスといい、クラスには個体（instance）が属することになる。そう考えれば、メンバーが集合に属しているのと同じ関係になる。
　システム作りでは--RDB を前提にすれば--、設計手法として、ER 手法とセット・アット・ア・タイム法が使われているが、ER 手法のいう entity が、セット・アット・ア・タイム法（直積集合）のいう「関係（テーブル）」に対応するのか、という点は疑問である（この点が、「意味論」と「数理モデル」が不協和音を起こす点である）。
　なぜなら、直積集合では、そもそも、意味構造として「関数従属性」が論点になるが、ER 手法には、そういう考えはない。「意味」を記述する前提が、2つのやりかたでは、まったく、違う。

　DOA では--私は、DOA という言いかたが嫌いなのですが（笑）--、「data-independence」という（コッド博士が提示した）前提が、当初の起点だったのですが--コッド博士は DOA という言葉を使っていないのですが--、いつのまにか、論点がすり替えられて、ER 手法が DOA の front-end に出てきてしまった（苦笑）。論点がすり替えられた理由は、業務分析という段階では、「数理モデル」よりも「意味論」のほうが論点になるからです。私は「意味論」を信奉していない（笑）。なぜなら、それぞれの SE が、それぞれの意見を述べるに過ぎないから（シロートの喧嘩になるから--苦笑）。

　「整合的な公理系である」 DOA＋が「整合的な公理系である」 OO に比べて、「優れている」ということはない。どちらも正しいやりかたですから。
　1つの体系を検討するためには、以下の点を検証しなければならない。

　（1）理論的な構造
　　　　- 無矛盾性
　　　　- 完全性
　（2）技術的な構造
　　　　- 単純性
　　　　- 実効性

　DOA＋が整合的な公理系であれば、（1）を満たしているし、OO が整合的な公理系であれば、（1）を満たしています。とすれば--理論的に正しいなら--、手法が選択される理由は、単純性と実効性しかない。1つの論点に対して、理論的に正しい公理系が 2つあるのなら、単純なほうを選ぶ（あるいは、使いやすいほうを選ぶ）、というのが数学の考えかたです。以上の点を満たしている手法なら、DOA＋でも OO でも良い、ということです。

　DOA＋の公理系と OO の公理系では、最大の相違点は、タイプ理論を使うか使わないか、という点です。DOA の基点となったセット・アット・ア・タイム法は、（「セット」という呼称が記述しているように）タイプ理論を使わない。OO は、クラス概念を使うので、タイプ理論　（あるいは、「階」の構成）を前提にしています。

　数学者はクラス概念を使い、論理学者はセット概念を使う、という傾向があるそうです。
　（いまだ、「構造」が与えられていない）事象に対して、「構造」を考えるとなれば、クラス概念が役立つ。当初、1人の数学者の価値観を前提にして構成された「構造」は、「正確な」証明という検証を通過して、だれでもが「合意」できる「構造」として認知されます。証明というきびしい手続きを通過して、個人の価値観を回避します。
　クラス図が、証明に似た「合意」を得る手続きを提示しているなら、私は、クラス図を信用します。

　いっぽう、すでに、或る命題が主張されていて、その真偽を判断するなら--そして、命題論理ではなくて、述語論理を使っているなら--、セット概念（セットおよびサブセット）が役立つ。

　本ホームページのなかで、いくども言及していますが、Ｔ字形 ER手法は、公理系のなかに、以下の 2つを取り入れていない--意識的に排除しました。
　　（1）タイプ理論
　　（2）写像理論

　そして、「合意」の手段として、（語-言語のなかで使われている）「コード体系」を前提にして、命題論理を使った公理系になっています。
　命題論理は「主語-述語」の形式を単位とするので、主語間の関係を記述できない。そこで、「関係の論理」を記述するために、Ｔ字形 ER手法は、（「関数」ではなくて）主選言標準形を使った推論ルールを使っています。さらに、データの周延を検証するために、セット概念（セットとサブセット）を使っています。「認知」の方法として命題論理を使い、「検証」の方法としてセット概念を使っている、というのがＴ字形 ER手法の特徴です。

　したがって、厳密に言えば、Ｔ字形 ER手法は、「言語の形態論」としての手法であって、世間でいう「DOA」ではない、ということになるのかもしれないですね（笑）。
　Ｔ字形 ER手法は、企業のなかで使われている語-言語を解析して、データ正規形を生成しながら、事業解析およびアルゴリズムの I/O 化を同時に実現する手法であって、語-言語を前提にして「事実を記述する」手法です。したがって、私は、Ｔ字形 ER手法のことを「モデリングの技法」であるとは、金輪際、言ってこなかったし、そう言うつもりもない--たしかに、Ｔ字形 ER手法を使って作図された構造のなかでは、任意の文（あるいは、文の集合）は、推論の手順たるリレーションシップを辿れば、すべて、導出される（証明される）ので、「モデル」と呼んでも良いと思うのですが、私が最大の目的にした点は、データおよび関係の「認知」という点であって、「認知」が「合意」されていれば--そして、推論ルールに従って作図されたら--整合的である、ということにすぎない。

　　ただ、語-言語のコード体系という前提を外せば、Ｔ字形 ER手法のなかで使っている検証手段のセット概念をクラス概念に「読み替えることができる」（笑）。OO 派の人たちのなかで、Ｔ字形 ER手法のファンがいるそうですが、おそらく、OO 派の人たちのなかで、数学を熟知している人たちがいて、（「分出公理」の制限を外せば）セット概念もクラス概念も、「概念的な階層図を描いたら」、外見上は、ほぼ、同じになることを逆手にして、Ｔ字形 ER手法を「クラス生成の簡易手法」として使っているのでしょう（笑）。

　ただし、いわゆる「HDR-DTL （one-header-many-details）」を扱うときに、私が、どうして、それを「resource-対-event ＝複数-対-複数」の関係形態として扱わなかったのか、という点を考えていただきたい。
　述語論理を前提にしていれば、「HDR-DTL」は「resource-対-event ＝複数-対-複数」の関係形態として扱えば単純に対応できるのですが、どうして、私が、わざわざ、「モノ＝関係（関係が、そのまま、モノになる）」という記述にしたのか、という点を考えてみてください。セット概念の観点から判断すれば、「相違のサブセット」間のリレーションシップは奇妙に映るでしょうが、命題論理の観点に立って、タイプ理論を回避するためには、あれしかなかった。

　Ｔ字形 ER手法を「クラスの簡易生成手法」として使えば、かならず、（クラス概念では対象とならない）「対照表」と（クラス概念では、ほかの扱いかたとなる）「HDR-DTL」が、壁として立ちはだかるはずです（笑）。
　なぜなら、Ｔ字形ＥＲ手法は、OO とは違う数学の前提を使っているから。
　しかも、OO が前提にしているタイプ理論を使っていないから。

　
　[ 参考 ]
　DOA と OO との概念の対比が混迷した理由は、以下の歴史的な流れがあったからかもしれない。
　DOA は、「広義には」、「data-independence」の観点からデータ構造（データ正規形）を考えることを言っていたのですが、設計の段階が 2つに割れていて、概念設計と呼ばれる段階では、チェン ER や意味論データベース・モデル（SDM）が提示され、いっぽうで、コッドのセット理論（セット・アット・ア・タイム法）が提示されて、「意味論」と「数理モデル」の軋轢があったからでしょうね。セット・アット・ア・タイム法を実現したプロダクトとして RDB が導入されて、コッド正規形が中核を占めたのですが、直積集合を使ったセット・アット・ア・タイムは、属性値集合を起点にして tuple を生成するモデルを精確に示したけれど、事業のなかで実際に使われているデータを対象にしたら、「関係（テーブル、ファイル）」の順序対を配慮していなかった。いっぽうでは、チェン ER や SDM が、現実の世界を対象にしたら、モノとモノとの関係（チェン ER の relationship）やモノの構成（SDM の「is-a」関係、「part-of」関係、「instance-of」関係）に関して見通しが良かった。そのために、意味論と数理モデルの接続が論点になった。
　さらに、1995年あたりから、Java が出てきて、オブジェクト指向言語が front-end に出てきて、内部状態をもつオブジェクト概念（オブジェクトの集まりをクラスという）とメソッドが再考されたが--オブジェクト指向言語は1970年頃には出ていたし（SIMULA67）、1972年には、SmallTalk の第 1版が出て、1980年には、SmallTalk はオブジェクトやクラスを搭載した言語として整備されていたが--、1997年には、UML が提示され、概念設計の段階で、クラス図が、以前の意味論と対比されることになった。
　こうなったら、もう、三つ巴（DOA 系の概念設計手法 [ 意味論モデル ]、RDB 向けの設計論、オブジェクト指向の手法）ですね（笑）。
　ちなみに、私は、時代の流れのなかで、年齢的には、RDB を日本のなかに導入普及した張本人の 1人だったので、数理モデルと意味論を融合することに精一杯であって、オブジェクト主導の考えかたを、ほとんど、知らない。おそらく、この 3つのすべてに対して、同じような深い理解をしている人は--すべてのやりかたに関して、データ構造やアルゴリズムを実地に設計できる人は--、金輪際、いないのではないでしょうか。なぜなら、それぞれの専門家は、自らのやりかたを、事業のなかで使われている実際のデータを材料にして検証しながら、モデル（あるいは、仮説）を整えるのが精一杯でしょうから、ほかのやりかたを実地に検証する余裕がない。
　さて、これらの考えかたに関して、それぞれ、同じような深い理解を得るためには、いったい、どうしたら良いのでしょうか、、、「直感的には」、RDB を使ったウェッブのシステム作りなら、「DOA ＋ OOP」という接続が単純なソリューションだと思うのですが、なにせ、ER 概念とセット概念とオブジェクト概念（クラス概念）は、ズレがあるし、それらを、すべて、熟知している人もいないし、、、。
　さらに、やっかいな点は、それらの概念が対象としている事業の解析そのものがむずかしい（事業に関する知識を習得していなければならない）、という点です。ははは、システム・エンジニアは、超人であることを期待されているなのかなあ、、、。

　
　（2003年11月27日）