TOP＞設計・移行・活用＞ 設計フェーズ システム企画担当者のためのBIシステム導入の勘所 〜速く、安く、確実に導入するには〜 第７回：BIシステムをつくってみる−実践編（2） 設計と構築 著者：アイエイエフコンサルティング  平井 明夫   2005/1/12 1   2  3  4  次のページ    読者の皆さん、こんにちは。前回は、例題として提示されたユーザー企業のシステムに対する要望から、実際に導入計画、要件定義の2つのフェーズを行いました。今回は、設計フェーズから開始します。 設計フェーズ （参考：第5回「BIシステムの特性を知る」-3P）    設計フェーズの最初のタスクはシステム方式設計ですが、今回は、このタスクは省略して以下のような結果を前提として作業を進めます。 システム方式 データウェアハウスは、OSとしてLinux、RDBとしてPostgreSQLが使用されている。 BIツールとしては、M-OLAP方式のOpenOLAPを採用する。 OpenOLAPを動作させるハードウェアは、データウェアハウスのサーバーと共有する。 障害時のリカバリーは特に考慮しない。    さて、このようなシステム方式設計の結果を前提とすると、これ以降の設計フェーズのタスクとしては、多次元データベース設計と画面設計の2つだけが必要になります。 多次元データベース設計の実際    それでは、多次元データベース設計を行ってみましょう。ディメンショナル・モデリングの結果から、「売上実績」という名前の多次元データベースを1つ作成します。    まず、次元階層定義を行います。この多次元データベースを構成するディメンションは、時間、製品、チャネルの3つです。それぞれのディメンションについて、ディメンションの定義結果をもとに各レベルを記入していきます。図1が、その結果です。 多次元DB名 次元数 次元名 レベル1 レベル2 レベル3 レベル4 売上実績 3 時間 年 月     製品 合計 製品クラス 製品ファミリー 製品 チャネル 合計 チャネル     図1：多次元データベース設計〜次元階層定義    ここで、注意すべきは、レベル1です。時間ディメンションは、ディメンションの定義のとおり、年、月の2階層になっていますが、製品ディメンションとチャネル・ディメンションの場合は、レベル1に合計という項目が記入されています。この合計というのは、それぞれ、全製品についての合計、全チャネルについての合計を意味します。通常、時間ディメンションの場合は、全期間の合計値という項目は必要とされませんが、それ以外のディメンションについては、ディメンショナル・モデリングの際には明示されなかった総合計の値が実際の分析では必要とされます。このような総合計の値の有無は、この段階で明確に定義しておく必要があります。    次に変数次元マトリックスを作成します。この多次元データベースを構成するメジャーは売上金額とコストの2つです。それぞれのメジャーについて、ディメンショナル・モデリングの結果をもとに、各ディメンションとの対応を記入していきます。図2がその結果です。 多次元DB名 変数名 積上げ方式 次元名 時間 製品 チャネル 売上実績 売上金額 加算 ○ ○ ○ コスト 加算 ○ ○ ○ 図2：多次元データベース設計〜変数次元マトリックス    ここでも、ディメンションナル・モデリングでは明示されなかった項目が1つあります。それが、積上げ方式です。この例では、いずれのメジャーについても加算が記入されています。これは、それぞれのレベルの集計値が、最下層から順々に加算されていく処理を行うということを示します。加算以外でよく使用される積上げ方式に平均があります。この場合は、単純な積上げではなく、どのレベルの集計値も全てファクトのデータから都度計算する必要があります。そうしないと図3のように6.8となるべきところが7になってしまうように間違った値が計算されてしまう可能性があります。 図3：誤った平均値の積上げ計算の例    以上で多次元データベース設計が終了しました。 1   2  3  4  次のページ 著者プロフィール 株式会社アイエイエフコンサルティング  平井 明夫 日本DEC（現hp）、コグノス、日本オラクルを経て現職。一貫してソフトウェア製品の開発、マーケティング、導入コンサルティングを歴任。 特に、データウェアハウス、BI、OLAPを得意分野とする。現在、企業業績管理、管理会計などデータ分析ソリューションの短期導入を可能にするテンプレートやパッケージの開発を行っている。 INDEX 第７回：BIシステムをつくってみる−実践編（2）設計と構築 設計フェーズ   画面設計の実際   構築フェーズ   （1）ディメンションの登録