以下を例にする。

[ 前提 ]

　（1） 取引先として、出荷先と納入先を管理する。取引先 コード を認知番号とする。
　　　　- 取引先には、出荷先と納入先が混ざっている。
　　　　- 取引先には、出荷先と納入先を切り離すための指標 （区分 コード） はない。
　　　　- 出荷先と納入先は、取引先 コード の値を観て、判断している。

　（2） 地域を管理する。地域 コード を認知番号とする。

　
[ 要件 ]

　（1） 出荷先が担当している地域を管理する。
　（2） 地域のなかの納入先を管理する。

　
[ データ 構造 ]

　（1） 取引先 ｛取引 先コード、名称、...｝.
　（2） 地域 ｛地域 コード、名称、...｝.
　（3） 取引先. 地域. 対照表 ｛取引先 コード (R)、地域 コード (R)｝.

　
　さて、この対照表は、バリデーション・ルール を記述する対照表である。
　要件として、以下の 2つの バリデーション・ルール がある。

　（1） 出荷先が担当している地域。
　（2） 地域のなかの納入先。

　
　この対照表のなかに、バリデーション・ルール として、2つの 「意味」 が混ざっている。
　とすれば、2つの 「意味」 を、べつべつに記述したいが──べつべつの対照表にしたいが──、べつべつにするための形式的な指標がない。言い換えれば、出荷先および納入先は、取引先 コード の値を使って判断しているので、（取引先の） サブセット を作ることができない。1つの entity に対して、サブセット を作るためには、形式的要件 （null が生じること） か、実質的な要件 （区分 コード が宣言されていること） がなければならない [ 197ページ 参照 ]。

　したがって、この対照表は、2つの 「意味」 が混ざったまま、1つの対照表として定立するしかない。そして、1つの 「意味」 は、プログラム の アルゴリズム のなかで扱うしかない。
　あるいは、「INDEX-only」 を使って、2種類の CREATE INDEX を用意するしかない。

　
　ただ、データ 構造を 「実装する」 際 （あるいは、物理設計では）、たとえば、この対照表を、物理的に 2つに切り離して、それぞれ、「出荷先が担当している地域」 と 「地域のなかの納入先」 を、べつべつに ロード することはできる。そうすれば、プログラム の アルゴリズム は単純になる。