AWS Entity Resolution 用語集 - AWS Entity Resolution
Amazon リソースネーム (ARN)属性タイプ自動処理AWS KMS key ARNクリアテキスト信頼レベル (ConfidenceLevel)復号Encryptionグループ名ハッシュハッシュプロトコル (HashingProtocol)ID マッピング方法ID マッピングワークフローID 名前空間入力フィールド入力ソース ARN (InputSourceARN)機械学習ベースのマッチング手動処理Many-to-Manyマッチング一致 ID (MatchID)一致キー (MatchKey)一致キー名一致ルール (MatchRule)一致マッチングワークフロー一致するワークフローの説明一致するワークフロー名ワークフローメタデータの一致正規化 (ApplyNormalization)正規化 (ApplyNormalization) – ML ベースのみOne-to-OneマッチングOutputOutputS3PathOutputSourceConfigプロバイダーのサービスベースのマッチングルールベースのマッチングSchemaスキーマの説明スキーマ名スキーママッピングスキーママッピング ARN一意の ID

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Entity Resolution 用語集

Amazon リソースネーム (ARN)

AWS リソースの一意の識別子。ARNs は、 AWS Entity Resolution ポリシー、Amazon Relational Database Service (Amazon RDS) タグ AWS Entity Resolution、API コールなど、すべての でリソースを明確に指定する必要がある場合に必要です。

属性タイプ

入力フィールドの属性のタイプ。スキーママッピングを作成するときは、名前、住所、電話番号、E メールアドレスなどの事前設定された値リストから属性タイプを選択します。属性タイプは、提示するデータ AWS Entity Resolution の種類を に伝え、適切に分類および正規化できるようにします。

自動処理

一致するワークフロージョブの処理頻度オプション。データ入力が変更されたときに で自動的に実行できます。

このオプションは、ルールベースのマッチングでのみ使用できます。

デフォルトでは、一致するワークフロージョブの処理頻度は手動に設定されます。これにより、オンデマンドで実行できます。データ入力が変更されたときに、一致するワークフロージョブを自動的に実行するように自動処理を設定できます。これにより、一致するワークフロー出力up-to-date状態になります。

AWS KMS key ARN

これは、保管時の暗号化用の AWS KMS Amazon リソースネーム (ARN) です。指定しない場合、システムは AWS Entity Resolution マネージド KMS キーを使用します。

クリアテキスト

暗号的に保護されていないデータ。

信頼レベル (ConfidenceLevel)

ML マッチングの場合、これは ML が一致したレコードセットを識別する AWS Entity Resolution ときに によって適用される信頼レベルです。これは、出力に含まれる一致するワークフローメタデータの一部です。

復号

暗号化されたデータを元の形式に戻すプロセスです。復号化は、シークレットキーにアクセスできる場合にのみ実行できます。

Encryption

キーと呼ばれる秘密の値を使用して、データをランダムに見える形式にエンコードするプロセスです。キーにアクセスしない限り、元のプレーンテキストを特定することはできません。

グループ名

グループ名は入力フィールドのグループ全体を参照し、解析されたデータをグループ化して一致させるのに役立ちます。

例えば、、first_name、 middle_nameの 3 つの入力フィールドがある場合last_name、グループ名に一致と出力full_nameの と入力することで、それらをグループ化できます。

ハッシュ

ハッシュとは、固定サイズの不可逆的で一意の文字列を生成する暗号化アルゴリズムを適用することを意味します。これは hash. AWS Entity Resolution uses Secure Hash Algorithm 256-bit (SHA256) ハッシュプロトコルと呼ばれ、32 バイトの文字列を出力します。では AWS Entity Resolution、出力でデータ値をハッシュするかどうかを選択できます。

ハッシュプロトコル (HashingProtocol)

AWS Entity Resolution は Secure Hash Algorithm 256-bit (SHA256) ハッシュプロトコルを使用し、32 バイトの文字列を出力します。これは、出力に含まれる一致するワークフローメタデータの一部です。

ID マッピング方法

ID マッピングの実行方法。

ID マッピングには 2 つの方法があります。

  • ルールベース – 一致するルールを使用して、ID マッピングワークフローのソースからターゲットにファーストパーティデータを変換する方法。

  • プロバイダーサービス – プロバイダーサービスを使用して、ID マッピングワークフローでサードパーティーでエンコードされたデータをソースからターゲットに変換する方法。

    AWS Entity Resolution は現在、プロバイダーのサービスベースの ID マッピング方法として LiveRamp をサポートしています。この方法を使用するには、 を通じて LiveRamp AWS Data Exchange へのサブスクリプションが必要です。詳細については、「ステップ 1: でプロバイダーサービスをサブスクライブする AWS Data Exchange」を参照してください。

