Netezza 移行の視覚化とレポート

この記事は、Netezza から Azure Synapse Analytics に移行する方法に関するガイダンスを提供する 7 つのパートから成るシリーズのパート 4 です。 この記事では、視覚化とレポートのベスト プラクティスを重点的に説明します。

Microsoft とサード パーティの BI ツールを使用して Azure Synapse Analytics にアクセスする

組織では、さまざまなビジネス インテリジェンス (BI) ツールとアプリケーションを使用して、データ ウェアハウスとデータ マートにアクセスします。 BI 製品の例をいくつか次に示します。

• Power BI などの Microsoft BI ツール。

• Microsoft Excel スプレッドシートなどの Office アプリケーション。

• さまざまなベンダーのサードパーティ BI ツール。

• BI ツール機能が埋め込まれたカスタム分析アプリケーション。

• BI プラットフォーム上でクエリやレポートを実行することでオンデマンドの BI をサポートし、それによってデータ ウェアハウスやデータ マートのデータに対してクエリを実行する運用アプリケーション。

• Azure Synapse Spark Notebook、Azure Machine Learning、RStudio、Jupyter Notebook などの対話型データ サイエンス開発ツール。

データ ウェアハウスの移行の一環として視覚化とレポートを移行する場合は、BI 製品によって生成された既存のすべてのクエリ、レポート、ダッシュボードを新しい環境で実行する必要があります。 Azure Synapse で BI 製品によって生成される結果は、レガシ データ ウェアハウス環境と同じでなければなりません。

移行後に一致した結果を得るには、データ ウェアハウスのスキーマとデータを Azure Synapse に移行した後に、すべての BI ツールとアプリケーションの依存関係が機能する必要があります。 依存関係には、アクセスやセキュリティなど、目に見えにくい側面が含まれています。 アクセスとセキュリティに対処する際には、必ず以下を移行してください。

• 認証。これにより、Azure Synapse 上のデータ ウェアハウスおよびデータ マート データベースにユーザーがサインインできます。

• すべてのユーザーを Azure Synapse に。

• すべてのユーザー グループを Azure Synapse に。

• すべてのロールを Azure Synapse に。

• アクセス制御を管理するすべての承認特権を Azure Synapse に。

• 移行前の既存のデータ ウェアハウスに存在していたものを反映するユーザー、ロール、特権の割り当て。 次に例を示します。

  • ロールに割り当てられたデータベース オブジェクト特権
  • ユーザー グループに割り当てられたロール
  • ユーザー グループやロールに割り当てられたユーザー

アクセスとセキュリティは、移行されたシステムでのデータ アクセスに関する重要な考慮事項であり、「Netezza 移行のセキュリティ、アクセス、操作」に詳細な説明があります。

必要なすべてのデータを移行することで、レガシ環境のデータに対してクエリを実行するレポートとダッシュボードによって Azure Synapse で同じ結果が生成されるようにします。

ビジネス ユーザーは、Azure Synapse に移行されたシステムで信頼を損なう想定外の事態が起こらない、シームレスな移行を期待します。 的確なコミュニケーションをとることで、ユーザーが抱えている可能性のある不安を和らげるように努めてください。 ユーザーは次のことを期待しています。

• クエリで直接参照される際に、テーブル構造が変わらないこと。

• クエリで直接参照される際に、テーブル名と列名が変わらないこと。 たとえば、集計レポートの生成時に、BI ツールの列で定義されている計算フィールドがエラーになってはなりません。

• 履歴分析がそのまま同じであること。

• 可能であれば、データ型が変わらないこと。

• クエリの動作が変わらないこと。

• ODBC/JDBC ドライバーがテストされ、クエリの動作が変わらないことが確認済みであること。

