Принципы построения систем, ориентированных на анализ данных

При построении 1-й очереди ЕАИС акцент делался на классические методы проектирования базы данных, т. е. на системы, ориентированные на обработку транзакций в реальном времени (On-Line Transaction Processing — OLTP).

OLTP-системы ориентированы на выполнение транзакций, информация в них носит оперативный характер. Записи в OLTP-системах могут регулярно добавляться, удаляться и редактироваться. OLTP-система выдает ответы на простые вопросы типа «Каков был уровень импорта товара N в регионе М в январе 2004 года?». Традиционные системы OLTP оперируют такими понятиями, как сущность, связь, функциональная декомпозиция и анализ изменения состояний.

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

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

Хранилища данных

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

В большинстве случаев сложный аналитический запрос невозможно сформулировать в терминах языка SQL, поэтому для получения информации применяют специальные языки, ориентированные на аналитическую обработку данных. К их числу можно, например, отнести язык Express 4GL фирмы Oracle. Также для выполнения запросов могут быть использованы приложения, написанные специально для решения тех или иных задач.

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

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

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

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

Перечисленные особенности СППР привели к тому, что данные, используемые для анализа, стали выделять в отдельные базы данных, получившие название хранилищ данных (ХД).

Концепция информационных хранилищ данных (первоначально она так и называлась — Information WareHouse) зародилась в 80-х гг. XX в. в недрах корпорации IBM, но все же «отцом» технологии считается Билл Инмон, технический директор компании Prism.