2005年11月16日 複合構成の認知番号 (その 1) >> 目次 (作成日順)
  ● QUESTION   1つの認知番号が、いくつかの コード から構成されているが、どうすれば良いか。
  ▼ ANSWER   個々の事例を、個々に対応するしかない。
2010年12月 1日 補遺  



 認知番号は、entity を直示する 1つの番号 (コード) でなければならない。言い換えれば、認知番号は、2つ以上の (ほかの) 認知番号を使って、複合的に構成されてはならない。2つ以上の認知番号を使って、複合的に構成された対象は、「関係」 を意味している (指示している) のであって、直示していない。

 そういう構成は、TM では、「対照表 (構成表、あるいは 『事態』」)」 「対応表 (上への関数)」 および 「再帰表 (『道』、あるいは親子関係)」 として記述される。つまり、TM では、2つ以上の認知番号を使って、複合的に構成された対象は、すべて、「××表」 という呼称が付されている──entity としない。

 ただ、2つ以上の認知番号を使って、複合的に構成された対象に対して、改めて、1つの認知番号を付与している事態も、ときどき、観られる。たとえば、典型的な例として、(単純に、モデル 化してしまっているが、) 以下の例を示す。

   商品 コード (ファミリー・コード、スペア・パーツ 区分 コード、連続番号、追番).

 1つの商品 コード が、(商品の) ファミリー・コード や、スペア・パーツ 区分 コード (部品構成のなかで使われるいっぽうで、単独に市販品としても扱われることを示す コード) や 連続番号という複合構成になっている。こういう事態では、まず、商品番号を認知番号にして、「商品」 entity を認知する──ただし、それが複合構成になっていることを、(認知番号の下に) 注記する。

  ┌───────────────────────────────────────┐
  │                 商 品                  R│
  ├──────────────────┬────────────────────┤
  │商品番号              │                    │
  │(ファミリー・コード、        │                    │
  │ スペア・パーツ 区分 コード、   │                    │
  │ 連続番号、追番)          │                    │
  │                   │                    │
  └──────────────────┴────────────────────┘

 
 さて、一通り、構造図を作成したら、次に、複合構成になっている認知番号を、エンドユーザ といっしょに検討する。そのときに、やっかいな点になるのが、商品番号を構成している スペア・パーツ 区分 コード が、その entity の 「性質 (述語)」 になっている、という事態である。

  ┌───────────────────────────────────────┐
  │                 商 品                  R│
  ├──────────────────┬────────────────────┤
  │商品番号              │スペア・パーツ 区分 コード       │
  │(ファミリー・コード、        │                    │
  │ スペア・パーツ 区分 コード、   │                    │
  │ 連続番号、追番)          │                    │
  │                   │                    │
  └──────────────────┴────────────────────┘

 
 さらに、もっと やっかいな点になるかもしれないのは、連続番号が、ファミリー・コード ごとに付与されているかもしれない、という点である。すなわち、連続番号のなかには、同じ値が起こり得るかもしれない──ファミリー A の 0001 番 もあれば、ファミリー B の 0001 番 もあり得る。連続番号 の適用区域が、ファミリー 単位であるかもしれない。

 さらに、もっともっと やっかいな点になるかもしれないのは、スペア・パーツ 区分 コード が、スペア・パーツ としても扱うという単なる flag ではなくて、「1 = 量産品、2 = 試作品、3 = スペア・パーツ」 というように、区分 コード のなかに、「AND 関係」 が生じている事態があるかもしれない (苦笑)。

 そういう検討のなかでは、当然ながら、(「商品」 entity に関与する) ほかの entity も検討しなければならないでしょうね。そして、それらの検討のなかで、商品番号を改訂できるのかどうか、という点を、エンドユーザ といっしょに考えなければならないでしょう。あるいは、もし、商品番号を改訂できないとしても──「情報」 としては、商品番号を、いままでの複合構成として表示しても──、データベース のなかで、商品を指示するための認知番号を付与することを エンドユーザ が 「同意」すれば、ひょっとしたら、「みなし entity」 を使って、現行の商品 コード を翻訳するかもしれないし、対照表 (ファミリー. スペア・パーツ. 商品番号. 対照表) を使って翻訳するかもしれない。

 (1) みなし entity を使う

    { ファミリー・コード、 ファミリー名称、・・・ }.
    { スペア・パーツ 区分 コード、 ・・・ }.
    { 新・商品番号、商品名称、・・・ }.
    { 新・商品番号 (R)、ファミリー・コード (D)、スペア・パーツ 区分 コード (D)、連続番号、追番 }.

    { ファミリー・コード (R)、スペア・パーツ 区分 コード (R)、新・商品番号 (R) }.

 (2) 対照表を使う

    { ファミリー・コード、 ファミリー名称、・・・ }.
    { スペア・パーツ 区分 コード、 ・・・ }.
    { 新・商品番号、商品名称、・・・ }.
    { ファミリー・コード (R)、スペア・パーツ 区分 コード (R)、新・商品番号 (R) 、連続番号、追番 }.

 ちなみに、(1) と (2) のちがいを説明することができますか。
 (2) のほうが、ファミリー 構成のなかで、商品番号 (連続番号) を考えていますが、(1) は、ファミリー・コード を (D) としている措置から判断して、みなし entity を 「コード 変換 テーブル」 にしています。

 以上に述べた例は、非常に単純にした典型例ですが、こういう単純な例であっても、一様には対応できないことが ご理解いただけたでしょう。ましてや、もっと、詳細な 実地の データ では、もっともっと、配慮がいるでしょう。最初に言いましたが、個々の事態に、それぞれ、対応するしかないのです。そして、こういう検討を通して、事業の 強み・弱みを 「的確に」 感知できるのです。

 



