Алгоритм поиска практически похожих значений - PullRequest
Новая
       3

Алгоритм поиска практически похожих значений

11 голосов
/ 08 июля 2010

У меня есть Persons таблица в SQL Server 2008 .

Моя цель - найти людей, которые имеют почти одинаковые адреса.

Адрес описывается столбцами state, town, street, house, apartment, postcode и phone.

Из-за некоторых специфических различий в некоторых штатах (не в США) и в человеческом факторе (ошибки в адресах и т. Д.) Адрес не заполняется одинаковым образом.

Самые распространенные ошибки в адресах

  1. Чувствительность к регистру
  2. Кто-то написал «apt.», Другой - «квартиру» или «ap». (хотя адреса не написаны на английском языке)
  3. Пробелы, точки, запятые
  4. Различия в написании названий улиц, например, "Доктор" Джонс-стрит "или" Доктор Джонс-стрит "или" Д. Джон. st. "или" Dr Jones st "и т. д.

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

Есть ли алгоритм для такого рода проблем?

Заранее спасибо.

UPDATE

  1. Как я уже говорил, адрес разделен на разные столбцы. Должен ли я генерировать строку, объединяющую столбцы, или делать ваши шаги для каждого столбца? Я предполагаю, что я не должен объединять столбцы, но если я буду сравнивать столбцы отдельно, как мне организовать их? Должен ли я найти сходства для каждого столбца, объединить их или пересечь или что-нибудь еще?
  2. Нужно ли мне собирать статистику или какой-то алгоритм обучения?

Ответы [ 15 ]

0 голосов
/ 08 июля 2010

Одним из методов может быть применение алгоритма Левенштейна к полям адреса. Это позволит вам сравнить строки на предмет сходства.

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

0 голосов
/ 08 июля 2010

Другая идея заключается в использовании обучения.Например, вы можете узнать для каждой аббревиатуры и ее места в предложении, что означает эта аббревиатура. 

3 Jane Dr. -> Dr (in 3rd position (or last)) means Drive
Dr. Jones St -> Dr (in 1st position) means Doctor

Например, вы можете использовать деревья решений и обучить пользователя системе.Вероятно, несколько примеров каждого использования будет достаточно.Вы не могли бы классифицировать однобуквенные аббревиатуры, такие как Д. Джонс, которые могут быть Дэвидом Джонсом или доктором Джонсом.Но после первого уровня перевода вы можете просмотреть индекс улицы города и посмотреть, сможете ли вы расширить D. до названия улицы.

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

Такое ощущение, что должны быть какие-то коммерческие продукты, делающие это там.

0 голосов
/ 08 июля 2010

A есть возможность иметь в базе данных словарную таблицу, которая отображает все варианты в «правильную» версию слова: 

*Value* | *Meaning*
Apt.    | Apartment
Ap.     | Apartment
St.     | Street

Затем вы пропускаете каждое слово черезсловарь перед сравнением.

Редактировать: только этот слишком наивен, чтобы быть практичным (см. комментарий).

0 голосов
/ 08 июля 2010

Вы можете добавить все адреса в веб-службу, такую ​​как Google Maps (хотя я не знаю, подходит ли она), и посмотреть, имеют ли они одинаковые координаты GPS.

0 голосов
/ 08 июля 2010

возможности таких вариаций бесчисленны, и даже если такой алгоритм существует, он никогда не может быть надежным. В конце концов, у тебя не может быть проверки орфографии для существительных. вы можете предоставить раскрывающийся список ранее введенных значений полей, чтобы они могли выбрать одно из них, если конкретное имя уже существует. лучше иметь отдельные поля для каждого значения, например, квартиры и т. д.

Страница:
...