Мыслительный процесс любого человека сложно математизировать.
Любая бизнес-задача генерирует набор формальных и неофициальных документов, информация из которых отражается в корпоративном хранилище.
Каждая задача, порождающая какой-либо информационный процесс, создает вокруг себя набор документов и логику их обработки, которая мало формализована в корпоративной среде хранения.
В хранилище данных должны быть структуры для очистки информационного потока.
В этом может помочь продукт Oracle Enterprise Data Quality, который призван решить проблему очистки «грязных» данных.
Но этим его использование не ограничивается.
1. Понятие случайной базы данных.
Первые деловые связи человека описываются формальными и неофициальными документами, такими как заявление, декларация, трудовой договор, заявление о трудоустройстве, заявление на ресурс.
Эти документы создают логические связи между бизнес-процессами, но, как правило, являются продуктом мышления офис-менеджеров и плохо формализованы.
Задача любой, даже несколько сложной оптимизации — не просто понять формальные и неформальные правила, но, зачастую, свести разрозненные знания в общую информационную базу.
Определение.
Назовем случайной базой данных набор фактов, документов, ручных заметок, формальных документов, которые обрабатываются людьми для конкретного бизнес-процесса, но не могут быть обработаны полностью автоматически из-за сильного влияния человеческого фактора.
Пример.
Секретарь формально принимает трубку.
Звонящий заинтересован в продукте или услуге.
Вызывающий абонент неизвестен CRM. Вопрос: что должен сказать звонящий, чтобы его услышал специалист? Если сформулировать точнее: насколько деловые инструкции секретаря допускают формальный диалог о бизнесе, если ответственный специалист не готов к такому виду деятельности? Получается, что мы снова приходим к определению случайной базы данных.
Возможно, там содержится больше фактов, чем может знать секретарь.
Но полученная в нем информация не может быть лишней.
Вообще, когда на вход формализованной системы поступают случайные факты из случайной базы данных, то возникает такое явление, как информационная перегрузка – а вся информационная перегрузка может повлиять на продуктивность не только секретаря, но и всей компании.
Если его использовать в целях обработки, то машина, считывающая состояния этой информации, приходит на основании логических выводов в состояние, противоположное человеку – информационную перегрузку.
Человеческая логика более гибкая.
2. Применение определения к реальным проблемам.
Представим себе магазин, в котором ценники на случайные товары заметно завышены или занижены.
При выходе из этого магазина в голове неопытного покупателя со списком покупок останется цена 5-7 (а то и 3) самых популярных товаров, цена которых может повлиять на размер общего чека.
Оказывается, если бы можно было знать перечень товаров, цену на которые покупатели чаще всего запоминают, то и остальные цены можно было бы варьировать в относительно широком диапазоне.
Вы когда-нибудь задумывались, почему перед Великим постом мясо сначала резко дешевеет, а потом может подорожать, а потом исчезнуть? Цена товара, спрос на который может упасть до нуля, сначала искусственно подогревается, затем, перейдя определенный уровень спроса, начинает фиксироваться, а через некоторое время принудительно возрастает, так как жадность не позволяет продавать.
и без того неликвидный товар по справедливой цене.
Практически аналогичная ситуация складывается на рынке данных.
Самая полезная информация почти всегда скрыта за вторичными гипотезами о ее применимости и извлечении.
Достаточно разместить на любом относительно незащищенном ресурсе любую информацию, которая заинтересует 5000-7000 человек; сайты для копирования обязательно будут. Или знаменитая игра с телефонными кодами «Кто мне звонилЭ» Около тысячи сайтов в Рунете состоят только из номеров телефонов различных операторов, чтобы быть чуть выше в результатах поиска, пытаясь как-то подороже продать доменное имя и рекламу.
3. Цена вопроса при работе с «грязными» данными.
По исследованиям автора статьи, до 10% трудовых ресурсов каждого проекта отвлекается на написание тех или иных процедур очистки данных.
Если не останавливаться на совершенно банальном типе и длине, то существуют еще уникальные идентификаторы, правила целостности баз данных и правила деловой целостности, количественные и качественные шкалы единиц, системы единиц трудоемкости и любые другие состояния, влияния, переходы, составление из которых требуется как обычный статистический, так и логический и серьезный бизнес-анализ.
Формализация требований приводит к необходимости формализовать связь факт-измерение как для построения хранилищ, так и для решения фронтальных вопросов.
Согласны, если 70% времени работы любого хранилища занимают ETL-процессы, то экономия 5-7% ресурсов на правильной очистке данных на условном хранилище на 200 000 клиентов — это уже хороший бонус? Давайте прольем свет на проблемы «грязных» данных в готовых системах.
Допустим, вы отправляете поздравления с национальным праздником 10 000 клиентам по почте.
Сколько людей бросят ваше письмо с самой красивой открыткой в почтовый ящик, если вы ошибетесь в имени, фамилии или неправильно укажете пол в форме? Цена ваших усилий способна свести настроение любого пользователя к нулю! 4. Oracle Enterprise Data Quality — щит и меч корпоративного хранилища.
Представленные нами снимки экрана описывают возможности продукта Oracle Enterprise Data Quality.
Итак, позвольте кому-нибудь пролить воду на вашу базу данных или текстовый документ.
Вот список стандартных процессоров (логических единиц, которые позволяют использовать
к данным определенных гипотез или для поиска того, что требуется):
Случайное действие профилировщика базы данных:
Эбазовая проверка финансовой состоятельности:
Работа с почтовым индексом:
Работы по очистке почтовых адресов:
Очистка пользовательских данных:
Присвоение записи определенному доверительному интервалу:
Определение пола пользователя по косвенным данным:
Определение города и страны, штата:
Простейший поиск ключей в случайной базе данных:
Дедупликация пользовательских данных:
5. Интересные наблюдения, сделанные по результатам работы над Oracle EDQ.
Одним из принципов сравнения вклада писателей и поэтов в литературу является сравнение их поэтического и литературного словаря.
Вот несколько словарей, составленных в свободное время для тестирования готовых решений в Oracle EDQ, Python и Java. Будем признательны, если авторы-филологи опубликуют свои результаты в комментариях.
Номер предмета | Слово | Частота появления | |||
Лев
Толстой, «Война и мир».
Фрагмент таблицы частот авторский словарь.
|
И.
Бродский, «Урания».
|
И.
Полное собрание сочинений Бродского, фрагмент частотного словаря автор.
|
Н.
Некрасов, фрагмент частотного словаря из полного собрания очерки.
|
||
1. | И | 10351 | В 1037 | В 5745 | И 3420 |
3. | В | 5185 | И 647 | И 4500 | В 2108 |
4. | Нет | 4292 | Нет 391 | Нет 3022 | Нет 1726 |
5. | Что | 3845 | на 341 | на 2239 | я 1040 |
6. | Он | 3730 | Как 329 | Как 1758 | С 883 |
7. | на | 3305 | С 237 | С 1674 | на 854 |
8. | С | 3030 | Что 168 | Что 1531 | Как 763 |
9. | Как | 2097 | К 148 | И 1200 | Что 693 |
10. | я | 1896 | от 147 | я 1040 | Он 644 |
11. | его | 1882 | от 104 | К 922 | Ты 475 |
12. | К | 1771 | я 90 | от 810 | Но 472 |
13. | Что | 1600 | Где 88 | Все 748 | А 449 |
14. | она | 1564 | как 88 | К 744 | Так 383 |
15. | Но | 1234 | позади 76 | Ты 721 | К 367 |
16. | Этот | 1208 | К 74 | В 713 | Все 344 |
17. | сказал | 1135 | Но 72 | позади 687 | позади 313 |
18. | был | 1125 | ни один 70 | от 635 | мне 309 |
19. | Так | 1032 | бы 69 | Но 617 | Да 294 |
20. | принц | 1012 | Что 67 | Он 592 | его 275 |
21. | позади | 985 | Ты 67 | Но 584 | Что 232 |
22. | А | 962 | О 66 | Что 540 | был 229 |
23. | Для него | 918 | Но 63 | О 538 | К 224 |
24. | Все | 908 | Есть 61 | Этот 524 | Нет 223 |
25. | К | 895 | я 61 | я 489 | ни один 222 |
26. | ее | 885 | А 463 | О 213 | |
27. | от | 845 | Где 449 | их 212 | |
28. | как 443 | от 209 | |||
29. | А 428 | от 207 | |||
30. | такой же 422 | Мы 206 |
Кстати, статистика Дарьи Донцовой во многом совпадает со статистикой Льва Толстого в области частотности лексики полного собрания сочинений.
6. Несколько формальных заявлений в качестве заключения.
В нашей стране проживает около 60 тысяч Иванов Иванов Ивановичей.
Предполагая, что где-то гипотетически средняя база данных хранит 100 таблиц, каждая таблица имеет 10 ключевых полей и каждый ключ может принимать 60 тысяч значений, мы обнаружим, что общее количество уникальных состояний ключа в базе данных составляет примерно 60 миллионов.
Даже если в одной таблице смешаны два ключа, они могут генерировать до 20 уникальных состояний в одной таблице.
Всего база уникальных состояний может содержать до нескольких тысяч.
Согласны ли вы, что тратить 10% времени разработки и 5-7% времени выполнения ETL на отлов таких мелочей — непозволительная роскошь? UPD1 Если в работе вам надоело таскать с собой систему контроля для каждого мало-мальски важного каталога, то вам на помощь придут системы MDM (Master Data Management).
Разумеется, мы поставляем на рынок такие системы, в том числе и в бесплатной версии программного обеспечения.
УПД2 Очень часто на конференциях задают вопрос: «Как дешевле создать систему управления качеством данных».
Пожалуйста, считайте эту статью небольшим введением в этот вопрос с некоторым упрощением функциональности EDQ. Да, и ещё, можно взять комбинацию ODI+EDQ и сделать это очень хорошо, но это уже предмет дальнейшего обсуждения.
Теги: #Oracle Enterprise Data Quality #java #проектирование системы #забавные задачи #oracle #java #Управление разработкой
-
От Commodore До Ipad
19 Oct, 24