fc2ブログ

(元)社内SEの徒然なる日記

基幹系データベースも長期保存はしたいのだが...

■ 基幹系DB

基幹系システム構築における愚痴でも書こうかと思います。

無駄にダラダラと書いたのですが、中身はありません。ただのボヤキです。面倒になったらスルーして下さい。


基幹系データベースには今使うデータのみを保持して、情報系データベースには基幹系から出力したデータを蓄積する。こういう方針は良く見られると思います。

私の勤め先でも同じで、基幹系システムから日次(または月次)でデータを吐き出して、情報系データベース、つまりDWHに蓄積しています。

それは正しい設計だとは思うのですが...

■ 情報系は重要

情報系データベースは、それはそれで重要だとは思います。

基本的に蓄積型で小細工もしないので、誤ったプログラム修正とか妙なデータパッチの影響で壊れる恐れが少ない、基幹系に比べて利用者が少ないので色々と無茶な処理も出来る。

構築する時も、正規化とか気にしないで良いし(むしろ、されると使いづらい)、速度も(基本的には)不要なのでインデックスはなくても問題なし。精々、誤ったデータが入らないように重複チェック(PrimaryKeyの設定とか)が機能するようにする程度。耐障害性も低くて良いわけだし、気楽なものです。

おかげで、大容量のデータを安価に溜め込むことが可能になります。

ただ、ここに蓄積されるのってデータでしかないんですよね。なので、ここから何らかの数値を作るってなると、かなり苦戦することになります。例えば、DWHに蓄積した明細データから、ある時点のB/Sの未成工事支出金に該当する金額を作れとなると、本当に作れるのかって話になったりします。

データはあっても、それを必要な形に成型する機能が存在しないのです。

■ 基幹系の場合

基幹系の場合は、正規化されたデータを色々とくっ付けて必要な情報を出力する機能が揃っています。

画面上に必要な値を入力してボタンをクリック、すると帳票やデータ(CSVとかEXCEL)が出力される。ユーザーから見ると難しいことを考えなくてもいいし、私たちSEにとっても必要な数値を出すためのロジックが目の前にあるので何かあった時も対応しやすいわけです。

これが、ただ漠然とデータを蓄積する情報系データベースとの大きな違いですね。

ってことで、勤め先では基幹系データベースのデータを出来るだけ消さないように蓄積し続けています。当初の設計時は保持期間5年、今は色々と工夫して10年まで伸ばしています(できれば、もっと伸ばしたい)。

最近はハードもソフトも優秀になってますし、きちんと設計したシステムなら大量のデータが存在しても性能劣化なんて気にするほど起こりません。いや、正確には性能劣化は起きるのですが、チューニング出来る技量があれば何とかなるって事ですね。

勤め先の月次処理は、数年前のシステム稼働当初は4時間は掛かっていたのですが、今では2~3時間くらいで終わっています。データは比較できないくらいに増えているのにです。

こうなると、業務ロジックとセットになった基幹系データベースのデータを消すのは惜しくなるのです。

さて、データベース自体はそれでいいのですが、問題は基幹系システムを支える業務ロジックが「今この瞬間」しか見ていない場合です。いくらデータを長期保存できても、ロジックが過去の情報参照に使えなければ意味がありません。

例えば、うーん、そうですね。手形を管理するシステムがあったとします。手形は受取手形から割引手形という感じで、一つのデータ(手形)の状態がコロコロと変わっていきます。この時に、過去のいつの時点では受取手形で、いつ割引手形になったという情報を把握できるように設計しておかないとダメなのですが、これが意外と難しい。

その結果、今の時点では正しい状態が把握できるけど、数か月前の状態を見ることは出来ない。という事態が発生するわけです。

はい、出来ないんですよ。

数年がかりで、殆どのデータは基幹系システムから過去の情報を見れるように修正したのですが、いくつか手が出せない領域が残ってます。さっきの手形の話もそうですが、修正が不可能と言いたくなるほど難しい場合には諦めるしかありません。リスクを冒してまでやる訳にはいかないですし。

こうなると、情報系データベース(DWH)から簡単にデータを抜けるように抽出方法をパッケージ化した方が現実的かとも思えるのですが...

悩ましいなぁ。

投稿記事の一覧:http://harikofu.web.fc2.com/

--- blog end ---

スポンサードリンク

PageTop

コメント


管理者にだけ表示を許可する