Определения

Консолидация данных это набор процедур и методов, ориентированных на получение данных из источников, обеспечение уровня информативности и качества данных, преобразование данных в универсальный формат, в котором они загружаются в хранилище данных или аналитическую систему.

Консолидация данных является первым этапом реализации аналитической задачи или проекта. В основе консолидации данных лежит процесс сбора и организации хранения в виде, доступном для их обработки на аналитической системе или решения аналитической задачи. Основными задачами консолидации являются оценка качества полученных данных, а также дополнение данных.

Основные показатели качества консолидации данных:

• высокая скорость доступа к данным;
• компактность хранения данных;
• поддержка целостности структуры данных;
• контроль целостности данных.

ХД – Хранилище данных (База данных);

ИД – Источник данных (Источник данных);

ПД - Периметр данных совокупность источников данных (ИД) для получения информации;

ETL — набор методов для переноса исходных данных из различных источников в аналитическую систему или поддерживающих некоторое хранилище данных;

OLTP - Система оперативной обработки информации (On-Line Transaction Processing — оперативная обработка транзакций в режиме реального времени);

СППР - Информационная система поддержки принятия решений (СППР);

АС - Аналитическая система.

Источники данных

Одним из основных понятий консолидации является источник данных это некий объект, содержащий данные, которые могут быть нужными для аналитической задачи. Необходимо обеспечить, чтобы используемая АС могла осуществлять доступ к данным после получения или после преобразования в другой формат.

АС, не содержат средств ввода и редактирования данных и как правило работают с данными полученными из источников. Таким образом, формирование исходных данных для анализа в большинстве случаев ложится на источники данных.

Основные задачи консолидации данных

В процессе разработки консолидации данных решаются следующие задачи:

• выбор источников данных;
• разработка стратегии консолидации;
• оценка качества получаемых данных;
• обогащение данных;
• очистка данных или их предварительная обработка;
• перенос в хранилище данных;
• получение данных из хранилища;
• анализ данных а АС.

Определение

Очистка данных — набор методов или процедур, предназначенных на начальном этапе устранить дефекты получаемых данных: пустые ссылки, дубликаты, противоречия и т. д.

Обогащение — набор методов или процедур дополнения данных некоторой информацией, по каким либо причинам отсутствующих в исходном наборе.

Обобщенная схема процесса консолидации

Консолидация в процессе анализа данных может быть представлена в виде следующей структурной схемы см. рис.

Основные особенности концепции ХД

Определение

Хранилище данных это разновидность систем хранения, ориентированных в первую очередь на поддержку процесса анализа данных для выполнения аналитических запросов.

Основным элементом ХД является механизм, позволяющий аналитику оперировать данными терминами предметной области - предметный слой. Он дает аналитику возможность сосредоточиться на анализе и не задумываясь о внутренних механизмах получения данных.

Как правило ХД отличается от типовых систем хранения данных целью использования. Например, фиксация продаж и регистрация документов это задача OLTP-системы. Построение динамики продаж и спроса за несколько лет, удобнее выполнять при поддержке ХД.

Основные требования к ХД

Чтобы ХД выполняло функции, соответствующие задаче поддержки процесса анализа данных — оно должно удовлетворять следующим требованиям:

• высокая скорость получения данных из хранилища;
• автоматическая поддержка внутренней целостности данных;
• возможность получения и сравнения срезов данных;
• наличие средств для просмотра данных в хранилище;
• обеспечение целостности данных.

Задачи, решаемые ХД

Основными задачами, которые требуется решить в процессе разработки ХД, являются:

• выбор структуры хранения данных, обеспечивающей высокую скорость выполнения запросов и минимизацию объема оперативной памяти;
• первоначальное заполнение и последующее пополнение хранилища;
• обеспечение единой методики работы с разнородными данными и создание удобного интерфейса пользователя.

В зависимости от круга решаемых задач и уровня их сложности архитектура ХД и модели данных, могут существенно различаться. Типовая схема ХД на рис. ниже

 

Способы использования ХД

С помощью аналитического приложения, используемого совместно с ХД, формируются запросы к данным из хранилища. Данные могут подвергаться обработке средствами АС, и тогда будут выводиться результаты обработки данных.

Спектр применения консолидации данных достаточно широк. Соответственно, методики применения ХД могут быть различны. Можно выделить три основных направления по использованию ХД:

• регулярные отчеты — подготовка отчетов стандартных форм, получаемых многократно с определенной периодичностью (Периодичность);
• нерегламентированные запросы — возможность получать ответы на нестандартные, сформированные «по требованию» вопросы (Пакет данных);
• интеллектуальный анализ данных — поддержка процесса интеллектуального анализа больших массивов данных с целью выявления скрытых закономерностей, структур и объектов, построения моделей, прогнозов и т.д. (Отчет консолидации)

Введение в ETL

Извлечение данных из источников и загрузка в ХД для дальнейшей аналитики связано с рядом проблем:

• Исходные данные находятся в источниках разных типов и форматов, могут использовать различную кодировку, когда для решения задачи анализа данные должны быть преобразованы в универсальный формат, который поддерживается ХД и АС. (Структура пакетов)
• Данные в источниках излишне детализированы, когда для решения задач анализа требуются агрегирование данных. (Свертка данных)
• Исходные данные, являются «неполными», то есть содержат различные дефекты, которые мешают корректному анализу. (Алгоритмы очистки данных)

Для переноса исходных данных из различных источников в ХД необходимо использовать специальный подход, который должен получать данные из источников различного формата, преобразовывать их в единый формат, поддерживаемый ХД, а при необходимости — выполнять очистку данных. Такой подход получил название ETL (от англ. extraction, transformation, loading — «извлечение», «преобразование», «загрузка»). Сам процесс переноса данных и действия называют ETL-процессом, а программные средства — ETL-системами.

Определение

ETL — комплекс методов, реализующих процесс переноса исходных данных из различных источников в аналитическое приложение или поддерживающее его хранилище данных. (Алгоритмы загрузки)

Основные цели и задачи процесса ETL

Приложения ETL извлекают информацию из одного или нескольких источников, преобразуют ее в формат, поддерживаемый системой хранения и обработки, которая является получателем данных, а затем загружают в нее преобразованную информацию. Изначально ETL-системы использовались для переноса информации из более ранних версий различных информационных систем в новые. В настоящее время ETL-системы все более широко применяются именно для консолидации данных с целью их дальнейшего анализа. Очевидно, что поскольку ХД могут строиться на основе различных моделей данных (многомерных, реляционных, гибридных), то и процесс ETL должен разрабатываться с учетом всех особенностей используемой в ХД модели. Кроме того, желательно, чтобы ETL-система была универсальной, то есть могла извлекать и переносить данные как можно большего числа типов и форматов.

Независимо от особенностей построения и функционирования ETL-система должна обеспечивать выполнение трех основных этапов процесса переноса данных (ETL-процесса).

• Извлечение данных. На этом этапе данные извлекаются из одного или нескольких источников и подготавливаются к преобразованию. Следует отметить, что для корректного представления данных после их загрузки в ХД из источников должны извлекаться не только сами данные, но и информация, описывающая их структуру, из которой будут сформированы метаданные для хранилища.
• Преобразование данных. Производятся преобразование форматов и кодировки данных, а также их обобщение и очистка.
• Загрузка данных — запись преобразованных данных в соответствующую систему хранения.

Перемещение данных в процессе ETL можно разбить на последовательность процедур, представленных следующей функциональной схемой рис.

Извлечение данных в ETL

Начальным этапом процесса ETL является процедура извлечения записей из источника данных и подготовка содержащейся в них информации к процессу преобразования.

При разработке процедуры извлечения данных в первую очередь необходимо определить регламент загрузки ХД и соответственно частоту выгрузки данных из OLTP-систем или отдельных источников. Например, выгрузка может производиться по истечении заданного временного интервала (день, неделя, месяц или квартал). В некоторых случаях предусматривается возможность вне регламентного извлечения данных после завершения определенного бизнес-события (приобретение нового бизнеса, открытие филиала, поступление большой партии товаров). В зависимости от объема извлекаемых данных, сложности доступа к ним и скорости работы оборудования, выгрузка данных занимает определенное время, которое так и называют — «окно выгрузки». Очевидно, что в течение «окна выгрузки» резко увеличивается нагрузка на компьютерную сеть организации и ее работа может оказаться частично или полностью парализованной. Особенно это актуально для OLTP-систем, где в такие периоды может резко возрасти время ожидания отклика. Поэтому «окно выгрузки» стараются выбрать так, чтобы оно в минимальной степени влияло на рабочий процесс, например в обеденный перерыв, сразу по завершении рабочего дня или ночью.

Если выгрузку данных производить более часто, то, с одной стороны, количество «окон загрузки» увеличивается, но поскольку за меньший период в OLTP-системе накапливается меньше изменений, то «окна загрузки» становятся короче и нагрузка на систему — ниже.

После извлечения данные помещаются в так называемую промежуточную область, где для каждого источника данных создается своя таблица или отдельный файл (или и то и другое). В некоторых случаях, когда требуется выгрузить данные из нескольких источников одного типа, для них создается общая таблица; одно из ее полей указывает на источник, из которого были взяты данные.

Выбор используемых источников данных

Перед тем как приступить к процессу извлечения данных, необходимо определить, в каких именно источниках хранятся данные, которые должны попасть в хранилище. Все источники можно разделить на две группы — расположенные в корпоративных информационных системах и на локальных компьютерах отдельных пользователей. С точки зрения соблюдения регламента и периодичности загрузки данных в ХД предпочтительны источники из первой группы, поскольку они также функционируют в соответствии с определенным порядком, который проще согласовать с периодичностью загрузки данных в хранилище. Что касается источников на локальных ПК, то обычно никаких сколь-нибудь строгих правил работы с ними не устанавливается: пользователи включают и выключают компьютеры, когда хотят; постоянно возникают те или иные проблемы с сетью и т. д. Тем не менее именно на локальных компьютерах часто собирается очень ценная для анализа информация. Поэтому при выборе источников данных для загрузки в ХД необходимо учитывать следующие факторы:

• значимость данных с точки зрения анализа;
• сложность получения данных из источников;
• возможное нарушение целостности и достоверности данных;
• объем данных в источнике.

Как правило, приходится искать компромисс между этими факторами. Например, данные могут представлять несомненную ценность для анализа, но сложность их извлечения или некорректность структуры может свести на нет все преимущества от их использования. В другом случае данные легкодоступны и не требуют дополнительной обработки при загрузке в ХД, но при этом практически не представляют интереса с точки зрения анализа.

Особенности организации процесса извлечения данных

После того как источники, из которых будут извлекаться данные, выбраны, необходимо определить, все ли имеющиеся в источниках данные нужны в ХД.

Если извлекать нужно не все записи подряд, а только определенные, аналитик может описать набор условий, которые позволят отобрать только записи, представляющие интерес. Например, можно поставить условие, что записи, которые содержат информацию о продажах на сумму меньше заданной, извлекать и помещать в ХД не нужно, поскольку их ценность с точки зрения результатов анализа ничтожна.

Другой важный момент — определение глубины выгрузки данных по времени. Очевидно, что все записи понадобятся только при первичном заполнении хранилища. В процессе его пополнения из источников должны извлекаться лишь те записи, которые добавлялись или изменялись после прошлого извлечения. Иногда хранилища полностью очищают и перезагружают. Но это возможно только в случае, если ХД не очень большое и процесс регенерации занимает не слишком много времени, а также если регенерация происходит редко и за промежуток времени между ними большая часть данных изменяется или утрачивает актуальность.

Вопрос определения глубины выгрузки важен только при начальной загрузке хранилища, когда требуется определить, информация за какой период времени является актуальной. В простейшем случае, когда никаких соображений на этот счет нет, можно загрузить все имеющиеся записи. Однако этот подход не всегда оптимален, поскольку в хранилище может оказаться много информации, не представляющей ценности для анализа в связи с потерей актуальности. Таким образом, выбор глубины выгрузки исторических данных должен обеспечить компромисс между объемом выгружаемых данных и их ценностью с точки зрения анализа.

Процедура определения глубины выгрузки облегчается, если в источнике данных присутствует поле, в котором указывается время создания и изменения каждой записи (Актуальность). В этом случае отбирать извлекаемые записи по времени можно с помощью несложного фильтра. (Дата актуальности)

При повторных загрузках ХД важно не только определить глубину выгрузки, но и организовать поиск измененных данных . Для этой цели разработаны различные методики, например использование меток времени. Для каждой измененной записи создается метка, указывающая на время изменения, и при очередной выгрузке извлекаются только те записи, метки времени которых созданы позднее прошлого извлечения. (Таблицы изменений).

Особенности извлечения данных из различных типов источников

Процесс извлечения данных в рамках ETL существенно зависит от типов и структуры источников данных. Можно выделить три разновидности источников данных, с которыми чаще всего сталкиваются организаторы аналитических проектов.

Базы данных (SQL Server, Oracle, Firebird, Access и т. д.). В большинстве случаев извлечение данных из баз данных не вызывает проблем, поскольку структура данных в них жестко задана, соответствует определенным стандартам и общепринятым требованиям. Кроме того, во многих СУБД предусмотрен автоматический контроль за целостностью и непротиворечивостью данных.

