Добрый день всем посетителям этой статьи!
На правах автора отвечаю, что по сути этой статьи можно понять, из каких таблиц собирается определенная таблица корпоративного хранилища.
Сперва хочу определиться насчет глубины.
На рис.3 видно, что FCT_CARDACC_COMMISS вобрала в себя данные из DIM_ACCOUNTS, DIM_CARDS, DIM_CARDS_HIST, FCT_CARDACC_COMMISS и FCT_NEWACC_COMMISS.
Каждая из пяти перечисленных таблиц, сама может наполняться из ряда других таблиц, поэтому можно последовательно раскрывая каждую увидеть их все.
До бесконечности это может длиться, только в одном случае, если где-то при составлении графа загрузки, мы допустили ошибку и зациклили.
То есть в качестве одного из источников указали приемник этого источника. Но такие просчеты легко отслеживаются в модели с помощью CONNECT BY nocycle.
При правильном графе наполнения хранилища, подобных казусов быть не должно, и раскрытие дерева каждого элемента хранилища имеет конечную ветвь.
Теперь, масштаб.
Если вдаваться в подробности и вспомнить, что еще не изжил себя файловый обмен и источниками данных могут служить структурированные файлы приходящие из вне нашей системы, а там они сами являются какими-либо наполняемыми структурами.
А для кого-то как источник является Internet.
В принципе, модели данных как таковую это все укладывается, но я бы все же остановился на границах информационной системы нашего предприятия.
Для нормального функционирования модели, а она создана на Oracle, нужна информация системных обьектов: Table, View, User и Link.
На правах автора отвечаю, что по сути этой статьи можно понять, из каких таблиц собирается определенная таблица корпоративного хранилища.
Сперва хочу определиться насчет глубины.
На рис.3 видно, что FCT_CARDACC_COMMISS вобрала в себя данные из DIM_ACCOUNTS, DIM_CARDS, DIM_CARDS_HIST, FCT_CARDACC_COMMISS и FCT_NEWACC_COMMISS.
Каждая из пяти перечисленных таблиц, сама может наполняться из ряда других таблиц, поэтому можно последовательно раскрывая каждую увидеть их все.
До бесконечности это может длиться, только в одном случае, если где-то при составлении графа загрузки, мы допустили ошибку и зациклили.
То есть в качестве одного из источников указали приемник этого источника. Но такие просчеты легко отслеживаются в модели с помощью CONNECT BY nocycle.
При правильном графе наполнения хранилища, подобных казусов быть не должно, и раскрытие дерева каждого элемента хранилища имеет конечную ветвь.
Теперь, масштаб.
Если вдаваться в подробности и вспомнить, что еще не изжил себя файловый обмен и источниками данных могут служить структурированные файлы приходящие из вне нашей системы, а там они сами являются какими-либо наполняемыми структурами.
А для кого-то как источник является Internet.
В принципе, модели данных как таковую это все укладывается, но я бы все же остановился на границах информационной системы нашего предприятия.
Для нормального функционирования модели, а она создана на Oracle, нужна информация системных обьектов: Table, View, User и Link.