2005年10月16日 対照表と 「組 オブジェクト」 >> 目次 (テーマ ごと)
  ● QUESTION   対照表が 「組 オブジェクト」 になることもあるのではないか。
  ▼ ANSWER   たしかに、ある。ただし、TM では、「組」 の規準を基本的に時系列と考えている。
2010年11月 1日 補遺  



 「ベーシックス」 (7月 1日付) で、「集合 オブジェクト」 と 「組 オブジェクト」 について、述べた (420ページ 参照)。「集合 オブジェクト」 と 「組 オブジェクト」 は、以下にように、定義できる。

 (1) S1、S2、・・・、Snを オブジェクト (あるいは、セット の メンバー) とする。
 (2) オブジェクト の並びを論点にすれば、
   (S1、S2、・・・、Sn) は、「組 オブジェクト」 である。
 (3) オブジェクト の並びを論点にしないなら、
   {S1、S2、・・・、Sn} は、「集合 オブジェクト」 である。

 「並び」 が論点になるかどうか、という点が、「集合 オブジェクト」 と 「組 オブジェクト」 の相違点である (「組 オブジェクト」 は、いくつかの集合値が、或る規則に従って、並べられた組である)。
 TM では、モノ を記述する概念として、以下の 2つを使っている。

 (1) Entity
 (2) 集合を値とする オブジェクト (集合 オブジェクト および組 オブジェクト)

 Entity と 「集合を値とする オブジェクト」 との相違点は、認知番号が付与されているかどうか、という点にある。つまり、「合意された認知番号」 を付与されている対象が、TM では、entity として考えられ、認知番号を付与されていない対象は、「みなし entity」 か 「集合を値とする オブジェクト」 として考えられている。「みなし entity」 は、任意の entity のなかに、ほかの entity の性質として扱われ得る性質が混成されているときに、第一階の述語論理のなかで、認知される個体であるが、「集合を値とする オブジェクト」 は、高階の概念である。
 したがって、TM では、entity と オブジェクト (object) は、用語法が違う。

 さて、TM では、entity の並びを考慮する際、「時系列」 を並びの規準にしている。
 したがって、以下に示すように、1つの対照表のなかで、(R) の並びを 「組 オブジェクト」 として考えない。

    {部門 コード (R)、従業員番号 (R)}.

 すなわち、(部門 コード、従業員番号) であっても、(従業員番号、部門 コード) であっても良い。
 ただし、(もし、対照表が、「event」 として認知されるのであれば──言い換えれば、対照表のなかに、日付が帰属するのであれば──、) 2つの対照表のあいだには──あるいは、1つの対照表と 1つの 「event」 のあいだには──「並び」 を考慮しなければならない。

 1つの対照表のなかで、(R) の 「並び」 を考慮したほうが良い例も、たしかに、ある。たとえば、「銀行口座」 がそうである。

    {銀行 コード (R)、支店 コード (R)、口座番号 (R)}.

 もし、これらの (R) が、事実上、1つの 「口座番号」 として、意識されているのなら──言い換えれば、1つの コード が、3つの コード から構成されている、と意識しているのならば──、(R) のあいだには、並びが成立する。したがって、以下のように、組 オブジェクト として、記述するのが正しい。

    (銀行 コード、支店 コード、口座番号).

 ただし、TM は、(数学的な手法を使っている訳ではないが、数学的に言えば、) 第一階の述語を上限としている。そして、高階の概念は、すべて、まず、「関係」 を 「事態」 として認知することを原則としている。したがって、対照表は、あくまで、「事態」 として、まず、認知されるか──その性質として、日付が帰属するか──もし、「事態」 として認知されないのであれば、「構成表」 (真理値表) として扱うことを原則としている。

 その構成表が、「resource」 として、entity 的な役割を担うかどうか──言い換えれば、複数の (R) が、1つの認知番号に置換できるかどうか、(かつ、日付が帰属しないかどうか)──、という点は、TM の対象外としている。
 たとえば、対照表{銀行 コード (R)、支店 コード (R)、口座番号 (R)} は、日付を付与すれば、「event」 (口座開設) として認知することもできるし、事実上、1つの 「口座番号」 を 3つの (R) が構成している 「resource」 として認知することもできる。

 TM では、「並び」 とは、原則として、時系列を規準にしている──ただし、例外として、「親子関係」 を示す再帰 (構成表) は、(関係の論理を グラフ の論理に読み替えて、) 個体のあいだに、並びを導入している。
 したがって、対照表のなかには──「構成」 を記述する対照表には──、「組 オブジェクト」 として記述できる構成もあるが、TM では、(それを 「組 オブジェクト」 として考えたとしても、) 記述上、「並び」 を記述していない。

 



