2005年 3月16日 対応表のあいだに成立する関係 >> 目次 (作成日順)
  ● QUESTION   対応表と他の entity (「event」 と 「resource」) のあいだに、関係は成立するか。
  ▼ ANSWER   成立しない。対応表と entity は、数学的に云えば、「階」 が違う。
2010年 4月 1日 補遺  



 対応表は、2つの 「event」 のあいだで、先行 「event」 の リレーションシップ・タイプ が 「複数」 であるときに、生成される。すなわち、先行 「event」 と後続 「event」 をむすぶ 「マッピング・リスト (mapping-list)──数学的には、「上への関数 (on-to mapping)」 である。言い換えれば、集合(entity)と集合(entity)をむすぶ 「写像集合 (あるいは、「関数」 の クラス)」 である。

 T字形 ER手法は、タイプ (type) 理論を使わない前提に立っているので、「階」 の概念を導入していないが、もし、タイプ 理論を 「比喩的に」 使えば、対応表は、entity に比べて、「階」 が 1つ上位になる。したがって、「階」 の違う モノ に対して──たとえば、タイプ 1 と タイプ 2 に対して──、タイプ 1 に対して適用される生成規則を使って、(タイプ 1 と) タイプ 2 を、むすぶことはできない。

 ただし、2つの対応表は、同じ 「階」 なので、もし、それぞれの対応表のなかに、共有される (R) があれば、むすぶこと (統合する) ことはできる──「2つの対応表を、むすぶ意味があるのか」 という点をべつにして、技術的には、むすぶことができる。

 



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

 「対応表」 は、先行・後続 関係のなかで、先行 「event」 のなかに 「多値」 が生じている状態──写像で云えば、「全射」──を それぞれの x の値を y に対して一意に対応できるようにした 「関数」 (マッピング・リスト) です。たとえば、複数の 「受注」 を 1つの 「出荷」 に対応するなど。

 ちなみに、「対応表」 は、セット 概念 (ZF の公理系) では 「写像集合」 として──すなわち、ひとつの集合 (セット) として──考えられていますが、クラス 概念 (BG の公理系) では、「関数」 の クラス (ファンクター) です。そして、ZF の公理系で証明できる式は BG の公理系でも証明できますし、BG の公理系で証明できる式は ZF の公理系でも証明できます。

 さて、TM (T字形 ER手法の改良版) では、「対応表」 は 「関係文法」 の ひとつとして使われています──すなわち、2つの項 (entity) のあいだの関係 (関係) として使われています。その 「関係文法」 のなかに、「対応表」 と似た構成として 「対照表」 が示されています。そして、「対応表」 と 「対照表」 を混同する人たちが多いようです──データ 設計を記述した書物のなかに、私が実際に読んだ [ 書店で立ち読みしたのですが ] ミーハー 本のなかには、「ふたつの entity 間の関係が 『複数-対-複数』 の関係であれば、『対照表』 を作る」 というふうに、私の著作を間違って引用している書物が数冊ありました [ ちなみに、「対照表」 というのは、私の造語です ]。その記述を読めば、「対応表」 と 「対照表」 のちがいを把握していないことが露呈されています。

 「対照表」 は、「和集合」──ふたつの集合を前提にして、ひとつの entity を構成している状態──です。「対照表」 は、ZF の公理系のなかで、「対の公理」 と 「置換公理」 を使って認識された集合です。すなわち、ふたつの集合 M と N があれば、その ふたつの集合を元とする集合 S、すなわち { M, N } が存在して、S において f (x) が認められれば、{ f (x) | x ∈ S } を集合とする、ということ。たとえば、TM では、「従業員」 と 「部門」 という ふたつの集合が存在して、その ふたつの集合を元とする { 従業員, 部門 } において、「日付」 が存在すれば──あるいは、仮想したければ──、{ 従業員, 部門 } は 「配属」 という事態 (event) を構成する、ということ。この構成においては、「従業員」 と 「部門」 とのあいだの関係が、「複数-対-1」 であろうが 「複数-対-複数」 であろうが、{ 従業員, 部門 } は、単なる マッピング・リスト ではなくて、意味論上、「ひとつの entity を言及しています」。ここで云う 「意味論」 というのは、文法に従って構成された項──ここでは、{ 従業員, 部門 } ──が現実的事態と対比して、項が示す事態が時刻 t において生じていることを意味しています。

 いっぽう、「受注」 と 「出荷」 のあいだの関係が 「複数-対-1」 (あるいは、「複数-対-複数」) のときに 「対応表」 を構成しますが、「対応表」──すなわち、f ( 受注, 出荷 ) ──は、関数 (マッピング) であっても、意味論上、単独の事態 (event) を指示しない。

 勿論、数学上、ファンクター を使って、次の式を構成することはできます── g (x, f'). この式は、たとえば、( x → y ) と ( y → z ) という推移律があって、( x → ( y → z ) ) というふうに構成して、( y → z) を f' にして、g ( x, f' ) という高階の関数を構成することができます。この構成では、x と f' が対応されているので、(もし、この構成を TM に適用すれば、) 第一階の項と高階の項のあいだに関係を構成できるように思われますが、TM では、第1階の項と関係を構成できる 「複合的構成」 は、和集合で、かつ、その和集合において、「F-真」 が実現されているとき──言い換えれば、「event」 か 「resource」 としての性質をもつとき──、そして、そのときに限る。したがって、TM では、「対応表」 と 「event (あるいは、resource)」 のあいだで関係が構成されることは起こらない──ただし、「対照表」 と 「event (あるいは、resource)」 のあいだでは、前述したように、「対照表」 が和集合として ひとつの事態を指示するのであれば、関係を構成する場合があります。この点が、「対応表」 と 「対照表」 のちがいです。

 こう謂っていいかもしれない──「対応表」 は、あくまで、構文論上の演算であって、意味論上、現実的事態を指示しないが、「対照表」 は、(構文論上の演算であると同時に、) 意味論上、現実的事態を指示することがある、と。だから、私は、「対応表」 という語のほかに、「対照表」 という語を 「わざわざ」 用いたのです。それが無視されて、「ふたつの entity 間の関係が 『複数-対-複数』 の関係であれば、『対照表』 を作る」 というふうに流用されるのは──そういうふうに、「対照表」 の語を使われるのは──困る。





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