Совет 1. Именование объектов.
Начнем с совсем простого, т.е. с того, как называть свои пакеты, интерфейсы и функции. Хорошей практикой считается подход, когда интерфейс называется так же, как и целевая таблица, которая этим интерфесом заполняется. По названию процедуры должно быть понятно, что она и примерно как делает. Пакет именуется по тем же принципам.
Совсем недавно я обнаружил, что наименование сценария для объекта автоматически генерируется в верхнем регистре:
Этот момент может быть использован для визуального разделения запусков, которые производит разработчик, или, например, тестировщик, при разработке ETL. Таким образом, если мы видим, что сессия запускается вся в верхнем регистре - значит запускался сценарий. Иначе - пакет.
Следовательно, совет - именовать пакеты, интерфейсы, процедуры по принципу Первая_Заглавная_Буква, а сценарии уже автоматически сгенерируется в ВЕРХНЕМ_РЕГИСТРЕ.
Совет 2. Построение диаграммы интерфейса.
Встречаются интерфейсы, у которых количество источников данных достаточно велико. Например, 20 таблиц источников. При этом, бывает, вся диаграмма выглядит достаточно скомканно:
Чтобы немного увеличить полезную площадь экрана, и разместить таблицы источники так, чтобы было чуточку яснее, что с ними происходит, можно временно отключить отображение панели свойств, целевой таблицы, да и список объектов тоже скрыть.
На картинке показано состояние, когда три перечисленных окна отображаются. Нажатие на выделенные красным иконки приведет к их закрытию. Повторно отобразить эти окна можно точно так же.
Совет 3. Построение диаграммы пакета.
Примерно тот же подход можно использовать при разработке пакета. Т.е. прятать, при необходимости:
а) - панель объектов; б) - панель свойств; в) панель инструментов; г-д) убрать с диаграммы указатели следующего успешного или неуспешного шагов.
Совет 4. Перенос объектов между папками
Для переноса объектов между папками, например, после дуплицирования интерфейса, чтобы перенести его копию в папку разработчика для разработки модификаций, можно применить такой же подход "открыть в новом окне", как описано в разделе Группировка сценариев по папкам.
Совет 5. Дублирование нескольких элементов диаграммы пакета
Этот метод подсмотрен вот здесь. Суть его очень простая. Выделяем несколько шагов на диаграмме пакета, например, запуск сценария, ожидание его завершения и нажимаем на кнопку Duplicate Step:
Используя этот удобный механизм, можно быстро подготовить обвязку для сохранения ошибок в дочерних сценариях по описанному здесь подходу.
Совет 6. Настраиваем параметры
Параметры Дизайнера, так же как и параметры остальных клиентских приложений ODI настраиваются через меню File - User Parameters. Я рекомендую настроить следующие три, выделенные красным на картинке:
Автоматический маппинг (Automatic Mapping) - рекомендую оставлять значение Ask. Это приведет к тому, что при смене целевой таблицы (либо первом добавлении ее в интерфейс), приложение Дизайнер будет делать запрос на автоматическое сопоставление колонок таблиц источников и таблицы приемника. Иногда быстрее позволить программе сделать это самой.
Блокировать объект при открытии (Lock object when opening) - рекомендую ставить 0, т.е. не блокировать объект при открытии. При правильной организации совместной работы в такой блокировке больше вреда, чем пользы.
Удалять сессии вместе с удалением сценария (Delete linked session with scenarios) - настоятельно рекомендую отключить эту опцию. Включение этой опции приведет к тому, что при удалении сценария, логи запуска этого сценария тоже будут удалены из репозитория. На практике такой подход приведет к тому, что, например, при ошибке работы сценария разработчик меняет объект и перегенерируют сценарий для этого объекта. Перегенерация сценария это его удаление и создание. После удаления, лога выполнения с ошибкой в Операторе не будет.
Остальные два параметра описаны в этом посте.
Совет 7. Прячем неиспользуемые технологии
Меню Windows пункт Hide Unused Technologies позволит видеть только перечень тех технологий, которые реально используются в мастер репозитории. Т.е. для них настроены физические и логические архитектуры, контексты и т.п. Лучше всего включение этой опции поможет при работе в приложении Менеджер топологий.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.