2008年 9月 1日 「技術編-11 データ の関係」 を読む >> 目次にもどる
2014年11月01日 補遺  


 

 「Event」 概念と 「resource」 概念は、TM の最大特徴点ですが、個体に関する哲学──すなわち、実体主義と関係主義──の結節点にもなっていることが最近 (ここ一年) になって わかってきました。

 実体主義は、個体を一次的とみなして、関係は個体のあいだに成立する二次的な概念とする考えかたです。関係主義は、関係が一次的で個体は関係のなかの変項であるとする考えかたです。それぞれの考えには、一長一短があります──実体主義は、個体を認知するという点では われわれの ふだんの思考に合致する長所をもつのですが、いっぽうで、個体を 「(厳正に) 定義する」 ことができないという弱点があるし、関係主義は、個体を定義するという無限後退を免れて、なんらかの モデル を作りやすいのですが、いっぽうで、個体が すべて 「並べられる」 という前提が実際の適用では やや 難点になるでしょう。

 TM は、基本的に、関係主義に立っています。すなわち、関係を 「直積集合」 の部分集合として考えて、モデル を作るときに、関数を前提にしています。関係を数学的な式で示せば以下のとおりです。

    R { s1 ∈ X1, s2 ∈ X2,・・・, sn ∈ Xn ∧ P (s1, s2,・・・, sn) }.

 X1, X2, ・・・, Xn が集合 (セット) で、s1, s2, ・・・, sn が、それぞれの集合の元です。すなわち、「空でない」 集合から それぞれ 元を ひとつずつ選んできて 「並べたら」 ひとつの集合 (タプル) になるという考えかたです──集合論の 「ZF の公理系」 のなかで示された集合です。このときに s1, s2, ・・・, sn という項は、X1, X2, ・・・, Xn が集合 (セット) の元であって、集合は f (x) という性質を内包にして作られた外延であって、直積のなかでは、「主体 (subject)」 あるいは 「できごと」 という相違点を重視されない。言い換えれば、s1, s2, ・・・, sn に対して entity という一般語を使ったときに、それらの entity が主体か事態かを重視しない──ただし、「ER (Entity-Relationship)」 モデル では、s1, s2, ・・・, sn を、「主体型 entity」 あるいは 「関連型 entity」 というふうに分けているようです。

 TM は、コッド 関係 モデル に対して──コッド 関係 モデル は 「直積」 を前提にした モデル ですが──意味論を 「強く」 意識した モデル なので、上述した式を前提にしています。ただ、「直積」 のなかの項が すべて 「並べられる」 という前提に対して、外点・特徴関数・閉包の観点から判断して、( ER モデル が entity を 「主体型 entity」 あるいは 「関連型 entity」 に分けたように、) 項を ふたつの クラス に分けたほうが良いと判断しました。というのは、TM では、entity を以下のように定義しています──ちなみに、ER モデル では、entity は定義されていない (というよりも、ふつうの文脈では、entity を定義することはできないでしょうね)。

    Entity である = Df 個体指定子が付与されている管理対象である。

    Event である = Df 性質として 「日付」 が帰属する entity である。

    Resource である = Df Event 以外の entity である。

 TM が entity を定義できた理由は、事業過程・管理過程のなかで伝達されている 「情報」 には、管理対象に対して管理番号を付与しているという事実があったからです──たとえば、「商品番号」 を個体指定子にして 「商品」 を認知するとか。

 事業過程は、一連の できごと (行為) の順列であると言っていいでしょう。すなわち、できごと は 「日付」 を軸にして 「並べる」 ことができる先行・後続関係を示します── R ( c1, c2,・・・, cn ).

 そして、それらの できごと に対して、主体が関与します── R { s, c }.
 そこで、できごと の構成に対して、主体を外点として特徴関数を作ろうとしても── R ( c1, c2,・・・, cn ∨ s1 ) を考えても──主体を事態 (できごと) と同列に並べる特徴関数を作れないでしょう。したがって、主体と事態 (できごと) は べつの関数を考えたほうがいいと判断した次第です。

 ところが、主体どうしのあいだで起こる関係──すなわち、2項関係──が、実体主義的な観点に立てば、3項態を作ることがあります。たとえば、{ 従業員, 部門 } という 2項関係が 3項態として 「配属」 という 「意味」 をもつということです。集合論的に言えば、ふたつの集合を前提にして、それらの和集合を作って、その和集合が f (x) という特徴を示せば、和集合は ひとつの集合として存在すると考えることができます。もし、その和集合の特徴として、「日付」 を付与できれば、ふたつの主体の関係は できごと として考えることができる、ということになります。

 R ( c1, c2,・・・, cn ) と R { s1, s2 } と R { s, c } が、どうも、実体主義と関係主義の はざまで グレーゾーン になっているように私には思われます。もし、私が正しければ、直積の 「並び」 に上手に対応するためには、そして、意味論を 「強く」 適用するのであれば、事業過程・管理過程を対象にして モデル を作るのなら、モデル の関係文法は、直積を一律に適用しないで、いくつかの文法で構成したほうがいいでしょう。その 「いくつかの関係文法」 を TM は、以下のように示しました。

    aRb において、

    1. a ≠ b (ふたつの集合のあいだでは)

    (1) event-対-resource の関係

    (2) event-対-event の関係

    (3) resource-対-resource の関係

    2. a = b (ひとつの集合のなかの元を並べる)

 
 この文法で構成される 「event」 あるいは 「対照表 (ふたつの resource が構成する事態)」 は、つねに、以下の 「T-文」 で 「F-真」 を判断します。

     言明 p が真であるのは、時刻 t において、事態 q と対応するとき、そして、そのときに限る。

 



