[ 前提 ]

　　営業所 [ R ]
　　　｜
　　　× （営業所区分 コード）
　　　│
　　　├｛国内営業所｜営業所 コード, 営業所名称,・・・｝
　　　│
　　　└｛海外営業所｜営業所 コード, 営業形態, 営業所名称,・・・｝

　　なお、営業形態は、以下の意味とする。
　　　- 現地経営
　　　- 国内からの派遣経営

　
[ 考えかた ]

　実装形として、以下の テーブル を考える。

　（1） ｛営業所 コード, 営業所区分 コード, 営業所名称,・・・｝.
　（2） ｛営業所 コード, 営業形態｝.

　以上の実装形にした理由は、おそらく、以下の点を配慮したのであろう。

　（1） 営業所を、つねに、一覧的に表示しなければならない。
　（2） 営業所の一覧表示では、国内と海外が、べつべつの集合として表示されていれば良い。
　（3） 営業形態を表示しなくても良い。

　
　構文論として、営業形態を営業所 コード から切り離すための整合性はない。言い換えれば、営業形態は、営業所 コード （営業所の集合） のなかに帰属していなければならない データ である。
　もし、営業形態を営業所 コード （営業所の集合） から切り離すとすれば、「営業形態を、（情報のなかで） 表示しなくても良い」 ということを理由にするなら──営業所のなかで、営業形態は、記録対象にはなっているが、管理対象となっていないなら──、意味論的に観て、営業形態は、「VE」 として扱われなければならない。そうだとすれば、そもそも、「論理設計」 が妥当でなかった、ということである。つまり、「論理設計」 は、以下の構造でなければならない。

　　営業所 [ R ]
　　　｜
　　　× （営業所区分 コード）
　　　│
　　　├｛国内営業所｜営業所 コード, 営業所名称,・・・｝
　　　│
　　　└｛海外営業所｜営業所 コード, 営業所名称,・・・｝

　｛営業所 コード（R）、営業形態｝. [ VE ]

　
　「論理設計」 のなかで、整合的な意味単位として作られた 個体 （正規形） を変形して （正規形を崩して） 実装することは、使っている RDB が粗悪な プロダクト でないかぎり、まず、考えられない。「物理設計」 というのは、使っている ハードウェア や ソフトウェア （RDB、言語など） の特性に合うように、「論理設計」 を調整する作業であって、「論理設計」 で記述された 「意味」 を崩すことではない。「意味 （の単位）」 を崩せば、それ （意味） を復原するための負荷を、アルゴリズム が担うことになる。もし、「論理設計」 と 「物理設計」 が、大幅に乖離するのなら、「論理設計」 の妥当性──あるいは、使っている ソフトウェア （RDB など） の品質──を疑えば良い。