Единый источник истины

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

Существует несколько сценариев относительно копий и обновлений:

• Основные данные никогда не копируются, вместо этого на них делаются только ссылки; это означает, что все операции чтения и обновления передаются непосредственно в SSOT.
• Основные данные копируются, но копии только считываются и обновляются только основные данные; если запросы на чтение данных выполняются только по копиям, это экземпляр CQRS .
• Основные данные копируются, а копии обновляются; для этого необходим механизм согласования при наличии одновременных обновлений.
  • Обновления копий могут быть удалены всякий раз, когда на ведущем устройстве выполняется одновременное обновление, поэтому они не считаются полностью зафиксированными до тех пор, пока не будут распространены на ведущее устройство. (многие блокчейны работают именно так.)
  • Одновременные обновления объединяются. (если автоматическое слияние не удалось, оно может вернуться к другой стратегии, которая может быть предыдущей стратегией или чем-то еще, например, ручным вмешательством, что делает большинство систем контроля версий исходного кода.)

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

В идеале системы SSOT предоставляют данные, которые являются подлинными (и аутентифицируемыми ), актуальными и пригодными для ссылки .

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

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

Реализация

Онтологические взаимодействия

Признанной предпосылкой (представления о том, что может существовать любой данный единственный источник истины) является то, что в зависимости от онтологического условия существует не более чем одна истина (о любом конкретном факте или идее), утверждение, которое является онтологическим как в ИТ-смысл и общий смысл этого слова. Во многих случаях это не представляет проблемы (например, в определенных пространствах имен или даже между ними, если конфликты имен или более широкие конфликты имен адекватно обрабатываются). Самые широкие контексты (и, следовательно, самые сложные в отношении онтологических расхождений) требуют адекватного эпистемических режимов сравнения и согласования (или, по крайней мере, переговоров или транзакционного обмена). Архетипическим примером этого класса примирения является то, что две библиотеки богословской семинарии , принадлежащие к двум различным религиям (X и Y), могут обмениваться информацией с архитектурой SSOT, но объединение истины будет находиться на уровне утверждения, что «религия X утверждает, что Бог фиолетовый, тогда как религия Y утверждает, что Бог зеленый», а не на уровне «Бог фиолетовый» или «Бог зеленый».

Архитектура или архитектурные особенности

Идеальная реализация SSOT редко возможна на большинстве предприятий. Это связано с тем, что многие организации имеют несколько информационных систем, каждая из которых нуждается в доступе к данным, относящимся к одним и тем же объектам (например, клиенту). Часто эти системы приобретаются у поставщиков как готовые коммерческие продукты и не могут быть модифицированы тривиальными способами. Поэтому каждая из этих различных систем должна хранить свою собственную версию общих данных или объектов, и, следовательно, каждая система должна хранить свою собственную копию записи (следовательно, это немедленно нарушает подход SSOT, определенный выше). Например, система планирования ресурсов предприятия (ERP) (такая как SAP или Oracle e-Business Suite ) может хранить записи о клиентах; системе управления взаимоотношениями с клиентами (CRM) также необходима копия записи о клиенте (или ее части), а системе складской диспетчеризации также может потребоваться копия некоторых или всех данных о клиенте (например, адреса доставки). В тех случаях, когда поставщики не поддерживают подобные модификации, не всегда возможно заменить эти записи указателями на SSOT.

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

• Управление основными данными (MDM)
• Хранилище событий и источник событий (ES)

Управление основными данными (MDM)

Система MDM может выступать в качестве источника истины для любого объекта, который не обязательно имеет альтернативный «источник истины» в другой системе. Обычно MDM действует как концентратор для нескольких систем, многие из которых могут разрешать (быть источником достоверной информации) обновления различных аспектов информации о данном объекте. Например, CRM-система может быть «источником истины» для большинства аспектов деятельности клиента и обновляется оператором колл-центра. Однако клиент может (например) также обновить свой адрес через веб-сайт службы поддержки клиентов, используя другую внутреннюю базу данных из CRM-системы. Приложение MDM получает обновления из нескольких источников, действует как посредник, определяя, какие обновления следует считать достоверными («золотая запись»), а затем распространяет эти обновленные данные во все системы-подписчики. Приложению MDM обычно требуется, чтобы ESB объединял свои данные с несколькими системами-подписчиками.

Хранилище событий и источник событий (ES)

В событийно-ориентированных архитектурах все чаще встречается реализация шаблона Event Sourcing , который сохраняет состояние системы в виде упорядоченной последовательности изменений состояния. Для этого вам понадобится Event Store — особый тип базы данных, предназначенный для хранения всех событий, изменяющих состояние системы. Хранилище событий в архитектуре «Источник событий + Разделение ответственности за запросы команд + Проектирование на основе домена + Обмен сообщениями » фактически является «единым источником достоверной информации» с дополнительным преимуществом, заключающимся в том, что оно также может действовать как корпоративная сервисная шина, поскольку может напрямую прослушивать хранилище событий для статуса меняется по мере того, как все проходит. Кроме того, сохраняя все события, он также играет роль Хранилища Данных . Последнее преимущество заключается в том, что с помощью этой системы можно реализовать шаблон общей базы данных , еще один не упомянутый метод получения единого источника истины.

Хранилище данных (DW)

Хотя основной целью хранилища данных является поддержка отчетности и анализа данных, которые были объединены из нескольких источников, тот факт, что такие данные были объединены (в соответствии с бизнес-логикой, встроенной в процессы преобразования и интеграции данных ), означает, что данные Склад часто используется как фактический SSOT. Однако, как правило, данные, доступные из хранилища данных, не используются для обновления других систем; скорее, DW становится «единым источником правды» для отчетности перед множеством заинтересованных сторон. В этом контексте хранилище данных правильнее называть « единой версией истины », поскольку в его операционных источниках данных существуют другие версии истины (никакие данные не происходят из хранилища данных; это просто механизм отчетности для загруженных данных). из операционных систем).

См. также

• Блокчейн , распределенное хранилище данных для цифровых транзакций.
• Циклическая отчетность , проблема, когда источник откуда-то получает информацию, которая затем использует этот источник в качестве ссылки.
• Нормализация базы данных , метод проектирования таблиц в реляционных базах данных, позволяющий свести к минимуму дублирование информации.
• Единая версия истины , идеальная, когда все данные организации хранятся в согласованной и неизбыточной форме.
• Единая версия фактов , концепция в хранилище данных
• Система записи , авторитетный источник данных для данного элемента данных.

Исходный код

При разработке программного обеспечения одна и та же схема, бизнес-логика и другие компоненты часто повторяются в разных контекстах, при этом каждая версия называет себя «исходным кодом». Чтобы решить эту проблему, концепции SSOT также можно применить к принципам разработки программного обеспечения с использованием таких процессов, как рекурсивная транскомпиляция, для итеративного преобразования одного источника истины во множество различных типов исходного кода, которые будут структурно соответствовать друг другу, поскольку все они получены из тот же ССОТ.