「多値の AND」 に関して、2005年 6月16日および 2005年 7月 1日の記述は、「多値の AND」 が、なんらかの形で、アトリビュート を付随する形態として考えて、「HDR-DTL」 になる形態を検討しましたが、「多値の AND」 が認知番号に対して起こるのであれば、以下のように単純に記述すれば良いでしょう。

　┌─────────────────┐　　　　　┌─────────────────┐
　│　　　　　　　営業所　　　　　　Ｒ│　　　　　│　　　　　　　契　約　　　　　　Ｅ│
　├────────┬────────┤　　　　　├────────┬────────┤
　│営業所コード　　│営業所名称　　　│　　　　　│契約書番号　　　│契約日　　　　　│
　│　　　　　　　　│　　　　　　　　│＞───＜│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　　　　　　　│　　　　　　　　│
　│　　　　　　　　│　　　　　　　　│　　　　　│　　  　　　　　│　　　　　　　　│
　└────────┴────────┘　　　　　└────────┼────────┘
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　┼
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　∧
　　　　　　　　　　　　　　　　　　　　　　　　　┌─────────────────┐
　　　　　　　　　　　　　　　　　　　　　　　　　│　　　　契約. 営業所種別　　　ＭＡ│
　　　　　　　　　　　　　　　　　　　　　　　　　├────────┬────────┤
　　　　　　　　　　　　　　　　　　　　　　　　　│契約書番号(R) 　│　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　│営業所コード(R) │　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　│　　　　　　　　│　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　│　　  　　　　　│　　　　　　　　│
　　　　　　　　　　　　　　　　　　　　　　　　　└────────┴────────┘

　
　「多値の OR」と「多値の AND」は、instance のあいだの選言・連言です。 たとえば、3件の データ があって、その 3件の データ が排他的 OR であれば 「多値の OR」 であり──言い換えれば、一時点で、1つの データ しか成立しないということですが──、3件が並立するのであれば 「多値の AND」 です。
　TM では、OR あるいは AND は、「事態の成立・不成立」 を示しています。すなわち、或る一時点で、複数の データ のなかで、1つの事態が成立するのであれば、OR 関係として扱い、高々 1つ （つまり、複数） 成立するのであれば、AND 関係として扱います。

　このときに、やっかいな論点になるのは、instance のあいだに選言と連言が混成されている事態です。
　たとえば、以下を考えてみてください。_（参考）

　（1）（a OR b）　OR c

　（2）（a OR b） AND c

　
　会議室の予約を例にします。
　（1） は、第一候補として、a および b の 2つを予約して──ただし、最終的には、いずれか 1つが選ばれるという前提ですが──、第二候補として c を予約します。一見、a と b は、（構文論的には、） AND の関係に思えますが、意味論的には OR 関係です。そして、第一候補として 2つを予約した事実は、（　） を使って示されています。つまり、第一候補は、集合 オブジェクト になっています。

　（1）は、「多値の OR」 として扱うことができます。たとえば、

　｛予約番号、予約日、・・・｝ [ E ]
　｛予約番号（R）、会議室番号（R）、種別 コード｝ [ MO ]
　｛001、a、1｝
　｛001、b、1｝
　｛001、c、2｝

　
　（2）は、基本的には、「多値の AND」として扱うことになるでしょうが、（a OR b） を記述するのが、 少々、やっかいです。たぶん、「予約番号」 の 「行番号 （あるいは、枝番、追番）」 を使って、OR を 指示することになるでしょう。

　｛予約番号、予約日、・・・｝ [ HDR ]
　｛予約番号、行番号、会議室番号（R）｝ [ DTL ]
　｛001、1、a｝
　｛001、1、b｝
　｛001、2、c｝

　あるいは、こういう事態に対応するために、「候補順位種別 コード」 を用意しているかもしれない。そうであれば、以下のようになるでしょう。

　｛予約番号、予約日、・・・｝ [ HDR ]
　｛予約番号、行番号、会議室番号（R）、候補順位種別 コード｝ [ DTL ]
　｛001、1、a、1｝
　｛001、2、b、1｝
　｛001、3、c、2｝

　


（参考）

　ほかにも、（a AND b） OR c の現象も起こります。たとえば、第一候補は a と b の 2つの部屋を使用するが、第二候補は、c の 1つの部屋を使うことを考えることができるでしょう。このときに、（a AND b） を集合 オブジェクト として考えて、A とすれば、「A OR c」は MO ですが、A そのものは MA ですので、 HDR-DTL 構成となります。もし、この構成を正確に記述するならば、以下になります。

　　[ HDR ]
　　｛予約番号、予約日、・・・｝.

　　[ DTL ]
　　｛予約番号、行番号、会議室番号（R）｝-────────┐
　　[ MO ]　　　　　　　　　　　　　　　　　　　　　　　　　 　　　　　　　 ├×─ 予約会議室
　　｛予約番号（R）、会議室番号（R）、種別 コード｝ ─────┘

　そして、DTL の行番号が種別 コード として使われるでしょう。
　ただ、「意味論的に正確に記述した」 構成が 「構文論的にわかりやすい」 かといえば、そうでもないでしょうね。だとすれば、以下の MO を使って、種別 コード のなかに 「同じ値」 が記入されていたら、AND であるという 「便法」 のほうが 「見やすい」 でしょう （ただし、アトリビュート・リスト のなかには、その点を注記しなけらばならない）。

　　｛予約番号、予約日、・・・｝.
　　｛予約番号（R）、会議室番号（R）、種別 コード｝.

　ただし、この構成は、あくまで、「便法」 です。
　なぜなら、「データ 構造」 を観て、OR 関係あるいは AND 関係を判断できないから。

　ちなみに、以下の事態も考えてみて下さい。

　　（1） （p AND q） OR （r AND ｓ）.
　　（2） （p OR q） AND （r OR ｓ）.