En las bases de datos , la captura de datos modificados ( CDC ) es un conjunto de patrones de diseño de software que se utilizan para determinar y rastrear los datos que han cambiado (los "deltas") de modo que se puedan tomar medidas utilizando los datos modificados. El resultado es un conjunto de datos impulsado por delta .
CDC es un enfoque para la integración de datos que se basa en la identificación, captura y entrega de los cambios realizados en las fuentes de datos empresariales. Por ejemplo, se puede utilizar para la actualización incremental de la carga de datos .
CDC ocurre a menudo en entornos de almacenamiento de datos, ya que capturar y preservar el estado de los datos a lo largo del tiempo es una de las funciones principales de un almacén de datos, pero CDC se puede utilizar en cualquier base de datos o sistema de repositorio de datos.
Los desarrolladores de sistemas pueden configurar mecanismos CDC de varias maneras y en cualquier capa del sistema o en una combinación de ellas, desde la lógica de la aplicación hasta el almacenamiento físico.
En un contexto CDC simplificado, un sistema informático tiene datos que se cree que han cambiado desde un momento anterior, y un segundo sistema informático debe tomar medidas en función de esos datos modificados. El primero es la fuente, el segundo es el objetivo. Es posible que el origen y el destino sean físicamente el mismo sistema, pero eso no cambiaría lógicamente el patrón de diseño. Pueden existir múltiples soluciones CDC en un solo sistema.
Las tablas cuyos cambios deben capturarse pueden tener una columna que represente la hora del último cambio. Nombres como LAST_UPDATE, LAST_MODIFIED, etc. son comunes. Se considera que cualquier fila de cualquier tabla que tenga una marca de tiempo en esa columna que sea más reciente que la última vez que se capturaron datos ha cambiado.
Las marcas de tiempo en las filas también se utilizan con frecuencia para el bloqueo optimista , por lo que esta columna suele estar disponible.
Los diseñadores de bases de datos asignan a las tablas cuyos cambios deben capturarse una columna que contiene un número de versión. Nombres como VERSION_NUMBER, etc. son comunes.
Una técnica consiste en marcar cada fila modificada con un número de versión. Se mantiene una versión actual para la tabla, o posiblemente para un grupo de tablas. Esto se almacena en una construcción de soporte, como una tabla de referencia. Cuando se produce una captura de cambios, se considera que todos los datos con el último número de versión han cambiado. Una vez que se completa la captura de cambios, la tabla de referencia se actualiza con un nuevo número de versión.
(No confunda esta técnica con el control de versiones a nivel de fila utilizado para el bloqueo optimista . Para el bloqueo optimista, cada fila tiene un número de versión independiente, generalmente un contador secuencial. Esto permite que un proceso actualice atómicamente una fila e incremente su contador solo si otro proceso tiene no incrementó el contador. Pero CDC no puede usar versiones a nivel de fila para encontrar todos los cambios a menos que conozca la versión "inicial" original de cada fila. Esto no es práctico de mantener).
Esta técnica puede complementar o complementar las marcas de tiempo y las versiones. Puede configurar una alternativa si, por ejemplo, se configura una columna de estado en una fila de la tabla que indica que la fila ha cambiado (por ejemplo, una columna booleana que, cuando se establece en verdadero, indica que la fila ha cambiado). De lo contrario, puede actuar como complemento a los métodos anteriores, indicando que una fila, a pesar de tener un nuevo número de versión o una fecha posterior, aún no debe actualizarse en el destino (por ejemplo, los datos pueden requerir validación humana).
Este enfoque combina los tres métodos discutidos anteriormente. Como se señaló, no es raro ver múltiples soluciones CDC funcionando en un solo sistema; sin embargo, la combinación de tiempo, versión y estado proporciona un mecanismo particularmente poderoso y los programadores deben utilizarlos como un trío siempre que sea posible. Los tres elementos no son redundantes ni superfluos. Usarlos juntos permite una lógica como: "Capture todos los datos de la versión 2.1 que cambiaron entre 2005-06-01 00:00 y 2005-07-01 00:00 donde el código de estado indica que está listo para producción".
Puede incluir un patrón de publicación/suscripción para comunicar los datos modificados a múltiples objetivos. En este enfoque, los eventos de registro que ocurren en la tabla transaccional se activan en otra tabla de cola que luego se puede "reproducir". Por ejemplo, imagine una tabla de Cuentas, cuando las transacciones se toman en esta tabla, se activarían activadores que luego almacenarían un historial del evento o incluso los deltas en una tabla de cola separada. La tabla de cola puede tener un esquema con los siguientes campos: Id, TableName, RowId, Timestamp, Operation. Los datos insertados para nuestro ejemplo de Cuenta podrían ser: 1, Cuentas, 76, 2008-11-02 00:15, Actualización. Los diseños más complicados podrían registrar los datos reales que cambiaron. Esta tabla de cola podría luego "reproducirse" para replicar los datos del sistema de origen a un destino.
La captura de datos ofrece un desafío en el sentido de que la estructura, el contenido y el uso de un registro de transacciones son específicos de un sistema de gestión de bases de datos. A diferencia del acceso a los datos, no existe ningún estándar para los registros de transacciones. La mayoría de los sistemas de gestión de bases de datos no documentan el formato interno de sus registros de transacciones, aunque algunos proporcionan interfaces programáticas para sus registros de transacciones (por ejemplo: Oracle, DB2, SQL/MP, SQL/MX y SQL Server 2008).
Otros desafíos en el uso de registros de transacciones para la captura de datos de cambios incluyen:
Las soluciones CDC basadas en archivos de registro de transacciones tienen distintas ventajas que incluyen:
Como suele ocurrir en ámbitos complejos, la solución final a un problema de CDC puede tener que equilibrar muchas preocupaciones en competencia.
La captura de datos modificados aumenta en complejidad y reduce su valor si el sistema de origen guarda los cambios de metadatos cuando los datos en sí no se modifican. Por ejemplo, algunos modelos de datos rastrean al usuario que miró por última vez pero no cambió los datos en la misma estructura que los datos. Esto genera ruido en la captura de datos modificados.
En realidad, el seguimiento de los cambios depende de la fuente de datos. Si los datos se conservan en una base de datos moderna , la captura de datos modificados es una simple cuestión de permisos. Dos técnicas son de uso común:
Si los datos no están en una base de datos moderna, CDC se convierte en un desafío de programación.
A veces, la dimensión que cambia lentamente se utiliza como método alternativo. [1] CDC y SCD son similares en que ambos métodos pueden detectar cambios en un conjunto de datos. Las formas más comunes de SCD son el tipo 1 (sobrescribir), el tipo 2 (mantener el historial) o el 3 (solo el valor anterior y actual). SCD 2 puede resultar útil si se necesita historial en el sistema de destino. CDC sobrescribe en el sistema de destino (similar a SCD1) y es ideal cuando solo los datos modificados deben llegar al destino, [2] es decir, un conjunto de datos controlado por delta . [ cita necesaria ]