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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В СППР (система поддержки принятия решений) эти два типа данных называются соответственно оперативными источниками данных(ОИД) и хранилищем данных.

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

Свойства хранилищ данных:

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

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

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

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

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

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

Это можно объяснить следующими причинами:

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

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

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

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

Недостатки данного подхода:

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

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

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

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

– несинхронностью моментов обновления данных в разных ОИД;

– отличиями в описании одинаковых объектов и событий предметной области;

– ошибками при вводе;

– утерей фрагментов архивов и т. д.

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

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

3) СППР с ВД. Достоинствами такого подхода являются:

Проектирование ВД для ответов на определенный круг вопросов;

Быстрое внедрение автономных ВД и получение отдачи;

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

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

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

Отсутствие консолидированности данных на уровне предметной области, а, следовательно – отсутствие единой картины.

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

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

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

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

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

Простота расширения СППР за счет добавления новых ВД;

Снижение нагрузки на основное ХД.

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

Избыточность (данные хранятся как в ХД, так и в ВД);

Дополнительные затраты на разработку СППР с ХД и ВД.

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Однако в простоте этого решения скрывается и основной его недостаток. К сожалению, стандартный 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), которая позволяет хранить дерево любой глубины вложенности и размерности и позволяет выбирать потомков и родителей с помощью одного запроса.

Другой способ, описанный Ральфом Кимбаллом , основан на введении вспомогательной таблицы ("helper-table"), через которую осуществляется связь таблицы фактов с таблицей измерения. Эта вспомогательная таблица отражает иерархическую структуру измерения и подчиняется следующему закону: вспомогательная таблица содержит весь набор пар "родитель-потомок", причем потомок может не быть непосредственным потомком родителя. Структура такой таблицы и ее содержимое показано в таблице 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". Однако во всех рассмотренных задачах существуют нерешенные вопросы, требующие дальнейших исследований. В частности сложным для реализации является случай иерархических измерений с необходимостью поддержания истории изменений, которые имеют связи с какими-либо другими справочниками. В данную статью не вошли вопросы, касающиеся методов очистки данных и алгоритмов загрузки данных в хранилище. Эти темы требуют отдельного рассмотрения.

ЛИТЕРАТУРА

Отметим, что складирование данных - это развивающаяся технология. Как и для любой развивающейся технологии, определенная доля осторожности должна присутствовать при оценке действий производителей ПО ХД, пытающихся позиционировать себя среди конкурентов. Например, дискуссии о размерах ХД - с какого размера хранилище данных можно считать собственно хранилищем? С 50 ГБ? Заметим, что в некоторых областях исследования размер анализируемого массива может быть очень небольшим. Просто нет данных. А анализ такого массива возможен.

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

Извлечение данных из операционных систем

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

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

Необходимость интегрирования данных из нескольких OLTP-систем

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

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

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

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

Различия между транзакционной и аналитической обработкой данных

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

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

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

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

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

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

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

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

Данные в хранилище данных хранятся значительно более длительное время, чем в OLTP-системах

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

Фактически, проект системы складирования данных может начинаться и без любого определенного плана архивирования данных из ХД. Стоимость сопровождения данных после их загрузки в хранилище невысока. Наибольшие затраты при создании хранилища выпадают на трансформацию данных ( data transfer ) и их очистку ( data scrubbing ). Хранение данных в течение пяти и более лет типично для систем складирования данных . Поэтому процедурам архивизации данных из ХД на стадиях их создания и эксплуатации в начале периода можно не уделять много времени. Особенно если учесть снижение цен на аппаратные средства ЭВМ.

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

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

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

Рис. 1.5.

Логическое преобразование данных OLTP-систем и моделирование данных

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

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

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

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

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

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

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

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

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

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

Преобразование информации, описывающей состояние объектов в OLTP-системе

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

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

Рассмотрим более сложный пример трансформации данных при управлении запасом товара в OLTP-системе. Запас может изменяться в каждой транзакции. Количество конкретного товара на складе может быть уменьшено транзакцией подсистемы заполнения заказа или увеличено при поступлении купленного товара. Если система обработки заказа выполняет десятки тысяч транзакций в день, то, вероятно, фактический уровень запаса в БД будет иметь много состояний и зафиксируется во многих снимках в течение этого дня. Невозможно зафиксировать все эти постоянные изменения в БД и перенести их в ХД. Отображение такого поведения объекта в системе – источнике данных по-прежнему является одной из нерешенных задач в системах складирования данных . Есть ряд подходов к решению этой проблемы. Например, можно периодически фиксировать снимки уровня запаса в ХД.

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

Денормализация модели данных

Следующий момент в проектировании реляционных ХД состоит в решении вопроса о том, насколько важно в ХД соблюдать принципы реляционной теории, а именно: разрешить денормализацию модели, в частности, для увеличения производительности запросов. Прежде чем мы рассмотрим денормализацию модели данных в контексте складирования данных, давайте кратко вспомним основные моменты теории реляционных БД и процесса нормализации . Е.Ф. Кодд разработал реляционную теорию БД в конце 60-х прошлого века, когда он работал в исследовательском центре IBM. Сегодня большинство популярных платформ БД полностью следует этой модели. Реляционная модель БД - коллекция двухмерных таблиц, состоящих из рядов и колонок. В терминологии реляционной модели эти таблицы, строки и колонки соответственно называются отношениями или сущностями, кортежами, атрибутами (attribute) и доменами (domain). Модель идентифицирует уникальные ключи (Key) для всех таблиц и описывает отношения между таблицами через значения атрибутов (ключей).

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

• Первая нормальная форма 1NF ( 1НФ ). Говорят, что отношение находится в первой нормальной форме, если оно описывает одну единственную сущность и не содержит в качестве атрибутов массивов или повторяющихся групп значений. Например, таблица заказов, включающая в себя позиции заказа, не будет находиться в первой нормальной форме, поскольку содержит повторяющиеся атрибуты для каждой позиции заказа.
• Вторая нормальная форма 2NF (2НФ). Говорят, что отношение находится во второй нормальной форме , если оно находится в первой нормальной форме и все неключевые атрибуты функционально полно зависят от первичного ключа отношения .
• Третья нормальная форма 3NF (3НФ). Говорят, что отношение находится в третьей нормальной форме , если оно находится во второй нормальной форме и его неключевые атрибуты полностью независимы друг от друга.

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

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

Статичность взаимосвязей в исторических данных

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

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

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

Физическое преобразование данных приложений источников

Важным моментом в системах складирования данных является физическое преобразование данных. Эти процедуры в складировании данных известны как процессы очистки данных (" data scrubbing ", "data staging" или "data purge "). Процесс очистки данных является наиболее интенсивным и трудоемким в любом проекте создания ХД. Физическое преобразование включает использование стандартных терминов предметной области ХД и стандартов данных. В течение процесса физического преобразования данные находятся в некотором промежуточном файле до того, как будут занесены в ХД. Когда данные собираются из многих приложений, их целостность может быть проверена в течение процесса формирования преобразованных данных до загрузки в ХД.

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

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

Различные подсистемы OLTP-систем и внешних источников данных могут использовать различное определение доменов атрибутов на физическом уровне представления данных . Так, атрибут типа "идентификатор продукта" в одной системе имеет длину от 12 символов, а в другой - 18 символов. С другой стороны, ПО одних существующих систем может иметь ограничения на определение длин имен атрибутов и бедный набор типов для определения доменов, а в других такие ограничения могут отсутствовать и может предоставляться широкий выбор типов атрибутов.

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

Все атрибуты в ХД должны согласованно использовать предопределенные значения. В различных приложениях могут быть приняты различные соглашения по предопределенным значениям атрибутов. К таким предопределенным значениям относятся значения по умолчанию, значения, заменяющие null-значения, и т. п. Например, признак пола в различных системах может иметь различные значения: в одних это символьные значения "М" и "Ж", в других - цифровые значения 0 и 1. Более неприятным примером является случай, когда одно значение данных используется в приложении в нескольких целях, т.е. атрибут на самом деле представляет множественное значение. Например, когда в атрибуте "тип метода измерения" две первые цифры означают метод измерения, а две вторые - метод физического контроля измерения. Такие различные значения перед загрузкой в ХД должны быть преобразованы к принятому в ХД предопределенному значению.

