Расширение ММА для задач бюджетирования.
В данной статье рассматривается вариант расширения многоуровневой масштабируемой архитектуры (LSA) для задач бюджетирования.
Существенное отличие информационного хранилища решающего задачи подготовки данных для отчетности от бюджетирования заключается в том, что если ETL – это обработка, модификация, обогащение и подготовка данных, осуществляемая без участия пользователя, то бюджетирование в первую очередь это процесс в котором основная роль отводится ответственному пользователю. Концепция ММА архитектуры, концентрирующаяся на разделении потоков данных по слоям и доменам, по умолчанию не выделяет в своей структуре отдельного слоя для решения задач бюджетирования, поэтому для эффективного развития архитектуры такой слой необходимо добавлять.
Уровень интеграционного планирования IPL (Integrated Planing Lavel)
• Этот слой не является обязательным и содержит инфо-кубы планирования.
• Время жизни данных в зависимости от требований планирования от 1 года до нескольких лет.
• Может получать данные из BTL, FRL, DRL посредством функций планирования.
• Используется для ввода данных планирования в систему в ручном режиме.
Уровень логирования вводимых IP данных LPL (Logging Planing Layer)
Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland
ЗарегистрироватьсяУ вас уже есть учетная запись?
Войти
Обсуждения
2
Комментарий от
Сергей Моисеев
| 11 сентября 2013, 14:20
А где в этой архитектуре место для архивированных данных?
Для всех уровней срок жизни не превышает нескольких лет.
Если существуют требования по архивированию данных на сроки измеряемые десятками лет с целью обеспечения к ним редкого доступа по запросу. То в таком контексте, архивирование вообще не является задачей для BW, а должно достигаться на уровне исходых систем?
Тогда данные планирования после переноса в такой архив, также надо рассматривать в качестве исходной системы? И в случае развития текущей модели данных, доступ к архивным может быть настроен за счет настройки ETL и переноса по запросу?
Комментарий от
Илья Муковоз
| 30 сентября 2013, 12:19
Сергей Моисеев 11 сентября 2013, 14:20
Алексей, здравствуйте.
А где в этой архитектуре место для архивированных данных?
Для всех уровней срок жизни не превышает нескольких лет.
Если существуют требования по архивированию данных на сроки измеряемые десятками лет с целью обеспечения к ним редкого доступа по запросу. То в таком контексте, архивирование вообще не является задачей для BW, а должно достигаться на уровне исходых систем?
Тогда данные планирования после переноса в такой архив, также надо рассматривать в качестве исходной системы? И в случае развития текущей модели данных, доступ к архивным может быть настроен за счет настройки ETL и переноса по запросу?
Для архивирования данных предназначен слой CML (Corparate Memory Layer) - уровень корпоративного хранилища данных. По умолчанию предполагается что для выполнения анализа исторических данных достаточно 2 года истории, но ничто не мешает хранить и 5 и 10 лет истории, другое дело что трудно представить себе организацию, где процессы или номенклатура не менялись бы в течении более чем 2-х лет (возникает задача совместимости идентификаторов). Для компаний где изменения все же происходят, исторические тренды удобней хранить в виде KPI, что позволяет уходить от глубокой детализации к конкретным показателям эффективности.
Что касается технической реализации механизмов хранения 10-ти летней истории, то в BW поддерживаются механизмы NLS (Near Line Storage) которые позволяют хранить редко используемые данные на ленточных носителях (работают медленно, но надежно).
Данные планирования - да, их тоже можно рассматривать как исходные данные, коими с точки зрения as-is анализа они и являются.