2006年 2月 1日 応用編-1 「3P 形式の伝票」 (identifier の流用) >> 目次にもどる
2011年 1月 1日 補遺  

 

 3P 形式の伝票を 「相違の サブセット」 として扱っていることは正しい。
 ただ、以下の文は、誤解を与えるかもしれない。

  ただし、こういう事象を、「みなし エンティティ」 (後述、応用編-19 参照) として扱うこともできる。

 「相違の サブセット」 と 「みなし entity」 のちがいは、後続 event に対して 「認知番号を継承するかどうか」 という点にあることは、TM (T字形 ER手法) の文法を知っていれば、理解できるでしょう。すなわち、「みなし entity」 として扱えば、「みなし entity」 の (R) は、後続 event に継承できない。

  {受注番号、品目 コード (R)、得意先 コード、受注日、受注数}.
  {受注番号 (R)、出荷日}.
  {受注番号 (R)、請求日、請求金額 (D)}.

 3P 形式の伝票のなかで、正常営業循環が閉じていれば、「みなし entity」 を使うことは正しいが、たとえば、もし、「請求」 が終わってから、請求書 (受注伝票) を、ほかの event と対応するのであれば、受注番号 (R) は継承できない。

 また、3P 形式であっても、出荷用に使われている 受注番号 (R) と請求用に使われている 受注番号 (R) が、実際には、それぞれ、出荷番号および請求番号として認知されているのであれば──すなわち、形式的には、受注番号を流用していても、実地の使用では、出荷番号および請求番号として認知されているのであれば──、3P 形式は、それぞれ、単独の entity とするのが正しい。そういう典型的な例として、たとえば、「製番」 がある。受注から出荷まで、1つの 「製番」 を使っていても、受注時には受注番号として使われ、出荷時には出荷番号として使われているのであれば、それぞれ、受注番号および出荷番号とするのが正しい──ただし、認知番号を受注番号としても、「製番」 であることを注記しておいてほうが良い。

 ┌─────────────────┐
 │       受 注       │
 ├────────┬────────┤
 │受注番号    │        │
 │(製番)    │        │
 │        │        │
 └────────┴────────┘

 ┌─────────────────┐
 │       出 荷       │
 ├────────┬────────┤
 │出荷番号    │        │
 │(製番)    │        │
 │        │        │
 └────────┴────────┘

 
 そして、受注と出荷が対応すれば、文法どおりに作図すれば、以下のような構造になる。

 {受注番号、・・・}.
 {出荷番号、受注番号 (R)、・・・}.

 受注番号 (R) と出荷番号は、事実上、同じである。したがって、受注番号 (R) は、実装しないことを取消線を使って指示しなければならない。

 {受注番号、・・・}.
 {出荷番号、受注番号 (R)、・・・}.

 3P 形式であっても、単独の entity として認知する例は、昨年 (2005年 9月末に) 出版した 「赤本」 (「データベース 設計論──T字形ER」、184 ページ) に示したので参照されたい。 □

 



[ 補遺 ] (2011年 1月 1日)

 「みなし entity」 は、TM (「T字形 ER法」 の改良版) の体系には入っていない。というのは、「みなし entity」 は、構文論 (文法)──すなわち、記号の演算──のなかで構成される項ではないので。「みなし entity」 は、意味論──すなわち、記号の外に立って、記号の意味を考えること──を強く適用して構成される項です。そのために、構文論を主体にした TM の体系に入れないで、TM を拡張した──意味論を強く適用した──体系として TM’のなかで 「みなし entity」 を扱っています。TM および TM’ については、「赤本」 を参照してください。

 「みなし entity」 は、構文論のなかで構成される項でないので、「関係」 の文法を持っていない。したがって、「みなし entity」 は、(派生元の entity との関係を除いて、) 他の entity とは関係 (関数) を構成しない。







  << もどる HOME すすむ >>
  「T字形ER データベース設計技法」を読む