「resource」 にも、「header-details （以下、HDR-DTL）」 形式はある。　以下を考えてみる。

　（1） 取引の対象として 「法人」 がある
　　　 （identifier は 「法人 コード」 とする）。
　（2） 顧客管理として、与信管理などは、「法人」 を単位としている。
　（3） ただし、契約するときには、「法人」 の 「窓口」 を対象とする
　　　 （契約と窓口の identifier は、それぞれ、契約番号と窓口 コード とする）。
　（4） 「窓口」 は複数ある。

　以上の構造は、顧客管理は 「法人」 を単位としていて、取引 （契約） は 「窓口」 を単位としている、という構造である。

　さて、「法人」 と 「契約」 を、それぞれ、「resource」 と 「event」 として扱うことは正しい。

　　法人　｛法人コード、法人名称,...｝ [ R ]
　　契約　｛契約番号、契約日,...｝ [ E ]

　さらに、与信管理などが 「法人」 を単位にしているので、与信管理は 「VE」 として扱う。

　　法人　　 　　 ｛法人コード、法人名称,...｝ [ R ]
　　法人. 与信　｛法人コード (R)、...｝ [ VE ]
　　契約　　　 　 ｛契約番号、契約日,...｝ [ E ]

　さて、ここで論点になるのが 「窓口」 である。「窓口」 の扱いとしては、以下の 3つが想像できる。

　（1） 単独の entity （「resource」）
　（2） 「法人」 の 「entity. role」
　（3） 「法人」 の 「HDR-DTL」

　「窓口」 が 「単独の entity （「resource」） になることはあり得ない。
　なぜなら、「窓口」 を entity （「resource」） として扱えば、取引の対象となっている 「法人」 の組織構造を当方が保守することになってしまい、当方には、そういう保守責任はないし、「窓口」 は、あくまで、取引している 「法人」 が契約の際に通知してくる組織情報であって、当方には保守責任はない。

　とすれば、「entity. role」 を考えることができるが、「窓口」 は契約の単位で成立して、同時に、複数の 「窓口」 が成立することができるので、データ の 「多義」 ではない。したがって、「entity. role」 も成立しない。

　「HDR-DTL」 形式として、DTL の単位で契約が成立して、DTL を包括した管理情報として HDR が成立している、と考えるのが妥当であろう。とすれば、「窓口」 は、以下の扱いになる。

　　法人 HDR　 ｛法人コード、法人名称,...｝[ R ]
　　法人 DTL　 ｛法人コード、窓口コード、...｝[ R ]
　　法人. 与信　｛法人コード (R)、...｝[ VE ]
　　契約　　　 　｛契約番号、法人コード (R)、窓口コード (R)、契約日,...｝[ E ]

　ちなみに、データ を詳細に解析すれば、「窓口コード」 の値が以下のように成立する可能性もある。

　（1） 窓口 コード 01 は 「部門 コード」 である。
　（2） 窓口 コード 02 は 「事業所 コード」 である。
　（3） 概念的には、01 は 02 のなかにふくまれる構造である。

　ただ、前述したように、当方では、取引の対象となっている 「法人」 の組織構造を保守する責任はないのであって、「部門 コード が事業所 コード にふくまれる」 という構造は 「法人」 側の構造であって、当方では、あくまで、契約の際に、法的な対象として 「窓口」 を扱っているにすぎない。ただし、DA （Data Analyst） は、「窓口 コード」 を解析するときには、以上のような現象があることを即座に思い浮かばないようでは落第である。