マージングキャンペーンでのデータモデルの設定 - 7.2

Talend Data Stewardshipの例

EnrichVersion
7.2
EnrichProdName
Talend Big Data
Talend Big Data Platform
Talend Data Fabric
Talend Data Integration
Talend Data Management Platform
Talend Data Services Platform
Talend MDM Platform
Talend Real-Time Big Data Platform
EnrichPlatform
Talend Data Stewardship
task
データガバナンス > キャンペーンの管理
データガバナンス > タスクの割り当て
データガバナンス > データモデルの管理
データクオリティとプレパレーション > タスク管理

データモデルにより管理対象データの構造が決定されます。データモデルはデータの構文とセマンティックの検証に使用されます。

データモデルにリスト表示される各属性にロールごとの読み取り/書き込みアクセス許可を定義できます。

手順

  1. [ADD CAMPAIGN] (キャンペーンの追加)ページで、[DATA MODEL] (データモデル)をクリックし、モデルリストから[CRM Data Deduplication] (CRMデータ重複除去)キャンペーンで使用するデータ構造を選択します。

    [Data Model] (データモデル)リストでは、定義されているすべてのデータモデルにアクセス権が付与されます。

  2. データ構造内の属性の横にあるボタンをそれぞれ選択して、属性ごとおよびデータスチュワードごとにアクセス許可を設定し、誰がどの属性を表示/編集できるかを定義します。
    オプション 説明
    データモデルの属性に対して読み取り/書き込みアクセスが提供されます。
    データモデルの属性に対して読み取りアクセスのみ提供されます。

    この種のアクセスは、データスチュワードが情報を調べて判断を下す必要があるものの、値を変更してはならない場合、たとえば、スチュワードが表示する一意の識別子が、他のエンティティにリンクしている場合、または信頼できることが判明しており、変更するべきでないデータを表示する場合に便利です。

    属性へのアクセスを提供しません。

    属性の非表示の機能は、情報の機密性が高い場合や、財務情報などの情報をデータスチュワードに見せたくない場合に便利です。非表示にする属性の別の例としては技術識別子など、スチュワードにとっては単にノイズであっても、タスクの一部として伝播する必要のある項目があります。

    例え

    CRM Data Deduplication (CRM データ重複除去)キャンペーンで、Account Analyst(アカウント分析者)のロールが割り当てられているデータスチュワードの識別属性に読み取り専用アクセスを付与します。

  3. 各属性の横にあるSurvivorship Rule (サバイバーシップルール)リストからルールを選択します。
    これらのルールはキャンペーンにデータを読み込む際、マスターレコードを定義する属性値を決定するために使用されます。データスチュワードは、これらの選択を手動で変更できます。
    オプション 説明
    First valid (最初の有効) データモデルで定義されている属性のデータ型に関して、有効な値を含む最初のソースを選択します。「先頭」はタスク作成時のレコードの順番によって定義されます。
    First not null (最初がNULLでない) 値が含まれている最初のソースを選択します。この場合の「最初」とはタスク作成時のレコードの順番によって定義されます。
    [Most common] (最も共通) 1つまたは複数のデータソースからの重複のうち最も共通する属性値を選択します。
    [Most recent] (最も直近) 1つまたは複数のデータソースからの重複のうち最も直近の属性値を選択します。これはメタデータの最後の更新日に基づきます。
    Most trusted (最も信頼できる) キャンペーンの作成時またはキャンペーンでタスクを読み込む時に設定したトラストスコアにしたがって重複のうち最も信頼制の高い属性値を選択します。トラストスコアが定義されていない場合、このオプションは動作しません。
    フォーム右上のリストからルールをクリックすると、すべての属性に対して1つのルールを選択できます。指定されたアルゴリズムを適用できない場合、ルールはFirst not null (最初がNULLでない)に戻ります。たとえば、トラストスコアを設定していないのに、キャンペーン定義にMost trusted (最も信頼できる)を選択した場合、First not null (最初がNULLでない)が使用されます。同様に、[Most common] (最も一般的)または[First valid] (最初の有効)を選択しているのに、重複データに共通するものがないか、有効なデータがない場合にも[First not null] (最初がNULLでない)が使用されます。

    例え

    マスターレコードをビルドするためにどんな価値を選択するのかは、サバイバーシップルールによって決まります。以下は、そのことを示すサンプルです。
    [First valid] (最初の有効): メールアドレス:
    • 最初の値が有効でなく、2番目の値が有効な場合は、2番目のメールが勝ちます。
    • すべてのメールアドレスが無効な場合は、最初の空でない値が勝ちます。
    [First not null] (最初がNULLでない): ファーストネーム:
    • 最初の値が空で、2番目の値が空でない場合は、2番目のファーストネームが勝ちます。
    • すべてのファーストネームが空の場合、マスターレコード内でファーストネームは空になります。
    [Most common] (最も一般的): ラストネーム:
    • 2つのソースレコード内でラストネームが同一である場合は、この値が勝ちます。
    • すべてのソースレコード内でラストネームが異なる場合は、最初の空でない値が勝ちます。
    [Most recent] (最近)の電話番号とタイムスタンプ:
    • 1つの電話番号に最新のタイムスタンプがある場合は、この値が勝ちます。
    • すべての電話番号に同じタイムスタンプがある場合は、最初の空でない値が勝ちます。
    [Most trusted] (最も信頼できる): 住所:
    • ソースレコード内のすべての住所にトラストスコアがある場合は、スコアが最高の値が勝ちます。
    • ソースレコード内のすべての住所にトラストスコアがあり、2つが同一である場合は、同一住所の最初のものが勝ちます。
    • どの住所もトラストスコアを持たない場合は、最初の空でない値が勝ちます。