2005年 5月16日 基準編-4 identifier と コード 体系 >> 目次にもどる
2010年 4月16日 補遺  

 

 Identifier は、個体を 「名指し」 する役割である。
 すなわち、「現実世界」 では、同じ個体 (「...の時に、...の所に存在する」 個体) は、2つ存在しないし、かつ、「現実世界」 では、(いくつかの性質の連言が個体として認知されるのではなくて、) 個体が指示されて、性質が認知される。言い換えれば、「現実世界」 を対象にして、モデル を作るのであれば、 個体を指示するために使う記号が identifier である。したがって、identifier には、以下の性質がある。

 (1) 単一の (one and only) 記号である--言い換えれば、複数の記号を使って構成された概念ではない。
 (2) 値は、一意である。

 
 「現実世界」 として、経営過程を対象にしたとき、identifier として、どのような指示記号を使うか、という点は、モデル を作る際の 1つの前提になる。経営過程は、以下の 3つから構成されている。

 (1) 事業過程 (購買過程、生産過程、販売過程、労務過程、財務過程)
 (2) 管理過程 (購買管理、生産管理、販売管理、労務管理、財務管理)
 (3) 組織過程

 事業過程とは、実際に営まれている事業のことをいう。管理過程とは、事業過程を管理するために導入された報告過程である。したがって、管理過程は、事業過程に対する 1つの モデル (情報体系) である、と云ってもよい。
 経営過程を対象にして、モデル を作る際、以下の 2つの やりかた を考えることができる。

 (1) 事業過程を対象にして、管理過程を再設計する (オノマシオロジー 的観点)
 (2) 管理過程を対象にして、事業過程との指示関係を問う (セマシオロジー 的観点)

 オノマシオロジー 的観点に立って、事業過程そのものを対象にして、モデル を作るのであれば、identifier として、「現実の個体」 を示すために、なんらかの人為的な指示記号 (object-id) を使うことになる。ただ、この やりかた では、どのような 「個体」 を認知するのか、という点は、なんら 「判断規準」 がない。したがって、個体の認知が 「恣意的」 になる。

 セマシオロジー 的観点に立って、管理過程を対象にして、モデル を作るのであれば、管理過程のなかでは、コード 体系が導入されているので、コード 体系を前提にして、個体を認知することができる。事業過程では、管理過程が記述した コード 体系を前提にして、情報が伝達されている。コード 体系のなかに記述された商品番号は、事業過程のなかに関与する人たちが使う商品番号であって、たとえば、或る従業員が、(コード 体系を無視して、) 商品を扱うことはできない。つまり、コード 体系は、事業過程に関与する人たちが 「同意した認知 (あるいは、従わなければならない規約)」 なのである。したがって、事業のなかに存在する個体を認知する際、(認知の) 「恣意性」 は起こらない。

 T字形 ER手法は、identifier として、コード 体系のなかに定義された指示記号を使う。というのは、それが、事業過程に関与する人たちが 「同意」 した認知だから──モデル を作る認識主体 (システム・エンジニア) の認知が、事業のなかに存在している個体の認知を左右するのではない。

 コード 体系のなかに定義されている指示記号 (たとえば、商品番号とか契約番号とか) には、適用区域がある。たとえば、営業所ごとに、契約を管理していて、契約番号の値が付与されるのであれば、契約番号は、営業所のあいだでは、一意的にはならない。したがって、「個体の一意性」 を示すために導入される identifier の値は、コード 体系を前提にすれば、かならずしも、一意性を実現しない。コード 体系を前提にすれば、identifier の一意性は、コード の適用区域を配慮しなければならない──たとえば、さきの契約番号で云えば、「営業所 コード + 契約番号」 という構成にしなければ、個体 (契約) の一意性は実現されない。

 本稿 (基準編-4) では、以下の 2点を検討している。

 (1) Identifier として、コード 体系のなかに定義された指示記号を使う (認知の 「同意」)。
 (2) コード 体系を前提にすれば、identifier の値は、適用区域を配慮しなければならない。

 そして、identifier は、マスター・キー (一意性を実現するために導入された index-key) ではない、という点を訴えている。この考えかた (identifier として、コード 体系を前提にすること) は、いまも、変わっていない。

 



[ 補遺 ] (2010年 4月16日)

 TM (T字形 ER手法の改良版) の モデル 体系は、以下の体系です。

    「合意」 された認知 (語彙) → L-真 の構成 → F-真の験証

 TM が この体系に整えられた時期は、「赤本」 (2005年) から 「いざない」 (2009年) に至る時期です。この過程において、私が苦慮していた点は、T字形 ER手法のなかに導入した 「identifier」 概念を モデル の体系のなかで どのようにして扱うか、という点でした。というのは、数学上、モデル の存在性は、以下のように定理化されていて、「合意」 概念を入れる余地がない。

    意味論的な恒真性 ←→ 証明可能性

 モデル であるかぎり、「証明可能性」 (あるいは、無矛盾性) を実現しなければならないのは当然のことなのですが、ロジック における 「意味論的な恒真性」 というのは、現実的事態──私の仕事では、事業過程──において、どういう意味なのかが私にとって争点 (論点) になっていました。もし、意味論的な恒真性を 「(事実的な) F-真」 として、証明可能性を 「(導出的な) L-真」 とすれば、T字形 ER手法で導入した identifier (個体指定子) は、かならずしも、(事実と対比して、実在的な) F-真を指示しない──たとえば、「カラー・コード」 で指示された 「カラー (色)」 は抽象的な・反復して使用される概念であって、色は物体色であれ構造色であれ、なんらかの存在物に帰属する性質であって、単独の実在ではない。したがって、色そのものの F-真を問うことはできない。

 私が直面した問題は、「モデル の真理条件」 と 「モデル の正当化条件」 です。
 すなわち、F-真と 「合意」 を いかにして モデル の体系のなかで構成するか が私の直面した問題点でした。F-真は、以下の T-文で験証されます。

    文「p」 が真であるのは、時刻 t において、事態 p と一致したとき、そして、そのときに限る。

 すなわち、TM において、「event」──ただし、「resource」 が関与した状態──のみが F-真の験証対象になる、ということです。そうであれば、「resource」 の存在性 (そして、正確に謂えば、関係文法を適用する以前の状態にある 「event」) が──単純に謂えば、「個体 (entity)」 の存在性が──いかに正当化されるか、という点が私の直面した問題点でした。あるいは、こう謂っていいかもしれない──ユーザ が なにがしかの 「語彙」 を使って 「意味」 を伝達できるのは、どうしてか、と。

 T字形 ER手法では、「語彙」 の意味が導入されるのは、ユーザ が 「合意した認知」 を前提にしている、という考えです。そして、その考えかたは、TM にも継承されました。そのため、「語彙」 に対して導入された 「合意された認知」 という考えかたと、文の真理条件として導入された F-真を いかにして並立するか が私の直面した問題点でした。その問題点に対して ソリューション を与えるためには、当然ながら、ロジック 上の モデル としての完全性 (F-真 ←→ L-真) を前提にしなければならない。

 私が考えた ソリューション は、「文」 が構成される以下の プロセス に対応して、「合意」 「L-真」 および 「F-真」 を並べるということでした。

    語彙 → 文法 → 文

 すなわち、

    「合意された」 語彙 → 文法にしたがって構成された 「文」 → 事実と対比して真を実現した 「文」

 この プロセス が 「合意 → L-真 → F-真」 という TM の手続き体系 (モデル の正当化条件) になった次第です。そして、この体系であれば、「関数 (ブラックボックス)」 において、「自然言語の語彙」 を input として使い、それらの語彙に対して なんらかの 「関係文法を適用して、output として構成された・「形式化された」 文を事実と対比して 「真」 (F-真) を問うことができるので、管理過程で使われている 「情報」 を input にして、最終的には、事業過程の 「現実的事態」 と対比できる。そうすれば、コード 体系の有効性が──かならずしも、コード が有効に作用しているということではなくて、コード の妥当性を問うという意味ですが──験証できるし、事業の 「意味」 も確認することができます。この プロセス を本 エッセー では、「セマシオロジー」 と云っています。

 なお、identifier の 「一意性」 については、「赤本」 58ページ・59ページ で検討していますので──identifier の値が、かならずしも、一意にならないことを証明しているので──参照してください。





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