Структурированные файлы различных форматов. Такие файлы очень широко распространены, поскольку средства их создания (в большинстве случаев это типовые офисные приложения) общедоступны и не требуют высокой квалификации персонала и высокой производительности систем. К таким источникам относятся текстовые файлы с разделителями, файлы электронных таблиц (например, Excel, CSV-файлы, HTML-документы и т. д.). Здесь проблем больше, поскольку пользователь может допускать ошибки, пропуски, вводить противоречивые данные, терять фрагменты данных и т. д. Пользователи офисных приложений часто понятия не имеют о том, что такое тип данных, и уж тем более не связывают вводимые ими данные с задачами будущего анализа. Очевидно, что в этой ситуации при извлечении данных можно столкнуться с чем угодно. Единственным плюсом является то, что для доступа к типовым структурированным данным можно применять такие стандартные средства, как ODBC и ADO.

Неструктурированные источники. Как правило, эта ситуация требует особого внимания. Если избежать использования неструктурированных источников не получается, нужно применить специальные средства их преобразования в структурированный вид. Когда источник невелик, возможно, это удастся сделать вручную. Но в большинстве случаев приходится разрабатывать специальный инструментарий, учитывающий особенности организации данных в источнике и то, какую структуру из них следует создать. Существуют также готовые программные системы для решения этой задачи. Конечная цель структурирования — так упорядочить данные в файле, чтобы их в том или ином виде можно было загрузить в реляционную таблицу.

Таким образом, извлечение данных из OLTP-систем, СУБД и отдельных структурированных источников в рамках ETL-процесса может оказаться задачей достаточно сложной в техническом плане и важной для эффективного анализа данных. Поэтому разработкой и организацией процесса извлечения данных должны заниматься как технические специалисты, так и аналитики.

Очистка данных в ETL. Два уровня очистки данных

Наличие «грязных» данных — одна из важнейших и трудно формализуемых проблем аналитических технологий вообще и ХД в частности. Очистка данных обязательна при их перегрузке в хранилище, и при разработке стратегии ETL этому уделяется большое внимание. Следует отметить, что, помимо очистки данных перед их загрузкой в хранилище, пользователь может выполнить дополнительную очистку средствами аналитической системы уже после выполнения запроса к ХД. Такое дублирование вполне оправданно по ряду причин.

• В данных, извлекаемых из различных источников, могут содержаться проблемы, из-за которых выполнить загрузку данных в ХД будет невозможно.
• Конечный пользователь чаще всего не имеет представления обо всех особенностях данных в источниках, из которых они извлекаются, и поэтому не может (и не должен) разрабатывать стратегию очистки.
• Вторичная очистка данных, предусмотренная в аналитической системе, по своим методам и целям существенно отличается от очистки данных в процессе ETL. Целесообразность применения того или иного метода очистки данных, полученных в результате запроса из ХД, определяется пользователем, исходя из особенностей конкретной задачи анализа. При этом часто используется субъективное мнение аналитика, основанное на личном опыте. Например, одному специалисту гладкость ряда данных покажется недостаточной для решения определенной задачи анализа и он применит процедуру сглаживания для очистки от шумов или аномальных значений. В то же время другой аналитик скажет, что в результате сглаживания вместе с шумом и аномалиями подавлены изменения, несущие полезную информацию.
• Некоторые виды ошибок (например, противоречия и аномальные значения) могут быть обнаружены только после консолидации данных. Действительно, нельзя сделать вывод, что некоторое значение является аномальным, пока не произведено его сравнение с соседними значениями.

Таким образом, первичная очистка данных в процессе ETL носит в большей степени технический характер. Ее основная задача — подготовить данные к загрузке в хранилище. Вторичная очистка в аналитической системе является пользовательской, она направлена на подготовку данных к решению конкретной аналитической задачи. Поэтому оба этапа очистки одинаково важны и необходимы.

Критерии оценки качества данных

Чтобы разработать методику очистки данных в процессе ETL, необходимо определить критерии оценки их качества. Одним из таких критериев является критичность ошибок. В этой связи данные могут быть разделены на три категории:

• данные высокого качества, не нуждающиеся в очистке;
• данные, содержащие критичные ошибки, из-за которых они в принципе не могут быть загружены в ХД (например, буква или пробел в числовом значении, неправильный разделитель целой и дробной частей числа и т.д.). То есть критичными являются ошибки, которые делают невозможной дальнейшую работу с данными;
• данные, содержащие некритичные ошибки, которые не мешают их загрузке в ХД, но при этом данные являются некорректными с точки зрения их анализа (аномальные значения, пропуски, дубликаты, противоречия и т.д.). Некритичные ошибки могут быть исправлены в процессе анализа данных средствами аналитической системы.

Существует несколько проблем, из-за которых данные нуждаются в очистке. Наиболее широко распространены проблемы, связанные с нарушением структуры данных:

корректность форматов и представлений данных;

уникальность первичных ключей в таблицах БД;

полнота и целостность данных;

полнота связей;

соответствие некоторым аналитическим ограничениям и т. д.

Преобразование данных в ETL

Этап ETL-процесса, следующий за извлечением, — преобразование данных. Его цель — подготовка данных к размещению в ХД и приведение их к виду, наиболее удобному для последующего анализа. При этом должны учитываться некоторые выдвигаемые аналитиком требования, в частности, к уровню качества данных. Поэтому в процессе преобразования может быть задействован самый разнообразный инструментарий, начиная от простейших средств ручного редактирования данных до систем, реализующих весьма сложные методы обработки и очистки данных.

В процессе преобразования данных в рамках ETL выполняются следующие операции рис.:

• преобразование структуры данных;
• агрегирование данных;
• перевод значений;
• создание новых данных;
• очистка данных.

Агрегирование данных

Как правило, в качестве источников данных для хранилищ выступают системы оперативной обработки данных (OLTP-системы), учетные системы, файлы различных СУБД, локальные файлы отдельных пользователей и т.д. Общим свойством всех этих источников является то, что они содержат данные с максимальной степенью детализации — сведения о ежедневных продажах или даже о каждом факте продажи в отдельности, об обслуживании каждого клиента и т.д. Распространено мнение, что такое детальное воспроизведение событий в исследуемом бизнес-процессе только пойдет на пользу, поскольку данные никогда не бывают лишними и чем больше их будет собрано, тем точнее окажутся результаты анализа.

Это не совсем так. Элементарные события, из которых состоит бизнес-процесс, например обслуживание одного клиента, выполнение одного заказа и т. д., которые также называют атомарными (то есть неделимыми), по своей сути являются случайными величинами, подверженными влиянию множества различных случайных факторов — от погоды до настроения клиента. Следовательно, информация о каждом отдельном событии в бизнес-процессе практически не имеет ценности. Действительно, на основании информации о продажах за один день нельзя сделать вывод обо всех особенностях торговли. Точно так же нельзя выработать стратегию работы с клиентами на основе исследования поведения одного клиента.

Иными словами, для достоверного описания предметной области использование данных с максимальным уровнем детализации не всегда целесообразно, поэтому наибольший интерес для анализа представляют данные, обобщенные по некоторому интервалу времени, по группе клиентов, товаров и т. д. Такие обобщенные данные называются агрегированными (иногда агрегатами), а сам процесс их вычисления — агрегированием.