ID マッピングワークフロー

指定された ID マッピング方法に基づいて、入力データソースから入力データターゲットにデータをマッピングするデータ処理ジョブ。これにより、ID マッピングテーブルが生成されます。このワークフローでは、ソースからターゲットに変換する ID マッピング方法と入力データを指定する必要があります。

ID マッピングワークフローは、独自の または 2 つの AWS アカウント で実行するように設定できます AWS アカウント。

ID 名前空間

複数の AWS アカウント にわたるデータセットを説明するメタデータと AWS Entity Resolution 、ID マッピングワークフローでこれらのデータセットを使用する方法を含む のリソース。

ID 名前空間には、 SOURCEと の 2 種類がありますTARGET。SOURCE には、ID マッピングワークフローで処理されるソースデータの設定が含まれています。には、すべてのソースが解決されるターゲットデータの設定TARGETが含まれています。2 つの 間で解決する入力データを定義するには AWS アカウント、ID 名前空間ソースと ID 名前空間ターゲットを作成して、データを 1 つのセット (SOURCE) から別のセット () に変換しますTARGET。

自分と別のメンバーが ID 名前空間を作成し、ID マッピングワークフローを実行したら、 でコラボレーションに参加 AWS Clean Rooms して、ID マッピングテーブルでマルチテーブル結合を実行し、データを分析できます。

詳細については、AWS Clean Rooms ユーザーガイドをご参照ください。

入力フィールド

入力フィールドは、 AWS Glue 入力データテーブルの列名に対応します。

入力ソース ARN (InputSourceARN)

AWS Glue テーブル入力用に生成された Amazon リソースネーム (ARN)。これは、出力に含まれる一致するワークフローメタデータの一部です。

機械学習ベースのマッチング

機械学習ベースのマッチング (ML マッチング) では、データ全体で一致が不完全であるか、まったく同じように見えない可能性があります。ML マッチングは、入力したすべてのデータにわたってレコードのマッチングを試みるプリセットプロセスです。ML マッチングは、一致したデータセットごとに一致 ID と信頼レベルを返します。

手動処理

オンデマンドで実行できるようにする、一致するワークフロージョブの処理頻度オプション。

このオプションはデフォルトで設定され、ルールベースのマッチングと機械学習ベースのマッチングの両方で使用できます。

Many-to-Manyマッチング

Many-to-manyマッチングは、類似データの複数のインスタンスを比較します。同じ一致キーが割り当てられた入力フィールドの値は、同じ入力フィールドにあるか異なる入力フィールドにあるかに関係なく、互いに照合されます。

例えば、「Phone」という一致キーhome_phoneが同じ mobile_phoneや などの複数の電話番号入力フィールドがあるとします。many-to-manyマッチングを使用して、mobile_phone入力フィールドのデータとmobile_phone入力フィールドのデータおよびhome_phone入力フィールドのデータを比較します。

一致ルールは、 (または) オペレーションで同じ一致キーを持つ複数の入力フィールドのデータを評価し、one-to-many一致は複数の入力フィールドの値を比較します。つまり、2 つのレコード間で mobile_phoneまたは の組み合わせがhome_phone一致すると、「Phone」一致キーは一致を返します。一致を見つけるための一致キー「Phone」の場合は、Record One mobile_phone = Record Two mobile_phoneOR OR Record One mobile_phone = Record Two home_phone Record One home_phone = Record Two home_phone OR ですRecord One home_phone = Record Two mobile_phone。

一致 ID (MatchID)

ルールベースのマッチングと ML マッチングの場合、これは によって生成 AWS Entity Resolution され、一致した各レコードセットに適用される ID です。これは、出力に含まれる一致するワークフローメタデータの一部です。

一致キー (MatchKey)

一致キーは、 AWS Entity Resolution どの入力フィールドを類似データと見なし、どの入力フィールドを異なるデータと見なすかを に指示します。これにより、ルールベースのマッチングルール AWS Entity Resolution を自動的に設定し、さまざまな入力フィールドに保存された同様のデータを比較できます。

mobile_phone 入力フィールドやhome_phone入力フィールドなど、比較するデータに複数のタイプの電話番号情報がある場合は、両方の一致キー「Phone」を指定できます。その後、ルールベースのマッチングは、すべての入力フィールドの「または」ステートメントと「電話」一致キーを使用してデータを比較するように設定できます (「一致ワークフロー」セクションのOne-to-One の一致」およびMany-to-Many一致」定義」を参照）。

ルールベースのマッチングで異なるタイプの電話番号情報を個別に考慮する場合は、「Mobile_Phone」や「Home_Phone」などのより具体的なマッチングキーを作成できます。次に、一致するワークフローを設定するときに、各電話一致キーをルールベースのマッチングで使用する方法を指定できます。

特定の入力フィールドに MatchKey が指定されていない場合、マッチングには使用できませんが、マッチングワークフロープロセスを通じて実行でき、必要に応じて出力できます。

一致キー名

一致キーに割り当てられた名前。

一致ルール (MatchRule)

ルールベースのマッチングの場合、これは、一致したレコードセットを生成するために適用されたルール番号です。これは、出力に含まれる一致するワークフローメタデータの一部です。

一致

さまざまな入力フィールド、テーブル、またはデータベースのデータを組み合わせて比較し、特定の一致基準を満たすことに基づいて (たとえば、一致するルールやモデルを通じて）、どちらが類似しているか、または「一致するかを判断するプロセス。

マッチングワークフロー

一致する入力データとマッチングの実行方法を指定するように設定したプロセス。

一致するワークフローの説明

入力することを選択できる、一致するワークフローのオプションの説明。説明は、複数のワークフローを作成する場合に、一致するワークフローを区別するのに役立ちます。

一致するワークフロー名

指定した一致するワークフローの名前。

注記

一致するワークフロー名は一意である必要があります。同じ名前にすることはできません。そうしないと、エラーが返されます。

ワークフローメタデータの一致

一致するワークフロージョブ AWS Entity Resolution 中に によって生成および出力される情報。この情報は出力時に必要です。

正規化 (ApplyNormalization)

スキーマで定義されているとおりに入力データを正規化するかどうかを選択します。正規化は、余分なスペースや特殊文字を削除し、小文字の形式に標準化することで、データを標準化します。

例えば、入力フィールドの属性タイプがフルフォンで、入力テーブルの値が の形式である場合(123) 456-7890、 AWS Entity Resolution は値を に正規化します1234567890。

注記

正規化は、名前、住所、電話番号、E メールのグループタイプでのみサポートされます。

以下のセクションでは、標準の正規化ルールについて説明します。

ML ベースのマッチングについては、「」を参照してください正規化 (ApplyNormalization) – ML ベースのみ。

名前

注記

正規化は名前グループタイプでのみサポートされます。

名前グループタイプは、コンソールではフルネームとして、API NAME では として表示されます。

名前グループタイプのサブタイプを正規化する場合：

  • コンソールで、フルネームグループに名、ミドルネーム、姓のサブタイプを割り当てます。

  • CreateSchemaMapping API で、NAMEgroupName に次のタイプを割り当てます: NAME_FIRST、NAME_MIDDLE、NAME_LAST。

  • TRIM = 先頭と末尾の空白をトリミング

  • LOWERCASE = すべてのアルファ文字を小文字にします

  • CONVERT_ACCENT = Covert アクセント付き文字から通常の文字へ

  • REMOVE_ALL_NON_ALPHA = アルファ以外の文字をすべて削除します [a-zA-Z]

E メール

注記

正規化は E メールグループタイプでサポートされています。

E メールグループタイプは、コンソールでは E メールアドレスとして、API EMAIL_ADDRESS では として表示されます。

  • TRIM = 先頭と末尾の空白をトリミング

  • LOWERCASE = すべてのアルファ文字を小文字にします

  • CONVERT_ACCENT = Covert アクセント付き文字から通常の文字へ

  • EMAIL_ADDRESS_UTIL_NORM = ユーザー名からドット (.) を削除し、ユーザー名のプラス記号 (+) の後にすべてを削除し、一般的なドメインバリエーションを標準化します。

  • REMOVE_ALL_NON_EMAIL_CHARS = non-alpha-numeric文字 [a-zA-Z0-9] と [.@-] をすべて削除します

電話

注記

正規化は、電話グループタイプでのみサポートされます。

電話グループタイプは、コンソールではフルフォンとして表示され、API PHONE では として表示されます。

電話グループタイプのサブタイプを正規化する場合：

  • コンソールで、完全な電話グループに電話番号と電話の国コードのサブタイプを割り当てます。

  • CreateSchemaMapping API で、PHONEgroupName に次のタイプを割り当てます: PHONE_NUMBERおよび PHONE_COUNTRYCODE。

  • TRIM = 先頭と末尾の空白をトリミング

  • REMOVE_ALL_NON_NUMERIC = 数値以外の文字をすべて削除します [0-9]

  • REMOVE_ALL_LEADING_ZEROES = 先頭のゼロをすべて削除

  • EN="_PREFIX_WITH_MAP, "phonePrefixMap" = 各電話番号を調べ、phonePrefixMap のパターンと照合しようとします。一致が見つかった場合、ルールは電話番号のプレフィックスを追加または変更して、マップで指定された標準化された形式に準拠していることを確認します。

Address

注記

正規化は、アドレスグループタイプでのみサポートされます。

アドレスグループタイプは、コンソールではフルアドレスとして、API ADDRESS では として表示されます。

アドレスグループタイプのサブタイプを正規化する場合：

  • コンソールで、住所 1、住所 2、住所 3、市区町村名、州、国、郵便番号 t のサブタイプを住所グループに割り当てます。

  • CreateSchemaMapping API で、ADDRESSgroupName に次のタイプを割り当てます: ADDRESS_STREET1、ADDRESS_STREET2、ADDRESS_STREET3、ADDRESS_CITY、ADDRESS_STATEADDRESS_COUNTRY、、ADDRESS_POSTALCODE。

  • TRIM = 先頭と末尾の空白をトリミング

  • LOWERCASE = すべてのアルファ文字を小文字にします

  • CONVERT_ACCENT = Covert アクセント付き文字から通常の文字へ

  • REMOVE_ALL_NON_ALPHA = アルファ以外の文字をすべて削除します [a-zA-Z]

  • ADDRESS_RENAME_WORD_MAP を使用する RENAME_WORDS = Address 文字列の単語を ADDRESS_RENAME_WORD_MAP の単語に置き換えます

  • ADDRESS_RENAME_DELIMITER_MAP を使用する RENAME_DELIMITERS = Address 文字列の区切り文字を ADDRESS_RENAME_DELIMITER_MAP の文字列に置き換えます

  • ADDRESS_RENAME_DIRECTION_MAP を使用する RENAME_DIRECTIONS= Address 文字列の区切り文字を ADDRESS_RENAME_DIRECTION_MAP の文字列に置き換えます

  • ADDRESS_RENAME_NUMBER_MAP を使用する RENAME_NUMBERS = Address 文字列の数値を ADDRESS_RENAME_NUMBER_MAP の文字列に置き換えます

  • ADDRESS_RENAME_™_CHAR_MAP を使用する RENAME_™_CHARS = Address 文字列の特殊文字を ADDRESS_RENAME_™_CHAR_MAP の文字列に置き換えます

ADDRESS_RENAME_WORD_MAP

これらは、アドレス文字列を正規化するときに名前が変更される単語です。

"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_RENAME_DELIMITER_MAP

これらは、アドレス文字列を正規化するときに名前が変更される区切り文字です。

",": " ",
".": " ",
"[": " ",
"]": " ",
"/": " ",
"-": " ",
"#": " number "

ADDRESS_RENAME_DIRECTION_MAP

これらは、アドレス文字列を正規化するときに名前が変更される方向識別子です。

"east": "e",
"north": "n",
"south": "s",
"west": "w",
"northeast": "ne",
"northwest": "nw",
"southeast": "se",
"southwest": "sw"

ADDRESS_RENAME_NUMBER_MAP

これらは、アドレス文字列を正規化するときに名前が変更される数値文字列です。

"número": "number",
 "numero": "number",
 "no": "number",
 "núm": "number",
 "num": "number"

ADDRESS_RENAME_SPECIAL_CHAR_MAP

これらは、アドレス文字列を正規化するときに名前が変更される特殊文字文字列です。

"ß": "ss",
 "ä": "ae",
 "ö": "oe",
 "ü": "ue",
 "ø": "o",
 "æ": "ae"

ハッシュ

  • TRIM = 先頭と末尾の空白をトリミング

Source_ID

  • TRIM = 先頭と末尾の空白をトリミング

正規化 (ApplyNormalization) – ML ベースのみ

スキーマで定義されているとおりに入力データを正規化するかどうかを選択します。正規化は、余分なスペースと特殊文字を削除し、小文字の形式に標準化することで、データを標準化します。

例えば、入力フィールドの属性タイプが でNAME、入力テーブルの値が の形式である場合Johns Smith、 AWS Entity Resolution は値を に正規化しますjohn smith。

以下のセクションでは、機械学習ベースのマッチングワークフローの正規化ルールについて説明します。

名前

  • TRIM = 先頭と末尾の空白をトリミング

  • LOWERCASE = すべてのアルファ文字を小文字にします

E メール

  • LOWERCASE = すべてのアルファ文字を小文字にします

  • (at)(大文字と小文字が区別されます) のみを @ 記号に置き換えます

  • 値内の任意の場所にあるすべての空白を削除します。

  • 最初の の外部にあるものがあれば、すべて削除"<>"します

電話

  • TRIM = 先頭と末尾の空白をトリミング

  • REMOVE_ALL_NON_NUMERIC = 数値以外の文字をすべて削除します [0-9]

  • REMOVE_ALL_LEADING_ZEROES = 先頭のゼロをすべて削除します

  • EN™_PREFIX_WITH_MAP、phonePrefixMap」 = 各電話番号を調べ、phonePrefixMap のパターンと照合しようとします。一致が見つかった場合、ルールは電話番号のプレフィックスを追加または変更して、マップで指定された標準化された形式に準拠していることを確認します。

One-to-Oneマッチング

One-to-one のマッチングでは、類似データの単一インスタンスを比較します。同じ入力フィールドに同じ一致キーと値を持つ入力フィールドは、互いに照合されます。

例えば、「Phone」という一致キーが同じ mobile_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」一致キーは一致を返します。一致を見つけるための一致キー「Phone」の場合は、 Record One mobile_phone = Record Two mobile_phone または ですRecord One home_phone = Record Two home_phone。

一致ルールは、 (および) オペレーションで異なる一致キーを持つ入力フィールドのデータを評価します。ルールベースのマッチングで異なるタイプの電話番号情報を個別に考慮する場合は、「mobile_phone」や「home_phone」などのより具体的なマッチングキーを作成できます。ルールで両方の一致キーを使用して一致を検索する場合は、 Record One mobile_phone = Record Two mobile_phoneおよび 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 とルール番号を返します。

エンティティを一意に識別できるルールを定義することをお勧めします。ルールを順序付けして、より正確な一致を最初に見つけます。

例えば、ルール 1 とルール 2 の 2 つのルールがあるとします。

これらのルールには、次の一致キーがあります。

  • ルール 1 にはフルネームと住所が含まれます

  • ルール 2 にはフルネーム、住所、電話番号が含まれます

ルール 1 が最初に実行されるため、ルール 1 によってすべて見つかったはずであるため、ルール 2 では一致は見つかりません。

電話によって区別される一致を見つけるには、次のようにルールの順序を変更します。

  • ルール 2 にはフルネーム、住所、電話番号が含まれます

  • ルール 1 にはフルネームと住所が含まれます

Schema

一連のデータの編成と接続方法を定義する構造またはレイアウトに使用される用語。

スキーマの説明

入力を選択できるスキーマのオプションの説明。説明は、複数のスキーマを作成する場合にスキーママッピングを区別するのに役立ちます。

スキーマ名

スキーマの名前。

注記

スキーマ名は一意である必要があります。同じ名前にすることはできません。そうしないと、エラーが返されます。

スキーママッピング

のスキーママッピング AWS Entity Resolution は、マッチングのためにデータを解釈 AWS Entity Resolution する方法を に指示するプロセスです。一致するワークフローに AWS Entity Resolution 読み込む入力データテーブルのスキーマを定義します。

スキーママッピング ARN

スキーママッピング用に生成された Amazon リソースネーム (ARN)。

一意の ID

指定した一意の識別子で、 が AWS Entity Resolution 読み取る入力データの各行に割り当てる必要があります。

たとえば、Primary_key、Row_ID、または Record_ID などです。

一意の ID 列は必須です。

一意の ID は、単一のテーブル内の一意の識別子である必要があります。

異なるテーブル間で、一意の ID に重複する値を含めることができます。

一致するワークフローが実行されると、一意の ID が次の場合、レコードは拒否されます。

  • が指定されていない

  • は同じテーブル内で一意ではありません

  • は、ソース間で属性名の点で重複しています。

  • が 38 文字を超えている (ルールベースのマッチングワークフローのみ）