BI ツールによって基になるデータ ウェアハウスまたはデータ マート データベース内のビューに対するクエリが実行される場合、移行後もそれらのビューは機能しますか? Azure Synapse 内に同等の機能のない、レガシ データ ウェアハウス DBMS に固有の独自の SQL 拡張機能がある場合、一部のビューが機能しないことがあります。 その場合、それらの非互換機能を把握し、それらを解決する方法を見つける必要があります。

DBMS プラットフォーム間での NULL 値の動作やデータ型の変化といったその他の問題は、テストし、計算結果にわずかな違いも存在しないことを確認する必要があります。 これらの問題を最小限に抑え、必要なすべての手順を行って、ビジネス ユーザーに影響が及ばないようにしてください。 レガシ データ ウェアハウス環境によっては、サードパーティのツールがレガシ環境と新しい環境の違いを隠し、BI ツールとアプリケーションを変更せずに実行するのに役立つ場合があります。

テストは、視覚化とレポートの移行に不可欠です。 両方の環境でテストを実行および再実行するには、テスト スイートと合意されたテスト データが必要です。 テスト ハーネスも有用であり、このガイドでいくつか紹介されています。 また、移行のテストの側面にビジネス ユーザーを招き入れることで、信頼感を高め、それらのユーザーがプロジェクトに参加し、携わるようにすることが重要です。

たとえば、Power BI への移行など、BI ツールの切り替えを検討している場合があります。 このような変更を、スキーマ、データ、ETL 処理などの移行と同時に行いたいと考えています。 しかし、リスクを最小限に抑えるには、最初に Azure Synapse に移行し、すべてを動作させてから、さらなるモダン化を行うのがよいでしょう。

既存の BI ツールがオンプレミスで実行されている場合は、それらをファイアウォール経由で Azure Synapse に接続して、両方の環境に対して比較を実行できることを確認します。 または、既存の BI ツールのベンダーが Azure で製品を提供している場合は、そちらで試すこともできます。 同じことが、オンプレミスで実行されているアプリケーションのうち、BI が埋め込まれている、または BI サーバーをオンデマンドで呼び出す (たとえば、XML または JSON データを含む "ヘッドレス レポート" を要求するなどして) アプリケーションにも当てはまります。

ここでは考えるべき点が多くあるので、詳しく見ていきます。

データ仮想化を使用して BI ツールとレポートでの移行の影響を最小限に抑える

移行中に、ビジネス要求を開く、欠落しているデータを追加する、新機能を実装するといった長期的な要件を満たしたいと考える場合があります。 ただし、このような変更は、特にその変更にデータ モデルの構造変更が含まれている場合、データ ウェアハウスへの BI ツールのアクセスに影響を与える可能性があります。 アジャイル データ モデリング手法を採用する場合、または構造変更を実装する場合は、移行 "後" に行います。

スキーマの変更やその他の構造変更が BI ツールに及ぼす影響を最小限に抑える方法の 1 つが、BI ツールと、データ ウェアハウスおよびデータ マートとの間にデータ仮想化を導入することです。 次の図は、データ仮想化によって移行をユーザーから隠す方法を示しています。

データ仮想化により、セルフサービスの BI ツールを使用するビジネス ユーザーと、移行対象の基になるデータ ウェアハウスとデータ マートの物理スキーマとの間の依存関係が切り離されます。

データ仮想化を使用すると、Azure Synapse への移行の間に行われた (たとえば、パフォーマンス最適化のための) スキーマの変更を、ビジネス ユーザーから見えないようにできます。ビジネス ユーザーがアクセスできるのはデータ仮想化レイヤーの仮想テーブルのみであるためです。 また、構造を変更する場合、更新する必要があるのは、データ ウェアハウスまたはデータ マートと仮想テーブルとの間のマッピングのみです。 データ仮想化を使用すると、ユーザーは構造変更に気付かないままになります。 Microsoft パートナーがデータ仮想化ソフトウェアを提供しています。

最初に移行する優先度の高いレポートを特定する

