ERモデリングレッスン7（イベントと在庫）

永続

だいぶ遅くなってしまったが、連載第5回の記事で紹介した基本パターンの「イベントと在庫」のERモデルを説明する。（ERモデルを解説する理由については、以前のエントリ(id:ahirasawa:20050629)を参照していただきたい。）

UMLのクラス図とベン図（＝変形オブジェクト図）表現は次の通り。

ERモデルは次のようになる。

「イベントと在庫」の典型的な例は、銀行預金の入出金である。イベント側の主キーには「口座番号」に加えて「SeqNO（シーケンス番号）」か「タイムスタンプ」を設定しておく。

上記のモデルを描いてみたところで、RDBを永続記憶に採用している銀行勘定系システムはどれくらいあるのだろうかと疑問に思った。自分がメインフレーマで金融担当SEだったのはもう10数年前のことだが、その頃のピーク時トランザクション量は都銀で数百件／秒、地銀で数十件／秒だった。最近はサンデーバンキングやATMの時間延長が当たり前になったのでトランザクションは多少平準化しているかもしれない。一方で銀行同士の合併が進んでいることも考え合わせれば、ピーク時トランザクション量は決して減ってないだろう。（証券システムの方はネット取引の増加で大変なことになっているらしいが）。

10数年前の感覚では、数百件／秒のトランザクション処理システムともなると、パフォーマンスの観点からしてRDBの採用はあり得なかった。何しろRDBはインデクスを経由するし、テーブルが異なればディスク領域も分かれてしまうため、遅くて使い物にならないから。

当時のある都銀の勘定系システムは、普通預金の入出金トランザクションは物理I/Oが2回で済むように設計されていた。つまり1回読んで、1回書いて終わり、である。1回の入出金トランザクションでは、CIF（顧客）、口座、入出金などのDBにアクセスする必要があるが、CODASYL型DBなら一人の顧客の情報を物理的に隣接したディスク領域に格納できるため、実際のI/O回数を少なくできる。しかしRDBではこうした芸当は望むべくもない。（ちなみにこれはODBでも可能である）。

最近はUNIXやWindowsで稼働する勘定系システムの話を時々聞く。こうしたシステムの永続記憶はRDBのようだが、何か特別な仕掛けをしているのだろうか？もしかしたらCPUやディスクの能力が飛躍的に向上したため、普通にSQLを発行しても大丈夫なのかな？そんなワケないと思うんだけど..