В информационной науке и информационных технологиях архитектура единого источника истины ( SSOT ) или архитектура единой точки истины ( SPOT ) для информационных систем представляет собой практику структурирования информационных моделей и связанных с ними схем данных таким образом, что каждый элемент данных обрабатывается (или редактируется) только в одном месте, обеспечивая нормализацию данных до канонической формы (например, при нормализации базы данных или включении контента ).
Существует несколько сценариев относительно копий и обновлений:
Преимущества архитектуры SSOT включают в себя более простое предотвращение ошибочных несоответствий (например, когда где-то забывается дублирующее значение/копия) и значительно упрощенный контроль версий . Без SSOT работа с несоответствиями подразумевает либо сложные и подверженные ошибкам алгоритмы консенсуса, либо использование более простой архитектуры, которая может потерять данные в случае несоответствия (последнее может показаться неприемлемым, но иногда это очень хороший выбор; так работает большинство блокчейнов: транзакция фактически является окончательной, только если она была включена в следующий добываемый блок).
В идеале системы SSOT предоставляют данные, которые являются подлинными (и поддающимися аутентификации ), релевантными и пригодными для использования . [1]
Развертывание архитектуры SSOT становится все более важным в корпоративных условиях, где неправильно связанные дублирующие или денормализованные элементы данных (прямое следствие преднамеренной или непреднамеренной денормализации любой явной модели данных) представляют риск извлечения устаревшей и, следовательно, неверной информации. Распространенными примерами (т. е. примерными классами реализации) являются следующие:
Признанной предпосылкой (представления о том, что может существовать любой заданный единственный источник истины) является то, что это зависит от онтологического условия, что существует не более одной истины (о любом конкретном факте или идее), утверждение, которое является онтологическим как в смысле ИТ , так и в общем смысле этого слова. Во многих случаях это не представляет проблемы (например, в пределах определенных пространств имен или даже между ними, пока коллизии имен или более широкие конфликты имен адекватно обрабатываются). Самые широкие контексты (и, следовательно, самые тернистые, относительно онтологических расхождений) требуют адекватного сравнения и согласования эпистемического режима (или, по крайней мере, переговоров или транзакционных обменов). Типичным примером такого рода примирения является случай, когда две библиотеки теологических семинарий , принадлежащие к двум разным религиям (X и Y), могли обмениваться информацией с помощью архитектуры SSOT, но объединение истины будет происходить на уровне утверждения, что «религия X утверждает, что Бог фиолетовый, тогда как религия Y утверждает, что Бог зеленый», а не на уровне «Бог фиолетовый» или «Бог зеленый».
Идеальная реализация SSOT редко возможна на большинстве предприятий. Это связано с тем, что многие организации имеют несколько информационных систем, каждой из которых необходим доступ к данным, относящимся к одним и тем же сущностям (например, клиенту). Часто эти системы приобретаются как коммерческие готовые продукты у поставщиков и не могут быть изменены тривиальными способами. Поэтому каждая из этих различных систем должна хранить свою собственную версию общих данных или сущностей, и поэтому каждая система должна сохранять свою собственную копию записи (следовательно, немедленно нарушая подход SSOT, определенный выше). Например, система планирования ресурсов предприятия (ERP) (такая как SAP или Oracle e-Business Suite ) может хранить запись о клиенте; система управления взаимоотношениями с клиентами (CRM) также нуждается в копии записи о клиенте (или ее части), а система диспетчеризации склада также может нуждаться в копии некоторых или всех данных о клиенте (например, адрес доставки). В случаях, когда поставщики не поддерживают такие изменения, не всегда возможно заменить эти записи указателями на SSOT.
Для организаций (с более чем одной информационной системой), желающих внедрить Единый источник истины (без изменения всех систем, кроме одной главной, для хранения указателей на другие системы для всех сущностей), некоторые поддерживающие архитектуры включают:
Система MDM может выступать в качестве источника истины для любого объекта, который не обязательно имеет альтернативный «источник истины» в другой системе. Обычно MDM выступает в качестве концентратора для нескольких систем, многие из которых могут разрешать (быть источником истины) обновления различных аспектов информации о данном объекте. Например, система CRM может быть «источником истины» для большинства аспектов клиента и обновляется оператором колл-центра. Однако клиент может (например) также обновить свой адрес через веб-сайт обслуживания клиентов с другой внутренней базой данных из системы CRM. Приложение MDM получает обновления из нескольких источников, действует как брокер для определения того, какие обновления следует считать авторитетными (золотая запись), а затем синдицирует эти обновленные данные для всех систем-подписчиков. Приложение MDM обычно требует ESB для синдицирования своих данных для нескольких систем-подписчиков. [2]
В архитектурах, ориентированных на события, все чаще можно встретить реализацию шаблона Event Sourcing, который сохраняет состояние системы как упорядоченную последовательность изменений состояния. [3] Для этого вам необходимо Event Store , особый тип базы данных, предназначенный для хранения всех событий, которые изменяют состояние системы. Хранилище событий в архитектуре Event Sourcing + Command Query Responsibility Separation + Domain Driven Design + Messaging фактически является «единым источником истины» с дополнительным преимуществом, заключающимся в том, что оно также может выступать в качестве Enterprise Service Bus, поскольку оно может напрямую прослушивать хранилище событий на предмет изменений статуса по мере прохождения всего. Кроме того, сохраняя все события, оно также играет роль Data Warehouse . Последнее преимущество заключается в том, что с помощью этой системы можно реализовать шаблон Shared Database, еще один не упомянутый метод получения единого источника истины.
Хотя основная цель хранилища данных заключается в поддержке отчетности и анализа данных, которые были объединены из нескольких источников, тот факт, что такие данные были объединены (в соответствии с бизнес-логикой, встроенной в процессы преобразования и интеграции данных ), означает, что хранилище данных часто используется как фактический SSOT. Однако, как правило, данные, доступные в хранилище данных, не используются для обновления других систем; вместо этого DW становится «единственным источником истины» для отчетности перед несколькими заинтересованными сторонами. В этом контексте хранилище данных правильнее называть «единой версией истины », поскольку другие версии истины существуют в его операционных источниках данных (никакие данные не возникают в DW; это просто механизм отчетности для данных, загруженных из операционных систем). [4]
В разработке программного обеспечения одна и та же схема, бизнес-логика и другие компоненты часто повторяются в нескольких различных контекстах, в то время как каждая версия называет себя «исходным кодом». Чтобы решить эту проблему, концепции SSOT также могут быть применены к принципам разработки программного обеспечения с использованием таких процессов, как рекурсивная транскомпиляция , чтобы итеративно превратить один источник истины во множество различных видов исходного кода, которые будут соответствовать друг другу структурно, поскольку все они получены из одного и того же SSOT. [5]
данных предназначены исключительно для выполнения запросов и анализа и часто содержат большие объемы исторических данных. Данные в хранилище данных обычно извлекаются из широкого спектра источников, таких как файлы журналов приложений и транзакционные приложения.