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 hacer un seguimiento de 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 deltas .
CDC es un enfoque de integración de datos que se basa en la identificación, captura y entrega de los cambios realizados en las fuentes de datos de la empresa. Por ejemplo, se puede utilizar para la actualización incremental de la carga de datos.
El 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 el 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 una o varias capas del sistema, desde la lógica de la aplicación hasta el almacenamiento físico.
En un contexto simplificado de CDC, un sistema informático tiene datos que se cree que han cambiado desde un punto anterior en el tiempo, 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 destino. Es posible que la fuente y el destino sean el mismo sistema físicamente, pero eso no cambiaría el patrón de diseño lógicamente. Pueden existir múltiples soluciones de CDC en un solo sistema.
Las tablas cuyos cambios se deben capturar pueden tener una columna que represente la hora del último cambio. Los nombres como LAST_UPDATE, LAST_MODIFIED, etc. son comunes. Se considera que ha cambiado 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 los datos.
Las marcas de tiempo en las filas también se utilizan con frecuencia para el bloqueo abierto, 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. Son comunes los nombres como VERSION_NUMBER, etc.
Una técnica consiste en marcar cada fila modificada con un número de versión. Se mantiene una versión actual de la tabla, o posiblemente de un grupo de tablas. Esta se almacena en una estructura 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, normalmente un contador secuencial. Esto permite que un proceso actualice atómicamente una fila e incremente su contador solo si otro proceso no ha incrementado 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 es poco práctico de mantener).
Esta técnica puede complementar o complementar las marcas de tiempo y el control de 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 de 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 analizados anteriormente. Como se ha señalado, no es raro ver varias soluciones CDC en funcionamiento en un único sistema; sin embargo, la combinación de tiempo, versión y estado proporciona un mecanismo especialmente potente y los programadores deberían utilizarlos como un trío siempre que sea posible. Los tres elementos no son redundantes ni superfluos. Su uso conjunto permite una lógica como la siguiente: "Capturar todos los datos de la versión 2.1 que cambiaron entre el 01-06-2005 a las 00:00 y el 01-07-2005 a las 00:00 donde el código de estado indica que está lista para la producción".
Puede incluir un término para comunicar los datos modificados a varios destinos. En este enfoque, los desencadenadores registran los eventos que suceden en la tabla transaccional en otra tabla de cola que luego se puede "reproducir". Por ejemplo, imagine una tabla de Cuentas, cuando se realizan transacciones contra esta tabla, se activarían desencadenadores que luego almacenarían un historial del evento o incluso los deltas en una tabla de cola separada. La tabla de cola podría 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 presenta un desafío, ya 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 modificados incluyen:
Las soluciones de CDC basadas en archivos de registro de transacciones tienen ventajas distintivas que incluyen:
Como ocurre a menudo en ámbitos complejos, la solución final a un problema de CDC puede tener que equilibrar muchas preocupaciones en pugna.
La captura de datos modificados aumenta tanto en complejidad como en valor si el sistema de origen guarda los cambios en los metadatos cuando los datos en sí no se modifican. Por ejemplo, algunos modelos de datos rastrean al usuario que miró por última vez los datos pero no los modificó en la misma estructura que estos. 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 almacenan en una base de datos moderna , la captura de datos modificados es una simple cuestión de permisos. Se utilizan dos técnicas comunes:
Si los datos no están en una base de datos moderna, el CDC se convierte en un desafío de programación.
A veces, la dimensión de cambio lento se utiliza como un 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 ser útil si se necesita el historial en el sistema de destino. CDC sobrescribe en el sistema de destino (similar a SCD1) y es ideal cuando solo los datos modificados necesitan llegar al destino, es decir, un conjunto de datos impulsado por delta .