Analysis Services 2005 の移行

  • [アーティクル]
このページはアーカイブです。記載されている内容は情報提供のみを目的としており、ページ内のリンクは有効でない可能性がありますが、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。

公開日: 2005年9月27日 | 最終更新日: 2005年10月20日

Michael Young (Proclarity Corporation)、Dave Wickert (Microsoft Corporation)

SQL Server 技術資料
対象製品 : SQL Server 2005

概要
このホワイト ペーパーでは、SQL Server 2005 の Analysis Services に移行する手順について説明します。統合ディメンション モデル (UDM) により、キューブ開発者は新しい設計方法を導入できます。UDM では、リレーショナル レポートと OLAP レポートの環境を組み合わせることにより、双方のデータ要求環境の統合フォーラムを実現します。新しいデザイン オプションと、それが組織に与える影響を理解することが、移行の最適化につながります。移行ウィザードは、既存のキューブを Analysis Services 2005 に移動するための高速で効率的なツールです。このホワイト ペーパーは、ウィザードについて理解して、ウィザードを使用した方がよいかどうかを判断するのに役立ちます。状況によっては、Analysis Services 2005 の新しい機能を十分に活用するために、キューブを初めから再設計した方がよい場合もあります。

トピック

プロジェクト REAL について
はじめに
移行に影響するキューブ設計の問題
移行ツール
プロジェクト REAL での移行
移行と再設計
まとめ

プロジェクト REAL について

プロジェクト REAL は、実際の顧客シナリオに基づいたインプリメンテーション リファレンスを構築することにより、Microsoft® SQL Server™ 2005 をベースとしたビジネス インテリジェンス アプリケーションを作成する最善の方法を見つける試みです。これにより、顧客データを社内に持ち込んで、開発中に顧客が直面する同種の問題にこれを活用することが可能となります。これらの問題には以下のものがあります。

  • スキーマの設計

  • データの抽出、変換、および読み込み (ETL) 処理の実装

  • 実稼動に向けたシステムのサイズ設定

  • 継続的なシステムの管理とメンテナンス

実際の展開シナリオで作業することにより、ツールの使用方法を十分に理解できます。目標は、大企業が独自の環境で実際の展開を行う際に直面するあらゆる問題に対処することです。このホワイト ペーパーでは、プロジェクト REAL での移行の役割について説明します。プロジェクト REAL では、Microsoft ビジネス インテリジェンスの顧客のデータを使用します。プロジェクトのフェーズ 1 は、Microsoft SQL Server 2000 データ ウェアハウスに売り上げと在庫データを格納している大規模な電気製品小売業務をモデルとしたものです。SQL Server 2000 データ変換サービス (DTS) を使用して、リレーショナル データベースへのデータ フローが管理されています。また、このリレーショナル データベースからレポートの作成と対話的なクエリを実行するための SQL Server 2000 Analysis Services キューブへのデータ フローも管理されています。この顧客は、およそ 200 GB のデータをリレーショナル ストアに格納しています。このデータはすべて、後で Analysis Services キューブのデータとして使用されます。フェーズ 1 の実装では、主に SQL Server 2000 の既存の顧客が SQL Server 2005 への移行を実行する際に直面する可能性のある問題に焦点を当てます。結果の大部分は、既存の機能の移行と共に、適宜使用するいくつかの新しい機能を示しています。Analysis Services の移行部分では、主に移行ウィザードを使用することにより、キューブ データが Analysis Services 2005 に移行されました。追加の機能は、新しいバージョンへの移行後にキューブに追加されました。

プロジェクト REAL のフェーズ 2 は、別の顧客のさらに大規模なデータ セットに基づいており、SQL Server 2005 のフェーズ 1 より多くの新機能が使用されます。これは、フェーズ 2 が主として SQL Server 2005 ソリューションを新たに実装しているためです。フェーズ 2 の目的は、Analysis Services の新しい機能を数多く例示することです。フェーズ 2では、キューブの再設計が必要だと判断され、移行ウィザードは使用されませんでした。プロジェクト REAL については、今後リリースされるホワイト ペーパーも参照してください。

はじめに

Analysis Services 2005 には、OLAP の新しい使用方法が用意されており、OLAP レポートとリレーショナル レポートの要件を完全に統合できます。Analysis Services 2005 を活用することにより、全体的なキューブ管理を減らす一方で、エンド ユーザーの操作環境を強化できます。統合ディメンション モデル (UDM) の設計方法を使用すると、リレーショナル レポートと OLAP レポートの環境をシームレスに結び合わせることができます。これにより、キューブの根本的な構造化方法が変わりました。

Analysis Services 2005 の新機能により、共通のナビゲーション パターンを効率的に使用し、リレーショナル レポートと OLAP レポートの両方の要件を満たすことが可能になります。さらに、一意のデータ型を扱って、分析の実行に関連するメモリのオーバーヘッドを減らすことも可能になります。