既存のレポートとダッシュボードを Azure Synapse に移行する際に問うべき重要な問題は、どのレポートを最初に移行するかということです。 その決定を促す要因として、次のようなものが考えられます。

• 使用

• 事業価値

• 移行のしやすさ

• データ移行戦略

以下のセクションで、これらの要因について説明します。

何を決定する場合でもビジネス ユーザーが関与する必要があります。ビジネス ユーザーがレポート、ダッシュボード、その他の視覚化を生成し、それらの項目から得た分析情報に基づいてビジネス上の意思決定を行うためです。 以下ができれば、全員にメリットがもたらされます。

• レポートとダッシュボードをシームレスに移行する。
• 最小限の労力でレポートとダッシュボードを移行する。
• BI ツールがレガシ データ ウェアハウス システムではなく Azure Synapse をポイントするようにし、既存のものと同じレポート、ダッシュボード、その他の視覚化を取得する。

使用状況に基づいてレポートを移行する

使用状況は、多くの場合、事業価値の指標になります。 使用されないレポートとダッシュボードはビジネス上の決定に影響せず、現在の価値も提供しないことは明らかです。 使用されていないレポートとダッシュボードを確認する方法がない場合は、使用状況の統計情報を提供するいくつかの BI ツールのうち、いずれかを使用できます。

レガシ データ ウェアハウスが何年も稼働している場合は、何百、何千というレポートが存在する可能性があります。 レポートとダッシュボードのインベントリを集め、そのビジネス上の目的と使用状況の統計情報を特定することが重要です。

使用されていないレポートについては、移行作業を減らすために破棄するかどうかを決定します。 使用されていないレポートを破棄するかどうかを決定する際の鍵となる質問は、レポートが使用されていない理由が、人々がそのレポートの存在を知らない、事業価値がない、別のレポートが優先されている、のどれであるかということです。

事業価値に基づいてレポートを移行する

使用状況だけでは、常に事業価値を示す適切な指標になるとは限りません。 レポートの分析情報が事業価値にどの程度寄与するかを検討してください。 これを行う方法の 1 つは、レポートに依存するすべてのビジネス上の意思決定の収益性と依存の程度を評価することです。 ただし、ほとんどの組織では、その情報が利用できるようになっていません。

事業価値を評価するもう 1 つの方法は、レポートがビジネス戦略に沿っているか確認することです。 経営陣が設定したビジネス戦略には、通常、戦略的な事業目標 (SBO)、主要業績評価指標 (KPI)、達成すべき KPI 目標、その達成に責任を持つ者が明示されています。 不正行為の削減、顧客エンゲージメントの向上、ビジネス運用の最適化など、レポートが寄与する SBO 別にレポートを分類できます。 その後、優先度の高い目標に関連付けられているレポートとダッシュボードに、移行対象として優先度付けすることができます。 このようにして、初期移行によって戦略的な領域での事業価値がもたらされます。

事業価値を評価するもう 1 つの方法は、レポートとダッシュボードを運用時、戦術的、または戦略的として分類し、それらが使用されるビジネス レベルを特定することです。 SBO では、これらすべてのレベルで寄与することが求められます。 どのレポートとダッシュボードが、どのようなレベルで使用され、どのような目標に関連付けられているかを把握することで、初期移行の際に、優先度の高い事業価値に重点を置くことができます。 次の "ビジネス戦略目標" の表を利用して、レポートとダッシュボードを評価できます。

Azure Data Catalog などのメタデータ検出ツールを使用すると、ビジネス ユーザーは、データ ソースにタグを付けて評価し、それらのデータ ソースのメタデータをエンリッチして検出と分類に役立てることができます。 レポートまたはダッシュボードのメタデータを使用すると、そのビジネス価値を理解するのに役立ちます。 このようなツールがない場合、移行するかどうかにかかわらず、レポートとダッシュボードが事業価値にどのように寄与しているかを把握するには時間がかかる可能性があります。

