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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В торговой сети "Бубль-Гум" десяток взаимодействующих информационных систем, а в качестве шины данных у нас Apache Kafka.

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

JSON или CSV для обмена данными между БД?

Заметил, что зачастую для интеграции реляционных баз данных используются объектно-ориентированные сообщения. В сущности, это означает лишние расходы на преобразования между реляционным и объектным представлениями данных.

Например, в системе управления заказами клиентов есть логическая сущность заказ, состоящая из "шапки" и строк заказа. В реляционной БД она представляется двумя таблицами.

Моделирование данных (о терминах и смыслах)

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

Борхес, "Аналитический язык Джона Уилкинса"

Модели данных делятся на

а) концептуальные,
б) реляционные,
в) корпоративные,
г) "сущность-связь",
д) предметной области,
е) незавершенные,
ж) приснившиеся архитектору данных за пять минут до пробуждения.

Ну, вы поняли?

Виды данных в информационных системах

Неоднократно встречал деление данных в информационных системах (далее ИС) на

1. справочники,
2. мастер-данные,
3. документы,
4. метаданные.

Этого недостаточно, чтобы представить типичное разнообразие данных с точки зрения их моделирования и задач, возникающих при эксплуатации ИС. Вот мое деление, которым пользуюсь несколько лет и которое кажется довольно удачным:

1. справочники,
2. ресурсы,
3. конфигурации,
4. операции,
5. транзакции,
6. деривативы,
7. метаданные.

Опишу эти виды данных неформально, но доходчиво.

Периодические таблицы-2 (не химия)

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

select *
from ttt
where current_date between first_date and last_date
;

Подход естественный и очевидный. В самом деле, январь длится с 1 по 31, включительно. Неделя длится с понедельника по воскресенье, включительно. Акция в магазине проходит с 10 по 15 апреля, включительно.

Однако! Магазин работает с 10 до 20 часов, исключая 20 часов. Обеденный перерыв длится с 13 до 14 часов, исключая 14 часов, а с 14 до 14:30 проходит совещание – исключая 14:30.

Неизвестное vs Отсутствующее, или Двуликий NULL

Когда-то я уже писал о "многоликом NULL", см. Часть I и Часть II. Сегодняшний пост в дополнение и в развитие этой темы.

Я неоднократно встречал утверждение, что NULL в SQL нужно понимать как "неизвестно что". С этим согласуется поведение операторов сравнения при сравнении двух NULL (команды выполнены в PostgreSQL 15):

select 1
where null = null
   or null != null
   or null < null
   or null <= null
   or null >= null
   or null > null
;

no rows

Активирование и деактивирование логических сущностей в оперативной БД

Каждая логическая сущность предметной области

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

Например, запись справочника может быть активной в течение всего жизненного цикла – от ее создания до удаления, или до выведения системы из эксплуатации. А экземпляр мастер-данных (товар, партнер, сотрудник и т.д.), как правило, активен в течение некоторого периода времени, пока с ним работают бизнес-процессы (пока товар закупается или продается, пока партнер связан договорными отношениями, пока сотрудник не уволился, и т.д.).

Какого ограничения целостности не хватает в SQL

Константного - когда значение в столбце, присвоенное insert'ом, нельзя изменить update'ом.

Столбцов, которые выиграют от такого ограничения, достаточно много - это, конечно, первичные ключи, и другие атрибуты, описывающие неотъемлемые неизменные свойства объектов, без которых объект утрачивает свою "природу" и перестает быть собой, например, тип товара, вид заказа и подобные. В приложении, с которым работают пользователи, такие поля доступны для заполнения при создании новой записи и недоступны для изменения при редактировании уже существующей.

Можно, конечно, создать триггер для update, который запретит изменение, если новое значение такого столбца отличается от старого.

Периодические таблицы (не химия)

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

В связи с этим при вставке или изменении записи нужно проверять, не приведет ли эта операция к появлению в таблице записей с пересекающимися периодами.

Про отношения с таблицами. C примерами на SQL

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

Например, для двух множеств

A = {1, 2, 3}
B = {'Стакан', 'Лимон'}

декартово произведение есть

A x B = {
    (1, 'Стакан'), 
    (1, 'Лимон'),
    (2, 'Стакан'),
    (2, 'Лимон'),
    (3, 'Стакан'),
    (3, 'Лимон')
}

Вперед к основам: 1NF, 2NF, 3NF

Учитель сказал:
- Учиться и время от времени повторять изученное, разве это не приятно?

Конфуций, "Лунь Юй"

В нормализованной реляционной БД практически исключена избыточность данных. Это значит, что для изменения некоторого факта, хранимого в БД, достаточно только в одном месте добавить, удалить или модифицировать данные. Тем самым, нормализация БД способствует поддержанию целостности данных, снижая риск логических ошибок в процессе изменения данных. Кроме того, нормализованная схема данных с большой вероятностью адекватна предметной области, интуитивно понятна и расширяема.

В 1970 - 1971 годах Эдгар Кодд впервые сформулировал требования к нормализованным структурам данных, названные им нормальная форма 1, 2 и 3 (1NF, 2NF, 3NF). С тех пор были определены еще несколько нормальных форм, которые предъявляют дополнительные требования к организации данных в реляционной БД; о них можно прочитать, например, в статье Википедии.

Однако, в большинстве случаев достаточно обеспечить соответствие реляционной структуры данных 3-ей нормальной форме (3NF). Далее будут рассмотрены первые три нормальные формы, примеры их нарушения, сопутствующие этому проблемы и способы их решения.