Администраторы БД - категория специалистов, основной задачей которых является поддержание СОД в актуальном рабочем состоянии. Их, как правило, интересует не семантика данных, а способы их физического представления и организации. Администратор обычно не работает с конкретными значениями данных, не занимается написанием новых и модернизацией уже существующих прикладных программ. И хотя потребность в наличии и доступности метаданных у этой категории специалистов высока, их обычно вполне устраивают ограниченные описания данных, содержащиеся в традиционных справочниках БД. И даже, несмотря на то что структура описаний в таких справочниках достаточно сложна для понимания, это также не вызывает особых нареканий. Число администраторов обычно невелико, и они, как правило, обладают достаточной квалификацией и опытом работы.
Разработчики - категория специалистов, ответственных за разработку и дальнейшее развитие СОД. Наличие метаданных (данных о данных) является необходимым условием успешной реализации любой СОД. И именно при разработке (модернизации) СОД эта информация формируется и активно используется. Однако формируется, не означает того, что формируется электронный образ общедоступной и общепонятной базы метаданных. Более того, даже если при разработке информационной системы используется CASE-инструментарий:
- результирующие описания, в первую очередь, ориентированы и будут полезны разработчикам, но никак не пользователям и в меньшей степени администраторам системы;
- в процессе эксплуатации СОД изменения в прикладные программы и даже в структуры данных, часто вносятся напрямую, а не через CASE-инструментарий.
Поэтому, через непродолжительный промежуток времени, описания данных, сформированные в процессе разработки, перестают соответствовать реальности.
Существенно иная ситуация в случае информационных систем, ориентированных на аналитическую работу с данными (таблица 4). Здесь наличие метаданных и средств их представления конечным пользователям является одним из основополагающих факторов успешной реализации системы. Для конечного пользователя база метаданных является тем же самым, что и путеводитель для туриста, попавшего в незнакомый город. Прежде чем сформулировать свой вопрос к системе, менеджер должен понять, какая информация в ней есть, ее актуальность, насколько ей можно доверять и даже сколько времени может занять формирование ответа. Поэтому для конечного пользователя крайне важно и желательно, чтобы в системе содержались не только описания собственно структур данных, их взаимосвязей, предвычисленных уровней агрегации, но источников получения данных. Аналитику желательно не просто знать о том, какие данные есть в системе, но и источники их получения и степень их достоверности. Например, одна и та же информация может попасть в Хранилище Данных из различных источников. В этом случае пользователь должен иметь возможность узнать, какой источник выбран в качестве основного и каким образом выполнялись согласование и очистка исходных данных; периодичности обновления. Пользователю желательно не просто знать, какому моменту времени соответствуют те или иные данные, но и когда они будут обновлены; собственников данных. В отличие от традиционных СОД, где пользователь видит только то, что ему разрешено, здесь пользователю будет полезно знать:
- какие еще данные есть в системе;
- кто является их собственником;
- какие шаги он должен предпринять, чтобы получить к ним доступ;
- статистические оценки запросов.
Еще до выполнения запроса пользователю желательно иметь хотя бы приблизительную оценку времени, которое потребуется для получения ответа, и представлять, каков будет объем этого ответа.
Уровень приложения (внешних источников данных) | Описывает структуру данных в операционных БД и других источниках данных. Обычно, этот уровень достаточно сложен для понимания неподготовленного пользователя и является приложение ориентированным |
Уровень ядра Хранилища Данных | Описывает логическую и физическую структуру и взаимосвязи данных в Хранилище Данных. |
Уровень конечного пользователя | Описывает структуры данных в Хранилище Данных в терминах предметной области конечного пользователя. |
Таблица 4. Уровни метаданных в Хранилище Данных.
5 Хранение и обработка очень больших объемов данных.
Когда мы говорим о целевой БД Хранилища Данных, то подразумеваем, что это нечто очень большое (таблица 5). Но насколько большое? Согласно данным Meta Group, уже сегодня около половины организаций планируют Хранилища в 100 гигабайт и более. И уже известны реализации систем с терабайтами данных.
Маленькое Хранилище Данных | До 3 Гбайт | До нескольких миллионов строк в одной таблице |
Среднее Хранилище Данных | До 25 Гбайт | До ста миллионов строк в одной таблице |
Большое Хранилище Данных | До 200 Гбайт | До нескольких сотен миллионов строк в одной таблице |
Очень Большое Хранилище Данных | Свыше 200 Гбайт | Сотни миллионов или миллиарды строк в одной таблице |
Таблица5. Классификация ХД в соответствии с объемом целевой БД.
Причем, когда говорится о 100 гигабайтах исходных данных, следует понимать, что реальное дисковое пространство, требуемое для реализации целевой БД, будет несколько больше. Коэффициенты увеличения данных при помещении в ХД составляют от нескольких единиц до нескольких десятков.
1.3.2 Основные компоненты Хранилищ Данных.
Основными компонентами Хранилищ Данных являются:
1) ПО промежуточного слоя.
Обеспечивает сетевой доступ и доступ к базам данных. Сюда относятся сетевые и коммуникационные протоколы, драйверы, системы обмена сообщениями и пр.
2) Транзакционные БД и внешние источники информации.
Базы данных OLTP-систем исторически предназначались для эффективной обработки структур данных в относительно небольшом числе четко определенных транзакций. Из-за ограниченной целевой направленности "учетных" систем применяемые в них структуры данных плохо подходят для систем поддержки принятия решений. Кроме того, возраст многих установленных OLTP-систем достигает 10 - 15 лет.
3) Уровень доступа к данным.
Относящееся сюда ПО обеспечивает общение конечных пользователей с информационным хранилищем и загрузку требуемых данных из транзакционных систем. В настоящее время универсальным языком общения служит язык структурированных запросов (SQL).
4) Загрузка и предварительная обработка.
Этот уровень включает в себя набор средств для загрузки данных из OLTP-систем и внешних источников. Выполняется, как правило, в сочетании с дополнительной обработкой: проверкой данных на чистоту, консолидацией, форматированием, фильтрацией и пр.
5) Информационное хранилище.
Представляет собой ядро всей системы - один или несколько серверов БД.
6) Метаданные.
Метаданные (репозиторий, "данные о данных"). Играют роль справочника, содержащего сведения об источниках первичных данных, алгоритмах обработки, которым исходные данные были подвергнуты, и т. д.
7) Уровень информационного доступа
Обеспечивает непосредственное общение пользователя с данным DW посредством стандартных систем манипулирования, анализа и предоставления данных типа MS Excel, MS Access, Lotus 1-2-3 и др.
8) Уровень управления (администрирования)
Отслеживает выполнение процедур, необходимых для обновления информационного хранилища или поддержания его состояния. Здесь программируются процедуры подкачки данных, перестройки индексов, выполнения итоговых (суммирующих) расчетов, репликации данных, построения отчетов, формирования сообщений пользователям, контроля целостности и др.
1.4 Подходы и имеющиеся решения
1.4.1 Data Warehouse Framework
Архитектура Microsoft Data Warehousing Framework представляет собой план разработки и интеграции продуктов, базирующихся на платформе Microsoft. В рамках этой инфраструктуры предоставляется объектно-ориентированный комплект компонентов, обеспечивающих Рисунок 3. Data Warehousing Frameworkуправление информацией в распределенной среде
Data Warehousing Framework описывает связи между различными компонентами, используемыми в процессе создания, использования и администрирования хранилища данных. Ядром Data Warehousing Framework является набор продуктивных технологий, включающий в себя уровень транспортировки данных (OLE DB) и интегрированный репозитарий метаданных. Эти две технологии обеспечивают интегрируемость множества продуктов и инструментальных средств, используемых в процессе построения хранилища данных.
Создание хранилища данных требует применения набора инструментальных средств для описания логической и физической структуры источников данных и мест их назначения в хранилищах или киосках данных. Оперативные данные должны пройти этап очистки и преобразования перед помещением в хранилище или киоск данных, чтобы соответствовать сформированным на этапе проектирования спецификациям. Такой процесс поэтапной обработки данных на практике часто бывает многоуровневым, особенно в архитектурах, использующих общекорпоративные хранилища, но на приведенной выше схеме он изображен для экономии места в упрощенном виде.
Для обеспечения доступа к информации хранилища данных применяются инструменты конечных пользователей. В идеальном случае, пользовательский доступ осуществляется через некоторое средство работы с каталогами, предоставляющее возможность поиска именно тех данных, которые нужны пользователю для решения вопросов бизнеса, а также обеспечивающее необходимый уровень защиты, лежащий между пользователями и серверными системами.