バッチ処理でデータベース活用：4つの課題と5つの解決ポイント

1. バッチ処理でデータベース活用

　読者の皆さんはご存知かと思いますが、現在のOracleデータベースは高機能になりデータ加工に利用できる様々な機能が実装されています。これらの機能を使わずに、今まで通り単なるデータ格納庫として利用するのはもったいないですね。

　バッチ処理は業務システムの多くで利用されていますが、あくまでもシステムの裏方としての役割のため、なかなかノウハウがメディアに出てくることがありません。

　実はバッチ処理とデータベースをうまく組み合わせて使うことこそ、現在抱えている問題や課題の解決になるのです。

　今回はバッチ処理の特徴をまとめ、バッチ処理でのデータベース活用について説明します。

1-1. バッチ処理の現状

　コンピュータ性能の向上や通信回線費の低下で常時オンライン化しやすくなったこと、またビジネス環境が変化し利用者が結果を即時に要求することが多くなったことを背景として、以前と比べるとバッチ処理はずいぶん減ったと思います。

　とはいえ、それとは対照的に処理対象データは飛躍的に増加の一途をたどってもいます。現在稼動中の多くのシステムにおいてもバッチ処理が裏を支えているといえます。

1-2. バッチ処理の特徴

　バッチ処理は社内外や他システムから受け付けたデータを蓄積し、正常・異常データの仕分けや集計処理、各種伝票作成・印刷などで利用されます。

　これらのバッチ処理は「まとめて処理する」「コンピュータを効率よく利用する」といった共通の特徴があります。

　全ての処理をオンラインで処理するには、同時に複数の処理要求があっても平気なように高性能なコンピュータを用意する必要があります。それでも想定以上の要求があった場合には処理しきれないことも考えられます。そこで要求されたデータの登録だけをしておき、一定時間の要求データをまとめてバッチ処理することで大量の要求をすべて処理できるようになります。

1-3. 現状の問題点

　現在稼動しているバッチ処理は様々な業務システムで利用されていますが、同様の問題や課題を抱えている場合が多いです。

• 1-3-1. 十分な開発時間が与えられない
  　例えば稼動中のシステムをリニューアルするプロジェクトが立ち上がったとします。そのシステム開発の際に、オンライン系はユーザーが目にする部分であるため優先順位が高くなりますが、バッチ系の場合はシステムの裏方なのでどうしても開発の優先順位が低くなります。タイトなスケジュールで開発されることが多くなることで、さらに大きな問題となりやすいのです。
• 1-3-2. 仕様書とアプリケーションが同期しない
  　開発時間が十分にないことでバッチ処理は再構築などのコストがかかるような開発はせず、つぎはぎの改良となりやすいのです。さらにおっくうになりがちな仕様書も多少の変更だからといって更新されず、仕様書とアプリケーションが同期していないことも少なくありません。
• 1-3-3. メンテナンス性が悪く、変化に対応できない
  　バッチアプリケーションはつぎはぎ開発で肥大化しているため、メンテナンス性が悪くビジネス環境の変化に即応できなくなってきています。
  　また、昨今の企業合併などによる企業規模・事業規模拡大などが要因でデータ量が増大すると、計画したスケジュール時間内に処理が完了しなくなるケースも少なくありません。このようなバッチ処理が原因で業務に影響がでることもありますので大問題です。
• 1-3-4. コスト削減できない
  　メンテナンス性が悪いため当然、開発コストや運用コストを削減することが難しくなります。
  　さらにメインフレーム上のバッチ処理の場合には、複雑化・肥大化し仕様書も存在しないバッチアプリケーションが存在することで、メインフレームを全廃できずにコスト削減できないといった問題もあります。

1-4. バッチ処理の再構築