SHOEISHA iD

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

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

直近開催のイベントはこちら!

Security Online Day 2023 春の陣

2023年3月14日(火)10:00~16:00

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

お申し込み受付中!

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

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

第4回

OLAPはSQLで可能だが…

 さて、ここで問題は、これらの分析手法がSQLで記述可能か否かということですが、答えは「可能」です。いずれもグループ化のキーに何を指定するか、どのような順番で指定するかが異なるだけです。

 つまり、OLAPはSQLで行うことが可能だということです。

 しかし、要求の都度、SQLでクエリすることにした場合、レスポンスはどうなるでしょうか。数百万件、あるいは数千万件のデータを地域・商品別で集計したと思ったら、次の瞬間に次元を入れ替えて商品・地域別で集計するよう要求される、しかも処理するデータ量は前回と同じです。このような要求に素早く応えるために考案されたのがキューブです。

 キューブというのは、一言で言えばサマリデータであり、当然ですがSQLで作成されるものです。たとえばドリルダウンが想定されるならば、はじめから「期間別」、「期間・地域別」、「期間・地域・商品別」の集計データを持ってれば良いわけですし、ダイシングが想定されるならば「地域・商品別」、「商品・地域別」の集計データを持っていればクエリ性能は格段に良くなるわけで、このようなOLAPの分析手法に対応した集計データの固まりがキューブの実体です。

 以上のように見てきますと、「OLAPをやりたいのだが、キューブは必要か?」という質問は、「ドリルダウンやスライス&ダイスをやりたいのだが、集計データを用意しておく必要はあるか?」という意味であり、このことに対する回答は、そのシステムにおけるOLAPの性能次第ということになるでしょう。システムを提案する側は、ユーザ要件にOLAPが掲げられている場合は必要があればPOCにより性能を評価した上でキューブの要否を判断し、作成する場合はその形態を明確に提示する必要があると考えています。

OLAPの形態

 次に、OLAPの形態について私の考えを述べます。

 OLAPの形態は、ROLAPとMOLAPに大別されます。「R」はRelational、「M」はMulti-dimensionalの頭文字ですから、ROLAPはリレーショナルデータベースを使用したOLAP、MOLAPは多次元データベース(またはキューブ)を使用したOLAPということになります。さらに細かく見て行くと、ROLAPには、ドリルダウンなどの操作の都度SQLクエリを行うタイプ(①)と、クライアント側にキューブを作成するタイプ(②)があり、MOLAPにもRDB内にキューブを作成するタイプ(③)と別サーバ(いわゆるOLAPサーバ)にキューブを作成するタイプ(④)があります。

 形態を決定するための評価を行うとすれば、①、②、③、そして④と順番に評価してゆくことになるでしょう。その結果、とてつもなく高速なRDBMSでキューブは一切不要ということが判明すれば①のタイプが採用されることになりますが、実際には、②~④のいずれかのタイプが選択されることになると思います。

OLAPの定型分析と非定型分析

 では、どのタイプがよいでしょうか。

 OLAPには定型分析と非定型分析があり、これらすべての分析に対応するキューブを事前に作成するのは非常に困難です。別サーバ上でキューブを作成する④のタイプは、当該サーバがすべてのOLAP要求に応える必要上、あらゆる非定型分析も想定して多くのキューブを事前に用意しなければならず、これがキューブ作成に長時間を要する原因となっています。さらに、キューブをドリルダウンしてゆくと最終的に生データに辿り着きますが、このときバックエンドのサーバから生データを取得する必要が生じます。

 ですから私は、キューブを事前に作成するならば定型分析用のキューブのみとし、非定型分析用のキューブは動的に作成すればよい、そのためにはキューブは生データが存在する場所に作成した方がよいと考えています。このようにすれば、単一のRDBMSが定型/非定型のOLAP要求に応えることが可能となりますし、また、生データへのドリルダウンもスムーズに行うことができるようになります。

 さらに、RDBMSがOLAP関数をサポートしていれば、複数の次元を持つキューブが単一のSQLクエリで作成可能です。たとえば地域と商品という2つの次元のキューブを作成するのに、1回目は地域・商品別、2回目は商品・地域別というようにクエリを2回実行する必要はないので、非定型分析に対応するキューブの動的作成も素早く行うことができます。

 以上から私は、OLAPの形態としては、OLAP機能を持つ(OLAP関数をサポートしている)RDBMSを使用した③のタイプがよいと考えています。

次のページ
データウェアハウスの構築ポイント

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

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

もっと読む

この記事の著者

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

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

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

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

この記事をシェア

EnterpriseZine(エンタープライズジン)
https://enterprisezine.jp/article/detail/178 2008/11/07 11:51

Job Board

PR

おすすめ

アクセスランキング

アクセスランキング

イベント

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

2023年3月14日(火)10:00~16:00

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

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

メールバックナンバー

アクセスランキング

アクセスランキング