Хранилище данных. Витрина данных.

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

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

Подходы и имеющиеся решения реализации Компания IBM A Data Warehouse Plus. Целью является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественна тесная интеграция программных продуктов. Предлагаются три решения для хранилищ данных: Изолированная витрина данных. Предназначена для решения отдельных задач вне связи с общим хранилищем корпорации. Зависимая витрина данных. Аналогична изолированной витрине данных, но источники данных находятся под централизованным контролем. Глобальное хранилище данных. Корпоративное хранилище данных, которое полностью централизовано контролируется и управляется. Глобальное хранилище данных может храниться централизовано или состоять из нескольких распределенных в сети рынков данных.

Подходы и имеющиеся решения реализации (продолжение) Oracle Решение компании Oracle основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих: наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей хранилищ данных; существование набора готовых приложений, обеспечивающих возможности разработки хранилища данных; высокий технологический потенциал компании в области анализа данных; доступность ряда продуктов, производимых другими компаниями.

Подходы и имеющиеся решения реализации (продолжение) Hewlett Packard OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонент. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, предназначенный для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д. NCR Решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования СУБД Teradata и связанных с ней методах параллельной обработки.

Подходы и имеющиеся решения реализации (продолжение) Informix Software Стратегия компании направлена на расширение рынка для продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура базируется на четырех технологиях: реляционные базы данных, программное обеспечение для управления хранилищем данных, средства доступа к данным и платформе открытых систем. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных. SAS Institute Компания считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем: обеспечение доступа к данным с возможностью их извлечения из самых разнообразных хранилищ данных (и реляционных, и не реляционных); преобразование данных и манипулирование ими с использованием 4GL; наличие сервера многомерных баз данных; большой набор методов и средств для аналитической обработки и статистического анализа.

Подходы и имеющиеся решения реализации (окончание) Sybase Стратегия компании основывается на разработанной ей архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация). Software AG Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления хранилищем данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в хранилище данных.

Правила для хранилищ данных (Уиллиам и Келли ) 1. Хранилища данных и операционная среда должны быть разделены. 2. Данные в хранилище должны интегрироваться. 3. В хранилище содержатся данные, накопленные за долгое время. 4. Данные в хранилище- это мгновенный снимок данных, полученный в данный момент времени. 5. Данные в хранилище предметно ориентированы. 6. Данные в хранилище предназначены для чтения с периодическим обновлением на основе операционных данных. Данные в хранилище обновлять оперативно нельзя.

Правила для хранилищ данных ( продолжение ) 7. Жизненный цикл в хранилище данных отличается от классической информационной системы. В хранилище данных во главе - данные, а в операционной базе данных - процесс. 8. В хранилище данных хранятся данные с несколькими уровнями детализации (текущие, старые, слабо обобщенные, данные высокой степени обобщения). 9. Среда хранилища данных характеризуется транзакциями, выполняющих чтение только большого числа данных. (Среда операционной базы данных – большое число транзакций обновлений). 10. Хранилище данных в составе имеет систему, которая отслеживает источники данных, преобразование и хранение.

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

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

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

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

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

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

Построение полноценного корпоративного хранилища данных обычно выполняется в трехуровневой архитектуре. Корпоративное хранилище данных

В 1994 году было предложено объединить концепции витрин данных и хранилища данных и использовать хранилища для витрин данных. Целью объединения было то, чтобы сами витрины данных основывались на данных, которые хранятся в хранилищах. Была предложена так называемая многоуровневая архитектура из трех уровней: 1-й уровень общекорпоративной базы данных на основе распределенной СУБД; 2-й уровень базы данных подразделений. Здесь хранятся агрегированные данные, то есть реляционные базы данных хранят операционные данные, а агрегированные данные отбрасываются на 2 уровень. 3-й уровень - это конкретные места пользователей-аналитиков. Те пользователи, которые на основе витрин данных делают какие-то выводы.

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

Проектирование витрин данных Пример схемы для витрины данных продаж

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

Пример таблицы фактов и измерений

Архитектура хранилища данных На сегодняшний день предложено множество архитектур, рассмотрим пять наиболее распространенных: 1. независимые витрины данных (independent data marts) 2. шина взаимосвязанных витрин данных(data-mart bus architecture with linked dimensional data marts) 3. архитектура «звезда» (hub-and-spoke) 4. централизованное хранилище данных (centralized data warehouse) 5. федеративная архитектура (federated architecture).

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

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

Архитектура «звезда» (Bill Inmon) Представляет собой централизованное хранилище данных с зависимыми витринами данных. Эта архитектура разрабатывается на основе корпоративного анализа требований к данным. Важно обратить внимание на создание масштабируемой и поддерживаемой инфраструктуры. На основе использования корпоративного представления данных выполняется итеративная разработка архитектуры, при этом вовлекается одна предметная область за другой. Детальные данные хранятся в нормализованной форме в хранилище данных. Зависимые витрины данных получают данные из хранилища данных. Зависимые витрины данных разрабатываются для подразделений или конкретных функциональных областей, целей и могут быть как нормализованными, так и денормализованными, либо в виде любой агрегированной структуры данных. Большинство пользователей выполняет запросы на зависимых витринах данных.

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

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