DB Stories

DBに関する過去、現在、未来の話題をプロフェッショナルの視点で紹介

スタースキーマとキューブ(2)

リッチなディメンションテーブル

前回に引き続きディメンションテーブルについて解説していきます。

www.dbstories.com

上記記事で見てきたように、ディメンションとは、「ファクトを「抽出する条件」と「集約する項目」」を意味しています。つまり、ディメンションとはファクトテーブルを分析する軸のことを意味します。

  • 問い合わせに対する抽出条件
  • ファクトの集約単位となる
  • 表示項目のソート順になる
  • レポート作成の分析軸の定義となる

これを言い換えるとディメンションはファクトの値を解きほぐすために利用するものとなります。ディメンションの属性を増やすほどより多くの軸でファクトを分析することが可能になります。より多くの分析をするためには、より多くの項目(列)を持つリッチなディメンションテーブルが必要となります。具体的には以下のような原則が存在します。

  • 組み合わせで決まる項目を別々に保持する
  • コード値はそれに対応する説明も保持する
  • フラグ値はTrue/Falseに対応する説明も保持する
  • 複数項目で構成される項目は、複数の項目を保持し、かつ連結した値についても保持する
  • 数値の項目は保持しない

これらディメンションテーブルの属性項目について見ていきます。

f:id:good-value:20170208214454p:plain

自明な組み合わせ項目(Common Combinations)

 業務システムにおいて、組み合わせ項目というのはでき限りバラバラにするというルールが存在しています。たとえば、氏名については姓と名に分離して別項目として保持するようにするのが一般的です。氏名が必要となる場合は、姓と名を連結させて利用することになります。この「氏名」についてここでは「自明な組み合わせ項目」と呼ぶことにします。ディメンションテーブルにおいては、この自明な組み合わせ項目についても一つの項目として扱います。つまり「姓」「名」「氏名」と3つの項目を持つことになります。これらの項目を持つことによって、集計、並び替え、パフォーマンス対応としてのインデックス作成を可能とします。

コード値とその説明

 業務システムにおいてリスト化されている論理ドメインについてコード値を利用することが一般的です。多くは別テーブル(コードテーブル)でコード値に対応する説明を保持します。ディメンションテーブルにおいてはコード値と説明の両方を保持するようにします。データ分析の利用者は自分の使いたい方を利用することができるようになります。さらに検索クエリーがコードテーブルを参照する必要がなくなるのでよりシンプルに分析が行えるというメリットがあります。

フラグとその値

 Boolean値をもつ項目のことをフラグ列と呼びます。業務システムにおいていくつかの保持方法があります。「Boolean型を列に持つ」「0 or 1の数値を持つ」「Y or Nのような文字列を保持する」などが一般的な方法です。 ディメンションテーブルにおいては説明を加味した項目としてデータを保持します。たとえば、「クレジットカード注文フラグ」列については、「クレジットカード/クレジットカード未利用」という説明文そのものを保持させます。

複数の組み合わせ項目

 業務システムにおいては、複数項目の組み合わせからなる属性については分離して保持する必要があります。例えば郵便番号が該当します。日本の場合、郵便番号7ケタの上3ケタは「都道府県」を表します。のこりの3ケタでその都道府県内の地域を示しています。このような例において「郵便番号(7桁)」「郵便番号(上3桁)」「郵便番号(下4桁)」「都道府県名」というように複数の項目を一つにした項目、バラバラにした項目、対応する説明があればその項目という形で保持します。同様な例として固定電話番号があります。「電話番号(全桁)」「市外局番」「市内局番」というように保持するのが望ましいと言えます。

ディメンションテーブルの数値項目

 ほとんどのディメンションテーブルの列は文字列型になりますが、数値型データが入る場合があります。この数値型データについてはしばし混乱の元凶となります。今まで見てきたように、郵便番号、電話番号、その他のコード値は数値型で扱う場合もあります。(実務上は文字列型が多いです)これらの役割はデータ分析のための項目(抽出、集約)となるので明らかにディメンションとなります。このような簡単に分類できるもの以外のものもあります。たとえば、「単価」について考えてみます。この単価はファクトなのかディメンションなのかというのがここでの論点です。この項目がファクトテーブルの集約や集計につかわれるのであればこれはディメンションとなります。単価そのものを集計するということは通常は考えられませんが、「私は単価100円と1000円のどちらを多く販売したのだろうか」という集計を行うのであればこれはディメンションとなります。 扱い個数単位(ロット)はディメンションで、個数の小計はファクトです。ロットとトランザクション数を掛けたものを集約・集計する場面は十分に考えられます。この2つについては多次元データモデル設計においては明確にどこに配置すべきかというのは決まっています。

行動分析結果としてのディメンション

ファクトの分析をする際に、今までの行動分析の結果を利用することがあります。この説明だけだと理解しにくいので具体的な例を挙げます。「100万ドル以上の売り上げを出した顧客は売り上げが50万ドル以下の顧客と比較して値引き率は大きいのか」という分析です。この分析をするためには顧客の過去の注文実績をもとに分類する必要があります。この分類はディメンションとして持つことになります。このファクトテーブルを分析して求めるディメンション項目は「行動ディメンション(behavioral dimension)」と呼ばれます。この項目はディメンションとファクトの両方の意味を持つことになります。

(つづく)