В результате агрегирования большое количество записей о каждом событии в бизнес-процессе заменяется относительно небольшим количеством записей, содержащих агрегированные значения. Например, вместо информации о каждой из 365 ежедневных продаж в году в результате агрегирования будут храниться 52 записи с обобщением по неделям, 12 — по месяцам или 1 — за год. Если цель анализа — разработка прогноза продаж, то для краткосрочного оперативного прогноза достаточно использовать данные по неделям, а для долгосрочного стратегического прогноза — по месяцам или даже по годам.

Фактически при агрегировании производится объединение нескольких записей в одну с вычислением агрегированного значения на основе значений каждой записи. При вычислении агрегатов может быть использовано несколько способов.

• Среднее — для данных, расположенных в пределах интервала, в котором они обобщаются, вычисляется среднее значение. Затем все записи из данного интервала заменяются одной, содержащей их среднее значение (рис. 27).
• Сумма — агрегируемые записи заменяются одной, в которой указывается сумма агрегируемых значений.
• Максимум — в результирующей записи остается максимальное значение из всех объединяемых.
• Минимум — в результирующей записи остается минимальное значение из всех объединяемых.
• Количество уникальных значений — результатом агрегирования будет число уникальных значений, появляющихся в ячейках одного и того же поля. Так, для поля, содержащего информацию о профессии клиента, данный способ агрегирования покажет, сколько раз та или иная профессия появлялась в списке. Например, если в 25 записях в поле профессия имело место значение Системный аналитик, а в 50 — Менеджер, то в результате агрегирования мы получим число 2.
• Количество — результатом агрегирования будет число записей, содержащихся в поле. В приведенном выше примере с профессиями клиентов при этом варианте агрегирования получим 75.
• Медиана — вычисляется медиана агрегируемых значений. Медиана представляет собой порядковую статистику, рассчитываемую следующим образом. Набор агрегируемых значений, например продажи по дням недели, сортируется в порядке возрастания. Тогда медианой будет центральный элемент упорядоченного набора, если этот набор содержит нечетное количество значений, или среднее двух центральных элементов, если число элементов четное. Например, пусть каждый день в течение недели продажи составляли {100, 120, 115, 119, 107, 131, 102}. Тогда для определения медианы нужно выстроить эти значения по возрастанию: {100, 102, 107, 115, 119, 120, 131}. Значение центрального элемента полученной последовательности, то есть 115, и будет медианой. Если продажи осуществлялись только 6 дней в неделю (воскресенье — выходной), то будет получена последовательность из четного числа значений {100, 107, 115, 119, 120, 131}. В этом случае медиана будет равна: (115 + 119) / 2 = 117.

Закономерен вопрос: нужно ли агрегировать все данные без разбору по всем возможным уровням обобщения или к этому следует подходить внимательно? Для ответа необходимо изучить наиболее вероятные направления использования данных в ХД. Однако если хранилище находится на стадии разработки и внедрения и методика его использования еще не до конца проработана, то сделать это трудно. Тем не менее, если опросить потенциальных пользователей ХД, что именно они хотят получить, возможно, некоторые сведения на этот счет удастся разыскать.

Из всех возможных вариантов агрегирования следует выбрать наиболее значимые с точки зрения планируемых направлений анализа, а от остальных отказаться. Очевидно, можно отказаться от агрегатов, которые имеют малое число подчиненных агрегированных значений (например, агрегирование ежемесячных продаж за квартал), поскольку их легко вычислить в процессе анализа. Или, наоборот, можно отказаться от агрегатов с максимальной степенью детализации (например, агрегирование ежедневных продаж). Второй вариант наиболее предпочтителен, поскольку на первый взгляд сулит существенную экономию, так как число дней в году умножается на число товаров и продавцов. Однако если данные о продажах являются разреженными, то есть не каждый товар продается ежедневно, то экономия может оказаться весьма незначительной.

Выбор нужных агрегатов всегда определяется особенностями бизнеса. При этом следует помнить, что агрегаты, требуемые для анализа, могут быть вычислены и непосредственно при выполнении аналитического запроса к ХД, хотя тем самым время его выполнения несколько увеличится. Подобный подход позволяет, например, отказаться от агрегирования редко используемых данных.

Таким образом, выбор правильной стратегии агрегирования данных в ETL — сложная и противоречивая задача. Увеличение числа агрегатов в ХД приводит к увеличению его размеров и сложности структуры данных. Снижение числа агрегатов в ХД может привести к необходимости их вычисления в процессе выполнения аналитических запросов, что увеличит время ожидания пользователя. Следовательно, необходимо обеспечить разумный компромисс между этими факторами. Существует и более простое правило, определяющее стратегию агрегирования: создавайте только те агрегаты, которые с большой долей вероятности понадобятся при анализе данных.

Перевод значений

Часто данные в источниках хранятся с использованием специальных кодировок, которые позволяют сократить избыточность данных и тем самым уменьшить объем памяти, требуемой для их хранения. Так, наименования объектов, их свойств и признаков могут храниться в сокращенном виде. В этом случае перед загрузкой данных в хранилище требуется выполнить перевод таких сокращенных значений в более полные и, соответственно, понятные.

Например, согласно заведенному в организации порядку, идентификационный номер операции может быть закодирован в виде 06–04–12–62, где 06–04 — число и месяц, 12 — код товара, 62 — код региона. Такое представление позволяет хранить данные очень компактно. Однако для заполнения соответствующих измерений в многомерной модели запись необходимо декодировать.

Кроме того, часто возникает необходимость конвертировать числовые данные, например преобразовать вещественные в целые, уменьшить избыточную точность представления чисел, использовать экспоненциальный формат и т. д.

Создание новых данных

В процессе загрузки в ХД может понадобиться вычисление некоторых новых данных на основе существующих, что обычно сопровождается созданием новых полей. Например, OLTP-система содержит информацию только о количестве и цене проданного товара, а в целевой таблице ХД есть поле Сумма. Тогда в процессе преобразования необходимо вычислить сумму как произведение цены на количество проданных единиц товара. Таким образом, будет создано поле, содержащее новую информацию.

Еще одним возможным примером новых данных, создаваемых в процессе обработки, являются экономические, финансовые и другие показатели, которые могут быть вычислены на основе имеющихся данных. Так, на основе данных о продажах можно рассчитать рейтинг популярности товаров и создать новое поле, в котором для каждого товара будет указано соответствующее рейтинговое значение (например, по пятибалльной системе).

Создание новой информации на основе имеющихся данных тесно связано с таким важным процессом, как обогащение данных, которое может производиться (частично или полностью) на этапе преобразования данных в ETL. Агрегирование также может рассматриваться как создание новых данных.

Очистка данных

Сбор данных в процессе ETL производится из большого числа источников, многие из которых не содержат автоматических средств поддержки целостности, непротиворечивости и корректного представления данных. В связи с этим при переносе информации в ХД приходится сталкиваться с потоками «грязных» данных, которые могут стать причиной неправильных результатов анализа и даже сделать невозможным применение некоторых аналитических алгоритмов и методов. По этой причине в процессе ETL применяется очистка — процедура корректировки данных, которые в каком-либо смысле не удовлетворяют определенным критериям качества, то есть содержат нарушения структуры данных, противоречия, пропуски, дубликаты, неправильные форматы и т.д.

Некоторые проблемы в данных являются критичными и даже не позволяют выполнить загрузку данных в ХД (как правило, это нарушения структуры и некорректные форматы данных). Другие проблемы менее критичны, не мешают переносу данных в ХД, но не позволяют их корректно анализировать (пропуски, противоречия и дубликаты). Критичные проблемы в данных должны устраняться непосредственно в процессе ETL. Некритичные факторы, снижающие качество данных, могут устраняться как в процессе ETL, так и при подготовке их к анализу в аналитической системе.

Очистка данных — одна из наиболее важных и в то же время наиболее сложных и трудно поддающихся формализации задач ETL-процесса, поскольку набор факторов, снижающих качество данных, весьма разнообразен и может постоянно меняться. Поэтому очистке данных при разработке ETL-процессов уделяют большое внимание.

Выбор места для выполнения преобразований данных

В принципе, преобразование данных может быть выполнено на любом этапе ETL-процесса. Но иногда требуется выбрать оптимальное место для осуществления преобразования. Некоторые виды преобразований удобнее выполнять «на лету», в процессе извлечения данных из источника, другие — в промежуточной области, третьи — в процессе загрузки данных в ХД. Рассмотрим преимущества и недостатки этих вариантов.

• Преобразование в процессе извлечения данных. На данном этапе лучше всего выполнять преобразование типов данных и производить фильтрацию записей, представляющих интерес для ХД. В идеальном случае должны отбираться только те записи, которые изменялись или создавались после прошлой загрузки. Недостаток — повышение нагрузки на OLTP-систему или БД.
• Преобразование в промежуточной области перед загрузкой данных в хранилище — наилучший вариант для интеграции данных из множества источников, поскольку в процессе извлечения данных, очевидно, этого сделать нельзя. В промежуточной области целесообразно выполнять такие виды преобразований, как сортировка, группировка, обработка временных рядов и т.п.
• Преобразование в процессе загрузки данных в ХД. Отдельные простые преобразования, например преобразование регистров букв в текстовых полях, могут быть выполнены только после загрузки данных в хранилище.

Таким образом, все операции преобразования, которые могут потребоваться при переносе данных в ХД, обычно не сосредотачиваются на одном шаге ETL-процесса, а распределяются по различным этапам в зависимости от того, где выполнение преобразования более эффективно.

Загрузка данных в хранилище

После того как данные извлечены из различных источников и выполнены преобразование, агрегация и очистка данных, осуществляется последний этап ETL — загрузка данных в хранилище. Процесс загрузки заключается в переносе данных из промежуточных таблиц в структуры хранилища данных. От продуманности и оптимальности процесса загрузки данных во многом зависит время, требуемое для полного цикла обновления данных в ХД, а также полнота и корректность данных в хранилище.

Организация процесса загрузки

Первыми в процессе загрузки данных в ХД обычно загружаются таблицы измерений, которые содержат суррогатные ключи и другую описательную информацию, необходимую для таблиц фактов.

При загрузке таблиц измерений требуется и добавлять новые записи, и изменять существующие. Например, измерение Клиент может содержать десятки тысяч клиентов, при этом информация меняется только для незначительного их числа (не более 10%). Нужно добавить данные о новых клиентах и одновременно модифицировать информацию о существующих.

При добавлении новых данных в таблицу измерений требуется определить, не существует ли в ней соответствующая запись. Если нет, то она добавляется в таблицу. В противном случае могут использоваться различные способы обработки изменений в зависимости от того, нужно ли поддерживать старую информацию в хранилище с целью ее последующего анализа. Например, если изменился только адрес клиента, то в большинстве случаев нет необходимости хранить старый адрес, поэтому запись может быть просто обновлена.

Неполная загрузка данных

Одной из основных проблем данного этапа ETL является то, что далеко не всегда данные загружаются полностью: в загрузке некоторых записей может быть отказано. Отклонение записей происходит по следующим причинам.

• На этапе преобразования данных не удалось исправить все критичные ошибки, которые блокируют загрузку записей в ХД.
• Некорректный порядок загрузки данных. Например, предпринимается попытка загрузить факты для значения измерения, которое еще не было загружено. Причиной этого является неправильная разработка ETL-процесса.
• Внутренние проблемы ХД, например недостаток места в нем.
• Прерывание процесса загрузки или остановка его пользователем. Независимо от причин результатом всегда оказывается наличие определенного количества записей, которые не попали в хранилище. Как правило, предусмотрена система извещения пользователя о том, что хранилище содержит не полностью загруженные данные. Это необходимо потому, что если неполные данные будут использованы для анализа (при этом аналитик пребывает в уверенности, что данные достоверны), то последствия могут быть непредсказуемыми. Например, если не до конца загрузились данные о продажах по определенным товарным позициям и последующий анализ выявит падение продаж, то руководство компании может ошибочно исключить такие товары из ассортимента как не пользующиеся спросом, хотя на самом деле это не так.

При появлении данных, попытка загрузки которых потерпела неудачу, необходимо предусмотреть следующие действия (рис.):

• сохранить данные, не попавшие в ХД, в виде таблицы или файла того же формата, что и исходная таблица или файл (такие таблицы обычно называют таблицами исключений);
• провести анализ отклоненных данных для выявления причин, по которым они не были загружены;
• при необходимости произвести дополнительную обработку и очистку данных, после чего предпринять повторную попытку их загрузки.

Если и повторная попытка загрузки данных не увенчалась успехом, то в хранилище окажутся неполные данные, анализ которых может привести к неправильным выводам. Для решения этой проблемы можно:

• восстановить состояние хранилища, каким оно было до загрузки (например, с помощью резервной копии или операции отката, если она предусмотрена);
• полностью очистить в ХД таблицы с неполными данными, чтобы исключить некорректные результаты их анализа;
• оставить все как есть и уведомить пользователя о возникших проблемах. В этом случае аналитик узнает, что загруженная информация недостоверна, и будет использовать ее с определенными ограничениями.

Многопоточная организация процесса загрузки данных

При очередной загрузке в ХД переносится не вся информация из OLTP-системы, а только та, которая была изменена в течение промежутка времени, прошедшего с предыдущей загрузки. При этом можно выделить два вида изменений — добавление и обновление (дополнение).

