|
|
|
| Всем доброго дня!
Нужен какой-то эффективный метод борьбы с ошибками в данных в базе Access (2003).
Данные находятся в таблице. Ошибки касаются названий улиц города.
Например: несчастная улица Хо Ши Мина, может быть в таких вариантах: Хо-Ши-Мина, Хошимина и пр... + еще всякие варианты с перестановкой слов: Юрия Гагарина - Гагарина Юрия... По названию улицы проставляется зона города, поэтому важно, чтобы название было правильным...
Киньте идею, пожалуйста, как может выглядеть примочка для исправления ошибок... Может кто-нибудь сталкивался с этим. Буду очень признательна, если поделитесь опытом. | |
|
| |
|
|
|
| 1. примочка в виде человека. он сидит и исправляет. отвечает только за корректность данных в справочниках.
2. создать базу знаний по предметной области и использовать её в других разработках. можно продавать за деньги потом.
пункт второй в итоге вытекает из пункта первого рано или поздно.
3. создать искусственный интеллект. пока ведутся разработки. слишком много человеческого фактора все время.... | |
|
| |
|
|
|
| давать пользователю возможность выбирать название ТОЛЬКО из списка, список пополнять ТОЛЬКО ответсвенным администратором БД.
есть компании которые занимаются анализом и нормализацуией таких данных и исправлением таких ошибок, но дешевля нанять человека и сделать это самим
кстати это не называется собственно "ошибки в базах данных" - это ошибки ввода или опечатки, и с точки зрения БД ошибками они не являются. | |
|
| |
|
|
|
| Спасибо... Понимаю, что информация должна правильно заполняться на входе, тогда не надо будет с ней мучиться.
Я не говорила про "ошибки в базах данных", а "ошибках в данных в БД", хотя может действительно понятнее будет "ошибки ввода". | |
|
| |
|
|
|
| как верно сказано выше, на данном уровне самым эффективным способом решения проблемы - это создание справочников, ввод которые ограничен определенными ответственными лицами. Рядовые же пользователи просто выбирают из справочника..
С другой стороны, многое зависит от того как информация будет использоваться. возможно неудобства и ограничения справочников не стоят нех неудобств которые дает "разношерстность" ввода | |
|
| |
|
|
|
| Спасибо, Osmor за, как всегда, деловой стиль ответа. Информация в базе заполняется не в нашей конторе. Кто и как ее заполняет мне неизвестно. Я могу только ругаться на то, как ее заполняют, но от этого ничего не измениться.
Справочники есть. Они помогают во многом. По названию улицы проставляется зона города.
Но все равно ошибок много. В справочнике есть "1 Линия", но нет "Линия 1" или "Линия 1." | |
|
| |
|
|
|
| Ключевая фраза
Информация в базе заполняется не в нашей конторе. Кто и как ее заполняет мне неизвестно
Тогда никто кроме человека вам не поможет...
можно как-то упростить поиск похожих названий.
Ну например все названия которых нет в базе выводятся в отдельный список (слева)
справа при выборе позиции списка выводятся все существующие с базе названия в который встречаются слова из новой записи (под словами можно понимать набор символов отделеных друг от друга пробелом, или друшими служебными символами, например "-")
для огланичения кол-ва записей можно создать словарь слов которые не должны искаться типа "1", "1-я", "им." "имени" и т.п., что бы выборка осуществляласть только по "значимым словам".
ПОсле этого оператор принимает решение или выбрать из списка существующих значенией "синоним" для нового, или добавить новое значение.
Но без вмешательсва человека вряд ли получится | |
|
| |
|
|
|
| + функция нечеткого сравнения строк | |
|
| |
|
|
|
| Могучий оператор SELECT ... *LIKE* найдет всех твоих ХоШиМинов + Форма с отобранными записями + Кнопка "Удалить некорректную запись" + Администратор базы. | |
|
| |
|
|
|
| Спасибо, Osmor, Evgen, Силыч! Простите, что долго не давала обратную связь.... Навалилось тут все...
Osmor, Evgen, спасибо за картинку и идею того, как это может выглядеть... Что-то в этом духе мне и нужно... Буду соображать, как это реализовать теперь... Думаю еще будут вопросы... Удачи Вам! | |
|
| |
|
|
|
| Мне кажется с *like* придется под каждое сложное слово писать свою маску, например Хо*Ши*Мина. Многовато. Поскольку выбирать придется ручками, то желательно, чтоб похожие хотя б находились рядом в списке. Может сделать так: добавляем поле в которое помещаем значение исходного слова, но после обрезки цифр, дефисов, точек, пробелов, включениний типа ул., г. и т.д. Затем сортируем по этому полю. Затем выбросить все, что встречается один раз. | |
|
| |
|
|
|
| Что-то похожее и мне требовалось - найти двойников в базе по адресу. Я через КЛАДР эту проблему решил. Т.е. я выделяю город в строке адреса, нахожу город в КЛАДР'е, выбираю все улицы этого города из КЛАДР'а, и затем пытаюсь найти выбранные улицы в строке адреса. В итоге получаю код улицы из КЛАДР'а и храню его в базе для последующей проверки на двойников. Проверка получилась долгая, на SQL SERVER 2000 около миллиона записей неделю проверяется и около 75% адресов распознаётся, но даже такой результат очень сильно облегчил жизнь.
Юрия Гагарина и Гагарина Юрия такой метод распознает, а Хо-Ши-Мина и Хошимина - это только ручная правка | |
|
| |
|
|
|
| можно наверное функцую написать..
длинненькую как фамилии в родительном, дательном, виниттттт | |
|
| |
|
|
|
| можно видимо таблицу создать корректных (правидных) наименований и из неё выбирать..
можно видимо нескоько таких таблиц - глаголы существит местоимея_я_Я_я | |
|
| |