DBを使用しない業務システムはまず無いでしょう。
定型的な業務システムのDB設計手法は、枯れて定石化してもいい時期だと思うのですが、毎回同じことで喧々諤々となってしまいます。
マスタの主キー(ここではマスターは得意先マスターで主キーは得意先コードとします) 一つとっても、サーベイ段階で議論白熱することがあります。
・顧客側は主キーはユニークだが,コードの付け替えがあるので,不変ではないと主張, 開発側はシステム的に主キーの付け替えは困ると主張。
・顧客が合併したときの複数顧客を一本化することもある.
・顧客コードは桁に意味を持たせる.上2桁は顧客名称の頭文字に対応.
などなど。
そこでシステム屋とすれば、サロゲートキーの導入をしたくなります。Oganacの設計はマスターの連携はサロゲートキーで行うようにしてます。IO部分の定石化がすすみ、実装も楽になります。
勿論万能薬ではないのでネガティブな部分もあります。容量的に冗長, IOが二段になる等等。
しかし後日のシステム拡張性を考えれば、顧客コードを主キーにするのはデメリットが多いように感じます。
サロゲートキーは業務的にはある意味、無意味な項目ですので冗長な印象を与えないように配慮が要ります。
システムを纏める際には, 業務からみた DB図と, 開発側から見た DB図は 別仕立てで作成したほうが良いのではと感じます。
上記の例で言えば, 業務から見た図は, 顧客コードが主キーになる DB図であり、開発側から見た図は実際のEntity表となります。
別な言葉を使えば, 論理関連図 vs 物理関連図 となります。 顧客との打ち合わせは,論理関連図で行えば十分だと思います。
物理実装は開発側裁量の範囲だと考えています。
物理関連図の実装まで顧客の了解を得ようとすると不毛の会議に突入しかねません。(顧客のレベル問題もあり一概には言えませんが)