このホワイト ペーパーは、移行プロセスを理解し、自分の組織に最適な移行パスを決定するのに役立ちます。移行は、組み込みの移行ツールを使用するか、既存のキューブを再設計することにより行うことができます。このホワイト ペーパーでは、Analysis Services 2005 における設計の変更と、それらの変更が現在のキューブ構造に与える影響について説明します。

このホワイト ペーパーでは、移行ウィザードの主な手順について説明します。さらに、ウィザードを使用すべきかどうかを判断する際に生じるいくつかの疑問点も示します。

このホワイト ペーパーは、はじめに移行ウィザードを使用すべきか、またはキューブを始めから再設計すべきかを判断するのに役立ちます。

移行に影響するキューブ設計の問題

Analysis Services 2005 のキューブは、この製品の以前のバージョンにおけるキューブとは大きく異なります。移行ウィザードを使用して移行する場合、Analysis Services により新しい環境に既存のキューブが複製されます。この場合は新しいプラットフォームにすばやく移行できますが、Analysis Services 2005 の新しい設計機能をすべて活用することはできません。

Analysis Services 2005 では、統合ディメンション モデル (UDM) が導入されました。UDM の役割は、OLAP レポートとリレーショナル レポートの環境をシームレスにまとめることです。もともと、OLAP 環境は、ナビゲーション パスによりデータをドリルアップおよびドリルダウンする点で勝っています。データはレベルに保存されます。リレーショナル レポートは、どの場所にもフィールドを配置できるレポートを生成する点で勝っています。

OLAP の問題は、ユーザーがフィールドを使用したくても、キューブ管理者が定義した階層にそれらのフィールドが適合しない場合に生じます。これらのキー フィールドが、他のフィールドがある自然な階層に適合しない場合、どのようにして分析に含めることができるでしょうか。この問題に対処するには、OLAP とリレーショナル ツールの両方を使用するなどして別の方法を用意する必要があります。

UDM は、使用するすべてのフィールドを最上位の属性として扱うことにより、分析とリレーショナル レポートを完全に統合する際の問題を解決します。UDM により、以前はなかった柔軟性が実現しました。UDM は、柔軟な設計を可能にするいくつかの高レベルなコンポーネントで構成されています。これらの機能は次のとおりです。

  • 属性の階層とユーザー定義の階層

  • 関連属性

  • データ ソース ビュー

  • メジャー グループ

  • 分析観点

以下のセクションでは、これらの各機能が Analysis Services 2005 におけるキューブの設計に与える影響について説明します。これは、最善の移行パスを決定するのに役立ちます。

属性の階層化

Analysis Services 2005 では、分析を行うどのフィールドからも属性を作成できます。その後、分析またはリレーショナル レポートで属性を活用できます。さらに、属性を階層に整理して、ナビゲーション パスを作成できます。ナビゲーションの観点からすると、Analysis Services 2000 のディメンションが、属性の階層とユーザー定義の階層に置き換えられます。その結果、ナビゲーションはキューブ共通となり、多くの属性の階層が存在することになります。実際、複雑な大きいキューブには何百もの属性が含まれることがありました。Analysis Services 2000 では、小さいセットのディメンションを使用することが最善の方法でした。これは、次の 2 つの理由によります。

  • メモリを効率的に使用するため。すべてのディメンションは既定で MOLAP ストレージに設定され、各メンバはメモリに読み込まれました。少数の共有ディメンションにより、処理が高速になり、クエリの応答時間が短くなりました。

  • ユーザーにコンテキストを追加するため。6 つまたは 8 つより多いディメンションを概念化し、スライシング、ダイシング、およびドリルアップとドリルダウンを行う際に、ユーザーがコンテキストを維持するのは困難です。

    UDM により、このすべてが変わります。分析で参照する各フィールドは、キューブ内の属性として追加されます (ほとんどのフィールドは自動的に追加されます)。その後、それらをもとに、それらをユーザー定義の階層に配置できます。ユーザー定義の階層は、従来の階層か、多くの子が単一の親にまとめられた強力な階層にすることができます。または、親と子の割合に関係なくさまざまなナビゲーション パスに従って属性を配置可能なナビゲーション階層にすることもできます。この設計方法には、以下の利点があります。

  • データのレポートまたはビューのどの部分にも、任意のフィールドを配置できます。1 つのフィールドを取得して、それを階層の他のフィールドから独立した列および行に配置することを簡単に行うことができます。

  • キューブにより、データ ウェアハウスやデータ ストアを表現する以上のことを行うことができます。Analysis Services 2005 のキューブには、(複数のファクト テーブルから) 多数の属性、ユーザー定義の階層、およびメジャーを含めることができます。このため、キューブをソース データにより近い表現にすることができます。

  • キューブには、複数のディメンション テーブルおよび複数のファクト テーブルからのデータを含めることができます。使用可能な設計の種類には、事実上制限がありません。

  • ナビゲーション パスを、すべてのデータ型に定義できます。作成する階層の種類に制限されることがなくなります。

  • メンバ プロパティと仮想ディメンションは、レポートのためには必要なくなります。Analysis Services 2000 のキューブの管理者は、多くの場合メンバ プロパティを追加した後に仮想ディメンションを追加して、レポートに列を追加できるようにする必要がありました。属性が分析とレポートの基礎となり、ほとんどの場合は属性は 1 つの列を表現するため、これは必要なくなりました。

