「物が、そのまま、関係として成立している」 という特殊形である。

　Ｔ字形ＥＲ手法では、「ａＲｂ」 を関数として解釈しないで、命題論理の観点から--物と関係は同一の レベル にある、という観点から--、以下のような推論規則を用意してある。

　「複数-対-１」 （あるいは、「複数-対-複数」） の関係が、（数学でいう） 「多価関数」である。
　いわゆる 「HDR-DTL」 の形態をとる可能性が起こるのは、「resource-対-event」 の多価関数と 「event-対-event」 の多価関数である。[ 述語論理では、いわゆる 「HDR-DTL」 の問題点は起こらない。なぜなら、それらは 「従属関数」 として扱われるから。]

　「event-対-event」 の多価関数 （複数-対-１） は、「対応表」 （mapping-list） を作成して一価関数に変換されていて、しかも、前方の複数の event が後方の１つの event にまとめられている形態なので、「対応表」 が 「明細行」 として機能する可能性はない。[「event-対-event」 の 「複数：複数」 の多価関数は、２つの個体間に成立する検証可能性 （traceability） を保証しずらいので、事実上、「HDR-DTL」 としては起こらない。]
　したがって、「HDR-DTL」 の形態が典型的に起こるのは 「resource-対-event」 の多価関数である。

　たとえば、以下を仮想する。

　｛顧客番号、顧客名称｝
　｛商品番号、商品名称｝
　｛受注番号、受注日、受注数｝

　商品と受注との間に、「複数：複数」 の関係が成立しているとすれば、推論規則に従って記述すれば、以下のようになる。

　｛顧客番号、顧客名称｝
　｛商品番号、商品名称｝
　｛受注番号、顧客番号 (R)、商品番号 (R)、受注数、受注日｝

　さて、ここで問題点となるのは、受注日 （しかも、同じ値の受注日） が、複数、起こる、という点である。しかしながら、受注された日は、事実として、１つの値である。

　そこで、以下のような措置を取るとする。

　｛顧客番号、顧客名称｝
　｛商品番号、商品名称｝
　[ 受注 ヘッダー （HEADER）] ｛受注番号、顧客番号 (R)、受注日｝
　[ 受注明細 （DETAIL）] ｛受注番号、明細行番号、商品番号 (R)、受注数｝

　以上のような措置を取れば、問題点となるのは、同じ認知番号 （identifier） を附与された べつべつの （２つ以上の） entity は成立できない （it cannot be）、という規則に抵触してしまう点である。言い換えれば、２つの受注番号のなかで、どちらかが、(R) でなければならない、ということである。

　「event」 の定義から判断して--「DATE （取引日）」 が帰属する entity は 「event」 であるから--、「受注日」 が帰属する受注番号が (R) になることはあり得ない。とすれば、（受注数の帰属する） 受注番号が (R) ということになる。

　ところが、以下の現象があれば、それは矛盾になる。たとえば、以下を仮想する。

　｛出荷番号、出荷日｝

　そして、受注は明細単位に出荷される、とする。とすれば、受注明細は受注番号が (R) であるから、受注番号を出荷に送ることができない。

　｛顧客番号、顧客名称｝
　｛商品番号、商品名称｝
　｛受注番号、顧客番号 (R)、受注日｝
　｛受注番号 (R)、明細行番号、商品番号 (R)、受注数｝
　｛出荷番号、明細行番号 (R)、出荷日｝

　以上の措置では、出荷のなかに送られた明細行番号が、どの受注番号に附属する明細行であるか、という点を同定できない。これが、（命題論理の推論規則のなかに起こる） いわゆる 「HDR-DTL」 の問題点なのである。次回は、この点について解説する。□