Fuente única de verdad

En ciencia de la información y tecnología de la información , la arquitectura de fuente única de verdad ( SSOT ) o arquitectura de punto único de verdad ( SPOT ) para sistemas de información es la práctica de estructurar modelos de información y esquemas de datos asociados de tal manera que cada elemento de datos se gestione (o edite) en un solo lugar, proporcionando normalización de datos a una forma canónica (por ejemplo, en la normalización de bases de datos o la transclusión de contenido ). ^{[ 1 ]}

Existen varios escenarios con respecto a las copias y actualizaciones:

• Los datos maestros nunca se copian, sino que solo se hacen referencias a ellos; esto significa que todas las lecturas y actualizaciones van directamente al SSOT.
• Los datos maestros se copian, pero las copias solo se leen y solo se actualizan los datos maestros; si las solicitudes para leer datos solo se realizan en las copias, esto es un caso de CQRS .
• Los datos maestros se copian y las copias se actualizan; esto requiere un mecanismo de conciliación cuando hay actualizaciones simultáneas.
  • Las actualizaciones en las copias pueden descartarse cuando se realiza una actualización simultánea en el nodo maestro, por lo que no se consideran totalmente confirmadas hasta que se propagan al nodo maestro. (Muchas cadenas de bloques funcionan de esta manera).
  • Las actualizaciones simultáneas se fusionan. (Si falla una fusión automática, se puede recurrir a otra estrategia, que podría ser la anterior o alguna otra, como la intervención manual, que es lo que hacen la mayoría de los sistemas de control de versiones).

Las ventajas de las arquitecturas SSOT incluyen una prevención más sencilla de inconsistencias erróneas (como el olvido de un valor duplicado o una copia) y un control de versiones mucho más simplificado . Sin una arquitectura SSOT, lidiar con las inconsistencias implica algoritmos de consenso complejos y propensos a errores, o bien utilizar una arquitectura más simple que puede perder datos ante una inconsistencia (esta última opción puede parecer inaceptable, pero a veces es una muy buena elección; así es como funcionan la mayoría de las cadenas de bloques: una transacción solo es definitiva si se incluyó en el siguiente bloque que se minó).

Idealmente, los sistemas SSOT proporcionan datos que son auténticos (y autenticables ), relevantes y referenciables . ^{[ 2 ]}

La implementación de una arquitectura SSOT está adquiriendo cada vez más importancia en entornos empresariales donde los elementos de datos duplicados o desnormalizados, vinculados incorrectamente (consecuencia directa de la desnormalización intencional o no intencional de cualquier modelo de datos explícito), representan un riesgo para la recuperación de información obsoleta y, por lo tanto, incorrecta. Algunos ejemplos comunes (es decir, clases de implementación de ejemplo) son los siguientes:

• En los registros electrónicos de salud (EHR), es imperativo validar con precisión la identidad del paciente contra un único repositorio de referencia, que actúa como SSOT. Las representaciones duplicadas de datos dentro de la empresa se implementarían mediante el uso de punteros en lugar de tablas, filas o celdas de base de datos duplicadas. Esto garantiza que las actualizaciones de datos de los elementos en la ubicación autorizada se distribuyan de manera integral a todos los miembros de la base de datos federada en la arquitectura empresarial general . Los EHR son un excelente ejemplo de cómo la arquitectura SSOT es a la vez crucial y difícil de lograr: es difícil porque el intercambio de información de salud entre organizaciones es inherentemente un obstáculo para la competencia en ciberseguridad , y no obstante es necesario para prevenir errores médicos , evitar los costos innecesarios de la ineficiencia (como el trabajo duplicado o la repetición de tareas) y hacer factibles los conceptos de atención primaria y atención integral (para lograr transiciones de atención competentes ). ^{[ 3 ]}
• La publicación de fuente única, como principio o ideal general en la gestión de contenidos, se basa en la existencia de SSOT (Single Source Trusts), mediante transclusión o (al menos de otra forma) sustitución. La sustitución se produce a través de bibliotecas de objetos que se propagan como copias estáticas, las cuales se actualizan posteriormente cuando es necesario (es decir, cuando la actualización de copiar y pegar o importar se activa por un evento de actualización mayor). Los sistemas de gestión de contenidos basados ​​en componentes constituyen una clase de sistemas de gestión de contenidos que buscan ofrecer esta capacidad.

Un requisito previo reconocido (de la noción de que puede existir una única fuente de verdad) es que dependa de la condición ontológica de que no exista más de una verdad (sobre cualquier hecho o idea en particular), una afirmación ontológica tanto en el sentido de la informática como en el sentido general de la palabra. En muchos casos, esto no presenta problemas (por ejemplo, dentro de espacios de nombres específicos , o incluso entre ellos, siempre que se gestionen adecuadamente las colisiones de nombres o los conflictos de nombres más amplios ). Los contextos más amplios (y por lo tanto más espinosos, en lo que respecta a las discrepancias ontológicas) requieren una comparación y reconciliación adecuadas de regímenes epistémicos (o al menos negociación o intercambios transaccionales ). Un ejemplo arquetípico de este tipo de reconciliación es que dos bibliotecas de seminarios teológicos , de dos religiones diferentes (X e Y), podrían intercambiar información con una arquitectura SSOT, pero la unificación de la verdad residiría en el nivel de la afirmación de que "la religión X afirma que Dios es morado, mientras que la religión Y afirma que Dios es verde", en lugar de en el nivel de "Dios es morado" o "Dios es verde".

