Организация моделей и проектов в ODI.

Приветствую.

Перевод заметки Ули Бетке под названием Best practice of organizing interfaces and data stores into projects and models in ODI.

<Начало перевода>

---

Задумывались ли вы как лучше всего организовать структуру объектов в проекте ODI? Можно дальше не искать, я обрисую то, что хорошо подходит для Корпоративного Хранилища Данных (EDW).

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

Область стейджа

Можно продолжить разбиение или группировку моделей систем источников по типу или технологиям, например, источники в файлах, в Oracle DB, в XML и т.п.



По тому же принципу вы подразделяете модель области стейджа на подмодели базируясь на типе источника



То же самое происходит с объектами проекта Стейдж:

Детальные данные

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



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

Подобным же образом вы разделяете модель детальных данных на подмодели по предметным областям.

Витрины данных

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



Одно замечание напоследок. Вы, возможно, будете встречать утверждение о том, что не стоит превышать ограничение в 300 объектов в проекте ODI. Я не знаю, откуда взялось такое ограничение. Я никогда не встречался с проблемами при превышении этого значения. Если бы это было на самом деле так, это было бы серьезным недостатком ODI.

---

<Конец перевода>

Я где-то читал об описанном выше ограничении, но оно, скорее, звучало как рекомендация, а не жесткий запрет. В проекте, над котором я в данный момент тружусь, ODI используется в полную силу, хоть и не во всех своих возможных применениях. Так вот у нас ситуация примерно такова:

количество проектов в одном репозитории - ~20
среднее количество папок во всех проектах - ~15
максимальное количество папок в проекте - ~130
среднее количество интерфейсов во всех проектах - ~465
максимальное количество интерфейсов в проекте - ~2500
Все пока работает без особых нареканий, чего я и вам желаю.