---

Назад

Содержание

Далее

---

Переменные

Начиная с DTS в SQL Server 7.0 глобальные переменные (которые теперь называются просто переменными) всегда были важным элементом для динамического конфигурирования пакета без необходимости жёсткого программирования. В SSIS их функциональность была сильно расширена за счет улучшения процесса обработки переменных и введения области видимости.

В SQL Server 2000 был только один тип переменных - глобальные переменные. Областью видимости этих переменных был весь пакет. В SSIS же область видимости переменных может быть ограничена пакетом, контейнером или системой. Это помогает лучшему обмену переменными между пакетами. А также помогает удерживать переменную только в рамках ее части работы. При такой изначальной гибкости можно упростить создание одиночного ETL процесса и уменьшить затраты на кодирование в задаче Script.

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

Динамическое изменение свойств

Наверное, Вы уже заметили отсутствие задачи Dynamic Properties из SQL Server 2000. Этой задачи больше не существует, потому что свойства всех задач или контейнеров можно динамически изменить через переменные. Это очень полезно, если нужно запускать задачу, которая соединяется с источником данных, имя которого неизвестно до момента выполнения. На Рисунке 49 показан пример такого типа функции, в которой соединение для задачи XML задается через переменную XPathResult.

Рисунок 49

Можно использовать переменные в ограничениях приоритета для управления ходом выполнения пакета на основе проверки выполнения определенных условий. Для этого нужно дважды нажать кнопку мыши на ограничении приоритета и изменить свойство это ограничения так, как показано на Рисунке 50. Сначала нужно выбрать Evaluation Operation (свойство EvalOp) для того, чтобы происходило вычисление выражения. Можно выбрать между только вычислением выражения и одновременными успешным завершением предыдущей задачи и вычислением выражения в качестве условий продолжения выполнения. И в заключении задайте собственно выражение, которое нужно вычислять. Для указания переменной используйте символ @.

В приведенном примере проверяется, что значение переменной @NumberWidgets меньше числа 10. Если это условие выполняется, то значит полученный от поставщика XML содержит ошибки и его необходимо об этом уведомить. Если же имеется более 10 продуктов, то данные считаются правильными и их можно преобразовать в другой файл с помощью XSLT. Т.е. при выполнении пакета можно увидеть, что при правильном XML файле будет выполнена только задача XSLT to Text File. Задача же Send Mail будет проигнорирована при данном выполнении пакета.

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

Выражения свойств

Выражения свойств позволяют динамически изменять переменные в ходе выполнения. Эти встроенные в язык выражения позволяют легко изменить свойства задач, соединений, лог провайдеров и нумераторов ForEach. Ранее для подобных целей нужно было использовать задачу Dynamic Properties, но выражения свойств гораздо лучше справляются с этим. Их можно использовать для изменения свойств таких событий как:

• Задачи
  • Before Saving
  • After Loading
  • Before initialization
  • Before Validation
  • Before Execution
• Менеджеры соединений
  • Before Saving
  • After Loading
  • Before initialization
  • Before returning from AcquireConnection calls
• Лог провайдеры
  • Before Saving
  • After Loading
  • Before Initialization
• Нумератооы ForEach
  • Before Saving
  • After Loading
  • Before Initialization
  • Before returning from GetEnumerator calls

Например, если ежедневно от мэйнфрэйма приходит файл и необходимо перемещать его в директорию Processed, снабдив при этом временной меткой, то можно использовать выражения свойств совместно с задачей File System для динамического задания имени конечного файла.

Элементы потока данных

Также как поток управления контролирует ход выполнения пакета, так и поток данных контролирует преобразования данных. Почти все, что хоть как-то работает с данными, попадает в категорию потока данных. Для создания потока данных нужно в своем потоке управления добавить задачу Data Flow.

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

Источники