Una implementación ideal de SSOT rara vez es posible en la mayoría de las empresas. Esto se debe a que muchas organizaciones cuentan con múltiples sistemas de información, cada uno de los cuales necesita acceso a datos relacionados con las mismas entidades (por ejemplo, clientes). A menudo, estos sistemas se adquieren como productos comerciales estándar de proveedores y no se pueden modificar fácilmente. Por lo tanto, cada uno de estos sistemas necesita almacenar su propia versión de datos o entidades comunes, y en consecuencia, cada sistema debe conservar su propia copia de un registro (lo que viola inmediatamente el enfoque SSOT definido anteriormente). Por ejemplo, un sistema de planificación de recursos empresariales (ERP) (como SAP u Oracle e-Business Suite ) puede almacenar un registro de cliente; el sistema de gestión de relaciones con el cliente (CRM) también necesita una copia del registro del cliente (o parte de él) y el sistema de despacho de almacén también podría necesitar una copia de algunos o todos los datos del cliente (por ejemplo, la dirección de envío). En los casos en que los proveedores no admiten dichas modificaciones, no siempre es posible reemplazar estos registros con punteros al SSOT.

Para las organizaciones (con más de un sistema de información) que deseen implementar una Fuente Única de Verdad (sin modificar todos los sistemas excepto uno maestro para almacenar punteros a otros sistemas para todas las entidades), algunas arquitecturas de apoyo son:

• Gestión de datos maestros (MDM)
• Tienda de eventos y servicios de abastecimiento para eventos (ES)

Un sistema de gestión de datos maestros (MDM) suele servir como fuente de verdad para los metadatos de una organización, ayudando a garantizar la precisión y la coherencia en todas las fuentes de datos de dicha organización. ^{[ 4 ]} Normalmente, el MDM actúa como un centro para múltiples sistemas, muchos de los cuales pueden permitir (ser la fuente de verdad para) actualizaciones de diferentes aspectos de la información de una entidad determinada. Por ejemplo, el sistema CRM puede ser la "fuente de verdad" para la mayoría de los aspectos del cliente y es actualizado por un operador de un centro de llamadas. Sin embargo, un cliente también puede (por ejemplo) actualizar su dirección a través de un sitio web de atención al cliente, con una base de datos de back-end diferente a la del sistema CRM. La aplicación MDM recibe actualizaciones de múltiples fuentes, actúa como intermediario para determinar qué actualizaciones deben considerarse autorizadas (el registro maestro) y luego distribuye estos datos actualizados a todos los sistemas suscriptores. La aplicación MDM normalmente requiere un ESB para distribuir sus datos a múltiples sistemas suscriptores. ^{[ 5 ]}

En las arquitecturas orientadas a eventos, se ha vuelto cada vez más común encontrar una implementación del patrón Event Sourcing que almacena el estado del sistema como una secuencia ordenada de cambios de estado. ^{[ 6 ]} Para ello, se necesita un Event Store , un tipo particular de base de datos diseñada para contener todos los eventos que cambian el estado del sistema. El Event Store en una arquitectura Event Sourcing + Command Query Responsibility Separation + Domain Driven Design + Messaging es, de hecho, una "fuente única de verdad", con la ventaja adicional de que también puede actuar como un Enterprise Service Bus, ya que puede escuchar directamente al Event Store los cambios de estado a medida que todo pasa. Además, al guardar todos los eventos, también desempeña el rol de Data Warehouse . Una última ventaja es que a través de este sistema se puede implementar el patrón Shared Database , otra técnica no mencionada para obtener una fuente única de verdad.

Si bien el propósito principal de un almacén de datos es respaldar la generación de informes y el análisis de datos combinados de múltiples fuentes, el hecho de que dichos datos se hayan combinado (de acuerdo con la lógica empresarial integrada en los procesos de transformación e integración de datos ) implica que el almacén de datos se utiliza a menudo como una SSOT de facto . Sin embargo, por lo general, los datos disponibles en el almacén de datos no se utilizan para actualizar otros sistemas; más bien, el DW se convierte en la "única fuente de verdad" para la generación de informes a múltiples partes interesadas. En este contexto, el almacén de datos se denomina más correctamente "una única versión de la verdad ", ya que existen otras versiones de la verdad en sus fuentes de datos operativas (ningún dato se origina en el DW; es simplemente un mecanismo de generación de informes para los datos cargados desde los sistemas operativos). ^{[ 7 ]}

• Blockchain , almacén de datos distribuido para transacciones digitales
• Informes circulares , problema en el que una fuente obtiene información de algún lugar y luego utiliza esa fuente como referencia.
• Normalización de bases de datos , técnica para diseñar tablas en bases de datos relacionales de manera que se minimice la duplicación de información.
• No te repitas
• Versión única de la verdad , ideal cuando todos los datos de una organización se almacenan de forma consistente y sin redundancias.
• Versión única de los hechos , concepto en el repositorio de datos
• Sistema de registro , la fuente de datos autorizada para un elemento de datos determinado.