● みなし概念

　TM’──TM ではない点に注意されたい──では、「みなし概念」 として以下の 2つが用意されている。

　　（1） みなし entity
　　（2） 概念的 スーパーセット

　
　「みなし entity」 概念は、「entity ではないが、entity とみなす」 考えかたである。TM ──TM’ ではない点に注意されたい──では、entity は以下のように定義されている。

　　　Entity である ＝ _Df 認知番号を付与された対象である。

　すなわち、「みなし entity」 概念は、認知番号が付与されていない対象であっても、擬似 entity として セット （集合） を作る考えかたである。

　TM は、意味論 （指示規則） を前提にして entity を認知して、entity を構文論 （文法） に従って組み合わせて 「構造」 を作る体系である。TM の アウトプット （作図された「構造」） に対して、いっそう、意味論 （指示規則） を強く適用したのが TM’ である。TM’ では、認知番号を付与されていない対象でも、内包 （「性質」） を判断規準にして外延 （「みなし entity」） を作る。現象的には、以下の 4つが基本形になる。

　　（1） resource のなかに、event 的性質が混入している。
　　（2） resource のなかに、ほかの resource の性質が混入している。
　　（3） event のなかに、resource 的性質が混入している。
　　（4） event のなかに、ほかの event の性質が混入している。

　「みなし entity」 を データ 解析の観点から言えば、(3) が重視されるが、「みなし entity」 を導入した理由は、（1） にある。（1） の典型的な現象が、たとえば、以下の例である。

　　　｛従業員番号、従業員名称、・・・、入社日、・・・｝.

　TM では、entity を 2種類 （event と resource） に類別して、以下のように定義している。

　　　event である ＝ _Df 性質として日付が帰属する。
　　　resource である ＝ _Df event 以外の entity をいう。

　したがって、上述した 「従業員」 を例にすれば、従業員のなかに入社日が帰属していることは定義に反する （矛盾になる）。コッド 関係 モデル の関数従属性から言えば、「従業員」 のなかに入社日を構成しても間違いにはならないが、意味論 （event と resource） の前提を導入した TM では違反になる。したがって、TM の定義に反しないように、entity を 「純化」 するために、「みなし entity」 概念を導入した。

　「みなし概念」 のもう 1つである 「概念的 スーパーセット （みなし スーパーセット）」 は、事業過程 （管理過程） を改善するために導入された概念である。TMD （TM Diagram） を作成したあとで、「事業の観点から判断して、構造が妥当かどうか」 を検証するために導入された概念である。

　
　● 概念的 スーパーセット （みなし スーパーセット）

　「概念的 スーパーセット （「みなし スーパーセット」 とも云う） は、「概念的」 という形容詞が付与されているように、そのもの-の性質は記述されない。つまり、家族的類似性のある セット 群を括るために導入された総称 （label） であって、数学的な クラス 概念ではない。たとえば、以下を考えてみる。

　　　｛出荷先番号、出荷先名称、・・・｝.
　　　｛請求先番号、請求先名称、・・・｝.
　　　｛納入先番号、納入先名称、・・・｝.
　　　｛支払先番号、支払先名称、・・・｝.

　以上の セット （entity） に対して、たとえば、「取引先」 という概念的 スーパーセット を作る。

　　　[ 取引先 ]
　　　　　↑
　　　　　× （概念的 スーパーセット）
　　　　　｜
　　　　　├｛出荷先番号、出荷先名称、・・・｝.
　　　　　├｛請求先番号、請求先名称、・・・｝.
　　　　　├｛入荷先番号、納入先名称、・・・｝.
　　　　　└｛支払先番号、支払先名称、・・・｝.

　概念の階を 1つ上位にして、概念的 スーパーセット を作ったら、次に、概念的 スーパーセット を起点にして、それぞれの セット の関係を検証する。上昇したら、ふたたび、下降するというのが概念検討の常道である。