データ移行戦略に基づいてレポートを移行する

データ マートの移行を優先する移行戦略の場合、データ マートの移行順序が、どのレポートとダッシュボードを最初に移行するかに影響します。 事業価値に基づく戦略の場合、データ マートを Azure Synapse に移行する順序にビジネスの優先順位が反映されます。 メタデータ検出ツールは、どのデータ マート テーブルがどのレポートのデータを提供するかを示すことで、戦略の実装に役立ちます。

レポートと視覚化に影響を与える可能性がある移行の非互換性の問題

BI ツールでは、レポート、ダッシュボード、その他の視覚化は、データ ウェアハウスまたはデータ マート内の物理テーブルやビューにアクセスする SQL クエリを発行して生成されます。 レガシ データ ウェアハウスを Azure Synapse に移行する場合、いくつかの要因がレポート、ダッシュボード、その他の視覚化を簡単に移行できるかどうかに影響します。 それらの要因には次のものがあります。

• 環境間のスキーマの非互換性。

• 環境間の SQL の非互換性。

スキーマの非互換性

レポート、ダッシュボード、その他の視覚化のデータを提供するデータ ウェアハウス テーブルまたはデータ マート テーブルの、移行中におけるスキーマの非互換性は、次のようになります。

• Azure Synapse に同等のものがない、レガシ データ ウェアハウス DBMS での標準以外のテーブル型。

• Azure Synapse に同等のものがない、レガシ データ ウェアハウス DBMS でのデータ型。

ほとんどの場合、これらの非互換性には対応策があります。 たとえば、サポートされていないテーブル型のデータは、適切なデータ型を持つ標準テーブルに移行し、日付または時刻列でインデックスを付けるかパーティション分割できます。 同様に、サポートされていないデータ型を別の種類の列で表現し、Azure Synapse で計算を実行して同様の結果を得ることができる場合があります。

スキーマの非互換性による影響を受けるレポートを特定するには、レガシ データ ウェアハウスのシステム カタログに対してクエリを実行して、サポートされていないデータ型を持つテーブルを識別します。 その後に、BI ツールのメタデータを使用して、それらのテーブルのデータにアクセスするレポートを特定できます。 オブジェクトの種類の非互換性を特定する方法の詳細については、「サポートされていない Netezza データベース オブジェクトの種類」を参照してください。

多くの BI ツールでは一般性の低いデータ型がサポートされていないため、スキーマの非互換性がレポート、ダッシュボード、その他の視覚化に及ぼす影響は想定より少ないと考えられます。 その結果、レガシ データ ウェアハウスには、サポートされていないデータ型をより一般的な型に CAST したビューがすでに存在する可能性があります。

SQL の非互換性

移行時に、SQL の非互換性は、次のようなアプリケーションまたはツールのレポート、ダッシュボード、またはその他の視覚化に影響を与える可能性があります。

• Azure Synapse に同等のものがない、独自の SQL 関数を含むレガシ データ ウェアハウス DBMS のビューにアクセスする。

• Azure Synapse に同等のものがない、レガシ環境の SQL 言語に固有である独自の SQL 関数を含む SQL クエリを発行する。

SQL の非互換性がレポート ポートフォリオに与える影響を評価する

お使いのレポート ポートフォリオには、埋め込みクエリ サービス、レポート、ダッシュボード、その他の視覚化が含まれている場合があります。 これらの項目に関連付けられたドキュメントは、Azure Synapse へのレポート ポートフォリオの移行時における SQL の非互換性の影響を評価するために利用しないでください。 より正確な方法で、SQL の非互換性の影響を評価する必要があります。

EXPLAIN ステートメントを使用して SQL の非互換性を見つける

