DB Stories

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

ファクトテーブル(1)

データウェアハウスについての解説記事の4回目です。

前回までの記事

参考書籍は以下を利用しています。

Star Schema The Complete Reference

Star Schema The Complete Reference

ファクトテーブル

目的別データ(サブジェクトエリア)において、ファクトテーブルが一つだけ存在しているということは非常にまれです。ファクトテーブル一つで企業活動を包含することは不可能だからです。そのため、ほぼすべての場合において複数のファクトテーブルを扱うことを考慮する必要があります。

多次元データモデル設計における経験からも、それぞれの業務プロセスごとに一つのファクトテーブルが存在することがほとんどです。このことは、複数の業務プロセスを一つのファクトテーブルで包含する設計からくる複雑さはあまりなく、あくまでも、各業務プロセスが個別に分析されるというある意味考えやすいことを意味します。この章では「複数の業務プロセスまたがって分析する場合」つまり、ファクトテーブルを個別にみるのではなく、ある関連性を持って分析することについて解説を行います。

個別の業務プロセス分析についても重要ですが、プロセスをまたがる分析というのも重要になります。多次元データモデルにおいて、このことは複数のファクトテーブルから情報を得ることを意味します。不適切に分析した場合の例と正しい結果を得るための2つのステップについて解説を行う予定です。業務プロセスをまたがる分析(複数のファクトテーブルを分析すること)の方法について長所と欠点について解説を行います。

ファクトテーブルと業務プロセス

多次元データモデルは「どのように現実世界を分析するか」というのを表しているともいえます。今までの説明で強調してきたように、すべてのスタースキーマは一つのファクトテーブルが含まれていて、その業務プロセスのデータを保持しています。そのデータ、つまりファクトはそのスタースキーマに存在するディメンジョンにより意味(context)を与えられます。ファクトテーブルの粒度というのは記録することができるデータの粒度であると言えます。

ファクトテーブルを一つ持つか複数持つかという検討を行う際には、次のシンプルな考え方があります。「それぞれ個別に分析を行うため、各プロセスは別々のファクトテーブルを保持するべきである」

設計者がこのガイドラインに従うとき、分析者がそれぞれのプロセス分析を混乱なく行うことができます。まず最初に「プロセス」というあいまいな表現を明確に定義する必要があります。

読者としてはこのガイドラインが何を意味しているか困惑するかもしれません。「プロセス」とは何を意味するのか。この情報工学上の用語は「プロセスモデルにおける概念」と(あまりなじみはありませんが)「エンティティリレーションモデルにおける概念」の2つが存在します。エンティティリレーションモデルは情報を説明すために利用されますが、プロセスモデルは業務活動を説明するために利用されます。エンティティリレーションモデルは業務システムのデータベース設計で利用され、プロセスモデルはコンポーネント機能の設計で利用されます。

実はコレが実に厄介な話となります。プロセスモデルは「機能分解」という考えも含まれます。「あるプロセスはいくつかのサブプロセスにブレイクダウンできます」という例です。例えば、販売プロセスは「受注」「配送」 「請求」「返品管理」というサブプロセスを含みます。先に提示したガイドラインに従うとするなら多くの混乱が生じます。販売は一つのプロセスだが、別のプロセスにも関連しています。この時、販売分析は複数のファクトテーブルで行うべきかそれともひとつで行うべきでしょうか。

スタースキーマ設計においては、プロセスモデルの概念を使うのではなく、次の2つの非常に簡単なテストを持ってファクトテーブルを一つにするか分割するかというのを検討します。

  • これらの出来事(ファクト)は同時発生するものか
  • これらファクトは同一データ粒度で利用されるものか

もしこの問いに対して一つでも「No」となるのであれば、このファクトは別々プロセスであることを意味します。二つのファクトが同時発生するものでない、もしくは同じデータ粒度を持たない場合において別々のプロセスとなります。たとえば、「受注数量」「出荷数量」についての分析を考えてみます。「受注」と「出荷」は同時に行われるプロセスではありません。受注が行われた時、出荷に関する情報はまだ決定されてはいません。出荷情報は後から決定されるものです。「受注数量」と「出荷数量」は同一データ粒度は持ちません。出荷数量は配送方法によって決定されますが、受注は関連しないからです。

この例において、「受注数量」と「出荷数量」はテストに「No」ということになり、それぞれ別プロセスであると言えます。この2つについて分析を行う場合、2つのファクトテーブルを扱うことになります。このことを理解するためにさらに補足しておきます。

プロセスにおいて個別にファクトテーブルを保持することは全てのファクトテーブルが一つのプロセスを表しているというわけではありません。複数のプロセスを一つのファクトで表すことはプロセス間どおしの分析をする場合に有用です。他のファクトテーブルから集約を行い保持することになります(訳注:データマートを作成するということです)例えば、販売分析のため複数のスター(提案、受注、出荷、返品)を集約したファクトを作成するというものです。もしプロセス個別に分析する必要がなければ、プロセスごとにファクトを作成する必要はありません。このことがファクトを一つにするか複数に分割するかというジレンマともいえます。

(つづく)