関連属性

Analysis Services 2005 では、メンバ プロパティの概念が拡大されました。従来のメンバ プロパティは、属性リレーションシップとして使用できるようになりました。メンバ プロパティを検索すると、従来のメンバ プロパティだけでなく、すべての属性リレーションシップも表示されます。属性リレーションシップは、集計を実行可能な場所を決定するために 集計ウィザードにより使用されます。レベルに整理された属性の間には、属性関係が必要になります。たとえば、共通顧客階層には、レベルとして "国"、"地域"、"都道府県"、"市区町村"、および "顧客" を含めることができます。集計を活用すると、"市区町村" に "都道府県" に対する属性リレーションシップが含められます。数式ウィザードでも、計算を実行する最善のメカニズムを決定するために属性リレーションシップが使用されます。

メンバ プロパティは、多くの場合 Analysis Services 2000 でのレポート生成を容易にするために使用されていました。階層の一部ではない列を表示するには、メンバ プロパティを使用して列の値を表示します。メンバ プロパティは、計算されるメンバ、または仮想ディメンションとして表示するか、メンバ プロパティをネイティブに開示するサードパーティ製ツールを使用して表示することができました。UDM を使用すると、関心のあるすべての列を簡単に属性として追加できるため、レポート生成のためにメンバ プロパティを作成する必要がなくなります。これらの属性は、列および行に配置して、分析の際に簡単に使用できるようになります。

メモ   Analysis Services 2005 では、属性関係を使用して、ユーザー定義の階層にまとめるために必要な計算が決定されます。属性関係を使用しない場合、集計は作成されません。強力な階層では、子が属性関係としてその親レベルを持つことになります。属性階層の集計処理は、この関係に依存しています。

データ ソース ビュー

Analysis Services 2005 では、キューブとデータ ソースの間に抽象化するための付加的なレイヤが追加されます。データ ソース ビューにより、キューブをそのデータ ソースから論理的に分離できます。1 つ以上のデータ ソースをデータ ソース ビューに組み合わせて、データの論理的な表現を作成できます。データ ソース ビューは、データ ソースから選択したテーブルか、名前付きクエリのどちらかにすることができます。名前付きクエリは、希望する方法でデータを読み込むために記述する SQL ステートメントです (リレーショナル ビューとあまり変わりませんが、名前付きクエリは DSV に格納されます)。その後、キューブがデータ ソース ビューから構築されます。

データ ソース ビューには以下のような特徴があります。

  • データ ソースから抽象化レイヤが作成されます。

  • 複数のデータ ソースを含めることができます。これは、同じサーバー上の複数のデータベースでも、複数のサーバー上のデータベースでもかまいません。

  • Analysis Services がデータの読み込みに使用するクエリを記述するための名前付きクエリを使用できます。これは、ソースから読み込まれるデータをフィルタ処理、制限、または最適化するために使用できます。

  • データの名前を変更して、実際のデータ ソースとは独立した名前付けレイヤを作成できます。

  • 論理キーを表現して、ファクト テーブルとディメンション テーブルの間の関係を定義できます。

  • 名前付き計算がサポートされます。各名前付き計算には、列の定義の構築に使用される式が格納されます。

  • キューブを構築するための基礎となります。

メジャー グループ

新しいキューブを設計する際に主な考慮事項となることの 1 つは、ユーザーがデータを表示するコンテキストです。キューブは、複数のファクト テーブルから作成できます。これらの各ファクト テーブルには複数のメジャーを含めることができ、各ファクト テーブルには異なるレベルの粒度を設定できます。そのため、キューブには最高で何百もの属性が含まれるだけでなく、異なるファクト テーブルおよび異なる粒度のメジャーも含まれます。

たとえば、"製品"、"店舗"、"顧客"、"日付" という項目 (だれが何を、どこで、いつ購入したか) が含まれる "売上実績" メジャー グループが存在するキューブがあるとします。また、このキューブには、"品種"、"店舗"、"月" という項目 (この先何月に、何を販売し、それをどこで販売するか) が含まれる "予測" メジャー グループもあるとします。さらに、"製品"、"店舗"、"週" という項目 (どれくらい、どこに、いつ在庫していたか) が含まれる "在庫" メジャー グループがあるとします。これらの 3 つのメジャー グループを同じキューブに組み合わせることにより、傾向を表す情報を調べることができます。たとえば、在庫切れの製品があった場合は売上に影響を与え、どのように予測を後押ししたでしょうか。これは、すべてのデータを同じキューブに組み合わせることができるために実現できます。Analysis Services 2000 では、2 つのキューブを作成した後、それらを仮想キューブに組み合わせました。Analysis Services 2005 では、複数のメジャー グループ (ファクト テーブルごとに 1 つ) が含まれる単一のキューブを作成します。

