Информационные технологии поддержки принятия решений на основе хранилищ данных Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 519.816

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ ПОДДЕРЖКИ ПРИНЯТИЯ РЕШЕНИИ

НА ОСНОВЕ ХРАНИЛИЩ ДАННЫХ Шубенин Алексей Алексеевич

К.т.н., начальник научно-исследовательской лаборатории Федеральное государственное бюджетное учреждение «3 Центральный научно-исследовательский институт» Министерства обороны Российской Федерации 107564, г. Москва, Погонный проезд, дом 10, e-mail: ashubenin@yandex.ru Прокина Наталья Владимировна К.т.н., с.н.с., Федеральное государственное бюджетное учреждение «3 Центральный научно-исследовательский институт» Министерства обороны Российской Федерации 107564, г. Москва, Погонный проезд, дом 10, e-mail: nataly_pr@mail.ru Мухин Владимир Николаевич заместитель начальника НТЦ-1 Акционерное Общество «Научно-производственное предприятие «Рубин» 440000, г. Пенза, ул. Байдукова, 2, e-mail: bob12121@mail.ru Поздняков Сергей Юрьевич начальник отделения Акционерное Общество «Научно-производственное предприятие «Рубин» 440000, г. Пенза, ул. Байдукова, 2, e-mail: pozdnyakov-sergey@yandex.ru

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

Ключевые слова: принятие решений, хранение данных, информационные технологии, анализ данных, системный анализ.

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

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

Отличительные характеристики информационных технологий поддержки принятия решений следующие:

- ориентация на решение плохо структурированных задач;

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

- направленность на непрофессионального пользователя компьютера;

- высокая адаптивность методов к характеристикам имеющегося технического и программного обеспечения.

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

1. Архитектура систем поддержки принятия решений. На сегодняшний день можно выделить четыре типа наиболее популярных архитектур СППР, основанных на технологии хранилищ данных: функциональная архитектура, независимые витрины данных, двухуровневое хранилище данных, трехуровневое хранилище данных [5]. Структура СППР с функциональной архитектурой приведена на рис. 1, она является наиболее простой с архитектурной точки зрения. Такие системы часто встречаются на практике, особенно в организациях с невысоким уровнем аналитической культуры и недостаточно развитой информационной инфраструктурой.

Рис. 1. СППР с функциональной архитектурой

Характерной чертой СППР с функциональной архитектурой является осуществление анализа с использованием данных из оперативных систем (источников данных), которые имеют общую черту: они предназначены для реализации отдельных операций (транзакций). Для обозначения таких систем используется термин OLTP (On-Line Transaction Processing -обработка транзакций в режиме реального времени). Транзакционные системы представляют собой источники данных, используемые для последующей аналитической обработки. Данные из транзакционных источников требуется собрать, структурировать и представить в

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

Преимущества СППР с функциональной архитектурой:

- быстрое внедрение за счет отсутствия этапа перегрузки данных в специализированную систему;

- минимальные затраты за счет использования одной платформы.

Недостатки СППР с функциональной архитектурой:

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

- низкое качество данных с точки зрения их роли в поддержке принятия стратегических решений, что обусловлено отсутствием этапа очистки данных;

- невысокое качество выходных данных СППР с функциональной архитектурой;

- большая нагрузка на оперативные системы, которая может привести к остановке работы СППР, что весьма нежелательно.

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

Рис. 2. СППР с независимыми витринами

Есть два подхода к применению витрин данных. Первый подход предполагает, что витрина данных представляет собой локальное хранилище данных, оптимизированное для запросов к данным конкретной предметной области при рассмотрении проблематики принятия решений. При втором подходе витрина рассматривается как OLAP-система (OnLine Analytical Processing), оптимизированная для запросов пользователей к данным

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

Преимущества СППР с витринами данных следующие:

- новые витрины данных можно внедрять в процессе эксплуатации существующих и достаточно быстро;

- витрины проектируются для решения задач принятия решений в интересах отдельных подразделений предприятия;

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

Недостатки СППР с витринами данных:

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

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

- данные не консолидируются на уровне предприятия, таким образом, отсутствует единое представление бизнес-процессов.

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

Рис. 3. СППР с двухуровневым хранением данных

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

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

Преимущества СППР с двухуровневым хранением данных:

данные хранятся в единственном экземпляре; минимальные затраты на хранение данных;

- отсутствие проблемы синхронизации нескольких копий данных;

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

