Как стать автором
Обновить

Случайные базы данных. Oracle Enterprise Data Quality — щит и меч корпоративного хранилища

Блог компании РДТЕХ (Разумные Деловые Технологии) Oracle *Java *Управление разработкой *
Процесс мышления любого человека с трудом подвергается математизации. Любая бизнес-задача порождает набор формальных и неформальных документов, информация из которых имеет отражение в корпоративном хранилище. Каждая задача, порождающая любой информационный процесс, создает вокруг себя набор документов и логику их обработки, которая мало формализуется в среде корпоративного хранилища. Внутри хранилища данных должны быть структуры для очистки информационного потока. В этом может помочь продукт 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). Разумеется, мы поставляем такие системы на рынок, в том числе есть версия на свободно-распространяемом программном обеспечении.

UPD2 Очень часто на конференциях задается вопрос: «Как подешевле создать систему управления качеством данных». Прошу считать эту статью небольшим введением в этот вопрос, с некоторым упрощением функциональности EDQ. Да, и еще, можно взять связку ODI + EDQ и сделать совсем хорошо, но это — предмет дальнейшего повествования.
Теги:
Хабы:
Всего голосов 14: ↑11 и ↓3 +8
Просмотры 2K
Комментарии 2
Комментарии Комментарии 2

Информация

Дата основания
Местоположение
Россия
Сайт
www.rdtex.ru
Численность
101–200 человек
Дата регистрации