• Добавление — в ХД передается новая, ранее не существовавшая информация, например сведения о продажах, произошедших с прошлой загрузки, о появлении нового клиента, товара и т.д.
• Обновление (дополнение) — в ХД передается информация, которая существовала ранее, но по какой-либо причине была изменена или дополнена (например, изменился город, в котором живет клиент).

Для распределения загружаемых данных на потоки используются средства мониторинга изменений в данных. Они фиксируют состояние данных в некоторые моменты времени и определяют, какие данные были изменены или дополнены. Применяются следующие методы:

• полное сравнение загружаемых записей со всей информацией, которая уже содержится в хранилище. Данный способ является самым простым и в то же время самым трудоемким в плане вычислительных затрат;
• использование признаков модифицированных данных или полей Дата/Время для определения последнего изменения записи (если такие поля предусмотрены в источнике данных).

Распределение загружаемых данных на поток добавления и поток обновления позволяет выполнять перенос данных в хранилище с помощью обычных запросов, не используя какие-либо фильтры для разделения данных на новые и обновляющие.

Обновление данных должно производиться строго в соответствии с требованиями к обеспечению истории данных, то есть не должно приводить к потере уже существующих данных, за исключением особых случаев.

Следует отметить, что при разработке методики загрузки данных в ХД нет общего подхода к тому, как модифицировать таблицы измерений. Например, если изменилось описание некоторого продукта, придется создать новое поле в таблице, чтобы сохранить старое описание и добавить новое. Если требуется сохранить все старые описания продукта, то придется создавать новую запись для каждого изменения и назначать соответствующие ключи.

Пост загрузочные операции

После завершения загрузки выполняются дополнительные операции над данными, только что загруженными в ХД, перед тем как сделать их доступными для пользователя. Такие операции называются пост загрузочными. К ним относятся переиндексация, верификация данных и т.д.

С точки зрения аналитика, наиболее важной задачей является верификация данных. Прежде чем использовать новые данные для анализа, полезно убедиться в их надежности и достоверности. Для этих целей можно предусмотреть комплекс верификационных тестов. Например:

• при суммировании продаж по одному измерению результат должен совпадать с соответствующей суммой, полученной по-другому, связанному с ним измерению, то есть сумма продаж по всем товарам за месяц должна соответствовать сумме сделок, заключенных со всеми клиентами за тот же период;
• итоговый показатель за месяц должен соответствовать сумме ежедневных или еженедельных показателей в этом месяце;
• суммарная выручка по всем регионам за текущий месяц должна соответствовать сумме продаж по всем региональным дилерским центрам.

Кроме того, может оказаться полезным сравнивать данные не только в различных разрезах после их загрузки в ХД, но и с источниками данных. Так, если значения какого-либо показателя в источнике и хранилище равны, то все нормально, в противном случае данные, возможно, некорректны.

Если тестирование показало, что несоответствия, позволяющие заподозрить потерю или недостоверность данных, отсутствуют, то можно считать загрузку данных в ХД успешной и приступать к анализу новой информации.

Особенности непосредственной загрузки данных из наиболее распространенных типов источников

Наиболее часто встречающимися видами источников данных, доступ к которым производится напрямую, являются:

• текстовые файлы с разделителями (TXT, CSV);
• файлы электронных таблиц Excel;
• файлы плоских таблиц БД, например dBase, FoxPro и т. д. (DBF-файлы);
• реляционные СУБД настольного уровня, например Access и т. д.;
• корпоративные базы данных и учетные системы (Oracle, Informix, Sybase, DB2 и т. д.).

Текстовые файлы с разделителями (TXT, CSV). Файлы в TXT-формате хорошо известны большинству пользователей (даже непрофессиональных) еще со времен MS-DOS. Для создания таких файлов достаточно использовать простейший текстовый редактор, например Блокнот из набора стандартных программ Windows. Однако эти файлы имеют произвольную структуру данных, поэтому они наиболее уязвимы с точки зрения нарушения структуры, использования некорректных форматов и представлений данных. Так что загрузка и очистка TXT-файлов могут вызвать самые серьезные проблемы, несмотря на то что эти файлы очень просты в создании.

Чтобы создать структурированный текстовый файл, который может быть загружен в аналитическую систему, достаточно упорядочить в нем данные в виде вертикальных столбцов и горизонтальных строк, из которых будут сформированы поля и записи соответственно. Для разделения столбцов должны использоваться однотипные символы-разделители, например табуляция, точка с запятой и др. Можно использовать как один символ, так и несколько идущих подряд символов. При создании файла следует придерживаться нескольких правил.

1. В первой строке файла нужно указать заголовки столбцов в произвольной форме, при этом используются кириллица и пробелы. При загрузке в аналитическую систему заголовки столбцов будут преобразованы в метки полей, что позволит аналитику быстрее разобраться с содержимым источника. Поскольку в TXT-файлах имена полей (в том виде, как они представлены в таблицах файлов БД) отсутствуют, при загрузке в аналитическую систему они будут установлены автоматически в соответствии с правилами, принятыми в данной системе. Например, им по умолчанию могут быть присвоены метки COL1, COL2 или FIELD1, FIELD2 и т. д. Если в первой строке текстового файла над каждым столбцом указано его название, то система при загрузке сможет преобразовать эти названия в имена полей, если каким-либо образом указать, что первая строка содержит заголовки. Однако это возможно только при условии, что названия столбцов не противоречат правилам назначения имен полей в данной аналитической системе, то есть не содержат недопустимых символов, не превышают заданную длину и т. д. Это следует учитывать при создании текстовых файлов с разделителями, которые планируется использовать в качестве источников данных для аналитических систем.
2. Необходимо соблюдать регулярность структуры данных, то есть каждые строка и столбец должны содержать одинаковое число элементов. Если некоторые значения были утеряны, то их можно заменить средними значениями по столбцу для числовых атрибутов. Для строковых атрибутов можно указать наиболее вероятное значение или значение по умолчанию, которое впоследствии может быть соответствующим образом обработано (например, NONAME). Оставлять пустые или фиктивные значения нежелательно: пропущенное значение может заблокировать работу аналитических алгоритмов, а фиктивное (например, $999,999) может быть обработано как истинное.
3. Столбцы должны быть типизированы, то есть содержать данные только одного типа (например, только строковые или только числовые). Кроме того, внутри каждого столбца формат представления чисел или дат должен быть одинаковым. Например, использование в одном столбце краткого (12.07.06) и полного (12 июля 2006 г.) форматов даты способно вызвать серьезные проблемы при загрузке данных. Также нежелательно использовать в одном поле числа в экспоненциальном формате (1,2E + 3) и в обычном (12 000), поскольку это может вызвать проблемы при загрузке значений из данного поля.
4. Строковые значения желательно приводить в соответствие унифицированным шаблонам. Например, нежелательно смешивать представление ФИО, указывая инициалы то справа, то слева от фамилии или вообще не указывая, использовать в инициалах то одну, то две буквы и т. д. При указании названий организаций также нужно использовать единое представление. Например, форма собственности должна во всех строках указываться только после названия (это упростит сортировку названий по алфавиту). Несоблюдение этого требования, скорее всего, не вызовет проблем при загрузке, но может привести к неправильной обработке таких данных аналитическим приложением.
5. Символы-разделители и их количество во всех строках и между столбцами должны быть одинаковыми.
6. Необходимо использовать одинаковые разделители целой и дробной частей чисел и групп разрядов. Например, если по умолчанию в качестве разделителя целой и дробной частей используется точка, а в каком-то значении будет обнаружена запятая, это значение будет рассматриваться системой как строковое.

