SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

最新イベントはこちら!

Data Tech 2024

2024年11月21日(木)オンライン開催

EnterpriseZine Day Special

2024年10月16日(火)オンライン開催

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けの講座「EnterpriseZine Academy」や、すべてのITパーソンに向けた「新エバンジェリスト養成講座」などの講座を企画しています。EnterpriseZine編集部ならではの切り口・企画・講師セレクトで、明日を担うIT人材の育成をミッションに展開しております。

お申し込み受付中!

変化する情報活用ニーズ、進化しないデータウェアハウス

データウェアハウス構築の秘訣(1)

第3回

 前回は、私がデータウェアハウス構築の現場で実際に投げかけられた数々の疑問(質問)の中から代表的なものをいくつか紹介させていただきました。データウェアハウスの構築にも意外と難しい側面があることを多少なりともご理解いただけたのではないでしょうか。  さて今回は、前回紹介しました疑問に対して「では、どうしたらよいのか」という私自身の考えを述べさせていただき、次回、データウェアハウスの構築ポイントを整理していきます。

2つの考え方があるデータウェアハウス・システムの構成

 データウェアハウス・システムの構成には、2つの考え方があります。

 1つ目は、セントラルウェアハウスを構築し、そこに統合されたデータを活用するために目的別にデータマートを構築するという考え方です。この場合のデータマートは、セントラルウェアハウスのデータに依存することになるので、従属型データマートと呼ばれます。

 これに対し、セントラルウェアハウスの構築は必須ではなく、目的別にデータマートを構築すればよく、その集合体がデータウェアハウスであるという考え方があります。この場合のデータマートは、基幹系業務システムから直接データを抽出して構築される(セントラルウェアハウスに依存していない)ので、独立型データマートと呼ばれます。

 いずれの構成がよいのかと問われれば、私は迷わず前者と答えます。なぜなら、これまでの構築経験の中で後者を選択したことにより以下のような種々の問題に遭遇してきたからです。

  • データマートを作るたびにデータソースの所在確認、抽出/転送/ロード(ETL)モジュールの開発など同じ手間がかかります。このため、新規ユーザニーズに即応できません。
  • データマートは特定の分析要求に沿って開発されるため、当然ながら限定的な分析しかできません。このため、似て非なるデータマートが多数できてしまい、リソースを膨大に消費することになります。
  • 企業レベルでのデータ統合が行われないため、クモの巣状のシステム形態という問題は解決されず、かえってETLのタコ足が加わりシステム間の依存関係が複雑になります。
  • 切り口(視点)、データの詳細度(粒度)がデータマートごとに異なるため、いくつかのデータマートから作成されたレポートが整合しない場合があります。
  • ETLツールやBIツールが統一されないため、メンテナンスに手間がかかります。また、基幹系業務システムの仕様変更やデータメンテ(修正)が発生した場合、データマート側のメンテナンスにも手間がかかります。

 このような経験を経て、私は、

データウェアハウス=セントラルウェアハウス+従属型データマート

 が適切な形態だと考えるようになりました。

 しかしこの式は、最初の一歩がセントラルウェアハウスの構築だという意味ではありません。むしろ、セントラルウェアハウスの構築自体をプロジェクトの目的にするのは好ましくないと考えています。その理由は、もしセントラルウェアハウスの構築をプロジェクトの目的とした場合、データ設計がトップダウン・アプローチにならざるを得ないからです。トップダウン・アプローチで設計するということは、企業内のエンティティを洗い出し、どのエンティティをセントラルウェアハウスに入れるのかを検討するところから始めるということで、これは非常に困難な作業です。かといって、各業務システムで使用されているデータをかき集め、業務担当者から業務内容およびデータ項目の意味をヒアリングして企業レベルのERDを作るというボトムアップ・アプローチを採ったとしても、大変な作業になるでしょう。

 したがって、単に企業レベルでデータを統合するためにセントラルウェアハウスを構築しようとするのではなく、特定のユーザニーズを解決する目的でデータマートを構築することろから始めるのがよいと思います。そのユーザ・ニーズを解決するためにデータを集める、新しいユーザニーズが出たら不足するデータを集めて追加するということを繰り返して段階的に成長させる、つまりセントラルウェアハウスを指向することが重要だと考えています。

次のページ
仮想的なビューの提供を優先的に検討する

この記事は参考になりましたか?

  • Facebook
  • X
  • Pocket
  • note
変化する情報活用ニーズ、進化しないデータウェアハウス連載記事一覧

もっと読む

この記事の著者

サイベース 本庄 朗人(サイベース ホンジョウ アキヒト)

サイベース株式会社 プロフェッショナルサービス本部 担当部長。大手独立系SI企業を経てサイベース入社。90年代後半からデータウェアハウスの構築プロジェクトに従事、現在に至る。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/123 2007/09/03 13:00

Job Board

AD

おすすめ

アクセスランキング

アクセスランキング

イベント

EnterpriseZine(エンタープライズジン)編集部では、情報システム担当、セキュリティ担当の方々向けに、EnterpriseZine Day、Security Online Day、DataTechという、3つのイベントを開催しております。それぞれ編集部独自の切り口で、業界トレンドや最新事例を網羅。最新の動向を知ることができる場として、好評を得ています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング