翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # データセットの使用 データセットは Quick Sight 分析の基盤であり、分析とダッシュボードを強化する準備済みで構造化されたデータソースとして機能します。データソースからデータセットを作成したら、ライフサイクルを通じてデータセットを効果的に管理して、信頼性、安全性、共同分析を確保する必要があります。 このセクションでは、データセットの編集とバージョニングからチームメンバーとの共有、セキュリティコントロールの実装まで、データセット管理ワークフロー全体について説明します。共同分析をサポートしながらデータセットの整合性を維持し、データセットに依存する分析を追跡し、行レベルと列レベルの両方のセキュリティを実装して機密情報を保護する方法について説明します。チーム使用のためのデータセットの準備、分析問題のトラブルシューティング、データガバナンスポリシーの実装など、これらのトピックは Quick Sight での効果的なデータセット管理に不可欠な知識を提供します。 **Topics** + [データセットの作成](creating-data-sets.md) + [データセットの編集](edit-a-data-set.md) + [以前の公開済みバージョンへのデータセットの復元](dataset-versioning.md) + [データセットの複製](duplicate-a-data-set.md) + [データセットの共有](sharing-data-sets.md) + [データセットを使用するダッシュボードと分析の追跡](track-analytics-that-use-dataset.md) + [Amazon Quick でのデータセットパラメータの使用](dataset-parameters.md) + [Amazon Quick での行レベルのセキュリティの使用](row-level-security.md) + [データセットへのアクセスを制限するために列レベルのセキュリティを使用する](restrict-access-to-a-data-set-using-column-level-security.md) + [Amazon Quick での IAM ロールとしてのクエリの実行](datasource-run-as-role.md) + [データセットの削除](delete-a-data-set.md) + [分析へのデータセットの追加](adding-a-data-set-to-an-analysis.md) # データセットの作成 Amazon Quick では、新規または既存のデータソースからデータセットを作成できます。さまざまなデータベースデータソースを使用して、Amazon Quick にデータを提供できます。これには、Amazon RDS インスタンスと Amazon Redshift クラスターが含まれます。また、MariaDB、Microsoft SQL Server、MySQL、Oracle、および、組織内、Amazon EC2、または類似の環境の PostgreSQL インスタンスなども含まれます。 **Topics** + [新しいデータソースを使用したデータセットの作成](creating-data-sets-new.md) + [既存のデータソースを使用したデータセットの作成](create-a-data-set-existing.md) + [Amazon Quick で既存のデータセットを使用してデータセットを作成する](create-a-dataset-existing-dataset.md) # 新しいデータソースを使用したデータセットの作成 Amazon RDS、Amazon Redshift、Amazon EC2 などの AWS サービスに基づいてデータセットを作成する場合、そのソースからのデータを消費するときにデータ転送料金が適用される場合があります。これらの料金は、その AWS リソースが Amazon Quick アカウントに AWS リージョン 選択したホームにあるかどうかによっても異なる場合があります。料金の詳細については、該当するサービスの料金表ページを参照してください。 データベースの新しいデータセットを作成する際に、1 つのテーブルを選択したり、複数のテーブルを結合させたり、SQL クエリを作成して必要なデータを取得したりすることが可能です。データセットが直接クエリを使用するか、その代わりにデータを [SPICE](spice.md) に保存するかを変更することもできます。 **新規データセットを作成するには** 1. データセットを作成するには、**データ**ページで**新しいデータセット**を選択します。次に、既存のデータセットまたはデータソースに基づいてデータセットを作成するか、新しいデータソースに接続し、そのデータソースに基づいてデータセットを作成します。 1. データソースへの接続情報を指定します。 + ローカルのテキストまたは Microsoft Excel ファイルの場合は、ファイルの場所を特定してファイルをアップロードするだけです。 + Amazon S3 の場合、使用するファイルまたはバケットを特定するマニフェスト、およびターゲットファイルのインポート設定を指定する必要があります。 + Amazon Athena の場合、 AWS アカウントのすべての Athena データベースが返されます。追加の認証情報は必要ありません。 + Salesforce の場合、接続のための認証情報を指定します。 + Amazon Redshift、Amazon RDS、Amazon EC2、またはその他のデータベースデータソースの場合、データをホストするサーバーおよびデータベースに関する情報を指定する必要があります。また、そのデータベースインスタンスの有効な認証情報も指定する必要があります。 # データベースからのデータセットの作成 以下の手順では、データベースデータソースに接続してデータセットを作成する方法について説明します。Amazon Quick アカウントが自動検出した AWS データソースからデータセットを作成するには、 を使用します[自動検出された Amazon Redshift クラスターまたは Amazon RDS インスタンスからのデータセットの作成](#create-a-data-set-autodiscovered)。他のデータベースデータソースからデータセットを作成するには、[自動検出以外のデータベースを使用したデータセットの作成](#create-a-data-set-database) を使用します。 ## 自動検出された Amazon Redshift クラスターまたは Amazon RDS インスタンスからのデータセットの作成 以下の手順に従って、自動検出された AWS データソースへの接続を作成します。 **自動検出された AWS データソースへの接続を作成するには** 1. [データソースのクォータ](data-source-limits.md) をチェックし、ターゲットテーブルまたはクエリがデータソースのクォータを超えていないことを確認します。 1. 使用する予定のデータベースの認証情報に、「[必要なアクセス許可](required-permissions.md)」で説明している適切なアクセス許可があることを確認します。 1. 「」の手順に従って、Amazon Quick Access のクラスターまたはインスタンスが設定されていることを確認します[ネットワークとデータベースの設定要件](configure-access.md)。 1. Amazon クイックスタートページで、**データ**を選択します。 1. **Create ** を選択し、**New データセット**を選択します。 1. 接続する AWS サービスに応じて、**RDS** または **Redshift 自動検出**アイコンを選択します。 1. データソースの接続情報を以下のように入力します。 + [**Data source name (データソース名)**] に、データソースの名前を入力します。 + [**Instance ID (インスタンス ID)**] で、接続先のインスタンスまたはクラスターの名前を選択します。 + [**Database name (データベース名)**] には、[**Instance ID (インスタンス ID)**] のクラスターまたはインスタンスのデフォルトデータベースが表示されています。そのクラスターまたはインスタンスの別のデータベースを使用するには、その名前を入力します。 + **[UserName]** で、次を実行するための許可を持つユーザーアカウントのユーザー名を入力します。 + ターゲットデータベースにアクセスします。 + 使用するデータベース内の（`SELECT` ステートメントを実行する）テーブルを読み取ります。 + **[パスワード]** で、入力したユーザーアカウントのパスワードを入力します。 1. [**Validate connection (接続を検証)**] を選択して、接続情報が正しいことを確認します。 1. 接続が検証された場合は、[**Create data source**] を選択します。検証されなかった場合は、接続情報を修正してから、検証をもう一度試します。 **注記** Amazon Quick は、Secure Sockets Layer (SSL) を使用して、Amazon RDS インスタンスと Amazon Redshift クラスターへの接続を自動的に保護します。これを有効にするために何かを行う必要はありません。 1. 次のいずれかを選択します。 + **独自 SQL** 次の画面では、[**Use custom SQL (独自 SQL を使用する)**] オプションを使用してクエリを記述することができます。これにより、[**Enter custom SQL query (独自 SQL を入力する)**] という名前の画面が開き、クエリの名前を入力して SQL を入力できます。最良の結果を得るには、SQL エディタでクエリを作成し、このウィンドウに貼り付けます。クエリに名前を付けて入力したら、[**Edit/Preview data (データの編集/プレビュー)**] または [**Confirm query (クエリの確認)**] を選択できます。または、[**Edit/Preview data (データの編集/プレビュー)**] を選択して、すぐにデータ準備に移動することができます。SQL を検証し、エラーがないことを確認するには、[**Confirm query (クエリの確認)**] を選択します。 + **テーブルの選択** 特定のテーブルに接続するには、**[Schema: contain sets of tables]** (スキーマ: テーブルのセットを含む) で、**[Select]** (選択) をクリックしてからスキーマを選択します。データベース内の 1 つのスキーマのみが存在する場合は、そのスキーマが自動的に選択され、スキーマの選択オプションは表示されません。 分析を作成する前にデータ準備を行うには、[**Edit/Preview data**] を選択してデータ準備を開きます。他のテーブルに結合する場合は、このオプションを使用します。 それ以外の場合は、テーブルを選択してから、[**選択**] を選択します。 1. 次のいずれかのオプションを選択します。 + 分析を作成する前に、データを準備します。これを行うには、[**Edit/Preview data (データの編集/プレビュー)]** を選択して、選択したテーブルのデータ準備を開きます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 + テーブルデータをそのまま使用してデータセットと分析を作成し、そのデータセットデータを SPICE にインポートしてパフォーマンスを向上させます (推奨)。これを行うには、テーブルサイズと SPICE インジケータをチェックして、十分な容量があるかどうかを確認します。 十分な SPICE 容量がある場合は、**[Import to SPICE for quicker analytics]** (迅速な分析のために SPICE へインポート) を選択してから、**[Visualize]** (視覚化) をクリックして分析を作成します。 **注記** SPICE を使用したいが空き容量が不足しているという場合は、**[Edit/Preview data]** (データの編集/プレビュー) をクリックします。データ準備では、データセットからフィールドを削除してサイズを小さくすることができます。フィルタを適用したり、返される行または列の数を減らす SQL クエリを記述することもできます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 + データセットを作成し、そのテーブルデータをそのまま使用して分析を作成し、データをデータベースから直接照会するには、**[Directly query your data]** (データクエリを直接実行) オプションを選択します。次に、[**Visualize (視覚化)**] を選択して分析を作成します。 ## 自動検出以外のデータベースを使用したデータセットの作成 自動検出された Amazon Redshift クラスターまたは Amazon RDS インスタンス以外のデータベースへの接続を作成するには、次の手順に従います。このようなデータベースには、別の にある、 AWS リージョン または別の AWS アカウントに関連付けられている Amazon Redshift クラスターと Amazon RDS インスタンスが含まれます。また、MariaDB、Microsoft SQL Server、MySQL、Oracle、および、Amazon EC2 またはその他アクセス可能な環境にあるオンプレミスの PostgreSQL の各インスタンスも含まれます。 **自動検出された Amazon Redshift クラスターまたは RDS インスタンスではないデータベースへの接続を作成するには** 1. [データソースのクォータ](data-source-limits.md) をチェックし、ターゲットテーブルまたはクエリがデータソースのクォータを超えていないことを確認します。 1. 使用する予定のデータベースの認証情報に、「[必要なアクセス許可](required-permissions.md)」で説明している適切なアクセス権限があることを確認します。 1. 「」の手順に従って、Amazon Quick Access のクラスターまたはインスタンスが設定されていることを確認します[ネットワークとデータベースの設定要件](configure-access.md)。 1. Amazon クイックスタートページで、**データの管理**を選択します。 1. **Create ** を選択し、**New データセット**を選択します。 1. 別の または別の AWS アカウント AWS リージョン に関連付けられている Amazon **Redshift クラスターに接続する場合は、Redshift 手動接続**アイコンを選択します。または、該当するデータベース管理システムのアイコンを選択し、Amazon Aurora、MariaDB、Microsoft SQL Server、MySQL、Oracle、PostgreSQL いずれかのインスタンスに接続します。 1. データソースの接続情報を以下のように入力します。 + [**Data source name (データソース名)**] に、データソースの名前を入力します。 + [**Database server (データベースサーバー)**] で、次のいずれかの値を入力します。 + Amazon Redshift クラスターまたは Amazon RDS インスタンスの場合は、クラスターまたはインスタンスのエンドポイントを、ポート番号を付けずに入力します。たとえば、エンドポイントの値が「`clustername.1234abcd.us-west-2.redshift.amazonaws.com:1234`」である場合は、「`clustername.1234abcd.us-west-2.redshift.amazonaws.com`」と入力します。エンドポイント値は、クラスターの**エンドポイント**フィールドまたは AWS コンソールのインスタンスの詳細ページから取得できます。 + MariaDB、Microsoft SQL Server、MySQL、Oracle または PostgreSQL の Amazon EC2 インスタンスの場合は、パブリック DNS アドレスを入力します。パブリック DNS 値は、Amazon EC2 コンソールのインスタンス詳細ペインにある、**[Public DNS]** (パブリック DNS) フィールドから取得できます。 + MariaDB、Microsoft SQL Server、MySQL、Oracle または PostgreSQL の Amazon EC2インスタンス以外のインスタンスの場合は、データベースサーバーのホスト名またはパブリック IP アドレスを入力します。接続のセキュリティ保護のために Secure Sockets Layer (SSL) を使用している (推奨) 場合は、SSL 証明書で要請されている情報に一致するホスト名を指定する必要があります。受け入れられる証明書の一覧については、「[Amazon Quick SSL および CA 証明書](configure-access.md#ca-certificates)」を参照してください。 + [**Port (ポート)**] に、クラスターまたはインスタンスで接続に使用されているポート番号を入力します。 + [**Database name (データベース名)**] に、使用するデータベースの名前を入力します。 + **[UserName]** で、次を実行するための許可を持つユーザーアカウントのユーザー名を入力します。 + ターゲットデータベースにアクセスします。 + 使用するデータベース内の（`SELECT` ステートメントを実行する）テーブルを読み取ります。 + **[パスワード]** で、入力したユーザーアカウントに関連付けられているパスワードを入力します。 1. (オプション) Amazon Redshift クラスター以外に接続していて、接続を保護する必要がない場合は、**[Enable SSL]** (SSL の有効化) がオフになっていることを確認します。保護されていない接続では改ざんされやすいため、*このチェックボックスはオンのままにしておくことをお勧めします*。 ターゲットインスタンスで SSL を使用して接続を保護する方法の詳細については、使用しているデータベース管理システムのドキュメントを参照してください。Amazon Quick は、自己署名 SSL 証明書を有効として受け入れません。受け入れられる証明書の一覧については、「[Amazon Quick SSL および CA 証明書](configure-access.md#ca-certificates)」を参照してください。 Amazon Quick は、SSL を使用して Amazon Redshift クラスターへの接続を自動的に保護します。これを有効にするために何かを行う必要はありません。 Presto や Apache Spark などの一部のデータベースは、Amazon Quick が接続する前に追加の要件を満たす必要があります。詳細については、「[Presto を使用したデータソースの作成](create-a-data-source-presto.md)」または「[Apache Spark を使用したデータソースの作成](create-a-data-source-spark.md)」を参照してください。 1. (オプション) [**Validate connection (接続を検証)**] を選択して、接続情報が正しいことを確認します。 1. 接続が検証された場合は、[**Create data source**] を選択します。検証されなかった場合は、接続情報を修正してから、検証をもう一度試します。 1. 次のいずれかを選択します。 + **独自 SQL** 次の画面では、[**Use custom SQL (独自 SQL を使用する)**] オプションを使用してクエリを記述することができます。これにより、[**Enter custom SQL query (独自 SQL を入力する)**] という名前の画面が開き、クエリの名前を入力して SQL を入力できます。最良の結果を得るには、SQL エディタでクエリを作成し、このウィンドウに貼り付けます。クエリに名前を付けて入力したら、[**Edit/Preview data (データの編集/プレビュー)**] または [**Confirm query (クエリの確認)**] を選択できます。または、[**Edit/Preview data (データの編集/プレビュー)**] を選択して、すぐにデータ準備に移動することができます。SQL を検証し、エラーがないことを確認するには、[**Confirm query (クエリの確認)**] を選択します。 + **テーブルの選択** 特定のテーブルに接続するには、**[Schema: contain sets of tables]** (スキーマ: テーブルのセットを含む) で、**[Select]** (選択) をクリックしてからスキーマを選択します。データベース内の 1 つのスキーマのみが存在する場合は、そのスキーマが自動的に選択され、スキーマの選択オプションは表示されません。 分析を作成する前にデータ準備を行うには、[**Edit/Preview data**] を選択してデータ準備を開きます。他のテーブルに結合する場合は、このオプションを使用します。 それ以外の場合は、テーブルを選択してから、[**選択**] を選択します。 1. 次のいずれかのオプションを選択します。 + 分析を作成する前に、データを準備します。これを行うには、[**Edit/Preview data (データの編集/プレビュー)]** を選択して、選択したテーブルのデータ準備を開きます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 + テーブルデータをそのまま使用してデータセットと分析を作成し、そのデータセットデータを SPICE にインポートしてパフォーマンスを向上させます (推奨)。これを行うには、テーブルサイズと SPICE インジケータをチェックして、十分な容量があるかどうかを確認します。 十分な SPICE 容量がある場合は、**[Import to SPICE for quicker analytics]** (迅速な分析のために SPICE へインポート) を選択してから、**[Visualize]** (視覚化) をクリックして分析を作成します。 **注記** SPICE を使用したいが空き容量が不足しているという場合は、**[Edit/Preview data]** (データの編集/プレビュー) をクリックします。データ準備では、データセットからフィールドを削除してサイズを小さくすることができます。フィルタを適用したり、返される行または列の数を減らす SQL クエリを記述することもできます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 + テーブルデータをそのまま使用してデータセットと分析を作成し、データベースから直接データをクエリします。そのためには、[**Directly query your data (データを直接クエリする)**] オプションを選択します。次に、[**Visualize (視覚化)**] を選択して分析を作成します。 # 既存のデータソースを使用したデータセットの作成 Salesforce、 AWS データストア、またはその他のデータベースデータソースに最初の接続を行うと、Amazon Quick は接続情報を保存します。これにより、データソースが **[Create a Data Set]** (データセットの作成) ページの **[FROM EXISTING DATA SOURCES]** (既存データソースから) セクションに追加されます。これらの既存のデータソースを使用して、接続情報を再度指定することなく、新しいデータセットを作成できます。 ## 既存の Amazon S3 データソースを使用したデータセットの作成 既存の Amazon S3 データソースを使用してデータセットを作成するには、次の手順に従います。 **既存の S3 データソースを使用してデータセットを作成するには** 1. Amazon クイックスタートページで、**データ**を選択します。 1. **「作成**」を選択し、**「新しいデータセット**」を選択します。 1. 使用する Amazon S3 データソースを選択します。 1. データセットを作成する前にデータを準備するには、**[Edit/Preview data]** (データの編集/プレビュー) を選択します。または、データをそのまま使用する分析を作成するには、[**Visualize (視覚化)**] を選択します。 ## 既存の Amazon Athena データソースを使用したデータセットの作成 既存の Amazon Athena データソースを使用してデータセットを作成するには、以下の手順を実行します。 **既存の Athena 接続プロファイルからデータセットを作成するには** 1. Amazon クイックスタートページで、**データ**を選択します。 1. **Create ** を選択し、**New データセット**を選択します。 使用する既存のデータソースの接続プロファイルアイコンを選択します。接続プロファイルには、データソースアイコンと、接続を作成したユーザーによって提供された名前がラベル付けされています。 1. [**データセットを作成**] を選択します。 Amazon Quick は、Athena ワークグループのみに基づいて、このデータソースの接続プロファイルを作成します。データベースとテーブルは保存されません。 1. **[Choose your table]** (テーブルの選択) 画面で、以下のいずれかを実行します。 + SQL クエリを作成するには、**[Use custom SQL]** (カスタム SQL を使用) を選択する。 + データベースとテーブルを選択するには、まず **[Database]** リストからデータベースを選択します。次に、そのデータベースに表示されたリストからテーブルを選択します。 ## 既存の Salesforce データソースを使用してデータセットを作成する 既存の Salesforce データソースを使用してデータセットを作成するには、次の手順に従います。 **既存の Salesforce データソースを使用したデータセットの作成** 1. Amazon クイックスタートページで、**データ**を選択します。 1. **Create ** を選択し、**New データセット**を選択します。 1. 使用する Salesforce データソースを選択します。 1. [**Create Data Set**] を選択します。 1. 次のいずれかを選択します。 + **独自 SQL** 次の画面では、[**Use custom SQL (独自 SQL を使用する)**] オプションを使用してクエリを記述することができます。これにより、[**Enter custom SQL query (独自 SQL を入力する)**] という名前の画面が開き、クエリの名前を入力して SQL を入力できます。最良の結果を得るには、SQL エディタでクエリを作成し、このウィンドウに貼り付けます。クエリに名前を付けて入力したら、[**Edit/Preview data (データの編集/プレビュー)**] または [**Confirm query (クエリの確認)**] を選択できます。または、[**Edit/Preview data (データの編集/プレビュー)**] を選択して、すぐにデータ準備に移動することができます。SQL を検証し、エラーがないことを確認するには、[**Confirm query (クエリの確認)**] を選択します。 + **テーブルの選択** 特定のテーブルに接続する場合は、**[Data elements:contain your data]**] (データ要素: データを含む) で、**[Select]** (選択) をクリックしてから **[REPORT]** (レポート) または **[OBJECT]** (オブジェクト) のいずれかを選択します。 分析を作成する前にデータ準備を行うには、[**Edit/Preview data**] を選択してデータ準備を開きます。他のテーブルに結合する場合は、このオプションを使用します。 それ以外の場合は、テーブルを選択してから、[**選択**] を選択します。 1. 次の画面で、次のいずれかのオプションを選択します。 + データセットを作成し、そのデータをそのまま使用して分析を作成するには、**[Visualize]** (視覚化する) を選択します。 **注記** 十分な [SPICE](spice.md) 容量がない場合は、**[Edit/Preview data]** (データの編集/プレビュー) を選択します。データ準備では、データセットからフィールドを除去してデータセットのサイズを減らしたり、返される行数を減らすフィルターを適用したりできます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 + 分析を作成する前にデータ準備を行うには、[**Edit/Preview data**] を選択して、選択したレポートまたはオブジェクトのためのデータ準備を開きます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 ## 既存のデータベースデータソースを使用したデータセットの作成 既存のデータベースデータソースを使用してデータセットを作成するには、次の手順に従います。 **既存のデータベースデータソースを使用してデータセットを作成するには** 1. Amazon クイックスタートページで、**データ**を選択します。 1. **Create** を選択し、**New データセット**を選択します。 1. 使用するデータベースデータソースを選択し、**データセットの作成**を選択します。 1. 次のいずれかを選択します。 + **独自 SQL** 次の画面では、[**Use custom SQL (独自 SQL を使用する)**] オプションを使用してクエリを記述することができます。これにより、[**Enter custom SQL query (独自 SQL を入力する)**] という名前の画面が開き、クエリの名前を入力して SQL を入力できます。最良の結果を得るには、SQL エディタでクエリを作成し、このウィンドウに貼り付けます。クエリに名前を付けて入力したら、[**Edit/Preview data (データの編集/プレビュー)**] または [**Confirm query (クエリの確認)**] を選択できます。または、[**Edit/Preview data (データの編集/プレビュー)**] を選択して、すぐにデータ準備に移動することができます。SQL を検証し、エラーがないことを確認するには、[**Confirm query (クエリの確認)**] を選択します。 + **テーブルの選択** 特定のテーブルに接続するには、**[Schema: contain sets of tables]** (スキーマ: テーブルのセットを含む) で、**[Select]** (選択) をクリックしてからスキーマを選択します。データベース内の 1 つのスキーマのみが存在する場合は、そのスキーマが自動的に選択され、スキーマの選択オプションは表示されません。 分析を作成する前にデータ準備を行うには、[**Edit/Preview data**] を選択してデータ準備を開きます。他のテーブルに結合する場合は、このオプションを使用します。 それ以外の場合は、テーブルを選択してから、[**選択**] を選択します。 1. 次のいずれかのオプションを選択します。 + 分析を作成する前に、データを準備します。これを行うには、[**Edit/Preview data (データの編集/プレビュー)]** を選択して、選択したテーブルのデータ準備を開きます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 + テーブルデータをそのまま使用してデータセットと分析を作成し、そのデータセットデータを [SPICE](spice.md) にインポートしてパフォーマンスを向上させます (推奨)。これを行うには、SPICE インジケータをチェックして、十分な容量があるかどうかを確認します。 十分な SPICE 容量がある場合は、**[Import to SPICE for quicker analytics]** (迅速な分析のために SPICE へインポート) を選択してから、**[Visualize]** (視覚化) をクリックして分析を作成します。 **注記** SPICE を使用したいが空き容量が不足しているという場合は、**[Edit/Preview data]** (データの編集/プレビュー) をクリックします。データ準備では、データセットからフィールドを削除してサイズを小さくすることができます。フィルタを適用したり、返される行または列の数を減らす SQL クエリを記述することもできます。データ準備の詳細については、「[データセットサンプルの準備](preparing-data-sets.md)」を参照してください。 + テーブルデータをそのまま使用してデータセットと分析を作成し、データベースから直接データをクエリします。そのためには、[**Directly query your data (データを直接クエリする)**] オプションを選択します。次に、[**Visualize (視覚化)**] を選択して分析を作成します。 # Amazon Quick で既存のデータセットを使用してデータセットを作成する Amazon Quick でデータセットを作成したら、ソースとして使用して追加のデータセットを作成できます。これを行うと、親データセットに含まれるすべてのデータ準備 (結合や計算フィールドなど) が保持されます。新しいデータの結合やデータのフィルタリングなど、新しい子データセット内のデータに準備を追加できます。また、子データセットに対して独自のデータ更新スケジュールを設定し、それを使用するダッシュボードと分析を追跡することもできます。 RLS ルールが有効になっているデータセットをソースとして使用して作成された子データセットは、親データセットの RLS ルールを継承します。より大きな親データセットから子データセットを作成するユーザーには、親データセットでアクセスできるデータのみが表示されます。次に、継承された RLS ルールに加えて、新しい子データセットにさらに RLS ルールを追加して、新しいデータセット内のデータにアクセスできるユーザーをさらに管理できます。子データセットは、直接クエリで RLS ルールが有効になっているデータセットからのみ作成できます。 既存のクイックデータセットからデータセットを作成すると、次の利点があります。 + **データセットの一元管理** - データエンジニアは、組織内の複数のチームのニーズに合わせて簡単に拡張できます。これを行うには、組織の主要データモデルを記述するいくつかの汎用データセットを開発し、維持することができます。 + **データソース管理の削減** – ビジネスアナリスト (BAs) は、多くの場合、データベースへのアクセスのリクエスト、データベース認証情報の管理、適切なテーブルの検索、クイックデータ更新スケジュールの管理に多くの時間と労力を費やします。既存のデータセットから新しいデータセットを構築することは、BA がデータベースからの raw データでゼロから開始する必要がないことを意味します。キュレートされたデータから始めることができます。 + **事前定義された主要メトリクス**：既存のデータセットからデータセットを作成することにより、データエンジニアは、企業の多くの組織にわたって重要なデータ定義を一元的に定義および維持できます。例としては、売上高の伸びと純差益還元などがあります。この機能を使用すると、データエンジニアはこれらの定義に変更を配信することもできます。このアプローチは、ビジネスアナリストが適切なデータの視覚化をより迅速かつ確実に開始できることを意味します。 + **データをカスタマイズする柔軟性** - 既存のデータセットからデータセットを作成することで、ビジネスアナリストは、自分のビジネスニーズに合わせてデータセットを柔軟にカスタマイズできます。これにより、他のチームのデータが中断される心配を回避できます。 例えば、あなたは 5 人のデータエンジニアで構成されるeコマース中心チームの一員であるとします。自分と自身のチームは、データベース内の販売、注文、キャンセル、返品データにアクセスできます。スキーマを介して 18 個の他のディメンションテーブルを結合することで、クイックデータセットを作成しました。チームが作成した主要メトリクスは、計算フィールド、注文商品販売 (OPS) です。その定義は次のとおりです。OPS = 製品数量 x 料金。 チームは、8 か国の 10 の異なるチームをまたぐ 100 人以上のビジネスアナリストにサービスを提供しています。これらは、クーポンチーム、アウトバウンドマーケティングチーム、モバイルプラットフォームチーム、レコメンデーションチームです。これらのチームはすべて、各自のビジネスラインを分析するためのベースとして OPS メトリクスを使用します。 何百もの接続されていないデータセットを手動で作成して維持するのではなく、チームはデータセットを再利用して、組織全体のチームに対して複数のレベルのデータセットを作成します。これにより、データ管理が一元化され、各チームがそれぞれのニーズに合わせてデータをカスタマイズできるようになります。同時に、メトリクス定義の更新などの更新がデータに同期され、行レベルおよび列レベルのセキュリティが維持されます。例えば、組織内の個々のチームが集中型データセットを使用できます。その後、チーム固有のデータと組み合わせて、新しいデータセットを作成し、その上に解析を構築できます。 主要 OPS メトリクスの使用に加えて、組織内の他のチームは、作成した一元化されたデータセットの列メタデータを再利用できます。例えば、データエンジニアリングチームは、一元化されたデータセット内で*名前*、*説明*、*データ型*、および*フォルダ*などのメタデータを定義できます。それ以降の全てのチームが使用できます。 **注記** Amazon Quick は、1 つのデータセットから最大 2 つの追加レベルのデータセットの作成をサポートします。 例えば、親データセットから、子データセットを作成し、孫データセットを合計 3 つのデータセットレベルで作成できます。 ## 既存のデータセットからのデータセットの作成 以下の手順に従って、既存のデータソースを使用してデータセットを作成します。 **既存のデータセットからデータセットを作成するには** 1. クイックスタートページから、左側のペインで**データ**を選択します。 1. **Create** を選択し、新しいデータセットの作成に使用するデータセットを選択します。 1. 対象のデータセットのページが開くので、**[Use in analysis]** (分析で使用)、**[Use in dataset]** (データセットで使用) の順に選択します。 データ準備ページが開き、計算フィールド、結合、セキュリティ設定など、親データセットのすべてのものがプリロードされます。 1. 開いたデータ準備ページで、左下の [**クエリモード**]、データセットが元の、親データセットから変更と更新を取り込む方法を選択します。以下のオプションを選択できます。 + **直接クエリ** - デフォルトのクエリモードです。このオプションを選択すると、関連付けられたデータセット、分析、またはダッシュボードを開くと、このデータセットのデータは自動的に更新されます。ただし、次のような制限があります。 + 親データセットが直接クエリを許可している場合、子データセットで直接クエリモードを使用できます。 + 結合に複数の親データセットがある場合、すべての親が同じ基になるデータソースの場合にのみ、子データセットの直接クエリモードを選択できます。例えば、同じ Amazon Redshift 接続などです。 + 直接クエリは、単一の SPICE 親データセットでサポートされています。結合内の複数の SPICE 親データセットではサポートされません。 + **SPICE** - このオプションを選択する場合は、新しいデータセットの親データセットとの同期用にスケジュールを設定できます。データセットの SPICE 更新スケジュールの作成に関する詳細については、[SPICE データの更新](refreshing-imported-data.md) を参照してください。 1. (オプション) 分析用にデータを準備します。データ準備の詳細については、「[Amazon Quick Sight でのデータの準備](preparing-data.md)」を参照してください。 1. (オプション) 行レベルまたは列レベルのセキュリティ(RLS/CLS) を設定して、データセットへのアクセスを制限します。RLS の設定の詳細については、「[データセットへのアクセスを制限するためのユーザーベースのルールでの行レベルのセキュリティの使用ユーザーベースのルールの使用](restrict-access-to-a-data-set-using-row-level-security.md)」を参照してください。SPF の設定の詳細については、「[データセットへのアクセスを制限するために列レベルのセキュリティを使用する](restrict-access-to-a-data-set-using-column-level-security.md)」を参照してください。 **注記** RLS/CLS は、子データセットにのみ設定できます。親データセットの RLS/CLS はサポートされていません。 1. 完了したら、[**Save & publish**] を選択して、変更を保存し、新しい子データセットを公開します。または、[**Save & publish**] を選択クして、新しい子データセットを公開し、データの視覚化を開始します。 # 他のユーザーがデータセットから新しいデータセットを作成しないようにする制限 Amazon Quick でデータセットを作成すると、他のユーザーが他のデータセットのソースとして使用しないようにできます。他のユーザーがそれを使用してデータセットを作成できるかどうかを指定できます。または、直接クエリデータセットや SPICE データセットなど、他のユーザーがデータセットから作成できる、または作成できないデータセットのタイプを指定することもできます。 次の手順を使用して、他のユーザーがデータセットから新しいデータセットを作成できないように制限する方法を学習します。 **他のユーザーがデータセットから新しいデータセットを作成しないように制限する** 1. クイックスタートページから、左側のペインで**データ**を選択します。 1. **Create** を選択し、新しいデータセットの作成を制限するデータセットを選択します。 1. そのデータセットに対して開いたページで、[**Edit dataset**] を選択します。 1. 開いたデータ準備ページで、右上の [**Manage**] を選択し、その後 [**Properties**] を選択します。 1. 開いた [**Dataset properties**] ペインで、以下のオプションから選択します。 + このデータセットからすべてのタイプの新しいデータセットを作成できないように制限するには、[**Allow new datasets to be created from this one**] をオフにします。 新しいデータセットの作成が許可されている場合、トグルは青色になります。新しいデータセットを作成できないときは、灰色になります。 + 他のユーザーが直接クエリデータセットを作成できないように制限するには、**[Allow direct query]** (直接クエリを許可) をオフにします。 + 他のユーザーによるデータセットの SPICE コピーの作成を制限するには、**[Allow SPICE copies]** (SPICE のコピーを許可) をオフにします。 SPICE データセットの詳細については、[SPICE へのデータのインポート](spice.md) を参照してください。 1. ペインを閉じます。 # データセットの編集 既存のデータセットを編集して、データ準備を行うことができます。Quick Sight データ準備機能の詳細については、「」を参照してください[Amazon Quick Sight でのデータの準備](preparing-data.md)。 編集用のデータセットは、**[Datasets]** (データセット) ページ、または分析ページから開けます。いずれかでデータセットを編集すると、そのデータセットを使用するすべての分析のデータセットが変更されます。 ## データセットを編集するときに考慮すべきこと 2 つの状況で、データセットへの変更により問題が発生する可能性があります。1 つは、意図的にデータセットを編集する場合です。もう 1 つは、データソースが変更されてそれに基づく分析に影響を与える場合です。 **重要** 本番稼働用環境で使用される分析は、正常に機能し続けるように保護する必要があります。 データの変更を扱うときは、以下のことをお勧めします。 + データソースとデータセット、およびそれらに依存するビジュアルをドキュメント化します。ドキュメントには、スクリーンショット、使用しているフィールド、フィールドウェルの配置、フィルタ、ソート、計算、カラー、フォーマットなどが含まれている必要があります。ビジュアルを再作成するのに必要なすべてを記録します。また、データセット管理オプションでデータセットを使用する Quick Sight リソースを追跡することもできます。詳細については、「[データセットを使用するダッシュボードと分析の追跡](track-analytics-that-use-dataset.md)」を参照してください。 + データセットを編集するときは、既存のビジュアルが壊れるような変更を加えないようにします。例えば、ビジュアルで使用されている列を削除するなどです。列を削除する必要がある場合は、その代わりに計算列を作成します。置き換え後の列は、元の列と同じ名前とデータ型にする必要があります。 + ソースデータベースのデータソースまたはデータセットが変更された場合は、前に説明したように、ビジュアルをその変更に合わせます。または、ソースデータベースを変更に合わせることもできます。例えば、ソーステーブル (ドキュメント) のビューを作成するとします。この状況で、テーブルが変更された場合は、列 (属性) を含める/除外する、データ型の変更、null 値の埋め込みなどを行って、ビューを調整できます。また、別の状況で、データセットが低速の SQL クエリに基づく場合は、クエリの結果を保持するテーブルを作成できます。 ソースのデータに十分に適応できない場合は、分析のドキュメントに基づいてビジュアルを再作成します。 + データソースへのアクセスができなくなった場合は、そのソースに基づく分析は空になります。作成したビジュアルは引き続き存在しますが、表示するデータを受け取るまでは表示できません。管理者によりアクセス許可が変更されたときに、このようなことが発生する場合があります。 + ビジュアルの基本となっているデータセットを削除すると、ドキュメントから再作成しなければならない可能性があります。ビジュアルを編集し、そのビジュアルで使用する新しいデータセットを選択します。古いファイルを新しいファイルに置き換える必要が常にある場合は、常に使用可能な場所にデータを保存します。例えば、.csv ファイルを Amazon S3 に保存して、ビジュアルに使用するための S3 データセットを作成します。S3 に保存されたファイルへのアクセスの詳細については、「[Amazon S3 ファイルを使用したデータセットの作成](create-a-data-set-s3.md)」を参照してください。 または、データをテーブルへインポートし、ビジュアルをクエリに基づいて行います。このようにすると、含まれているデータが変更されても、データ構造は変わりません。 + データ管理を一元化するには、他のユーザーが独自のデータセットを作成するために使用できる、汎用的な多目的データセットを作成することを検討してください。詳細については、「[Amazon Quick で既存のデータセットを使用してデータセットを作成する](create-a-dataset-existing-dataset.md)」を参照してください。 ## データセットページでのデータセットの編集 1. クイックスタートページから、左側の**データ**を選択します。 1. 開いた**データ**ページで、編集するデータセットを選択し、右上の**データセットの編集**を選択します。 データ準備ページが開きます。データセットで行える編集の種類については、「[Amazon Quick Sight でのデータの準備](preparing-data.md)」を参照してください。 ## 分析のデータセットの編集 分析ページからデータセットを編集するには、次の手順に従います。 **分析ページからデータセットを編集するには** 1. 分析内で、**[Fields list]** (フィールドリスト) ペインの上部にある鉛筆形の編集アイコンを選択します。 1. **[Data sets in this analysis]** (この分析のデータセット) で、編集するデータセットの右側にある 3 つのドットを選択し、次に **[Edit]** (編集) を選択します。 これで、データ準備ページの中に対象のデータセットが開きます。データセットに対して実行できる編集の種類については、「[Amazon Quick Sight でのデータの準備](preparing-data.md)」を参照してください。 # 以前の公開済みバージョンへのデータセットの復元 Amazon Quick Sight でデータセットに変更を保存して公開すると、データセットの新しいバージョンが作成されます。そのデータセットの以前に公開された全バージョンのリストは、いつでも確認できます。その履歴内にある特定のバージョンをプレビューしたり、必要に応じてデータセットを以前のバージョンに戻したりすることも可能です。 データセットのバージョニングには、以下の制限が適用されます。 + バージョニングペインには、データセットの最新 1,000 バージョンのみが表示され、バージョニングに使用できます。 + 公開済みバージョンが 1,000 を超えると、最も古いバージョンがバージョニングペインから自動的に削除され、それらのバージョンにデータセットを復元することはできなくなります。 以下の手順に従って、データセットを以前の公開済みバージョンに復元します。 **データセットを以前の公開済みバージョンに復元する** 1. クイックスタートページから、**データ**を選択します。 1. **データ**ページでデータセットを選択し、右上の**データセットの編集**を選択します。 データセットの編集の詳細については、[データセットの編集](edit-a-data-set.md) を参照してください。 1. 開いたデータセットの準備ページで、右上の青いツールバーにある **[Manage]** (管理) アイコンをクリックし、**[Publishing history]** (バージョニング) を選択します。 以前に公開されたバージョンのリストが右側に表示されます。 1. **[Publishing history]** (バージョニング) ペインで、目的のバージョンを見つけてから **[Revert]** (復元) をクリックします。 復元する前にバージョンをプレビューするには、**[Preview]** (プレビュー) をクリックします。 データセットが復元され、確認メッセージが表示されます。**[Publishing history]** (バージョニング) ペインも更新され、データセットのアクティブなバージョンが表示されます。 ## バージョンの復元に関するトラブルシューティング 以下のいずれかが原因で、データセットを特定のバージョンに復元できない場合があります。 + データセットが 1 つ、または複数の削除されたデータソースを使用している。 このエラーが発生した場合、データセットを以前のバージョンに復元することはできません。 + 復元することで計算フィールドが無効になる。 このエラーが発生した場合は、計算フィールドを編集または削除してから、データセットを保存することができます。そうすることで、データセットの新しいバージョンが作成されます。 + データソースから 1 つ、または複数の列が欠落している。 このエラーが発生すると、Quick Sight はプレビューでデータソースの最新のスキーマを表示し、バージョン間の違いを照合します。スキーマのプレビューに表示される計算フィールド、フィールド名、フィールドタイプ、およびフィルターの変更は、復元したいバージョンからのものです。この調整されたスキーマを、データセットの新しいバージョンとして保存できます。または、バージョニングペインの最上部にある (最新) バージョンで **[Preview]** (プレビュー) をクリックして、アクティブ (最新) バージョンに戻ることも可能です。 # データセットの複製 既存のデータセットを複製して、そのコピーを新しい名前で保存することができます。新しいデータセットは完全に別のコピーです。 **[Duplicate dataset]** (データセットの複製) オプションは、そのデータセットの所有者であり、データソースへのアクセス許可を持っている場合に使用できます。 **データセットを複製するには** 1. クイックスタートページから、左側の**データ**を選択します。 1. 複製するデータセットを選択します。 1. 開いたデータセットの詳細ページで、**データセットの編集**のドロップダウンを選択し、**複製**を選択します。 1. [Duplicate dataset] (データセットの複製) ページが開くので、複製されたデータセットに名前を付け、その後で **[Duplicate]** (複製) を選択します。 複製されたデータセットの詳細ページが開きます。このページからは、データセットの編集や、更新スケジュールの設定、その他を行うことができます。 # データセットの共有 他の Quick Sight ユーザーおよびグループにデータセットへのアクセスを許可するには、データセットを共有します。これにより、他のユーザーやグループはデータセットから分析を作成できます。共同所有者としての他のユーザーやグループも、データセットを更新、編集、削除、または再共有できます。 ## データセットの共有 データセットの所有者としてのアクセス許可があるユーザーは、次の手順により、そのアクセス許可を共有できます。 **データセットを共有するには** 1. クイックスタートページから、左側の**データ**を選択します。 1. **データ**ページで、共有するデータセットを選択します。 1. データセットの詳細ページが開くので、**[Permissions]** (許可) タブを選択し、次に **[Add users & groups]** (ユーザーとグループの追加) を選択します。 1. このデータセットを共有するユーザーまたはグループを入力し、その後で **[Add]** (追加) を選択します。招待できるのは、同じクイックアカウントに属するユーザーのみです。 このステップを繰り返し、データセットを共有するすべてのユーザーの情報を入力します。 1. **[Permission]** (許可) 列で、ユーザーまたはグループごとにロールを選択し、データセットに対するアクセス許可を付与します。 **[Viewer]** (閲覧者) を選択し、そのデータセットから分析や他のデータセットを作成することを、ユーザーに許可します。**[Owner]** (所有者) を選択すると、さらに、そのユーザーはデータセットの更新、編集、削除、再共有が行えます。 ユーザーに、データセットへのリンクを含む E メールが届きます。グループの場合は招待メールを受信しません。 # データセットを共有しているユーザーの許可の表示と編集 データセットへの所有者のアクセス許可があるユーザーは、次の手順で、そのデータセットへのユーザーアクセスの表示、編集、変更が行えます。 **所有者としてのアクセス許可がある場合にデータセットへのユーザーアクセスを表示、編集、変更するには** 1. クイックスタートページから、左側の**データ**を選択します。 1. **データ**ページで、共有するデータセットを選択します。 1. [Dataset details] (データセットの詳細) ページが開くので、**[Permissions]** (許可) タブを選択します。 そのデータセットへのアクセス権を持つ、すべてのユーザーおよびグループの一覧が表示されます。 1. (オプション) ユーザーまたはグループの許可ロールを変更するには、ユーザーまたはグループの **[Permissions]** (許可) 列で、ドロップダウンメニューを展開します。次に、**[Viewer]** (閲覧者) または **[Owner]** (所有者) のいずれかを選択します。 # データセットへのアクセス権の取り消し データセットへの所有者のアクセス許可があるユーザーは、次の手順で、そのデータセットへのユーザーアクセスを取り消すことができます。 **所有者としてのアクセス許可がある場合に、データセットへのユーザーアクセスを取り消すには** 1. クイックスタートページから、左側の**データ**を選択します。 1. **データ**ページで、共有するデータセットを選択します。 1. [Dataset details] (データセットの詳細) ページが開くので、**[Permissions]** (許可) タブを選択します。 そのデータセットへのアクセス権を持つ、すべてのユーザーおよびグループの一覧が表示されます。 1. ユーザーまたはグループの **[Actions]** (アクション) 列で、**[Revoke access]** (アクセス権の取り消し) を選択します。 # データセットを使用するダッシュボードと分析の追跡 Quick Sight でデータセットを作成すると、そのデータセットを使用するダッシュボードと分析を追跡できます。この方法は、データセットを変更したときに影響を受けるリソースを確認する場合や、データセットを削除する場合に便利です。 データセットを使用するダッシュボードと分析を確認するには、次の手順を実行します。 **データセットを使用するリソースを追跡するには** 1. クイックスタートページから、左側のペインで**データ**を選択します。 1. **データ**ページで、リソースを追跡するデータセットを選択します。 1. そのデータセットに対して開いたページで、[**Edit dataset**] を選択します。 1. 開いたデータ準備ページで、右上の [**Manage**] を選択し、その後 [**Usage**] を選択します。 1. データセットを使用するダッシュボードと解析が、開いたペインに一覧表示されます。 # Amazon Quick でのデータセットパラメータの使用 Amazon Quick では、作成者は直接クエリでデータセットパラメータを使用してデータセットを動的にカスタマイズし、再利用可能なロジックをデータセットに適用できます。データセットパラメータは、データセットレベルで作成されるパラメータです。これは、コントロール、計算フィールド、フィルター、アクション、URL、タイトル、説明を通じて分析パラメータに使用されます。分析パラメータの詳細については、「[Amazon Quick のパラメータ](parameters-in-quicksight.md)」を参照してください。以下に、データセットパラメータを使用して実行できる 3 つのアクションを示します。 + **ダイレクトクエリのカスタム SQL** – データセットの所有者は、データセットパラメータをダイレクトクエリデータセットのカスタム SQL に挿入できます。これらのパラメータをクイック分析のフィルターコントロールに適用すると、ユーザーはカスタムデータをより迅速かつ効率的にフィルタリングできます。 + **反復可能な変数** – データセットページ内の複数の場所に表示される静的な値は、カスタムデータセットパラメータを使用して 1 回のアクションで変更できます。 + **計算フィールドをデータセットに移動する** – クイック作成者は、分析内のパラメータを使用して計算フィールドをコピーし、データセットレベルに移行できます。これにより、分析レベルで計算フィールドが誤って変更されないように保護され、また計算フィールドが複数の分析間で共有されます。 状況によっては、データセットパラメータにより、複雑なカスタム SQL を必要とするダイレクトクエリデータセットのためのフィルターコントロールパフォーマンスが改善され、データセットレベルでのビジネスロジックが簡素化されます。 **Topics** + [データセットパラメータの制限](#dataset-parameters-limitations) + [Amazon Quick でのデータセットパラメータの作成](dataset-parameters-SQL.md) + [データセットパラメータをカスタム SQL に挿入する](dataset-parameters-insert-parameter.md) + [データセットパラメータを計算フィールドに追加する](dataset-parameters-calculated-fields.md) + [データセットパラメータをフィルターに追加する](dataset-parameters-dataset-filters.md) + [高速分析でのデータセットパラメータの使用](dataset-parameters-analysis.md) + [データセットパラメータの高度なユースケース](dataset-parameters-advanced-options.md) ## データセットパラメータの制限 このセクションでは、Amazon Quick でデータセットパラメータを使用する際に発生する可能性のある既知の制限について説明します。 + ダッシュボードの閲覧者が E メールによるレポートをスケジュールする場合、選択したコントロールは、E メール添付のレポートに含まれるデータセットパラメータに反映されません。代わりに、パラメータのデフォルト値が使用されます。 + データセットパラメータは、SPICE に保存されているデータセットのカスタムSQL に挿入できません。 + 動的デフォルトは、データセットを使用している分析の分析ページでのみ設定できます。データセットレベルで動的なデフォルトを設定することはできません。 + **[すべて選択]** オプションは、データセットパラメータにマッピングされている分析パラメータの複数値コントロールではサポートされていません。 + カスケードコントロールは、データセットパラメータではサポートされていません。 + データセットパラメータは、データセットがダイレクトクエリを使用している場合にのみ、データセットフィルターで使用できます。 + カスタム SQL クエリでは、使用可能なデータセットパラメータは 128 個のみです。 # Amazon Quick でのデータセットパラメータの作成 データセットパラメータの使用を開始するには、次の手順を実行します。 **新しいデータセットパラメータを作成するには** 1. クイックスタートページから、左側の**データ**を選択し、変更するデータセットの横にある省略記号 (3 つのドット) を選択し、**編集**を選択します。 1. 表示される **[データセット]** ページで、左側の **[パラメータ]** を選択し、(\$1) アイコンを選択して新しいデータセットパラメータを作成します。 1. 表示される **[新しいパラメータを作成]** ポップアップで、**[名前]** ボックスにパラメータ名を入力します。 1. **[データ型]** ドロップダウンで、必要なパラメータのデータ型を選択します。サポートされているデータ型は、`String`、`Integer`、`Number`、および `Datetime` です。このオプションは、パラメータの作成後に変更することはできません。 1. **[デフォルト値]** で、パラメータに設定するデフォルト値を入力します。 **注記** データセットパラメータを分析パラメータにマッピングする場合、別のデフォルト値を選択できます。この場合、ここで設定したデフォルト値は新しいデフォルト値によってオーバーライドされます。 1. **[値]** で、パラメータに設定する値のタイプを選択します。**[単一の値]** パラメータは、単一選択ドロップダウン、テキストフィールド、およびリストコントロールをサポートします。**[複数の値]** パラメータは、複数選択のドロップダウンコントロールをサポートします。このオプションは、パラメータの作成後に変更することはできません。 1. 新しいパラメータの設定が完了したら、**[作成]** を選択してパラメータを作成します。 # データセットパラメータをカスタム SQL に挿入する SQL ステートメントの `<<$parameter_name>>` を使用してデータセットパラメータを参照することにより、[ダイレクトクエリ] モードでデータセットのカスタム SQL にそのデータセットパラメータを挿入できます。ランタイムの際、ダッシュボードユーザーはデータセットパラメータに関連付けられたフィルターコントロール値を入力できます。その値が SQL クエリに反映された後、ダッシュボードのビジュアルで結果を確認できます。パラメータを使用して、顧客が `where` 句に入力した内容に基づく基本フィルターを作成できます。もしくは、`case when` または `if else` 句を追加して、パラメータの入力に基づき、SQL クエリのロジックを動的に変更することもできます。 例えば、エンドユーザーのリージョン名に基づいてデータをフィルタリングする `WHERE` 句をカスタム SQL に追加するとします。この場合、`RegionName` と呼ばれる単一の値のパラメータを作成します: ``` SELECT * FROM transactions WHERE region = <<$RegionName>> ``` ユーザーがパラメータに複数値を指定するようにすることもできます。 ``` SELECT * FROM transactions WHERE region in (<<$RegionNames>>) ``` 次のより複雑な例では、データセットの作成者は、ダッシュボードフィルターコントロールで選択できるユーザーの姓名に基づいて、2 つのデータセットパラメータを 2 回参照します。 ``` SELECT Region, Country, OrderDate, Sales FROM transactions WHERE region= (Case WHEN <<$UserFIRSTNAME>> In (select firstname from user where region='region1') and <<$UserLASTNAME>> In (select lastname from user where region='region1') THEN 'region1' WHEN <<$UserFIRSTNAME>> In (select firstname from user where region='region2') and <<$UserLASTNAME>> In (select lastname from user where region='region2') THEN 'region2' ELSE 'region3' END) ``` `SELECT` 句でパラメータを使用して、ユーザー入力からデータセットで新しい列を作成することもできます。 ``` SELECT Region, Country, date, (case WHEN <<$RegionName>>='EU' THEN sum(sales) * 0.93 --convert US dollar to euro WHEN <<$RegionName>>='CAN' THEN sum(sales) * 0.78 --convert US dollar to Canadian Dollar ELSE sum(sales) -- US dollar END ) as "Sales" FROM transactions WHERE region = <<$RegionName>> ``` データセットパラメータを追加する前にカスタム SQL クエリを作成するか、既存のクエリを編集するには、「[データをカスタマイズするための SQL の使用](adding-a-SQL-query.md)」を参照してください。 データセットパラメータを使用してカスタム SQL を適用する場合、`<<$parameter_name>>` はプレースホルダー値として使用されます。ユーザーがコントロールからパラメータ値のいずれかを選択すると、Quick はプレースホルダーをユーザーがダッシュボードで選択した値に置き換えます。 次の例では、ユーザーは、データを状態別にフィルタリングする新しいカスタム SQL クエリを入力します。 ``` select * from all_flights where origin_state_abr = <<$State>> ``` パラメータのデフォルト値が SQL クエリに適用され、結果が **[プレビュー]** ペインに表示されます。 # データセットパラメータを計算フィールドに追加する 形式 `${parameter_name}` を使用して、データセットパラメータを計算フィールド式に追加することもできます。 計算を作成するときは、**[パラメータ]** リストの下にあるパラメータのリストから既存のパラメータを選択できます。複数値のパラメータを含む計算フィールドを作成することはできません。 計算フィールドの追加の詳細については、「[Amazon Quick でパラメータを使用して計算フィールドを使用する](parameters-calculated-fields.md)」を参照してください。 # データセットパラメータをフィルターに追加する [ダイレクトクエリ] モードのデータセットの場合、データセットの作成者は、カスタム SQL なしで、フィルターでデータセットパラメータを使用できます。データセットが SPICE にある場合、データセットパラメータをフィルターに追加することはできません。 **データセットパラメータをフィルターに追加するには** 1. フィルターを作成するデータセットのデータセットページを開きます。左側の **[フィルター]** を選択し、**[フィルターを追加]** を選択します。 1. フィルターに付ける名前を入力し、ドロップダウンでフィルタリングするフィールドを選択します。 1. 新しいフィルターを作成した後、**[フィルター]** ペインでフィルターに移動し、フィルターの横にある省略記号 (三点) を選択して、**[編集]** を選択します。 1. **[Filter type]** (フィルタータイプ) で、**[Custom filter]** (カスタムフィルター) を選択します。 1. **[フィルター条件]** で、希望する条件を選択します。 1. **[パラメータを使用]** ボックスを選択し、フィルターで使用するデータセットパラメータを選択します。 1. 変更が完了したら、**[適用]** を選択します。 # 高速分析でのデータセットパラメータの使用 データセットパラメータを作成したら、そのデータセットを分析に追加した後、そのデータセットパラメータを新規または既存の分析パラメータにマッピングします。データセットパラメータを分析パラメータにマッピングした後、それらをフィルター、コントロール、その他の分析パラメータ機能とともに使用できます。 データセットパラメータは、パラメータが属するデータセットを使用する分析の **[パラメータ]** ペインで管理できます。**[パラメータ]** ペインの **[データセットパラメータ]** セクションでは、マッピングされていないデータセットパラメータのみを表示するように選択できます (デフォルト)。もしくは、マッピングされている、されていないにかかわらず、すべてのデータセットパラメータを表示するには、**[表示]** ドロップダウンから **[すべて]** を選択します。 ## 新しいクイック分析でのデータセットパラメータのマッピング パラメータを含むデータセットから新しい分析を作成する場合、データセットパラメータを使用する前に、それらのパラメータを分析にマッピングする必要があります。これは、パラメータを含むデータセットを分析に追加する場合にも当てはまります。分析のマッピングされていないすべてのパラメータは、分析の **[パラメータ]** ペインに表示できます。または、分析を作成する際、またはデータセットを追加する際に、ページの右上に表示される通知メッセージで **[表示]** を選択することもできます。 **データセットパラメータを分析パラメータにマッピングするには** 1. [クイックコンソール](https://quicksight.aws.amazon.com/)を開きます。 1. 変更する分析を選択します。 1. **[パラメータ]** アイコンを選択して、**[パラメータ]** ペインを開きます。 1. マッピングするデータセットパラメータの横にある省略記号 (三点) を選択し、**[パラメータをマッピング]** を選択して、データセットパラメータをマッピングする分析パラメータを選択します。 分析に分析パラメータがない場合は、**[パラメータをマッピング]** と **[新規作成]** を選択して、作成時にデータセットパラメータに自動的にマッピングされる分析パラメータを作成できます。 1. (オプション) 表示される **[新しいパラメータを作成]** ポップアップで、**[名前]** に新しい分析パラメータの名前を入力します。 1. (オプション) **[静的デフォルト値]** で、パラメータに設定する静的デフォルト値を選択します。 1. (オプション) **[動的デフォルトを設定]** を選択して、新しいパラメータの動的デフォルトを設定します。 1. **[マッピングされたデータセットパラメータ]** テーブルには、新しい分析パラメータにマッピングしているデータセットパラメータが表示されます。この分析パラメータに他のデータセットパラメータを追加するには、**[データセットパラメータの追加]** ドロップダウンを選択し、マッピングするパラメータを選択します。データセットパラメータのマッピングを解除するには、削除するデータセットパラメータの横にある **[削除]** ボタンを選択します。 分析パラメータの作成の詳細については、「[Amazon Quick でのパラメータの設定](parameters-set-up.md)」を参照してください。 データセットパラメータを分析パラメータにマッピングすると、分析パラメータは、分析で使用される場所にかかわらず、データセットパラメータを表します。 **[パラメータを編集]** ウィンドウで、データセットパラメータを分析パラメータにマッピングしたり、マッピング解除したりすることもできます。**[パラメータを編集]** ウィンドウを開くには、**[パラメータ]** ペインに移動し、変更する分析パラメータの横にある省略記号 (三点) を選択し、**[パラメータを編集]** を選択します。この分析パラメータに他のデータセットパラメータを追加するには、**[データセットパラメータの追加]** ドロップダウンを選択し、マッピングするパラメータを選択します。データセットパラメータのマッピングを解除するには、削除するデータセットパラメータの横にある **[削除]** ボタンを選択します。**[すべて削除]** を選択して、すべてのマッピングされたデータセットパラメータを削除することもできます。変更が完了したら、**[更新]** を選択します。 分析パラメータを削除すると、すべてのデータセットパラメータのマッピングが分析から解除され、**[パラメータ]** ペインの **[未マッピング]** セクションに表示されます。データセットパラメータを一度に 1 つの分析パラメータにのみマッピングできます。データセットパラメータを別の分析パラメータにマッピングするには、データセットパラメータのマッピングを解除してから、それを新しい分析パラメータにマッピングします。 ## マッピングされた分析パラメータにフィルターコントロールを追加する Quick でデータセットパラメータを分析パラメータにマッピングした後、フィルター、アクション、計算フィールド、タイトル、説明、URLsのフィルターコントロールを作成できます。 **マッピングされたパラメータにコントロールを追加するには** 1. 分析ページの **[パラメータ]** ペインで、必要なマッピングされた分析パラメータの横にある省略記号 (三点) を選択し、**[コントロールを追加]** を選択します。 1. 表示される **[コントロールを追加]** ウィンドウで、希望の **[名前]** を入力し、コントロールに付ける **[スタイル]** を選択します。単一の値のコントロールの場合は、`Dropdown`、`List`、および `Text field` から選択します。複数値コントロールの場合は、`Dropdown` を選択します。 1. **[追加]** を選択してコントロールを作成します。 # データセットパラメータの高度なユースケース このセクションは、より高度なオプションと、データセットパラメータとドロップダウンコントロールを使用するユースケースについて説明します。以下のチュートリアルを参照しながら、データセットパラメータを使用して動的なドロップダウンの値を作成します。 ## データセットパラメータによる複数値コントロールの使用 データセットのカスタム SQL に挿入されるデータセットパラメータを使用する場合、通常、データセットパラメータは特定の列の値によってデータをフィルタリングします。ドロップダウンコントロールを作成し、パラメータを値として割り当てた場合、ドロップダウンには、パラメータがフィルタリングした値のみが表示されます。以下は、データセットパラメータにマッピングされ、フィルタリングされていないすべての値を表示するコントロールを作成する手順です。 **割り当てられたすべての値をドロップダウンコントロールで表示させるには** 1. 元のデータセットのすべての一意の値を含む新しい単一列のデータセットを SPICE またはダイレクトクエリで作成します。例えば、元のデータセットが次のカスタム SQL を使用しているとします。 ``` select * from all_flights where origin_state_abr = <<$State>> ``` すべての一意の元の状態を含む単一列のテーブルを作成するには、次のカスタム SQL を新しいデータセットに適用します。 ``` SELECT distinct origin_state_abr FROM all_flights order by origin_state_abr asc ``` SQL 式は、すべての一意の状態をアルファベット順に返します。新しいデータセットには、データセットパラメータは含まれていません。 1. 新しいデータセットの **[名前]** を入力し、データセットを保存して公開します。この例では、新しいデータセットの名前は `State Codes` です。 1. 元のデータセットを含む分析を開き、新しいデータセットを分析に追加します。既存の分析にデータセットを追加する方法については、「[分析へのデータセットの追加](adding-a-data-set-to-an-analysis.md)」を参照してください。 1. **[コントロール]** ペインに移動し、編集するドロップダウンコントロールを見つけます。コントロールの横にある省略記号 (三点) を選択し、**[編集]** を選択します。 1. 左側に表示される **[フォーマットコントロール]** で、**[値]** セクションの **[データセットフィールドにリンク]** を選択します。 1. 表示される **[データセット]** ドロップダウンで、作成した新しいデータセットを選択します。この例では、`State Codes` データセットが選択されています。 1. 表示される **[フィールド]** ドロップダウンで、適切なフィールドを選択します。この例では、`origin_state_abr` フィールドが選択されています。 新しいデータセットへのコントロールのリンクを完了すると、すべての一意の値がコントロールのドロップダウンに表示されます。これには、データセットパラメータによって除外される値が含まれます。 ## [すべてを選択] オプションによるコントロールの使用 デフォルトでは、1 つ以上のデータセットパラメータが分析パラメータにマッピングされ、コントロールに追加される場合、`Select all` オプションは使用できません。以下は、前のセクションと同じシナリオ例を使用した回避策の手順です。 **注記** このチュートリアルは、ダイレクトクエリでロードできる小規模のデータセットが対象です。大規模なデータセットがあり、`Select All` オプションを使用したい場合は、データセットを SPICE にロードすることをお勧めします。ただし、`Select All` オプションをデータセットパラメータとともに使用する場合は、このチュートリアルでその方法について説明します。 まず、`States` という複数値パラメータを持つカスタム SQL を含むダイレクトクエリデータセットがあるとします。 ``` select * from all_flights where origin_state_abr in (<<$States>>) ``` **データセットパラメータを使用するコントロールで [すべて選択] オプションを使用するには** 1. 分析の **[パラメータ]** ペインで、使用するデータセットパラメータを見つけ、パラメータの横にある省略記号 (三点) から **[編集]** を選択します。 1. 表示される **[パラメータを編集]** ウィンドウで、**[複数の静的デフォルト値]** セクションに新しいデフォルト値を入力します。この例では、デフォルト値は ` All States` です。この例では、デフォルト値がコントロールの最初の項目として表示されるように、先頭にスペース文字が使用されていることに注意してください。 1. **[更新]** を選択してパラメータを更新します。 1. 分析別分析で使用しているデータセットパラメータを含むデータセットに移動します。データセットのカスタム SQL を編集して、新しい静的な複数のデフォルト値のデフォルトユースケースを含めます。` All States` の例を使用すると、SQL 式は次のようになります。 ``` select * from public.all_flights where ' All States' in (<<$States>>) or origin_state_abr in (<<$States>>) ``` ユーザーがコントロールで ` All States` を選択した場合、新しい SQL 式は一意のレコードすべてを返します。ユーザーがコントロールから別の値を選択した場合、クエリはデータセットパラメータによってフィルタリングされた値を返します。 ### [すべて選択] オプションと複数値オプションによるコントロールの使用 前の `Select all` の手順と前述の複数値コントロールの方法を組み合わせて、ユーザーが選択できる複数値に加え、`Select all` の値を含むドロップダウンコントロールを作成できます。このチュートリアルは、前の手順に従って、データセットパラメータを分析パラメータにマッピングする方法を理解し、分析でコントロールを作成できることを前提としています。マッピング分析パラメータの詳細については、「[新しいクイック分析でのデータセットパラメータのマッピング](dataset-parameters-analysis.md#dataset-parameters-map-to-analysis)」を参照してください。データセットパラメータを使用する分析でのコントロールの作成の詳細については、「[マッピングされた分析パラメータにフィルターコントロールを追加する](dataset-parameters-analysis.md#dataset-parameters-analysis-filter-control)」を参照してください。 **[すべて選択] オプションとマッピングされたデータセットパラメータを使用して複数値をコントロールに追加するには** 1. `Select all` カスタム SQL 式を含む元のデータセットと、元のデータセットに存在するフィルタリングされた列のすべての可能な値を含む 2 番目のデータセットを含む分析を開きます。 1. 前に作成したセカンダリデータセットに移動して、フィルタリングされた列のすべての値を返します。以前に設定した `Select all` オプションをクエリに追加するカスタム SQL 式を追加します。次の例では、データセットの戻り値のリストの先頭に ` All States` レコードを追加します。 ``` (Select ' All States' as origin_state_abr) Union All (SELECT distinct origin_state_abr FROM all_flights order by origin_state_abr asc) ``` 1. データセットが属する分析に戻り、使用しているデータセットパラメータを、前述の手順のステップ 3 で作成した分析パラメータにマッピングします。分析パラメータとデータセットパラメータには同じ名前を付けることができます。この例では、分析パラメータは `States` と呼ばれます。 1. 新しいフィルターコントロールを作成するか、既存のフィルターコントロールを編集し、**[すべて選択を非表示]** を選択して、複数値コントロールに表示される無効な **[すべて選択]** オプションを非表示にします。 コントロールを作成すると、ユーザーは同じコントロールを使用して、データセット内のフィルタリングされた列のすべてまたは複数値を選択できます。 # Amazon Quick での行レベルのセキュリティの使用 | | | --- | |  適用対象: Enterprise Edition  | Amazon Quick の Enterprise Edition では、データセットに対する行レベルのセキュリティ (RLS) を設定することで、データセットへのアクセスを制限できます。これは、データセットを共有する前または後に行います。RLS が設定されたデータセットをデータセット所有者と共有する場合、所有者は引き続きすべてのデータを表示できます。しかし、それを閲覧者と共有する場合、閲覧者は許可データセットのルールによって制限されたデータしか表示できません。 また、Quick の登録されていないユーザー用に Amazon Quick ダッシュボードをアプリケーションに埋め込む場合、行レベルのセキュリティ (RLS) を使用して、タグでデータをフィルタリング/制限できます。タグは、アプリケーション内のセッションを識別するユーザー指定の文字列です。タグを使用して、データセットの RLS コントロールを実装できます。データセットで RLS ベースの制限を設定することで、Quick はユーザー ID/セッションに関連付けられたセッションタグに基づいてデータをフィルタリングします。 データセットへのアクセスは、ユーザー名ベースもしくはグループベースのルール、タグベースのルール、またはそれらの両方を使用して制限することができます。 Quick でプロビジョニング (登録) されたユーザーまたはグループのデータを保護する場合は、ユーザーベースのルールを選択します。これを実行するには、データにアクセスする各ユーザーまたはグループに対して、列ごとに設定されたルールが含まれる許可データセットを選択します。データにアクセスできるのは、これらのルールで特定されたユーザーまたはグループのみです。 埋め込みダッシュボードを使用していて、Quick でプロビジョニングされていないユーザー (未登録ユーザー) のデータを保護する場合にのみ、タグベースのルールを選択します。これを実行するには、列にタグを定義してデータをセキュア化します。ダッシュボードを埋め込むときは、タグに対する値を渡す必要があります。 **Topics** + [データセットへのアクセスを制限するためのユーザーベースのルールでの行レベルのセキュリティの使用](restrict-access-to-a-data-set-using-row-level-security.md) + [匿名ユーザー用のダッシュボードの埋め込み時におけるデータセットへのアクセスを制限するためのタグベースのルールでの行レベルのセキュリティの使用](quicksight-dev-rls-tags.md) # データセットへのアクセスを制限するためのユーザーベースのルールでの行レベルのセキュリティの使用 | | | --- | |  適用対象: Enterprise Edition  | Amazon Quick の Enterprise Edition では、データセットに対する行レベルのセキュリティ (RLS) を設定することで、データセットへのアクセスを制限できます。これは、データセットを共有する前または後に行います。RLS が設定されたデータセットをデータセット所有者と共有する場合、所有者は引き続きすべてのデータを表示できます。しかし、それを閲覧者と共有する場合、閲覧者は許可データセットのルールによって制限されたデータしか表示できません。行レベルのセキュリティを追加することで、アクセスをさらに管理できます。 **注記** SPICE データセットを行レベルのセキュリティに適用する場合、データセット内の各フィールドに最大 2,047 文字の Unicode 文字を含めることができます。このクォータを超えるフィールドは、取り込み中に切り捨てられます。SPICE データクォータの詳細については、「[インポートされたデータに対する SPICE クォータ](data-source-limits.md#spice-limits)」を参照してください。 これを行うには、ユーザーまたはグループを識別するための 1 つの列を持つクエリまたはファイルを作成します。`UserName` と を使用するか`GroupName`、または `UserARN`と を使用できます`GroupARN`。そのユーザーまたはグループに*ルールを追加する*と考えることもできます。次に、アクセスを付与または制限するフィールドごとに、クエリまたはファイルに 1 列追加します。追加したユーザーまたはグループ名ごとに、各フィールドの値を追加します。NULL (値なし) を、すべての値を意味するものとして使用できます。データセットのルールの例は、「[行レベルのセキュリティに対するデータセットルールの作成](#create-data-set-rules-for-row-level-security)」を参照してください。 データセットのルールを適用するには、ルールをアクセス許可データセットとしてデータセットに追加します。次のポイントに注意が必要です。 + アクセス許可のデータセットに重複する値を含めることはできません。ルールの適用方法を評価する際、重複は無視されます。 + 指定された各ユーザーまたはグループには、データセットルールのフィールド値に*一致する*行のみが表示されます。 + ユーザーまたはグループにルールを追加し、他のすべての列を値なし (NULL) のままにすると、すべてのデータへのアクセスが付与されます。 + ユーザーまたはグループにルールを追加しない場合、そのユーザーまたはグループにデータが一切表示されません。 + ユーザーごとに適用されるルールレコードの完全なセットは、999 を超えないようにしてください。この制限は、ユーザーネームに直接割り当てられるルールと、グループ名を使用してユーザーに割り当てられるルールの総数に適用されます。 + フィールドにカンマ (,) が含まれている場合、Amazon Quick はカンマで区切られた各単語をフィルター内の個々の値として扱います。例えば、`('AWS', 'INC')` の中で、`AWS,INC` は2つの文字列、`AWS` および `INC` とみなされます。`AWS,INC` を使用してフィルタリングするには、アクセス許可データセット内の文字列を二重引用符で囲みます。 制限されたデータセットが SPICE データセットである場合は、ユーザーあたりの適用されたフィルター値の数を、制限されたフィールドごとに 192,000 個以下にする必要があります。これは、ユーザー名に直接割り当てられるフィルター値と、グループ名を使用してユーザーに割り当てられるフィルター値の総数に適用されます。 制限されたデータセットが直接クエリデータセットである場合、ユーザーごとに適用されるフィルター値の数はデータソースに応じて異なります。 フィルター値の制限を超えると、視覚化レンダリングが失敗する場合があります。フィルターリストを短縮できるように、制限されたデータセットに列を追加して、元の制限された列に基づいて行を複数グループに分割することをお勧めします。 Amazon Quick は、スペースをリテラル値として扱います。したがって、制限しているフィールドにスペースがある場合、その行にはデータセットルールが適用されます。Amazon Quick はNULLs と空白 (空の文字列「」) の両方を「値なし」として扱います。NULL は空のフィールドの値です。 データセットがどのデータソースから来ているかに応じて、直接クエリを設定し、アクセス許可のテーブルへアクセスすることができます。用語内にスペースが含まれている場合、引用符で区切る必要はありません。直接クエリを使用する場合は、元のデータソースでクエリを簡単に変更できます。 もしくは、テキストファイルまたはスプレッドシートからデータセットのルールをアップロードすることもできます。カンマ区切り値 (CSV) ファイルを使用している場合は、指定された行にスペースを含めないでください。スペースが含まれている用語は、引用符で区切る必要があります。ファイルベースのデータセットのルールを使用する場合は、データセットのアクセス許可設定にある既存のルールを上書きすることで、変更を適用する必要があります。 制限されているデータセットは、**データ**画面で **RESTRICTED** という単語でマークされます。 RLS ルールがアクティブな親データセットから作成された子データセットでは、親データセットの RLS ルールと同じ RLS ルールが保持されます。子データセットにはさらに RLS ルールを追加できますが、データセットが親データセットから継承する RLS ルールを削除することはできません。 RLS ルールがアクティブな親データセットから作成された子データセットは、直接クエリでのみ作成できます。親データセットの RLS ルールを継承する子データセットは SPICE ではサポートされていません。 行レベルのセキュリティが機能するのは、テキストデータ (文字列、char、varchar など) が含まれるフィールドのみです。現状、日付または数値フィールドでは機能しません。行レベルのセキュリティ (RLS) を使用するデータセットでは、異常検出はサポートされていません。 ## 行レベルのセキュリティに対するデータセットルールの作成 データセットのルールとして使用する、アクセス許可のファイルまたはクエリを作成するには、次の手順に従います。 **データセットのルールとして使用するアクセス許可ファイルまたはクエリを作成するには** 1. 行レベルのセキュリティ (RLS) のデータセットルール (アクセス許可) を含むファイルまたはクエリを作成します。 フィールドの順序は関係ありません。ただし、すべてのフィールドでは、大文字と小文字が区別されます。これらがフィールド名と値に完全に一致していることを確認してください。 構成は次のいずれかのようになります。ユーザーまたはグループを特定するフィールドが少なくとも 1 つあることを確認してください。両方を含めることができますが、必須は 1 つのみで、一度に 1 つのみ使用されます。ユーザーまたはグループに使用するフィールドには、任意の名前を付けることができます。 **注記** グループを指定する場合は、Amazon Quick グループまたは Microsoft AD グループのみを使用します。 次の例は、グループを含むテーブルを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/quick/latest/userguide/restrict-access-to-a-data-set-using-row-level-security.html) 次の例は、ユーザー名を含むテーブルを示しています。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/quick/latest/userguide/restrict-access-to-a-data-set-using-row-level-security.html) 以下は、ユーザーおよびグループの Amazon リソースネーム (ARN) が含まれるテーブルの例です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/quick/latest/userguide/restrict-access-to-a-data-set-using-row-level-security.html) .csv ファイルを使用する場合は、構造が以下のいずれかのようになっている必要があります。 ``` UserName,SalesRegion,Segment AlejandroRosalez,EMEA,"Enterprise,SMB,Startup" MarthaRivera,US,Enterprise NikhilJayashankars,US,SMB PauloSantos,US,Startup SaanviSarkar,APAC,"SMB,Startup" sales-tps@example.com,"","" ZhangWei,APAC-Sales,"Enterprise,Startup" ``` ``` GroupName,SalesRegion,Segment EMEA-Sales,EMEA,"Enterprise,SMB,Startup" US-Sales,US,Enterprise US-Sales,US,SMB US-Sales,US,Startup APAC-Sales,APAC,"SMB,Startup" Corporate-Reporting,"","" APAC-Sales,APAC,"Enterprise,Startup" ``` ``` UserARN,GroupARN,SalesRegion arn:aws:quicksight:us-east-1:123456789012:user/Bob,arn:aws:quicksight:us-east-1:123456789012:group/group-1,APAC arn:aws:quicksight:us-east-1:123456789012:user/Sam,arn:aws:quicksight:us-east-1:123456789012:group/group-2,US ``` SQL の例を次に示します。 ``` /* for users*/ select User as UserName, SalesRegion, Segment from tps-permissions; /* for groups*/ select Group as GroupName, SalesRegion, Segment from tps-permissions; ``` 1. データセットルールのデータセットを作成します。簡単に検索できるようにするために、意味のある名前を付けます（**Permissions-Sales-Pipeline**）。 ## 行レベルのセキュリティのためのルールデータセットのフラグ付け 特定のデータセットをルールデータセットとして適切にフラグ付けするには、次の手順を使用します。 ルールデータセットは、行レベルのセキュリティに使用されるアクセス許可データセットを通常のデータセットと区別するフラグです。アクセス許可データセットが 2025 年 3 月 31 日より以前に通常のデータセットに適用された場合、**[データセット]** のランディングページに [ルールデータセット] のフラグが表示されます。 アクセス許可データセットが 2025 年 3 月 31 日までに通常のデータセットに適用されなかった場合、通常のデータセットとして分類されます。ルールデータセットとして使用するには、アクセス許可データセットを複製し、データセット作成時にコンソールでルールデータセットとしてフラグを付けます。EDIT DATASET を選択し、オプションで DUPLICATE AS RULES DATASET を選択します。 ルールデータセットとして正常に複製するには、元のデータセットが以下の両方の条件を満たしていることを確認します: 1. 必須のユーザーメタデータ列またはグループメタデータ列を含むこと。2. データ型が文字列型である列のみを含むこと。 コンソールで新しいルールデータセットを作成するには、[新しいデータセット] ドロップダウンで [新しいルールデータセット] を選択します。プログラムでルールデータセットを作成するときは、次のパラメータを追加します: [UseAs: RLS\$1RULES](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_CreateDataSet.html#API_CreateDataSet_RequestSyntax)。これは、ルールデータセットの作成にのみ使用されるオプションのパラメータです。コンソールまたはプログラムでデータセットが作成され、ルールデータセットまたは通常のデータセットとしてフラグ付けされると、変更することはできなくなります。 データセットがルールデータセットとしてフラグ付けされると、Amazon Quick は厳格な SPICE 取り込みルールを適用します。データ整合性を確保するために、長さ制限を超える無効な行またはセルがある場合、ルールデータセットの SPICE 取り込みは失敗します。正常な取り込みを再開するには、取り込みの問題を修正する必要があります。厳格な取り込みルールは、ルールデータセットにのみ適用されます。行のスキップや文字列の切り捨てがあっても、通常のデータセットではデータセットの取り込みが失敗することはありません。 ## 行レベルのセキュリティの適用 ファイルまたはクエリを、アクセス許可のルールを含むデータセットとして使用し、行レベルのセキュリティ (RLS) を適用するには、次の手順に従います。 **ファイルまたはクエリを使用して行レベルのセキュリティを適用するには** 1. ルールを新しいデータセットとして追加したことを確認します。追加してもデータセットのリストに表示されない場合は、画面を更新します。 1. **データ**ページで、データセットを選択します。 1. [Dataset details] (データセットの詳細) ページが開くので、**[Row-level security]** (行レベルのセキュリティ) で、**[Set up]** (セットアップ) を選択します。 1. 開いた **[Set up row-level security]** (行レベルのセキュリティ) ページで、**[User-based rules]** (ユーザーベースのルール) を選択します。 1. 表示されるデータセットのリストから、許可データセットを選択します。 許可データセットがこの画面に表示されない場合は、データセットに戻り、ページを更新します。 1. **[Permissions policy]** (アクセス許可ポリシー) で **[Grant access to dataset]** (データセットへのアクセス権を付与する) をオンにします。各データセットにはただ 1 つのアクティブなアクセス許可データセットがあります。2 つ目のアクセス許可データセットを追加しようとすると、既存のものが上書きされます。 **重要** 行レベルのセキュリティを使用するときは、NULL 値および空の文字列値にいくつかの制限が適用されます。 データセットの制限されたフィールドに NULL 値または空の文字列 ("") がある場合、制限の適用時にこれらの行が無視されます。 アクセス許可のデータセット内で、NULL 値および空の文字列は同じように扱われます。詳細については、以下のテーブルを参照してください。 機密情報が誤って公開されないように、Amazon Quick はすべてのユーザーにアクセス権を付与する空の RLS ルールをスキップします。*空の RLS ルール*は、行のすべての列が値を持たない場合に発生します。Quick RLS は、NULL、空の文字列 (")、または空のカンマ区切り文字列 (",," など) を値なしとして扱います。 空のルールのスキップ後も、他の非空の RLS ルールは引き続き適用されます。 許可データセットに空のルールしかなく、それらのルールがすべてスキップされた場合、この許可データセットによって制限されているデータには誰もアクセスできません。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/quick/latest/userguide/restrict-access-to-a-data-set-using-row-level-security.html) データセットがデータセットのルールによって制限されている場合を除き、ダッシュボードを共有しているユーザーなら誰でもダッシュボード内の全データを表示できます。 1. **[Apply data set]** (データセットの適用) をクリックして変更を保存します。次に、**[Save data set rules?]** (データセットのルールを保存しますか?) ページで **[Apply and activate]** (適用とアクティベート) をクリックします。既存のユーザーへのアクセス許可の変更はすぐに適用されます。 1. (オプション) アクセス許可を削除するには、まずデータセットからデータセットのルールを削除します。 データセットのルールが削除されたことを確認してください。次に、アクセス許可データセットを選択してから、**[Remove data set]** (データセットの削除) を選択します。 アクセス許可を上書きするには、新しいアクセス許可データセットを選択して適用します。同じデータセット名を再利用できます。ただし、**Permissions** (アクセス許可) 画面で新しい許可を適用して、これらの許可がアクティブになるようにしてください。SQL クエリは動的に更新されるため、Amazon Quick の外部で管理できます。クエリの場合、直接クエリのキャッシュが自動更新されるときに、アクセス許可が更新されます。 ファイルベースのアクセス許可データセットを、対象のデータセットから削除する前に削除すると、制限されているユーザーはデータセットにアクセスすることができません。このデータセットがこの状態の間は、**[RESTRICTED]** (制限対象) のマークが付いたままになります。しかし、そのデータセットの **[Permission]** (アクセス許可) を表示すると、データセットのルールが選択されていないことがわかります。 この問題を修正するには、新しいデータセットルールを指定します。同じ名前のデータセットを作成するだけではこの問題は解決されません。**[Permissions]** (アクセス許可) 画面で新しい許可データセットを選択する必要があります。この制限は、ダイレクト SQL クエリには適用されません。 # 匿名ユーザー用のダッシュボードの埋め込み時におけるデータセットへのアクセスを制限するためのタグベースのルールでの行レベルのセキュリティの使用 | | | --- | |  適用対象: Enterprise Edition  | | | | --- | |    対象者: Amazon Quick Administrators と Amazon Quick Developer  | Quick でプロビジョニング (登録) されていないユーザー用に Amazon Quick ダッシュボードをアプリケーションに埋め込む場合、行レベルのセキュリティ (RLS) を使用して、タグでデータをフィルタリング/制限できます。タグは、アプリケーション内のセッションを識別するユーザー指定の文字列です。タグを使用して、データセットの RLS コントロールを実装できます。データセットで RLS ベースの制限を設定することで、Quick はユーザー ID/セッションに関連付けられたセッションタグに基づいてデータをフィルタリングします。 例えば、さまざまな小売業者のための顧客向けアプリケーションを所有する物流会社があるとしましょう。これらの小売業者の何千人ものユーザーが、アプリケーションにアクセスし、倉庫からの注文の出荷状況に関する指標を確認します。 Quick で何千人ものユーザーを管理する必要がないため、匿名埋め込みを使用して、認証および承認されたユーザーが表示できる選択したダッシュボードをアプリケーションに埋め込みます。ただし、小売業者にはビジネス用のデータのみが表示され、他のデータは表示されないようにする必要があります。タグによる RLS を使用すると、顧客に関連するデータのみが表示されるようにできます。 そのためには、以下のステップを実行します。 1. RLS タグをデータセットに追加します。 1. `GenerateEmbedUrlForAnonymousUser` API オペレーションを使用して、実行時にこれらのタグに値を割り当てます。 `GenerateEmbedUrlForAnonymousUser` API オペレーションを使用した匿名ユーザー向けダッシュボードの埋め込みに関する詳細については、[匿名 (未登録) ユーザー向けの Amazon Quick Sight ダッシュボードの埋め込み](embedded-analytics-dashboards-for-everyone.md) を参照してください。 タグによる RLS を使用するには、次の点に注意してください。 + タグによる RLS の使用は、現在、匿名埋め込み (特に、`GenerateEmbedUrlForAnonymousUser` API オペレーションを使用する埋め込みダッシュボード) でのみサポートされています。 + タグによる RLS の使用は、`GenerateEmbedURLForRegisteredUser` API オペレーションまたは古い `GetDashboardEmbedUrl` API オペレーションを使用する埋め込みダッシュボードではサポートされていません。 + RLS タグは、 AWS Identity and Access Management (IAM) またはクイック ID タイプではサポートされていません。 + SPICE データセットを行レベルのセキュリティに適用する場合、データセット内の各フィールドに最大 2,047 文字の Unicode 文字を含めることができます。このクォータを超えるフィールドは、取り込み中に切り捨てられます。SPICE データクォータの詳細については、「[インポートされたデータに対する SPICE クォータ](data-source-limits.md#spice-limits)」を参照してください。 ## ステップ 1: データセットに RLS タグを追加する Amazon Quick のデータセットにタグベースのルールを追加できます。または、`CreateDataSet` または `UpdateDataSet` API オペレーションを呼び出すことによってタグベースのルールを追加することもできます。詳細については、「[API を使用してデータセットに RLS タグを追加する](#quicksight-dev-rls-tags-add-api)」を参照してください。 Quick のデータセットに RLS タグを追加するには、次の手順に従います。 **RLS タグをデータセットに追加する** 1. クイックスタートページから、左側の**データ**を選択します。 1. RLS を追加するデータセットを選択します。 1. [Dataset details] (データセットの詳細) ページが開くので、**[Row-level security]** (行レベルのセキュリティ) で、**[Set up]** (セットアップ) を選択します。 1. 開いた **[Set up row-level security]** (行レベルのセキュリティを設定) ページで、**[Tag-based rules]** (タグベースのルール) を選択します。 1. **[Column]** (列) では、タグルールを追加する列を選択します。 例えば、この物流会社の場合は、`retailer_id` 列が使用されます。 文字列データ型の列のみがリストされます。 1. **[Tag]** (タグ) には、タグキーを入力します。任意のタグ名を入力できます。 例えば、この物流会社の場合は、タグキー `tag_retailer_id` が使用されます。こうすることで、アプリケーションにアクセスする小売業者に基づいた行レベルのセキュリティが設定されます。 1. (オプション) **[Delimiter]** (区切り記号) には、リストから区切り記号を選択するか、独自の区切り記号を入力します。 タグに複数の値を割り当てるときは、区切り記号を使用してテキスト文字列を区切ることができます。区切り記号の値は、最長で 10 文字にすることができます。 1. (オプション) **[Match all]** (すべて一致) には、**[\$1]** を選択するか、独自の文字 (1 つ、または複数) を入力します。 このオプションは、データセット内のその列にあるすべての値でフィルタリングしたいときに使用する任意の文字にすることができます。値を 1 つずつリストする代わりに、この文字を使用できます。この値を指定する場合、少なくとも 1 文字、または最大 256 文字の長さにすることができます。 1. **[Add]** (追加) を選択します。 タグルールがデータセットに追加されて最下部にリストされますが、まだ適用はされていません。データセットに別のタグルールを追加するには、ステップ 5～9 を繰り返します。タグルールを編集するには、ルールの後の鉛筆アイコンを選択します。タグルールを削除するには、ルールの後の削除アイコンを選択します。データセットには最大 50 個のタグを追加できます。 1. データセットにタグルールを適用する準備ができたら、**[Apply rules]** (ルールを適用) をクリックします。 1. **[Turn on tag-based security?]** (タグベースのセキュリティをオンにしますか?) で **[Apply and activate]** (適用とアクティベート) をクリックします。 これでタグベースのルールがアクティブになりました。**[Set up row-level security]** (行レベルのセキュリティを設定) ページに、データセットのタグルールをオンとオフに切り替えるためのトグルが表示されます。 データセット用のすべてのタグベースのルールを無効にするには、**[タグベースのルール]** トグルをオフにし、表示されるテキストボックスに「確認」と入力します。 **データ**ページには、タグルールが有効になっていることを示すロックアイコンがデータセット行に表示されます。 これで、[ステップ 2: ランタイム時に値を RLS タグに割り当てる](#quicksight-dev-rls-tags-assign-values) で説明されているように、ランタイム時にタグルールを使用してタグ値を設定できるようになりました。ルールは、アクティブな場合にのみクイックリーダーに影響します。 **重要** データセットでタグが割り当てられ、有効になったら、ダッシュボードの作成時にデータセット内のデータを表示するアクセス許可を Quick authors に付与してください。 Quick authors にデータセット内のデータを表示するアクセス許可を付与するには、データセットルールとして使用するアクセス許可ファイルまたはクエリを作成します。詳細については、「[行レベルのセキュリティに対するデータセットルールの作成](restrict-access-to-a-data-set-using-row-level-security.md#create-data-set-rules-for-row-level-security)」を参照してください。 タグベースのルールを作成すると、タグベースのルールが相互にどのように関連しているかを示す新しい **[ルールを管理]** テーブルが表示されます。**[ルールを管理]** テーブルにリストされているルールを変更するには、ルールの後の鉛筆アイコンを選択します。その後、タグを追加または削除し、**[更新]** を選択します。更新したルールをデータセットに適用するには、**[適用]** を選択します。 ### (オプション) RLS タグに OR 条件を追加する タグベースのルールに OR 条件を追加して、クイックアカウントユーザーにデータを表示する方法をさらにカスタマイズすることもできます。タグベースのルールで OR 条件を使用すると、ルールで定義された少なくとも 1 つのタグが有効であれば、Quick のビジュアルが表示されます。 **タグベースのルールに OR 条件を追加するには** 1. **[ルールを管理]** テーブルで、**[OR 条件を追加]** を選択します。 1. 表示される **[タグを選択]** ドロップダウンリストで、OR 条件を作成するタグを選択します。**[ルールを管理]** テーブルには、最大 50 個の OR 条件を追加できます。データセット内の 1 つの列に複数のタグを追加できますが、1 つのルールには少なくとも 1 つの列タグが含まれている必要があります。 1. **[更新]** を選択してルールに条件を追加し、**[適用]** を選択して更新されたルールをデータセットに適用します。 ### API を使用してデータセットに RLS タグを追加する 別の手段として、`CreateDataSet` または `UpdateDataSet` API オペレーションを呼び出すことによって、データセットにタグベースの行レベルのセキュリティを設定し、有効化することもできます。以下の例を使って説明します。 **重要** API コールでセッションタグを設定する場合、 セッションタグをセキュリティ認証情報として扱います。セッションタグをエンドユーザーまたはクライアント側のコードに公開しないでください。 サーバー側のコントロールを実装します。セッションタグは、エンドユーザーが変更できるパラメータではなく、信頼できるバックエンドサービスによってのみ設定されていることを確認してください。 セッションタグを列挙から保護します。あるテナントのユーザーが、他のテナントに属する sessionTag 値を検出または推測できないようにします。 アーキテクチャを確認します。ダウンストリームの顧客またはパートナーが API を直接呼び出すことが許可されている場合は、アクセスすべきでないテナントに sessionTag 値を指定できるかどうかを評価します。 ------ #### [ CreateDataSet ] 以下は、タグによる RLS を使用するデータセットを作成する例です。これは、前述の物流会社のシナリオを想定しています。タグは、`row-level-permission-tag-configuration` 要素で定義されています。タグは、データを保護する列に対して定義されています。このオプション要素の詳細については、*Amazon Quick API リファレンス*の[RowLevelPermissionTagConfiguration](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_RowLevelPermissionTagConfiguration.html)」を参照してください。 ``` create-data-set --aws-account-id --data-set-id --name --physical-table-map [--logical-table-map ] --import-mode [--column-groups ] [--field-folders ] [--permissions ] [--row-level-permission-data-set ] [--column-level-permission-rules ] [--tags ] [--cli-input-json ] [--generate-cli-skeleton ] [--row-level-permission-tag-configuration '{ "Status": "ENABLED", "TagRules": [ { "TagKey": "tag_retailer_id", "ColumnName": "retailer_id", "TagMultiValueDelimiter": ",", "MatchAllValue": "*" }, { "TagKey": "tag_role", "ColumnName": "role" } ], "TagRuleConfigurations": [ tag_retailer_id ], [ tag_role ] }' ] ``` この例のタグは、要素の `TagRules` 部分で定義されています。この例では、2 つの列に基づいて 2 つのタグが定義されています。 + `tag_retailer_id` タグキーは `retailer_id` 列に対して定義されています。この物流会社の場合は、アプリケーションにアクセスしている小売業者に基づいて行レベルのセキュリティが設定されます。 + `tag_role` タグキーは `role` 列に対して定義されています。この物流会社の場合は、特定の小売業者からアプリケーションにアクセスしているユーザーのロールに基づいて、行レベルのセキュリティの追加レイヤーが設定されます。例として、`store_supervisor` または `manager` があります。 タグごとに、`TagMultiValueDelimiter` および `MatchAllValue` を定義できます。これらはオプションです。 + `TagMultiValueDelimiter` - このオプションは、ランタイム時に値を渡すときにそれらを区切るために使用する任意の文字列にすることができます。値の最大長は 10 文字です。この場合、区切り文字の値としてカンマが使用されます。 + `MatchAllValue` - このオプションは、データセット内のその列にあるすべての値でフィルタリングしたいときに使用する任意の文字にすることができます。値を 1 つずつリストする代わりに、この文字を使用できます。指定する場合、この値は 1 文字から 256 文字までの長さにすることができます。この場合、すべての値の一致としてアスタリスクが使用されます。 データセット列のタグを設定するときに、必須プロパティの `Status` を使用して、それらを有効または無効にします。タグルールを有効にするには、このプロパティに対して値 `ENABLED` を使用します。タグルールを有効にすることによって、[ステップ 2: ランタイム時に値を RLS タグに割り当てる](#quicksight-dev-rls-tags-assign-values) で説明されているように、ランタイム時にタグルールを使用してタグ値を設定できます。 以下は、応答の定義の例です。 ``` { "Status": 201, "Arn": "arn:aws:quicksight:us-west-2:11112222333:dataset/RLS-Dataset", "DataSetId": "RLS-Dataset", "RequestId": "aa4f3c00-b937-4175-859a-543f250f8bb2" } ``` ------ #### [ UpdateDataSet ] **UpdateDataSet** `UpdateDataSet` API オペレーションを使用して、既存のデータセットの RLS タグを追加または更新できます。 以下は、RLS タグを持つデータセットを更新する例です。これは、前述の物流会社のシナリオを想定しています。 ``` update-data-set --aws-account-id --data-set-id --name --physical-table-map [--logical-table-map ] --import-mode [--column-groups [--field-folders ] [--row-level-permission-data-set ] [--column-level-permission-rules ] [--cli-input-json ] [--generate-cli-skeleton ] [--row-level-permission-tag-configuration '{ "Status": "ENABLED", "TagRules": [ { "TagKey": "tag_retailer_id", "ColumnName": "retailer_id", "TagMultiValueDelimiter": ",", "MatchAllValue": "*" }, { "TagKey": "tag_role", "ColumnName": "role" } ], "TagRuleConfigurations": [ tag_retailer_id ], [ tag_role ] }' ] ``` 以下は、応答の定義の例です。 ``` { "Status": 201, "Arn": "arn:aws:quicksight:us-west-2:11112222333:dataset/RLS-Dataset", "DataSetId": "RLS-Dataset", "RequestId": "aa4f3c00-b937-4175-859a-543f250f8bb2" } ``` ------ **重要** データセットでタグが割り当てられ、有効になったら、ダッシュボードの作成時にデータセット内のデータを表示するアクセス許可を Quick authors に付与してください。 Quick authors にデータセット内のデータを表示するアクセス許可を付与するには、データセットルールとして使用するアクセス許可ファイルまたはクエリを作成します。詳細については、「[行レベルのセキュリティに対するデータセットルールの作成](restrict-access-to-a-data-set-using-row-level-security.md#create-data-set-rules-for-row-level-security)」を参照してください。 `RowLevelPermissionTagConfiguration` 要素の詳細については、*Amazon Quick API リファレンス*の[RowLevelPermissionTagConfiguration](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_RowLevelPermissionTagConfiguration.html)」を参照してください。 ## ステップ 2: ランタイム時に値を RLS タグに割り当てる RLS のタグは、匿名埋め込みにのみ使用できます。`GenerateEmbedUrlForAnonymousUser` API オペレーションを使用してタグの値を設定できます。 **重要** API コールでセッションタグを設定する場合、 セッションタグをセキュリティ認証情報として扱います。セッションタグをエンドユーザーまたはクライアント側のコードに公開しないでください。 サーバー側のコントロールを実装します。セッションタグは、エンドユーザーが変更できるパラメータではなく、信頼できるバックエンドサービスによってのみ設定されていることを確認してください。 セッションタグを列挙から保護します。あるテナントのユーザーが、他のテナントに属する sessionTag 値を検出または推測できないようにします。 アーキテクチャを確認します。ダウンストリームの顧客またはパートナーが API を直接呼び出すことが許可されている場合は、アクセスすべきでないテナントに sessionTag 値を指定できるかどうかを評価します。 以下の例は、前のステップでデータセットで定義された RLS タグに値を割り当てる方法を示しています。 ``` POST /accounts/AwsAccountId/embed-url/anonymous-user HTTP/1.1 Content-type: application/json { “AwsAccountId”: “string”, “SessionLifetimeInMinutes”: integer, “Namespace”: “string”, // The namespace to which the anonymous end user virtually belongs “SessionTags”: // Optional: Can be used for row-level security [ { “Key”: “tag_retailer_id”, “Value”: “West,Central,South” } { “Key”: “tag_role”, “Value”: “shift_manager” } ], “AuthorizedResourceArns”: [ “string” ], “ExperienceConfiguration”: { “Dashboard”: { “InitialDashboardId”: “string” // This is the initial dashboard ID the customer wants the user to land on. This ID goes in the output URL. } } } ``` 以下は、応答の定義の例です。 ``` HTTP/1.1 Status Content-type: application/json { "EmbedUrl": "string", "RequestId": "string" } ``` Quick でユーザーを登録しない RLS サポートは、 `GenerateEmbedUrlForAnonymousUser` API オペレーションでのみサポートされます。このオペレーションでは、`SessionTags` で、データセット列に関連付けられたタグの値を定義できます。 この場合、以下の割り当てが定義されています。 + `West`、`Central`、および `South` の各値は、ランタイム時に `tag_retailer_id` タグに割り当てられます。区切り文字には、データセットの `TagMultipleValueDelimiter` で定義されたカンマが使用されます。列でコール値を使用するには、値を、タグの作成時に `MatchAllValue` として定義された *\$1* に設定します。 + 値 `shift_manager` は `tag_role` タグに割り当てられます。 生成された URL を使用するユーザーは、`role` 列に値 `shift_manager` がある行のみを表示できます。このユーザーは、`retailer_id` 列の `West`、`Central`、または `South` 値のみを表示できます。 `GenerateEmbedUrlForAnonymousUser` API オペレーションを使用した匿名ユーザーのダッシュボードの埋め込みの詳細については、[匿名 (未登録) ユーザー向けの Amazon Quick Sight ダッシュボードの埋め込み](embedded-analytics-dashboards-for-everyone.md)「」または*「Amazon Quick API リファレンス*」の[GenerateEmbedUrlForAnonymousUser](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_GenerateEmbedUrlForAnonymousUser.html)」を参照してください。 # データセットへのアクセスを制限するために列レベルのセキュリティを使用する Quick の Enterprise Edition では、データセットに対する列レベルのセキュリティ (CLS) を設定することで、データセットへのアクセスを制限できます。CLS が有効なデータセットまたは分析では、制限対象の記号 ![\[The lock icon for CLS.\]](http://docs.aws.amazon.com/ja_jp/quick/latest/userguide/images/cls-restricted-icon.png) を横におきます。デフォルトでは、すべてのユーザーとグループにデータへのアクセス権があります。CLS を使用することにより、データセット内の特定の列へのアクセスを管理することができます。 アクセスできない CLS 制限のあるデータセットを含む分析またはダッシュボードを使用する場合、制限対象のフィールドを使用するビジュアルを作成、表示、または編集することはできません。ほとんどのビジュアルタイプでは、アクセス権のない制限対象の列がビジュアルに含まれている場合、そのビジュアルは分析やダッシュボードに表示されません。 テーブルとピボットテーブルの動作は異なります。テーブルまたはピボットテーブルで、**[Rows]** (行) または **[Columns]** (列) のフィールドウェルがあり、これらの制限対象の列にアクセスできない場合、分析やダッシュボードでビジュアルを表示できません。テーブルまたはピボットテーブルに、**[Values]** (値) フィールドで制限された列があると、アクセス可能な値のみを含む分析またはダッシュボードのテーブルが表示されます。制限対象の列の値は、[Not Authorized] (権限がありません) と表示されます。 分析またはダッシュボードで列レベルのセキュリティを有効にするには、管理者アクセス権が必要です。 **CLS で新しい分析を作成するには** 1. クイックスタートページで、**分析**タブを選択します。 1. 右上で **[New analysis]** (新しい分析) を選択します。 1. データセットを選択し、**[Column-level security]** (列レベルのセキュリティ) を選択します。 1. 制限する列を選択し、**[Next]** (次へ) を選択します。デフォルトでは、すべてのグループとユーザーがすべての列にアクセスできます。 1. 各列にアクセスできるユーザーを選択し、**[Apply]** (適用) を選択して変更を保存します。 **CLS の既存の分析を使用するには** 1. クイックスタートページで、**データ**タブを選択します。 1. データページで、データセットを開きます。 1. データセットの詳細ページが開くので、**[Column-level security]** (列レベルのセキュリティ) で **[Set up]** (セットアップ) を選択します。 1. 制限する列を選択し、**[Next]** (次へ) を選択します。デフォルトでは、すべてのグループとユーザーがすべての列にアクセスできます。 1. 各列にアクセスできるユーザーを選択し、**[Apply]** (適用) を選択して変更を保存します。 **CLS 付きのダッシュボードを作成するには** 1. クイックナビゲーションペインで、**分析**タブを選択します。 1. ダッシュボードを作成する分析を選択します。 1. 右上にある **[公開]** を選択します。 1. 次のいずれかを選択します。 + 新しいダッシュボードを作成するには、**[Publish new dashboard as]** (新しいダッシュボードに名前を付けて公開) を選択し、ダッシュボード名を入力します。 + **[Replace an existing dashboard]** (既存のダッシュボードを置き換える) を選択し、置き換えるダッシュボードを選択します。 さらに、**[Advanced publish options]** (高度な公開オプション) を選択します。詳細については、「[ダッシュボードの公開](creating-a-dashboard.md)」を参照してください。 1. **[ダッシュボードの公開]** を選択します。 1. (オプション) 次のいずれかを実行します。 + 共有せずにダッシュボードを公開するには、[**Share dashboard with users (ダッシュボードをユーザーと共有する)**] 画面が表示されたときに画面の右上にある [**x**] を選択します。アプリケーションバーから **[Share]** (共有) を選択すれば、いつでもダッシュボードを共有できます。 + 「[Amazon Quick Sight ダッシュボードの共有](sharing-a-dashboard.md)」の手順に従って、ダッシュボードを共有します。 # Amazon Quick での IAM ロールとしてのクエリの実行 Amazon Athena、Amazon Redshift または Amazon S3 に接続されたデータソースに対してより広範な許可を与えるのではなく、きめ細かなアクセスポリシーを使用することで、データセキュリティを強化できます。まず、ユーザーまたは API がクエリを開始したときにアクティブになる権限を持つ AWS Identity and Access Management (IAM) ロールを作成します。次に、クイック管理者または開発者が IAM ロールを Athena または Amazon S3 データソースに割り当てます。ロールを設定すると、クエリを実行するすべてのユーザーまたは API に、クエリを実行するのに必要な正確な権限が付与されます。 データセキュリティを強化するために run-as ロールの実装に取り掛かる前に、考慮すべき点がいくつかあります。 + 追加のセキュリティがどのように役立つかを明確にします。 + クイック管理者と協力して、データソースにロールを追加すると、セキュリティの目標や要件をより適切に満たすことができるかどうかを確認してください。 + データソース、関係する人、アプリケーションの数を考慮して、この種のセキュリティをチームで適切に文書化して管理できるかどうか尋ねてみてください。そうでない場合、その作業は誰が引き受けるのでしょうか？ + 構造化された組織では、運用、開発、IT サポートといった並列チームに関係者を配置します。彼らの経験、アドバイス、そしてあなたの計画をサポートしたいという意欲を求めてください。 + プロジェクトを開始する前に、データへのアクセスを必要とする人を対象とした概念実証を行うことを検討してください。 Athena、Amazon Redshift または Amazon S3 での run-as ロールの使用には、次のルールが適用されます。 + 各データソースには、1 つの RoleArn しか関連付けられません。通常、データセットやビジュアルにアクセスするデータソースの使用者は、さまざまな種類のクエリを生成できます。このロールは、どのクエリが機能するか、どのクエリが機能しないかについての境界を設定します。 + ARN は、それを使用するクイックインスタンス AWS アカウント と同じ の IAM ロールに対応する必要があります。 + IAM ロールには、Quick がロールを引き受けることを可能にする信頼関係が必要です。 + Quick の APIs を呼び出す ID には、 `RoleArn` プロパティを更新する前にロールを渡すアクセス許可が必要です。ロール ARN を作成または更新する場合にのみ、ロールを渡す必要があります。権限は後で再評価されません。同様に、ロール ARN を省略しても権限は不要です。 + ロール ARN を省略すると、Athena または Amazon S3 データソースはアカウント全体のロールとスコープダウンポリシーを使用します。 + ロール ARN が存在する場合、アカウント全体のロールとスコープダウンポリシーの両方が無視されます。Athena データソースの場合、Lake Formation 許可は無視されません。 + Amazon S3 データソースの場合、マニフェストファイルとマニフェストファイルによって指定されたデータの両方に、IAM ロールを使用してアクセスできる必要があります。 + ARN 文字列は、 AWS リージョン データが配置およびクエリされる AWS アカウント および の既存の IAM ロールと一致する必要があります。 Quick が の別のサービスに接続すると AWS、IAM ロールが使用されます。デフォルトでは、この詳細度の低いバージョンのロールは、使用するサービスごとに Quick によって作成され、ロールは AWS アカウント 管理者によって管理されます。カスタムのアクセス権限ポリシーを含む IAM ロール ARN を追加すると、追加の保護が必要なデータソースのより広範なロールがオーバーライドされます。ポリシーの詳細については、「IAM ユーザーガイド」の「[カスタマー管理ポリシーの作成](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_managed-policies.html)」を参照してください。 ## Athena データソースを使用してクエリを実行する API を使用して ARN を Athena データソースにアタッチします。これを実行するには、[AthenaParameters](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_AthenaParameters.html) の [RoleArn](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_RoleArn.html) プロパティにロール ARN を追加します。確認のために、**[Athena データソースを編集]** ダイアログボックスでロール ARN を表示できます。ただし、**[ロール ARN]** は読み取り専用フィールドです。 開始するには、カスタム IAM ロールが必要です。これを次の例で示します。 次のコード例は、学習のみを目的として提供されていることに注意してください。この例は、一時的な開発およびテスト環境でのみ使用し、本番環境では使用しないでください。この例のポリシーは、特定のリソースを保護しません。特定のリソースはデプロイ可能なポリシーに含まれている必要があります。また、開発のためにも独自の AWS アカウント情報を追加する必要があります。 次のコマンドは、シンプルな新しいロールを作成し、Quick にアクセス許可を付与するいくつかのポリシーをアタッチします。 ``` aws iam create-role \ --role-name TestAthenaRoleForQuickSight \ --description "Test Athena Role For QuickSight" \ --assume-role-policy-document '{ "Version": "2012-10-17" , "Statement": [ { "Effect": "Allow", "Principal": { "Service": "quicksight.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }' ``` 各データソースで使用する IAM ロールを特定または作成したら、attach-role-policy を使用してポリシーをアタッチします。 ``` aws iam attach-role-policy \ --role-name TestAthenaRoleForQuickSight \ --policy-arn arn:aws:iam::222222222222:policy/service-role/AWSQuickSightS3Policy1 aws iam attach-role-policy \ --role-name TestAthenaRoleForQuickSight \ --policy-arn arn:aws:iam::aws:policy/service-role/AWSQuicksightAthenaAccess1 aws iam attach-role-policy \ --role-name TestAthenaRoleForQuickSight \ --policy-arn arn:aws:iam::aws:policy/AmazonS3Access1 ``` アクセス許可を確認したら、新しいロールを作成するか、既存のロールを更新することで、クイックデータソースでロールを使用できます。これらのコマンドを使用する場合は、 AWS アカウント ID と を更新 AWS リージョン して独自のコマンドと一致させます。 これらのサンプルコードスニペットは本番環境向けではないことに注意してください。 AWS は、本番では、一連の最小特権ポリシーを特定して使用することを強くお勧めします。 ``` aws quicksight create-data-source --aws-account-id 222222222222 \ --region us-east-1 \ --data-source-id "athena-with-custom-role" \ --cli-input-json '{ "Name": "Athena with a custom Role", "Type": "ATHENA", "data sourceParameters": { "AthenaParameters": { "RoleArn": "arn:aws:iam::222222222222:role/TestAthenaRoleForQuickSight" } } }' ``` ## Amazon Redshift データソースを使用してクエリを実行する Amazon Redshift データを run-as ロールと接続して、きめ細かいアクセスポリシーでデータセキュリティを強化します。パブリックネットワークまたは VPC 接続を使用する Amazon Redshift データソース用の run-as ロールを作成できます。**[Amazon Redshift データソースの編集]** ダイアログボックスで使用する接続タイプを指定します。run-as ロールは、Amazon Redshift Serverless データソースはサポートされていません。 開始するには、カスタム IAM ロールが必要です。これを次の例で示します。次のコマンドは、新しいロールのサンプルを作成し、Quick にアクセス許可を付与するポリシーをアタッチします。 ``` aws iam create-role \ --role-name TestRedshiftRoleForQuickSight \ --description "Test Redshift Role For QuickSight" \ --assume-role-policy-document '{ "Version": "2012-10-17" , "Statement": [ { "Effect": "Allow", "Principal": { "Service": "quicksight.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }' ``` 各データソースで使用する IAM ロールを特定または作成したら、`attach-role-policy` を使用してポリシーをアタッチします。使用するロールに `redshift:GetClusterCredentialsWithIAM` アクセス許可がアタッチされている場合、 `DatabaseUser` と `DatabaseGroups` の値はオプションです。 ``` aws iam attach-role-policy \ --role-name TestRedshiftRoleForQuickSight \ --policy-arn arn:aws:iam:111122223333:policy/service-role/AWSQuickSightRedshiftPolicy aws iam create-policy --policy-name RedshiftGetClusterCredentialsPolicy1 \ --policy-document file://redshift-get-cluster-credentials-policy.json aws iam attach-role-policy \ --role-name TestRedshiftRoleForQuickSight \ --policy-arn arn:aws:iam:111122223333:policy/RedshiftGetClusterCredentialsPolicy1 // redshift-get-cluster-credentials-policy.json { "Version": "2012-10-17" , "Statement": [ { "Sid": "RedshiftGetClusterCredentialsPolicy", "Effect": "Allow", "Action": [ "redshift:GetClusterCredentials" ], "Resource": [ "*" ] } ] } ``` 上記の例では、`RoleARN`、`DatabaseUser`、`DatabaseGroups` の IAM パラメータを使用するデータソースを作成します。IAM `RoleARN` パラメータを介してのみ接続を確立する場合は、以下の例に示すように、 `redshift:GetClusterCredentialsWithIAM` アクセス許可をロールにアタッチします。 ``` aws iam attach-role-policy \ --role-name TestRedshiftRoleForQuickSight \ --policy-arn arn:aws:iam:111122223333:policy/RedshiftGetClusterCredentialsPolicy1 // redshift-get-cluster-credentials-policy.json { "Version": "2012-10-17" , "Statement": [ { "Sid": "RedshiftGetClusterCredentialsPolicy", "Effect": "Allow", "Action": [ "redshift:GetClusterCredentialsWithIAM" ], "Resource": [ "*" ] } ] }" ``` アクセス許可を確認したら、新しいロールを作成するか、既存のロールを更新することで、クイックデータソースでロールを使用できます。これらのコマンドを使用する場合は、 AWS アカウント ID と AWS リージョンを独自のものに合わせて更新します。 ``` aws quicksight create-data-source \ --region us-west-2 \ --endpoint https://quicksight.us-west-2.quicksight.aws.com/ \ --cli-input-json file://redshift-data-source-iam.json \ redshift-data-source-iam.json is shown as below { "AwsAccountId": "AWSACCOUNTID", "DataSourceId": "DATSOURCEID", "Name": "Test redshift demo iam", "Type": "REDSHIFT", "DataSourceParameters": { "RedshiftParameters": { "Database": "integ", "Host": "redshiftdemocluster.us-west-2.redshift.amazonaws.com", "Port": 8192, "ClusterId": "redshiftdemocluster", "IAMParameters": { "RoleArn": "arn:aws:iam::222222222222:role/TestRedshiftRoleForQuickSight", "DatabaseUser": "user", "DatabaseGroups": ["admin_group", "guest_group", "guest_group_1"] } } }, "Permissions": [ { "Principal": "arn:aws:quicksight:us-east-1:AWSACCOUNTID:user/default/demoname", "Actions": [ "quicksight:DescribeDataSource", "quicksight:DescribeDataSourcePermissions", "quicksight:PassDataSource", "quicksight:UpdateDataSource", "quicksight:DeleteDataSource", "quicksight:UpdateDataSourcePermissions" ] } ] } ``` データソースが VPC 接続タイプを使用している場合は、次の VPC 設定を使用してください。 ``` { "AwsAccountId": "AWSACCOUNTID", "DataSourceId": "DATSOURCEID", "Name": "Test redshift demo iam vpc", "Type": "REDSHIFT", "DataSourceParameters": { "RedshiftParameters": { "Database": "mydb", "Host": "vpcdemo.us-west-2.redshift.amazonaws.com", "Port": 8192, "ClusterId": "vpcdemo", "IAMParameters": { "RoleArn": "arn:aws:iam::222222222222:role/TestRedshiftRoleForQuickSight", "DatabaseUser": "user", "AutoCreateDatabaseUser": true } } }, "VpcConnectionProperties": { "VpcConnectionArn": "arn:aws:quicksight:us-west-2:222222222222:vpcConnection/VPC Name" }, "Permissions": [ { "Principal": "arn:aws:quicksight:us-east-1:222222222222:user/default/demoname", "Actions": [ "quicksight:DescribeDataSource", "quicksight:DescribeDataSourcePermissions", "quicksight:PassDataSource", "quicksight:UpdateDataSource", "quicksight:DeleteDataSource", "quicksight:UpdateDataSourcePermissions" ] } ] } ``` データソースが `redshift:GetClusterCredentialsWithIAM` アクセス許可を使用し、 `DatabaseUser` または `DatabaseGroups` パラメータを使用しない場合は、ロールにスキーマの一部またはすべてのテーブルへのアクセスを付与します。ロールに特定のテーブルへの `SELECT` アクセス許可が付与されているかどうかを確認するには、Amazon Redshift クエリエディタに次のコマンドを入力します。 ``` SELECT u.usename, t.schemaname||'.'||t.tablename, has_table_privilege(u.usename,t.tablename,'select') AS user_has_select_permission FROM pg_user u CROSS JOIN pg_tables t WHERE u.usename = 'IAMR:RoleName' AND t.tablename = tableName ``` Amazon Redshift クエリエディタの `SELECT` アクションの詳細については、「[SELECT](https://docs.aws.amazon.com/redshift/latest/dg/r_SELECT_synopsis.html)」を参照してください。 ロールに `SELECT` アクセス許可を付与するには、Amazon Redshift クエリエディタに次のコマンドを入力します。 ``` GRANT SELECT ON { [ TABLE ] table_name [, ...] | ALL TABLES IN SCHEMA schema_name [, ...] } TO "IAMR:Rolename"; ``` Amazon Redshift クエリエディタの `GRANT` アクションの詳細については、「[GRANT](https://docs.aws.amazon.com/redshift/latest/dg/r_GRANT.html)」を参照してください。 ## Amazon S3 データソースを使用してクエリを実行する Amazon S3 データソースには、Quick がデータの検索と解析に使用するマニフェストファイルが含まれています。クイックコンソールから JSON マニフェストファイルをアップロードすることも、S3 バケット内の JSON ファイルを指す URL を指定することもできます。URL を指定する場合は、Amazon S3 の ファイルにアクセスするためのアクセス許可が Quick に付与されている必要があります。クイック管理コンソールを使用して、マニフェストファイルとそれが参照するデータへのアクセスを制御します。 **RoleArn** プロパティを使用すると、アカウント全体のロールをオーバーライドするカスタム IAM ロールを通じて、マニフェストファイルとそれが参照するデータへのアクセスを付与できます。API を使用して、ARN を Amazon S3 データソースのマニフェストファイルにアタッチします。これを実行するには、[S3Parameters](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_S3Parameters.html) の [RoleArn](https://docs.aws.amazon.com/quicksight/latest/APIReference/API_RoleArn.html) プロパティにロール ARN を含めます。確認のために、**[S3 データソースを編集]** ダイアログボックスでロール ARN を表示できます。ただし、次のスクリーンショットに示すように、**[Role ARN]** (ロール ARN) は読み取り専用フィールドです。 開始するには、Amazon S3 マニフェストファイルを作成します。次に、新しい Amazon S3 データセットを作成するときに Amazon Quick にアップロードするか、データファイルを含む Amazon S3 バケットにファイルを配置できます。マニフェストファイルがどのようなものかを確認するには、次の例を参照してください。 ``` { "fileLocations": [ { "URIPrefixes": [ "s3://quicksightUser-run-as-role/data/" ] } ], "globalUploadSettings": { "format": "CSV", "delimiter": ",", "textqualifier": "'", "containsHeader": "true" } } ``` マニフェストファイルの作成方法については、「[Amazon S3 のマニフェストファイルでサポートされている形式](supported-manifest-file-format.md)」を参照してください。 マニフェストファイルを作成して Amazon S3 バケットに追加するか、クイックにアップロードしたら、`s3:GetObject`アクセス権を付与する IAM の既存のロールを作成または更新します。次の例は、 AWS API を使用して既存の IAM ロールを更新する方法を示しています。 ``` aws iam put-role-policy \ --role-name QuickSightAccessToS3RunAsRoleBucket \ --policy-name GrantS3RunAsRoleAccess \ --policy-document '{ "Version": "2012-10-17" , "Statement": [ { "Effect": "Allow", "Action": "s3:ListBucket", "Resource": "arn:aws:s3:::s3-bucket-name" }, { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::s3-bucket-name/manifest.json" }, { "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::s3-bucket-name/*" } ] }' ``` ポリシーによって `s3:GetObject` アクセスが付与されたら、Amazon S3 データソースのマニフェストファイルに更新された `put-role-policy` を適用するデータソースの作成を開始できます。 ``` aws quicksight create-data-source --aws-account-id 111222333444 --region us-west-2 --endpoint https://quicksight.us-west-2.quicksight.aws.com/ \ --data-source-id "s3-run-as-role-demo-source" \ --cli-input-json '{ "Name": "S3 with a custom Role", "Type": "S3", "DataSourceParameters": { "S3Parameters": { "RoleArn": "arn:aws:iam::111222333444:role/QuickSightAccessRunAsRoleBucket", "ManifestFileLocation": { "Bucket": "s3-bucket-name", "Key": "manifest.json" } } } }' ``` アクセス許可を確認したら、新しいロールを作成するか、既存のロールを更新することで、クイックデータソースでロールを使用できます。これらのコマンドを使用する場合は、必ず AWS アカウント ID と を更新 AWS リージョン して独自のコマンドと一致させてください。 # データセットの削除 **重要** 現在、データセットの削除は元に戻せず、元に戻すことができない作業損失が生じる可能性があります。削除は、依存オブジェクトを削除するためにカスケードしません。代わりに、削除されたデータセットを同一のデータセットに置き換える場合でも、依存オブジェクトは動作を停止します。 データセットを削除する前に、まず各依存分析またはダッシュボードに新しいデータセットを指定することが強く推奨されます。 現在、依存ビジュアルがまだ存在しているときにデータセットを削除した場合、それらのビジュアルを含む分析とダッシュボードには、新しいメタデータを同化する方法がありません。表示したままですが、機能できません。同一のデータセットを追加して修復することはできません。 これは、データセットに、そのデータセットに依存している分析とダッシュボードに不可欠な、メタデータが含まれているためです。このメタデータは、データセットごとに一意に生成されます。Quick Sight エンジンはメタデータを読み取ることができますが、人間が読み取ることはできません (たとえば、フィールド名は含まれません）。そのため、データセットの正確なレプリカには異なるメタデータがあります。各データセットのメタデータは、同じ名前とフィールドを共有する複数のデータセットであっても、一意です。 **データセットを削除するには** 1. 開始する前に、他のユーザーが引き続き使用したい分析やダッシュボードに、データセットが使用されていないことを確認します。 **データ**ページで、不要になったデータセットを選択します。次に、右上の **[Delete Dataset]** (データセットを削除) を選択します。 1. このデータセットが使用中であるという警告が表示された場合は、すべての依存分析とダッシュボードを追跡し、別のデータセットを指定します。これを実行できない場合は、削除するのではなく、以下のベストプラクティスを 1 つ以上試します。 + データセットの名前を変更し、データセットが明確に廃止されるようにします。 + データセットに行が追加されないよう、データをフィルタリングします。 + 他のすべてのユーザーによるデータセットへのアクセスを削除します。 できる手段をすべて使用して、依存オブジェクトの所有者にこのデータセットが廃止されることを通知します。また、アクションを実行するのに十分な時間を提供していることを確認してください。 1. データセットが削除された後に機能しなくなる依存オブジェクトがないことを確認したら、データセットを選択し、**[Delete Data Set]** (データセットの削除) を選択します。選択を確定するか、[**Cancel (キャンセル)**] を選択します。 **重要** 現在、データセットの削除は元に戻せず、元に戻すことができない作業損失が生じる可能性があります。削除は、依存オブジェクトを削除するためにカスケードしません。代わりに、削除されたデータセットを同一のデータセットに置き換える場合でも、依存オブジェクトは動作を停止します。 # 分析へのデータセットの追加 分析を作成したら、この分析にさらなるデータセットを追加できます。次に、これらのデータセットを使用して、さらに多くのビジュアルを作成できます。 分析内から、フィールドの追加や削除、またはその他のデータ準備の実行などの編集作業のために任意のデータセットを開くことができます。また、データセットの削除や置換を行うこともできます。 現在選択されているデータセットが **[データ]** ペインの上部に表示されます。これは、現在選択されているビジュアルで使用されているデータセットです。データセットは、ビジュアルごとに 1 つしか使用できません。別のビジュアルを選択すると、選択されているデータセットが、そのビジュアルで使用されているデータセットに変更されます。 選択されているデータセットを手動で変更するには、**[データ]** ペインの上部にあるデータセットリストを選択してから、別のデータセットを選択します。現在選択されているビジュアルがこのデータセットを使用しない場合、このビジュアルの選択が解除されます。次に、選択したデータセットを使用するビジュアルを選択します。または、**[ビジュアル]** ペインで **[追加]** を選択して、選択したデータセットを使用して新しいビジュアルを作成します。 ビジュアルの候補を表示するためにツールバーの **[Suggested]**] (推奨)を選択すると、現在選択されているデータセットに基づくビジュアルが表示されます。 [**Filter**] (フィルター) ペインに表示されるのは、現在選択されているデータセットに対するフィルターのみです。また、フィルターは現在選択されているデータセットに対してのみ作成できます。 **Topics** + [データセットの置き換え](replacing-data-sets.md) + [分析からデータセットを削除する](delete-a-data-set-from-an-analysis.md) 以下の手順を実行して、分析にデータセットを追加したり、分析で使用されているデータセットを編集したりします。 **分析にデータセットを追加するには** 1. 分析ページで、**[データ]** ペインに移動し、**[データセット]** ドロップダウンを展開します。 1. **[新しいデータセットの追加]** をクリックして、データセットを追加します。または、**[データセットを管理]** を選択してデータセットを編集します。データセットの編集に関する詳細については、「[データセットの編集](edit-a-data-set.md)」を参照してください。 1. データセットのリストが表示されます。データセットを選択して、**[Select]** (選択) をクリックします。キャンセルするには、**[Cancel]** (キャンセル) をクリックします。 # データセットの置き換え 分析では、データセットを追加、編集、置換、または削除できます。このセクションでは、データセットを置き換える方法について説明します。 データセットを置き換えるとき、ビジュアルを設計どおりに動作させるには、元の列を新しいデータセットに反映させる必要があります。データセットを置き換えると、分析の [undo (元に戻す)] や [redo (やり直す)] の履歴も消去されます。つまり、アプリケーションバーの [undo (元に戻す)] ボタンや [redo (やり直す)] ボタンを使用して変更間を移動できません。したがって、データセットを変更すると決めたら、分析の設計を、編集中の状態ではなく比較的安定した状態にすることが必要になります。 **データセットを置き換えるには** 1. 分析ページで、**[データ]** ペインに移動し、**[データセット]** ドロップダウンを展開します。 1. **[データセットを管理]** を選択します。 1. 置換するファイルの横にある省略記号 ([...]) をクリックし、**[置換]** を選択します。 1. [**Select replacement dataset (置き換えるデータセット)**] のページで、リストからデータセットを選択し、[**Select (選択)**] を選びます。 **注記** データセットを置き換えると、この分析の [undo] (元に戻す) と [redo] (やり直す) の履歴が消去されます。 データセットは新しいものに置き換えられます。フィールドリストとビジュアルは新しいデータセットで更新されます。 この時点で、新しいデータセットの追加、新しいデータセットの編集、または別のデータセットへの置換を選択できます。[**Close (閉じる)**] を選択して終了します。 ## 新しいデータセットが一致しない場合 場合によっては、選択した置換用データセットに、分析のビジュアル、フィルター、パラメータ、および計算フィールドで使用されているすべてのフィールドと階層が含まれていないことがあります。その場合、Quick Sight から、不一致または欠落している列のリストを示す警告が表示されます。 このような場合は、2 つのデータセット間のフィールドマッピングを更新できます。 **フィールドマッピングを更新するには** 1. [**Mismatch in replacement dataset (データセット置換のミスマッチ)**] のページで [**Update field mapping (フィールドマッピングの更新)**] を選択します。 1. [**Update field mapping (フィールドマッピングの更新)**] ページで、マッピングするフィールドのドロップダウンメニューを選択し、マッピング先のフィールドをリストから選択します。 新しいデータセットにフィールドが欠落している場合、[**Ignore this field (このフィールドを無視)**] を選択します。 1. [**Confirm (確認)**] を選択して更新を確認します。 1. [**Close (閉じる)**] を選択してページを閉じ、分析に戻ります。 データセットは新しいものに置き換えられます。フィールドリストとビジュアルは新しいデータセットで更新されます。 新しいデータセットにないフィールドを使用していたビジュアルは、空白に更新されます。ビジュアルにフィールドを再追加したり、分析からビジュアルを削除したりできます。 データセットを置き換えた後でも、変更したい場合は元に戻すことができます。例えば、データセットを置き換えた後で、新しいデータセットに合わせて分析を変更することが困難であるとわかったとします。分析に加えた変更はすべて元に戻すことができます。その後、新しいデータセットを元のものに置き換えるか、分析の要件によりよく一致するデータセットに置き換えることができます。 # 分析からデータセットを削除する 以下の手順に従って、分析からデータセットを削除します。 **分析からデータセットを削除する** 1. 分析ページで、**[データ]** ペインに移動し、**[データセット]** ドロップダウンを展開します。 1. **[データセットを管理]** を選択します。 1. 削除するファイルの横にある省略記号 ([...]) をクリックし、**[削除]** を選択します。分析のデータセットが 1 つのみである場合、これを削除することはできません。 1. **[Close]** (閉じる) を選択してダイアログボックスを閉じます。