これは、キューブの構築者にとっては非常に柔軟性がありますが、必ずしもエンド ユーザーが必要とするコンテキストを提供するわけではありません。ほとんどのエンド ユーザーは、データ ウェアハウスやデータ ストア設計に詳しくありません。メジャー グループは、さまざまなメジャーを互いに分割して、ユーザーにコンテキストで分割することによって提供しやすくするために作成できます。同様のレベルの粒度が設定されたメジャーは、グループ化して、単一のユニットとして扱う (管理上の観点から) ことができます。既定では、メジャー グループは取得元のファクト テーブルにより整理されます。1 つのファクト テーブルから取得されたメジャーには、同じレベルの粒度が設定されます。1 つのファクト テーブル内のすべてのメジャーは、同じメジャー グループに所属することになります。メジャー グループには、以下のような利点があります。

  • メジャーは複数のファクト テーブルから取得できます。

  • メジャーは、粒度によりグループ化されます。

  • 複数のレベルの粒度を、単一のキューブに含めることができます。

  • 特定のメジャー グループにセキュリティを適用できます。

  • メジャー グループは、1 つ以上のパースペクティブを使用して開示し、エンド ユーザーが理解できるディメンションを使用してグループ化できます。メジャー グループは、エンド ユーザーにコンテキストを提供しやすくします。

分析観点

Analysis Services 2000 では、キューブは多くの場合少ない数のディメンションと、1 つのファクト テーブルから取得された特定数のメジャーで定義されました。複数の粒度のメジャーを追加したり、さまざまなキューブの多くのディメンションを表示したりするため、仮想キューブを作成し、複数のキューブを組み合わせて、さらに大きいものの外観を生成できました。これにより、最終結果を構築することが可能になりました。これは、粒度の問題に対処することを可能にするだけでなく、Analysis Services 2000 でのメモリ消費にも役立ちました。

これは、UDM により変わりました。キューブには何百もの属性階層、ユーザー定義の階層、およぶ複数のメジャー グループ (さまざまなファクト テーブルから取得) を含めることができるようになりました。このため、キューブの設計は非常に柔軟性のあるものになります。残った問題は、ユーザーのコンテキストです。特定の観点で、ユーザーが理解できるようにデータのビューを制限する必要があります。データのビューは、ユーザーがそのプロジェクトの要件に簡単に合わせることができるものにする必要があります。

分析観点は、エンド ユーザーにコンテキストを提供します。 ** 分析観点とは、論理集合としてグループ化する属性、ユーザー定義の階層、アクションおよびメジャーのセットのことです。分析観点より、分析の基礎とユーザーのコンテキストが提供されます。何百もの属性と多数のメジャーが含まれる大きいキューブは、非常に一般的です。ユーザーが、自分の作業を理解しやすくするデータの集合を操作するために、多くの分析観点が作成されます。UDM はキューブの管理者のためのものであり、分析観点はエンド ユーザーのためのものです。分析観点は、セキュリティの実装には使用できません。

ヒント   分析観点は、キューブが Analysis Services 2000 で表示されたのと同じ方法でフロントエンド ツールに開示されます。接続およびナビゲートするキューブのセットを調べるためにユーザーが使用される場合、Analysis Services 2000 のキューブに存在していたのと同じディメンションとメジャーが含まれる分析観点を実装することにより、ユーザーに対して同様の体験を作成できます。たとえば、"ブランド マネージャ" 分析観点、"店長" 分析観点、"地域マネージャ" 分析観点など、データのさまざまな業務用途に基づくさまざまな分析観点が含まれる "売上" 物理キューブを作成できます。各パースペクティブは、実際にはエンド ユーザーに対してキューブとして開示されますが (大きくなるほど、複雑なベース キューブになります)、ディメンション、計算、メジャー グループ、および他の要素は特定の業務用途に合わせて調整されます。

設計上の問題のまとめ

Analysis Services 2005 のキューブには、多数の属性、ユーザー定義の階層、およびメジャーを含めることができます。UDM は、OLAP 環境の最も良い点と、リレーショナル レポート環境の最も良い点を組み合わせて、キューブ設計における無制限の機会を実現します。キューブ設計の最終結果には、ユーザーが必要とするよりも多くのものが包含される可能性があります。メジャー グループとパースペクティブを使用して、ユーザーにコンテキストを提供できます。ほとんどの場合、分析観点はユーザーの操作環境の基礎となります。

移行ツール

Analysis Services 2005 には、移行プロセスで役立つツールが用意されています。既に Analysis Services 2000 がインストールされているコンピュータに Analysis Services 2005 をインストールし、既定のインスタンスのインストールを選択すると、インストール中に移行ウィザードを実行するかどうかを確認するメッセージが表示されます。インストール時にウィザードを使用しないことを選択した場合、後でスタンドアロン ツールとして使用できます。