_v_qryhist システム テーブルにクエリを実行して、レガシ Netezza データ ウェアハウスの最近の SQL アクティビティを表示することで、SQL の非互換性を見つけることができます。 詳細については、「Query history table (クエリ履歴テーブル)」を参照してください。 スクリプトを使用して、代表的な SQL ステートメント セットをファイルに抽出します。 次に、各 SQL ステートメントの先頭に EXPLAIN ステートメントを付け、Azure Synapse でそれらの EXPLAIN ステートメントを実行します。 サポートされていない独自の SQL 拡張機能を含む SQL ステートメントは、EXPLAIN ステートメントの実行時に Azure Synapse によって拒否されます。 この方法では、SQL の非互換性の程度を評価できます。

レガシ データ ウェアハウス DBMS からのメタデータは、非互換ビューの特定にも役に立ちます。 前と同様に、代表的な SQL ステートメント セットをキャプチャし、各 SQL ステートメントの先頭に EXPLAIN ステートメントを付け、Azure Synapse でそれらの EXPLAIN ステートメントを実行して、非互換の SQL を持つビューを特定します。

Azure Synapse Analytics へのレポートとダッシュボードの移行をテストする

データ ウェアハウスの移行の重要な要素は、Azure Synapse でレポートとダッシュボードをテストし、移行が正常に行われたか確認することです。 一連のテストと、成功したことを確認するために実行する各テストで求められる結果のセットを定義します。 既存および移行されたデータ ウェアハウス システムの間でレポートとダッシュボードをテストして比較し、以下を行います。

• 移行中に行われたスキーマの変更が、レポートの実行機能、レポートの結果、または対応するレポートの視覚化に影響を与えたかどうかを特定します。 スキーマの変更の例として、非互換のデータ型を、Azure Synapse でサポートされている同等のデータ型にマップした場合があります。

• すべてのユーザーが移行されていることを確認します。

• すべてのロールが移行され、ユーザーがそれらのロールに割り当てられていることを確認します。

• アクセス制御リスト (ACL) が移行されていることを確認するため、すべてのデータ アクセス セキュリティ特権が移行されていることを確認します。

• すべての既知のクエリ、レポート、ダッシュボードの結果が一貫していることを確認します。

• データと ETL の移行が完了し、エラーがないことを確認します。

• データのプライバシーが確保されていることを確認します。

• パフォーマンスとスケーラビリティをテストします。

• 分析機能をテストします。

ユーザー、ユーザー グループ、ロール、特権を移行する方法については、「Netezza 移行のセキュリティ、アクセス、操作」を参照してください。

各テストの再現性を高め、一貫したアプローチでテスト結果を評価できるように、テストを可能な限り自動化します。 自動化は、既知の定期的なレポートに適しており、Azure Synapse Pipelines または Azure Data Factory オーケストレーションによって管理できます。 回帰テスト用の一連のテスト クエリが既にある場合は、既存のテスト ツールを使用して移行後のテストを自動化できます。

アドホック分析とレポート作成はより困難であり、移行前後の同じレポートとダッシュボードが整合していることを確認するために、一連のテストをまとめる必要があります。 不整合が見つかった場合、移行テスト中に元のシステムと移行されたシステムの間でメタデータ系列を比較できるかどうかが重要になります。 他の方法による検出が困難な場合に、この比較で相違点を浮き彫りにし、不整合が発生した場所を特定できます。

系列を分析して、レポート、ダッシュボード、およびデータ間の依存関係を理解する

系列を理解することは、レポートとダッシュボードの移行を成功させる重要な要素です。 系列は、移行されたデータの行程を示すメタデータです。これにより、レポートまたはダッシュボードからデータ ソースへのパスを遡って追跡できます。 系列が示すのは、ポイント間でのデータの移動の過程、データ ウェアハウスまたはデータ マート内におけるデータの場所、データを使用しているレポートとダッシュボードです。 系列は、さまざまなデータ ストア (ファイルやデータベースなど) を介して異なる ETL パイプラインを通過し、レポートにたどり着く際にデータがどのように処理されたのかを理解するのに役立ちます。 ビジネス ユーザーがデータ系列にアクセスできれば、信頼性と自信を高め、情報に基づいてビジネス上の意思決定を行うことができます。

