Добавить комментарий

Верификация данных

Ого! Сайт жив, оказывается! :) Я как раз в 2004 году делал доклад на Московской секции ACM SIGMOD по верификации данных в РБД - в том числе, и на основе алгоритмов нечеткого поиска, в том числе, и по задаче выявления и избавления от дубликатов, в том числе, и в слабоструктурированных данных. Позволю себе дать кое-какие замечания.

1. Проблема дублирования НЕ "решается ограничением на ввод данных". Любой входной контроль может, в лучшем случае, затруднить ввод ошибочных данных, выявить валидность данных, но не их ошибочность.

2. Самая большая сложность - это не найти, а принять решение об изменении данных. Кто возьмёт на себя ответственность править БД?

3. Дубликаты (структурированных данных) могут быть внесены не только вследствие несовпадений значений отдельных полей, но и их комбинации. Реальный случай из практики: человек был занесён в БД дважды, при этом все поля кортежа были валидными (и даже совпадали), за исключением одного: из выпадающего меню был выбран соседний пункт (промах мышкой), в результате чего "улица маршала Рыбалко" превратилась в "улицу маршала Соколовского" (во втором случае адрес был введён правильно). Но самое неприятное, что такие дубли могут приводить к лавинообразному росту паразитных записей (привязанных либо у первой записи, либо ко второй), и, как следствие, к наведённым ошибкам при поиске и анализе информации. Справочник при выявлении ошибок подобного рода помочь не в состоянии.

4. Полагаться на словари-справочники опасно, поскольку там тоже могут быть неточные, неполные, устаревшие или просто ошибочные данные.

5. Не вижу никаких проблем с "размером географического справочника адресов" - ведь адрес по природе своей иерархичен! А потому справочник "для небольшого отдела, занимающегося международной рассылкой писем" должен содержать сотни или тысячи (ну, десятки тысяч) записей. Затраты на поддержание такого справочника в актуальном состоянии также смехотворно малы.

6. Согласен, "для достижения наилучшего результата может быть необходимым участие человека". Режим "кентавра" - самый эффективный для подобных задач.

7. Склеивание в одну строку атрибутов типа "ФИО", на мой взгляд, как раз затрудняет выявление ошибок в данных - ведь ошибки вида "Нилолай" (Николай) или "Алекандрович" (Александрович) вообще никак не зависят от содержимого других полей. И проводить верификацию по отдельным полям не только точнее, но и быстрее. Во всяком случае, мы поступали именно так.

8. Не понимаю, зачем тут вообще нужны запросы к СУБД - ведь верифицировать нужно ВСЕ данные базы - все, которые там вообще есть. Соответственно, не нужны никакие индексы, оптимизаторы запросов и прочие (потенциальные) проблемы.

9. А зачем нам "количество возможных размещений с повторениями из m символов алфавита по N"? Количество записей в базе и/или отдельных полей нам прекрасно известно уже на старте, и оно никакого отношения к комбинаторике не имеет. Количество уникальных элементов, как показывает практика, ещё меньше - обычно на 1-2 порядка.

10. Верификация сложных, неоднородных данных, которые в таблицу, что называется, "не лезут" при данном подходе просто невозможна.