Процесс мышления любого человека с трудом подвергается математизации. Любая бизнес-задача порождает набор формальных и неформальных документов, информация из которых имеет отражение в корпоративном хранилище. Каждая задача, порождающая любой информационный процесс, создает вокруг себя набор документов и логику их обработки, которая мало формализуется в среде корпоративного хранилища. Внутри хранилища данных должны быть структуры для очистки информационного потока. В этом может помочь продукт 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 для вылавливания таких мелочей — непозволительная роскошь?