Каталог решений - Заметки: Общие требования к НСИ (нормативно-справочная информация). Управление НСИ

Добрый день, коллеги. 

Тема к обсуждению.

Что такое НСИ (нормативно-справочная информация).

Кратко: Справочники, хранящие условно-постоянную информацию.

Цитата: "Ключевое отличие НСИ от однократно вводимой информации состоит в том, что НСИ многократно используется при производстве данных, соответственно, ошибки в ней обходятся очень дорого."

Пример: Справочник Контрагенты( используются и переиспользуются во многих “документах” и операциях систем. в Заказ клиента, в Актах, в Заказах поставщику и тд)

Есть два способа управления условно-постоянными данными: централизованный ( единая НСИ), децентрализованный ( каждая система сама владеет данными, и сама договаривается с другими системами об интеграциях). ( Есть также Bounded Context, но это требует отдельной статьи).

Рассмотрим Централизованные НСИ.

Общий принцип построения централизованных НСИ.

Некая центральная база (или система), имеющая интерфейс доступа, api для работы с данными в базе.

К ней подключаются системы потребители, по понятному-общепринятому протоколу.

Центральная НСИ умеет и отвечает за  хранение, управление, раздачу централизованных данные, оповещает об изменениях, хранит историю  и т.д.

Важно. Связи между базами и контроль данных однозначны. Мастер система одна, в ней заводят и редактируют данные. Данные через нее попадают в другие системы однозначно. НСИ оповещает об имениях потребителей, или умеет давать такую информацию, IDM пока так не делает.

Свойства в данных

В общем случае Центральная НСИ может содержать только два свойства: уникальный ИД элемента, и наименование. Остальные свойства могут хранится в системах потребителях.

Все свойства(данные) можно разделить на, условно, два типа:

1. Свойства уникальные для каждой системы.

2. НЕ уникальные свойства.

Уникальные свойства — управляются системой потребителем. Хранятся в системе потребителе, в обменах не участвуют. (Пример: ГФУ в КА, Группа Финансового учета, в зависимости от которой формируются проводки в КА. Данное свойство важно только для КА. Другим системам не интересно.)

НЕ Уникальные свойства. Если свойство используется в двух и более системах, оно считается не уникальный. И в общей практике хранится в Центральной НСИ. Управляется (вносится и редактируется) в Центральной НСИ (возможно! в системе потребителе, с понятной обратной связью в центральную НСИ). Участвует в обменах.

Важно понимать. НЕ уникальные свойства, если не сопровождаются единой центральной НСИ, очень быстро порождают паразитические связи ( обмены) между другими потребителями. Что приводит к снижению достоверности в данных, и в сложности поддержки данных связей. Проще говоря будем ловить ошибки в данных в каждой системе + трудозатраты.

И что теперь?

Важно определить какие свойства являются:

1. Уникальными (напомню: хранятся только в системе потребителе)

2. НЕ уникальными (хранятся и управляются в центральной НСИ, раздаются всем)

Есть исключения.

Если свойство не значительно (с точки зрения поведения систем) : его можно считать уникальным и игнорировать в обменах, и в управлении НСИ.

Если свойство используется в упрощенном обмене,  между двумя системами, также можно пренебречь его НЕ уникальностью, и обходится без Централизованной НСИ (пример — ставка НДС , которая важна только для КА и БУ).

Как определить: понять, где, в каких процессах, в каких метриках компании, свойства используются.

А дальше уже задача архитектора грамотно выстроить системы и обмены между ними.