「個体」 を指示する コード （すなわち、コード 体系のなかで定義されている管理番号） のことを、私は、いままで、「identifier」 とか 「認知番号」 とか 「個体指示子」 というふうに言ってきましたが、最近では、「個体指定子 （entity-setter）」 という言いかたを使っています。「個体指定子 （entity-setter）」 という言いかたは、デイヴィドソン 氏の著作 「真理と解釈」 のなかで目にしたので、借用しました。今後、「個体指定子」 を主に使いますが、「認知番号」 「個体指示子」 も併用すると思います。

　さて、「個体指定子」 は、原則として、atomic な項目であって、ほかの 「個体指定子」 を使って構成されていないこと。言い換えれば、「個体指定子」 は、個体を指示するための管理番号として、複合構成であってはいけない、ということです。
　しかし、現実には、「個体指定子」 が複合構成になっている現象が、ときどき、起こっています。その複合構成は、典型的に、以下の ふたつの形態をとっていることが多い。

　　（1） ほかの （2つ以上の） 「個体指定子」 を合成して、新たな 「個体指定子」 を構成する。
　　（2） 個体に帰属している データ 項目のなかから、複数 （2つ以上） 使って、「個体指定子」 を
　　　　構成している。

　（2） の現象は、次節 「技術編-8 認知番号の代用 （index-key）」 で説明します。
　本節では、（1） を説明しています [ （1） が良くないことを説明しています ]。すなわち、ほかの （2つ以上の） 「個体指定子」 を使って、新たな 「個体指定子」 を構成するということは、ふたつの 「個体」 の join であって、複合構成になった 「個体指定子」 は、「ほかの 『意味』」 （事態） を言及します。その例として、以下を示しています。

　　従業員 { 部門 コード、従業員番号、従業員名称、・・・ }.

　下線で示した 「マスター・キー （あるいは、ユニーク・キー）」 は、1970年代、構造的 プログラミング で使われた やりかた ですが、「個体と関係」 （あるいは、関係 モデル） という観点からみれば、従業員名称は、部門 コード に対して、なんら、functional dependency はないでしょう。したがって、もし、関係 モデル を前提にするのであれば、以下の構成としなければならないでしょうね。

　　従業員 { 従業員番号、従業員名称、・・・、部門 コード (R) }.

　構文論上、この構成は妥当なのですが、意味論上、部門 コード で null が起こるかもしれない──たとえば、部門に帰属していない 「専務取締役」 とか、「部門に配属されていない」 従業員であれば、部門 コード は null になります。この構成を前提にするのであれば、プログラム は、null に対応するために、4値 ロジック を使わなければならないでしょうね。4値 ロジック を使うのであれば、この構成は妥当です。

　私 （TM） は 「F-真」 を重視しているので （すなわち、「真理条件 （規約 T）」 を重視しているので）、「充足」 概念を前提にして、2値 ロジック を使っています。したがって、null を認めない。しかも、TM では、「個体」 を 「個体指定子」 に従って定立するので、以下の構成になります。

　　従業員 { 従業員番号、従業員名称、・・・ }.
　　部門　 { 部門コード、・・・ }.

　そして、それらを前提にして、以下を 「構成すれば」、「真理条件」 上、新しい 「意味」 を言及することになります。

　　{ 部門 コード (R)、従業員番号 (R) }.

　すなわち、「対の公理」 を前提にすれば、ふたつの集合──ここでは、部門と従業員ですが──をもとにして、それらが構成する ひとつの集合──ここでは、{ 部門 コード (R)、従業員番号 (R) } ──の存在を仮定することができます。そして、構成された集合が、「真理条件」 に照らして、ひとつの 「事態」──ここでは、「配属」──を 「指示する」 ことになるでしょう [ したがって、{ 部門 コード (R)、従業員番号 (R) } は、「F-真」 です ]。この構成法の妥当性は、後日 述べます [ 「技術編-16」 で述べます ]。

　以上の説明でわかるように、ふたつ以上の 「個体指定子」 を使って、ひとつの （新たな） 「個体指定子」 を構成すれば、「個体指定子」 が指示する 「個体」 が ちがう、ということです。

　では、「個体指定子」 は、「無意味な連続番号」 を使うべきか、と言えば、私は、かならずしも、同意しない。というのは、たとえば、自然数 （1, 2, ・・・, n） と 「個体」 を対応しても、もし、「基数 （cardinal number）」 として考えるのであれば、データ 件数を示しているにすぎないので、「意味」 はないし、「序数 （ordinal number）」 として考えるのであれば、「入社順 （個体の発生順）」 を示すので、それなりの 「意味」 はあるけれど、たとえば、ほかの例として、「商品番号」 に対して、自然数を 「1-対-1」 に対応する 「意味」 はないでしょう [ 商品の 「発生順」 を付与しなければならない 「意味」 はないでしょう ]。

　「個体指定子」 は、基本的に、その値が指示関係上、なんらかの 「意味 （指示規則）」 をもつように付値されるべきでしょうね。したがって、その値は、ほかの個体との関係のなかで付与されるのではなくて、個体そのもの-の指示のなかで付与されるべきでしょう。そして、その値のなかには、アルゴリズム を指図するような フラグ （flag） を導入してはいけない──たとえば、「個体指定子」 の値のなかで、しかじかの桁の値が、かくかくの文字 （あるいは、文字列） であれば、これこれの アルゴリズム を適用しなさい、というような指図を導入してはいけない。というのは、「個体指定子」 は、あくまで、「個体」 を指示する シンボル であって、「個体」 を プログラム のなかで どのように使うか は、指示とは べつの配慮だから。

　「個体指定子」 の付値は非常に難しい作業ですが、付値の基本規則は、それぞれの 「個体 （集合）」 のなかで、メンバー を 「並べる」 という規則です。 □