|
1 Downing Street
|
01-01-01
|
“Дом”
|
Таблица 1.2
Устранение дублирования
Номер
Клиента
| Имя | Адрес |
Дата
покупки
|
Покупаемый
Журнал
|
23003
|
Дженсон
|
1 Downing Street
|
04-15-94
|
Автомобильный
|
23003
|
Дженсон
|
1 Downing Street
|
06-21-93
|
Музыкальный
|
23003
|
Дженсон
|
1 Downing Street
|
05-30-92
|
Комиксы
|
23009
|
Клинтон
|
2 Boulevard
|
01-01-01
|
Комиксы
|
23013
|
Кинг
|
3 High Road
|
02-30-95
|
Спортивный
|
23003
|
Дженсон
|
1 Downing Street
|
01-01-01
|
“Дом”
|
В базе данных клиентов некоторые клиенты могут быть представлены несколькими записями, хотя во многих случаях это результат небрежности, такой как ошибка при набивке, или следствием того, что, например, клиенты перемещаются с одного места на другое без извещения об изменении адреса. Существуют также случаи, в которых люди преднамеренно записывают свои имена неправильно или дают неправильную информацию относительно себя, особенно в ситуации отказа им в некотором типе страхования. С помощью своего имени или неправильного адреса они пытаются избежать отрицательного решения. Конечно, для любой организации важно избегать такие аномалии в базе данных. Хотя обнаружение знаний и очистка данных - две различных дисциплины, они имеют много общего и при очистке данных могут быть применены алгоритмы распознавания паттернов.
В представленном примере в атрибуте имени БД присутствуют значения Дженсон и Джонсон. Они имеют различные клиентские номера, но один и тот же адрес, что достаточно сильно свидетельствует о том, что эти двое - один и тот же человек, но что в имени одного существует ошибка. Конечно, нельзя быть уверенным до конца, что это так, но алгоритм устранения дублирования, используя технику анализа образцов, мог бы идентифицировать ситуацию и представить её пользователю для принятия решения. Этот тип загрязнения встречается часто: потому что ошибка в первичной БД там, где появляются два клиента, когда в действительности существует только один, создаёт впечатление, что организация имеет больше клиентов, чем в есть на самом деле. Так как это ситуация, которая часто происходит в реальной жизни, многие большие банки и страховые компании не имеют никакой надежной идеи узнать, как много заказчиков они действительно имеют. Это представляет серьезную проблему в маркетинговой деятельности, но после процедуры устранения дублирования две подписки Дженсона/Джонсона можно определенно решить, кто из них таковой на самом деле.
Второй распространенный тип загрязнения - это недостаток области совместимости (табл. 1.3). Обратите внимание, что в первичной таблице мы имеем две записи, датированные 1 января 1901. Хотя организации вероятно даже не существовала в это время. Этот тип загрязнения особенно опасен, поскольку его трудно проследить, но он будет оказывать огромное влияние на тип образцов (паттернов), находимых применяемыми к этой таблице процедурами обнаружения знаний. В некоторых базах данных анализ показывает неожиданно высокое число людей, рожденных 11 ноября.
Когда люди вынуждены заполнять дату рождения за монитором, и они или не знают или не хотят обнародовать свою дату рождения, они склоняются набить 11-11-11. Само собой разумеется, это катастрофично в контексте обнаружения знаний, так как если информация неизвестна, то она должна и представляться так в базе данных. В нашем примере мы заменили часть данных нулевым значением и исправили другие области несовместимости.
Таблица 1.3
Область совместимости
Номер
Клиента
| Имя | Адрес |
Дата покупки
|
Покупаемый журнал
|
23003
|
Дженсон
|
1 Downing Street
|
04-15-94
|
Автомобильный
|
23003
|
Дженсон
|
1 Downing Street
|
06-21-93
|
Музыкальный
|
23003
|
Дженсон
|
1 Downing Street
|
05-30-92
|
Комиксы
|
23009
|
Клинтон
|
2 Boulevard
|
NULL
|
Комиксы
|
23013
|
Кинг
|
3 High Road
|
02-30-95
|
Спортивный
|
23003
|
Дженсон
|
1 Downing Street
|
12-20-94
|
“Дом”
|
Обогащение (добавление информации). Предположим, что мы получили дополнительную информацию о клиентах, состоящую из даты рождения, дохода, размера кредита, наличия автомобиля или дома (табл. 1.4.) Не очень важно, как была собрана информация, но необходимо оценить, можно ли новую информацию присоединить к существующим записям о клиентах.
Таблица 1.4
Обогащение
Имя
клиента
| Дата рождения | Доход | Кредит |
Владелец автомобиля
| Владелец дома |
Дженсон
|
04-13-76
|
$18,500
|
$17,800
|
Нет
|
нет
|
Клинтон
|
10-20-71
|
$36,000
|
$26,600
|
Да
|
нет
|
Кодирование. Данные в примере могут подвергаться ряду преобразований. Сначала дополнительная информация, которая была получена, чтобы обогатить базу данных, добавляется к записям, описывающим индивидуальности. На следующем этапе мы выделяем только те записи, которые имеют достаточно информации, чтобы быть ценными (табл.1.5).
Хотя трудно дать детализированные правила для этого вида операции, это ситуация, которая часто происходит на практике. В большинстве таблиц, которые собраны из операционных данных, отсутствует множество желательных данных и большинство из них невозможно восстановить. Поэтому необходимо принять обдуманное решение или пропустить эту информацию, или удалить её. Общее правило говорит, что любое удаление данных должно быть сознательным решением после всестороннего анализа возможных последствий. В некоторых случаях, особенно в задачах определения мошенничества, недостаток информации может быть ценным указанием наличия значимых образцов.
В представленном примере существует недостаток данных о Кинге, поэтому примем решение исключить эту запись из заключительной выборки. Конечно, это решение не бесспорно, потому что может существовать причинная связь между недостатком информации и поведением Кинга. Предположим, что можно игнорировать эти данные без каких-либо последствий для наших заключительных результатов. В этом примере мы не заинтересованы в именах клиентов, так как хотим только определить некоторые типы клиентов пользователя, так что их имена удаляются из базы данных (табл. 1.6).
До сих пор фаза кодирования состояла из простых операций SQL, но теперь вводим этап, где требуется творческое преобразование данных. Информация в нашей базе данных слишком детализирована, чтобы использоваться в качестве входной для алгоритмов распознавания образцов. Возьмём, например, понятие даты рождения: алгоритм, который помещает людей с одной и той же датой рождения в определенный класс заказчиков, очевидно, слишком детализирован для наших целей, в то же время подобный алгоритм, обрабатывающий возрастные классы с интервалом, например, 10 лет был бы подходящим. То же справедливо и для адресов.
Информация об адресах слишком детализирована для алгоритмов распознавания образцов и, в этом случае, нам необходимо записывать адреса в кодах регионов. Способ, которым кодируется информацию, в значительной степени, определит тип найденных нами паттернов. Следовательно, кодирование является творческой деятельностью, которое должно выполняться постоянно, чтобы получить наилучшие результаты. Возьмём, например, дату подписки; снова она слишком детализировано, но существуют различные способы записи этих дат так, чтобы обнаружились ценные образцы. Одним из решений могла бы быть трансформация даты приобретения в месяцы, начиная с 1990г. Таким образом, мы могли бы найти образцы во временной последовательности транзакций наших заказчиков, например, зависимости, подобные следующему правилу:
Заказчик с кредитом > 13,000 и возрастом между 22 и 31, который подписался на комиксы во время T, пятью годами позже с большой вероятностью подпишется на автомобильный журнал.
Или могли бы определить такую тенденцию:
Do'stlaringiz bilan baham: |