При загрузке в ХД все эти проблемы автоматически корректируются на этапе ETL. А при непосредственной загрузке пользователю приходится отслеживать эти проблемы самому. Если данных в источнике немного, то они могут быть откорректированы вручную. В противном случае приходится использовать средства очистки данных, предусмотренные в аналитической системе (например, восстановление пропущенных значений, трансформация типов и т. д.).

Чтобы настроить процесс импорта текстового файла с разделителями, обычно требуется указать:

• имя файла и путь к нему;
• символ-разделитель, используемый для разделения столбцов;
• используемый формат даты (времени);
• используемые разделители целой и дробной частей чисел и групп разрядов;
• номер строки файла, с которой требуется начать извлечение данных (если все данные извлекать не нужно или нужно извлечь только те данные, которыми файл был пополнен с прошлой загрузки);
• является ли первая строка строкой заголовков. Если да, то содержимое первой строки будет преобразовано в метки полей, а данные начнут загружаться со второй строки.

Таким образом, чтобы правильно настроить параметры импорта текстового файла, нужно иметь информацию о файле, которая в большинстве случаев может быть получена только опытным путем. Для этого достаточно открыть файл с помощью текстового редактора, просмотреть структуру файла и при необходимости откорректировать ее (например, присвоить столбцам заголовки).

Текстовые файлы в формате CSV менее известны пользователям, поскольку используются реже, чем обычные TXT-файлы. CSV (от англ. ramma separated values — «значения, разделенные запятыми») — это специальный текстовый формат, предназначенный для представления табличных данных. Каждая строка в таком файле соответствует одной строке таблицы. Значения отдельных столбцов разделяются специальным символом — запятой или точкой с запятой. Используемый символ-разделитель зависит от настроек региональных стандартов. В США это запятая, а в России — точка с запятой, поскольку у нас запятая используется для разделения целой и дробной частей чисел (в отличие от США, где для этого служит точка). Файлы такого типа могут быть получены путем конвертации из любого табличного процессора.

Все свойства обычных текстовых файлов с разделителями, описанные выше, и рекомендации по их подготовке и загрузке в полной мере относятся к CSV-файлам. Но у CSV-файлов есть и ряд преимуществ.

• Использование унифицированного символа-разделителя (запятой) позволяет избежать разночтений и связанных с этим проблем.
• Поскольку CSV-файлы в большинстве случаев являются результатом преобразования файлов Excel, в них более жестко задана структура строк и столбцов.
• Excel — одно из наиболее популярных офисных приложений, применяемых пользователями всех уровней, поэтому возможность загрузки данных из файлов в формате XLS предусмотрена практически в любой аналитической системе. Однако следует учитывать, что в одном столбце таблицы Excel могут содержаться данные различных типов и форматов, допускаться неправильное использование разделителей целой и дробной частей чисел и групп разрядов в них. В этом плане к ним следует относиться так же внимательно, как и к данным из текстовых файлов.
• Файлы реляционных СУБД. Источники этого типа самые «желанные» для пользователей аналитических систем, поскольку с ними меньше всего проблем. Структура данных в файлах реляционных СУБД жестко задана, поля строго типизированы, форматы данных соответствуют стандартам. В большинстве СУБД поддерживается автоматический контроль целостности, непротиворечивости и уникальности данных. Для загрузки данных, например, из файла Access достаточно указать имя файла и таблицу, из которой нужно взять данные.

Обогащение данных

В большинстве случаев хранилища данных создаются и поддерживаются для обеспечения эффективного анализа данных на предприятии.

Очевидно, что данные, собираемые для задач анализа, должны быть полными и достоверными, поскольку на основе неполных или недостоверных данных нельзя сделать правильные выводы о состоянии бизнеса и путях его совершенствования.

Неполные данные могут появиться, например, если часть сведений о продажах филиала фирмы была утеряна в процессе их переноса в ХД. Аналитик может прийти к выводу, что продажи в этом филиале катастрофически низкие, филиал работает неэффективно и его следует закрыть, хотя на самом деле деятельность филиала вполне успешна, а его сотрудники хорошо справляются со своими задачами. Недостоверные данные, которые при этом могут быть полными, содержат искаженную информацию, не позволяющую провести качественный анализ. Поэтому в процессе загрузки в ХД, а также при подготовке к анализу в аналитическом приложении данные проверяются на полноту, целостность, непротиворечивость, наличие ошибок, пропусков, аномальных значений и других факторов, которые могут привести к некорректным результатам анализа.

Данные и информация

Помимо достоверности и полноты данных, существует еще один фактор, непосредственно влияющий на эффективность их анализа, — информационная насыщенность. Вообще говоря, данные и информация не совсем одно и то же. Каждый сталкивался с ситуацией, когда, несмотря на наличие данных, извлечь из них какую-либо информацию оказывалось невозможно. Например, если вывести на экран компьютера текст с неправильной кодировкой шрифта, мы увидим вместо букв непонятные закорючки, фигурки, спецсимволы и т.д. Данные есть — информации нет. То же самое произойдет, если вы попытаетесь читать текст на иностранном языке, которого не знаете и символы которого вам неизвестны, например на китайском. При этом мы понимаем, что информация есть, но мы не можем ее распознать и осмыслить.

Для извлечения информации из данных может потребоваться их обработка — корректировка представления значений (символов), упорядочение и т.д. Примерами такой обработки служат перевод с неизвестного языка на известный, изменение кодировки символов и т.д. На практике подобная обработка с целью получить из произвольных данных информацию является очень трудоемкой, отнимающей много времени и не гарантирующей результатов. Действительно, если изначально при создании данных в них не закладывалась никакая информация, то и извлечь ее будет невозможно. Попробуйте закрыть глаза и случайно набрать на клавиатуре несколько строк, а затем отнесите набранный фрагмент криптографу, скажите, что это код, и попросите расшифровать его. Скорее всего, усилия специалиста будут напрасны. Если же ему случайно и удастся выявить некоторую закономерность и извлечь какую-то информацию, то о ее достоверности и говорить не приходится.

