Введение в основы OLAP. Хранилища данных: основные архитектуры и принципы построения в реляционных субд

Понятие хранилища данных

«Хранилище данных»- это предметно-ориентированное, привязанное ко времени и неизменяемое собрание данных для поддержки процесса принятия управляющих решений.

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

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

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

Зачем нужно строить хранилища данных - ведь они содержат заведомо избыточную информацию, которая и так находится в базах или файлах оперативных систем? Анализировать данные оперативных систем напрямую невозможно или очень затруднительно. Это объясняется различными причинами, в том числе разрозненностью данных и хранением их в форматах различных СУБД. Но даже если на предприятии все данные хранятся на центральном сервере БД, аналитик почти наверняка не разберется в их сложных, подчас запутанных структурах.

Таким образом, задача хранилища - предоставить «сырье» для анализа в одном месте и в простой, понятной структуре.

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

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

Концепция хранилища данных

Автором концепции хранилищ данных (Data Warehouse) является Б. Инмон, который определил хранилища данных как: «предметно-ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления», призванные выступать в роли «единого и единственного источника истины», обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений. Схему хранилища данных можно представить следующим образом:

Физическая реализация данной схемы может быть самой разнообразной. Рассмотрим первый вариант - виртуальное хранилище данных, это система, предоставляющая доступ к обычной регистрирующей системе, которая эмулирует работу с хранилищем данных. Виртуальное хранилище можно организовать двумя способами. Можно создать ряд «представлений» (view) в базе данных или использовать специальные средства доступа к базе данных (например, продукты класса desktop OLAP).

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

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

В основе концепции хранилищ данных лежат две основополагающие идеи:

1) интеграция ранее разъединенных детализированных данных в едином хранилище данных, их согласование и, возможно, агрегация:

· исторических архивов;

· данных из традиционных СОД;

· данных из внешних источников.

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

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

Таблица 1. Основные требования к данным в Хранилище Данных.

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

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

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

Для правильного понимания данной концепции необходимо уяснение следующих принципиальных моментов:

· Концепция хранилищ данных - это не концепция анализа данных, скорее, это концепция подготовки данных для анализа.

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

·Концепция хранилищ данных предполагает не просто единый логический взгляд на данные организации, а реализацию единого интегрированного источника данных.

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

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

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

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

Похожая информация.

Стремление объединить в одной архитектуре СППР возможности OLTP-систем исистем анализа,привело к появлению концепции х ра н и л ищ д а н ны х (ХД).

Концепция ХД так или иначе обсуждалась специалистами в области инфор-

мационных систем достаточно давно. Первые статьи,посвященные именно ХД,появились

в 1988 г., их авторами были Б. Девлин и П. Мэрфи. В 1992 г. У. Инмон подробно описалданную концепцию в своей монографии "Построение хранилищ данных" ("Building the Data Warehouse", second edition - QED Publishing Group, 1996).

В основе концепции ХД лежит идея разделения данных, используемых для

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

В своей работе Инмон дал следующее определение ХД.

Х ра ни л и щ е д а н н ы х -предметно-ориентированный,интегрированный,

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

Рассмотрим свойства ХД более подробно.

П р ед м е т н ая о ри е н т а ци я. Это фундаментальное отличие ХД от ОИД.

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

Предметная ориентация позволяет также хранить в ХД только те данные, которые

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

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

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

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

Такая модель неизбежно приводит к дублированию информации в ОИД и в ХД.

Однако Инмон в своей работе утверждает, что избыточность данных, хранящихся в

СППР, не превышает 1 %! Это можно объяснить следующими причинами.

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

Информация в ОИД носит, как правило, оперативный характер, и данные, потеряв

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

Во время загрузки в ХД данные очищаются (удаляется ненужная информация), и

после такой обработки они занимают гораздо меньший объем.

Подсистем а ввода(OLTP)

П о д с и с т е м

Аналитические запросы

П о д с и с т е м

О п е р а т о

Подсистем а ввода(OLTP)

а анализа

Р и с у н о к 7. Структура СППР с физическим ХД

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

Подсистем а ввода(OLTP)

Подсистем а ввода

Подсистема храненияинформации

Аналитические запросы