Источник задает расположение ваших исходных данных в процессе обработки. Источники обычно создаются в Connection Manager. Применяя для создания источника Connection Manager, можно повторно использовать их во всем пакете и случае необходимости поменять их параметры только в одном месте. В SQL Server 2000 источник и приемник данных были в действительности именно соединениями.

Источник OLE DB

Источник OLE DB, скорее всего, будет самым часто используемым элементом из Панели Инструментов. Как и в SQL Server 2000 DTS соединение OLE DB подходит для любого реляционного источника данных, как SQL Server, Access, Oracle, или DB2 и др. В SQL Server 2005 при создании источника OLE DB нужно будет указать, какое соединение следует использовать. При этом можно указать на представление источников данных (DSV) так, как если бы он был в обычной базе данных. На Рисунке 52 можно видеть, что курсор мыши указывает на Transactions DSV вместо главного соединения Adventure Works, которое содержит все неизмененные объекты.

Рисунок 52

После выбора источника данных (см. Рисунок 53) можно перейти к закладке Columns и выбрать то подмножество столбцов, которое необходимо будет передать следующему элементу данных. Делается это путем отметки тех столбцов, что нужно сделать доступными в потоке данных. При желании также можете переименовать столбцы, которые будут представлены в потоке данных, через изменение свойства Output Column.

Рисунок 53

Источник Flat File

Источник Flat File представляет соединение с нереляционным источником данных. Источником Flat File обычно являются файлы с разделителем (запятой или табуляцией), но это могут быть и файлы со столбцами фиксированного размера. Конфигурируется источник Flat File точно так же, как и источник OLE DB. После добавления источника на панель потока данных, он указывается Connection Manager-у в качестве соединения к плоскому файлу. После этого можно перейти к закладке Columns для определения списка тех столбцов, которые нужно представить в потоке данных. Все установки плоского файла такие, как тип разделителя, устанавливаются в Flat File Connection Manager.

Источник Raw File

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

Источник XML

Источник XML позволяет Вам сделать XML файл или элемент данных источником внутри процесса обработки данных. После добавления этого элемента данных можно или жестко задать XML файл через свойство XML location (см. Рисунок 54), или указать, что положение файла будет браться из переменной. Также можно указать, что XML данные могут и сами находиться в переменной. Данный источник полезен в связке с задачей Web Service или с задачей XML. После задания элемента данных для файла XML нужно создать XML Schema (XSD) файла либо выбирая кнопку Generate XSD, либо указывая на существующий XSD файл. В остальном данный источник похож на другие источники, где можно отфильтровать те столбцы, которые не хочется видеть в дальнейшей обработке.

Рисунок 54

Источник DataReader

Источник DataReader является соединением ADO.NET в том виде, как его можно видеть в .NET Framework при использовании интерфейса DataReader в приложении для соединения с базой данных. Источник DataReader позволяет создать соединение с управляемым источником данных и передавать в него SQL запросы. Результаты этого запроса могут быть использованы позже в потоке данных. Только всегда помните, что при работе с этим источником, нужно будет вводить текст SQL запроса вручную и не будет инструментов для построения запросов как в других источниках.

Приемники

Внутри потока данных приемники предназначены для приема данных от источников. За счет гибкой архитектуры, возможно, передавать данные практически в любой OLE DB-совместимый источник данных или в плоский файл. Есть также несколько второстепенных приемников, которые не будут рассмотрены в данной статье. Почти каждый приемник обладает похожими свойствами, которые отображаются в двух основных диалогах. Обычно, в закладке Connection Manager приемника можно задать использование соединения, которое было предварительно создано в Connection Manager. А в закладке Mappings определяются те данные, которые будут при обработке в потоке данных переданы приемнику, как это показано на Рисунке 55.

Рисунок 55

Приемник SQL Server

