| 2004年 11月16日 | 「event」 と 「resource」 を切り離す意義 | >> 目次 （作成日順） |
| ● QUESTION | 「event」概念 と 「resource」概念を使えば、どのような メリット があるのか。 | |
| ▼ ANSWER | 技術として、実効性 ・ 単純性 ・ 整合性 という 3点を、「同時に」 実現するため。 | |
| 2009年12月 1日 補遺 | ||
|
モデル （modeling） では、「構文論」 と 「意味論」 を考えなければならない。 「構文論 （構造を記述する文法）」 では、モノ を無定義語として、関数 （関係） のなかで成立する変項 （パラメータ） にすぎない、と考えます。つまり、 「存在とは、変項になりえること」。
したがって、従業員とか、部門とか、商品とかも、「従業員であること」 とか 「部門であること」 とか 「商品であること」 というふうに考えて、「event （できごと）」 のなかで生起する （比較的、長いあいだ、） 持続する現実的な事物にすぎない。認知の対象は、すべて、「できごと」 です。
（1） モノ を定義する。 「構文論」 では、（2） を使います。というのは、モノ は 「高階の」 構成物なので、定義できないから。「構文論」 の強みは、ルール （文法） が、比較的、明示されている、という点です。つまり、或るやりかたを使う際、一人の エンジニア の価値観のために、「構造」 が揺らがない、という点が強みです。言い換えれば、できるかぎり、「恣意性」 を排除する、という点が強みです。 「意味論」 では、（「意味」 そのものが、）「指示関係」 を論点にしますので、変項の 「意味」 を対象にしなければならない。「意味」 は、述語を使って記述されます。したがって、どのような述語が、どのような主語に帰属するのか、という点が論点になります。 Ｔ字形 ER手法は、「モノ と関係」 のなかで、（本来、無定義語である） モノ を 「定義しています」。つまり、（コード 体系を前提にして、） 「認知番号」 を、モノ の定義として使っています。というのは、事業過程のなかに関与する人たちが、「合意」 した認知を前提にするためです。かつ、Ｔ字形 ER手法は、「構文論」 を基本形にしています。つまり、「構造を作るための ルール」 を示す、ということです。 「event （できごと）」 は、系列 （時系列） を作ります。系列を判断する規準が 「日付」 です。つまり、「日付」 が帰属する主語が、「event （できごと）」 ということです。 「構文論 （ルール）」 のなかで、モノ は、以下の 2つに切り離すことができます。
（1） 系列を作る群
系列を作る群が 「event （できごと）」 です。
系列を作らない群が、「resource」 です。 以上を前提にして、事業過程のなかで、「できごと」 を切り出して、時系列に並べて、「できごと」 に関与する モノ を網羅的に記述する、というのが、「構文論」 としてのＴ字形 ER手法です。 「構文論」 のなかで記述された構造は、あくまで、「形式的な」 網羅性・無矛盾性・完全性を保証しただけであって、「現実の」 世界が、ほんとうに、そうなっているかどうか、という点を検証していない。「形式的に記述された」 構造が、「現実の世界」 を正しく記述しているかどうか、という点は、逐次、構造を、ユーザ といっしょになって、検証しなければならない。 検証する際、作図されたの構造を、自然言語を使って、しゃべってみる、という やりかた を、ユーザ といっしょに、やっています。たとえば、「event」 として、「受注」 と 「請求」 があって、「resource」 として、取引先が、受注にも請求にも、関与していれば、「受注した取引先とは違う取引先に対して請求することも事業のなかでやっているのですね」 というふうに確認します。 すなわち、「event」 を時系列にしたがって読みながら、「event」 の並びが、事業過程を正確に記述されているかどうか、そして、「event」 に関与する 「resource」 が正確に記述されているかどうか──どういうふうに事業をやっているのかという点が、正確に記述されているかどうか──という点を、逐一、検証します。 つまり、「構文論」 として、最初に、「形式」 を記述して、その 「形式」 が、ほんとうに、「現実の」 事業を記述しているのかどうか、という点を、ユーザ といっしょになって、検証します。その際、「形式」 が、「event」 と 「resource」 というふうに、記述されていれば、ユーザ といっしょに検証しやすい。それが、「意味論」 の世界です。そして、当初、作成されたＴ字形 ER図を、添削します──たいがい、当初に記述された ER図は、ずたずたに、添削される結末になります。というのは、ユーザ 自身が、思い込みのまま、記述してしまう傾向があるから。 Ｔ字形 ER手法が、「event」 と 「resource」 という考えかたを使っている理由は、実効性 （ききめがあること） ・ 単純性 （つかいやすさ） ・ 整合性 （理論的な正しさ） という 3点を、できるかぎり、調整して、「同時に」 実現するためです。 |
|
[ 補遺 ] （2009年12月 1日）
Entity を 「event」 と 「resource」 に切断した理由は、そもそも、「関係」 を 「関数」 として扱うときに、「（個体のあいだの） 並び」 を定則化するためでした。「並び」 には、以下の 2種類があります。
（1） 半順序 「順序」 は、数学では、厳正に定義されています。数学的定義そのものは、数学の書物を参照してもらうとして、本 エッセー では、数学的な定義を緩やかに適用して、以下の意味で使っています。
（1） 半順序とは、なんらかの並べかたがある、ということ。 （2） 全順序とは、「大小 （≧） に並ぶ」 線形順序ということ。
したがって、全順序は半順序の真部分集合ですが、その逆の関係は成立しない。 数学では、対象を 「項」 として考えているのですが、数学の 「関数」 を現実的事態に対して適用する場合、「項」 の性質が問われます。すなわち、事業過程のなかで認知されている対象に対して、なんらかの 「関係」 （あるいは、「関数」） を適用する場合、事業過程のなかで認知される対象には、全順序および半順序として並ぶ集合が存在します。たとえば、「受注」 「出荷」 「請求」 などの事象は、取引日を判断規準にして全順序 （時系列という線形順序） で並ぶのですが、「商品」 「従業員」 「部門」 「取引先」 などの事物は、全順序ではなくて、半順序で並べることになるでしょう。「事象」 とか 「事物」 という言いかたをしましたが、こういう個体を定義するのは、とても難しい。数学では、こういう個体は──「事象」 であれ 「事物」 であれ──、「無定義語 （変項）」 として扱います。そして、「関数」 を一次的に考えて、変項のなかに値を付与したときに──変項の値を一意にすることができて──、その値が 「真」 であれば、対象が存在する、というふうに考えます。 しかし、前述したように、事業過程で認知されている対象には、全順序を適用できる項と半順序を適用する項が共存していて、ひとつの 「関数」 のみで構成できない、というのが悩ましい争点です。 TM （Ｔ字形 ER手法の改良版） では、事業過程のなかで認知されている対象 （entity） を以下の 2つに切断しています。 event である ＝ Df 性質として 「日付」 が帰属する entity である。 resource である ＝ Df event 以外の entity である （補集合）。 そして、「event」 に対しては全順序を適用して、「resource」 に対しては半順序を適用しています。とすれば、関係 [ R (a, b) ] では、以下の 3つの関係が生じます。なお、ここでは、2つの entity のあいだで関係を考えることにして、「再帰」──ひとつの集合のなかの メンバー を並べる関数──を外しておきます。 （1） R ( event, event ). （2） R { resource, resource }. （3） R { event, resource }. R ( event, event ) は、全順序なので、先行・後続 関係として構成できます。R { resource, resource } は、2つの事物が存在しているのみなので、それらの 「和集合」──すなわち、R { resource, resource } ──として、なんらかの事象を構成します。言い換えれば、2つの集合を メンバー にした和集合に対して、性質 （日付） が存在するとき、あるいは、「日付」 を仮想したいとき、そのときにかぎり、R { resource, resource } を 「event」 として翻訳する （扱う） ということ。 さて、ここで争点になるのが、R { event, resource } の構成です。この構成は、数学的 ソリューション ではなくて、哲学的 ソリューション を適用せざるを得ない。すなわち、「事物 （resource） が事象 （event） に関与する （侵入する、ingression）」 という実体主義的文法を適用せざるを得ない。たとえば、以下の 2つの entity を前提にして考えてみます。 { 受注番号、受注日、受注数、・・・ }. [ event ] { 顧客番号、顧客名称、・・・ }. [ resource ] 上述した文法を適用すれば、以下の構成になるでしょう。 { 受注番号、顧客番号 （R）、受注日、受注数、・・・ }. [ event ] { 顧客番号、顧客名称、・・・ }. [ resource ] なお、「顧客」 entity が 「受注」 entity に関与したことを示すために、「受注」 entity に関与した 「顧客番号」 には （R） を付与しています──言い換えれば、「受注」 entity のなかの 「顧客番号」 は、関係のなかで関与したのであって、「受注」 の個体指定子ではない、ということです。 こういう 「関係の文法」 を使えば、本 エッセー のなかで説明したように、事業の構成を形式的構成として記述して、かつ、構成を 「解析」 しやすいでしょう。 「関係の文法」 では、つねに、「関数 [ R ( a, b ) ]」 を前提にしているのですが、争点になるのが、「event」 と 「resource」 とのあいだの関係です。TM は、実体主義的個体に関係主義的文法を適用する モデル になっています。すなわち、TM では、個体 （entity） は 「個体指定子 （entity-setter）」 を付与された対象していて、それらの個体に対して、関数 f ( x, y ) を適用するのですが、全順序のみではなくて、半順序も考慮して、全順序が適用される個体 （event） と半順序が適用される個体 （resource） のあいだでは、以下の実体主義的な考えかたを導入しています。 「resource が event に侵入する」
この考えかたは、ホワイトヘッド 氏の哲学および パース 氏の哲学を借用しています。 |
| << もどる | HOME | すすむ >> | |
| ▼ データ解析に関するＦＡＱ | |||