[ 補遺 ] (2010年12月 1日)

 ひとつの個体指定子が複合構成になっている状態は、たぶん、1970年代に プログラミング 法として主流だった 「構造的 プログラミング」 前提にしていたからではないか、と私は推測しています。その後、1980年代に コッド 関係 モデル を前提にした リレーショナル・データベース が現れ、SmallTalk が現れ、1990年代に 「オブジェクト 指向」 が事務系の システム 設計にも導入されるようになって、分析段階・設計段階で使われるモデル は 「抽象 データ 型」 モデル に移行したはずなのですが──したがって、個体指定子が複合構成になっている状態は除去されたはずなのですが──、今でも、複合構成の個体指定子が多量に存在しているようです。

 複合構成の個体指定子を単独の個体指定子に変えよと言うのは簡単なのですが、実際問題として、すべての システム を一挙に再構成できないので、いちぶずつ順々に変えてゆくしかないでしょうね。

 個体指定子の値を 「無意味な連続番号」を使うこと──すなわち、ひとつの クラス のなかで個体を並べる値として、「意味」 付けをしない連続番号を使うこと──が legitimate かどうかは論点になるでしょうね。たとえば、商品番号に関して以下の 2つの場合を考えてみましょう。

  (1) 無意味な連続番号を使う。

  (2) 或る程度の 「意味」 を付与する。

 (2) は、たとえば、{ 製造年月日、製造工場、モデル・シリーズ } という構成だとします──「201012AM2」 というふうに。

 理論的には、個体指定子は、個体を記号化して指示する機能であればいいので、無意味な連続番号でいいのですが、われわれが個体を認知したときに、その個体が他の個体と異 (ちが) う特徴点も 「同時に」 知りたいのではないかしら。勿論、個体指定子の値として 「無意味な連続番号」 を入手したあとで、その個体を retrieve して、その個体の 「性質 (attributes)」 を入手できるのですが、認知という行為において、「主語 (個体指定子)」 と 「述語 (性質)」 とのあいだに わずかの ズレ が起こるのを嫌うようです。言い換えれば、個体指定子が that という物を指示した時点で──ひとつの個体を認知した時点で──、その that が他の個体と異 (ちが) う 「性質の特徴点」 も同時に知るというのが認知の ありかた のようです。だから、「201012AM2」 という個体指定子を知った時点で、その個体が いかなる性質を持つ個体であるかがわかれば認知が寸断されないので仕事がやりやすい。この点 [ 個体指定子の値 ] が、コンピュータ 上の 「記号の演算」 と、人間が物を観る 「(記号の外に立って) 記号の意味」 との交点として──すなわち、構文論と意味論との交点として──難しい論点になっているのでしょうね。

 私は、個体指定子の値として、無意味な連続番号を良しとしない立場です。そうかといって、1970年代で多用された 「個体指定子の 『意味』 付け」 も私は良しとしない。それらの両極のあいだで、なんらかの legitimate な値を考えるのが個体指定子に関する意味論の難しさです。





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