El modelado de bóvedas de datos o data vault es un método de modelado de bases de datos diseñado para proporcionar un almacenamiento histórico a largo plazo de los datos que llegan desde múltiples sistemas operativos. También es un método para analizar datos históricos que aborda cuestiones como la auditoría, el seguimiento de los datos, la velocidad de carga y la resistencia al cambio, además de enfatizar la necesidad de rastrear de dónde provienen todos los datos de la base de datos . Esto significa que cada fila de una bóveda de datos debe ir acompañada de los atributos de origen del registro y fecha de carga, lo que permite a un auditor rastrear los valores hasta la fuente. El concepto fue publicado en 2000 por Dan Linstedt .
El modelado de bóvedas de datos no hace distinción entre datos buenos y malos (por "malos" se entiende los que no se ajustan a las reglas de negocio). [1] Esto se resume en la afirmación de que una bóveda de datos almacena " una única versión de los hechos " (también expresada por Dan Linstedt como "todos los datos, todo el tiempo"), a diferencia de la práctica en otros métodos de almacenamiento de datos de almacenar "una única versión de la verdad " [2], donde los datos que no se ajustan a las definiciones se eliminan o se "limpian". Un almacén de datos empresarial de bóveda de datos proporciona tanto una única versión de los hechos como una única fuente de verdad. [3]
El método de modelado está diseñado para ser resistente a los cambios en el entorno empresarial de donde provienen los datos almacenados, al separar explícitamente la información estructural de los atributos descriptivos . [4] Data Vault está diseñado para permitir la carga paralela tanto como sea posible, [5] de modo que las implementaciones muy grandes puedan escalar sin la necesidad de un rediseño importante.
A diferencia del esquema en estrella ( modelado dimensional ) y el modelo relacional clásico (3NF), el modelado de bóvedas de datos y de anclaje son adecuados para capturar los cambios que ocurren cuando se modifica o se agrega un sistema de origen, pero se consideran técnicas avanzadas que requieren arquitectos de datos experimentados . [6] Tanto las bóvedas de datos como los modelos de anclaje son modelos basados en entidades , [7] pero los modelos de anclaje tienen un enfoque más normalizado. [ cita requerida ]
En sus inicios, Dan Linstedt se refirió a la técnica de modelado que se convertiría en bóveda de datos como arquitectura de almacén fundacional común [8] o arquitectura de modelado fundacional común [9] . En el modelado de almacenes de datos hay dos opciones conocidas en competencia para modelar la capa donde se almacenan los datos. O bien se modela según Ralph Kimball , con dimensiones conformadas y un bus de datos empresarial , o se modela según Bill Inmon con la base de datos normalizada [10] . Ambas técnicas tienen problemas al tratar con cambios en los sistemas que alimentan el almacén de datos [ cita requerida ] . Para las dimensiones conformadas también hay que limpiar los datos (para conformarlos) y esto es indeseable en varios casos ya que esto inevitablemente perderá información [ cita requerida ] . La bóveda de datos está diseñada para evitar o minimizar el impacto de esos problemas, moviéndolos a áreas del almacén de datos que están fuera del área de almacenamiento histórico (la limpieza se realiza en los almacenes de datos) y separando los elementos estructurales (claves comerciales y las asociaciones entre las claves comerciales) de los atributos descriptivos.
Dan Linstedt, el creador del método, describe la base de datos resultante de la siguiente manera:
"El modelo Data Vault es un conjunto de tablas normalizadas, orientadas a los detalles, con seguimiento histórico y vinculadas de forma única que respaldan una o más áreas funcionales de la empresa. Es un enfoque híbrido que abarca lo mejor de la tercera forma normal (3NF) y el esquema en estrella . El diseño es flexible, escalable, consistente y adaptable a las necesidades de la empresa" [11]
La filosofía de Data Vault es que todos los datos son relevantes, incluso si no se ajustan a las definiciones y reglas comerciales establecidas. Si los datos no se ajustan a estas definiciones y reglas, entonces es un problema para la empresa, no para el almacén de datos. La determinación de que los datos son "incorrectos" es una interpretación de los datos que surge de un punto de vista particular que puede no ser válido para todos o en todo momento. Por lo tanto, el almacén de datos debe capturar todos los datos y solo cuando se informan o extraen datos del almacén de datos se interpretan los datos.
Otra cuestión a la que responde el almacén de datos es que cada vez es más necesario contar con una completa capacidad de auditoría y trazabilidad de todos los datos del almacén de datos. Debido a los requisitos de la ley Sarbanes-Oxley en los EE. UU. y a medidas similares en Europa, este es un tema relevante para muchas implementaciones de inteligencia empresarial, por lo que el objetivo de cualquier implementación de un almacén de datos es la completa capacidad de auditoría y trazabilidad de toda la información.
Data Vault 2.0 es la nueva especificación. Es un estándar abierto . [12] La nueva especificación consta de tres pilares: la metodología ( SEI / CMMI , Six Sigma , SDLC , etc.), la arquitectura (entre otras una capa de entrada (data stage, llamada persistent staging area en Data Vault 2.0) y una capa de presentación (data mart), y el manejo de servicios de calidad de datos y servicios de datos maestros), y el modelo. Dentro de la metodología, se define la implementación de las mejores prácticas. Data Vault 2.0 tiene un enfoque en la inclusión de nuevos componentes como big data , NoSQL - y también se centra en el rendimiento del modelo existente. La antigua especificación (documentada aquí en su mayor parte) está muy centrada en el modelado de bóvedas de datos. Está documentada en el libro: Building a Scalable Data Warehouse with Data Vault 2.0 [13] .
Es necesario evolucionar la especificación para incluir los nuevos componentes, junto con las mejores prácticas para mantener los sistemas EDW y BI actualizados con las necesidades y deseos de las empresas actuales.
El modelado de bóveda de datos fue concebido originalmente por Dan Linstedt en la década de 1990 y se publicó en 2000 como un método de modelado de dominio público. En una serie de cinco artículos en The Data Administration Newsletter, se amplían y explican las reglas básicas del método Data Vault. Estos contienen una descripción general, [14] una descripción general de los componentes, [15] un análisis sobre las fechas de finalización y las uniones, [16] tablas de vínculos, [17] y un artículo sobre prácticas de carga. [18]
Un nombre alternativo (y poco utilizado) para el método es "Arquitectura de modelado de integración fundamental común". [19]
Data Vault 2.0 [20] [21] llegó a escena en 2013 y trae a la mesa Big Data, NoSQL, integración perfecta no estructurada y semiestructurada, junto con metodología, arquitectura y mejores prácticas de implementación.
Según Dan Linstedt, el modelo de datos está inspirado (o modelado) en una visión simplista de las neuronas, las dendritas y las sinapsis, donde las neuronas están asociadas con los centros y los satélites de los centros, los enlaces son dendritas (vectores de información) y otros enlaces son sinapsis (vectores en la dirección opuesta). Al utilizar un conjunto de algoritmos de minería de datos, los enlaces pueden calificarse con índices de confianza y fuerza . Pueden crearse y eliminarse sobre la marcha de acuerdo con el aprendizaje sobre relaciones que actualmente no existen. El modelo puede transformarse, adaptarse y ajustarse automáticamente a medida que se utiliza y se alimenta con nuevas estructuras. [22]
Otro punto de vista es que un modelo de bóveda de datos proporciona una ontología de la empresa en el sentido de que describe los términos en el dominio de la empresa (centros) y las relaciones entre ellos (enlaces), agregando atributos descriptivos (satélites) cuando es necesario.
Otra forma de pensar en un modelo de almacén de datos es como un modelo gráfico . El modelo de almacén de datos en realidad proporciona un modelo "basado en gráficos" con centros y relaciones en un mundo de bases de datos relacionales. De esta manera, el desarrollador puede usar SQL para obtener relaciones basadas en gráficos con respuestas en menos de un segundo.
Data Vault intenta resolver el problema de lidiar con los cambios en el entorno separando las claves comerciales (que no mutan tan a menudo, porque identifican de manera única a una entidad comercial) y las asociaciones entre esas claves comerciales, de los atributos descriptivos de esas claves.
Las claves de negocio y sus asociaciones son atributos estructurales que forman el esqueleto del modelo de datos. El método de bóveda de datos tiene como uno de sus principales axiomas que las claves de negocio reales solo cambian cuando cambia el negocio y, por lo tanto, son los elementos más estables de los que derivar la estructura de una base de datos histórica. Si utiliza estas claves como columna vertebral de un almacén de datos, puede organizar el resto de los datos en torno a ellas. Esto significa que elegir las claves correctas para los centros es de suma importancia para la estabilidad de su modelo. [23] Las claves se almacenan en tablas con algunas restricciones en la estructura. Estas tablas de claves se denominan centros.
Los concentradores contienen una lista de claves empresariales únicas con baja propensión a cambiar. Los concentradores también contienen una clave sustituta para cada elemento del concentrador y metadatos que describen el origen de la clave empresarial . Los atributos descriptivos de la información del concentrador (como la descripción de la clave, posiblemente en varios idiomas) se almacenan en estructuras denominadas tablas satélite, que se analizarán a continuación.
El Hub contiene al menos los siguientes campos: [24]
No se permite que un concentrador contenga varias claves comerciales, excepto cuando dos sistemas entregan la misma clave comercial pero con colisiones que tienen significados diferentes.
Los centros normalmente deberían tener al menos un satélite. [24]
Este es un ejemplo de una tabla central que contiene automóviles, llamada "Automóvil" (H_CAR). La clave de conducción es el número de identificación del vehículo .
Las asociaciones o transacciones entre claves empresariales (por ejemplo, relacionar los centros de clientes y productos entre sí a través de la transacción de compra) se modelan mediante tablas de vínculos. Estas tablas son básicamente tablas de unión de varios a varios , con algunos metadatos.
Los enlaces pueden vincularse a otros enlaces para gestionar cambios en la granularidad (por ejemplo, agregar una nueva clave a una tabla de base de datos cambiaría el grano de la tabla de base de datos). Por ejemplo, si tiene una asociación entre cliente y dirección, podría agregar una referencia a un enlace entre los centros de producto y empresa de transporte. Este podría ser un enlace llamado "Entrega". Hacer referencia a un enlace en otro enlace se considera una mala práctica, porque introduce dependencias entre enlaces que dificultan la carga en paralelo. Dado que un enlace a otro enlace es lo mismo que un nuevo enlace con los centros del otro enlace, en estos casos, crear los enlaces sin hacer referencia a otros enlaces es la solución preferida (consulte la sección sobre prácticas de carga para obtener más información).
Los enlaces a veces vinculan centros con información que no es suficiente por sí misma para construir un centro. Esto ocurre cuando una de las claves comerciales asociadas por el enlace no es una clave comercial real. Como ejemplo, tomemos un formulario de pedido con "número de pedido" como clave y líneas de pedido que están codificadas con un número semialeatorio para que sean únicas. Digamos, "número único". La última clave no es una clave comercial real, por lo que no es un centro. Sin embargo, necesitamos usarla para garantizar la granularidad correcta para el enlace. En este caso, no usamos un centro con clave sustituta, sino que agregamos la clave comercial "número único" al enlace. Esto se hace solo cuando no hay posibilidad de usar la clave comercial para otro enlace o como clave para atributos en un satélite. Esta construcción ha sido llamada "enlace de pata de palo" por Dan Linstedt en su (ahora desaparecido) foro.
Los enlaces contienen las claves sustitutas de los centros que están vinculados, su propia clave sustituta para el enlace y metadatos que describen el origen de la asociación. Los atributos descriptivos de la información sobre la asociación (como la hora, el precio o la cantidad) se almacenan en estructuras llamadas tablas satélite que se describen a continuación.
Este es un ejemplo de una tabla de vínculos entre dos centros para automóviles (H_CAR) y personas (H_PERSON). El vínculo se llama "Conductor" (L_DRIVER).
Los ejes y enlaces forman la estructura del modelo, pero no tienen atributos temporales ni descriptivos. Estos se almacenan en tablas separadas llamadas satélites . Estos consisten en metadatos que los vinculan a su eje o enlace principal, metadatos que describen el origen de la asociación y los atributos, así como una línea de tiempo con fechas de inicio y finalización para el atributo. Mientras que los ejes y enlaces proporcionan la estructura del modelo, los satélites proporcionan la "carne" del modelo, el contexto para los procesos comerciales que se capturan en los ejes y enlaces. Estos atributos se almacenan tanto con respecto a los detalles del asunto como a la línea de tiempo y pueden variar desde bastante complejos (todos los campos que describen el perfil completo de un cliente) hasta bastante simples (un satélite en un enlace con solo un indicador válido y una línea de tiempo).
Por lo general, los atributos se agrupan en satélites según el sistema de origen. Sin embargo, los atributos descriptivos, como el tamaño, el costo, la velocidad, la cantidad o el color, pueden cambiar a diferentes velocidades, por lo que también puedes dividir estos atributos en diferentes satélites en función de su velocidad de cambio.
Todas las tablas contienen metadatos que describen mínimamente el sistema de origen y la fecha en la que esta entrada se volvió válida, lo que proporciona una vista histórica completa de los datos a medida que ingresan al almacén de datos.
Un satélite de efectividad es un satélite construido sobre un enlace, "y registra el período de tiempo en el que el enlace correspondiente registra el inicio y el fin de la efectividad". [26]
Este es un ejemplo de un satélite en el enlace de conductores entre los centros de vehículos y personas, llamado "Seguro del conductor" (S_DRIVER_INSURANCE). Este satélite contiene atributos que son específicos del seguro de la relación entre el vehículo y la persona que lo conduce, por ejemplo, un indicador de si se trata del conductor principal, el nombre de la compañía de seguros de este vehículo y persona (también podría ser un centro independiente) y un resumen del número de accidentes que involucran a esta combinación de vehículo y conductor. También se incluye una referencia a una tabla de consulta o referencia llamada R_RISK_CATEGORY que contiene los códigos para la categoría de riesgo en la que se considera que se encuentra esta relación.
(*) al menos un atributo es obligatorio. (**) el número de secuencia se vuelve obligatorio si es necesario para garantizar la unicidad de varios satélites válidos en el mismo concentrador o enlace.
Las tablas de referencia son una parte normal de un modelo de almacén de datos en buen estado. Su función es evitar el almacenamiento redundante de datos de referencia simples a los que se hace referencia con mucha frecuencia. De manera más formal, Dan Linstedt define los datos de referencia de la siguiente manera:
Toda la información que se considere necesaria para resolver descripciones de códigos o para traducir claves de manera coherente. Muchos de estos campos son de naturaleza "descriptiva" y describen un estado específico de otra información más importante. Como tal, los datos de referencia se encuentran en tablas separadas de las tablas sin procesar de Data Vault . [27]
Las tablas de referencia se referencian desde satélites, pero nunca se vinculan con claves externas físicas. No existe una estructura prescrita para las tablas de referencia: use lo que funcione mejor en su caso específico, desde tablas de búsqueda simples hasta pequeñas bóvedas de datos o incluso estrellas. Pueden ser históricas o no tener historial, pero se recomienda que se ciña a las claves naturales y no cree claves sustitutas en ese caso. [28] Normalmente, las bóvedas de datos tienen muchas tablas de referencia, al igual que cualquier otro almacén de datos.
Este es un ejemplo de una tabla de referencia con categorías de riesgo para conductores de vehículos. Se puede consultar desde cualquier satélite en el almacén de datos. Por ahora, la consultamos desde el satélite S_DRIVER_INSURANCE. La tabla de referencia es R_RISK_CATEGORY.
(*) al menos un atributo es obligatorio.
El proceso ETL para actualizar un modelo de almacén de datos es bastante sencillo (consulte la serie 5 de almacenes de datos: prácticas de carga). Primero, debe cargar todos los concentradores y crear identificadores sustitutos para todas las nuevas claves comerciales. Una vez hecho esto, puede resolver todas las claves comerciales en identificadores sustitutos si consulta el concentrador. El segundo paso es resolver los vínculos entre concentradores y crear identificadores sustitutos para todas las nuevas asociaciones. Al mismo tiempo, también puede crear todos los satélites que estén conectados a los concentradores, ya que puede resolver la clave en un identificador sustituto. Una vez que haya creado todos los vínculos nuevos con sus claves sustitutas, puede agregar los satélites a todos los vínculos.
Como los hubs no están conectados entre sí, excepto a través de enlaces, puedes cargar todos los hubs en paralelo. Como los enlaces no están conectados directamente entre sí, también puedes cargar todos los enlaces en paralelo. Como los satélites solo se pueden conectar a hubs y enlaces, también puedes cargarlos en paralelo.
El ETL es bastante sencillo y se presta a una automatización o creación de plantillas sencillas. Los problemas ocurren solo con enlaces relacionados con otros enlaces, porque la resolución de las claves comerciales en el enlace solo conduce a otro enlace que también debe resolverse. Debido a la equivalencia de esta situación con un enlace a múltiples concentradores, esta dificultad se puede evitar remodelando dichos casos y, de hecho, esta es la práctica recomendada. [18]
Los datos nunca se eliminan del almacén de datos, a menos que haya un error técnico al cargarlos.
La capa modelada de la bóveda de datos se utiliza normalmente para almacenar datos. No está optimizada para el rendimiento de las consultas, ni es fácil de consultar con las herramientas de consulta conocidas, como Cognos , Oracle Business Intelligence Suite Enterprise Edition , SAP Business Objects , Pentaho , etc. [ cita requerida ] Dado que estas herramientas informáticas para el usuario final esperan o prefieren que sus datos estén contenidos en un modelo dimensional , normalmente es necesaria una conversión.
Para este fin, los centros y los satélites relacionados con ellos se pueden considerar como dimensiones, y los enlaces y los satélites relacionados con ellos se pueden ver como tablas de hechos en un modelo dimensional. Esto le permite crear rápidamente un prototipo de un modelo dimensional a partir de un modelo de almacén de datos mediante vistas.
Tenga en cuenta que si bien es relativamente sencillo mover datos de un modelo de bóveda de datos a un modelo dimensional (limpio), lo inverso no es tan fácil, dada la naturaleza desnormalizada de las tablas de hechos del modelo dimensional, fundamentalmente diferente a la tercera forma normal de la bóveda de datos. [29]
La metodología de almacenamiento de datos se basa en las mejores prácticas de SEI / CMMI Nivel 5. Incluye múltiples componentes de CMMI Nivel 5 y los combina con las mejores prácticas de Six Sigma , gestión de calidad total (TQM) y SDLC. En particular, se centra en la metodología ágil de Scott Ambler para el desarrollo y la implementación. Los proyectos de almacenamiento de datos tienen un ciclo de lanzamiento corto y controlado por el alcance y deben constar de un lanzamiento de producción cada 2 o 3 semanas.
Los equipos que utilizan la metodología de bóveda de datos deberían adaptarse fácilmente a los proyectos repetibles, consistentes y mensurables que se esperan en el nivel 5 de CMMI. Los datos que fluyen a través del sistema de bóveda de datos EDW comenzarán a seguir el ciclo de vida TQM que ha estado ausente durante mucho tiempo en los proyectos de BI (inteligencia empresarial).
Algunos ejemplos de herramientas son: [ aclaración necesaria ]