Приемник SQL Server является типом приемника оптимизированным для SQL Server. Свои скоростные качества он получает за счет использования встроенных в SQL Server команд массовой загрузки. На закладке Advanced приемника можно указать те же установки, что доступны и при использовании команды массовой загрузки, например, срабатывание триггеров или блокирование таблицы. На Рисунке 56 можно увидеть установки заданные по-умолчанию. Очень важно отметить, что данные вид приемника можно использовать, только если выполнение пакета происходит на той же самой машине, на которой установлен SQL Server. Это ограничение происходит из-за использования интерфейсов, которые хранят все данные в памяти.

Рисунок 56

Приемник Raw File

Приемник Raw File (который также называют приемником Append) записывает неформатированные данные в файл. Из-за того, что используется начальный формат данных, такой вид экспорта данных является самым быстрым. Данный приемник можно использовать для записи данных в промежуточный файл, который позже можно загрузить и преобразовать в источнике Raw File другого пакета.

Приемник OLE DB

Приемник OLE DB является настоящим "пожирателем" данных. Этот приемник можно использовать для отсылки данных большинству видов реляционных источников данных. В большинстве своих настроек данный вид приемника похож на другие приемники. Но имеет хорошее дополнение в виде возможности при ошибках либо перенаправить сохранение записей, которые не удается добавить, в другую таблицу, либо прервать выполнение вообще, как это показано на Рисунке 57. Для перенаправления ошибочных записей выбирается другой приемник, который соединен с данным приемником, и поэтому может получать эти проблемные записи.

Рисунок 57

Приемник Recordset

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

Приемник DataReader

Приемник DataReader (не имеет отношение к источнику DataReader) является мощными видом приемника, который дает возможность получать обработанные выходные данные ADO.NET приложениям, таким, как Reporting Services или пользовательским приложениям, которые можно разработать с использованием интерфейса DataReader. Чтобы помочь самому себе правильно использовать приемник, нужно убедиться, что наименование приемника в дальнейшем позволит однозначно узнать его в программе. На Рисунке 58 можно увидеть приемник по имени OutputAfterAggregation.

Рисунок 58

Если планируется использовать эти данные в Reporting Services, то нужно удостовериться, что в пакете имеется соединение соответствующего типа. А в Reporting Services необходимо проверить наличие расширения SSIS в разделе <DATA> файла RSReportDesigner.config. При инсталляции версии SQL Server 2005 Beta 3 это будет сделано автоматически. В Report Designer можно будет увидеть новый тип соединения по имени SSIS. При выборе этого источника данных просто введите полное имя пакета, например:

-f C:\SamplePackages\RSSFeedFromPartner.dtsx

В диалоге Query соединения укажите тот приемник DataReader, из которого нужно извлекать данные. Каждый раз, когда отчет будет запрашивать данные, будет выполняться DTS пакет, и можно будет увидеть приемник DataReader в процессе передачи им данных в конвейер. Для этого пакет должен содержать задачу Data Flow.

Такой подход особенно полезен для отображения данных не SQL Server после преобразования в Reporting Services или в другом приложении. Например, можно отображать выборку RSS преобразованную к табличному виду в Reporting Services. Пользователи могут подписываться на RSS выборку в Reporting Services и через эту подписку получать свои данные.

Преобразование данных

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

Расширение или изменение данных

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

Преобразование Aggregate

Преобразование Aggregate производит над полученным набором данных операции суммирования, вычисления среднего значения, подсчет общего количества, подсчет уникальных значений, вычисление максимальных или минимальных значений. Данное преобразование может производить группировку по одному или нескольким столбцам. Преобразование можно использовать для получения итоговых сумм для большого набора данных без необходимости либо сначала помещать его в реляционную базу, либо возлагать эти дополнительные действия на принимающую данные систему. На Рисунке 59 показаны несколько агрегатных функций (Sum, Average, Max, Min) для таблицы Employee Dimension из базы AdventureWorks Data Warehouse с группировкой по столбцу Department:

Рисунок 59

На следующем рисунке показан результат преобразования Aggregate, который будет передан в приемник:

Преобразование Audit

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

• ExecutionInstanceGUID
• PackageID
• PackageName
• VersionID
• ExecutionStartTime
• MachineName
• UserName
• TaskName
• TaskID

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

Преобразование Character Map

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

• Lowercase - преобразует символы к нижнему регистру.
• Uppercase - преобразует символы к верхнему регистру.
• Byte reversal - меняет порядок байтов на обратный.
• Hiragana - преобразует Katakana символы в Hiragana.
• Katakana - преобразует Hiragana символы в Katakana.
• Half width - преобразует двухбайтовые символы к однобайтовым.
• Full width -преобразует однобайтовые символы к двухбайтовым.
• Linguistic casing - для преобразования регистра применяются лингвистические методы а не системные.
• Simplified Chinese - преобразует символы в Simplified Chinese.
• Traditional Chinese - преобразует символы в Traditional Chinese.

Преобразование Copy Map

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

Преобразование Data Conversion

В преобразовании Data Conversion данные одного типа в столбце источника можно конвертировать в данные другого типа в приемнике.

Преобразование Derived Column

Преобразование Derived Column позволяет поточные преобразования с использованием SSIS выражений. Например, можно применить к числовому столбцу функцию CEILING и передать результат в новый столбец. Также можно создать условные переходы внутри выражения.

Преобразование Fuzzy Grouping

Преобразование Fuzzy Grouping позволяет произвести очистку данных путем нахождения совпадений между данными в разных записях. Результатом преобразования являются три дополнительных столбца - один для уникальной идентификации записи, второй для идентификации группы и третий для указания степени совпадения с образцом (значение от 0 до 1). На основе заданных в задаче порогов вероятности, можно достичь высокого уровня соответствия данных образцам. Например, при установленном пороге вероятности в 80% все, что выше этого порога считается совпадающими данными, а все что ниже возможно требует ручного подтверждения соответствия образцу. Типичным случаем использования данного типа преобразования может служить группировка по названию компании производимая по источнику на основе свободно форматированного текста (в котором, например Microsoft = Micro soft = MicroSoft).

Заметим, что данное преобразование требует наличия соединения с базой SQL Server 2005 для создания временной таблицы с промежуточными результатами, которые используются алгоритмы группировки.

Преобразование Fuzzy Lookup

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

Обычно данный тип преобразования может следовать за стандартным Lookup преобразованием для тех записей, которым не были найдены совпадения. Это преобразование отличается от преобразования Lookup только тем, что в отличии от него использует нечеткое сравнение вместо сравнения на основе эквивалентности.

Преобразование Lookup

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

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

Преобразование Pivot

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

Преобразование Sort

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

Преобразование Unpivot

Преобразование Unpivot производит действия противоположные преобразованию Pivot.

Распределение, объединение или извлечение пробных данных

Все следующие преобразования распределяют, объединяют или извлекают данные.

Преобразование Conditional Split

Преобразование Conditional Split может перенаправить данные в различные приемники в зависимости от выполнения запрограммированных условий. Если ни одно из условий не выполнено, то данные автоматически направляются в приемник, который был задан как приемник по-умолчанию. BI Development Studio будет помечать каждый из вариантов вывода, включая вариант по-умолчанию, своим порядковым номером. Каждому условию должен быть определен уникальный приемник.

Преобразование Multicast

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

Преобразование Merge

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

Преобразование Merge Join

Преобразование Merge Join очень похоже на преобразование Merge, но позволяет создавать результат, который получается при FULL, LEFT или INNER соединении двух упорядоченных наборов данных. Требования, которые предъявляет преобразования Merge Join, совпадают с требованиями для преобразования Merge, т.е. оба преобразования требуют упорядоченных данных и совпадения метаданных.

Преобразование Union All

Преобразование Union All объединяет множество входных данных в один выходной набор. В отличии от преобразований Merge и Merge Join данное преобразование не требует того, чтобы входные данные были упорядочены. Первый из входных наборов становится эталонным, а все другие входные наборы должны совпадать с ним по следующим условиям:

• Тип данных
• Кодовая страница
• Точность
• Масштаб
• Размер
• Установки сравнения

Столбцы вторичных входных наборов, которые невозможно сопоставить со столбцами ссылочного набора в выходном наборе, будут установлены в NULL.

Бизнес-аналитические преобразования

Преобразование Data Mining Query

Преобразование Data Mining Query выполняет прогнозирующий запрос для заданной модели анализа данных. Данное преобразование содержит построитель запросов для создания Data Mining Extensions (DMX) запросов на основе модели, преобразователь входных данных, функции прогнозирования и пользовательские выражения.

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

Преобразование Data Mining Query требует наличия соединения с базой данных Analysis Services, которая содержит структуры и модели.

Преобразование Slowly Changing Dimension

Преобразование Slowly Changing Dimension (или коротко SCD) является наиболее замысловатым из всех преобразований SSIS. Оно автоматизирует и стандартизирует обычную, но сложную задачу как отследить измененные значения в измерениях хранилища данных. К счастью данное преобразование снабжено мастером, который поможет разработчику на каждом шаге конфигурирования этого преобразования.

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

Рисунок 61

Следующей шаг приводит к скучной задаче по выбору того, какие столбцы измерения являются Fixed, Type I, или Type II. В этом разделе мастера выбирается то, как система ETL будет себя вести при обнаружении расхождений между источником и приемником. Например, если имеется измерение Работники, состоящее из трех столбцов Birth Date, Home Phone Number и Department, то в конкретной сфере деятельности можно по разному отслеживать изменения в каждой из этих столбцов:

• Можно не ждать изменений в Birth Date (и при их появлении генерировать ошибку).
• Можно ожидать изменений в Home Phone Number, но не заботится о хранении истории этих изменений.
• Можно ожидать изменений в the Department и нуждаться в сохранении истории этих изменений.

Преобразование SCD поддерживает и такой сценарий, и другие, позволяя проектировщику выбрать подходящие бизнес правила для каждого атрибута, как это показано на Рисунке 62.

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

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

На последнем шаге мастера можно увидеть выходные устройства (возможно не более 6), которые будут созданы. Мастер SCD создаст для каждого выходного устройства новый OLE DB источник, а также несколько других преобразований для поддержки SCD. Результат выглядит приблизительно так, как показано на Рисунке 64. Каждый из выходных устройств будет автоматически снабжено комментарием.

Рисунок 64

Заметим, что при перезапуске мастера SCD, любые изменения на экране перепишут расположение задач в рабочей поверхности.

Прочие преобразования

Преобразование File Extractor

Преобразование File Extractor может взять данные типа TEXT, NTEXT, или IMAGE непосредственно из потока и записать их в файл. Каждая запись исходных данных может быть помещена в отдельный файл. Файлы приемники могут быть созданы на лету или можно добавить или заместить данные в уже существующих файлах.

Преобразование File Inserter

Преобразование File Inserter похоже на преобразование File Extractor за исключением того, что File Inserter может для каждой записи набора данных открыть файл и прочитать оттуда данные. Тип данных приемника информации из файла должен быть TEXT, NTEXT, или IMAGE.

Преобразование OLE DB Command

Преобразование OLE DB Command может для каждой записи набора данных выполнить SQL команды. Эти SQL команды может содержать параметры. Обычно данное преобразование используется для получения функциональности курсоров Transact-SQL для выполнения единообразной Transact-SQL операции для всего набора данных.

Преобразование Row Count

Преобразование Row Count подсчитывает число переданных через нее строк и сохраняет результат в переменную, которую можно использовать для проверки данных и процесса. Эту переменную также можно использовать для программного изменения в преобразованиях Conditional Split или Loop контейнерах.

Компонент Script

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

Преобразование Term Extraction

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