Недостатки СППР с двухуровневым хранением данных:

- данные не структурируются для поддержки потребностей отдельных пользователей или групп пользователей;

- возможны проблемы с производительностью системы;

- возможны трудности с разграничением прав пользователей на доступ к данным системы.

Структура СППР на основе трехуровневого хранения данных приведена на рис. 4.

Рис. 4. СППР с трехуровневым хранением данных

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

Преимущества СППР с трехуровневым хранением данных:

- создание и наполнение витрин данных упрощено, поскольку наполнение происходит из единого надежного источника очищенных нормализованных данных (хранилища);

- витрины данных синхронизированы и совместимы с корпоративным представлением о бизнес-процессах;

- имеется корпоративная многомерная модель данных, на основе которой существует возможность расширения хранилища данных и добавления новых витрин данных при минимальных затратах;

- гарантированная производительность системы при принятии решений.

Недостатки СППР с трехуровневым хранением данных:

- избыточность хранимых данных, которая приводит к росту требований на хранение данных;

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

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

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

- высокая степень нормализации;

- при возникновении ошибки транзакция должна целиком «откатиться» и вернуть систему к состоянию, которое было до начала транзакции;

- обеспечение обработки данных в реальном времени.

Системы OLTP обладают функциональными возможностями, ограниченность которых при обработке больших объемов данных осознана в 90-х гг. XX в. Вместе с тем накопленные объемы данных о результатах деятельности предприятий имеют большую ценность. Использование имевшихся в распоряжении компаний систем OLTP в целях анализа данных и принятия решений не привело к ожидаемым результатам, поэтому возникла необходимость в аналитических системах, в том числе и СППР, оперирующих большими объемами исторических данных. В качестве решения данной проблемы возникла технология OLAP (On-Line Analytical Processing, оперативная аналитическая обработка данных).

Основоположником технологии OLAP является Э. Кодд. В 1993 г. он опубликовал статью под названием «OLAP для пользователей-аналитиков: какой он должен быть», в ней он сформулировал двенадцать основных правил, которые должны служить основой для

выбора наиболее подходящих инструментов OLAP [6]. Впоследствии количество правил выросло до 18, и они были разбиты на четыре группы. Для того, чтобы упростить проверку на соответствие инструментов OLAP необходимым требованиям, на основе правил, разработанных Коддом, в 1995 году был разработан тест FASMI (Fast Analysis Shared Multidimensional Information, Быстрый Анализ Разделяемой Многомерной Информации). Приложение должно иметь возможность обращаться к любой нужной информации, независимо от ее объема и места хранения. Также OLAP-система должна поддерживать анализ, определяемый бизнес-процессами организации, и статистический анализ. Отмечается, что необходима возможность использования основных операций OLAP, к которым, как правило, относят операции среза (Slice), вращения (Rotate), консолидации (Drill Up) и детализации (Drill Down). Требования включают в себя также обеспечение одинаково высокой скорости выполнения всех запросов к системе. Рекомендованным временем для выполнения большинства аналитических запросов указано 5 с., при этом допустимым временем выполнения для наиболее сложных запросов считается 20 с. В системе должен быть обеспечен многопользовательский доступ к данным, при этом необходимо обеспечивать разграничение информации. Ключевым требованием данного теста является предоставление пользователям возможности работы с многомерной моделью, отвечающей представлениям пользователей о деятельности и структуре организации. При этом многомерное концептуальное представление данных может быть обеспечено без организации многомерного хранилища [1, 3].

Автором концепции ХД считается Билл Инмон [9] . ХД он определил как «предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные с целью поддержки управления». Впоследствии Инмон внес большой вклад в развитие данной концепции. Метод проектирования ХД, описываемый Инмоном, получил название «сверху вниз» и часто характеризуется как классический. Другим автором, внесшим большой вклад в развитие технологии хранилищ данных, является Ральф Кимбалл [10]. Подход, предлагаемый им, получил название «снизу вверх». Девятишаговая методология, описанная Кимбаллом, является одним из наиболее часто используемых подходов к проектированию хранилищ данных.

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

По способу реализации многомерной модели данных OLAP- системы делятся на три группы:

- MOLAP (Multidimensional OLAP) - исходные и агрегатные данные хранятся в многомерной базе данных. Хранение данных в многомерных структурах позволяет манипулировать данными как многомерным массивом, благодаря чему скорость вычисления агрегатных значений одинакова для любого из измерений. Однако в этом случае многомерная база данных оказывается избыточной, так как многомерные данные полностью содержат исходные реляционные данные. Также минусом является необходимость специального инструмента для формирования кубов и их пересчета в случае изменения базовых значений [2].

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

