はじめに

業務システムではリレーショナルデータベース(RDB)が広く利用されており、ERモデリング(Entity-Relationship Modeling)の手法に基づいて構成されたデータモデルでデータが保持されているのが一般的です。このデータモデルはデータの追加・変更・削除を行うトランザクションの効率的な処理や項目変更への柔軟な対応、データの冗長性を排除するなどの観点から正規化されたデータ構造となっています。

このような多数の細かなトランザクションの処理を求められる基幹系の業務システムとは異なり、データ分析システムは大容量なデータに対する処理負荷の高い集計処理をが求められ、BIやデータウェアハウスの分野ではその要求に対応するために「ディメンショナル・データモデリング(Dimensional Data Modeling)」の理論化がラルフ・キンボールらを中心に進められてきました。

Qlik Senseでは取り込んだデータの自動的なキー紐付けによるデータモデルの作成やチャートの軸・メジャー定義によるハイパーキューブの生成など、厳密にディメンショナル・データモデリングの考え方に従わなくてもデータ分析を行えてしまうことは多くあります。ただ、管理性やパフォーマンスの観点から最適化を目指すに当たってはBIやデータウェアハウスの分野で広く受け入れられているディメンショナル・データモデリングについて最低限の知識を持っておくことが求められますので、ここでは「ファクト」、「ディメンション」、「スタースキーマ」、「スノーフレーク」といったディメンショナル・データモデリングの基本事項について説明させて頂きます。

ファクトテーブルとディメンションテーブル

Qlik Senseの軸(ディメンション)とメジャー」のエントリでの解説にある通り、データ分析を行うに当たっては以下の様な形でデータ分析を行う視点や切り口に当たると、数式によって算出される集計値に当たるメジャーをチャートに設定します。

1

では、軸やメジャーには具体的にはどのような項目が含まれるでしょうか?以下のような項目が想定されます:

  • :商品、顧客、地域、時間など → 「属性」
  • メジャー:売上、数量、原価など → 「数値」

つまりデータ分析の目的は突き詰めると、主にテキスト形式で表現される「属性」に当たる軸でグループ化し、「数値」で表現されるメジャーを求めるということにあるということになります。

この目的に対応するために考え出されているのが、以下の形のディメンショナル・モデルとなります。中心に位置するファクトテーブルがメジャーの集計に使われる数値データを格納します。このファクトテーブルは売上や取引などのトランザクション単位のデータが格納され、典型的には最も巨大なテーブルとなります。

dimension

そしてその周辺に位置するのがディメンションテーブルとなり、ここに商品、顧客といった軸のデータが格納されます。

スタースキーマ

上記でご説明したディメンショナル・モデルはファクトテーブルを中心としてスター型となっていることからスタースキーマとも呼ばれます。以下の様な形で、中央のファクトテーブルにはディメンションテーブルへのキー項目と、集計の対象となる数値項目のみが格納されています。そして、周辺のディメンションテーブルには商品名や顧客名といった軸となる属性のデータが格納されています。一般的に業務システムのデータは正規化されて複数の階層のマスタテーブルに分かれており、このような構造とするには複数テーブルの結合などによる非正規化の作業が必要となります。(具体的には「テーブルの結合–ApplyMap, Lookup, Join, Keep」でご紹介しているような、テーブルの結合などの作業を行います。)

image_thumb.png

このスタースキーマのデータモデルでは、ディメンションテーブル上の項目によりグループ化されて、テーブル間のJoinに当たる処理を行う必要なしに中央のファクトテーブル上の数値項目が集計されるため、処理が効率的に事項されるのがこのモデリングの特長となります。

スノーフレーク

以下の様な形でディメンションテーブルが複数のテーブルに分割されたデータモデルを、その雪の結晶の様な見た目からスノーフレークと呼びます。業務システムのデータに対して非正規化の作業を行っていない場合には典型的にこのような構造となります。

この様なスノーフレークのデータ構造は非正規化の作業を省けるという開発作業上のメリットはありますが、集計時に分割されたディメンションテーブル間のデータを結合する処理が内部的に必要となるため、スタースキーマの構造と比べて処理効率は劣る形となります。

連想データモデル

これまで、スタースキーマやスノーフレークと呼ばれるデータ構造などについてご説明してきました。Qlik Senseではデータを取り込むと同じ名称の項目はキーとして自動的に紐付けられ、スノーフレークのデータ構造でも特に支障なくデータ分析が行えることも多くあります。ただし、特にデータ容量が大きくなる中で高いレスポンスが求められる場合などや管理性の観点から、Qlik Senseでもこれらの考え方を理解してデータモデルの設計に適用することが望まれます。

その一方、こういった広く受け入れられているディメンショナル・データモデリングの考え方とは異なったQlik Senseが持つユニークな特長として、「Qlikコア技術の「連想技術」と「インメモリ」」でご紹介している通り、Qlik製品では「連想技術」と呼ばれる技術が採用されています。Qlik製品では全レコード間のアソシエーションが保持されており、思考の流れに従った一連の分析を行うことができることから、Qlikではこのような分析を可能とするデータの持ち方を連想データモデル(Associative Data Model)と呼びます。

image

ディメンションテーブルの項目を軸としてファクトテーブルのメジャーの集計を行うというディメンショナル・データモデリングに基づいた一般的なBI製品での分析アプローチとは異なり、この連想データモデルによりパワー・オブ・グレー(Power of Gray)や思考の流れに従った一連の分析を行えるといった連想技術のメリットを享受できるという点はQlik Senseならではの特長と言えます。

まとめ

以上、「ファクト」、「ディメンション」、「スタースキーマ」、「スノーフレーク」といった「ディメンショナル・データモデル」の基本的な事項についての説明と、最後にQlik製品の特徴である連想データモデルについてご説明させて頂きました。