ビジネス・インテリジェンスが情報を活かす！

進化を続けるDB2 Data Warehouse Edition


レベル：

2006年6月16日（金）

第1回情報活用インフラ「DB2 Data Warehouse Edition V9.1」の新機能と情報系のデータモデル

	はじめに

	追加された新機能

	情報系のデータモデル

はじめに

社内のデータ統合や全社的な活用が不可欠となった昨今では、統合されたデータの活用が必要です。データの品質、信頼性をもつデータウェアハウスの構築、データの分析、マイニングを実施するためのインフラストラクチャーが、DB2 Data Warehouse Editionです。今までの強力な製品インフラに加え、新しいバージョンである9.1では、統合開発環境（Design Studio）、統合管理環境（Administration Console）、新しいETL環境が追加をされ、製品同士の連携が容易に行え、トータルなコストを安価に抑えることができます。

第1回目の今回は、新機能の説明、統合開発環境（Design Studio）を利用してデータモデルの定義について触れていきます。

補足

	この記事の執筆時には、日本語バージョンは未だ出荷されておらず画面は、英語版のものを使用しています。

	DB2 Data Warehouse Editionに含まれる各製品の説明は、『情報活用インフラ「DB2 Warehouse Edition」が提供するBIテクノロジー』の記事をご参考ください。

上に戻る

追加された新機能

開発環境と管理環境の統合
以前までのDB2 Data　Warehouse Edition V8.x では、各ツール毎（ETL機能はWarehouse Manager、OLAP機能はDB2 Cube Views、マイニング機能はDB2 Intelligent Miner)に開発や管理を行っていました。新しいDB2 Data Warehouse Edition V9.1では、各ツールの開発や管理は統合され、開発生産性の向上やツール切り替えを行うわずらわしさがなく、ユーザビリティーが向上しました。
開発環境はEclipse ベースのDesign Studioに、管理環境はWebベースのAdministration Consoleに統合されています。

DB2 Data Warehouse Editionのアーキテクチャー

拡大図

統合開発環境（Design Studio）
Eclipsでの開発概念であるプロジェクトによりリソース管理は一元化され、必要な場合のみデータベースに接続をして定義を反映をします。プロジェクトとは、開発単位を1つの集合としたもので、データウェアハウスの構築では　「Data Design Project (OLAP)」と　「Data Warehouse Project」の2つが提供されています。 Data Design Project (OLAP)は、新規にデータモデルを作成するフォワードと、既存データモデルから参照するリバースの2つの方法を提供をしています。　Data Warehouse Projectは、DB2 Cube Viewsと連携したOLAP（キューブ）やデータウェアハウスからデータマートを作成するETL処理(SQL Warehousing)、マイニングフローのリソース定義を行います。開発の基本は、Data Design Project (OLAP)でデータモデルを定義し、Data Warehouse Projectから定義された表やビューを、ETL処理等のソース表やターゲット表として利用します。



データベースエクスプローラ

		Data Design Project (OLAP) 表、ビュー、インデックス等のDDL文、OLAPのメタデータを定義しデータベースに反映します。起動時はデータベース接続はしておらず、定義情報はEclipsのローカルディレクトリーに保存され、明示的にデータベースに接続しDDL文を実行します。リバースを使用すると既存データモデルの変更(Alter文)が可能です。

		Data Warehouse Project プロジェクト下にSQL Warehousing の処理フローやDB2 Intelligent Minerのマイニングフローのリソースを定義します。

Design Studio画面イメージ

統合管理環境（Administration Console）
WebSphere Application Server下で管理するブラウザーベースの統合管理環境で、管理に特化しているので容易に使用ができ、マルチプラットフォームで参照できます。

	ロールベースのセキュリティー機能管理者、開発者、一般ユーザーという3種類のロール（役割）によってセキュリティーを管理しています。

	SQL Warehousing 管理機能 Design StudioからSQL Warehousingの処理定義を連携し、ETL処理の実行やスケジューリングによるバッチ起動が行えます。ETL処理の実行結果や実行履歴のログを参照できます。

	OLAP 管理機能 Design StudioからDB2 Cube Viewsの集約表(MQT)の定義を連携し、キューブを作成します。また、キューブモデルのインポートやエクスポート処理、OLAPメタデータの参照ができます。

	その他の管理機能 DB2 Intelligent Minerのモデリング管理やAlphabloxのアプリケーションページを表示します。また、さまざまな管理ログを参照できるのでトラブルシューティングに使用できます。

Administration Console画面イメージ