移行ウィザードを使用すると、Analysis Services 2000 のキューブを新しいバージョンに移行するか、XMLA (XML for Analysis) スクリプトを作成して、後で移行を実行することができます。ウィザードは高速で効率的です。最終結果が必要に合致するかどうかを判断する必要があります。場合によって、移行ウィザードは開始地点として適していたり、再設計が適していたりします。キューブを再設計する場合でも、移行ウィザードを実行することをお勧めします。少なくとも、ウィザードがオブジェクトを変換する方法を知ることは、とても役に立ち、多くのことを学習できます。最終的にその推奨事項を使用せずに、通常の設計ウィザードを使用してスキーマを再設計することを決定できますが、移行ウィザードの最終的な決定に同意しない場合でも、移行ウィザードが同様の処理をどのように実行するかを知ることができます。

Analysis Services 2005 には、2 つの組み込み移行ツールが用意されています。1 つ目のツールは、Analysis Services 2005 のインストール時の移行オプションです。

2 つ目のツールは、SQL Server 2005 プログラム グループの主なツールの 1 つとして、スタンドアロン プロセスとして起動される移行ウィザードです。

移行ウィザード

移行ウィザードは、Analysis Services 2000 に存在していたキューブを複製する際に真価を発揮します。ウィザードの目標は、Analysis Services 2005 の最良のキューブを作成することではありません。このことを考慮に入れると、ウィザードが選択を行う理由を理解しやすくなります。ウィザードを完了した後、Analysis Services 2005 の機能をより十分に活用するために必要な追加手順を決定する必要があります。

ウィザードでは、移行する OLAP データベースを選択する確認メッセージが表示されます。適切な OLAP データベースを選択したら、Analysis Services 2005 に直接移行するかどうか、または XMLA スクリプトを生成するかどうかを決定する必要があります。スクリプトは、後で SQL Server Management Studio から実行できます。

移行ウィザードを実行するには

  1. [SQL Server 2005] プログラム グループで、[移行ウィザード] を開きます。移行ウィザードは、Analysis Services ツールの 1 つです。図 1 に示すようなウィザードが表示されます。
    Cc917610.asmigrtn01(ja-jp,TechNet.10).gif

    図 1 : Analysis Services 2005 移行ウィザードを使用した Analysis Services 2000 のキューブの移行

    拡大表示する

  2. [次へ] をクリックして、ウィザードの [移行元と移行先の指定] 画面を表示します。

  3. 図 2に示すように、データの移行元と移行先を指定します。データの移行元には、Analysis Services 2000 インスタンスを指定してください。移行先には、新しい Analysis Services 2005 インスタンスを指定してください。移行先の代わりにスクリプト ファイルを選択できます。スクリプト ファイルを選択すると、後で実行してキューブを生成可能な XMLA スクリプトがウィザードにより生成されます。
    Cc917610.asmigrtn02(ja-jp,TechNet.10).gif

    図 2 : 移行の基礎として、データの移行元と移行先を指定する必要がある

    拡大表示する

  4. 移行元と移行先を指定したら、[次へ] をクリックします。データの移行元からメタデータが読み取られた後、[移行するデータベースの選択] 画面が表示されます。

  5. 移行するデータベースを選択します。既定では、移行先のデータベース名は自動的に作成されます。ウィザードは、同じ名前のデータベースの作成を試みます。同じ名前のデータベースが既に存在する場合、データベース名の終わりに 1 から始まる増分値を追加して名前が生成されます。名前を指定するには、[移行先データベース] セルをクリックして、図 3 に示すように名前を指定します。
    Cc917610.asmigrtn03(ja-jp,TechNet.10).gif

    図 3 : 移行先データベースの名前を Analysis Services 2005 で使用する名前に変更できる

    拡大表示する

  6. 移行するデータベースと移行先のデータベースの名前を指定したら、[次へ] をクリックします。

  7. ウィザードの [データベースを検証しています] 画面が起動します。この部分の実行には少し時間がかかります (データ ソース内のメタデータの量によります)。オブジェクトが検証される際、問題が存在する可能性のあるデータの警告メッセージとエラー メッセージが表示されます。ウィザードによりデータに加えられた変更内容に関する詳細を参照できます。たとえば、ディメンションの名前が変更された場合、名前が変更されたことを示す警告メッセージが表示されます。このホワイト ペーパーの後方では、移行ウィザードを使用する際に発生する可能性のある問題の一部について概要を説明します。

    [ログの表示] および [ログの保存] 機能を使用すると、詳細を表示およびフィルタ処理したり、後で見直すためにそれらをファイルに保存したりすることができます。オブジェクトの詳細の見直しが完了したら、[次へ] をクリックします。

  8. [データベースを移行しています] 画面が表示されます。ウィザードにより移行が実行され、メタデータが生成されます。ただし、データは転送されません。新しいキューブを処理して、データを追加します。

  9. データベースを移行したら、[次へ] をクリックしてウィザードを完了します。

    メモ   OLAP データベースが移行される際、キューブ メタデータが Analysis Services 2005 に移行されます。移行後、キューブを処理する必要があります。その後、データ ソースからキューブにデータが読み込まれ、データを参照できるようになります。

