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

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

    Комментарии 2

      0
      В нашей стране проживает примерно 60 тысяч Ивановых Иванов Ивановичей. Принимая, что где-то гипотетически в средней базе данных хранится 100 таблиц, в каждой таблице по 10 ключевых полей, а каждый ключ может принимать по 60 тысяч значений, получаем, что суммарное количество уникальных состояний ключей внутри базы данных примерно 60 миллионов. Если даже в одной таблице перепутаются два ключа, то они могут породить до 20 уникальных состояний в одной таблице. Всего в базе уникальных состояний может набежать до нескольких тысяч. Согласитесь, что тратить 10% времени разработки и 5-7% времени исполнения ETL для вылавливания таких мелочей — непозволительная роскошь?


      Можно поподробнее, пожалуйста? Возможно, другой пример? Спасибо.
        0
        1. В статье постулируется несколько неочевидных фактов. Одним из фактов является то, что имена собственные (как и иная личная информация) являются сложным в обработке информационным потоком из-за наличия большой чувствительности любой системы к ошибкам, так и конечных пользователей — к ошибкам в их именах, фамилиях и др.
        2. Пример с Ивановыми — классический пример, как одна фамилия может, будучи орфографически правильной, по разному произноситься. Это даже на ТВ обыгрывают в сериале ИвАновы-ИванОвы. Теперь рассмотрим реальную ситуацию.
        3. Пусть у вас есть 15-17 сторонних систем, которые пишут ФИО Ивановых в базу.
        Допустим, просто имя и фамилию. Проверки кто-то случайно выключил. Что попадет в таблицу? В таблицу попадет Иванов Иван… Что произойдет, если на такой таблице включить обычные связи? У вас будет 60 000 записей, среди которых, я просто уверен, будут полные дубликаты. Итак, представили ситуацию?
        4. Включили уникальность на таблице. Могут исчезнуть нужное имя с фамилией, а если включить внешние ключи, то в них может содержаться ошибка на уровне индекса, адреса, др. данных. Сколько раз так бывает, когда приставы, допустим, приходят к полному тезке?
        5. Возникает каскад ошибок, каждая из которых решалась бы в рамках одной таблицы, но хранилище подразумевает интегральное состояние объекта. А у нас — каскад ключей не привязанных к нужным ФИО. Поэтому я привел очень оптимистичную оценку, зачастую ситуация много-много хуже.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое