組織名や人名を突合するとき、表記ゆれを吸収するために正規化（全角半角の統一、空白除去、法人格や敬称の除去）をかける。この正規化は強くするほど表記ゆれに強くなる一方で、実在する別実体を同一のキーへ潰す方向にも効く。名称の一部が接頭・接尾の除去対象と重なっていると、正式名称が異なる別法人が同じキーになる。

判断基準

• 正規化の強度を落として解決しようとしない。除去をやめれば別実体の同一化は解けるが、表記ゆれ吸収という本来の目的を失い、突合対象すべての名寄せが崩れる。爆発半径が桁違いに大きい。
• 代わりにキーの次元を足す。名称に地理的な絞り（都道府県相当 → 市区町村相当）を重ねる方向は、既存キーを壊さず衝突だけを解く。政令市のように市の下にさらに区がある体系では、区まで含めないと解けない衝突が実在する。
• 一意制約を「名称＋広い地域」から「名称＋広い地域＋狭い地域」へ移すのは制約を緩める方向なので、既存データは必ず通る。移行時に既存行が制約違反で落ちる心配が要らないのは、この向きだけ。

実測してから決める

キーの候補ごとに、取り込む全データ（新規ソースだけでなく既存データとの突合も）でキーを計算し、衝突キー数と潰れる件数を数える。設計時のコメントに「衝突したら手動レビュー」と書いてあっても、実データに既に衝突があれば初回取り込みが必ず落ちるので運用が成立しない。

同時に測っておくべきもの:

• 抽出できない入力の件数。住所からの地域抽出は、国外住所・記載欠落・別言語表記で失敗する。追加するキー列は NULL 相当（空文字）を許す設計にする。
• 新旧ソースの重なり。既存データと新ソースが同一実体としてどれだけ名寄せされるかは、後段の属性更新規則の設計を左右する（重なりが多数派なら、属性の上書き規則は例外処理ではなく主要な設計事項になる）。

落とし穴

• キーの次元を足すと、既に1行へ潰れていた実体は自動では分かれない。次回の取り込みで新しいキーとして新規作成され、旧行は更新されない孤児として残る。孤児の掃除は別作業として見積もる。
• 一意制約に NULL 可の列が含まれると、多くの RDB は NULL 同士を重複扱いしないため、その組み合わせには制約が効かない。追加する列を NOT NULL（既定は空文字）にしておくと、少なくとも新しく増える穴は作らない。