従来の Unification ではうまくいかないケース#
例えば key として利用している email がメーリングリストや家族メールが含まれているため、email の一致で紐づけてしまうと異なる人物が紐づいてしまう可能性があるケースを考えてみよう。
ただ、この email を key から除外してしまうと、縫い合わせがうまくいかない。
一方、個人のユニーク性を担保した member_id のようなキーもある。
この時、以下のような縫い合わせができないかを考えるだろう:
まずはできる限り member_id の値に基づいて縫い合わせを行いたい
もし member_id の値が存在しないものに対しては email の値でできるだけ縫い合わせを行いたい
先ほどのテーブルを見てみよう。
member_id |
tel |
name |
|
---|---|---|---|
1 |
a@ex.com |
1111 |
Taka |
2 |
a@ex.com |
2222 |
Tatsuo |
3 |
b@ex.com |
3333 |
Naruse |
3 |
b@ex.com |
4444 |
Yuichiro |
NULL |
c@ex.com |
5555 |
Minero |
NULL |
c@ex.com |
6666 |
Kaz |
このテーブルにおいて今回ケースが生じていたとすると、
1行目と2行目は、 email が同じだが、member_id が異なるのでマージしたくない。
3行目と4行目は、 member_id が同じなのでマージしたい。
5行目と6行目は、 member_id が存在しないので、 email の一致によってマージしたい。
という願望を Unification に期待するすることになるだろう。

Fig. 47 1行目と2行目を別人物として扱いたいケース#
これをうまく実践してくれるオプションはないだろうか?実は、それを実現するのが do_not_merge_key:
なのである。
do_not_merge_key を利用しない場合#
まずは do_not_merge_key:
を使用しない、従来通りの canonical_ids:
の設定で実行したとしよう。
canonical_ids:
- name: person_id
merge_by_keys: [member_id, email]
merge_iterations: 3
しかし、この実行結果 (enriched_site_aaa
テーブル) は期待したものではない。なぜなら、1行目と2行目は、ユニーク性を担保している member_id が異なるのにも関わらず、email が同じために同一人物とみなされてしまったのだ。彼らはメーリングリストの email を使用しているために同じになっているにすぎない。
member_id |
tel |
name |
canonical_id |
|
---|---|---|---|---|
1 |
a@ex.com |
1111 |
Taka |
4ydklKlyPnfa |
2 |
a@ex.com |
2222 |
Tatsuo |
4ydklKlyPnfa |
3 |
b@ex.com |
3333 |
Naruse |
xqaWYjT4GR3a |
3 |
b@ex.com |
4444 |
Yuichiro |
xqaWYjT4GR3a |
NULL |
c@ex.com |
5555 |
Minero |
NEKDReELMAx |
NULL |
c@ex.com |
6666 |
Kaz |
NEKDReELMAx |
では、1行目と2行目を異なる人物として認識できるような Unification はできないのだろうか?
do_not_merge_key を利用した場合#
これに対して canonical_ids:
の設定に do_not_merge_key:
を設定して実行したとしよう。
canonical_ids:
- name: person_id
merge_by_keys: [member_id, email]
merge_iterations: 3
do_not_merge_key: member_id
この実行結果は1行目と2行目を同一視しない一方で、5行目と6行目を同一視する、期待通りのものになっている。
member_id |
tel |
name |
canonical_id |
|
---|---|---|---|---|
1 |
a@ex.com |
1111 |
Taka |
4ydklKlyPnfa |
2 |
a@ex.com |
2222 |
Tatsuo |
XNKI3XAY1Hja |
3 |
b@ex.com |
3333 |
Naruse |
xqaWYjT4GR3a |
3 |
b@ex.com |
4444 |
Yuichiro |
xqaWYjT4GR3a |
NULL |
c@ex.com |
5555 |
Minero |
NEKDReELMAx |
NULL |
c@ex.com |
6666 |
Kaz |
NEKDReELMAx |
実際、 master_table は以下の4行の出力になる。
person_id |
member_id |
tel |
name |
|
---|---|---|---|---|
58MMqWNFdAhu |
1 |
a@ex.com |
[1111] |
[“Taka”] |
WDbg4Lovngdu |
2 |
a@ex.com |
[2222] |
[“Tatsuo”] |
wkL-X_7PU2Ju |
3 |
b@ex.com |
[4444, 3333] |
[“Yuichiro”, “Naruse”] |
UVs_qHcWwZnz |
NULL |
c@ex.com |
[6666, 5555] |
[“Kaz”, “Minero”] |
do_not_merge_key 使用時の注意点#
do_not_merge_key:
には、1つの key だけを設定できる。その際、
merge_by_keys:
には必ずdo_not_merge_key:
が1番先 (優先度最上位) に来る必要がある。そうでないと"must be the first element of merge_by_keys"
のエラーが出る。