業務システムは千差万別なのでDB設計も千差万別。正解像というのは存在しないのかもしれません。
得意先マスターに請求先コードをn件保持するような設計をどう評価したものでしょう。
工程管理,教育管理など金額の絡まないシステムは概してデータの流れが単純になり見通しが良いのでスッキリしやすいと思います。
金額が絡むシステムは経理処理が絡むので安易に設計するとスパゲッティになったり、RDBのメリットを殺す設計になったりします。
DBはRDB以外にも形態がいろいろ在りますか、現在の大半の業務アプリはRDBが前提としているようなので、以下もRDBを前提とします。
売掛販売業務で考えます。(消費税処理は省略)
単純な販売管理だと,購入者と対価支払者が同一なので,
得意先CODE 商品コード 個数 代金
C001 GD001 1 20000
C002 GD002 1 30000
といったデータ構成になります。
商品の使用者と対価支払者が異なるときで使用者情報は無縁の時は
支払者CODE 商品コード 個数 代金
PY001 GD001 1 20000
PY002 GD002 1 30000
となります。
商品の使用者と対価支払者が異なるときで使用者情報も管理したい時は
得意先CODE 商品コード 個数 代金 支払者CODE
C001 GD001 1 20000 PY001
C002 GD002 1 30000 PY002
ここまでは単純な構成なので,混乱する要素は少ないでしょう。
得意先マスターに1つの請求先コードを設ければ対応可能です。
リース契約の時の処理もこのパターンで間に合います。
使用者と支払者が対にならないケースが時々あります。
規模が大きな会社などでは, 購入金額,種類に応じて決済部署が異なるケースがあります。
例として。
10,000円までは、支店経理部,100,000までは部門経理部, 100,000以上は本社経理部とする。 得意先1つに対して請求先は3パターンうちの1つに決まる。
このとき, エンティティの構成をどうするか,
Access/Excel/FileMakerなどからのアップサイジングでしばしば見られるのですが、 ( 得意先を第一に考える為でしょうか),得意先マスタに,
得意先コード, 請求先コード1,請求先コード2,請求先コード3の項目を設けて,売上データを作るとき、3つの内から1つを選択し,実請求先コードとしてデータ生成する。実に安易な定義。
これでOKとするのは如何なものでしょうか。請求先が3つで固定というのがまず引っかかります。
SE/PG関係なく,同種の項目の個数を限定するのは本能的に嫌がるものです。1レコード内に請求先コード1,2,3のような持ち方をされると違和感一杯になりまする
実装面ではデータのチェック面で,入力された請求先が, 請求先コード1/2/3と一致するか否かなどの判定部分が泥臭くなります。
また、実務データの整合性のチェックが入力担当者に依存されるので請求先コード1,2,3の選択ミスがシステム的にチェックできない。
これを堅牢なシステムにするには、請求先の決定方法と妥当性のCheckの仕組みを別に構築する必要があります。
債権管理の流れと物量の流れを結びつけるのが得意先マスターであるという視点に立てば、スパゲッティ化の元凶になります。
請求先自身の都合でコード付け替えが発生したりしたときの対処も単純にはできませせん。
お金が絡むシステムは、経理側から見たシステム構築が結果的にスッキリしたものになります。
第一,ER図だけでは,システム全体が読めなくなります。
一例として,
請求先マスターの子データとして,得意先マスターを紐付ける
商品マスターに対応する請求先コードを紐付ける
他に制約マスタを設ける
などがあります。
プログラムのスパゲッティが招く不幸は限定的なのに対して,システムのスパゲッティ化は全体的なものになります。
DBのエンティティ関連図が複雑になりスパゲッティ状態になると、製造段階で混乱が生じデスマーチの種になったりします。
上流工程での分析は十分考慮したい項目です。