以下を例にして考えてみる。

　（1） A 社と B 社が取引をしている。B 社は A 社の関連企業である。
　（2） A 社は B 社に受注する。（受注番号が identifier である。）
　（3） A 社の受注 データ のなかで、営業所 コード が使われている。
　　　ただし、営業所 コード は A 社が使っている コード であって、B 社では独自の店番号を使っている。
　（4） B 社の店番号とA 社の営業所 コード には、「1-対-1」 の対応関係が成立している。
　（5） A 社が B 社に対して受注を照会するときには営業所 コード を使っている。

　さて、B 社用のＴ字形 ER図を作成してみる。

　営業所 コード の扱いは以下の 2つを考えることができる。

　（1） 営業所 コード を identifier として扱う。
　（2） 営業所 コード を identifier として扱わない。

　したがって、営業所 コード は、技術的には、以下の 3つとして扱うことができる。

　（1） identifier
　（2） アトリビュート
　（3） VE

　
1. 営業所 コード を identifier として扱う

　営業所 コード を identifier として扱えば、営業所 entity が生成される。
　営業所 entity と店 entity の間に対照表を生成して、対照表を 「コード 変換 テーブル」 として使う。

　　受注 [ E ]
　　{ 受注番号、取引先 コード (R)、営業所 コード (R)、 受注日、受注数 }.

　　営業所 [ R ]
　　{ 営業所 コード }.

　　店 [ R ]
　　{ 店番号、 店名称 }.

　　営業所. 店. 対照表：
　　{ 営業所 コード (R)、店番号 (R) }.

　
2. 営業所 コード を identifier として扱わない （アトリビュート として扱う）

　営業所 コード を identifier として扱わないで、 店 entity のなかの アトリビュート として扱う。
　営業所 コード は B 社の コード ではないので、B 社には営業所 コード に対する保守責任はない。
　したがって、営業所 コード を店番号に対する 「備考 （コメント 行）」 として扱う。
　そして、A 社からの問い合わせに対応するために──「コード 変換」 のために──、店 entity に対して、「営業所 コード ＋ 店番号」 の インデックス を用意する。

　　受注 [ E ]
　　{ 受注番号、取引先 コード (R)、営業所 コード (R)、 受注日、受注数 }.

　　店 [ R ]
　　{ 店番号、店名称、営業所 コード (D) }.

　
3. 営業所 コード を identifier として扱わない （VE として扱う）

　営業所 コード が B 社の コード ではないことを明示するのなら、営業所 コード を VE として扱う。

　　受注 [ E ]
　　{ 受注番号、取引先コード (R)、営業所 コード (R)、受注日、受注数 }.

　　店 [ R ]
　　{ 店番号、 店名称 }.

　　店. 営業所 [ VE ]
　　{ 店番号 (R)、営業所 コード (D) }.

　したがって、VE を コード 変換 テーブル として使うことができる。

　
4. identifier・アトリビュート・VE の相違点

　営業所 コード を identifier として使えば、「明示的に （explicitly）」 コード 変換 テーブル を対照表の形として生成することができる。ただ、論点になるのは、営業所 entity が B 社にとって保守責任があるのかどうかという点である。言い換えれば、B 社が営業所 entity を 「resource」 として管理するなら、アトリビュート として、なにを管理するのか、という点が論点になる。営業所 entity は単なる名称 テーブル に過ぎないのではないか、という点が論点になる。
　もし、名称 テーブル に過ぎないのなら、リレーションシップ は生成されないし、対照表も生成されない。
　ただし、B 社が A 社の関連企業であり、A 社の営業所を 「意識的に」 認知しているとすれば、営業所 entity は 「resource」 として成立する。

　営業所 コード を （店 entity の） アトリビュート にすれば、営業所 コード が 「備考」 扱いとなるが、コード 変換 テーブル を 「明示的に」 生成することができない。言い換えれば、営業所 コード は、あくまで、A 社の コード 体系であって、A 社から問い合わせがあれば参照できればよい──参照用の インデックス を用意しておけばよい──、という考えかたである。B 社は A 社の関連会社ではあるが、あくまで、独立した法人であるという意識が強い考えかたである。

　営業所 コード を VE 扱いにすれば、営業所 コード を店 entity から切り離して──B 社の データ 構造のなかでは A 社の営業所を排除して──、いっぽうでは、コード 変換 テーブル を用意するという考えかたである。 3つの やりかた のなかでは、B 社の独立性が一番強い考えかたである。

　以上の考えかたを参照して判断されたい。