В некоторых системах - источниках данных могут отсутствовать значения (проблема пропущенных значений, "missing data") или преобразование для них не может быть выполнено (" corrupt data " - данные, для которых преобразование не может быть выполнено). Важно, чтобы в процессе преобразования такие данные принимали в ХД значения, которые позволяли бы пользователям интерпретировать их правильно. Одним атрибутам можно просто назначить разумное значение по умолчанию в случае отсутствия значения или конфликтов при преобразовании, а другим атрибутам - определить значения из значений прочих атрибутов. Например, пусть в сущности "Заказ" значение атрибута единицы измерения товара пропущено. Это значение может быть получено из соответствующего атрибута сущности "Товар" этой системы-источника. Для некоторых атрибутов не существует подходящих значений по умолчанию в случае, когда их значения отсутствуют. Для таких пропущенных значений в ХД следует также определять значение по умолчанию, например, как null-значение.

Приведены основные отличия использования данных в

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

Билл Инмон, автор концепции, в своей классической статье «Что такое хранилища данных» (D2K Incorporated, 1996) определяет хранилища данных как «предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления». Он рассматривает хранилища как «единый и единственный источник истины», «центр вселенной» систем поддержки принятия решений (СППР). «Из хранилищ данных,– пишет он,– информация перетекает в различные отделы, отфильтровываясь в соответствии с заданными настройками СППР. Эти отдельные базы данных для принятия решений называются витринами данных».

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

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

Сравнение характеристик данных в информационных системах , ориентированных на операционную и аналитическую обработку данных

Основные требования к данным в хранилище данных

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

Модели анализа данных

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

1. Статический анализ (DSS). Само понятие DSS (Decision Support Systems) собственно и переводится как СППР. До недавнего времени это была единственная аналитическая концепция. Результатом работы таких систем являлись строго регламентированные многостраничные отчеты, для формирования которых выполнялись длительные запросы, обрабатывающие колоссальные объемы данных. Такие запросы могли выполняться по нескольку часов, иногда десятки часов и даже сутками.

2. Оперативный анализ данных (OLAP). Автором концепции OLAP (On-Line Analytical Processing) является д-р Э. Кодд, сформулировавший в 1993 г. 12 основных требований к средствам реализации OLAP. Принципиальным отличием этой модели от традиционной статической DSS является концептуальное представление данных в виде многомерного куба. В то же время Э. Кодд показал потенциальные недостатки реляционного подхода в системах, ориентированным на анализ данных. Целью создания этой концепции являлась принципиальная возможность предоставления конечному пользователю средств формирования, обработки и выполнения нерегламентированных аналитических запросов с минимальным временем отклика системы. Необходимость возникновения этой новой концепции была предопределена тем фактором, что зачастую после получения стандартного отчета средствами DSS у аналитика появлялся новый вопрос или осознание того, что сам вопрос был сформулирован некорректно. В результате ему приходилось вновь долгое время ожидать получения очередного результата с тем, чтобы затем, возможно, вернуться к очередной итерации этого процесса.

Сравнение характеристик статического и динамического анализа

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

Витрины данных

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

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

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

Технология реализации хранилищ данных

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

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

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

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

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

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

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

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

8. Установка средств OLAP, прикладных систем, Web-серверов и всех необходимых инструментов и серверных программ, необходимых для доступа к данным, анализа и получения отчетов.

9. Установка на рабочие станции конечных пользователей клиентского программного обеспечения («толстый» клиент) или браузеров, поддерживающих стандартные форматы данных и Java-аплеты, а также необходимые расширения plug-in («тонкий» клиент) для доступа пользователей к данным.

После завершения процесса создания хранилища данных может показаться, что все уже сделано. На самом деле формирование хранилища представляет собой процесс, включающий также необходимые фазы постоянного надзора и сопровождения хранилища данных. Корректный надзор подразумевает не только поддержание корректности данных, но и обеспечение их секретности, особенно если доступ к данным хранилища осуществляется через Web. «Так как хранилище данных содержит одну из самых больших ценностей предприятия,– говорит Р. Тенлер, председатель компании Information Advantage,– данные должны быть в безопасности. Но чтобы осознать потенциальную ценность хранилища данных, организации придется предложить ее потенциальным покупателям».

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

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