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

Экстракцию данных можно выполнять на двух уровнях: на уровне приложения и на уровне базы данных или файла ("техническом уровне"). На уровне приложения экстракция данных выполняется в виде бизнес-объектов.

Так как он быстрее и проще, то этот метод наиболее предпочтительный, особенно когда в экстракции участвует много приложений и требуется длительный период времени для реализации данной задачи. Например, такой бизнес-объект, как "заказ клиента", может быть представлен несколькими основными таблицами СУБД. Отношение между таблицами определяет­ся логикой приложения. Экстракция на уровне базы данных или файла означает, что полный набор данных и соответст­вующие метаданные берутся непосредственно их этих раз­ных таблиц, а это трудная задача, занимающая много време­ни и требующая высокой квалификации[7].

Однако есть ситуации, при которых требуется экстракция на уровне базы данных или файла:

- данные хранятся в файлах (плоских файлах);

- данные отправляются через XML;

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

- структуры таблицы прозрачны;

- экстракция на уровне приложения невозможна.

2.4.2 Экстракция, преобразование и загрузка (ETL) в SAP BW

SAP BW предоставляет пользователям широкий набор возможностей ETL, который поддерживает экстракцию данных на уровнях приложения и файла. Он также предла­гает открытые интерфейсы для внешних инструментов ETL, которые обеспечивают дополнительные возможности. Дан­ные могут загружаться практически из любого источника (рисунок 5).

На рисунке 5 данные становятся доступными в SAP BW в соответствии с определениями исходных данных в каждом источнике данных. Фактические данные из разных источни­ков физически хранятся в объекте Persistent Staging Area (PSA), прозрачной таблице базы данных. PSA - это первич­ная область хранения в информационной модели SAP BW, в которой содержаться данные, запрошенные в неизменном виде из исходной системы. PSA создается для каждого источника данных и исходной системы[3].

Данные перемещаются из источника данных в инфо-источник (рисунок 4). В инфо-источнике содержатся данные, которые связаны друг с другом с точки зрения бизнеса.

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

Для поддержки мэппинга (мэппинг - процесс установления взаимно однозначного соответствия между объектами) в SAP BW отдельные поля источника данных присваиваются соответствующим инфо-объектам, которые составляют инфо-источник. Также в процессе мэппинга точно опреде­ляется, какие данные будут переноситься в инфо-источник из источника данных.

В SAP BW данные переносятся в инфо-пакетах. Инфо-пакет определяет, какие данные, содержащиеся в источнике дан­ных, должны запрашиваться из исходной системы. Инфо-пакет может запрашивать как переменные, так и основные данные при помощи точных параметров, например, только контроллинговая единица 0001 за октябрь 2001 года. Это означает, что инфо-пакеты могут описывать целевые поднаборы данных, содержащиеся в источнике данных. С помо­щью инструментальных средств администратора SAP BW можно планировать и отслеживать перенос инфо-пакетов.

Рисунок 5 - Экстракция, преобразование и загрузка (ETL) в SAP BW

2.5 Хранилище операционных данных (ODS)

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

Хранилище операционных данных, с другой стороны, спро­ектировано для поддержки большого количества запросов на небольшие объемы данных, которые часто обновляются. Оно хранит подробные данные и поддерживает процесс ежедневного принятия решений на тактическом уровне. Точные определения хранилища операционных данных бы­вают разными, но SAP рассматривает его как информацион­ную среду "почти" реального времени, которая поддер­живает оперативную отчетность, взаимодействуя с сущест­вующими операционными системами, хранилищами данных или аналитическими приложениями.

Рисунок 6 – Хранилище данных SAP BW

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

SAP BW предоставляет гибкий доступ к данным в хранилище данных (рисунок 6), хранилище операци­онных данных и многомерных моделях. Данные можно за­гружать из Persistent Staging Area непосредственно в храни­лище операционных данных и хранилище данных. Их также можно загружать непосредственно в многомерные инфо-кубы, если нет необходимости в очистке, преобразовании или консолидации данных, т.е. когда исходная система обеспе­чивает необходимый уровень качества данных.

В SAP BW ODS-объекты и связанные с ними правила обнов­ления, которые обрабатывают поток данных между объек­тами, создают хранилище операционных данных. Хранили­ще операционных данных может состоять из нескольких уровней ODS-объектов, разрешая дальнейшую консолида­цию данных. Например, ODS-объект, который содержит данные об "объеме отгрузки" можно объединить с ODS-объектом, который описывает "входящие заказы" для созда­ния консолидированного объекта "заказов и фактических данных" для продукта. Равно тому, как можно создавать уровни ODS-объектов, можно взвешивать преимущество анализа консолидированных данных относительно расту­щих затрат на хранение, необходимых для создания дополнительных объектов[5].