　　　[ 取引先 ]
　　　　　｜
　　　　　× （概念的 スーパーセット）
　　　　　↓
　　　　　├｛出荷先番号、出荷先名称、・・・｝.
　　　　　├｛請求先番号、請求先名称、・・・｝.
　　　　　├｛入荷先番号、納入先名称、・・・｝.
　　　　　└｛支払先番号、支払先名称、・・・｝.

　たとえば、「出荷先」 と 「請求先」 を以下のように検証する。

　　（1） 2つの セット は、いちぶ、交わる。
　　（2） 2つの セット は、同じ外延である。
　　（3） いずれかの セット が、もう 1つの セット を包摂する。
　　（4） 2つの セット は、交わらない。

　同じように、「入荷先」 と 「支払先」 との関係を検証する。さらに、「出荷先」 と 「入荷先」 との関係を検証し、「請求先」 と 「支払先」 の関係を検証する。そういうふうに検証すれば、家族的類似性を示す entity のあいだで、類似点と相違点を対比できるし、さらに、データ の重複度なども検証できる。
　「概念的 スーパーセット」 は、entity ばかりではなくて、アトリビュート に対しても適用する。たとえば、以下を考えてみる。

　　　｛商品番号、商品名称、・・・、商品単価、・・・｝.
　　　｛受注番号、商品番号 (R)、受注日、・・・、受注単価、・・・｝

　以下のように、「単価」 として、「概念的 スーパーセット」 を作る。

　　　　[ 単価 ]
　　　　　↑
　　　　　× （概念的 スーパーセット）
　　　　　｜
　　　　　├｛商品番号、商品名称、・・・、商品単価、・・・｝.
　　　　　└｛受注番号、商品番号 (R)、受注日、・・・、受注単価、・・・｝

　概念の階を 1つ上位にして、概念的 スーパーセット を作ったら、次に、概念的 スーパーセット を起点にして、それぞれの アトリビュート の関係を検証する。

　　　　[ 単価 ]
　　　　　｜
　　　　　× （概念的 スーパーセット）
　　　　　↓
　　　　　├｛商品番号、商品名称、・・・、商品単価、・・・｝.
　　　　　└｛受注番号、商品番号 (R)、受注日、・・・、受注単価、・・・｝

　すなわち、「単価」 が、どの entity で使われているのかを確認して、それぞれの 「単価」 が どのような 「意味」 として使われているのかを検証する。さらに、「単価」 の使いかた次第では、「単価」 に対して、認知番号を与えて、独立した entity として、「単価」 戦略 （「価格」 体制） を考慮したほうが良いかどうかを ユーサ゛ と協議するかもしれない。

　また、「概念的 スーパーセット」 は網羅性を検証するために使うこともある。たとえば、以下を考えてみる。

　　　｛新入社員研修番号、研修実施日、・・・｝.
　　　｛マネジャー 研修番号、研修実施日、・・・｝
　　　｛セカンド・キャリア 研修番号、研修実施日、・・・｝

　以上の研修に対して、「教育」 という 「概念的 スーパーセット」 を考えてみる。

　　　　[ 教育 ]
　　　　　↑
　　　　　× （概念的 スーパーセット）
　　　　　｜
　　　　　├｛新入社員研修番号、研修実施日、・・・｝.
　　　　　├｛マネジャー 研修番号、研修実施日、・・・｝
　　　　　└｛セカンド・キャリア 研修番号、研修実施日、・・・｝

　次に、「教育」 という観点からみて、研修体制が網羅されているのかどうかを検証する。

　　　　[ 教育 ]
　　　　　｜
　　　　　× （概念的 スーパーセット）
　　　　　↓
　　　　　├｛新入社員研修番号、研修実施日、・・・｝.
　　　　　├｛マネジャー 研修番号、研修実施日、・・・｝
　　　　　└｛セカンド・キャリア 研修番号、研修実施日、・・・｝

　たとえば、「中途採用者」 に対する研修は考慮されていないのかどうかを確認する。