[ 補遺 ] (2014年11月01日)

論点は、「主題」 (entity) を如何に並べれば、事業構造──そして、その意味──が掴めるかという点です。Event は時系列 (日付の大小関係) で並べる事ができますが、event に関与する resource は全順序に並べる事ができない [ 半順序です、しかも、もし五十音順にならべても、さして意味を成さない ]。

事業に関与する人々が伝達している 「情報」 のなかに、すでに { event、resource } の関連が記載されているので、記号演算では、それを前提として正規形を作ればよい、というのが コッド 関係 モデル の考えかたです──例えば、受注情報を記号列として考えて、{ 受注番号、顧客番号、商品番号、受注日、受注数 } の記号列を直積集合 (数学上の 「関係」) とみなして、正規形を作る。もし、商品が 1つの受注で複数を注文できるのであれば、多値関数なので、商品を次のように べつの tuple にするでしょう。

 { 受注番号、顧客番号、受注日 }.
 { 受注番号、商品番号、受注数 }.

その他にも、第二正規形・第三正規形があるのですが、割愛します。
コッド 関係 モデル は、完備性 (relational completeness) が証明されています。

しかし、この モデル に意味論を強く適用して、構文論 (記号演算) のあとで、「現実的事態」 との一致を考えるのであれば──言い換えれば、事業構造を究明するのであれば──、entity のあいだの 「関連 (日常語の 「関係」)」 を吟味すべきではないか。その考えかた (「関連」 の究明) を前提にして、なるべく数学的な技術を導入しようと試みたのが TM です。そのために、TM では、モノ を定義しなければならないという難問にぶつかりました。関係主義では、「関係」 が一義であって、モノ は変項にすぎない [ モノ は無定義語です ]。そのために、TM は、モノ (entity) を次の様に定義しています。

 Entity である =DF 個体指示子が付与された対象である。

Entity を 「主題」 と云ってもいいでしょう。そして、ひとつの 「主題」 は、いくつかの 「条件」 で構成されます。

 { 主題、条件1、・・・、条件n }.

こういう考えかたを前提にすれば、例えば 「従業員」 という主題には、部門 コード は関与しない。

 { 従業員番号、従業員名称、・・・ }.
 { 部門 コード、部門名称、・・・ }.

従業員と部門との 「関連」 は、「配属」 という event (技術的には、「対照表 (写像集合)」 を使って構成されます。
さらに、「受注」 には、entity として認知する時には、顧客番号も商品番号も関与しない。

 { 受注番号、受注日、受注数 }.

どの顧客から、どの商品が注文されたかは、「関連」 で示されることになります。

 { 顧客番号、顧客名称、・・・ }.
 { 商品番号、商品名称、・・・ }.
 { 受注番号、顧客番号 (R)、商品番号 (R)、受注日、受注数 }.

コッド 関係 モデル は a tuple を バラ してゆく やりかた ですが、TM は entity のあいだの 「関連」 を構成してゆく やりかた です。そのために、TM では、「関連」 を構成する文法を用意しなければならなかったのです──それが、{ event 対 resource } { event 対 event } { resource 対 resource } と 「再帰」 です。そして、「関連」 が構成されたあとで、「集合」 を吟味するという手続きになった次第です。しかも、「集合」 を吟味する時に、「現実」 との一致を考慮すれば、「集合」 (セット) のほかに クラス 概念を導入したほうが、「現実」 の構造が掴みやすいので、TM では、セット のほかに クラス を使っています。つまり、TM では、「関連」 を構成する文法を主体としたがために、モノ を次の 3つで記述するという体系になりました。

 意味論 (entity) → 構文論 (セット) → 意味論 (クラス)

Entity そのものを TM は重視している訳ではない──そのために、かつて 「T字形 ER法」 と名付けていた体系を TM と改名しました。Entity は、「集合」 を作るための前形です。そのために、TM は次の体系となっています。

 1. 主題と条件
 2. 関係 R と関数 f (主題の「並び」)
 3. 関係文法 (「関連」 の構成)
 4. 集合 (セット)
 5. 多値関数
 6. クラス

1. と 2. は、モデル を作るための準備作業です。




  << もどる HOME すすむ >>
  目次にもどる