| Oracle Business Intelligence Standard Edition Oneチュートリアル リリース10g（10.1.3.2.1） E05487-01 |
|
 戻る |
この章では、データ・マートの設計で発生する問題を見ていきます。この章は、データ・マートの実装プロジェクトを実行する際のヒントをまとめたものと考えてください。作業内容を把握することと同じくらい重要なのが、注意すべき点、つまり、このようなプロジェクトでつまづく要因になるおそれのある事柄（技術上の問題だけではない）を把握することです。データ・マートに対するビジネス面での促進要因は、情報に対するニーズであり、設計プロセスは、ビジネス・ニーズの洗い出しから始めるのがベストです。設計プロセスには、できるだけ早い段階で、ビジネス・スポンサーやエンド・ユーザーなど、データ・マートに投資している人たちを参画させるようにしてください。データ・マートが満たす必要のある情報要件、データソース、技術要件（ソースからデータをリフレッシュする必要のある頻度など）、およびプロジェクトの成功基準に関して、全員で合意に達する必要があります。
データ・マートの設計手順は次のとおりです。
プロジェクトのスコープを定義するための調査の実施
データ・マートのビジネス要件と技術要件の定義
データ・マートの論理設計および物理設計の開発
この章は次のトピックで構成されています。
データ・マートの実装を開始する前に、納入計画を作成する必要があります。この計画に反映すべき重要な情報は、ユーザーの情報要件と優先順位です。この情報の定義と承認をビジネス・スポンサーが行ったら、主要な成果物のリストを作成し、各成果物の担当者をチームのメンバーに割り当てることができます。
最初に行う作業は、プロジェクトのスコープを定義することです。データ・マートのスコープは、プロジェクトの境界を定義するものであり、通常の場合、地理、組織および適用分野、またはビジネス機能を組み合せた形で表現します。スコープを定義する際には、完了予定日および納入を約束した機能と、リソース（人、システムおよび予算）のバランスをとりながら、妥協を図ることが通常必要になります。スコープを定義し、それを関係者全員に周知徹底することが重要です。その理由は次のとおりです。
適切な期待値が設定される
段階的な開発の優先順位が決まる
リスクと問題点がハイライトされる
費用を見積ることができる
データ・マートの実装を開始するには、ビジネス要件と技術要件を定義する必要があります。ただし、ユーザーが最初の実装を使用して、自分の要件をより上手に伝達できるようになるのに従って、この要件は変化することがあります。データ・マートは、ユーザーからのフィードバックに応じて進化するため、データ・マートの開発は反復プロセスです。
この項は次のトピックで構成されています。
データ・マートの目的は、特定の部門や機能領域に固有のデータにアクセスできるようにすることです。このデータは、エンド・ユーザーが実行する種類の分析にとって意味のある詳細レベルであることが必要であり、エンド・ユーザーに理解されるビジネス用語で提示する必要があります。データ・マートのデータを分析すると、ビジネス面でより多くの情報を得た意思決定ができるようになると予想されます。したがって、ビジネス・パーソンが意思決定を行う仕組み、具体的には、意思決定プロセスでユーザーが尋ねる質問や、それらの質問に回答するために必要となるデータを理解する必要があります。ビジネス・プロセスを理解する最良の手段は、ビジネス・ピープルへのインタビューを実施することです。これらのインタビューで洗い出された要件が、データ・マートのビジネス要件を構成します。
データ・マートの要件を収集する際には、作業対象を1つのサブジェクト・エリアの情報ニーズに絞る必要があります。最初からすべての情報を網羅した詳細な要件ドキュメントなどなく、変化するニーズに対応できるようにデータ・マートを設計する必要があることを忘れないでください。ただし、新しいサブジェクトを導入したり最重要テーマから逸脱した場合、絞込みやスケジュールは通用しなくなります。
たとえデータ・マートが1つのサブジェクト・エリアに対応していても、サブジェクト・エリアには数多くのビジネス・ユーザーがおり、要件や期待値もユーザーごとに異なります。インタビューの対象として、ビジネス・エリアごとに少なくとも1人を特定するようにしてください。たとえば、マーケティング用のデータ・マートを構築する場合、マーケティング機能の多様な面に関与する人たちにインタビューします（マーケティング・アナリスト、チャネル専門家、直販管理者、プロモーション管理者など）。
一貫性のある一連の質問を使用するか、インタビューごとにインタビュー・テンプレートを使用します。この質問の対象は、内容、更新頻度、優先順位、詳細レベルなど、ユーザーの情報要件に絞ってください。最後に、インタビューおよび要件収集フェーズに明確な時間制限を設けてください。そうしないと、各要件を絞り込もうとして無限に作業が続くおそれがあります。この期間内にすべての要件を収集することはできませんが、ロードマップの作成には十分な情報が得られます。ニーズは実装期間中に変化します。これを受けて、変更リクエストを評価してそれに対応する手段、あるいはリクエストを却下して将来のフェーズで検討する手段が必要になります。
技術要件を洗い出す必要があります。この要件によって、データ・マートにフィードするデータをどこで取得するかを指定します。データ・マートで使用するデータのプライマリ・ソースは、日常のトランザクション・アクティビティを処理する業務系システムです。通常の場合、これらの業務系システムは、オンライン・トランザクション処理（OLTP）システムです。データ・マートには、そのような複数の業務系ソースからフィードされる場合があります。ただし、通常の場合、中間処理を行わずに業務系システムのデータをデータ・マートに変換することはできません。業務系データがどれだけクリーンであるか、また他のソースと統合するためにどれだけのフォーマットまたは変換が必要であるかを理解する必要があります。また、データのリフレッシュまたは更新が必要となる頻度を判断する必要があります。たとえば、比較的長期間の計画や分析にデータを使用する場合、フィードの頻度は、日次でなく週次または月次にすることが必要になります。ただし、更新の頻度がデータ・マートにおける詳細レベルを決定するとはかぎりません。週次で要約されたデータを月次でフィードすることもできます。このデータ・マート設計の第1フェーズでは、データソース、必要なデータ・クレンジングの種類、およびデータをリフレッシュする頻度を特定する必要があります。
インタビューを終了すると、データ・マート・アプリケーションが満たす必要のある一連の情報要件およびパフォーマンス要件が手元に残ります。現実的な判断でニーズの優先順位を決め、成功基準のリストを作成する必要があります。リストの優先順位を決めるには、次のように自問自答してください。
パフォーマンスが最優先の懸念事項か。
システム構成によって制約されているか。
データの更新またはデータへの追加を行う頻度はどれくらいか。
データ・マートは部門別データに対する総合的なソースとユーザーが考えているか、または、スコープ内のデータ・マートはその部門内の特定のトピックに限定されているか。
スコープがITアーキテクチャと整合性がとれているか、または、自律型の開発が可能か。
優先順位と重要な成功要因を定める際には、これらの質問に対する回答を考慮してください。
まとめとして、要件定義プロセスを容易にするためのガイドラインをいくつか次に示します。
プロセス全体にエンド・ユーザーを参画させる。
要件分析フレームワークを分類し、ビジネス・スポンサー、ITアーキテクト、データ・マート開発者およびエンド・ユーザーの要件を定義する。
エンド・ユーザーの期待値を管理する。
設計ステージの開始時点では、ビジネス要件がすでに定義され、データ・マート・アプリケーションのスコープに合意が得られ、概念設計ができています。ここで、要件をシステム成果物に変換することが必要になります。この手順では、データ・マートの論理設計および物理設計を作成します。そのプロセスでは、データの具体的な内容、データのグループ内およびグループ間の関係、データ・マートをサポートするシステム環境、必要なデータ変換、およびデータをリフレッシュする頻度を定義します。論理設計は物理設計に比べて、概念性も抽象性も勝っています。論理設計では、オブジェクト間の論理的な関係を見ていきます。物理設計では、オブジェクトを格納および取得する最も効果的な方法を見ていきます。
データ・マート設計は、エンド・ユーザーのニーズに合せて調整する必要があります。エンド・ユーザーは通常、分析を行い、個々のトランザクションではなく集計されたデータを見ます。設計の最大の原動力となるのはエンド・ユーザーにとっての実用性ですが、エンド・ユーザーは、実際に見るまで自分にとって何が必要であるかわからない場合もあります。適切に計画された設計であれば、ユーザーのニーズが変化および進化するのに合せて、拡大と変更が可能です。
最初の要件を満たすのに成功するかどうかは、設計の質にかかっています。システムやネットワークのリソースが無限にあるなどという贅沢な環境はありえないため、リソースの最適利用は主として設計に左右されます。最初に論理設計を行うことで、対象が情報要件に絞られ、詳細な実装作業がすぐに難航する事態は避けられます。
トップダウン形式の作業を強いられるわけではないことに注意してください。既存のデータ・スキーマに対してリバース・エンジニアリングを実行し、そこから設計を開始することも可能です。データ要件が明確になっていて、ソース・データに習熟している場合は、物理設計のレベルから作業を開始し、物理的な実装に直接進むこともできます。実際には、適切な設計を実現するまでに、反復作業をいくつも行います。
この項は次のトピックで構成されています。
論理設計とは、概念的で抽象的な設計のことです。物理的な実装の詳細には、まだ対処しません。対処するのは、必要な情報のタイプを定義することのみです。論理設計のプロセスでは、一連の論理的な関係にデータを配置します。この関係を、エンティティおよび属性と呼びます。エンティティは、情報のチャンクを表します。リレーショナル・データベースでは、多くの場合、エンティティは表にマッピングされます。属性はエンティティの構成単位であり、エンティティの一意性を定義するのに役立ちます。リレーショナル・データベースでは、属性は列にマッピングされます。
エンティティ関連ダイアグラムは従来、OLTPアプリケーションなど、高度に正規化されたモデルと関連付けられてきましたが、その手法は、ディメンション・モデルにも有用です。ただし、アプローチのやり方が異なります。ディメンション・モデルでは、情報の原子単位と原子単位間の関係すべてを検出しようとするかわりに、どの情報がファクト表に属しているか、またどの情報が関連するディメンション表に属しているかを特定しようとします。
設計に対する注意が欠かせません。設計プロセスでは、ビジネス要件を常に手元に用意しておきます。これより大事なものはありません。
設計プロセスの一環として、ソースの業務系データを、ターゲットのデータ・マート・スキーマのサブジェクト指向情報にマップします。ビジネス・サブジェクトつまりデータのフィールドを特定し、ビジネス・サブジェクト間の関係を定義して、各サブジェクトの属性に名前を付けます。
データ・マート・スキーマの決定に役立つ要素は、ソース・データのモデルおよびユーザー要件です。会社のエンタープライズ・データ・モデルからソース・モデルを取得したり、ここからデータ・マートの論理データ・モデルに対してリバース・エンジニアリングを実行することもできます。コンピュータのサイズ、ユーザーの数、格納容量、ネットワークのタイプ、ソフトウェアなど、システム・パラメータが原因で、論理データ・マート・モデルの物理的な実装を変更することが必要になる場合もあります。次のような論理設計を開発する際に、意思決定を下すことが必要になります。
ファクトとディメンション
ファクトの粒度
エンティティ間の関係
データの履歴期間
ビジネス・ユーザー要件から、データ要素の要望リストを生成します。このチュートリアルでは、データ・マートのスコープはユーザーが全面的に指定すると想定しています。多くの場合、ユーザーの具体的なリクエストにとどまらず、それ以上のことにも目を光らせ、将来のニーズを予測する必要があります。
最初に検討するのは、サブジェクト・エリアにとって重要なビジネス・パラメータです。営業およびマーケティングのデータ・マートでは、パラメータとして、「顧客」、「地域」、「商品」、「セールス」および「プロモーション」が考えられます。「時間」も忘れないでください。数値を見る頻度として、月次、日次、週次のいずれかを指定します。
次に、ユーザーが指定した要件から、あるいはユーザーとブレーンストーミングして、目的のデータ要素のリストを作成します。この演習が終了した時点で、次の内容が準備できます。
データ要素のリスト（生データと計算済データの両方）
データの属性（文字や数値などのデータ型）
データの妥当なグループ分け（国、都道府県、市区町村の要素に対する地理的な地域など）
データ間の関係の考え方（「市区町村は都道府県に含まれる」など）
営業およびマーケティングの例では、関心を持たれる代表的なデータ・フィールドとして、売上金額、売上個数、製品名、パッケージ、プロモーションの特徴、地域、国が考えられます。データ・マートを作成するための原動力となる重要なフィールドを特定します。営業データ・マートにとっては、売上金額や売上個数などのデータが重要です。
ユーザーからレポートが提供され、それによってデータ要件の考え方が生まれる場合があります。それらのレポートは、既存のレポートの場合も、ユーザーが見たいと思う種類のレポートの場合も考えられます。レポートは、ユーザーにニーズを明瞭に表現させるためのよい手段です。
この時点で、数値データ（ファクト）とテキストによるデータまたは記述的なデータ（ディメンション）に、データを分けることができます。エンド・ユーザーとの対話という反復プロセス中に、あるデータが重要である理由、つまり、このデータがどのような意思決定の原動力となるのかを質問してください。ビジネス・プロセスに対する洞察を深めると、データに対する将来のニーズを予測しやすくなります。
この時点で、データ・マート用のディメンションおよびファクトのリストが用意されています。問題は、データを入手できるかどうかです。そして入手可能な場合は、その対価です。データソースとしては、注文入力システムなどの業務系システムから、スプレッドシートまで考えられます。要望リストからソースに、個々のデータ要素をマップする必要があります。最も大きく最も総合的なソースから始め、必要に応じて他のソースを求めてください。
通常の場合、データのかなり多くの部分は、ソースが1つか2つです。ディメンションは通常の場合、オペレーティング・システム内の参照表にマップできます。ファクトは、未加工の形式で、トランザクション表にマップできます。トランザクション・データは通常、データ・マートで使用できるようにするため、粒度の指定レベルに基づいて集計する必要があります。粒度は、ユーザーが望む可能性のある最低レベルの情報です。要求したデータの一部がマップできない場合もあります。通常、この事象が発生するのは、ソース・システムのグループ分けが、データ・マート内で求められるグループと整合性がとれていない場合です。たとえば、通信会社では、コールは市外局番別に簡単に集計できます。ただし、データ・マートでは郵便番号別のデータが必要です。1つの市外局番には複数の郵便番号が含まれ、1つの郵便番号は複数の市外局番にまたがる場合があるため、これらのディメンションをマップすることは難しくなります。
データの一部が、費用が高すぎて取得できない場合もあります。たとえば、ユーザーがプロモーションのデータを要求しても、その情報が時間やプロモーションにわたって整合性が取れていないため、容易に取得できないことがあります。共通のシステム・フォーマットに変換するには、かなり高い費用がかかります。
この時点で、ファクトおよびディメンションとしてデータを分類することについて考え始めています。データ・マートにおいて、ファクト、ディメンションおよびそれらの関係を一般的に表現したものがスター・スキーマです。通常の場合、そこには時間のディメンションが含まれ、アクセスと分析がしやすくなるように最適化されています。中央に大きなファクト表があり、その周囲に小さなディメンション表があるというように、グラフィカルな表現が星（スター）に似ているため、これをスター・スキーマと呼びます。
詳細な設計モデリングには、スノーフレーク・スキーマや星型スキーマと呼ばれるスキーマを使用する場合があります。これらのスキーマは、表示される単純なスター・スキーマより複雑です。次の項では、ディメンション、ファクトおよび粒度のレベルの詳細について説明します。
この項は次のトピックで構成されています。
分類演習では、OLTPソースのフィールドの多くがディメンションとなります。設計上の大きな問題は、フィールドが既存のディメンションの別項目にすぎないのか、独自のディメンションを設定すべきなのかを判断することです。OLTPソース内のばらばらの日付を使用して、時間ディメンションが個別に生成されます。これによって、時系列の分析を実行する際の柔軟性が実現します。真のスター・スキーマの場合、ディメンション表の作成順序は、ファクト表より前に作成されるかぎり、問題にはなりません。一般的に、ある表を作成しておかないと、他の表からの参照ができません。したがって、最初にディメンション表をすべて作成するようにしてください。
ファクトとは、ビジネスの数値指標です。ビジネスに関するレポートの作成およびビジネスの分析に使用する数値計算をサポートします。一部の数値データは、たとえ見た目がファクトであっても、実はディメンションです。ある項目の集計に関心がない場合、その項目は実際にディメンションとなることもあります。どちらとも決めかねるフィールドをディメンションに分類した場合は、データベースのサイズと全体のパフォーマンスが向上します。
たとえば、ヘルス・クラブの会員データベースがあり、クラブのブランドで売り出しているビタミン剤を会員がどれだけ買っているかを調べると想定します。要望リストには、「年齢別の使用方法を...別に知りたい」や「会員の平均年齢を...別に知りたい」のような問合せがいくつかあります。この場合、年齢はファクトでしょうか、ディメンションでしょうか。年齢はディメンションとします。
ファクトとディメンションを定義したら、データ・マートにおけるデータの適切な粒度を決定します。この時点では、ディメンション内の特定のレベルの情報をユーザーが要求した理由がわかります。要求されたレベルの粒度に対応できるようにリソース要件を見積る必要があり、費用に基づいて、このレベルの粒度をサポートできるかどうかを判断する必要があります。
ファクト、ディメンションおよび目的のレベルの粒度をすべて定義したら、スター・スキーマを作成する用意が整ったことになります。次の手順は、キーを使用して、ファクト表とディメンション表の関係を定義することです。
主キーは1つ以上の列で、行を表の中で一意にします。ファクト表の主キーは、複数の列で構成される場合があります。そのようなキーを、コンポジット・キーまたは連結キーと呼びます。
ファクトとディメンションを結び付けるには、自然キーのかわりに、システムで生成されたキー（合成キー）を使用するのも一案です。こうすると、データ・マートの管理者は、たとえ業務系システムでキーの変更があっても、データ・マート環境内のキーを制御できます。
合成キーとは、生成された連続する整数のことです。自然キーに加えて、合成キーをディメンション表に入れます。次に、ファクト表をディメンション表に連結する列として、ファクト表の合成キーを使用します。
合成キーを作成するには、計画や作業が追加で必要になりますが、合成キーがあると、次に示すように、自然キーを上回る利点が生まれます。
自然キーは、製品コードのように、長い文字列になりがちです。合成キーは整数なので、問合せに対する応答時間が短縮されます。
データ・マートの管理者が合成キーを制御できます。製造グループが製品コードのネーミング規則を変更しても、データ・マートの構造には影響がありません。ほとんどのディメンション表に合成キーを使用することを検討してください（このチュートリアルの残りの部分では、合成キーをウェアハウス・キーと称します）。
OLTPデータベースのデータを変換してターゲットのスター・スキーマにロードするプロセスでは、スキーマ間のマッピングが必要になります。このマッピングには、集計などの変換が必要になる場合もあります。
物理設計プロセスでは、論理設計フェーズで収集したデータを、表や制約など、物理データベースの記述に変換します。この記述によって、物理データベース構造の配置が最適化され、最高のパフォーマンスが得られます。データ・マートのユーザーは特定のタイプの問合せを実行するため、データ・マート・データベースを最適化して、それらのタイプの問合せで優れたパフォーマンスを発揮できるようにします。索引のタイプやパーティション化など、物理設計に関する意思決定によって、問合せのパフォーマンスに大きな影響が及びます。
データ・マートが成功を収め、より幅広く使用されるようになると、アクセスするユーザーの数もずっと多くなります。時間の経過に応じて、データの数量も増大します。論理設計から物理表現に移行するとき、重要な検討事項となるのが、データの数量とユーザーの数を増やす能力、つまりスケーラビリティです。スケーラビリティに対するニーズに対応するには、ハードウェア容量、ソフトウェア、ネットワーク帯域幅などの制限要因を最小限に抑える必要があります。
この項は次のトピックで構成されています。
データ・マートのサイズを見積る際には、将来の増大に対応する方法を開発する必要があります。データベースのサイズを見積る方法はいくつかあります。1つのアプローチを次に示します。
ソース・データの代表的なサンプルを使用して、ファクト表の行の数を決定します。
ファクト表の行のサイズを見積ります。
行の数と1行のサイズを乗じて、ファクト表の行のサイズを見積ります。
データ・マートのサイズを見積ります。一般的に、データ・マートの合計サイズは、ファクト表のサイズの3〜5倍です。
このプロセスは通常、反復します。設計が変更するたびに、サイズの見積りをやりなおす必要があります。たとえスター・スキーマが小さいと思っても、この計算を一度行う必要があります。
サイズを計算したら、次の作業を行って想定内容を検証できます。
サンプル・ファイルを抽出します。
データベースにデータをロードします。
予想される行の正確な長さを計算します。
索引付け、ロールバックおよび一時表領域にかかるオーバーヘッドを追加し、フラット・ファイルに対するファイル・システムのステージング領域を追加します。
将来の増大を加味して計画を立てるには、次の手順で、ファクト表の見積ったサイズと最大の可能サイズの比率を使用して、データ・マートの将来のサイズを計算できます。
ディメンションごとに、目的の粒度をチェックして、最も細かいレベルの粒度でエントリの数を見積ります。
すべてのディメンションのエントリ数を乗じて、最大の可能行数を算出します。
代表的なデータの実際行数と可能行数の比率を計算します。
ある期間での各ディメンション表の増加率を見積ります。
すべてのディメンション表の行数を乗じます。
手順3で計算した比率を使用して、この数を調整します。
この結果にファクト表の行サイズを乗じます。
通常のバッチ・ジョブをスケジュールして、ソースのデータ・マートをリフレッシュすることが必要になる場合もあります。データ量とシステム・ロードによっては、このジョブに数時間かかる場合があります。データ・マートをリフレッシュする計画を立て、平常の状況では、バッチ処理に許可された時間帯（通常は夜）に達成できるようにします。プランニング・プロセスでは、リフレッシュされるデータ量も見積る必要があります。指定された維持期間を超えたデータを消去する方針を作成します。
メタデータとは、データに関する情報です。データ・マートの場合、メタデータの内訳は次のとおりです。
ビジネス用語でのデータの説明
システム用語でのデータのフォーマットおよび定義
データソースと、データのリフレッシュ頻度
メタデータ管理プロセスでの最大の目的は、データ・マートのメタデータの技術面でのビューおよびビジネス面でのビューのディレクトリを用意することです。メタデータは、技術メタデータとビジネス・メタデータに分類できます。
技術メタデータは、データ・マートの作成時に作成されたメタデータと、データ・マートの管理をサポートするメタデータで構成されています。これには、データ取得ルール、ターゲットのデータ・マートで要求されるフォーマットへのソース・データの変換、およびデータのバックアップとリフレッシュのスケジュールがあります。
ビジネス・メタデータでは、データ・マートで使用できる情報は何か、またそのデータにはどのようにアクセスできるかを、エンド・ユーザーが理解できます。
Oracle Warehouse Builderコンポーネントに対するデータ抽出ルールおよびリフレッシュ・スケジュールを決定するには、技術メタデータを使用します。同様に、Oracle BI Answersツールで使用するビジネス・レイヤーを定義するには、ビジネス・メタデータを使用します。
