En ciencias de la información y tecnología de la información , 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 manera que cada elemento de datos sea dominado (o editado). ) en un solo lugar, proporcionando normalización de datos a una forma canónica (por ejemplo, en normalización de bases de datos o transclusión de contenido ).
Existen varios escenarios con respecto a copias y actualizaciones:
Las ventajas de las arquitecturas SSOT incluyen una prevención más sencilla de inconsistencias erróneas (como el olvido de un valor duplicado/copia en algún lugar) y un control de versiones enormemente simplificado . Sin un SSOT, lidiar con las inconsistencias implica algoritmos de consenso complejos y propensos a errores, o usar una arquitectura más simple que es propensa a perder datos ante la inconsistencia (esto último puede parecer inaceptable, pero a veces es una muy buena opción; así es como la mayoría de las cadenas de bloques funcionan: una transacción es realmente definitiva sólo si se incluyó en el siguiente bloque que se extrae).
Idealmente, los sistemas SSOT proporcionan datos que son auténticos (y autentificables ), relevantes y referenciables . [1]
La implementación de una arquitectura SSOT se está volviendo cada vez más importante en entornos empresariales donde elementos de datos duplicados o desnormalizados vinculados incorrectamente (una consecuencia directa de la desnormalización intencional o no intencional de cualquier modelo de datos explícito) representan un riesgo de recuperación de información obsoleta y, por lo tanto, incorrecta. . Los ejemplos comunes (es decir, clases de ejemplo de implementación) son los siguientes:
Un prerrequisito reconocido (de la noción de que cualquier fuente única de verdad puede existir) es que depende de la condición ontológica de que no exista más que una única verdad (sobre cualquier hecho o idea en particular), una afirmación que es ontológica tanto en el sentido Sentido TI y el sentido general de esa palabra. En muchos casos, esto no presenta ningún problema (por ejemplo, dentro de espacios de nombres particulares , o incluso entre ellos, siempre y cuando las colisiones de nombres o los conflictos de nombres más amplios se manejen adecuadamente). Los contextos más amplios (y por lo tanto los más espinosos, en lo que respecta a las discrepancias ontológicas) requieren una adecuada comparación y reconciliación de regímenes epistémicos (o al menos negociación o intercambios transaccionales). Un ejemplo arquetípico de esta clase 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 púrpura mientras que la religión Y afirma que Dios es verde", en lugar de en el nivel de "Dios es púrpura" 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 tienen 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 compran a proveedores como productos comerciales listos para usar y no se pueden modificar de manera trivial. Por lo tanto, cada uno de estos diversos sistemas necesita almacenar su propia versión de datos o entidades comunes y, por lo tanto, cada sistema debe conservar su propia copia de un registro (violando así 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 del mismo) y el sistema de despacho del almacén también puede necesitar una copia de algunos o todos los datos del cliente (por ejemplo, dirección de envío). En los casos en que los proveedores no admitan 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 maestros excepto uno para almacenar punteros a otros sistemas para todas las entidades), algunas arquitecturas de soporte son:
Un sistema MDM puede actuar como fuente de verdad para cualquier entidad determinada que no necesariamente tenga una "fuente de verdad" alternativa en otro sistema. Normalmente, el MDM actúa como un centro para múltiples sistemas, muchos de los cuales podrían permitir (ser la fuente de verdad) actualizaciones de diferentes aspectos de la información sobre una entidad determinada. Por ejemplo, el sistema CRM puede ser la "fuente de verdad" para la mayoría de los aspectos del cliente y lo actualiza un operador del centro de llamadas. Sin embargo, un cliente también puede (por ejemplo) actualizar su dirección a través de un sitio web de servicio al cliente, con una base de datos de fondo diferente 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 disco de oro) y luego distribuye estos datos actualizados a todos los sistemas suscriptores. La aplicación MDM normalmente requiere que un ESB distribuya sus datos a múltiples sistemas de suscripción. [2]
En 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. [3] Para hacer esto, necesita un Almacén de eventos , un tipo particular de base de datos diseñada para almacenar todos los eventos que cambian el estado del sistema. El almacén de eventos en una arquitectura de Event Sourcing + Command Query Responsibility Separation + Domain Driven Design + Messaging es de hecho una "única fuente de verdad", con la ventaja adicional de que también puede actuar como un Enterprise Service Bus, ya que puede escuchar directamente la tienda de eventos para cambios de estado a medida que todo pasa. Además, al guardar todos los eventos, también cumple la función de Data Warehouse . Una última ventaja es que a través de este sistema se puede implementar el patrón Base de Datos Compartida, otra técnica no mencionada para obtener una única fuente de verdad.
Si bien el objetivo principal de un almacén de datos es respaldar la generación de informes y el análisis de datos que se han combinado de múltiples fuentes, el hecho de que dichos datos se hayan combinado (de acuerdo con la lógica empresarial incorporada en los procesos de transformación e integración de datos ) significa que los datos El almacén se utiliza a menudo como SSOT de facto . Sin embargo, generalmente 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 informar a múltiples partes interesadas. En este contexto, es más correcto hacer referencia al almacén de datos como una " versión única 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 informes para los datos cargados). de los sistemas operativos). [4]
En el diseño de software, el mismo esquema, lógica empresarial y otros componentes suelen repetirse en múltiples contextos diferentes, mientras que cada versión se refiere a sí misma como "Código fuente". Para abordar este problema, los conceptos de SSOT también se pueden aplicar a los principios de desarrollo de software utilizando procesos como la transcompilación recursiva para convertir de forma iterativa una única fuente de verdad en muchos tipos diferentes de código fuente, que coincidirán estructuralmente entre sí porque todos se derivan de el mismo SSOT. [5]
Los almacenes de datos están destinados únicamente a realizar consultas y análisis y, a menudo, contienen grandes cantidades de datos históricos. Los datos dentro de un almacén de datos generalmente se derivan de una amplia gama de fuentes, como archivos de registro de aplicaciones y aplicaciones de transacciones.