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を使用した③のタイプがよいと考えています。
