2002年 5月15日 「resource」 と 「event」 >> 目次 (作成日順)
  ● QUESTION   entity は、「resource」 と 「event」 の 2種類しかないのか。
  ▼ ANSWER   2種類しかない。 「並べられるか、そうでないか」 のいずれかである。
2007年 6月16日 補遺  



  Entity は、T字形 ER手法では、「resource」 と 「event」 の 2種類しかない。事業過程のなかで認知された モノ を entity という (前回の 121ページ を参照されたい)。T字形 ER手法では、entity は、以下のように定義されている。

     定義  entity とは、identifier (認知番号) を附与された モノ のことをいう。

 「認知」 の規準はT字形 (T-formed) の左側に表示され、T字形の右側には認知された モノ の 「性質が記述される」。たとえば、「従業員番号」 を認知規準にして、「従業員」 entity が認知され、名称などの性質が記述される。たとえば、「受注番号」 を認知規準にして、「受注」 entity が認知され、DATE (取引日) などの性質が記述される。

 モノ が複数あれば、「数」 が論点になる。
 ここでいう 「数」 とは自然数のことをいい、0, 1, 2,... をいうことにする。通常は、0 を自然数のなかにはいれないが--ギリシア 時代には、1 も自然数のなかにはいれなかったが--、ここでは 0 も自然数のなかにいれる。さて、「数」 には、以下の 2つの考えかたがある。

 (1) 基数 (cardinal、集合数)
 (2) 序数 (ordinal、順序数)

 基数は (モノ の) あつまりの 「多さ」 を記述する数であり、序数は系列のなかで 「並び (順序)」 を記述する数である。モノ は 「数」 を使って 「数える」 こともできるし 「並べる」 こともできる--集合論で言えば、{  } という括弧は 「集める」 ことを記述しているし、(  ) という括弧は 「並べる」 ことを記述している。

 さて、認知された モノ を 「数える」 ことはできるが、モノ と モノ との関係を記述して、しかじかの「構造」 を与えようとすれば、「並び」 が論点になる。だが、モノ には、「並べられる (順序対が有意味である)」 モノ と 「並べられない (順序対が無意味である)」 モノ がある。つまり、モノ は、「並べられるか、並べられないか」 という観点に立って (判断規準を使って) 分類することができる。
 たとえば、(出荷、請求) と (請求、出荷) では、「並び」 が違えば、それらの順序対が表現している意味が違ってくる。
 (出荷、請求) は、出荷してから代金を回収する意味であり、(請求、出荷) は、入金を確認してから出荷する意味である。いっぽう、(部門、従業員) と (従業員、部門) では、「並び」 が違っても、それらの順序対は同じ意味 (「配属」) になる。

 つまり、ビジネス のなかで扱われている データ には、順序対が有意味な データ と順序対が無意味な データ がある、ということである。有意味な順序対の データ を 「event」 といい、無意味な順序対の データ を 「resource」 という。これらの データ を 1つの規則 (たとえば、関数 [ 直積集合 ]) を使って同じように扱うことは、記号列を扱うには有効であるが、「ことばの意味」 を解析するには べつのやりかたを考えなければならない。なぜなら、「resource」 も、ビジネス のなかで使われている意味を度外視すれば、アルファベット 順に並べることはできる。
 しかし、われわれ システム・エンジニア がやらなければならないことは、しかじかの 「あるべき」 構造 (規範) を発見するのではなくて、データが実際にどのように使われているのか、という 「ことばの現実の使用 (データの意味)」 を記述することである。

 「並べられる」 か 「並べられない (並びが大きな論点にならない、という意味)」 か、という判断規準は、モノ の性質のなかに記述されている。つまり、データ を記述する 「ことばの文法」 のなかに 「ことばの意味」 は現れている。「event (並べられる データ)」 には 「DATE (取引日)」 が帰属するが、「resource (並びが大きな論点にならない データ)」 には 「DATE」 は帰属しない。

 以上に述べたように、事業過程のなかで認知された モノ (ビジネス・データ) は、「DATE」 を判断規準として、2つに分類される。

     定義 「event」 とは、(性質として) 「DATE」 が帰属している モノ をいう。

 したがって、entity の分類は 「並べられるか、並べられないか」 ということを判断規準にしているので、「resource」 とは 「event」 以外の entity のことをいう。つまり、entity は 「event」 と 「resource」 の 2つ以外にない。

 とすれば、「event」 と 「resource」 のあいだには--entity という (範囲が限られている) 集合のなかでは--、それぞれが排他的に並立する。つまり、排中律 (A ∨ ¬A) が成立する。

 ここで注意してほしい点は、「resource」 そのものを定義していない、という点である。したがって、entity の サブセット として排中律が成立すれば、以下のような 「境界上の事例」 はない。

  (1)   (event ∧ resource)
  (2) ¬(event ∨ resource)

 「境界線上の事例がない」 という配慮は、(モノ と モノ とのあいだに成立する) 「関係」 を記述するときに適用する規則のなかで矛盾が起こらないようにするためである。

 



[ 補遺 ] (2007年 6月16日)

 本 エッセー で述べたように、TM (T字形 ER手法) でいう 「resource と event」 は、「マスター・ファイル と トランザクション・ファイル」 という意味ではない点に注意して下さい。TM の 「resource と event」 は、関係の対称性・非対称性に対応する概念です。

 関係の対称性とは、たとえば、「恋人である」 という関係のように、2項関係のなかで、変項の並びを変えても、関係の意味が変わらない事態を示しています [ R (a, b) = R (b, a) ]。たとえば、個体 a と個体 b を、それぞれ、佐藤正美と山崎恵美子とすれば、「佐藤正美は山崎恵美子の恋人である [ R (a, b) ]」 が 「真」 なら、「山崎恵美子は佐藤正美の恋人である [ R (b, a) ]」 も 「真」 である、という関係です。

 いっぽう、関係の非対称性とは、たとえば、「父親である」 という関係で、変項の並びを変えたら、意味が変わってしまう事態です [ R (a, b) ≠ R (b, a) ]。たとえば、個体 a と個体 b を、それぞれ、佐藤正美と佐藤敦とすれば、たとえば、「佐藤正美は佐藤敦の父親である [ R (a, b) ]」 が 「真」 なら、「佐藤敦は佐藤正美の父親である [ R (b, a) ]」は 「偽」 となります。

 TM では、関係の非対称性を示す性質をもっている個体を 「event」 として定義しています。「event」 は、時系列のなかで非対称性を示します。

 「resource」 は、TM では、「event」 の補集合として定義されています--「resource」 そのものを、関係の対称性を前提にして定義していない点に注意して下さい。「resource」 を定義しなかった理由は、本 エッセー のなかで述べたように、「矛盾」 (「event かつ resource」 という事態とか 「event でもないし、resource でもない」 という事態)が起こらないように配慮したからです。

 「event と resource」 は、TM の 関係文法に従って組を作って、最終的に、ひとつの 「構造」 を作ります。したがって、もし、「event と resource」 のあいだに 「矛盾」 があれば、それらから導かれる 「構造」 が妥当でないことになってしまいます。TM では、「構造」 は、すべて、entity を起点にして導かれるので、証明可能です (「完全性」 を実現しています)。




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