2008年 3月 1日 「理論編-12 関係の対称性・非対称性」 を読む >> 目次に もどる
2013年 3月16日 補遺  


 本編は、前編 (「理論編-11 関係の論理」) を前提にして、「関係」 の性質を概説しています。
 そして、この 「関係の対称性・非対称性」 が、TM (T字形 ER手法) の文法のなかで最大特徴となっている点です。

 数学上、「関係」 は、「直積」 の部分集合として考えられています。したがって、項は、全順序 (あるいは、半順序) [ ≦ の関係 ] です。「集合」 の観点から云えば、「関係」 は、項を並べるための特徴関数です。

 構文論上、以上の扱いは、なんら齟齬は出ないのですが、意味論上──とくに、事業過程を対象にしたときに──、項の 「意味」 が問われます。事業過程を対象にしたら、項を並べるには、性質のちがう ふたつの特徴関数があることを私は気にしていました。ここでは、主体集合を対象にして特徴関数を考えてみます。それらに対して、特徴関数の 1つは、(受注、請求) のように、時系列で並べることのできる関係です。この特徴関数で並べられる主体集合を 「event」 としましょう。そして、もう 1つの特徴関数は、(従業員、部門) のように、特徴関数が存在するかどうかが わからない関係です。言い換えれば、「event」 に適用される特徴関数の対象にならない主体集合がある、ということです。この主体集合を 「resource」 としましょう。「resource」 は、勿論、アルファベット 順 (あるいは、五十音順) に並べることができるのですが、その 「並び」 には、事業過程上、いったい、どういう 「意味」 があるかといえば、ほとんど、無意味 (ナンセンス) です。そのために、私が、データ 設計の モデル を作ろうとしたとき、これらの主体集合 (「event」 と、その補集合) の関係文法で悩みました。

 そこで、改めて、「関係」 の性質を検討したときに、「関係の対称性・非対称性」 に気づいたのです。本編では、「関係の対称性・非対称性」 を、まず、一般的な事態のなかで考えて、「関係の対称性」 [ R (a, b) = R (b, a) ] として、「恋人である」 を例にして、「関係の非対称性」 [ R (a, b) ≠ R (b, a) ] として、「父親である」 を例にしています。

 関係主義──「関係」 が一次的であって、「個体 (主体)」 は変項である、という考えかた──の観点では、「性質 f (x)」 は、「関係 f (x, y)」 の特殊な形であるとして考えることができるのですが、「関係の対称性・非対称性」 を事業過程の データ 集合に適用したときに観られる 「event」 (および、「resource」) の関係が、「個体」 そのもの-の 「性質」 に起因するのか、それとも、「関係」 の 「性質」 として考えれば良いのか を私は判断できないので、TM では、事業過程の データ を 「event」 と 「resource」 に分類する際、「個体の性質・関係の性質」 として、「個体」 と 「関係」 を併記しています。

 もし、モデル が論理的意味論 (logical semantics) であるならば、事業過程のなかで使われる データ を 「構成」 する際、「関係の対称性・非対称性」 を配慮しなければならないでしょう。 □

 



[ 補遺 ] (2013年 3月16日)

 Entity は { 主題, 条件1, ・・・, 条件n } として構成されます (前回の論述を参照して下さい)。次に論点となるのは、これらの entity の並べかたです。つまり、主題を並べる関数をどうやって組むか、という論点です。
 主題は、次の 2種類に切断される。

  !. 全順序に並ぶ主題 (大小関係)

  2. 半順序の並ぶ主題 (なんらかのやりかたで並べられる)

 全順序に並ぶ主題が 「関係の非対称性」 の性質を持っています──「取引日」 の大小で並べられる主題です。それ以外が半順序で並ぶ主題、すなわち 「関係の対称性」 の性質を持つ主題です。
 Entity { h (e1,・・・, em), g (em+1,・・・, em+n)}.

 以上を前提にして、TM では、entity (主題) を次の 2つの切断しています。

  1. event である =DF 「取引日」 を条件とする entity である。

  2. resource である =DF event 以外の entity である。

 たとえば、

  1. event として、

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

    { 契約番号、契約日、・・・ }.

  2. resource として、

    { 顧客番号、顧客名称、・・・ }.

    { 商品番号、商品名称、・・・ }.

 なお、resource という呼称を気に入っていないので、良い呼称があれば── event に関与する物という意味ですが──教えていただければ幸いです。





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