2007年 6月16日 特論-11 T字形 ER手法 (その 1) [ 理論的な根拠 ] >> 目次に もどる
2012年 5月16日 補遺  


 本節を、いま、読み返してみて、綴られている文章の いきおい が気負っているのを感じて、恥ずかしい。
 そうなった次第は、私が血気盛んな 45歳の頃に綴った文だったので、やむをえないかなと思っています。

 さて、本節では、TM (T字形 ER手法) が、理論上、拠り所にした文献を明かしています。TM が、「当初」、底本にした文献は、「論理哲学論考」 (ウィトゲンシュタイン) です。「当初」 と綴ったように、TM は、そのあとで、理論の軌道を修正しています。理論の軌道修正は、ウィトゲンシュタイン の哲学の変化に対応しています。すなわち、ウィトゲンシュタイン が、「論理哲学論考」 を否定して、「哲学探究」 を記した軌跡に沿って、TM も、「哲学探究」 の路線に舵を取りました。ただ、本 エッセー では、「論理哲学論考」 を底本にした理由を述べてみます。

 私は、1980年代 (初期から中頃)、日本に RDB を導入した張本人の一人です。プロダクト としての RDB を日本に導入普及したいっぽうで、コッド 関係 モデルや チェン ER手法も導入しました。ただ、以前にも述べましたが、私は、チェン ER手法を認めてはいなかった。私は、当時も今も、コッド 関係 モデル 派です。

 当時、コッド 関係 モデル を実地に適用するために、私は、いわゆる 「正規化手続き」 を セミナー で教えていたのですが、実地の データ 設計では、コッド 正規形を作る際、モデル と実 データ のあいだで、或る「摩擦」 を感じていました。その 「摩擦」 は、意味論の問題点なのですが、当時の私には、いまだ、意味論を正当に理解できていなかった──ただ、チェン 氏の云う意味論が、どうも、妥当ではないと私は直知していたようです。そこで、私がとったやりかたは、モデル (コッド 関係 モデル) に対して、意味論を強化することでした。そのために、「理想的な人工言語」 を前提にして、「語-言語は、現実の世界 (事実) を写像している」 という 「論理哲学論考」 の考えかたを流用しようと考えました。

 「論理哲学論考」 を流用する際に、私が、まず、考えた点は、「最小の意味単位」 でした。そこで、私は、「論理哲学論考」 で述べられている真理関数の考えかたを使って、「事実」 は、「命題」 ──画面・帳票などの 「情報」──として記述され、「物」 が対応する 「(最小の意味単位たる) 名辞」 を entity として考えました。コッド 関係 モデル は、アトリビュート (属性値集合) を単位としたのですが、私は、「S-P (Subject-Predicate)」 を単位としました。つまり、「S-P」 を entity の基本形として考えました。そして、entity を 「認知」 する てだて の identifier (主語) として、個人の認知を排除して、コード 体系を使いました。

 Entity を定立したあとで、私が考えた点は、「論理哲学論考」 で示された 「真理値表」 を 「データ 構造を作る (すなわち、「事実」 を写す) 像」 にするという点でした。言い換えれば、コッド 関係 モデル の射影を 「真理値表」 で記述するということでした。たとえば、2つの entity { E1, E2 } があったとして、それらが関与して起こる 「事態」 を { (T, T) (T, F) (F,T) (F, F) } という形式で記述しようと考えました。したがって、いまでは TM の特徴点になっている 「event と resource」 に対して、event であろうが resource であろうが、つねに、entity のあいだでは、「対応表」 を作るという 「構造」 を考えていました。以下を考えてみて下さい。

  {取引先番号、取引先名称、...}.
  {受注番号、受注日、受注数、...}.
  {商品番号、商品名称、...}.
  {取引先番号 (R)、受注番号 (R)}.
  {受注番号 (R)、商品番号 (R)}.

 この形式を、当初、私は考えました。2つの 「対応表」 を統合して、{ 取引先番号 (R)、受注番号 (R)、商品番号 (R)} を考えれば、それぞれの entity が 「成立している 『事実』」 を記述できると私は考えたのです。この時点では、私は、いまだ、「event と resource」 という概念を考えていなかった── entity に対して、種類を考えなくて、一律、entity としていました。私は、当初、この形式を 「T字形 ER手法」 として公表しようと思っていたのですが、腑に落ちない点を感じていました。腑に落ちない点は、以下の 「名辞」 が、はたして、「有意味」 なのかどうかという点でした。

  {受注番号、受注日、受注数、...}.

 {取引先番号、取引先名称、...} や {商品番号、商品名称、...} は、「S-P」 形式として 「独立に」 意味が成立するのですが──「物」 との指示関係があるのですが──、{受注番号、受注日、受注数、...} は、「事態」 として、はたして、「意味」 を記述しているのかという点が問われます。

 そこで、「関係の論理 (aRb)」 を配慮すれば、「受注」 は ひとつの entity として認知されても、「受注」 という事態 (意味) は、「aRb」 そのものであるということです。「受注」 を 「aRb」 の事態として記述するために、私は、「event と resource」 という概念を導入しました。そして、私が次に悩んだ点は、「event と resource」 の定義でした。なんとか、それらを定義できたので、次に、「関係の文法」 を作りました。

 以上に述べてきましたように、TM は、当初、「論理哲学論考」 で示されている以下の 2点を起点にして作られました。

  (1) 写像理論
  (2) 真理関数

 ただ、「関係の論理 (aRb)」 を記述するために、TM 独自の 「関係文法」 を作りました。
 そうやって作った モデル を実地の データ 設計のなかで適用して整えてきました。ちなみに、実地に適用して、TM は、すこぶる 「ききめ」 を実証してきたのですが、以下の 2点が 「懸案事項」 として──言い換えれば、なんらかの修正を施さなければならない点として──残されてきました。

  (1) 写像理論 (「カラー・コード」 が指示する 「カラー」 entity は実在しない)
  (2) いわゆる 「HDR-DTL」 (関数の関数、あるいは、関数のクラス [ファンクター])

 モデル 理論の原点にもどって、これらの懸案事項を検討するために執筆したのが、「論理 データベース 論考」 です。



[ 補遺 ] (2012年 5月16日)

 本 エッセー では、T字形 ER法 (TM の全身) が産まれた舞台 ウラ を語っています。私は楽屋話をするのが好きじゃないので、本 エッセー を綴った事を今振り返ってみて少なからず (我ながら) びっくりしています。ただ、もし この エッセー が綴られていなかったら、私はT字形 ER法の産まれた舞台 ウラ を きっと忘れてしまっていたでしょうね。







  << もどる HOME すすむ >>
  「T字形ER データベース設計技法」を読む