マルチベンダー データ ウェアハウス環境では、BI チームのビジネス アナリストがデータ系列をマップする場合があります。 たとえば、ETL、データ ウェアハウス、レポートに異なるベンダーを使用していて、各ベンダーに独自のメタデータ リポジトリがある場合、レポート内の特定のデータ要素がどこから来たのかを特定するのは困難で時間がかかる可能性があります。

レガシ データ ウェアハウスから Azure Synapse にシームレスに移行するには、各環境で生成されたレポートとダッシュボードを比較する際に、エンドツーエンドのデータ系列を使用して、既存のものと同じ移行であることを立証します。 エンドツーエンドのデータの行程を示すには、複数のツールからメタデータをキャプチャして統合する必要があります。 メタデータの自動検出とデータ系列をサポートするツールを利用できれば、レポートや ETL プロセスが重複していないかを特定し、古い、疑わしい、または存在しないデータ ソースに依存するレポートを見つけることができます。 この情報を使用すると、移行するレポートと ETL プロセスの数を削減できます。

また、Azure Synapse のレポートのエンドツーエンドの系列を、レガシ環境の同じレポートのエンドツーエンドの系列と比較して、移行中に誤って発生した差異がないかどうかを確認することもできます。 このような比較は、移行をテストして成功したかどうかを検証する必要がある場合に非常に有用です。

データ系列を視覚化すると、移行プロセスの時間、労力、エラーを削減できるだけでなく、移行を迅速化できます。

系列を比較する自動メタデータ検出ツールとデータ系列ツールを使用することで、移行されたデータから生成された Azure Synapse 内のレポートが、レガシ環境と同じ方法で作成されているかを検証できます。 この機能は、以下の判断にも役立ちます。

• Azure Synapse でレポートやダッシュボードを正常に実行するために、どのデータを移行する必要があるのか。

• Azure Synapse での実行を成功させるために、どのような変換が行われたのか、そして行う必要があるのか。

• レポートの重複を減らす方法について。

自動メタデータ検出ツールとデータ系列ツールは、移行プロセスを大幅に簡素化します。これらを利用して、企業がデータ資産をより正確に認識し、強固なレポート環境を実現するために何を Azure Synapse に移行する必要があるかを把握できるためです。

複数の ETL ツールがエンドツーエンドの系列機能を備えています。そのため、Azure Synapse でその機能を使用しようとしている場合は、既存の ETL ツールにその機能があるかどうかを確認してください。 Azure Synapse Pipelines または Data Factory では、どちらもマッピング フローの系列を表示する機能がサポートされています。 Microsoft パートナーも、自動メタデータ検出、データ系列、系列比較のツールを提供しています。

BI ツールのセマンティック レイヤーを Azure Synapse Analytics に移行する

一部の BI ツールには、セマンティック メタデータ レイヤーと呼ばれるものがあります。 このレイヤーを使用すると、ビジネス ユーザーは、データ ウェアハウスまたはデータ マート データベース内の基になる物理データ構造に簡単にアクセスできます。 セマンティック メタデータ レイヤーでは、ディメンション、メジャー、階層、計算されたメトリック、結合などの高レベルのオブジェクトを提供することでアクセスを簡略化します。 高レベルのオブジェクトではビジネス アナリストになじみのあるビジネス用語が使用され、このオブジェクトはデータ ウェアハウスまたはデータ マート内の物理データ構造にマップされます。

データ ウェアハウスの移行の際には、列名やテーブル名の変更を余儀なくされることがあります。 たとえば、IBM Netezza では、テーブル名に "#" を含めることができます。 Azure Synapse では、"#" は一時テーブルを示すテーブル名のプレフィックスとしてのみ使用できます。 IBM Netezza では、一時テーブルの名前に必ずしも "#" が含まれているわけではありませんが、Synapse では必須です。 このような場合、テーブル マッピングを変更するために何らかの修正が必要になると考えられます。