新しいETLツール（SQL Warehousing）
新しいELT環境として、SQL Warehousingが提供され、データウェアハウスやデータマートを構築します。
Design Studioでは、データフローとコントロールフローを定義します。データフローは、ソース（処理元）とターゲット（処理先）を指定して1つの処理とします。コントロールフローは、データフローを複数記述しジョブフローとし、処理成功や失敗の結果による処理を定義します。また、ETL処理定義の検証にはJDBC接続によるデバッグ環境とETL処理をプロシージャー化する機能を提供しています。
Administration Consoleでは、プロシージャーを連携しWebSphere Application Server経由でDB2に登録し、ジョブの実行やスケジューリング管理を行います。

SQL Warehousingの開発

上に戻る

情報系のデータモデル

スタースキーマデータモデル
まずは、どのような分析要件でどの範囲でデータウェアハウスを作成するかを決定をします。範囲の決定には、基幹系を構築した時に作成をしたデータベースの概念設計や論理設計の出力であるER図や項目定義書を参考にすることができます。では、データウェアハウスにはどのようなデータモデルが適しているのでしょうか。

基幹系システムのデータモデルでは、データベース更新に適した正規化データモデルですが、データウェアハウスとしても使用される場合があります。しかし、分析系の処理から直接参照するデータウェアハウスやデータマートでは分析を意識したスタースキーマデータモデルを推奨します。スタースキーマモデルとは、中央に履歴や意思決定に使用する大きな表(以下、ファクト表)を配置し、その周辺に期間表、商品表、顧客表などの　参照用のマスター表(以下、ディメンション表)を配置します。スターの形をしているのでこの名前がつけられました。ファクト表とディメンション表は、ディメンション表にある主キーをファクト表の外部キーで参照することで関係づけしています。(参照整合性)

	分析要件からデータモデルへの反映スタースキーマデータモデルは、分析軸となるディメンション表、分析対象値を格納したファクト表、それらを明確に関連付けられたジョインパスから構成されており、分析要件とデータモデルを直接関連づけができます。データベースに不慣れなアナリストでも理解でき、データモデルが短期間で構築できます。

	スタースキーマ構成の時間軸時間軸をもつことで、過去データを数年にわたり保持ができます。さまざまな方向（ディメンション軸）からのOLAP分析（ドリルダウン、ドリルアップ、ダイス、スライス）ができます。

	スタースキーマモデルに特化したデータベース機能分析時のデータベースでは、複数のディメンション表とファクト表で結合処理をします。DB2では、特別なジョイン処理（スタージョイン）で最適化されており、クエリーの応答が高速です。

	データ整合性データが中央（ファクト表）に集中しているので冗長なデータを引きおこしません。情報系の大規模データウェアハウスでは、　データの整合性や値の真実度が重要です。

スタースキーマモデルの例

Design Studioでの物理データモデル定義
以前のバージョンでは、データベースを作成するDDL文はユーザー自らがコーディングを行う必要がありました。DB2 Data Warehouse Edition V9.1では、Design StudioにIBM Rational Data Architect の物理データモデル定義を行うコンポーネントが含まれており、エンティティーや制約を1つの部品としてモデル図にカットアンドペーストをして、容易に定義ができます。定義は、データデザインプロジェクトの作成、デザインエディターでのモデル定義、モデル定義の検査、クエリーの自動生成の手順で実施をします。では、各手順を説明していきましょう。

1.	データデザインプロジェクトを作成データデザインの元になるプロジェクトを作成をします。作成では、デザインプロジェクト名、接続するデータベース名、データベースのバージョン、作成方式を選択をします。作成方式では、データベースモデルを新規に作成するか、既存のデータモデルからリバースエンジニアリングで構成情報を読み込み、修正するかを指定をします。

2.	デザインエディターでのモデル定義エディターで、データモデルを定義をします。右側の部品パレットから、表と参照性制約の部品を選択しエディターに貼り付けます。例では、「売上」がファクト表、「年月日」「店舗」「サイズ」「商品」がディメンション表で、表間は参照制約で結ばれているスタースキーマ構造であることがわかります。また、このエディター画面から、プライマリキー、カラム追加、索引、トリガー等のさまざまなDDL文の定義ができます。


3.	データモデル定義の検査エディターを使用して構築をした定義が、データベースのルールに沿って作成されているかを検査をします。不備がある場合は、エディターにたち戻り修正を行い再検査をします。


4.	クエリーの自動生成自動的にDDL文を作成します。作成をしたSQLは任意の位置に保存ができ、オプションによりデータベースへDDL文処理を実行できます。

上に戻る

レベルマークについて

このページで紹介されている情報はレベル別にカテゴライズされています。

			：	上級者向け
			：	中級者向け
			：	初級者向け
			：	入門者向け

製品紹介

DB2 Data Warehouse Edition

Rational Data Architect V6.1