独立型データマートによる営業支援システムの構築
−DWHによる新たなデータ活用システムの構築事例−

(PDF文書,576KB)


【要旨】

<システム化の背景と目的>
弊社は、ユーザーに対し、5年程前に「分散データベース」と言う営業マン向けのデータ活用システムを構築した。
これは、EUC(End User Computing)を前提に、基幹上のデータを情報系のサーバにダウンロードし、Windows3.1が搭載されたパソコン上でEXCEL・QUERYを利用して自由に検索や加工ができる仕組みであった。
オープンシステム、ダウンサイジングが、盛んに叫ばれた時代に、自由度が高く、オープンマインドな「分散データベース」は、企業内全体で推し進めてきた情報武装化の一環として、ペーパレス化の推進、ホスト資産の有効活用、ホスト負荷軽減等を実現するシステムとして利用されてきた。
しかし、企業内で認知された「分散データベース」が、営業部門のシステムに留まらず、経理、人事部など他部門へも展開され、データ量、ユーザー数が多くなってきた頃より、検索レスポンスの劣化、EUC資産(EXCELマクロによる仕組み)の多種化、データ転送量の増加など、幾つかの問題が露呈し、また現状のインフラ上では実現できないユーザーニーズや案件も多くなり、解決と対応が急がれた。
時期的にも、端末のWindows95化やY2K対応がせまられる中で、「分散データベース」も何らかの方向性を示す必要があり、システム化の目的として
 1)ユーザーサイドのボトルネック解消(検索レスポンス劣化、EUC資産の散在など)
 2)システムサイドのボトルネック解消(遠隔地サーバによる運用環境、障害復旧時間増加など)
 3)新たなコンテンツの充実と意思決定支援が行える戦略的なシステムへの移行
を柱に、全社的データウェアハウスのサブジェクトシステムとして、営業部門に特化した「独立型データマート」を構築する運びとなった。

<システム構成と概要>
データウェアハウスとして構築するため、データベースエンジンには「RedbrickWareHouse」を採用した。
フロントエンドには、ユーザーの操作慣れやEUC資産の継続利用のため、EXCEL・QUERYをメインツールとし、新たに分析・意思決定のサポート強化と定型資料の一元管理を目的に、「BusinessObjects」を採用した。
サーバは、後に説明するプロトタイプでのWAN実測値評価にて、1台での運用で耐えうる確証が得られたので、Express5800-Ma140(2CPU、HD:24G、MM:1G、OS:NT4.0)1台の集中型とした。
コード変換、JOB制御管理は、弊社が開発したBabylonを採用した。Babylonは、障害通知の電子メール配信や、EXCEL形式での変換が可能であり、今後予想されるデータウェアハウスや、その先のホストコンピュータへの分析、シミュレーション結果のアップロードも睨んだ構成にしている。

1)RedbrickWarehouseの採用のポイント
@.高速なローディング機能に加えて、多彩なローディングオプションを持つTMULoaderが実装されている。
A.スキーマによるアクセスパスがワンパスジョインによりSQLが最適化され、スターインデックスとの兼ね合いで高速な検索が可能である。
B.検索エンジンに特化している為、不要なログ処理を発生させないアーキテクチャーである。
システム部門としては、検索に特化しているエンジンであったため、データベース設計に問題がなければ、比較的容易なチューニングで、ある程度のパフォーマンスを得られる部分も、運用コスト面で受ける恩恵を感じた。
2)BusinessObjectsの採用のポイント
@.テーブル構造を意識しなくても、ユーザー業務に沿ったビジネス用語で定義したユニバースと呼ばれる論理構造で情報分析が可能である。
A.作成したレポートは、リポジトリと呼ばれるデータベース上のエリアに格納され、ユーザーは、リポジトリから最新のレポートを入手できる。またリポジトリを経由して、ユーザー間でのレポートの送受信できるなど、共有化、共通化に長けている。
BusinessObjectsの次期バージョンでは、ブラウザ上での分析、加工が可能になる製品群が強化される事も採用の要因となった。

<キーポイント>
1)分析フェーズ
@.問題点の把握
ユーザー、システム側が抱えていた「検索レスポンスの劣化」「データ転送時間の増加」「障害時のリカバリ時間の増大」「EUC資産の多種化」等の大小あらゆる問題点を洗い出した。
A.プロトタイプ版の開発
RedbrickWareHouse、BusinessObjectsを採用するにあたり、まずは現行データを利用して、NEC社協力の上、プロトタイプを作成し評価した。データ規模は本番想定の1/5程度(100万件)のプロトタイプであったが、本開発での、DB設計やBusinessObjectsレポート作成の知識習得として重要なパイロットシステムとなった。
また、このプロトタイプで、WAN上での評価を行い、ユーザーが利用する業務体系での実測値テストでも特に不安材料となる結果には至らず、あわせて行ったユーザーデモでも比較的良い反応が得られた。
2)開発フェーズ
@.ホストとのデータ親和性を重視
ローカル特性の無いDIMENSION(マスタテーブル)は、全てホストから作成する事で、基幹系と情報系の親和性を向上させた。
A.EUC資産の継承
従来のユーザーインタフェースであるEXCEL・QUERYを同じ操作感で使用できることを前提に、EUC資産の継続利用や、ユーザーの操作慣れを考慮した環境を目指した。
B.全支店共通定型資料のBusinessObejcts化
高度で且つ難解なロジックで作成されていたEXCELマクロの定型資料を、全てBussinessObjectsのレポートで対応し、リポジトリによる一元管理を実現した。

<開発計画>
開発計画としては以下の通りである。約4ヶ月の短納期であったため、実施事項をフェーズ単位でわけ見落としが
ないようにスケジュール化し、合間に、開発者向けのRedbrickWareHouseやBusinessObjectsの教育を組み込んだ。
開発規模 RedbrickWareHouse FACT:6DB、DIMENSION:24DB
BusinessObjects ユニバース:6本 レポート:8本
EUC資産の移行 40本
開発人員 SE2名、PG1名(技術支援2名)

<評価>
約4ヶ月の短納期であり、インフラ面からの大きな変更であったが、問題点としてあげていた事柄については、全て解決することができた。ユーザーからは「検索が早くなった」との声を良く聞き、特にレスポンス面での効果を実感して頂いている。

<今後>
今回のシステム構築では、コンテンツの充実や分析ウェート向上も目的の1つで行ってきたが、データ活用の観点から言えば未だ不十分な点も多く順次整備していく必要がある。
 また「独立型データマート」として立ち上げたこのシステムを、今後、他店部への展開と共にデータウェアハウスとして、企業内の意思決定や経営戦略に役立てられるように拡張したい。
さらに、シンクライアント・モバイル環境での活用も視野に入れ、データウェアハウスの有効性を示していきたい。