2009年 8月 1日 「技術編-33 みなし スーパーセット」 を読む >> 目次にもどる
2018年 5月15日 補遺  


 

 「みなし スーパーセット」 は単純に言えば 「クラス」 概念です。「赤本」 で、「entity に対して適用した例」 と 「アトリビュート に対して適用した例」 を示しているので、取り立てて補足説明はいらないでしょう。

 「みなし スーパセット」 は、「セット」 概念で謂えば──「ZF の公理系」 では──、以下の 2つの公理を使った 「和集合」 と云ってもいいでしょう。

 (1) 対の公理

 (2) 置換公理

 つまり、ふたつ (以上の) 集合──たとえば、A および B ──が存在していて、それらの和集合 { A ∪ B } において、性質 f (x) が認識されるのであれば、{ A ∪ B } を ひとつの集合として考えていい、ということ。この意味では、「クラス」 と 「セット」 を同じと考えていいでしょう。セット に対して上位の セット (和集合) を仮想するという意味で 「スーパーセット」 と言いかたをしています。さらに、和集合の性質を TM 上 記述しない、という意味において──すなわち、和集合の性質を記述しないけれど、和集合が存在するとみなす、という意味において──、「みなし」 という言いかたをしています。

 「みなし スーパーセット」 の使いかたは、色々と考えられるのですが、一番に基本的な使いかたは、「みなし スーパセット」 を生成したら、「みなし スーパーセット」 と 「セット」 のあいだに成立する関係を 「セット と サブセット」 の関係として翻訳する使いかたです。そして、「セット と サブセット」 のあいだに成立する関係上の性質──すなわち、サブセット 間の排他的関係とか、サブセット の総和がセット になるとか──を検証すればいいでしょう。たとえば、「赤本」 で、「営業所」 entity と 「特約店」 entity に対して、「取扱店」 という 「みなし スーパーセット」 を構成していますが、「取扱店」 において、「営業所」 entity と 「特約店」 entity は排他的かどうか──言い換えれば、「営業所かつ特約店は存在しない」 こと──を確認すればいいでしょう。アトリビュート に対する 「みなし スーパセット」 の例として 「単価」 を示していますが──「商品単価」 と 「受注単価」 に対して、「単価」 という 「みなし スーパーセット」 を構成していますが──、アトリビュート に対する 「みなし スーパセット」 も、entity に対する 「みなし スーパーセット」 と同じように、「セット と サブセット」 に翻訳して、「構造の妥当性」 を調べればいいでしょう。

 実地の作業では、「みなし スーパーセット」 は、以下の ふたつを検討するために使います。

 (1) 構造の妥当性

 (2) 改善案の提言

 「構造の妥当性」 というのは、もし、「みなし スーパーセット」 の構成員である セット のあいだで、いちぶ まじわる現象が起これば、まじわりを除去するために なんらかの対応をしなければならない、ということです。たとえば、「取引先」 という概念 (「みなし スーパーセット」) の下に、「納入先」 entity と 「出荷先」 entity が存在していて、それらの entity のあいだに いちぶ まじわり が起これば、妥当な構造ではないので、「取引先」 という概念を実際の entity として具体化して [ 構成して ]、「納入先 コード」 および 「出荷先 コード」 を 「分類 コード」 として使うように訂正したほうがいいでしょう。

 「改善案の提言」 というのは、たとえば、前述した例で謂えば、「取扱店」 の サブセット として、「営業所」 あるいは 「特約店」 が実存しているのですが、他の サブセット を新たに導入できないか、と [ たとえば、「代理店」 という新機能を導入できないか、と ]。こういう概念の検討は、勿論、描かれた構成のみを観ていても生まれないので、事業に関する知識を持っていなければ浮かばないでしょう。

 以上の ふたつの検討は、「みなし スーパーセット」 が たとえ 概念であっても、勿論、システム・エンジニア のみが憶測で おこなうのではないのであって、ユーザ といっしょに進めるべき検討です。 □

 



[ 補遺 ] (2018年 5月15日)

 「みなし entity」 も 「(概念的) スーパーセット」 も クラス f (x) です。そして、クラス を生成する一般手続きはない。つまり、クラス は自由に生成できるということです。TM では、クラス を生成する起点は、次の 2つです。

 (1) セット に対して クラス を生成する。

 (2) セット の アトリビュート に対して クラス を生成する。

 (1) が 「スーパーセット」 で、(2) が 「みなし entity」 です。そして、勿論、生成した クラス に対して さらに 高階の クラス を生成することができます。

 「スーパーセット」 を生成する第一目的は、個体指示子の妥当性を検証するためです。というのは、TM は現に使用されている XX 番号や XX コード を起点にして entity (セット) を作るので、TM (TM’) の体系のなかでは、それらの番号・コード の妥当性を問う技術がない。そのために、いったん生成した entity (セット) が構造のなかで妥当かどうかを検証するために 「スーパーセット (クラス)」 を作る。ふたつの セット (A と B) を前提にして或る クラス を考えて、クラス を セット に読み替えれば、ふたつの セット (A と B) は サブセット に翻訳できる。そうすれば、サブセット のあいだには次の 5つの関係が考えられる。

 (1) A と B は別々である。
 (2) A は B をふくんで、さらに拡がっている。
 (3) B は A をふくんで、さらに拡がっている。
 (4) A と B は一部交わる。
 (5) A と B は同じである。

 問題となるのは、(4) の場合です── A と B が 「切断」 にはなっていない。すなわち、XX 番号・XX コード が 「形式上」 妥当ではない。

 「スーパーセット」 を生成する第二目的は、本文中に述べているように、ビジネス の可能性を探るためです。これについては、個々の環境条件・構成条件に依るので一般論では ソリューション がない──コンサルタント あるいは DA (Data Analyst) の腕の見せ所でしょうね。






  << もどる HOME すすむ >>
  目次にもどる