Report Builder の選択

分析を作成するオプションが増えたので、ニーズに合った Report Builder のフレーバーを正確に把握することが困難な場合があります。 このトピックでは、分析を構築するための最適な方法を選択する手順を説明します。

いつその SQL Report Builder を使えばいいですか。 whensql

traditional Report Builder 上で SQL Report Builder を使用する一般的な理由をいくつか見てみましょう。

SQL 固有の関数を使用する場合

この SQL Report Builder の美しさの一つは、現在Data Warehouseマネージャーで使用できない機能を使用できることです。 これまでは、アナリストがユーザーのビジョンを完全に実現するために介入する必要があった可能性があります。

SQL Report Builder は、以前は使用できなかった LISTAGG や GETDATE などの関数をサポートしています。 full list にアクセスできますが、その他の SQL 固有の関数には次のものがあります。

何らかのテストを行う場合

分析に最適な方法を見つけるために、様々な手法や戦略を試す場合は、SQL Report Builder を使用できます。 Data Warehouseマネージャで列を構築するには、DWM を使用して作成する時間と列は更新サイクルに依存します。

せいぜい、列を使用するには 1 回の更新サイクルを待つ必要があります。 列の作成を誤ったことに気付いた場合は、2 サイクルを経る必要があります。1 つのサイクルで最初に列に入力し、もう 1 つのサイクルで変更が反映されます。

新しい列を 1 回だけ使用する場合

前述のように、Data Warehouseマネージャーで列を作成するには時間がかかります。 Adobe 1 つのレポートで作成した列のみを使用する予定がある場合は、SQL Report Builder の使用が推奨されます。 これにより、更新サイクルが完了するまで待つ必要がなくなり、作業をより迅速に再開できます。

1 対多の関係を持つデータを操作する場合

データの構造によっては、分析を構築するための SQL Report Builder ータの方が効率的で論理的な選択になる場合があります。 1 対 1 のリレーションシップ用の列を作成するのはData Warehouse マネージャでは簡単ですが、1 対多のリレーションシップを処理する場合は、少し混乱する場合があります。

例えば、1 つの製品が複数の製品カテゴリの一部と見なされ、各製品の各カテゴリに関連付けられた売上高を表示するとします。 DWM を使用してこの関係を作成しようとすることは、面倒で難しい場合がありますが、SQL クエリを作成する方が少し簡単な場合があります。

従来のReport Builderを使用するのは、どのような場合ですか？ whentraditionalrb

SQL Report Builder を使用すると、以前は使用できなかった機能をより詳細に制御してアクセスできますが、常に正しい選択とは限りません。 Adobeでは、使用する report builder のフレーバーを決定する際に、次の点も考慮することをお勧めします。

単純なレポートを作成する場合

単純に作成したい場合は、従来のReport Builderを使用すると、完全な SQL クエリを記述するよりもはるかに高速になる可能性があります。 分析の作成に必要な列が既にData Warehouseマネージャーに存在している場合に役立ちます。

作業を他のユーザーと共有している場合…

組織全体のユーザーがこの分析を使用または表示していますか。 誰と作業を共有しているかによって、ビジュアルReport Builderを使い続けた方が良い場合もあります。 ユーザーは、Visual Report Builder の定義を素早く確認できるのに対し、長 SQL クエリを読み取る可能性もあります。

レポートを必要としているものの、SQL に慣れていない人がいる場合、AdobeはReport Builderの元の味を使用することを提案します。 これにより、作業が容易になります。

まとめ wrapup

SQL Report Builder と Visual Report Builder はどちらも、様々なユースケースに適しています。 これは、通常、分析のニーズと、誰が分析を使用しているかによって異なります。