翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS Entity Resolution 用語集 ## Amazon リソースネーム (ARN) AWS リソースの一意の識別子。ARNs は、 AWS Entity Resolution ポリシー、Amazon Relational Database Service (Amazon RDS) タグ AWS Entity Resolution、API コールなど、すべての でリソースを明確に指定する必要がある場合に必要です。 ## 属性タイプ 入力フィールドの属性のタイプ。[スキーママッピングを作成する](create-schema-mapping.md)ときは、**名前**、**住所**、**電話番号**、**E メールアドレス**などの事前設定された値のリストから**属性タイプ**を選択します。属性タイプは、表示するデータ AWS Entity Resolution の種類を指定し、適切に分類および正規化できるようにします。 ## 自動処理 データ入力が変更されたときに自動的に実行できるようにする、一致するワークフロージョブの処理頻度オプション。 このオプションは、[ルールベースのマッチング](#rule-based-matching-defn)でのみ使用できます。 デフォルトでは、一致するワークフロージョブの処理頻度は[**手動**](#manual-processing)に設定されます。これにより、オンデマンドで実行できます。データ入力が変更されると、一致するワークフロージョブを自動的に実行するように**自動**処理を設定できます。これにより、一致するワークフロー出力up-to-date状態になります。 ## AWS KMS key ARN これは、保管時の暗号化用の AWS KMS Amazon リソースネーム (ARN) です。指定しない場合、システムは AWS Entity Resolution マネージド KMS キーを使用します。 ## バッチワークフロー スケジュールされた間隔で実行され、データセット全体のデータを照合して解決するプロセス。のバッチワークフロー AWS Entity Resolution は、初期設定、定期的なフル更新、ソースデータセットとターゲットデータセットの両方に大きな変更があるシナリオに最適です。 ## クリアテキスト 暗号化で保護されていないデータ。 ## 信頼レベル (ConfidenceLevel) ML マッチングの場合、ML が一致するレコードセットを識別する AWS Entity Resolution ときに によって適用される信頼レベルです。これは、出力に含まれる[一致するワークフローメタデータ](#matching-workflow-metadata)の一部です。 ## 復号 暗号化されたデータを元の形式に戻すプロセスです。復号化は、シークレットキーにアクセスできる場合にのみ実行できます。 ## 暗号化 キーと呼ばれる秘密の値を使用して、データをランダムに見える形式にエンコードするプロセスです。キーにアクセスしない限り、元のプレーンテキストを特定することはできません。 ## グループ名 **グループ名**は入力フィールドのグループ全体を参照し、解析されたデータを一致する目的でグループ化するのに役立ちます。 例えば、、**first\$1name**、および の 3 つの入力フィールドがある場合**last\$1name**、一致と出力**full\$1name**のために として**グループ名**を入力して**middle\$1name**、それらをグループ化できます。 ## ハッシュ ハッシュとは、固定サイズの不可逆的で一意の文字列を生成する暗号化アルゴリズムを適用することを意味します。これは hash. AWS Entity Resolution uses Secure Hash Algorithm 256-bit (SHA256) ハッシュプロトコルと呼ばれ、32 バイトの文字列を出力します。では AWS Entity Resolution、出力でデータ値をハッシュするかどうかを選択できます。 ## ハッシュプロトコル (HashingProtocol) AWS Entity Resolution は Secure Hash Algorithm 256 ビット (SHA256) ハッシュプロトコルを使用し、32 バイトの文字列を出力します。これは、出力に含まれる[一致するワークフローメタデータ](#matching-workflow-metadata)の一部です。 ## ID マッピング方法 ID マッピングの実行方法。 ID マッピングには 2 つの方法があります。 + ルールベース – 一致するルールを使用して、ID マッピングワークフローのソースからターゲットにファーストパーティデータを変換する方法。 + プロバイダーサービス – プロバイダーサービスを使用して、ID マッピングワークフローでサードパーティーでエンコードされたデータをソースからターゲットに変換する方法。 AWS Entity Resolution は現在、プロバイダーのサービスベースの ID マッピング方法として LiveRamp をサポートしています。この方法 AWS Data Exchange を使用するには、 を通じて LiveRamp へのサブスクリプションが必要です。詳細については、「[ステップ 1: でプロバイダーサービスをサブスクライブする AWS Data Exchange](prepare-third-party-input-data.md#subscribe-provider-service)」を参照してください。 ## ID マッピングワークフロー 指定された ID マッピング方法に基づいて、入力データソースから入力データターゲットにデータをマッピングするデータ処理ジョブ。これにより、ID マッピングテーブルが生成されます。このワークフローでは、[ID マッピング方法](#id-mapping-method-defn)と、ソースからターゲットに変換する入力データを指定する必要があります。 ID マッピングワークフローを設定して、独自の または 2 つの AWS アカウント で実行できます AWS アカウント。 ## ID 名前空間 複数の AWS アカウント データセットを説明するメタデータと、[ID マッピングワークフロー](#id-mapping-workflow-defn)でこれらのデータセットを使用する方法 AWS Entity Resolution を含む のリソース。 ID 名前空間には、 `SOURCE`と の 2 種類があります`TARGET`。には、ID マッピングワークフローで処理されるソースデータの設定`SOURCE`が含まれています。には、すべてのソースが解決されるターゲットデータの設定`TARGET`が含まれています。2 つの で解決する入力データを定義するには AWS アカウント、ID 名前空間ソースと ID 名前空間ターゲットを作成して、データを 1 つのセット (`SOURCE`) から別のセット () に変換します`TARGET`。 自分と別のメンバーが ID 名前空間を作成し、ID マッピングワークフローを実行したら、 でコラボレーションに参加 AWS Clean Rooms して、ID マッピングテーブルでマルチテーブル結合を実行し、データを分析できます。 詳細については、「[AWS Clean Rooms ユーザーガイド](https://docs.aws.amazon.com/clean-rooms/latest/userguide/what-is.html)」を参照してください。 ## 増分ワークフロー データセット全体を処理するのではなく、前回の実行以降に新規または更新されたレコードのみを照合して解決するプロセス。の増分ワークフロー AWS Entity Resolution は、データセットのごく一部のみが変更されたときにデータの鮮度を維持するための頻繁な更新に最適です。 ## 入力フィールド 入力フィールドは、 AWS Glue 入力データテーブルの列名に対応します。 ## 入力ソース ARN (InputSourceARN) AWS Glue テーブル入力用に生成された Amazon リソースネーム (ARN)。これは、出力に含まれる[一致するワークフローメタデータ](#matching-workflow-metadata)の一部です。 ## 機械学習ベースのマッチング 機械学習ベースのマッチング (ML マッチング) は、不完全なデータやまったく同じように見えないデータ間で一致を検索します。ML マッチングは、入力したすべてのデータのレコードを照合しようとするプリセットプロセスです。ML マッチングは、[一致したデータセットごとに一致 ID](#match-id-defin) と[信頼レベル](#confidence-level-defn)を返します。 ## 手動処理 オンデマンドで実行できるようにする、一致するワークフロージョブの処理頻度オプション。 このオプションはデフォルトで設定され、[ルールベースのマッチング](#rule-based-matching-defn)と[機械学習ベースのマッチング](#ml-matching-defn)の両方で使用できます。 ## Many-to-Manyマッチング Many-to-manyマッチングは、類似データの複数のインスタンスを比較します。同じ一致キーが割り当てられた入力フィールドの値は、同じ入力フィールドにあるか異なる入力フィールドにあるかに関係なく、互いに照合されます。 たとえば、 `mobile_phone`や など、同じ一致キー「Phone`home_phone`」を持つ複数の電話番号入力フィールドがあるとします。many-to-manyマッチングを使用して、`mobile_phone`入力フィールドのデータと`mobile_phone`入力フィールドのデータおよび`home_phone`入力フィールドのデータを比較します。 一致ルールは、 (または) オペレーションで同じ一致キーを持つ複数の入力フィールドのデータを評価し、one-to-many一致は複数の入力フィールドの値を比較します。つまり、2 つのレコード間で `mobile_phone`または の組み合わせ`home_phone`が一致した場合、「電話」一致キーは一致を返します。一致を見つけるための一致キー「Phone」の場合は、`Record One mobile_phone = Record Two mobile_phone`OR `Record One mobile_phone = Record Two home_phone` OR `Record One home_phone = Record Two home_phone` OR です`Record One home_phone = Record Two mobile_phone`。 ## 一致 ID (MatchID) ルールベースのマッチングと ML マッチングの場合、これは によって生成 AWS Entity Resolution され、一致する各レコードセットに適用される ID です。これは、出力に含まれる[一致するワークフローメタデータ](#matching-workflow-metadata)の一部です。 ## 一致キー (MatchKey) 一致キーは、 AWS Entity Resolution どの入力フィールドを類似データと見なし、どの入力フィールドを異なるデータと見なすかを指示します。これにより、ルールベースのマッチングルール AWS Entity Resolution を自動的に設定し、異なる入力フィールドに保存されている同様のデータを比較できます。 `mobile_phone` 入力フィールドや`home_phone`入力フィールドなど、比較するデータに複数のタイプの電話番号情報がある場合は、両方の一致キー「Phone」を指定できます。次に、ルールベースの一致を設定して、すべての入力フィールドの「または」ステートメントと「電話」一致キーを使用してデータを比較できます ([「一致ワークフロー」セクションのOne-to-One の一致](#one-to-one-matching-defn)と[Many-to-Many一致の定義](#many-to-many-defin)」を参照してください）。 ルールベースのマッチングで異なるタイプの電話番号情報を個別に考慮する場合は、「Mobile\$1Phone」や「Home\$1Phone」などのより具体的なマッチングキーを作成できます。次に、一致するワークフローを設定するときに、各電話一致キーをルールベースのマッチングで使用する方法を指定できます。 特定の入力フィールドに MatchKey が指定されていない場合、マッチングには使用できませんが、マッチングワークフロープロセスを通じて実行でき、必要に応じて出力できます。 ## 一致キー名 一致キーに割り当てられた名前。 ## 一致ルール (MatchRule) ルールベースのマッチングの場合、これは、一致したレコードセットを生成するために適用されたルール番号です。これは、出力に含まれる[一致するワークフローメタデータ](#matching-workflow-metadata)の一部です。 ## 一致 さまざまな入力フィールド、テーブル、またはデータベースのデータを組み合わせて比較し、特定の一致基準を満たす (例えば、一致するルールやモデルを通じて) ことに基づいて、どちらが類似しているか、または「一致する」かを判断するプロセス。 ## マッチングワークフロー 一致する入力データとマッチングの実行方法を指定するように設定したプロセス。 ## 一致するワークフローの説明 入力することを選択できる、一致するワークフローのオプションの説明。説明は、複数のワークフローを作成する場合、一致するワークフローを区別するのに役立ちます。 ## 一致するワークフロー名 指定した一致するワークフローの名前。 **注記** 一致するワークフロー名は一意である必要があります。同じ名前にすることはできません。そうしないと、エラーが返されます。 ## ワークフローメタデータの一致 一致するワークフロージョブ AWS Entity Resolution 中に によって生成および出力される情報。この情報は出力時に必要です。 ## 正規化 (ApplyNormalization) スキーマで定義されているように入力データを正規化するかどうかを選択します。正規化は、余分なスペースや特殊文字を削除し、小文字の形式に標準化することで、データを標準化します。 たとえば、入力フィールドの属性タイプが[フルフォン](#normalization-rule-phone)で、入力テーブルの値が の形式である場合`(123) 456-7890`、 AWS Entity Resolution は値を に正規化します`1234567890`。 **注記** 正規化は、[名前](#normalization-rule-name)、[住所](#normalization-rule-address)、[電話番号](#normalization-rule-phone)、E [メール](#normalization-rule-email)のグループタイプでのみサポートされます。 以下のセクションでは、標準の正規化ルールについて説明します。 ML ベースのマッチングについては、「」を参照してください[正規化 (ApplyNormalization) – ML ベースのみ](#normalization-ML-defn)。 **Topics** + [名前](#normalization-rule-name) + [E メール](#normalization-rule-email) + [電話](#normalization-rule-phone) + [Address](#normalization-rule-address) + [ハッシュ](#normalization-rule-hashed) + [Source\$1ID](#normalization-rule-source-id) ### 名前 **注記** 正規化は**名前**グループタイプでのみサポートされています。 **名前**グループタイプは、コンソールでは**フルネーム**として、API `NAME` では として表示されます。 Name ****グループタイプのサブタイプを正規化する場合: コンソールで、**フルネーム**グループに名****、**ミドルネーム**、**姓**のサブタイプを割り当てます。 [CreateSchemaMapping](https://docs.aws.amazon.com/entityresolution/latest/apireference/API_CreateSchemaMapping.html) API で、`NAME`**groupName** に次の**タイプ**を割り当てます: `NAME_FIRST`、`NAME_MIDDLE`、`NAME_LAST`。 + **TRIM** = 先頭と末尾の空白をトリミングする + **LOWERCASE** = すべてのアルファ文字を小文字にします + **CONVERT\$1ACCENT** = Covert アクセント付き文字から通常の文字へ + **REMOVE\$1ALL\$1NON\$1ALPHA **= 英数字以外の文字をすべて削除します [a-zA-Z] ### E メール **注記** 正規化は E **メール**グループタイプでサポートされています。 E **メール**グループタイプは、コンソールには **E メールアドレス**として、API `EMAIL_ADDRESS` には として表示されます。 + **TRIM **= 先頭と末尾の空白をトリミングする + **LOWERCASE** = すべてのアルファ文字を小文字にします + **CONVERT\$1ACCENT** = Covert アクセント付き文字から通常の文字へ + **EMAIL\$1ADDRESS\$1UTIL\$1NORM** = ユーザー名からドット (.) を削除し、ユーザー名のプラス記号 (\$1) の後にすべてを削除し、一般的なドメインバリエーションを標準化します。 + **REMOVE\$1ALL\$1NON\$1EMAIL\$1CHARS **= non-alpha-numeric文字 [a-zA-Z0-9] と [.@-] をすべて削除します ### 電話 **注記** 正規化は、**電話**グループタイプでのみサポートされています。 **電話**グループタイプは、コンソールでは**フルフォン**として、API `PHONE` では として表示されます。 **電話**グループタイプのサブタイプを正規化する場合: コンソールで、**完全な電話**グループに**電話番号**と**電話の国コード**のサブタイプを割り当てます。 [CreateSchemaMapping](https://docs.aws.amazon.com/entityresolution/latest/apireference/API_CreateSchemaMapping.html) API で、次の**タイプ**を `PHONE` **groupName** `PHONE_NUMBER`と に割り当てます`PHONE_COUNTRYCODE`。 + **TRIM** = 先頭と末尾の空白をトリミングする + **REMOVE\$1ALL\$1NON\$1NUMERIC** = 数値以外の文字をすべて削除します [0-9] + **REMOVE\$1ALL\$1LEADING\$1ZEROES** = 先頭のゼロをすべて削除します + **EN"\$1PREFIX\$1WITH\$1MAP, "phonePrefixMap"** = 各電話番号を調べ、phonePrefixMap のパターンと照合しようとします。一致が見つかった場合、ルールは電話番号のプレフィックスを追加または変更して、マップで指定された標準化された形式に準拠していることを確認します。 ### Address **注記** 正規化は**、アドレス**グループタイプでのみサポートされています。 **アドレス**グループタイプは、コンソールには**フルアドレス**として、API `ADDRESS ` にはフルアドレスとして表示されます。 **Address** グループタイプのサブタイプを正規化する場合: コンソールで、**フルアドレス**グループに次のサブタイプを割り当てます。**住所 1**、**住所 2**: **住所 3 名**、**市名**、**州**、**国**、**郵便番号** t [CreateSchemaMapping](https://docs.aws.amazon.com/entityresolution/latest/apireference/API_CreateSchemaMapping.html) API で、`ADDRESS`**groupName** に次の**タイプ**を割り当てます: `ADDRESS_STREET1`、`ADDRESS_STREET2`、`ADDRESS_STREET3`、、`ADDRESS_CITY``ADDRESS_STATE``ADDRESS_COUNTRY`、、。 `ADDRESS_POSTALCODE` + **TRIM** = 先頭と末尾の空白をトリミングする + **LOWERCASE** = すべてのアルファ文字を小文字にします + **CONVERT\$1ACCENT** = Covert アクセント付き文字から通常の文字へ + **REMOVE\$1ALL\$1NON\$1ALPHA **= アルファベット以外の文字をすべて削除します [a-zA-Z] + **ADDRESS\$1RENAME\$1WORD\$1MAP を使用した RENAME\$1WORDS** = Address 文字列の単語を[ ADDRESS\$1RENAME\$1WORD\$1MAP](#ADDRESS_RENAME_WORD_MAP) の単語に置き換える + **ADDRESS\$1RENAME\$1DELIMITER\$1MAP を使用する RENAME\$1DELIMITERS** = Address 文字列の区切り文字を [ADDRESS\$1RENAME\$1DELIMITER\$1MAP](#ADDRESS_RENAME_DELIMITER_MAP) の文字列に置き換えます + **ADDRESS\$1RENAME\$1DIRECTION\$1MAP を使用する RENAME\$1DIRECTIONS**= Address 文字列の区切り文字を [ADDRESS\$1RENAME\$1DIRECTION\$1MAP](#ADDRESS_RENAME_DIRECTION_MAP) の文字列に置き換えます + **ADDRESS\$1RENAME\$1NUMBER\$1MAP を使用する RENAME\$1NUMBERS** = Address 文字列の数値を [ADDRESS\$1RENAME\$1NUMBER\$1MAP](#ADDRESS_RENAME_NUMBER_MAP.title) の文字列に置き換えます + **ADDRESS\$1RENAME\$1SPECIAL\$1CHAR\$1MAP を使用する RENAME\$1SPECIAL\$1CHARS** = Address 文字列の特殊文字を [ADDRESS\$1RENAME\$1SPECIAL\$1CHAR\$1MAP](#ADDRESS_RENAME_SPECIAL_CHAR_MAP.title) の文字列に置き換えます #### ADDRESS\$1RENAME\$1WORD\$1MAP これらは、アドレス文字列を正規化するときに名前が変更される単語です。 ``` "avenue": "ave", "bouled": "blvd", "circle": "cir", "circles": "cirs", "court": "ct", "centre": "ctr", "center": "ctr", "drive": "dr", "freeway": "fwy", "frwy": "fwy", "highway": "hwy", "lane": "ln", "parks": "park", "parkways": "pkwy", "pky": "pkwy", "pkway": "pkwy", "pkwys": "pkwy", "parkway": "pkwy", "parkwy": "pkwy", "place": "pl", "plaza": "plz", "plza": "plz", "road": "rd", "square": "sq", "squ": "sq", "sqr": "sq", "street": "st", "str": "st", "str.": "strasse" ``` #### ADDRESS\$1RENAME\$1DELIMITER\$1MAP これらは、アドレス文字列を正規化するときに名前が変更される区切り文字です。 ``` ",": " ", ".": " ", "[": " ", "]": " ", "/": " ", "-": " ", "#": " number " ``` #### ADDRESS\$1RENAME\$1DIRECTION\$1MAP これらは、アドレス文字列を正規化するときに名前が変更される方向識別子です。 ``` "east": "e", "north": "n", "south": "s", "west": "w", "northeast": "ne", "northwest": "nw", "southeast": "se", "southwest": "sw" ``` #### ADDRESS\$1RENAME\$1NUMBER\$1MAP これらは、アドレス文字列を正規化するときに名前が変更される数値文字列です。 ``` "número": "number", "numero": "number", "no": "number", "núm": "number", "num": "number" ``` #### ADDRESS\$1RENAME\$1SPECIAL\$1CHAR\$1MAP これらは、アドレス文字列を正規化するときに名前が変更される特殊文字文字列です。 ``` "ß": "ss", "ä": "ae", "ö": "oe", "ü": "ue", "ø": "o", "æ": "ae" ``` ### ハッシュ + **TRIM** = 先頭と末尾の空白をトリミングする ### Source\$1ID + **TRIM** = 先頭と末尾の空白をトリミングする ## 正規化 (ApplyNormalization) – ML ベースのみ スキーマで定義されているように入力データを正規化するかどうかを選択します。正規化は、余分なスペースや特殊文字を削除し、小文字の形式に標準化することで、データを標準化します。 たとえば、入力フィールドの属性タイプが で`NAME`、入力テーブルの値が の形式である場合`Johns Smith`、 AWS Entity Resolution は値を に正規化します`john smith`。 以下のセクションでは、[機械学習ベースのマッチングワークフロー](#ml-matching-defn)の正規化ルールについて説明します。 **Topics** + [名前](#normalization-ML-defn-name) + [E メール](#normalization-ML-defn-email) + [電話](#normalization-ML-defn-phone) ### 名前 + **TRIM** = 先頭と末尾の空白をトリミングする + **LOWERCASE** = すべてのアルファ文字を小文字にします ### E メール + **LOWERCASE** = すべてのアルファ文字を小文字にします + (at)(大文字と小文字を区別) のみを @ 記号に置き換えます + 値内の任意の場所にあるすべての空白を削除します。 + 存在する`"<``>"`場合、最初の の外部にあるものをすべて削除します ### 電話 + **TRIM** = 先頭と末尾の空白をトリミングする + **REMOVE\$1ALL\$1NON\$1NUMERIC** = 数値以外の文字をすべて削除します [0～9] + **REMOVE\$1ALL\$1LEADING\$1ZEROES** = 先頭のゼロをすべて削除します + **EN"\$1PREFIX\$1WITH\$1MAP, "phonePrefixMap"** = 各電話番号を調べ、phonePrefixMap のパターンと照合しようとします。一致が見つかった場合、ルールは電話番号のプレフィックスを追加または変更して、マップで指定された標準化された形式に準拠していることを確認します。 ## One-to-Oneマッチング One-to-one のマッチングは、類似データの単一インスタンスを比較します。同じ入力フィールド内の同じ一致キーと値を持つ入力フィールドは、互いに照合されます。 たとえば、 `mobile_phone`や など、同じ一致キー「Phone`home_phone`」を持つ複数の電話番号入力フィールドがあるとします。one-to-oneのマッチングを使用して、`mobile_phone`入力フィールド内のデータと`mobile_phone`入力フィールド内のデータを比較し、`home_phone`入力フィールド内のデータと`home_phone`入力フィールド内のデータを比較します。`mobile_phone` 入力フィールドのデータは、`home_phone`入力フィールドのデータと比較されません。 一致ルールは、 (または) オペレーションで同じ一致キーを持つ複数の入力フィールドのデータを評価し、one-to-many一致は 1 つの入力フィールド内の値を比較します。つまり、2 つのレコード間で `mobile_phone`または `home_phone`が一致すると、「電話」一致キーは一致を返します。一致を見つけるための一致キー「Phone」の場合は、 `Record One mobile_phone = Record Two mobile_phone` または `Record One home_phone = Record Two home_phone`。 一致ルールは、 (および) オペレーションで異なる一致キーを持つ入力フィールドのデータを評価します。ルールベースのマッチングで異なるタイプの電話番号情報を個別に考慮する場合は、「mobile\$1phone」や「home\$1phone」などのより具体的なマッチングキーを作成できます。ルールで両方の一致キーを使用して一致を検索する場合は、 `Record One mobile_phone = Record Two mobile_phone` AND `Record One home_phone = Record Two home_phone`。 ## Output **OutputAttribute** オブジェクトのリスト。各オブジェクトには**名前**と**ハッシュという**フィールドがあります。これらの各オブジェクトは、 AWS Glue 出力テーブルに含める列と、列内の値をハッシュするかどうかを表します。 ## OutputS3Path AWS Entity Resolution が出力テーブルを書き込む S3 送信先。 ## OutputSourceConfig OutputSource オブジェクトのリスト。各オブジェクトには **OutputS3Path****ApplyNormalization**、**および Output** フィールドがあります。 ## プロバイダーのサービスベースのマッチング プロバイダーのサービスベースのマッチングは、優先データサービスプロバイダーとライセンスデータセットを使用してレコードを照合、リンク、強化するプロセスです。このマッチング手法を使用するには、プロバイダーサービス AWS Data Exchange で のサブスクリプションが必要です。 AWS Entity Resolution は現在、次のデータサービスプロバイダーと統合されています。 + LiveRamp + TransUnion + UID 2.0 ## ルールベースのマッチング ルールベースのマッチングは、完全一致を見つけるように設計されたプロセスです。ルールベースのマッチングは、ウォーターフォールマッチングルールの階層的なセットであり、入力したデータに基づいて提案され AWS Entity Resolution、ユーザーが完全に設定可能です。ルール条件内で提供されるすべての一致キーは、比較データを一致と宣言し、関連するメタデータを出力するために完全に一致する必要があります。ルールベースの一致は、[一致したデータセットごとに一致 ID](#match-id-defin) とルール番号を返します。 エンティティを一意に識別できるルールを定義することをお勧めします。ルールを順序付けして、より正確な一致を最初に見つけます。 たとえば、ルール **1 **とルール 2 の **2 つのルール**があるとします。 これらのルールには、次の一致キーがあります。 + **ルール 1** にはフルネームと住所が含まれます + **ルール 2** にはフルネーム、住所、電話番号が含まれます **ルール 1 **が最初に実行されるため、すべて**ルール 1 で見つかったはずであるため、ルール 2** ****では一致は見つかりません。 電話によって区別される一致を検索するには、次のようにルールの順序を変更します。 + **ルール 2** にはフルネーム、住所、電話番号が含まれます + **ルール 1** にはフルネームと住所が含まれます ## Schema 一連のデータの編成と接続方法を定義する構造またはレイアウトに使用される用語。 ## スキーマの説明 入力できるスキーマのオプションの説明。説明は、複数のスキーマを作成する場合にスキーママッピングを区別するのに役立ちます。 ## スキーマ名 スキーマの名前。 **注記** スキーマ名は一意である必要があります。同じ名前にすることはできません。そうしないと、エラーが返されます。 ## スキーママッピング のスキーママッピング AWS Entity Resolution は、マッチングのためにデータを解釈 AWS Entity Resolution する方法を指示するプロセスです。一致するワークフローに AWS Entity Resolution 読み込む入力データテーブルのスキーマを定義します。 ## スキーママッピング ARN [スキーママッピング](#schema-mapping-definition)用に生成された Amazon リソースネーム (ARN)。 ## 一意の ID 指定した一意の識別子で、 が AWS Entity Resolution 読み取る入力データの各行に割り当てる必要があります。 **Example** たとえば、**Primary\$1key**、**Row\$1ID**、または **Record\$1ID** などです。 **Unique ID** 列は必須です。 **一意の ID** は、単一のテーブル内の一意の識別子である必要があります。 **一意の ID ** はこのパターンを満たす必要があります。 `[a-zA-Z0-9_-]` 異なるテーブル間で、**一意の ID** に重複した値を含めることができます。 [一致するワークフロー](#matching-workflow-definition)の**一意の ID ** の最大長は 38 です の**一意の ID ** の最大長 257 文字 [ID マッピングワークフロー](#id-mapping-workflow-defn) [一致するワークフロー](#matching-workflow-definition)が実行されると、**一意の ID** が次の場合、レコードは拒否されます。 + が指定されていない + は同じテーブル内で一意ではありません + ソース間で属性名の点で重複する + が 38 文字を超えている (ルールベースのマッチングワークフローのみ)