|
2007年 8月 1日 |
特論-14 Ｔ字形 ER手法 （その 4） [ 「論考」 の流用 ] |
|
|
2012年 7月 1日 補遺 |
|
|
|
本節の副題が 「『論理哲学論考』 の流用」 となっているように、TM （Ｔ字形 ER手法） は、ウィトゲンシュタイン 作 「論理哲学論考」 を底本にして作られました。「論理哲学論考」 の考えかたを TM のなかで どのようにして使ったか という点については、特論-11 「理論的な根拠」 および特論-12 「対照表の根拠」 のなかで綴りました。本節は、それらの節を、べつの観点から まとめた最終節です。「べつの観点から まとめた」 というのは、以下の 「問題意識」 に沿って まとめたということです。 「モデル として、現実の事態を、いかにして、コンピュータ のなかに記述するか」 私
（佐藤正美） は、SDLC
（System
Development Life Cycle、具体的には、工程を分析・設計・製造・保守として考える）
を納得していますが、SDLC
を実現する
やりかた として ウォータフォール （waterfall）
式を認めてはいません。そして、ウォータフォール 式の アンチテーゼ
として、SDI/RAD
を作りました。 （1）
集合 A
と集合
B
は、べつべつの集合である。 オノマシオロジー （あるいは、記述的意味論） の立場にたつひとは、「事業過程 （購買過程・生産過程・販売過程・労務過程・財務過程などの実際の作業工程）」 そのものを分析対象にして、（2） を主張するでしょうね。もし、そうするのであれば、「事業過程」 そのものを分析した アウトプット を、（事業過程を管理している）「管理過程 （購買管理・生産管理・販売管理・労務管理・財務管理などの管理工程）」 の構造と対比して、管理過程から乖離している事業上の手続きの妥当性を検討して、管理過程の効率性・効果性を吟味しなければならないでしょう。そして、それをやるためには、当然ながら、管理過程の構造も正確に記述されていなければならないでしょう。というのは、被定義語 （事業過程） と定義語 （管理過程） の 2つとも理解されていなければ、対比はできないから。そして、1つの 「構造」 は 「個体と関係」 で記述されるならば、事業過程を記述するには、事業過程のなかで 「個体」 として認知されるのは、どういう対象なのかの判断規準がなければならないでしょうし、はたして、事業過程を対象にして、（事業過程のなかで仕事している人たちが合意している） 「『すべての』 個体」 を捕捉することができるのかしら。 事業過程に対しては管理過程という モデル が、すでに、存在しています。すなわち、「計画・管理」 は、現実の事態 （事業過程） に先行していると言って良いでしょう。事業過程と管理過程のあいだに、すでに、「なんらかの」 関係が生じているのであれば、（オノマシオロジー ではなくて、） セマシオロジー （あるいは、論理的意味論） の やりかた のほうが効率的でしょう。つまり、管理過程に対して 「構造」 を与えて、その 「構造」 と現実事態 （事業過程） との指示関係を調べるほうが効率的でしょう。 私は、セマシオロジー
の観点から TM
を作りました。すなわち、管理過程のなかで使われている語-言語を対象にして
「意味の構造」 を、まず、作って、現実事態との指示関係を調べるという
やりかた を私はTM
として採用しました。したがって、私は、論理設計を
データ 設計の中核にして、概念設計を認めていない。 3・1432 3・144 TM は、当初、ウィトゲンシュタイン 作 「論理哲学論考」 を底本にして、（主選言標準形を正規形にして、） 真理値表を 「関係」 の記述として考えました。しかし、管理過程のなかで使われている語-言語のなかに、コード 体系が導入されていて、「事態 （TM でいう 『event』）」 も語-言語で指示されています。そのために、「個体 （TM でいう 『resource』）」 のあいだに生じる 「関係」 を真理値表で記述しても--たとえば、個体 a （resource） と個体 b （resource） が組になって関係 R （event） を対照表として記述しても--、それらの個体 （resource） が作る事態 （event） を、たとえ、事態に対して個体指示子 （認知番号） が付与されているとしても--言い換えれば、「モノ （個体） と関係は同一 レベル にある」 としても--、真理値表のなかで、「個体 （resource）」 と 「関係 （event）」 を同列に記述することはできない。なぜなら、事態の真・偽には個体の真・偽が前提とされるから。そのために、TM は、「関係文法」 として、ホワイトヘッド が示した個体概念を援用しました。そして、ホワイトヘッド の個体概念を基礎にして、「個体 （resource） が事態 （event） に関与する [ ingression ]」 という 「関係文法」 を作って、個体どうしの関係は真理値表で示し、個体と事態とのあいだは、事態のなかに個体が侵入するという構成にしました。 TM は、語-言語 （しかも、自然言語） を材料にして 「意味の構造」 を記述するので、「合意」 とか 「文法」 を重視していますが--これを正当化条件と言って良いでしょう--、「指示」 を排除している訳ではない--真理条件を排除している訳ではない。セマシオロジー に立っている TM は、論理的意味論の手法ですから、真理条件として、カルナップ の示した 「事実的な F-真、導出的な L-真」 概念を導入しました。 以上のようにして、TM を整えてきたのですが、TM のなかで唯一説明できない事態が 「one-header-many-details （以下、HDR-DTL）」 でした。単純な多値関数であれば--それが、OR 関係であれ、AND 関係であれ--、TM の関係文法のなかで多値を除去することはできるのですが、HDR-DTL は、多値関数であり、かつ、合成関数 （関数の関数） という現象なので、「モノ （個体） と関係は同一 レベル にある」 という前提から導かれない現象です。この点に関しては、特論-13 「その 3 [ 限界 ]」 のなかで記述したので、参照して下さい。 なお、TM は、2値 ロジック を前提にしているので、null を認めていない点を強調しておきます。null に対しては、4値 ロジック （コッド 関係 モデル） か 2値 ロジック （TM） を使うべきであって、3値 ロジック を使うのは危険です。たとえば、「p ⇒ q （p ならば q）」 は、「¬p ∨ q」 と同値ですが、もし、p として null を使えば、3値 ロジック では、¬p は null とされています。プロダクト としての RDB は、4値 ロジック を導入しないで、null を認めているので、3値 ロジック を導入していると思って良いでしょう。とすれば、null を、できうるかぎり、使わないようにするのが 「データ 設計の鉄則」 です。 |
|
[ 補遺 ] （2012年 7月 1日） 本文には説明の足らない箇所が幾つか存しますが、全体を通して TM の考えかたを把握できるように綴られてるので、補足説明を取り立てて入れる事もないでしょう。TM を一言でいえば、「論理的意味論」 の技術だと思って間違いない。その考えかたは、「真理値表 （主選言形式 (「関係」 の論理的可能性)） → 「合意」 された概念 （ユーザ 言語の観察述語 (主題＋条件）） → L-真・F-真の導入」 というふうに拡充されて来ました。 |
|
|
|||
|
|
|||