ウィザードでは、以下の項目は移行されません。

  • リモート パーティション

  • リンク キューブ

  • ドリル スルー オプション

ウィザードでは、移行中にいくつかの選択が行われ、古い機能が新しい機能にマップされます。以下の点に注意してください。

  • メンバ プロパティは、属性リレーションシップに移行されます。属性関係という用語は、主に Business Intelligence Development Studio で使用されます。メンバ プロパティの API を検索した場合、すべての属性リレーションシップが返されます。元のメンバ プロパティのセットに加えて、階層内の各レベルには、その親レベルの追加の属性リレーションシップが存在します。属性リレーションシップは、データ ポイントの間に関係を作成する集計エンジンにより使用されます。これらの関係は、ロールアップの計算に必要です。これらの関連リレーションシップは削除しないでください。他のメンバ プロパティを追加して特定のレポート要件に対処した場合、列も属性ディメンションとして定義する必要があるため、レポート関連リレーションシップを削除できます。

  • データ ソース ビューでは、いくつかの名前付き計算が自動的に作成されます。これらの名前付き計算には、列の構築に使用される式が格納されます。これらには、各テーブル内で column1 から始まる columnx という名前が付けられます。この状況は、Analysis Services 2000 内の式に基づくレベルのメンバ名またはメンバ ID がある場合に発生します。Analysis Services 2000 では、メンバ名およびメンバ ID のプロパティ ボックスは、連結などの問題の処理に使用される SQL タイプのステートメントに使用できます。これらは、式として格納されるようになりました。たとえば、"食料品店" キューブでは、"顧客" ディメンション内にこの例があるとします。移行時に、Column1 という名前の "顧客" テーブル (データ ソース ビューにあり、属性としても追加されます) 内の新しい列に注意してください。プロパティを見直した場合、ソースは "名" 列と "姓" 列の連結になっています。

  • データ ソース テーブルのほとんどすべての列が、属性ディメンションとして追加されます。除外された列は、timestamp、uniqueidentifier、および table など、Analysis Service が関心のないデータ型として除外するデータ型が含まれる列です。数字、日付、文字ベースのすべての列は、追加される属性です。

  • 仮想キューブは、キューブとして移行されます。メジャー グループは、キューブに追加されません。それらは、ベース キューブを再度ポイントするリンク メジャー グループとして移行されます。元の仮想キューブにより参照されるベース キューブごとに、ベースを再度ポイントするメジャー キューブが存在します。

  • 仮想ディメンションは、ディメンションのマージのルールとなります。仮想ディメンションは、メンバ プロパティに基づいており、1 つ以上のレベルが含まれていました。仮想ディメンションに 1 つのレベルがあった場合、基になっていたディメンションにマージされます。仮想ディメンションに複数のレベルがあった場合、実際のディメンションに変換されます。たとえば、Foodmart データベースには、3 つの仮想ディメンションがあります。これを表すため、"地域" (複数のレベルがあります) と "店舗サイズ (平方メートル)" (1 つのレベルがあります) を調べます。移行時に、"地域" が新しいディメンションとして作成されます。"店舗サイズ (平方メートル)" は、"店舗" ディメンションにマージされます。"平方メートル" が、そのディメンションに属性として追加されます。

  • アクションごとに、コマンドとして移行されることを示すメッセージが表示されます。Analysis Services 2005 のユーザー インターフェイスでは、それらが引き続きアクションとして参照されていることがわかります。

  • データ ソース ビューは自動的に作成され、テーブルからの列のセットを表す名前付きクエリが作成されます。作成されるデータ ソース ビューには、Analysis Services 2000 OLAP データベースで使用されたファクト テーブルとディメンション テーブルがすべて含められます。

  • パーティションは移行され、それらを自動的に作成するために使用されるスクリプトが XMLA スクリプトとして移行されます。パーティションは、パーティションを処理するために Analysis Service 2000 により発行されるのと同じ SQL ステートメントを使用することで、クエリ バインドを使用します。

  • 役割は、キューブおよびディメンション セキュリティと共に移行されます。Analysis Services 2005 では、さらに多くの種類のセキュリティ実装が可能です。新しいセキュリティ オプションのいずれかを実装する場合は、移行後に行う必要があります。

  • 複数階層ディメンションは移行されますが、常に希望する名前が付けられるわけではありません。たとえば、Analysis Services 2000 の Time.Fiscal および Time.Calendar ディメンションは、ほとんどの場合 Time および Time 1 に移行されます。Time という名前の階層が既にある場合、Time TimeDim および TimeDim 1 に移行されます。これは、ややこしくなる可能性があります。これは希望する結果ではないかもしれませんが、ディメンションの名前は非常に簡単に変更できます。

