たとえば、以下の情報を前提にする。

　｛顧客番号、顧客名称、職業 コード、役職 コード｝.

　
　この例は、拙著「論理 データベース 論考」 219ページ の例題を簡略にした。
　以上の情報から、以下の entity を作る。

　顧客　｛顧客番号、顧客名称・・・｝.
　職業　｛職業 コード、・・・｝.
　役職　｛役職 コード、・・・｝.

　
　以上の entity から、以下の構造を作る。

　顧客　｛顧客番号、・・・｝.
　職業　｛職業 コード、・・・｝.
　顧客. 職業. 対照表　｛顧客番号 (R)、職業 コード (R)｝.
　役職　｛役職コード、・・・｝.
　顧客. 職業. 役職. 対照表　｛顧客番号 (R)、職業 コード (R)、役職 コード (R)｝.

　顧客. 職業. 対照表は、途中の推論なので、遺さない、とする。
　したがって、最終的には、以下の構造となる。

　顧客　｛顧客番号、・・・｝.
　職業　｛職業 コード、・・・｝.
　役職　｛役職 コード、・・・｝.
　顧客. 職業. 役職. 対照表　｛顧客番号 (R)、職業 コード (R)、役職 コード (R)｝.

　
　さて、職業のなかには、役職 コード のない職業もある。たとえば、小説家とか。
　したがって、対照表には、null値が生じるので、以下のように、サブセット を作る。

　　顧客. 職業. 役職. 対照表
　　　　　　　　│
　　　　　　　　× null （役職 コード）
　　　　　　　　│
　　　　　　　　├｛顧客番号 (R)、職業 コード (R)、役職 コード (R)｝
　　　　　　　　│
　　　　　　　　└｛顧客番号 (R)、職業 コード (R)｝

　
　さらに、「専業主婦」 を職業として コード 化していないのであれば、職業 コード にも null が生じることもある。したがって、以下の構造となる。

　　顧客. 職業. 役職. 対照表
　　　　　　　　│
　　　　　　　　× null （職業 コード、役職 コード）
　　　　　　　　│
　　　　　　　　├｛顧客番号 (R)｝
　　　　　　　　│
　　　　　　　　├｛顧客番号 (R)、職業 コード (R)｝
　　　　　　　　│
　　　　　　　　└｛顧客番号 (R)、職業 コード (R)、役職 コード (R)｝

　
　「論理 データベース 論考」 222ページ の試案では、役職 コード のない職業もあるので、職業と役職とを単純に結ぶことはできない、と判断して、対照表を作成していない。この判断は、事業のなかで、顧客として、だれを対象にしているか、という前提次第である。拙著の例題は、或る生命保険会社の実例を簡単な例題にして使った。したがって、顧客として、会社員のみを対象としている訳ではない。（会社員のほかに、） 専業主婦もいれば、農業に従事する人たちもいれば、自由業の人たちもいる。かつ、会社員であっても、役職の データ が null である人たちが多数いた。さらに、「不労所得」 （たとえば、マンション 賃貸収入とか） を得ている人たちもいる。そういう事業を前提にして、職業と役職とのあいだには、直接の関連はない、と記述したのであって、ふつうなら、職業と役職とのあいだに関連を考えるのが妥当だと思う。

　逆に言えば、まず、上述の対照表を作成して、それから、以下の点を確認すればよい。

　（1） 職業 コード が成立しないことは起こるか （たとえば、不労所得など）。
　（2） 役職 コード が成立しない職業はあるか （たとえば、自由業など）。
　（3） 役職が成立しても、職業は成立しないことはあるか （ちょっと、具体例が思い浮かばないが、、、）。

　もし、（1） と （2） が多いようであれば、職業 コード と役職 コード との間には関連を結ばないほうが良い。そういう事態であれば、役職 コード は、ほかの目的 （データ 使用の目的） のために使われていると思って良い──たとえば、その人 （高位の役職を得ている人） を起点にして、その人の部下たちを商品 セールス の対象とするとか。もし、そういう事態のなかで （会社員のみを対象にしていない事業のなかで）、役職は、ほかの使用目的がないのであれば、おそらく、無意味な データ である。