[pgsql-jp: 31373] Re: 取引先の分割や合併処理について

[SAKATA Tetsuo]

こんにちは。坂田＠横須賀です。

以前、DB設計を仕事にしていた時期があり、この話題には興味を持って
見ていましたが、フォローがつかないようですね。

やはり、この場は PostgreSQL というDBMSの情報を交換することが
主な関心事なので、手を挙げようという人は少ないんでしょうか。

この種の話題はこのMLにはややそぐわないと思うんですが、
思いついたことを少々書きます。

Chie.M wrote:
> Chie.Mです。お世話になっております。
> また、テーブル構造についての質問です。

Chie.Mさんのメールを読んでいて思ったんですが、テーブル構造以前に、
どのような要求があるのかが、イマイチわかりませんでした。
契約一覧表示や合算処理が挙げられていますが、それだけが
できれば十分なのか否かがわからないと、データ構造を決めるのは無理があります。
ですが、以下ではそれで十分と想定して書きます。

> 取引先マスタを元に契約書類を作成するようなデータベースを
> 作成しています。
> このような場合、取引先の社名変更や分割、合併についての処理は
> 皆様はどのようにしているのでしょうか？

設計上の考え方としては、まず会社間の合併や統合を(ERモデルで言う)
「多対多関連」で表現するのが良いと思います。

この多対多関連を表にすると、

合併(旧社名, 新社名, 種別, 合併ID)

のようになりますね(上記の表で合併のみならず分割も記録できます)。

その上で、契約の表示や合算処理の際には、必要に応じて「合併」表を
参照すればよい、ということになるかと思います。

しかしながら、このようなやり方には(少なくとも)2つの問題があります。

(1) 契約の表示や合算処理に際して、SQLを使うならば、
　　上記の「合併」表を結合する処理が必要になる
　　⇒性能上不利になりがち。
(2) 現在1つの会社ではあるが、過去に何回も合併や分割を繰り返している
　　会社の場合、過去にさかのぼってその会社の合算処理をすると、
　　その種の処理はSQLだけでは書けない。

そこで、実用上は会社の情報を記録しておく表を、以下のような構成にする
のが良いのではないかと思います。

会社(会社ID, 社名, 合算処理ID, 契約一覧ID...)

上記のスキーマでは、会社自体のIDを示す会社IDの他に、
合算処理の際に使うIDを「合算処理ID」、
契約一覧処理の際に使うIDを「契約一覧ID」、
として加えています。

問い合わせの方法としては、

1. ある会社の契約一覧を見たい
　　1.1 その会社のIDで「会社」表を引いて、「契約一覧ID」を取得する。
　　1.2 その「契約一覧ID」を当該会社のIDとみなして、契約を記録した
	テーブルを検索する。
	(…すると、「契約一覧ID」は1つの値ではなく、複数のIDを入れないと
	まずいですね。適宜正規化してください)

2. ある会社の合算処理をする
　　契約一覧を見るときと同様の処理を行う。合算処理IDの正規化についても同様。

このようにすれば、上で書いた2つの問題点はかなり軽減できるものと思います。
(それでも、やはり結合演算が必要ではありますが)
ただし、会社の合併や分割があった場合には、「会社」表をメンテして
「合算処理ID」や「契約一覧ID」を正しい値に設定しておく必要があります。

ただし、そのようなイベントの頻度は低いこと、かつ、必ず特定の
日から切り替わる(ある日の途中で社名が切り替わったりはしない)ので、
夜間バッチのような処理でも間に合うと思います。

以上、甚だ ad hoc ではありますが、元の問題の複雑さから見て、
やむを得ないように思います。いかがでしょうか。

では。
-- 
坂田 哲夫＠NTT サイバースペース研究所
sakata.tetsuo ＠ lab.ntt.co.jp
SAKATA, Tetsuo. Yokosuka JAPAN.