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

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

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

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

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

В состав хранилища данных, как правило, входит:

виртуальное хранилище данных;

витрины данных;

глобальное хранилище данных;

многоуровневая архитектура хранилища данных.

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

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

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

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

На втором уровне поддерживаются витрины данных на основе многомерной системы управления базами данных (примером такой системы является Oracle Express Server). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Необходимо заметить, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.

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

Хранилища данных обладают рядом свойств:

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

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

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

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

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

6. Минимизация избыточности информации. В ХД информация загружается из ОБД или OLTP-систем, при этом избыточность оказывается минимальной (около

Все данные в хранилище данных делятся на три основных категории:

метаданные;

детальные (текущие) данные;

агрегированные данные.

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

1. Модель снимков данных. Снимок данных - это представление данных в определенный момент времени. Данная модель характерна для оперативных систем (OLTP). Обновления данных носят деструктивный характер, т.е. предыдущие значения атрибутов замещаются новыми значениями. Модель имеет достаточно ограниченный круг применения в хранилищах данных, поскольку не обеспечивает хранения истории изменений.

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

3. Статусная модель используется для моделирования состояния объектов во времени. Она подходит для представления данных, имеющий нетранзакционный характер [5].

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

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

Очень часто информационно-аналитические системы, создаваемые в расчете на непосредственное использование лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические системы называются Информационными системами руководителя (ИСР), или Executive Information Systems (EIS). Они содержат в себе множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы которые могут возникнуть при принятии решений.

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