Соответствие одинаковых значений столбцов Oracle с использованием Soundex, Jaro Winkler и Edit Distance (UTL_MATCH)

Question

Я пытаюсь найти надежный метод для сопоставления дубликатов записей о людях в базе данных.У данных есть некоторые серьезные проблемы с качеством данных, которые я также пытаюсь исправить, но пока у меня нет на это разрешения, я застреваю с данными, которые у меня есть.

Доступные мне столбцы таблицы:

SURNAME       VARCHAR2(43)
FORENAME      VARCHAR2(38)
BIRTH_DATE    DATE
ADDRESS_LINE1 VARCHAR2(60)
ADDRESS_LINE2 VARCHAR2(60)
ADDRESS_LINE3 VARCHAR2(60)
ADDRESS_LINE4 VARCHAR2(60)
ADDRESS_LINE5 VARCHAR2(60)
POSTCODE      VARCHAR2(15)

Функция SOUNDEX относительно ограничена для этого использования, но пакет UTL_MATCH предлагает более высокий уровень соответствия с использованием алгоритма Jaro Winker.

Вместо того, чтобы повторятьИзобретая колесо, кто-нибудь реализовал надежный метод для сопоставления данных этого типа?

Проблемы качества данных, с которыми приходится сталкиваться:

1. Почтовый индекс, хотя и является обязательным, не всегда полностьюВведено.
2. Адресные данные относительно низкого качества с адресами, введенными в фиксированном формате (т. е. некоторые могут иметь строку 1 как «Flat 1», тогда как другие могут иметь строку 1 как «Flat1, 22 Acacia Ave»).
3. Столбец «Имя» может содержать инициал, полное имя или иногда более одного имени.

Например, я рассматривал:

КонкатенацияОбратимся к полям и применим алгоритм Jaro Winkler к полному адресу в сочетании с аналогичным тестом полного имени, объединенного вместе.

Дата рождения может сравниваться непосредственно для совпадения, но из-за большого объема данных простосоответствия на это не достаточно.

Oracle 10g R2 Enterprise Edition.

Любые полезные предложения приветствуются.

Answer 1

"Я пытаюсь найти надежный метод для сопоставления дубликата человека записей в базе данных. "

Увы, такого нет. Максимум, на что вы можете надеяться - это система с разумным элементом сомнения.

SQL> select n1
       , n2
       , soundex(n1) as sdx_n1
       , soundex(n2) as sdx_n2
       , utl_match.edit_distance_similarity(n1, n2) as ed
       , utl_match.jaro_winkler_similarity(n1, n2) as jw   
from t94
order by n1, n2
/


  2    3    4    5    6    7    8    9  
N1                   N2                   SDX_ SDX_         ED         JW
-------------------- -------------------- ---- ---- ---------- ----------
MARK                 MARKIE               M620 M620         67         93
MARK                 MARKS                M620 M620         80         96
MARK                 MARKUS               M620 M622         67         93
MARKY                MARKIE               M620 M620         67         89
MARSK                MARKS                M620 M620         60         95
MARX                 AMRX                 M620 A562         50         91
MARX                 M4RX                 M620 M620         75         85
MARX                 MARKS                M620 M620         60         84
MARX                 MARSK                M620 M620         60         84
MARX                 MAX                  M620 M200         75         93
MARX                 MRX                  M620 M620         75         92

11 rows selected.

SQL> SQL> SQL> 

Большим преимуществом SOUNDEX является то, что он токенизирует строку. Это означает, что он дает вам что-то , которое можно проиндексировать : это невероятно ценно, когда дело касается больших объемов данных. С другой стороны, он старый и грубый. Вокруг появились новые алгоритмы, такие как Metaphone и Double Metaphone. Вы должны быть в состоянии найти их реализации PL / SQL через Google.

Преимущество оценки состоит в том, что они допускают некоторую степень размытости; так что вы можете найти все строки where name_score >= 90%. Огромный недостаток в том, что оценки являются относительными, и поэтому вы не можете их индексировать. Такое сравнение убивает вас большими объемами.

Что это значит:

1. Вам нужно сочетание стратегий. Ни один алгоритм не решит вашу проблему.
2. Очистка данных полезна. Сравните оценки для MARX против MRX и M4RX: удаление чисел из имен улучшает рейтинг попаданий.
3. Вы не можете набирать большие объемы имен на лету. Используйте токенизацию и предварительную оценку, если можете. Используйте кэширование, если у вас мало оттока. Используйте разделение, если можете себе это позволить.
4. Используйте текст Oracle (или аналогичный) для создания тезауруса псевдонимов и вариантов.
5. В Oracle 11g появилась специальная функция поиска имен в Oracle Text. Узнайте больше.
6. Создайте таблицу канонических имен для оценки и свяжите с ней фактические записи данных.
7. Используйте другие значения данных, особенно индексируемые, такие как дата рождения, для предварительной фильтрации больших объемов имен или для повышения уверенности в предлагаемых совпадениях.
8. Имейте в виду, что другие значения данных связаны с их собственными проблемами: кто-то родился 31.01.11 в одиннадцать месяцев или в восемьдесят лет?
9. Помните, что имена являются хитрыми, особенно когда вы должны учитывать имена, которые были латинизированы: существует более четырехсот различных способов написания Моаммара Хадаффи (в римском алфавите) - и даже Google не может договориться о том, какой вариант является самый канонический.

По моему опыту, объединение токенов (имя, фамилия) является смешанным благословением. Это решает определенные проблемы (например, появляется ли название дороги в адресной строке 1 или адресной строке 2), но вызывает другие проблемы: рассмотрите возможность оценки GRAHAM OLIVER против OLIVER GRAHAM против оценки OLIVER против OLIVER, GRAHAM против GRAHAM, OLIVER против GRAHAM и GRAHAM против OLIVER ,

Что бы вы ни делали, вы все равно будете получать ложные срабатывания и пропущенные попадания. Ни один алгоритм не является доказательством против опечаток (хотя Jaro Winkler хорошо справился с MARX против AMRX).