移行ウィザードが完了した後、SQL Server Business Intelligence Development Studio に移動して結果を見直し、必要に応じて変更を加えることができます。移行後に実行する作業には以下のようなものがあります。

  • 名前付け規則に従うように、ディメンションの名前を変更します。

  • すべてのユーザー定義の階層が、適切なディメンションにあるかどうかを判断します。場合によっては、移行ウィザードにより必要以上のディメンションが作成されることがあります。ユーザー定義の階層のいくつかを統合したり、余分なディメンションを削除したりすることができます。これにより、新しいディメンションの名前が既存の MDX クエリに影響を与えて、それらが失敗することのないようにします。

  • 名前付き計算に名前を付けます。Columnx は、データ ソース ビューに追加される各名前付き計算に適用されます。これらに、列に適した名前を付けることができます。

  • ドリルスルー アクションとしてドリルスルー設定を設定します。ドリルスルーは、アクションとして実行されるようになったため、設定が必要です。

Business Intelligence Development Studio でディメンションの名前を変更するには、次の手順を実行します。

新しいキューブを表示して、ディメンションの名前を変更するには

  1. [SQL Server 2005] プログラム グループで、[SQL Server Business Intelligence Development Studio] を開きます。

  2. ツールを開くと、多くの場合 Visual Studio のスタート ページが開始されます。

  3. キューブを開くには、[ファイル] メニューの [開く] をクリックします。図 4に示すように、[Analysis Services データベース] をクリックします。
    Cc917610.asmigrtn04(ja-jp,TechNet.10).gif

    図 4 : Business Intelligence Development Studio から既存の Analysis Services データベースを開くことができる

    拡大表示する

  1. [新しいデータベースを作成する] または [既存のデータベースに接続する] のどちらかを選択するダイアログが表示されます。[既存のデータベースに接続する] を選択し、インスタンスとデータベースの情報を指定します。

  2. ソリューション エクスプローラに、データベースに加えて、生成されたキューブとディメンションの一覧が表示されます。

  3. ディメンションの名前を変更するには、ディメンションを右クリックし、[名前の変更] をクリックします。その後、図 5 に示すように新しい名前を入力できます。

    図 1 移行ウィザード

    図 5 : Analysis Services 2005 では、オブジェクトの名前を簡単に変更できます。

移行ウィザードには Analysis Services 2000 と同等の機能が備わっているわけではないため、多くの新機能が実装されません。これらの機能には、Analysis Services 管理ツールのタブおよびプロパティ ボックスでアクセスします。実装されない高レベルな機能には以下のようなものがあります。ただし、これらに限定されるわけではありません。

  • 主要業績評価指標 (KPI)

  • 変換

  • 多対多ディメンション

  • 多様ディメンション

  • 準加法メジャー

プロジェクト REAL での移行

プロジェクト REAL で使用された OLAP のデータベースとキューブは、再設計から構築されました。Analysis Services 2005 のウィザードは、キューブ設計の基礎として使用されました。別の処理として、結果を比較する目的で、Barnes and Noble Booksellers のサンプル データ セットに対して移行ウィザードが使用されました。データは、共有ディメンションを広範囲で活用し、共有ディメンションの多くは仮想ディメンションでした。移行ウィザードを実行した後、以下の所見が得られました。

  • 各仮想ディメンションは、アイテム テーブルからのメンバ プロパティに基づいていました。移行時に、それぞれがディメンションにマージ (または名前変更) されました。各仮想ディメンションは、項目ディメンションにユーザー定義の階層として追加されました。それらは、それぞれ既定で表示され、移行前と同じ方法で参照できます。これにより、新しいプロバイダを使用するだけで、以前のクエリが引き続き機能する可能性が増します。

  • Analysis Services 2000 で使用されていた 1 つのデータ ソースから、1 つのデータ ソース ビューが作成されました。データ ソース ビューは、既存のデータ ソースにより使用されていたすべてのテーブルを表していました。

  • Analysis Services 2005 のキューブには、仮想キューブだけが移行されました。各ベース キューブは、"店舗売上"、"店舗在庫"、および "配送センターの在庫" のそれぞれについて、個別のメジャー グループとして移行されました。

  • 役割およびデータ セキュリティなど、すべてのセキュリティ情報は正しく移行されました。

  • Time.Fiscal および Time.Calendar と名前が変更された Time ディメンションは例外として (複数階層に関する説明で前述のとおりです)、ディメンションの名前付けに競合はありませんでした。そのため、Analysis Services 2005 での名前は Analysis Services 2000 での名前と同じになりました。

  • 全体として、処理は高速かつシームレスで、Analysis Services 2000 で存在していたのと同じキューブが Analysis Services 2005 に正常に作成されました。

  • 在庫データでは、新しい準加法メジャーを使用して、すべての在庫メジャーおよび注文済みメジャーに LastNonEmptyChild を設定しました。これは、Analysis Services 2005 の新機能であるため、長期間準加法ロールアップに使用されていた複雑な計算を削除しました。

移行と再設計

