Войти
В информационных системах дизайн и теория, единый источник истины (SSOT ) - это практика структурирования информационных моделей и связанной с ними схемы данных, так что каждый элемент данных обрабатывается (или редактируется) только в одном месте. Любые возможные связи с этим элементом данных (возможно, в других областях реляционной схемы или даже в удаленных интегрированных базах данных ) только по ссылке. Поскольку все другие местоположения данных просто относятся к основному местоположению «источника истины», обновления элемента данных в основном местоположении распространяются на всю систему без возможности того, что где-то будет забыто повторяющееся значение.
Развертывание архитектуры SSOT становится все более важным в корпоративных условиях, где неправильно связаны повторяющиеся или ненормализованные элементы данных (прямое следствие преднамеренной или непреднамеренной денормализации любой явной модели данных) риск получения устаревшей и, следовательно, неверной информации. Типичным примером может служить электронная медицинская карта, где необходимо точно подтверждать личность пациента по единому справочному репозиторию, который служит SSOT. Дублированные представления данных на предприятии будут реализованы с помощью указателей, а не дублированных таблиц, строк или ячеек базы данных. Это гарантирует, что обновления данных для элементов в авторитетном расположении будут всесторонне распределены по всем объединенным базам данных в более крупной общей корпоративной архитектуре..
Системы SSOT предоставляют данные, которые являются подлинными, актуальными и пригодными для использования.
«Идеальная» реализация SSOT, описанная выше, редко возможна на большинстве предприятий. Это связано с тем, что многие организации имеют несколько информационных систем, каждой из которых требуется доступ к данным, относящимся к одним и тем же объектам (например, клиенту). Часто эти системы приобретаются в готовом виде у поставщиков и не могут быть изменены нетривиальными способами. Следовательно, каждая из этих различных систем должна хранить свою собственную версию общих данных или объектов, и поэтому каждая система должна сохранять свою собственную копию записи (следовательно, немедленно нарушая подход SSOT, определенный выше). Например, система ERP (планирование ресурсов предприятия) (такая как SAP или Oracle e-Business Suite) может хранить запись о клиенте; системе CRM (управление взаимоотношениями с клиентами) также нужна копия записи о клиенте (или ее части), а системе диспетчеризации склада может также потребоваться копия некоторых или всех данных о клиенте (например, адреса доставки). В случаях, когда поставщики не поддерживают такие модификации, не всегда возможно заменить эти записи указателями на SSOT.
Для организаций (с более чем одной информационной системой), желающих реализовать Единый источник истины (без изменения всех, кроме одной главной системы, для хранения указателей на другие системы для всех сущностей), обычно используются три вспомогательные технологии:
Сервисная шина предприятия (ESB) позволяет любому количеству систем в организации получать обновления данных, которые были изменены в другой системе. Чтобы реализовать единый источник истины, необходимо определить единую систему источников правильных данных для любой сущности. Изменения этого объекта (создание, обновление и удаление) затем публикуются через ESB; другие системы, которым необходимо сохранить копию этих данных, подписываются на это обновление и соответственно обновляют свои собственные записи. Для любого объекта должен быть идентифицирован главный источник (иногда называемый золотой записью). Любая данная система может публиковать (быть источником правды) информацию о конкретном объекте (например, клиенте), а также подписываться на обновления от другой системы для получения информации о каком-либо другом объекте (например, продукте).
Альтернативным подходом является обновление данных точка-точка, но оно становится экспоненциально дороже в обслуживании по мере увеличения количества систем, и этот подход все больше теряет популярность в качестве ИТ-архитектуры.
Система MDM может выступать в качестве источника истины для любой данной сущности, которая не обязательно может иметь альтернативный «источник истины» в другой системе. Обычно MDM действует как концентратор для нескольких систем, многие из которых могут разрешать (быть источником правды) обновления различных аспектов информации о данном объекте. Например, CRM-система может быть «источником истины» для большинства аспектов клиента и обновляется оператором центра обработки вызовов. Однако клиент может (например) также обновить свой адрес через веб-сайт обслуживания клиентов, используя внутреннюю базу данных, отличную от системы CRM. Приложение MDM получает обновления из нескольких источников, действует как брокер, чтобы определить, какие обновления следует рассматривать как авторитетные (Золотая запись), а затем объединяет эти обновленные данные во все системы подписки. Приложению MDM обычно требуется ESB для синдицирования своих данных в несколько систем-подписчиков. Интеграция данных клиента (CDI), как распространенное приложение управления основными данными, иногда сокращается до CDI-MDM.
Хотя основной целью хранилища данных является поддержка отчетности и анализа данных, которые были объединены из нескольких источников, тот факт, что такие данные были объединены (согласно встроенной бизнес-логике в процессах преобразования и интеграции данных ) означает, что хранилище данных часто используется в качестве единого входа de facto. Однако обычно данные, доступные из хранилища данных, не используются для обновления других систем; скорее DW становится «единственным источником истины» для отчетности перед множеством заинтересованных сторон. В этом контексте хранилище данных более правильно называть «единственной версией истины », поскольку в его операционных источниках данных существуют другие версии истины (данные не исходят из DW; это просто механизм отчетности для данных, загружаемых из операционных систем).
При разработке программного обеспечения одна и та же схема, бизнес-логика и другие компоненты часто повторяются в нескольких разных контекстах, при этом каждый версия называет себя «Исходный код». Чтобы решить эту проблему, концепции SSOT также могут быть применены к принципам разработки программного обеспечения с использованием таких процессов, как рекурсивная транскомпиляция, чтобы итеративно превращать один источник истины во множество различных видов исходного кода, которые будут структурно соответствовать друг другу. потому что все они получены из одного и того же SSOT.
В случаях, когда централизованное хранение данных и управление ими в эталонных местах нецелесообразно, например, в экосистемах данных программного обеспечения B2B, где существует несколько источников правды, компании используют система DSD. Эта система играет роль авиадиспетчера, чтобы обеспечить видимость централизованного управления данными и контроля за счет отправки обновлений и обеспечения точности данных в тех местах, где они хранятся.
