Логика контекста физики.

В: Скажите, есть ли у вас какая-нибудь недвижимость?
С: Нет.
В: Вклады в банке?
С: Нет.
В: Как я понимаю, вы сейчас учитесь?
С: Да, я студент.
В: Понимаете, я просто хочу определить, есть ли что-то, что будет удерживать вас в Украине.
С: Удерживать? Конечно есть, учёба удерживает.

Из разговора между студентом и сотрудником визового центра одной из стран шенгена при оформлении визы.

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

---

Физическая архитектура

Физическая архитектура описывает различные элементы информационных систем, с которыми взаимодействует ODI и определяет их характеристики.
Технология - обрабатывает данные определенных форматов. Таким образом, каждая технология включает в себя некоторый набор типов данных, и это позволяет Oracle Data Integrator генерировать скрипты преобразования данных из одного типа в другой.

Примечание: Любая СУБД (Oracle, DB2 и т.п.) формат файла (XML, File) или приложение представлено в ODI соответствующей технологией.

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

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

В конечном итоги, физическая архитектура включает определение физических агентов (специальных программ на Java) которые позволяют задачам Oracle Data Integrator выполняться на удаленных машинах.

Логическая архитектура

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

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

Контекст

Контекст соединяет вместе части физической архитектуры (реальной архитектуры) информационной системы с частями логической архитектуры (теми абстракциями, с которыми взаимодействует разработчик ODI при разработке ETL преобразований).

Пример: Логическая схема "Бухгалтерия" описывает абстрактное понятие, место, где находятся таблицы источники данных, загружаемые интерфейсами ODI в хранилище данных.

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

При этом структурно (количеством, названием и структурой таблиц и т.п.) данные схемы полностью совпадают, но расположены в разных схемах СУБД Oracle, и, вполне возможно, на разных Дата серверах (серверах данных).

Наличие контекста Dev позволяет разрабатывать и запускать интерфейсы на анонимизированных данных.
Наличие контекста Prod позволяет выполнять загрузку данных в ХД находящееся в промышленном использовании.

---

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

Вспомним, что каждая модель данных соединена с определенной логической схемой.

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

модель данных ---> логическая схема ---> несколько физических схем (один и тот же тип СУБД (соответственно, одна технология), разные схемы и/или экземпляры с одним и тем же набором таблиц)

Мы должны иметь по одной логической схеме для каждого этапа преобразования данных в ХД (между этапами меняется структура таблиц), так же верно, что мы должны иметь логическую схему для каждого источника данных (как связанного набора таблиц) в топологии ODI.

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

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

То есть, контекст Dev соединяет логическую модель Stage с физической схемой DS расположенной в СУБД Oracle на сервере под названием DWHDB1. А контекст Prod делает соединение той же логической схемы с совершенно другим сервером (PRD_DB) с данными, физически находящимися в схеме SourceStage. Т.е. в этом примере и сервера разные, и схемы называются по разному.

Второй вариант: тот же Dev контекст, а также контекст Test, соединяющий логическую схему Stage с физической схемой DS_Test на том же сервере DWHDB1. В данном случае используется один и тот же физический сервер для разработки и тестирования, что очень помогает в случае, когда нет возможности использовать для тестирования сопоставимый промышленному по мощности сервер СУБД.

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

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

Вот, в первом приближении, пока все. Будут вопросы - пишите.