移行ウィザードは、Analysis Services 2005 でどういったキューブができるかを確認する最も初歩的な方法です。ただし、移行ウィザードで作成されるキューブは、Analysis Services 2000 で構築したキューブを複製するためのものです。これは、希望する結果でない可能性があります。場合によっては、ウィザードを使用するだけで、必要な機能を移行して、追加できます。それ以外の場合では、新しいアーキテクチャでキューブを再設計することをお勧めします。以下の一連の質問は、移行ウィザードが開始点として適切か、または再設計すべきかを判断するのに役立ちます。

  • ディメンションおよびメジャー内に制限されている小さいキューブが多数ありますか。Analysis Services 2000 のキューブ管理者は、一般に小さいキューブを多数構築します。ウィザードを使用する場合、これらの各キューブは Analysis Services 2005 では個々のキューブに移行されます。Analysis Services 2005 では、メモリ使用量、単一のファクト テーブル メジャー、独立したカウント、およびメンバ プロパティなどの問題により制限されないため、小さいキューブを多くしない方がよい場合があります。ユーザー コンテキストを提供するパースペクティブが含まれる大きいキューブが少数あったほうが、わかりやすい場合があります。ユーザー コンテキストを提供する多数のキューブを使用していた場合、Analysis Services 2005 でキューブを再設計したほうがよい可能性があります。

  • レポート生成の目的でディメンションに追加した多数のメンバ プロパティがありますか。列は、レポートおよびナビゲーションのレイアウトに役立つ属性ディメンションとして追加されるようになりました。すべてのメンバ プロパティを、関連属性として持つ必要はありません。これにより、移行後に手動で多数のクリーンアップを行う必要が生じることがあるため、キューブを再設計した方がよい可能性があります。

  • キューブの多くにプライベート ディメンションを使用していましたか。プライベート ディメンションは、ディメンションとして移行されます。多数のプライベート ディメンションを使用し、さまざまなキューブに同じ種類のディメンションを使用していた場合、システムによりこれらのディメンションが Analysis Services 2005 のディメンションとして複製されます。これにより、ディメンション名のクリーンアップと、キューブの編集が必要になります。この場合は、再設計を検討することもできます。

  • メジャーとして使用可能になった計算されるメンバが多数ありますか。メジャーには、使用可能な多くの集計関数が含まれるようになりました。集計関数の一覧は、元の一覧の Sum、Count、Distinct Count、Min、および Max から拡張され、Average of Children、None、First Child、Last Child、First Non Empty Child、および Last Non Empty Child が追加されました。メジャーとして使用可能になった計算されるメンバを作成した場合、再設計するか、それとも移行後にクリーンアップを行う範囲を評価するかを検討できます。

  • ETL プロセスを大幅に変更したり、リレーショナル データベースにビューを作成してキューブに 1 つのデータ ソースを作成したりしましたか。データが複数のデータ ソースから自然に取得されるようにする場合は、キューブを再設計し、データ ソース ビューで名前付きクエリを構築してデータを読み込んだ方がよい可能性があります。

  • 独立したカウントを回避する必要がありますか。Analysis Services 2000 では、独立したカウントには多くの注意が必要でした。キューブごとに 1 つのカウントに制限されており、独立したカウントをそれ自身のキューブに配置し、仮想キューブ内の他のメジャーと組み合わせることが推奨されていました。この制限は存在しなくなり、回避策を実行する必要はなくなりました。

  • 多数の仮想ディメンションと仮想キューブを使用していますか。これらは、実際のディメンションと実際のキューブに移行されます。仮想ディメンションを使用している場合、属性ディメンションとして列を簡単に作成できるため、これは必要なものではない可能性があります。仮想キューブを使用している場合、データは重複されたデータとなったため、おそらく仮想キューブまたはベース キューブのどちらかをクリーンアップする必要があります。クリーンアップが広範囲に及ぶ場合、キューブを再設計した方がよい可能性があります。

  • キューブの設計を気に入っていても、Analysis Services 2005 に用意されている新機能を使用したいですか。キューブに満足していて、Analysis Services 2005 の新しい設計要件でも機能すると感じる場合は、移行ウィザードを使用してデータを新しいバージョンに移動してください。その後、必要な新機能を追加できます。新しい機能の総合的な一覧については、製品のマニュアルを参照してください。

まとめ

統合ディメンション モデル (UDM) を使用すると、リレーショナル レポートと OLAP レポートを結び合わせることができます。Analysis Services 2005 にある新しい設計の選択肢により、設計の無限の可能性が開かれ、エンド ユーザーの分析およびレポート環境が大幅に強化されます。移行ウィザードは、その方針に沿って始めることができる優れたツールです。移行ウィザードを使用すると、OLAP データベースをとても簡単に新しいバージョンに移植できるため、新機能を活用し始めることができます。移行ウィザードは、Analysis Services 2005 で現在のキューブを再現する際に真価を発揮します。最終的には、移行ウィザードを使用するより最初から始めた方がよいほど設計の変更が大きいかどうかを判断できます。現在存在しているものと、Analysis Services 2005 での変更の程度を評価することにより、再設計するか、ウィザードを使用するかを最も適切に決定できます。

詳細情報
https://www.microsoft.com/japan/sql/