2009年11月 1日 「実践編-11 T字形 ER図の拡充」 を読む >> 目次にもどる
2018年 8月15日 補遺  


 

 TM (T字形 ER手法の改良版) は、モデル として、以下のように構成されています。

                  (F-真)
  ┌──────────────────────────────────┐
  │                                  │
  │         ┌───────┐                │
  │         │       │                │
  │        ─┘       └─               ↓
  y (形式的構造) ←    f    ← x (語彙) ← 「情報」 ← 現実的事態
           ─┐ (L-真)  ┌─
            │       │
            └───────┘

 すなわち、

 (1) 事業過程・管理過程で使われている 「情報」 を in-put とする。
 (2) 「情報」 に記述されている語彙に対して 「形式的構造」 を与える。
 (3) 「形式的構造」 と現実的事態を対比する。

 (2) を 「tentative modeling」 と云っています──すなわち、「文法」 に従って、語彙を前提にして文を構成する、ということ。構文論重視の作業と云っていいでしょう。そして、(3) を 「semantic proofreading」 と云っています──すなわち、構成された文が現実的事態と対比して、「真」 かどうかを験証する、ということ。意味論重視の作業と云っていいでしょう。

 以上の作業は、以下の 2点を前提にして、「事業を 『正確に』 記述する」 ことを目的としています。

 (1) ユーザ 言語を変形しない。
 (2) できるだけ機械的に構成する。

 さて、「事実を 『正確に』 記述」 したならば、以下の 3点を考慮して 「構造」 を修正します。

 (1) 再設計の目的
 (2) 現 やりかた の強み・弱み
 (3) 現 やりかた の環境適応力

 以上の 3点のなかで、「再設計の目的」 は、ユーザ が すでに提示しています。ただ、ここで われわれ システム・エンジニア が注意しなければならない点は、ユーザ が抱いている実現目的が、現 やりかた と対比して、実現できる範囲にあるかどうか ということを見極めなければならない。実現目的は、ユーザ が望んでいる改善なので、現 やりかた と隔たっているのがふつうですが、その隔たり [ 距離 ] を システム・エンジニア は或る程度 計量しなければならない。たとえば、「コスト を30%削減する」 という目的が示されたときに、TMD のなかで、コスト に係わる データ が どの 「箱」 (entity、対照表、対応表、再帰表など) のなかに記述されていて、どういう 「関係」 のなかで どのように並ぶのか を観て、それらの構成のなかで目的を実現できるのか、それとも、構成の変更──既存の データ を使った新たな構成──を考えなければならないのか、さらに、いままでにない新たな構成を導入しなければならないのか、を考えなければならない。

 と同時に、形式的構造のなかで、ユーザ の気づいていない 「潜在的な問題点」 が存在していないかを システム・エンジニア は感知しなければならない。システム・エンジニア が、もし、そういう 「潜在的な問題点」 を感知したならば、それを ユーザ に伝えて、対応を協議しなければならない。

 上述した問題点を把握するには、現 システム の 「事実を 『正確に』 観る」 しかない。問題点に対して ソリューション が考えられたならば、その ソリューション を 「構造的」 な プログラム として構成することを私は悪いと謂わないけれど、irrelevant だと思っています。私は、寧ろ、「抽象 データ 型 (abstract data type)」 のほうが legitimate だと思っています。というのは、「抽象 データ 型」 のほうが 「事業 (現実的事態)」 と その 「形式的構成」 の対応が わかりやすいので。まず、「事実を 『正確に』 記述」 した形式的構成を基礎資料にして、以下の補助資料を使えばいいでしょう。

 (1) 再設計の目的を具体的な実現数値で 3つほど列挙する。
 (2) 現 システム の長所 を 3つ、短所を 2つ 列挙する。

 再設計の目的は、「戦略的 (stratigic)」 な考慮点──すなわち、環境の変化に対する適応点──を扱い、現 システム の長所・短所は、「問題解決型 (issue-solution)」 の改良点を扱っています。これらの 2点を実現するために TMD を修正 [ 推敲 ] します。ここで くれぐれも注意しなければならない点は、形式的構成を変更したならば、かならず、変更点に対して 「アトリビュート・リスト」 を作成して 「『制約・束縛』 を網羅的に検証する」 という点です。DA (Data Anayst) は、往々にして、TMD (「妥当な構造」) を作ることばかりに興味を示しますが、モデル が モデル として使われるためには、「真とされる値」 が充足されるための 「制約・束縛」 を ひとつとして見逃してはいけないことに もっと注意を払っていただきたい。

 以上の作業が終われば、いよいよ、実装形を作る作業に進みます。実装形の作りかたは、次回 説明します。 □

 



[ 補遺 ] (2018年 8月15日)

 本文中に書かれている考えかた (モデル の前提) は、現在も変わっていません。

 一つ補足説明するならば、「F-真」 について、TM と数学では違っているという点です。
 数学では、「L-真」 は 「妥当な構造を作る (無矛盾性)」 を意味して、「F-真」 は 「真とされる値の充足」 を意味します。TM でも、当然ながら、それらの意味を継承しているのですが、TM では 「F-真」 について更に 一つ意味を追加しています。

 TM では、「F-真」 は、「真とされる値が充足されること、そして 『現実の事業構造』 と形式的構造が一致していること」 という意味です。「現実の事業構造と形式的構造が一致している」 ということを判断するために、TM は entity を 「event (出来事、行為、取引) と それに関与する モノ」 という意味論的拡充を施しています。そして、それを判断する モノ として 「event」 を重視しています──すなわち、事業を構成している プロセス を重視しています。形式的構造上 「event」 として構成された モノ (集合) が実際の事業過程の プロセス と 「1 対 1」 対応する (one-to-one correspondence) ことを前提にしています。勿論、この 「現実と形式」 の 「1 対 1」 対応は、「形式」 が示すものが現実に 「単独で実存 する」 ということを直示 (指示) しているということではなくて──たとえば、カラー・コード で示される色とか分類 コード で示される分類とかは単独で実存しない──、管理過程の構造が事業過程のやりかたを写像しているという意味です

 TM の前身たる T字形 ER法は、ウィトゲンシュタイン 氏の 「論理哲学論考」 を本説にして作られました。ウィトゲンシュタイン 氏は、「現実と形式」 は 「1 対 1」 の対応ではなくて、互いの 「構造全体」 が対応しているという picture theory (写像理論) を示していますが──そして、この考えかたは 「関係」 の構成を重視する数学でも同じですが──、TM は意味論的な 「event」 という概念を導入して、ウィトゲンシュタイン 氏とは違う考えかたをしています。

 さらに、「真とされる値の充足」 について、数学では関数上の制約 (constraints)をもってして 「真」 とされる値が充足されることを云っていますが、実際の事業では、個々の取引 (event) 上に様々な制約束縛が付帯しています──したがって、それらの制約束縛を網羅しなければ、「F-真」 を充たすことができない。TM では、これらの制約束縛を網羅することに意を注ぎました。そして、これらの制約束縛は、モデル (形式的構造) 上には顕れない。制約束縛を記述するために用意されているのが 「アトリビュート・リスト」 です。






  << もどる HOME すすむ >>
  目次にもどる