ляционной СУБД, предназначенной для хранилища данных, были сформулированы Red Brick Systems. Плюсом данного подхода является то, что все данные хранятся в одном формате внутри одной СУБД. Минусами являются чрезмерное увеличение объема таблицы данных для куба и сложность пересчета агрегированных значений при изменении начальных данных [2].

- HOLAP (Hybrid OLAP) - исходные данные остаются в той же реляционной базе данных, где они изначально находились, а агрегатные данные хранятся в многомерной базе данных. Технология HOLAP пытается совместить преимущества MOLAP и ROLAP, но при этом не достигаются скорость обработки данных, характерная для MOLAP, и целостность хранения данных, а также возрастают затраты на поддержку и определение типа хранения для подкубов [2].

Существуют три основных схемы ХД: «Звезда», «Снежинка» и «Созвездие». Модель данных «Звезда» является наиболее простой структурой данных, состоящей из одной таблицы фактов и нескольких таблиц измерений. Структура модели «Звезда» приведена на рис. 5. Модель содержит шесть измерений (сущностей, классов, таблиц): «Кафедра»; «Руководитель»; «Ученая степень»; «Научная специальность»; «Аспирант»; «Показатель». Сущность (таблица) «Запись» соответствует фактам, характеризующим деятельность аспирантов в определенный период времени. Сущность «Показатель» отражает сведения о показателях, по которым оценивается деятельность аспирантов.

Рис. 5. Структура модели данных «Звезда»

Таблица фактов содержит сведения о произошедших событиях в деятельности аспирантов, которые могут быть проанализированы при принятии решений. Таблица измерений содержит атрибуты событий, сохраняемых в таблице фактов, представляющие собой текстовые или иные описания. При этом таблицы измерений имеют первичные ключи к, г, ё, s, a, р, таблица фактов - п, I [4].

Схема «Снежинка» также состоит из таблицы фактов и нескольких таблиц измерений. Отличием является то, что в схеме «Снежинка» таблицы измерений нормализованы, в то время как для схемы «Звезда» характерны полностью денормализованные таблицы измерений. Обобщенная модель данных «Снежинка», содержащая измерения и факты, приведена на рис. 6.

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

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

Рис. б. Структура модели данных «Снежинка»

Таким образом, отличия между ХД и базами данных ОЦГР-систем определяются областями их применения. Отличия между базами данных ОЦГР-систем и хранилищами данных, характерными для OLAP-систем, приведены в табл. 1.

Таблица 1. Сравнение особенностей баз данных OLTP и хранилищ данных

База данных ОЬТР Хранилище данных

Содержит текущие данные Содержит исторические данные

Хранит подробные сведения Хранит подробные сведения, а также частично и полностью обобщенные данные

Данные являются динамическими Данные в основном являются статическими

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

Предсказуемый способ использования данных Средняя и низкая интенсивность обработки транзакций

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

Высокая интенсивность обработки транзакций Предназначено для проведения анализа

Предсказуемый способ использования данных Ориентировано на предметные области

Ориентирована на прикладные области Поддержка принятия стратегических решений

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

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

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. Барсегян А. А., Куприянов М. С., Степаненко В. В., Холод И. И.. Методы и модели анализа данных: OLAP и Data Mining. - СПб. БХВ-Петербург, 2004. 336 с.

2. Барсегян А. А., Куприянов М. С., Степаненко В. В., Холод И. И. Технологии анализа данных: Data Mining, Visual Mining, Text Mining, OLAP/ 2-е изд., перераб. и доп. - СПб. БХВ-Петербург, 2007. 384 с.

3. Исаев Д.В, Родионов А.С. OLAP-система как инструмент современного экономиста // Финансовая газета. 2002. №44. С.14-15

4. Паклин Н. Б., Орешков В. И., Бизнес-аналитика: от данных к знаниям. - СПб. Питер, 2009. - 724 с.

5. Спирли, Э., "Корпоративные хранилища данных. Планирование, разработка и реализация. Т.1". Издательство: Вильямс (2001). 400 стр.

6. Codd E.F., Codd S.B. and Salley C.T. Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate Technical report, 1993

7. Devlin B. Data warehouse: from architecture to implementation. Addison Wesley Longman, Inc. (1997). ISBN 0-201-96425-2.