Преобразование Term Lookup

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

Компоненты управления событиями

Внутри SSIS архитектуры существует расширенная концепция событий и обработчиков событий. В предыдущих версиях доступ к событиям уровня пакета достигался с помощью программного запуска пакета из среды Visual Basic или Microsoft Visual C++®. В SSIS же события пакета доступны в пользовательском интерфейсе и для каждого из них можно спроектировать его собственный обработчик с целью создания сложных потоков обработки. Фактически для каждой выполняемой контейнерной задачи в среде работы пакета существуют ее события. Ниже приведен список обработчиков событий, которые существует при выполнении пакета:

Событие	Описание
OnError	Событие возникает при появлении ошибки.
OnExecStatusChanged	Это событие возникает, когда статус выполнения объекта меняет свое значение с True на False или наоборот.
OnInformation	Это событие возникает, когда объект готов рапортовать о чем-либо.
OnPostExecute	Это событие возникает сразу после того, как объект завершает выполнение.
OnPostValidate	Это событие возникает сразу после того, как объект был протестирован в режиме редактирования.
OnPreExecute	Это событие возникает непосредственно перед запуском объекта.
OnPreValidate	Это событие возникает, когда начинается процесс проверки объекта.
OnProgress	Это событие возникает, когда изменяется измеряемое состояние хода выполнения.
OnQueryCancel	Это событие возникает непосредственно перед тем, как процесс готов к завершению.
OnTaskFailed	Это событие возникает в том случае, если выполнение задачи завершилось неудачей.
OnVariableValueChanged	Это событие возникает в том случае, когда меняется значение переменной, для которой задано свойство RaiseChangeEvent.
OnWarning	Это событие возникает в том случае, когда генерируется предупреждение.

При таком обилии обработчиков событий архитектура событий предлагает простые и стандартизированные решения задачи управления. Например, общую систему обработки ошибок и отчётности на уровне пакета или контейнера. ( Обработчики событий детально писаны в Server 2005 Books Online). В дополнение широта модели событий в общей архитектуре такова, что позволяет и более продвинутые решения с обработкой событий на самых низких уровнях. Такие низкоуровневые решения можно встраивать в задачи и потока управления и потока данных для поддержки самых малых частей систем ETL.

Компоненты управления ошибками

Управление ошибками в SSIS значительно более мощное, чем в DTS 2000. Пакет может управлять ошибками многими различными способами, используя несколько новых методов. Можно легко отреагировать на ошибку или проигнорировать ее, проверяя тип ошибки, или время и место возникновения ошибки. SSIS позволяет разработчику качественно обрабатывать как процедурные ошибки, так и ошибки данных.

Процедурные ошибки

В SSIS, как и в DTS 2000, существует ограничение приоритета OnFailure, которое позволяет при ошибке выполнения задачи графически направить поток выполнения к задаче, предназначенной для обработки ошибки. Также можно проигнорировать ошибку, если изменить проверку результата ограничения на OnCompletion. В DTS 2000 это означало, что пакет все равно сообщит о своем неудачном завершении в вызвавшее его приложение (например, SQL Agent), не смотря на то, что возникшая ошибка могла быть второстепенной и восстановимой.

SSIS же предлагает разработчику более гибкий подход в лице нового свойства по имени ForceExecutionResult. Для этого свойства можно задать значение None, Success, Failure, или Completion. При выборе значения Success или Completion пакет будет всегда рапортовать об успешном завершении задачи, невзирая на то, что случилось на самом деле.

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

Ошибки данных

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

Например, если добавляется запись, которая нарушает ограничение первичного или ссылочного ключа, то эта запись может быть помещена в таблицу ошибок для более поздней обработки. Как это показано на Рисунке 65.