Таким образом, информация — это не любые данные, а только те, которые соответственным образом представлены и упорядочены, то есть имеют структурные закономерности, которые, кроме всего прочего, должны распознаваться и осмысливаться пользователем. Так, если мы видим текст на языке, символы которого нам незнакомы, мы сталкиваемся с ситуацией, когда упорядоченность данных есть, а соответствующего представления нет. Напротив, если в тексте на известном языке случайным образом переставить буквы, то получится правильное представление, но отсутствие упорядоченности. И в том и в другом случае воспользоваться этими данными мы не сможем, до тех пор пока они не будут соответствующим образом преобразованы.

Данные — понятие объективное. Они либо реально существуют как изменения некоторого физического процесса, либо нет. А информация в большинстве случаев субъективна. Если один эксперт с определенным уровнем компетентности, знаний и опыта увидит в некотором наборе данных полезную информацию, то другой эксперт с другим уровнем опыта и знаний отыщет совсем другую информацию или не найдет ее вовсе.

Приступая к анализу данных с целью поиска скрытых закономерностей и извлечения знаний, мы должны задаться рядом вопросов.

• Имеют ли эти данные вообще какой-нибудь смысл? Присутствует ли в них какая-либо информация?
• Если да, то насколько эта информация надежна и достоверна?
• Достаточно ли этой информации для генерирования надежных и достоверных знаний, на основе которых можно принимать ответственные управленческие решения?

Ответ на первый вопрос во многом определяется происхождением набора данных. Если данные были получены из надежного источника: от подразделения предприятия, из учетной системы, органов госстатистики и т. д. — скорее всего, в том или ином виде информация в них имеется. Правда, иногда для ее извлечения требуется некоторая обработка данных — перекодировка, преобразование форматов и т. д.

Таким образом, если поставщик данных хорошо известен, то и смысл данных определен. Например, если источником данных является бухгалтерия, то они, скорее всего, содержат информацию финансового или учетного характера. Если источником является какая-либо техническая служба предприятия, то и предоставляемая ею информация в большинстве случаев носит технический характер.

Надежность и достоверность проверяются практически на всех этапах аналитического процесса: сначала на этапе загрузки данных в ХД (в процессе ETL), затем в самом ХД (автоматический контроль) и, наконец, в аналитическом приложении при подготовке данных к анализу.

Третий вопрос является самым неоднозначным. Достаточно или недостаточно информации для решения той или иной аналитической задачи, каждый аналитик определяет сам на основании весьма субъективных критериев. Один аналитик даже из минимума информации выжмет максимум полезных знаний с помощью личного опыта, навыков аналитической работы, умелого применения аналитических методов и алгоритмов. Специалисту с меньшей квалификацией, возможно, не удастся решить задачу с любым количеством данных. Кроме того, сами аналитические задачи различаются по уровню сложности и требованиям к информативности исходных данных.

Необходимость обогащения данных

Часто возникают ситуации, особенно при решении нестандартных аналитических задач, когда для анализа требуется информация, которой почему-то не оказалось в наличии. Это может произойти из-за непродуманного процесса сбора данных. Порой базы данных оказываются забиты чем угодно, только не данными, имеющими прямое отношение к основным бизнес-процессам на предприятии. Например, в регистрирующую систему заносят номер автомобиля, на котором вывозят товар, номер путевого листа, ФИО водителя и т.д. А непосредственное отношение к бизнес-процессу имеют только наименование товара, его количество и цена за единицу. Очевидно, что большая часть информации, содержащейся в БД, может заинтересовать разве что начальника охраны, но никак не аналитика по продажам. 

Определение

Обогащение данных — процесс насыщения данных новой информацией, которая позволяет сделать их более ценными и значимыми с точки зрения решения той или иной аналитической задачи.

Можно выделить два основных метода обогащения данных — внешнее обогащение и внутреннее.

Внешнее обогащение предполагает привлечение дополнительной информации из внешних источников, что позволит повысить ценность и значимость данных с точки зрения их анализа. Под повышением значимости данных подразумевается, что на основе их анализа можно будет принимать управленческие решения принципиально нового уровня. Например, обычные данные о текущей работе предприятия позволяют оптимизировать товарные потоки, работу с клиентами, политику скидок, гарантий и т. д. Уже немало, но, поскольку у конкурентов тоже созданы аналитические службы, больших конкурентных преимуществ анализ только оперативной информации не принесет.

Другое дело — стратегический анализ, на основании результатов которого можно поднять работу предприятия на качественно новый уровень и существенно увеличить продажи, а соответственно, и прибыль. Как правило, подобные прорывы связаны с освоением новых рынков, технологий, номенклатуры выпускаемых изделий и т. д. Такие бизнес-проекты в случае успеха сулят большие дивиденды, но требуют очень больших временных и финансовых затрат. Поэтому, если при разработке и реализации масштабных бизнес-проектов допускаются просчеты, не учитываются какие-то факторы, делаются неверные прогнозы и проект заканчивается неудачей, для любого предприятия это очень серьезный удар, грозящий полным крахом.

Для поддержки успешного решения стратегических бизнес-задач необходимо использовать соответствующий уровень анализа данных. Данных из обычных OLTP или учетных систем предприятия для такого анализа, как правило, недостаточно. В этом случае следует привлекать дополнительную информацию из внешних источников. Она позволит обогатить внутренние данные, имеющиеся в распоряжении аналитиков фирмы, до уровня информативности и значимости, который позволит решать задачи стратегического анализа с соответствующим уровнем достоверности.

Внешними источниками могут быть:

• другие предприятия и организации, работающие в этой же сфере деятельности или в смежных сферах, причем как партнеры, так и конкуренты;
• финансово-кредитные учреждения, банки, страховые компании;
• государственные налоговые и статистические службы;
• органы государственного и муниципального управления;
• различные службы социальной сферы: миграционная служба, органы труда и занятости, система здравоохранения, пенсионные фонды и т. д.

Источником информации для обогащения данных могут быть любые организации, которые в процессе своей деятельности собирают, структурируют и хранят информацию, необходимую им для осуществления своих целей.

Внутреннее обогащение не предполагает привлечения внешней информации. В этом случае повышение информативности и значимости данных может быть достигнуто за счет изменения их организации. Не следует путать внутреннее обогащение с обычным преобразованием данных, выполняемым в процессе их загрузки в ХД или при подготовке к анализу в аналитическом приложении. Преобразование данных изначально связано с оптимизацией занимаемого ими объема, скорости доступа к ним, удобства представления для пользователя, обеспечения целостности и непротиворечивости данных, удаления факторов, которые мешают их корректно обрабатывать, и т. д. Такая обработка не преследует цель обогатить данные информацией, а только решает определенные технические проблемы.

Внутреннее обогащение обычно связано с получением и включением в набор данных полезной информации, которая отсутствует в явном виде, но может быть тем или иным способом получена с помощью манипуляций с имеющимися данными. Затем эта информация встраивается в виде новых полей или даже таблиц в ХД и может быть использована для дальнейшего анализа. Для обогащения данных также может использоваться информация, полученная в процессе их анализа.