canonical_id について

canonical_id の生成と割り当て

今回の例では、merge_by_keys: に設定する key の順番は email を最も優先度高くすることになる。 なぜなら、email の値は他の key の値と異なり、時間の経過においても値が変わりにくいからである。email を持たないユーザーは td_ssc_id が最終 leader となり、この値をもとに canonical_id が生成される。

Fig. 41 canonical_id の生成と割り当て

master_table に設定できる canonical_id について

master_table に設定する canonical_id は基本的に、merge_by_keys:に全ての key を設定したものであるが、canonical_idは 全ての key を使用していないものも作成できる。

ただ、master_table に設定できる canonical_id は merge_by_keys: が以下の条件を満たしているものでないといけない：

• 全てのソーステーブルのレコードに canonical_id が割り振られるような設定でなければならない。言い換えると、全てのソーステーブルで key が 1つ以上 merge_by_keys: に含まれている必要がある。

今回の例 (Example2 のデータ) では、各テーブルは

• site_aaa

  • td_client_id

  • td_global_id

  • td_ssc_id

• site_xxx

  • td_ssc_id

  • td_global_id

• site_yyy

  • email

  • td_ssc_id

• site_zzz

  • td_client_id

  • email

の key を持っていた。この場合、master_table に使用できる canonical_id の merge_by_keys: の設定は、

• ⭕️ [email, td_ssc_id, td_global_id, td_client_id]

• ⭕️ [td_ssc_id, td_global_id, td_client_id]

• ⭕️ [email, td_global_id]

• ⭕️ [td_ssc_id, td_client_id]

である。逆にエラーとなるものは例えば以下である。

• ❌ [td_global_id, td_client_id]

  • site_yyy に登場する key がない

• ❌ [email, td_client_id]

  • site_xxx に登場する key がない

この場合、

400 Bad Request: {"master_tables[0].attributes[0].source_columns[0].table":["is invalid because it doesn't have columns merged into this master_table's canonical_id 'person_id'"],"master_tables[0].attributes[1].sou...

のようなエラーメッセージが出る。 例えば [td_global_id, td_client_id] の例は、td_global_id、td_client_id のみに生成された canonical_id が付与されることになる。site_yyy テーブルには、これらの key がないために canonical_id を割り振ることができないことになる。少なくとも merge_by_keys: 内の key (縫い合わせに使われたkey) が1つでもあれば、全てのテーブル内のレコードに canonical_id が割り振ることができる。