№yöenun A.A., npoKuna H.B., Myxun B.H., no3duHKoe C.W.

8. IBM. «Business Intelligence Architecture on S/390. Presentation Guide». SG24-5747-00, IBM Corporation (2000).

9. Inmon W Building the Data Warehouse New York: John Willey & Sons, 1992

10. Kimbell R., Ross M. The Data Warehouse Toolkit: The Complete Guide to Dimensional Data Warehouses J. Willey & Sons. Second Edition, 2002 - 447 p

YAK 519.816

INFORMATION TECHNOLOGIES OF SUPPORT DECISION BASED ON DATA WAREHOUSING Aleksey A. Shubenin

PhD, chief research laboratory, Federal state budgetary institution «3 Central Research Institute» of the Ministry of defense of the Russian Federation, Pogonnij tr., 10, Moscow, Russia, 107564, e-mail: ashubenin@yandex.ru

Natalia V. Prokina

PhD, senior researcher, Federal state budgetary institution «3 Central Research Institute» of the Ministry of defense of the Russian Federation, Pogonnij tr., 10, Moscow, Russia, 107564, e-mail: nataly_pr@mail.ru

Vladimir N. Muhin

Deputy head of scientific-technical center, Joint stock Company "Scientific-production enterprise "Rubin" Baidukov str., 2, Penza, Russia, 440000, e-mail: bob12121@mail.ru

Sergey Y. Pozdnyakov Head of division, Joint stock Company "Scientific-production enterprise "Rubin" Baidukov str., 2, Penza, Russia, 440000, e-mail: pozdnyakov-sergey@yandex.ru

Abstract. The main feature of informational support of decision-making is a qualitatively new organization of interaction between man and computer. Developing of solutions is the main goal of this technology. Decision making occurs as a result of the iterative process, which involves a system of decision support and management specifying the input data and evaluates the result. The end of the iterative process happens by the will of man. Information technology of decision support can be used at any level of management. Decisions made at various levels of management, as a rule, should be coordinated. Therefore, an important function of DSS is to coordinate the decision-makers at different management levels. The article describes the system architecture of the decision support and online analytical processing data. The content of the article is devoted to the description of the most popular types of DSS architectures with advantages and disadvantages, as well as the processing technologies in real time.

Keywords: decision making, data storage, information technologies, analysis of data, system analysis.

References

1. Barsegyan A., Kupriyanov M., V. Stepanenko, Holod I.. Metodi i modeli analiza dannih: OLAP h Data Mining [Methods and models of the analysis of data: OLAP and Data Mining]. St. Petersburg, 2004. 336 p. (in Russian).

2. Barsegyan A., Kupriyanov M., Stepanenko V., Holod I.. Tehnologii analiza dannih: Data Mining, Visual Mining, Text Mining, OLAP [Holod Technologies of the analysis of data: Data Mining, Visual Mining, Text Mining, OLAP]. 2-ye izd. pererab. I dop. - SPb. BHV-St. Peterburg, 2007. 384 p. (in Russian).

3. Isaev D.V., Rodionov A.S. OLAP-sistema kak instrument sovremennogo ekonomista. [OLAP-system as a tool of the modern economist]. Finansovaya gazeta = Financial newspaper. 2002. № 44. pp.14-15 (in Russian).

4. Paklin N., Oreshkov V. Biznes-analitika: ot dannih k znanijam [Business analyst: from data to knowledge]. St. Peterburg, 2009. 724 p. (in Russian).

5. Spirli E. Corporativnye hranilisha dannyh. Planirovanie, razrabotka i realizaciya. [Corporate data warehouse. Planning, development and implementation]. № 1, 2001. 400 p. (in Russian).

6. Codd E.F., Codd S.B. and Salley C.T. Providing OLAP (on-line analytical processing) to user-analysts: An IT mandate. Technical report, 1993.

7. Devlin B. Data warehouse: from architecture to implementation. Addison Wesley Longman, Inc. (1997). ISBN 0-201-96425-2.

8. IBM. «Business Intelligence Architecture on S/390. Presentation Guide». SG24-5747-00, IBM Corporation (2000).

9. Inmon W. Building the Data Warehouse New York: John Willey & Sons, 1992.

10. Kimbell R., Ross M. The Data Warehouse Toolkit: The Complete Guide to Dimensional Data Warehouses J. Willey & Sons. Second Edition, 2002. 447 p.