2004年 4月 1日 並列 (連言) の記述 >> 目次 (作成日順)
  ● QUESTION   並列は、配列として記述しては駄目か (並べて記述しては駄目か)。
  ▼ ANSWER   駄目。 配列にすれば、多値を温存したままであり、意味の記述にはならない。
2009年 4月16日 補遺  



 「多値 (many-valued function)」 の現象において、「resource : resource = 複数 : 複数」 は、「対照表」 を使って対応されるし、「event : event = 複数 : 複数」 は、「対応表」 を使って対応される。 さて、「resource : event = 複数 : 複数」 のなかで、論点になるのが 「並列」 である。

 たとえば、「訪問」 と 「従業員」 の間に成立する 「複数:複数」 (293 ページ) を例にして、考えてみる。
 2人の従業員が 1組になって、訪問するが、従業員の間には、組を構成する ルール はない、とする。そうすれば、以下の データ 構造を考えても良いように思われる。

  {訪問番号、顧客番号 (R)、従業員番号 (R)、従業員番号 (R)、訪問日、・・・}.

 さて、「複数:複数」 の リレーションシップ は、以下の 2つの事態を記述している。

 (1) 1人の従業員は、複数の訪問をおこなう。
 (2) 1つの訪問には、複数の (この例では、2人の) 従業員が関与している。

 したがって、この 2つの 「意味」 を記述しなければならない。
 (1) は、「従業員」 entity と 「訪問」 entity の間に成立する リレーションシップ であるが、(2) は、訪問するときの 「従業員の構成 (関与形態)」 を示している。ただし、訪問のたびに編成される 「従業員の構成 (関与形態)」 である。

 もし、訪問のたびに、2人組が編成されるのではなくて、組が事前に編成されているのであれば、従業員の再帰として記述される。

 単純に言えば、2人が 1組になって訪問するのだから、{従業員番号 (R)、従業員番号 (R)} は、1つの組番号として置換してもよい。従業員が訪問した事実と、従業員が訪問に際に編成する構成は、べつの意味である。データ・スキーマ 上、配列のまま、多値を温存すれば、多値が示す意味を、一義として記述したことにならない。したがって、以下の記述とするのが正しい。

  訪問 HDR {訪問番号、顧客番号 (R)、訪問日、・・・}.
  訪問 DTL {訪問番号、従業員番号 (R)}. [ データ は 2件となる。]

 訪問 HDR が、訪問の事実を記録して、訪問 DTL が、訪問の構成 (従業員の構成) を記録している。

 



[ 補遺 ] (2009年 4月16日)

 本 エッセー では、HDR-DTL 構成が生じる事態の一つを検討しています。「データ 解析に関する FAQ」 の 285ページ から本 ページ に至るまで──すなわち、285ページ、289ページ、293ページ、297ページ において──、HDR-DTL 構成を様々な観点で検討しています。当時 (2000年から 2004年のあいだ)、私は、やっと、HDR-DTL 構成が 「多値関数 (合成関数)」 であることを把握した次第です。「黒本(T字形 ER データベース 設計技法)」 (1998年出版) では、HDR-DTL 構成を 「セット」 概念で説明しようとして説明しきれなかったので、HDR-DTL 構成を整合的に説明できないまま未決着状態になっていました。もし、HDR-DTL 構成を整合的に説明できなければ、HDR-DTL 構成は T字形 ER手法のなかで パラドックス になって、T字形 ER手法が モデル にならないという重大な事態に陥っていました。HDR-DTL 構成は、「セット」 概念では説明しきれないので、「クラス」 概念 (ファンクター) を導入しなければならないことに気づいたのが、2004年頃でした。そして、「意味論」 を再検討して──すなわち、「導出的な L-真、事実的な F-真」 を導入して──、「クラス」 概念を導入して、T字形 ER手法を再体系化した著作が 「赤本 (データベース 設計論)」 (2005年出版) です。「赤本」 では、T字形 ER手法の体系を根底から見直して (T字形 ER手法という呼称を捨て、) TM という新たな呼称で モデル を組み直しました。

 「赤本」 において一つの検討項目になった HDR-DTL 構成は、「データ 解析に関する FAQ」 の 285ページ、289ページ、293ページ、297ページ および 301ページ を ほぼ そのまま転載しました。

 当時、私が HDR-DTL 構成を一般化できなかった理由は、以下の 2点が先入観になっていたからです。

 (1) HDR-DTL は、「event」 において起こる事態である。
   (「event : resource = 複数 : 複数」 において起こる事態である。)

 (2) 「セット」 概念 (あるいは、サブセット 概念) で説明できるはずである。

 HDR-DTL 構成は、「『関係』 が、そのまま、ひとつの個体になる」 という構成なので──この点は、「黒本」 で既に気づいていましたが──、合成関数 (あるいは、具象 カテゴリー・ファンクター) を使わなければ説明できないのですが [ 言い換えれば、「クラス」 概念を使えば簡単に説明できるのですが ]、上述したように、私は先入観に囚われていて、「クラス」 概念を導入しなかった。というか、もっと正確に言えば、「クラス」 概念を使わないで、なんとか説明できないかと足掻いていました。「クラス」 概念を使わないようにしたかった理由は、T字形 ER手法を作ったときに、「真理値表」 を 「真」 概念の験証で使ったことと、コッド 関係 モデル を基底にしていたので、第一階の述語と 「セット」 概念で モデルの構成要件を考えたかったので。

 HDR-DTL 構成で苦しんでいた私は、データ・モデル の書物を 多数 調べて、HDR-DTL 構成の説明を探したのですが、誰一人として HDR-DTL 構成を整合的に説明していなかった (苦笑)。コンピュータ 関連の書物を読んでも整合的な説明を得られなかったので、私は、再度、数学基礎論の書物を読み直して、合成関数を使えば単純に説明できることを気づきました。そして、それに気づいたときに──HDR-DTL を一般形で把握できたので──、HDR-DTL 構成は、なにも、「event」 においてのみ生じる現象ではなくて、事業過程・管理過程において様々な現象で現れることを理解できました。その様々な形のなかで重立った現象が 285ページ、289ページ、293ページ、297ページ および 301ページ で示した現象です。HDR-DTL 構成を一般形で把握していなければ、これらの現象に対応できないでしょう──言い換えれば、これらの現象に対して 「妥当な構成」 を組めないでしょう (HDR-DTL を単純な 「パターン (デザイン・パターン)」 として示すのみなど言語道断です)。





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