Основной и наиболее сложной задачей, для решения которой применяются DTS, является создание хранилищ или витрин данных. Данные, которые наполняют хранилище, могут исходно быть представлены самыми различными форматами и системами хранения, как мы видели во Введении. Пусть, например, учетом торговых операций занимается приложение на Oracle, а отдел маркетинга отслеживает свои мероприятия с помощью Access. Мы хотим построить куб в MS OLAP Services, чтобы проанализировать как те или иные маркетинговые мероприятия сказываются на объемах наших продаж. Мораль - мы должны уметь осуществлять доступ к источникам данных различной природы. Перед тем, как положить данные в хранилище, данные должны быть очищены, проверены на непротиворечивость и приведены к единому виду. Например, одно приложение хранит месяц апрель как "Апрель", другое - как "апр", третье - как "April", четвертое - как "IV", пятое - как "04" и т.д. Даже если мы с помощью OLE DB, ODBC или как-то иначе доступились до всех наших разнородных источников данных, даже если (представим себе неправдоподобно хорошую ситуацию) это все хранится в одних форматах одной СУБД, мы получим несколько разных членов одного временнОго измерения, которым на самом деле соответствует всего лишь один член уровня "месяц". А ведь месяц может вообще храниться не отдельно, а в составе даты, например, 01/04/99, и тогда его нужно выцепить оттуда при наполнении хранилища. Еще одно требование - возможность частичной предагрегации. Представим себе, что продуктовое приложение хранит данные о продажах за каждый день. Но в процессе анализа будущего куба мы не собираемся погружаться до дней, нас вполне устроит месячный дискрет. Следовательно, нечего тащить все детали в куб и раздувать объем хранилища, стоит агрегировать месячные продажи еще на стадии наполнения хранилища. Итак, доступ к разнородным данным, их очистка, проверка на непротиворечивость, унификация и предагрегация - все эти задачи решают службы преобразования данных.
В простейшем случае DTS могут рассматриваться просто как средство импорта/экспорта данных в/из SQL Server. По большому счету этот инструмент можно применять безотносительно к SQL Server для переноса данных из одного источника в другой, например, из Oracle в Access, из dbf-формата в текстовый файл и т.д. Возникает законный вопрос - как обстоит дело с переносом метаданных и объектов БД, таких, как хранимые процедуры, триггера, индексы, правила ссылочной целостности и прочие ограничения? В случае, когда и источник, и назначение оба представляют собой один или разные SQL Server 7.0, перенос объектов не составляет труда и выполняется задачей типа Transfer SQL Server Objects. В остальных случаях автоматически решается только перенос схемы данных, например, структуры таблицы (и, само собой, данных в ней, как уже было сказано). Дело в том, что функциональность источника/назначения, не являющегося SQL Server, априори неизвестна DTS. Ну, например, что такое индекс, если речь идет об ODBC-драйвере для ASCII-файла? Поэтому если источник, скажем, тот же Oracle, поддерживает данный тип объекта, его перенос возможен, но потребует небольшой ручной работы, например, ввести в состав пакета задачу типа Execute SQL и написать в ней соответствующий SQL-скрипт. При переносе схемы данных отображение типов полей источника на типы полей назначения выполняется автоматически путем приведения и тех и других к стандартным типам OLE DB, за что отвечают OLE DB-провайдеры источника и назначения.
Базовой административной единицей DTS является пакет (package). Основными компонентами пакета служат соединение (connection), задача (task) и шаг (step). Пакет содержит самодостаточное описание всех входящих в него соединений, задач, шагов и других компонентов.
Назад | Содержание | Вперед