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

この記事は、Teradata から 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 Notebooks、Azure Machine Learning、RStudio、Jupyter Notebook などの対話型データ サイエンス開発ツール。

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

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

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

• Azure Synapse へのすべてのユーザー。

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

• すべてのロールから Azure Synapse へ。

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

• 移行前に既存のデータ ウェアハウスに存在していたものを反映するためのユーザー、ロール、および特権の割り当て。 例えば次が挙げられます。

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

アクセスとセキュリティは、移行されたシステムのデータ アクセスに関する重要な考慮事項であり 、Teradata 移行のセキュリティ、アクセス、および操作の詳細について説明します。

必要なすべてのデータを移行して、レガシ環境のデータに対してクエリを実行するレポートとダッシュボードが 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 に移行する際の重要な質問は、最初に移行するレポートです。 次のようないくつかの要因によって、その決定が促進される可能性があります。

• 使用方法

• ビジネス バリュー

• 移行のしやすさ

• データ移行戦略

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

決定に関係なく、レポート、ダッシュボード、その他の視覚化を生成し、それらの項目からの分析情報に基づいてビジネス上の意思決定を行うため、ビジネス ユーザーが関与する必要があります。 あなたがこれを行うことができれば、全員に利益があります。

• レポートとダッシュボードをシームレスに移行する
• 最小限の労力でレポートとダッシュボードを移行し、
• 従来のデータ ウェアハウス システムではなく Azure Synapse で BI ツールをポイントし、似たレポート、ダッシュボード、その他の視覚化を取得します。

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

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

レガシ データ ウェアハウスが何年も稼働している場合は、数千ではないにしても数百のレポートが存在する可能性は十分にあります。 レポートとダッシュボードのインベントリを作成し、ビジネス目的と使用状況の統計情報を特定する価値があります。

未使用のレポートの場合は、移行作業を減らすために使用停止にするかどうかを決定します。 未使用のレポートを使用停止するかどうかを決定する際の重要な質問は、人々がそのレポートの存在を知らないために使用されていないのか、ビジネス上の価値がないためなのか、それとも別のレポートに置き換えられたためなのかを確認することです。

ビジネス価値に基づいてレポートを移行する

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

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

ビジネス価値を評価するもう 1 つの方法は、レポートとダッシュボードを運用、戦術的、または戦略的に分類して、使用されているビジネス レベルを特定することです。 SBOは、これらすべてのレベルでの貢献を必要とします。 どのレポートとダッシュボードが使用され、どのレベルで、どのような目標に関連付けられているかを把握することで、優先度の高いビジネス価値に最初の移行を集中できます。 次の ビジネス戦略目標 テーブルを使用して、レポートとダッシュボードを評価できます。

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

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

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

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

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

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

• 環境間の SQL 非互換性。

スキーマの非互換性

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

• Azure Synapse に同等のテーブルがない、従来のデータ ウェアハウス DBMS の非標準テーブルの種類。

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

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

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

レポート、ダッシュボード、その他の視覚化に対するスキーマの非互換性の影響は、多くの BI ツールでサポートされる汎用データ型が少ないため、思ったよりも小さくなります。 その結果、レガシ データ ウェアハウスには、サポートされていないデータ型をより多くのジェネリック型に CAST するビューが既に存在する可能性があります。

SQL の非互換性

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

• Azure Synapse で同等の機能を持たない独自の SQL 関数を含む従来のデータ ウェアハウス DBMS ビューにアクセスします。

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

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

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

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

レガシ Teradata データ ウェアハウスの最近の SQL アクティビティのログを確認することで、SQL の非互換性を見つけることができます。 スクリプトを使用して、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 の移行が完了し、エラーがないことを確認します。

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

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

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

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

テストを可能な限り自動化して、各テストを反復可能にし、テスト結果を評価するための一貫したアプローチをサポートします。 Automation は既知の通常のレポートに適しており、 Azure Synapse パイプライン または 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 パイプラインまたは Data Factory では、どちらもマッピング フローで系列を表示する機能をサポートしています。 また、Microsoft パートナー は、自動メタデータ検出、データ系列、系列比較ツールも提供しています。

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

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

データ ウェアハウスの移行では、列名またはテーブル名の変更が強制的に行われる可能性があります。 たとえば、Teradata では、テーブル名に "#" を指定できます。 Azure Synapse では、"#" は一時テーブルを示すテーブル名のプレフィックスとしてのみ許可されます。 Teradata では、TEMPORARY TABLES は必ずしも名前に "#" を持つわけではありませんが、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 の問題を最小限に抑える方法の詳細については、このシリーズの次の記事「 Teradata の移行に関する SQL の問題を最小限に抑える」を参照してください。