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

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

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

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

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

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

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

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

　
　さらに、もっと やっかいな点になるかもしれないのは、連続番号が、ファミリー・コード ごとに付与されているかもしれない、という点である。すなわち、連続番号のなかには、同じ値が起こり得るかもしれない──ファミリー 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 を 「コード 変換 テーブル」 にしています。

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