2項が取りうる4つの関係。クラス設計をデータ設計に転用できない理由

2つの集合なり概念なりがあったら、それらの関係は以下のうちどれかになるが、

1. まったく重ならない
2. 一部重なる（けど包含関係じゃない）
3. 包含関係
4. 全部重なる

TMでは、2項の関係が上記のうちどれなのかに激しくこだわる。
例えば取引先の区分に「納入先」「支払先」がある場合、納入先かつ支払先の会社があるかどうかで、データ構造が変ってしまうから。

データ設計に比べると、アプリケーションの設計では「2つのクラスが示す概念が、一部重なるかどうか」みたいなことはあんまり問題にならない。
ドメインモデリングするなら（＝問題領域の構造をクラス図で表そうとするなら）問題になるのかもしれないが、私の場合はクラスを単なる実装技術として使っているので。
例えば納入先・支払先のオブジェクトを要求するユースケースが別々なのであれば、取引先の情報を、ある機能では納入先クラスのインスタンスにし、別の機能では支払先クラスのインスタンスにするだけ。「納入先かつ支払先」があってもアプリケーションには関係ない。

ただしこのやり方だと、(永続化を意識していない)クラス図と、(永続化を意識する)ER図は全然似ていないものになってしまう。
すると「O/Rマッパーを使ってテーブルとEntityクラスを対応付ける」みたいな省力化は不可能になる。

では「O/Rマッパーを使ってテーブルとEntityクラスを対応付ける」というアプローチでは、「納入先」かつ「支払先」の取引先をEntityクラスでどうやって表現するのだろう。
なんかスマートにできないような気がするけど。実践してる人は困ってないのか。