Технология хранилищ данных (стр. 6 из 11)

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

1.4.2 A Data Warehouse Plus.

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

Предлагаются три решения для хранилищ данных:

(1) Изолированная витрина данных. Предназначен для решения отдельных задач вне связи с общим хранилищем корпорации.

(2) Зависимая витрина данных. Аналогичен изолированной витрине данных, но источники данных находятся под централизованным контролем.

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

1.4.3 Warehouse Technology Initiative

Решение компании Oracle в области хранилищ данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Корпорация Oracle исходит из того, что Хранилище данных – это архитектура и технология, а не готовый продукт или семейство продуктов.

Общая архитектура решения представлена на рис.4

Рисунок.4. Архитектура СППР

Oracle Data Marts Builder -- специализированный инструментарий, предназначенный для автоматизации процессов выгрузки, транспортировки и преобразования данных(рис.5).

Рисунок 5. Структура метаданных Oracle Data Marts Builder

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

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

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

1. Определяются сетевые адреса серверов, из которых, будет выполняться выгрузка и транспортировка данных. В частом случае, это может быть тот же север на котором выполняется Oracle Data Marts Builder.

2. Для каждого источника данных автоматически формируется отдельный Базовый взгляд. Для этого Oracle Data Marts Builder связывается, через ODBC или напрямую, с БД источником и выгружает оттуда описания (структуру таблиц, типы полей и, если они определены, отношения типа - основной/внешний ключ) целевых структур данных. В дальнейшем, эти описания запоминаются и хранятся в соответствующих разделах базы метаданных Oracle Data Marts Builder.

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

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

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

4. Определяются процедуры (Планы) преобразования и согласования данных. Планы составляются на специальном высокоуровневом языке).

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

- выбрать данные из плоского файла с разделителями;

- выбрать данные из таблицы БД;

- удалить колонку из таблицы;

- найти и заменить один набор символов на другой;

- выполнить сортировку;

- заменить значение (текстовый дескриптор) его идентификатором (кодом),

- ранящимся во внешней таблице;

- выполнить сортировку;

- сформировать значение ключевого поля типа время;

- расщепить входной поток данных на два;

- объединить два потока данных в один;

- добавить данные в целевую таблицу;

- вызвать SQL Loader и передать данные на его вход;

- запомнить данные в виде плоского файла с разделителями;

- вывести данные на печать;

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

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

1.4.4 Warehouse WORKS.

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

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

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

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

Компонентная адаптивная архитектура Sybase (ImpactNOW) обеспечивает наиболее широкие возможности по повторному использованию стандартных компонент, причем всех основных форматов объектов -- ActiveX, JavaBeans, CORBA. Кроме того, она позволяет использовать их на любой уровне: клиента, сервера баз данных, промежуточного слоя. Это обеспечивает быструю разработку приложений, их высокую производительность, расширяемость и надежность.

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

2 глава Исследование методов организации структуры данных для аналитических систем.

2.1 СУБД для аналитических систем

2.1.1 РСУБД

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

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

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