Источник: deepedit
deepedit
God aften!
Представления (или, как их еще называют - вьюхи) очень важны, иногда они являются непосредственным воплощением ETL процесса. Например, на этапе загрузки данных из источников вполне вероятно использование представлений для простейших преобразований данных.
Нельзя сказать, что такое важное значение представлений никак не отражено в фольклоре. Как поет фронтмен группы ETaLlica - James_PK_Head_Field:
I am the View
I am the Table(t).
I am the View, I am the Table(t).
Даже из этого отрывка ясно, что представления многими ставятся на одно из первых мест.
В ODI есть возможность создания таблиц, например, с помошью опций модулей знаний можно создавать временную таблицу, но нет модуля знаний для создания представлений.
Из своего опыта, я хотел бы отметить две возможных задачи, которые периодически возникают при разработке ETL проектов. Первая задача - иметь возможность отслеживать пути происхождения данных, иногда это называется lineage, если в этой цепочке есть представления. И вторая задача - создание объектов БД при развертывании на промышленном сервере или в новой схеме БД при разработке.
В случае создания таблиц можно воспользоваться механизмами Конструктора Моделей. Код представлений также можно хранить в виде процедур по их созданию, но существует более подходящий вариант.
На одном из проектов я увидел, что существует специальный модуль знаний, для создания представлений. Этот модуль использовался при моделировании представления через интерфейс ODI. Я уточнил у коллег, оказалось, что этот модуль знаний не поставляется вместе с ODI, т.е. является самописным.
Итак, как же получить такой модуль знаний из того, что уже есть? На самом деле, совсем просто. Стандартный модуль знаний для загрузки данных из Oracle в Oracle имеет необходимый нам кусок. Смотрите, LKM Oracle to Oracle (DBLINK) работает, в упрощенном изложении, по следующему алгоритму:
- Удалить dblink на целевой БД.
- Создать dblink на целевой БД.
- Создать представление/таблицу на источнике.
- Создать синоним на результат пункта 3 в целевой БД.
- Далее работает интеграционный модуль знаний.
- Удалить созданное в пунктах 4, 3, 2.
Таким образом все, что необходимо сделать для создания нового модуля знаний для создания представлений, это небольшая модификация уже существующего кода из другого модуля знаний, штатно поставляемого с ODI.
Вот этот код:
create or replace view <%=odiRef.getTable("L", "TARG_NAME", "D")%>
(
<%=odiRef.getColList("", "[CX_COL_NAME]", ",\n\t", "", "")%>
)
as select <%=odiRef.getPop("DISTINCT_ROWS")%>
<%=odiRef.getColList("", "[EXPRESSION]", ",\n\t", "", "")%>
from <%=odiRef.getFrom()%>
where (1=1)
<%=odiRef.getFilter()%>
<%=odiRef.getJrnFilter()%>
<%=odiRef.getJoin()%>
<%=odiRef.getGrpBy()%>
<%=odiRef.getHaving()%>
Если я ничего не забыл, код, по сравнению с оригинальным вариантом, измененился только в плане передаваемых команде getTable параметров.
Создайте новый интеграционный модуль знаний и поместите приведенный код в единственный шаг этого IKM на вкладку Command on Target
Выглядеть будет примерно так:
И, как результат, при просмотре через модель ветки Populated By, будут видны таблицы или представления, которые загружают данное представление:
Таким образом, в полном согласии с заветами, мы начали с существующего кода в поставляемом модуле знаний и модифицировали его для наших нужд.