複数の BI ツール間での一貫性を実現するには、BI ツールやアプリケーションと Azure Synapse との間にデータ仮想化サーバーを配置し、使用することで、ユニバーサル セマンティック レイヤーを作成します。 データ仮想化サーバーでは、ディメンション、メジャー、階層、結合などの高レベル オブジェクトに共通のデータ名を使用します。 こうすることで、計算フィールド、結合、マッピングなど、すべてを 1 回だけ (ツールごとではなく) 構成します。 この後に、すべての BI ツールがデータ仮想化サーバーをポイントするようにします。

データ仮想化を使用することで、すべての BI ツールに一貫性を持たせ、BI ツールやアプリケーションと、Azure Synapse の基となる物理データ構造との間の依存関係を切り離します。 Microsoft パートナーは、Azure での一貫性の実現を支援します。 次の図は、データ仮想化サーバーで共通のボキャブラリを使用することによって、複数の BI ツールで共通のセマンティック レイヤーを認識できる様子を示しています。

まとめ

データ ウェアハウスのリフト アンド シフト移行では、ほとんどのレポート、ダッシュボード、その他の視覚化を簡単に移行できます。

レガシ環境からの移行中、レガシ データ ウェアハウスまたはデータ マート テーブル内のデータが、サポートされていないデータ型で格納されていることに気付く場合があります。 または、Azure Synapse に同等のものがない、独自の SQL を含むレガシ データ ウェアハウス ビューが見つかることもあります。 その場合は、これらの問題を解決して、Azure Synapse への移行を確実に成功させる必要があります。

問題がどこにあるかを特定するために、ユーザーが管理するドキュメントは利用しないでください。 代わりに、EXPLAIN ステートメントを使用します。これが、SQL の非互換性を特定する迅速で実用的な方法であるためです。 Azure Synapse で同等の機能を実現するには、非互換の SQL ステートメントを修正します。 また、自動メタデータ検出ツールと系列ツールを使用して、依存関係を把握し、重複するレポートを見つけ、古い、疑わしい、または存在しないデータ ソースに依存する無効なレポートを特定します。 系列ツールを使用して系列を比較し、レガシ データ ウェアハウス環境で実行されているレポートが、Azure Synapse でも同じように生成されていることを確認します。

使用しなくなったレポートは移行しないでください。 BI ツールの使用状況データは、どのレポートが使用されていないかを特定するのに役立ちます。 移行するレポート、ダッシュボード、その他の視覚化について、すべてのユーザー、ユーザー グループ、ロール、特権を移行します。 レポートの移行戦略の推進に事業価値を利用する場合は、レポートを戦略的なビジネス目標と優先度に関連付けて、特定の目標に対してレポート分析情報がどのように寄与しているかを特定します。 データ マートごとに移行する場合は、メタデータを使用して、どのレポートがどのテーブルとビューに依存しているかを特定します。それにより、最初に移行するデータ マートを、情報に基づいて決定できます。

移行中にデータ ウェアハウスまたはデータ マートのデータ モデルの構造変更が起こる可能性があります。 データ仮想化を使用して、BI ツールとアプリケーションを構造変更から保護することを検討してください。 データ仮想化では、共通のボキャブラリを使用して共通のセマンティック レイヤーを定義できます。 共通のセマンティック レイヤーを使用することで、新しい Azure Synapse 環境のすべての BI ツールとアプリケーション間で一貫して共通のデータ名、定義、メトリック、階層、結合が使用されます。

次のステップ

SQL の問題を最小限に抑える方法の詳細については、このシリーズの次の次の記事である、Netezza 移行の SQL の問題を最小限に抑える方法に関するページを参照してください。