Какие задачи решает агент системы на шине данных

В посте по интеграции систем посредством шины данных я писал о такой компоненте, как агент системы на шине данных. Агент системы на шине данных — это набор процедур, адаптирующий сообщения, предназначенные для передачи в систему, к специфике системы, и, наоборот, адаптирующий специфичные сообщения, полученные из системы, к требованиям других клиентов шины данных. Под спецификой системы понимаются соглашения, структура, состав, формат входящих и исходящих сообщений системы.

(Возможно, удачнее было бы назвать агента системы адаптером.)

Вот некоторые типичные кейсы, с которыми работает агент системы.

Загрузка изменений за прошлые даты в ДТФ

В посте о диапазонных таблицах фактов (ДТФ) я привел алгоритм их заполнения из ежедневных снэпшотов, содержащих данные на текущую дату. Алгоритм также годится для заполнения ДТФ в случае, когда на входе не регулярные (ежедневные) снэпшоты, а только нерегулярные изменения (дельта).

Но время от времени возникает задача добавления в непустую ДТФ новых или измененных данных за прошлые даты, и упомянутый алгоритм для этого не годится. Поэтому рассмотрим универсальный алгоритм заполнения ДТФ из источника, откуда поступают данные как на текущую дату, так и на прошлые даты — если данные за прошлую дату изменились.

Интеграция систем посредством шины данных

Ранее я писал о том, как мы интегрировали системы через шину данных. Этот пост продолжает тему интеграции систем через шину данных.

Дано: несколько систем и шина данных, реализующая обмен сообщениями через отдельные каналы (топики) по принципу publish - subscribe.

Цель: интегрировать системы посредством сообщений об изменениях, передаваемых и получаемых в/из шины данных.

Соединение диапазонных таблиц фактов

В прошлый раз я описал компактную форму хранения нерегулярно меняющихся данных в диапазонной таблице фактов (ДТФ) на основе периодических снэпшотов.

Речь идет о таблице фактов в широком смысле:

"Каждая таблица с составным ключом из нескольких внешних ключей – это таблица фактов." Ральф Кимбалл

Такая таблица не обязательно принадлежит презентационному слою хранилища данных, но на законных основаниях может жить в промежуточном слое, который предоставляет данные для витрин. (Кстати, такая таблица в терминах Data Vault — сателлит линка.)

Компактное представление истории нерегулярно меняющихся данных

Тема данного поста навеяна чтением Ральфа Кимбалла, который выделяет три вида таблиц фактов при построении хранилищ данных: транзакционные, снэпшотные и накопительные. В первых каждой строке соответствует отдельная транзакция (бизнес-операция, факт снятия показаний, зарегистрированное уникальное событие), загружаемая в хранилище данных из системы-источника. Вторые формруются из периодически загружаемых моментальных снимков (снэпшотов), где каждый снэпшот содержит множество строк. Третьи допускают многократное обновление строк, поскольку их строки описывают некие эволюционирующие сущности, например, заказы с этапами жизненного цикла или продажи за месяц при ежедневном обновлении.

Поговорим о снэпшотных таблицах фактов. И начнем с определения контекста.