2019年 2月15日 | 「1.5 『意味および意義』 ならびに 『真』」 を読む | >> 目次に もどる |
本節では、モデル 技術において、「意味」 とか 「意義」 という概念よりも 「真」 という概念が大事であることを述べています。その理由は、構文論 (記号演算) に対して正当な注意を払うためです。一言でいえば、分析・設計を 「科学」 として扱うためです。 私は、ひょんなことから 30数年前に 日本に RDB を導入普及する仕事に就きました──日本には RDB の先例がなかったので、米国で RDB の理論・技術を学びました。RDB の データ 設計法として、コッド 関係 モデル を学んで (データベース 技術といっしょに) 日本に導入普及しました。コッド 正規形は今では当たり前の技術になりましたが、当時は 「新しい」 技術でした──コッド 博士の難解な論文を読んで、その論文で述べられている技術を実務上 簡単に使うことができるように翻訳することは一苦労でした。コッド 関係 モデル の最大の貢献は、「設計を科学にした」 ことです。それ以前では、データ 設計は、SE の 「経験」 に依ること大でした。 コッド 正規形は、数学を根柢にした技術です。したがって、数学を正規に学習していない SE が コッド 論文を読んでも皆目わからないか、あるいは論文に述べられている細かな点を間違って習得してしまうでしょうね──英語の論文を日本語に翻訳して読むことができたからといって、わかったつもりになってしまう危険性が高い。コッド 論文では、普通の英文 (論理式が示されていない自然言語の英文) の ウラ には相当な数学的知識が前提となっています (ちなみに、コッド 博士は数学者です)。 私は、コッド 正規形を 当時 日本に普及した面々のなかの一人でしたが、実務上 使用するにあたって 「或る違和感」 を覚えていました。その違和感とは、コッド 正規形が これほどすばらしい モデル にもかかわらず、どうして データ 設計のみに適用されて 事業分析の領域までを その範囲に入れることをしなかったのか、と怪訝に思った点でした。モデル であれば、当然ながら、現実的事態を形式的 [ つまり、論理的 ] に写像した構成物でなので、事業分析にも使うことができるはずのものです。しかし、コッド 正規形は データ 設計として使われて、事業分析では、当時、ER 図法 (Entity-Relationship Diagram、P. チェン 氏の提唱) が使われていました。P. チェン 氏は、ER 法を 「意味論 (semanntics)」 のための技術だと述べていました。そして、彼が言うには、ER 法を使って現実世界の 「モノ とそれらの関連」 を描いて、それから コッド 正規形を作ればいい、と。その やりかた が 当時 流行って、構文論の先に意味論が重視されるという悪弊が蔓延しました (私は、それを 「悪弊」 と敢えて言っておきます)。 私は意味論重視を嫌悪しています。我々 システム・エンジニア の仕事は 「事業を プログラミング する」 ことです。その仕事を 「科学」 にするには、(データ 設計のみならず) 「分析」 も 「科学」 でなければならないはずです。「科学」 としての手順を踏むのであれば、当然ながら、構文論が先で意味論は後です。そうするためには、コッド 関係 モデル を拡張して (データ 設計のみならず) 事業分析にも適用できるようにしたいというのが私の狙いでした。そして、その成果としてできあがったのが TM です。 「意味」 とか 「意義」 という概念を重視していては、構文論を意味論の先に持ってくることができない。構文論を先にするためには、「真」 という概念を どうしても モデル の中核に置かなければならない。そのために、「意味」「意義」 という概念を 「真」 概念に移行しなければならないので、次の四人の研究成果を検討して、「真」 概念を中核にして モデル 技術 (TM) を作った次第です──
(1) フレーゲ 氏の 「意味と意義」 そして、最終的に次の手順を前提にして TM を整えました。 「合意」された語彙 (モノ の記号化)→ 「L-真」 の構成 (構文論)→ 「F-真」 の文 (意味論)。
詳細については 「いざない」 を読んでください。 |
<< もどる | HOME | すすむ >> | |
目次にもどる |