「個体指定子 （entity-setter）」 は、atomic （すなわち、「one and only」 の データ項目） でなければならないことを前回 「技術編-7」 で述べました。TM では、「情報 （の意味）」 を 「解析」 する際に、最小の （atomic な） 個体を 「entity」 としています。TM の 「関係文法」 は、数学の 「解析 （analysis）」 手続きを前提にして作られています──数学の 「解析」 とは、証明しなければならない対象 A が存在しているとき、A が成り立つためには、B₁ が成り立たなければならないことと示し、さらに、B₁ が成り立つためには、B₂ が成り立たなければならないことを示すというふうに、以下のように、順次、対象を導出する手順です。

　　　　　A → B₁ → B₂ → ... → B_n.

　TM では、「既知の ことがら」 B_n として──すなわち、最小単位たる 「打ち止め」 として── entity を考えています。
　そして、entity は、事業過程・管理過程のなかで 「同意された」 個体でなければならない。その 「認知の同意」 を示すのが、事業過程・管理過程のなかで使われている 「個体指定子 （すなわち、コード 体系のなかで定義されている認知番号）」 です。

　上述の例では、{ 部門 コード、作成日、... 数量、... } という構成は──ただし、下線は 「unique-key」 を示しますが──、「しかじかの部門は、かくかくの時刻 t において、××台の生産を計画した」 という事態 （複文） を記述しているのであって、いまだ、「解析」 の途上にある状態です──言い換えれば、「解析」 が終わっていない状態です。この状態で認知される entity は、「部門」 のみであって、「生産計画」 は、個体指定子が付与されていないので、entity にはならない。しかじかの 「部門」 が生産計画を作成したという事実を記述するのであれば──しかも、「生産計画」 を独立した個体 （entity） として認知するための個体指定子 (entity-setter） がないのであれば──、以下のように記述するのが正しいでしょう。

　┌─────────────────┐　　　　　┌─────────────────┐
　│　　　　　　　部　門　　　　　　Ｒ│　　　　　│　　　　　部門. 生産計画　　　ＶＥ│
　├────────┬────────┤　　　　　├────────┬────────┤
　│部門コード　　　│部門名称　　　　│　　　　　│部門コード（Ｒ）│作成日　　　　　│
　│　　　　　　　　│　　　　　　　　├┼──○＜│　　　　　　　　│台数　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　　　　└────────┴────────┘

　「部門. 生産計画」 は、「みなし entity」 です──「みなし entity」 は、後日、説明します。「生産計画」 は、個体指定子を付与されていないので、それを作成した 「部門」 の個体指定子を継承します──ちなみに、(R) は、「Re-used」 の意味であって、Reference-key ではない点に注意してください。すなわち、(R) は、個体が──それが主体 （subject） であれ、事態 （event） であれ──、ほかの主体に作用しているか、あるいは、ほかの事態 （case） に関与していることを示す符帳です。そして、○ は、リレーションシップ の 「ゼロ の cardinality」 といい、生産計画のほうでは、対応する occurrence が無いこともある、という意味です──すなわち、生産計画のほうでは、すべての occurrence （∀x） が対応している （全射かつ単射） のではない （¬∀x） ということ、言い換えれば、いくつかの対応する occurrence が存在する （¬∀x ＝ ∃x） ということを示しています。

　この構成 （「部門. 生産計画」） を前提にして、もし、「indexing」 を使うのであれば──勿論、「indexing」 を使わないでも良いのですが、「indexing」 を、もし、使うとすれば──、以下の データ 項目を create index の対象にすることは、プロダクト としての RDB の使用上、禁止にはなっていない、ということです。ただし、「indexing」 は、「関係 モデル」 とは無関係の事項です。

　　　　create index （部門 コード, 作成日）