Для задач преобразования данных обработка ошибок может заключаться в создании дополнительного приемника данных (типа OLE DB, Flat File, или Raw File), в который будут передаваться ошибочные записи. При нажатии кнопки мыши на приемнике трансформации появится красная стрелка, которая соответствует ограничению приоритете OnFailure. При перетаскивании этой стрелки к новому приемнику появится диалоговое окно Error Dispositions, как показано на Рисунке 66.

Рисунок 66

В этом диалоге можно задать автоматическую обработку ошибок данных двух разных типов - критические ошибки (например, нарушение Первичного Ключа) и ошибки усечения. Эти ошибки можно пропустить, отказать или перенаправить в альтернативный приемник. В данном выше примере любые критические ошибки, возникшие в столбцах Col1, Col2, или Col3, будут переданы в источник данных по имени Error, но разрешена передача далее усеченных данных. В приведенной ниже таблицы описаны возможные действия.

Опция	Описание
Fail Component	Вся задача потока данных завершается при возникновении любой серьезной ошибки.
Ignore Failure	Задача потока данных завершается успешно, невзирая на то имели ли место ошибки или нет.
Redirect Row	Вызвавшая ошибку запись перенаправляется в соответствующий приемник данных.

Если нужно избавиться от ошибок путем перемещения их в новый приемник (т.е. нужно просто не игнорировать ошибки и не прерывать пакет), то нужно определить отображения ошибки. Дважды нажмите кнопку мыши на соединении приемника данных по имени Error, после чего выберите таблицу, в которую будут копироваться ошибочные данные, а затем выберите закладку Mapping (см. Рисунок 67). Можно заметить там появление двух дополнительных столбцов в списке столбцов источника - ErrorCode и ErrorColumn. Они будут содержать информацию об ошибке каждой ошибочной записи преобразования и их также можно поместить в таблицу ошибок.

Рисунок 67

И напоследок нужно запретить свойство Fast Load для преобразования приемника данных. Если это свойство разрешено, то SSIS будет применять пакетное добавление записей, при котором ошибки уровня записи будут недоступны. Такое решение приведет к некоторой потере производительности, но это необходимая "цена" за возможность перенаправить все ошибки.

Компоненты ведения протокола и аудита

Ведение протокола в SSIS было значительно изменено для большей поддержки более низких уровней доступных для протоколирования. К существовавшим ранее возможностям ведения протоколирования на уровне пакета и задачи добавилась возможность задать различные параметры ведения протокола для отдельных задач и пакета. Новая система ведения протоколов также позволяет создание элементов протоколирования для каждого события задачи или пакета.

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

Можно разрешить ведение протокола для пакета при нажатии правой кнопки мыши в редакторе потока данных и выборе Logging или выбрав пункт Logging в меню DTS. По-умолчанию, ведение протокола не включено, поэтому для его конфигурации нужно добавить хотя бы одного провайдера на уровне пакета. На Рисунке 68 можно увидеть три доступных пакету провайдера:

Рисунок 68

После того, как ведение протокола включено, можно указать вести протокол для любой задачи и определить параметры протоколирования. Обратите внимание на кнопку Advanced в закладке Details. При нажатии на неё можно увидеть полный список всех событий и атрибутов, которым можно задать ведение протокола (см. Рисунок 69).

Рисунок 69

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

• OnPipelinePostEndOfRowset
• OnPipelinePostPrimeOutput
• OnPipelinePreEndOfRowset
• OnPipelinePrePrimeOutput
• OnPipelineRowsSent
• Diagnostic

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

Для каждого из этих событий DTS поддерживает пять методов ведения протоколов, или другими словами провайдеров: Text File, SQL Profiler, SQL Server, Windows Event Log, и XML File.

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

• Computer
• Operator
• SourceName
• SourceID
• ExecutionID
• MessageText
• DataBytes

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

И напоследок отметим, что SSIS поддерживает создание пользовательских провайдеров ведения протокола, в которых можно реализовать тот функционал, который лучше всего подходит под Ваши потребности. За более подробной информацией обратитесь к SQL Server Books Online.