[ 補遺 ] (2010年11月 1日)

 今読み返してみて、ひどく歯切れの悪い説明をしていますね (苦笑)。
 歯切れが悪くなった理由は、「対照表が 『組 オブジェクト』 になる」 例 (銀行口座の例)──言い換えれば、対照表が 「event」 的性質ではなくて「resource」 的性質となる例──の説明が下手くそだからでしょうね。そして、「組 オブジェクト」 であれ 「集合 オブジェクト」 であれ、オブジェクトは 「集合を値とする」 クラス であると説明している点が、歯切れの悪い説明になった根本の理由でしょうね。

 対照表を オブジェクト の観点で説明しないで、対照表は写像集合である、と言い切ったほうが わかりやすい。そして、その写像集合の性質として 「日付 (できごとの起こった日、取引日) を仮想したいのであれば、写像集合を一つの集合 (event) として考えればいい、というふうに説明するほうが わかりやすいでしょうね [ ZF の公理系を前提にして、「対の公理」 「和集合の公理」 および フレンケル の 「置換公理」 を使う、ということ)。

 Entity を セット (集合) に変換して、セット を整えてから クラス に変換するほうが──多値関数上の 「AND 関係 (one-header-many-details)」 を ファンクター として説明するほうが──手続きとして統一がとれているし、わかりやすい [ この場合でも、ZF の公理系と第一階の述語 ロジック を前提にすれば、多値関数の 「AND 関係」 を合成関数として考える (説明する) こともできるでしょう ]。TM は、手続き上、(多値関数の 「AND 関係」 を一価関数に変換する手続きを除けば、) セット 概念を使っているので、TM の関係文法において、対照表を説明するときに クラス 概念を事前に定義しないで導入するのは ルール 違反になるでしょう。したがって、対照表は、セット 概念の観点に立って、写像集合として説明したほうがいい。この写像集合において、或る性質 f (x) が考えられるなら──そして、TM では、「event」 と 「resource」 を類別する性質は 「日付」 なので──、「event」 を構成する 「日付」 が実存しているか、あるいは、そういう 「日付」 を仮想したいのであれば、写像集合を 「event」 として 「解釈」 すればいい、ということ。

 論点は、写像集合として構成された対照表に対して、性質 f (x) が考えられるかどうか、という点です。性質 f (x) を考えられるのであれば、「event」 として 「解釈」 すればいいし、そうでないなら、「resource」 としての性質が考えられるかどうかを検討すればいい。そのときの争点が、対照表を構成している 2つの集合において、「並び」 (順序、関係の対称性・非対称性) を配慮しなければならないかどうか、という点です。その点を本 エッセー では、「集合 オブジェクト」 (関係の対称性) と 「組 オブジェクト」 (関係の非対称性) を使って説明したのですが、いっぽうで、「階」 概念──あるいは、「集合を値とする」 という言いかた──を混入してしまったので、歯切れが悪くなった次第です。申し訳ない。

 なお、対照表が 「event」 の性質も 「resource」 の性質も示さないのであれば、対照表を構成している 2つの集合に対する 「制約・束縛」 として作用するかどうかを考えればいいでしょう。





  << もどる HOME すすむ >>
  データ解析に関するFAQ