Подсистем а анализа(OLAP,

О п е р а т о

В и р т у а л ьн о е

Р и с у н о к 8. С т р у к т у ра С ПП Р с в и р т у а л ь н ы м Х Д

Однако такой подход обладает многими недостатками.

Время обработки запросов к виртуальному ХД значительно превышает соот-

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

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

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

Различные ОИД могут поддерживать разные форматы и кодировки данных. Часто

на один и тот же вопрос может быть получено несколько вариантов ответа. Это можетбыть связано с:

несинхронностью моментов обновления данных в разных ОИД; отличиями в описании одинаковых объектов и событий предметной области; ошибками при вводе; утерей фрагментов архивов и т. д.

В таком случае цель - формирование единого непротиворечивого взгляда наобъект управления - может быть не достигнута.

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

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

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

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

Остановимся на основных проблемах создания ХД:

необходимость интеграции данных из неоднородных источников в рас-

пределенной среде;

потребность в эффективном хранении и обработке очень больших объемов информации; необходимость наличия многоуровневых справочников метаданных; О

повышенные требования к безопасности данных. Рассмотрим эти проблемы более

подробно.

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

По т р е б н о с т ь в э ф ф е к т и в н ом х р а н е ни и и о б р або т к е о че н ь бол ь ш и х об ъ е мов ин ф о р ма ц и и . Свойство неизменности ХД предполагает накопление в нем информации задолгий период времени, что должно поддерживаться постоянным ростом объемовдисковой памяти. Ориентация на выполнение аналитических запросов и связанная с этимденормализация данных приводят к нелинейному росту объемов памяти, занимаемой ХДпри возрастании объема данных. Исследования, проведенные на основе тестового набораTPC-D, показали, что для баз данных объемом в 100 Гбайт требуется память, в 4,87 разабольшая объемом,чем нужно для хранения полезных данных.

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

Повы ш е ни е т р е бова ни й к б е зо п а с н о с т и д а нн ы х . Собранная вместе и со-

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

данных из оперативных баз данных и внешних источников, защиты данных при ихпередаче по сети и т.п.

Снижения затрат на создание ХД можно добиться, создавая его упрощенный

вариант - витрину данных (Data Mart).

В и т р ин а д а н ны х (В Д ) - это упрощенный вариант ХД, содержащий только тема-

тически объединенные данные.

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

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

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

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

Подсистем а ввода(OLTP)

Подсистема храненияинформации

Аналитические запросы

Подсистем а анализа(OLAP,

П о д с и с т е м

О п е р а т о

Подсистем а ввода(OLTP)

а анализа

Р и с у н о к 9. Структура СППР с самостоятельными ВД

Недостатками автономных ВД являются:

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

следовательно - отсутствие единой картины.

В последнее время все более популярной становится идея совместить ХД и ВД в

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

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

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

Достоинствами такого подхода являются:

простота создания и наполнения ВД, поскольку наполнение происходит из единого стандартизованного надежного источника очищенных данных - из ХД; простота расширения СППР за счет добавления новых ВД; с ни ж е ни е н а г р у з к и н а о с н о в н о е Х Д.

Подсистем а ввода(OLTP)

Подсистема храненияинформации

Аналитические запросы

П о д с и с т е м

О п е р а т о

Подсистем а ввода(OLTP)

А н а л и т и че с к и е

ХД запросы

ВД

а анализа

Подсистем а анализа(OLAP,

Р и с у н о к 10. Структура СППР с ХД и ВД

К недостаткам относятся:

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

Подводя итог анализу путей реализации СППР с использованием концепции ХД,можно выделить следующие архитектуры таких систем:

СППР с физическим (классическим) ХД (см. рис. 1); СППР с виртуальным ХД (см. рис. 2); СППР с ВД (см. рис. 3); СППР с физическим ХД и с ВД (рис. 4).

В случае архитектур с физическим ХД и/или ВД необходимо уделить внимание

вопросам организации (архитектуры) ХД и переносу данных из ОИД вХД.

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

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

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

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

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

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

Общая идея хранилищ данных заключается в разделении БД для OLTP-систем и БД для выполнения анализа и последующем их проектировании с учетом соответствующих требований. Концепция ХД так или иначе обсуждалась специалистами в области информационных систем достаточно давно. Первые статьи, посвященные именно ХД, появились в 1988 г., их авторами были Б. Девлин и П. Мэрфи. В 1992 г. У. Инмон подробно описал данную концепцию в своей монографии "Построение хранилищ данных" ("Building the Data Warehouse", second edition - QED Publishing Group, 1996).

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

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

Ниже дадим общую характеристику основных свойств ХД

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

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

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

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

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

Такая модель неизбежно приводит к дублированию информации в ОИД и в ХД.

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

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

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

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

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

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

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

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

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

Потребность в эффективном хранении и обработке очень больших объемов информации;

Необходимость наличия многоуровневых справочников метаданных;

Повышенные требования к безопасности данных.
Рассмотрим эти проблемы более подробно.

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

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

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

Сбор и хранение информации, а также решение задач информационно-поискового запроса эффективно реализуются средствами систем управления базами данных (СУБД). В OLTP ( Online Transaction Processing )-подсистемах реализуется транзакционная обработка данных. Непосредственно OLTP-системы не подходят для полноценного анализа информации в силу противоречивости требований, предъявляемых к OLTP-системам и СППР .

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

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

Подсистема анализа может быть построена на основе:

подсистемы информационно-поискового анализа на базе реляционных СУБД и статических запросов с использованием языка SQL;
подсистемы оперативного анализа. Для реализации таких подсистем применяется технология оперативной аналитической обработки данных OLAP, использующая концепцию многомерного представления данных;
подсистемы интеллектуального анализа, реализующие методы и алгоритмы Data Mining.

Понятие хранилища данных

Технология ХД предназначена для хранения и анализа больших объемов данных с целью дальнейшего обнаружения в них скрытых закономерностей и, наряду с технологией Data Mining, входит в понятие "предсказательная аналитика". Data Mining, в свою очередь, изучает процесс нахождения новых, действительных и потенциально полезных знаний в базах данных.

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

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

Физические и виртуальные хранилища данных

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

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

Достоинства виртуального ХД:

минимизация объема хранимых данных;
работа с текущими, актуальными данными.

Недостатки виртуального ХД:

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

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

Введение

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

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

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

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

Определение и типовые архитектуры ХД

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

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

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

Виртуальное хранилище данных это система, представляющая интерфейсы и методы доступа к регистрирующей системе, которые эмулируют работу с данными в этой системе, как с хранилищем данных. Виртуальное хранилище данных можно организовать, создав ряд представлений (view) в базе данных, либо применив специальные средства доступа, например продукты класса Desktop OLAP, к которым относится, например, BusinessObjects, Brio Enterprise и другие .

Главными достоинствами такого подхода являются:

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

	Производительности;
	Трансформации данных;
	Интеграции данных с другими источниками;
	Отсутствия истории;
	Чистоты данных;
	Зависимость от доступности основной БД;
	Зависимость от структуры основной БД.

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

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

Проектирование структуры реляционного хранилища данных

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

К числу мало освещенных тем можно отнести проблему представления иерархий. В качестве примера измерения, широко применяющегося при анализе деятельности предприятия и имеющего иерархическую структуру, можно привести справочник статей затрат. Рассмотрим модель мест возникновения затрат (МВЗ), представленную на рис 2.

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

		Parent ID
1	Предприятие
2	Управление
3	Инфраструктура
4	Производство
5
6	Сервисные услуги
7	Месторождение A
8	Месторождение B

Таблица 1.

Однако в простоте этого решения скрывается и основной его недостаток. К сожалению, стандартный SQL не поддерживает рекурсивные указатели, поэтому для представления деревьев в ХД используют другие методы.

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

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

select sum(fact_table.cost)
from fact_table, dimension_table D1, dimension_table D2
where fact_table.dimension_id = D2.id
and D2.left >= D1.left
and D2.right <= D1.right
and D1.name = "Инфраструктура"

Для простоты работы с таким справочником кроме полей left, right стоит добавить еще два поля: "Level" уровень узла в дереве, "Is_leaf" флаг, показывающий является ли узел листом в дереве или нет. Таким образом, мы получаем таблицу "dimension_table" (см. таблицу 2), которая позволяет хранить дерево любой глубины вложенности и размерности и позволяет выбирать потомков и родителей с помощью одного запроса.


1		Предприятие
2		Управление
3		Инфраструктура
4		Производство
5
6		Сервисные услуги
7		Месторождение A
8		Месторождение B

Таблица 2. Представление иерархий с помощью левой и правой границ

Другой способ, описанный Ральфом Кимбаллом , основан на введении вспомогательной таблицы ("helper-table"), через которую осуществляется связь таблицы фактов с таблицей измерения. Эта вспомогательная таблица отражает иерархическую структуру измерения и подчиняется следующему закону: вспомогательная таблица содержит весь набор пар "родитель-потомок", причем потомок может не быть непосредственным потомком родителя. Структура такой таблицы и ее содержимое показано в таблице 3.

Parent ID	Child ID	Distance
1
1
1
1
1
1
1
1
2	2	0	Y
3	3	0	N
3	5	1	N
3	6	1	N
4	4	0	N
4	7	1	N
4	8	1	N
5	5	0	Y
6	6	0	Y
7	7	0	Y
8	8	0	Y

Таблица 3. Структура и содержание вспомогательной таблицы.

Теперь связывая таблицу фактов (см. рис. 4) с идентификатором ребенка во вспомогательной таблице, а таблицу измерений с идентификатором родителя, мы можем вычислять сумму затрат для каждого МВЗ и всех его составляющих одним запросом, как и в предыдущем случае. При этом, добавляя ограничения на поля "Distance" и "Is Leaf", мы можем легко считать затраты для любого уровня в иерархии.

select sum(fact_table.cost)
from fact_table, dimension_table, helper_table
where fact_table.dimension_id = helper_table.child_id
and dimension_table.dimension_id = helper_table.parent_id
and dimension_table.name = "Инфраструктура"
and helper_table.distance = 1

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

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

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

Рассмотрим его более подробно (см. рис. 5). Таблица "dimension_actual" представляет собой таблицу измерений с первичным ключом dimension_id, содержащей корректные атрибуты измерения на сегодняшний день. С ней связана через внешний ключ dimension_id историческая таблица "dimension_history", в которой находится история изменения записей, определяемая датами начала/окончания действия записи (поля date_start, date_end). Актуальная на сегодняшний день запись также присутствует в ней с открытой датой окончания действия. Таблица фактов "fact_table" связана с таблицей измерений через вспомогательную таблицу "helper_table", которая отражает иерархическую структуру измерения.

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

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

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

Заключение

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

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

ЛИТЕРАТУРА

1.	Joerg Reinschmidt, Allison Francoise. Business Intelligence Certification Guide. IBM Red books;
2.	Inmon W. Building the Data Warehouse. New York: John Willey & Sons, 1992;
3.	Спирли, Эрик. Корпоративные хранилища данных. Планирование, разработка, реализация. Том. 1: Пер. с англ. М.: Издательский дом "Вильямс", 2001;
4.	Joe Celko. Trees in SQL: Intelligent Enterprise, October 20, 2000;
5.	Дональд Э. Кнут. Искусство программирования, том 1. Основные алгоритмы, 3-е изд.: М. : Издательский дом "Вильямс", 2000.;
6.	Ralph Kimball. Help for Hierarchies: DBMS September 1998;
7.	Ralph Kimball. Slowly Changing Dimensions: DBMS April 1996;
8.	Статистический словарь: М. "Финансы и статистика", 1989;
9.	Дюк В, Самойленко А, Data mining: учебный курс. СПб: Питер, 2001;
10.	Erhard Rahm, Hong Hai Do: Data Cleaning: Problems and Current Approaches. IEEE Data Engineering Bulletin 23(4): 3-13 (2000);
11.	Ralph Kimball: The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses. John Wiley 1996;
12.	Maria Sueli Almeida, Missao Ishikawa, Joerg Reinschmidt, Torsten Roeber, Getting Started with Data Warehouse and Business Intelligence. IBM Red books;
13.	Nigel Pendse, OLAP Architectures: The OLAP Report, http://www.olapreport.com/Architectures.htm#top.