2006年10月 1日 応用編-17 「正調 DOA」 と 「変奏曲」 >> 目次に もどる
2011年 9月 1日 補遺  


 本節の論旨は理解できるが、文は下手くそだと思う (苦笑)。
 「『正調 DOA』 と 『変奏曲』」 という言いかたそのものが journalese の臭さを出している。

 さて、本節の記述は、高 パフォーマンス を実現するために、「請求」 のなかに、顧客番号を挿入しているかのような論法になっているが、正しくない。顧客番号が 「請求」 entity のなかに挿入されている理由は、あくまで、「情報」 のなかに、「そういうふうに記述されている」 からである--たとえば、「請求書」 のなかに、顧客番号 (および顧客名称、あるいは、それらのいずれか) が記載されているとか、あるいは、「顧客ごとの請求一覧情報」 があって、「顧客」 と 「請求」 とのあいだに、「関係」 が明示されているとか。

 「出荷」 も 「請求」 も、受注のなかで認知された 「顧客」 情報を継承している。すなわち、「出荷」 も 「請求」 も、それらの情報を生成する起点は 「受注」 であって、「顧客」 ではない。したがって、「データ 構造」 を作るのであれば、「出荷」 も 「請求」 も、「受注」 に対して関係があるので、「顧客」 情報は、出荷伝票および請求書のなかで改めて入手 (create) されるのではなくて、あくまで、受注伝票のなかで入手された情報を継承しているにすぎない。したがって、{顧客番号、受注番号、出荷番号、請求番号、・・・} の関係は、以下のように テーブル 分割するのが (関係主義では、) 正しい。

  {受注番号、顧客番号}.
  {出荷番号、受注番号}.
  {請求番号、出荷番号}.

 外部 スキーマ として フォーム (伝票など) を対象にして概念 スキーマ (データ 構造) を作る・いわゆる 「DOA (Data-Oriented Approach)」 は、そういうふうに考える。

 いっぽう、「現実の世界」 を対象にする実体主義では、「顧客」entity は、「受注」 entity・「出荷」 entity・「請求」 entity と関係があるというふうに 「構造」 が記述される--当然ながら、「受注」entity は 「出荷」 entity と関係があり、「出荷」 entity は 「請求」 entity と関係があることも記述される。

  {受注番号、顧客番号}.
  {出荷番号、受注番号、顧客番号}.
  {請求番号、出荷番号、顧客番号}.

 さて、「現実の世界」 が、そういうふうな構造として記号化されていて (構造が作られていて)、かつ受注番号・出荷番号・請求番号は、それぞれ、連続番号とすれば (顧客ごとに連続番号ではないとすれば)、同一顧客に対する 「情報」 は、以下のように、まとめることができる。

   R {顧客番号、受注番号、出荷番号、請求番号、・・・}.

 したがって、データ 構造は、以下になる。

  {受注番号、顧客番号}.
  {出荷番号、受注番号}.
  {請求番号、出荷番号}.

 そうすれば、実体主義を前提にして記述した 「現実世界の構造」 から データ 構造を作れば、DOA を前提にして作成される データ 構造と同じなる。
 もし、受注・出荷・請求のあいだで、それぞれ、顧客がちがうのであれば--たとえば、営業所から注文がきて、特約店に出荷して、本社が支払うというような事態であれば--、以下の構造となる。

  {受注番号、顧客番号}.
  {出荷番号、受注番号、顧客番号}.
  {請求番号、出荷番号、顧客番号}.

 以上の考えかたが、本節で述べた 「正調 DOA」 である。
 さて、以上を前提にして、「管理情報」 のひとつとして、以下を考えてみる。

  「顧客ごとに請求一覧を管理している」

 その事態のなかで論点となるのは、「顧客」 と 「請求」 とのあいだに関係を認知するかどうかという点である。TM (T字形 ER手法) は、(本節で述べているように、) 「顧客」 と 「請求」 のあいだに関係を認知する。というのは、TMD (TM Diagram、T字形 ER図) として描かれた構造は、(論理的意味論の観点に立って、) 情報の 「意味」 を記述している。TM は、「情報 (伝票など)」 を外部 スキーマ として考えているが、概念 スキーマ を データ 構造として考えている訳ではない点に注意されたい。
 そして、TMD を、そのまま、データ 構造として流用しているにすぎない。

 



[ 補遺 ] (2011年 9月 1日)

 「T字形 ER法」 は、DOA (Data Oriented Approach) を前提にして作られたが、その改良版である TM は DOA の モデル ではない。そして、「T字形 ER法」 も TM も一貫して 「意味論」 を重視して作られた──言い替えれば、コッド 正規形を起点にして、「意味論」 を補強する モデル として作られた。ただ、「T字形 ER法」 では、その思想・技術が幼稚だったということ。そして、TM では、いわゆる 「数学基礎論」 の 「モデル の存在性」 (スコーレム 氏、ゲーデル 氏らの説) に遡って Theory of models を検討して、さらに、言語哲学 (ウィトゲンシュタイン 氏、カルナップ 氏、デイヴィッドソン 氏らの説) を重視して、「言語の形態論」 としての モデル の特徴が強くなった。次のように言っていいかもしれない── TM は、「抽象 データ 型 モデル」 として 「言語使用」(事業のなかで合意された 「意味」) を分析する モデル である、と。







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