今回のブログは、前回に引き続いて企業内情報生態系についてお話する。前回は、ODS、CENTRAL-DWH、DATA-MARTそれぞれのロケーション及び役割についてザックリとお話した(図1に前回同様のものを掲載)。そこで今回はそれらの特徴をさらに詳細に掘り下げてみることにする。次の表1に主要な観点からその特徴をまとめたのでご覧いただきたい。以下、ゾーン別にその誕生の歴史を振り返りながら説明して行きたい。
まずAゾーンであるが、こちらは1970年代から存在する最も古い基幹系システムの領域である。この領域のデータベース(ODS)は1980年代前半にOLTPシステムとともに世の中に登場した。目的がイベントの捕捉にあるので、データ粒度は取引明細であり、その保存期間は2~3か月となる。DB更新タイミングはリアルタイムが基本。物理DBはRDB。利用者は基幹業務システムの現場オペレータやトラブル対応のヘルプデスクである。
次に世の中に登場したのがCゾーンのいわゆる“情報系システム”である。1980年代半ばのSQL言語とBIツールの登場で、最初の情報系DBが企業内に構築された。当時は、この情報系DBの種類も限られていた為、ODSから直に生成される事が多かった。やがて類似した情報系DBも増え、CENTRAL-DWH経由で生成されるようになる。データの粒度は目的に応じたKEYによるサマリーで、保存期間は5~10年程度だ。DB更新タイミングは1回/日or月が一般的。物理DBはRDBの他に非定型検索に高速に応える為のCUBE型DBもあり。利用者は事業の戦略企画を練るスタッフが中心である。
最後にBゾーンの“情報系汎用データ基盤”であるが、1990年代後半のDWHやBI製品の進化とともに大規模な情報系DBのニーズが高まる。このゾーンのCENTRAL-DWHの役割は、データマイニング用の取引明細の格納庫と、CゾーンのDATA-MARTへの明細データ供給元という2つの役割がある。これらの役割からデータ粒度は自ずと取引明細が必要で、その保存期間は通常24~36か月となる。DB更新タイミングは1~2回/日のバッチ更新。データ発生源はODSであるが、通常は再利用を可能にする為にデータクレンジングを伴うケースが多い。物理DBMSはRDBを用いるが、大規模データの非定型な要件に応えるべく、通常のリレーショナルモデルではなく、スタースキーマモデルを用いることもある。利用者はデータマイナーの他に、即席SQLを操るIT部門特殊部隊などがいる。また近年、BIG-DATAと称して文書や画像等の非構造化データを扱うDBが登場してきたが、このDBMSもBゾーンに生息する新種である。豊富なビジネス知識をもとにこれを操るデータサイエンティストなる人種も登場し、このBゾーンは賑やかである。
以上がゾーン別の情報生態系の特徴である。いずれのゾーンもDBがその核となっている。そして、各ゾーンのDBは役割も構造も異なり、その設計は異なる専門性を必要とされる。決して一筋縄では行かない。近年、オブジェクト指向、サービス指向アーキテクチャ等のプロセス設計技術が進展する中、データベース設計ができるエンジニアが減ってきている。間違えてはいけないのがOOAやSOAがDOAと矛盾するものではないという事。プロセスの先には必ずターゲット・データがあり、それが整理されていることは大前提である。データが散らかったままでプロセスを整備することは、レスポンス面での要件を満たすことが難しいだけでなく、適正なデータ品質をキープすることすら危うくなる。大人数は要らないがユーザ企業内に少なくとも数名は欲しい人材である。いまDB設計エンジニアの育成が急務である。このことはユーザ企業に限った話ではなくSIerも同様とお見受けする。
次回のブログ“企業内情報生態系(その3)”では、各種DWHがビジネスへどのようなフィードバックをもたらすかについて考えるとともに、DWHの技術面、利用局面それぞれの今後の課題について触れてみたい。