Captura de datos de cambio

En bases de datos, cambiar la captura de datos (CDC) es un conjunto de software patrones de diseño utilizado para determinar (y seguimiento) los datos que ha cambiado de modo que pueden adoptarse medidas utilizando los datos cambiados. Además, captura de datos de cambio (CDC) es un enfoque de integración de datos que se basa en la identificación, captura y entrega de los cambios realizados en orígenes de datos empresariales.

Soluciones CDC ocurren más a menudo en data warehouse ambientes ya que captura y preservar el estado de los datos a través del tiempo es una de las funciones básicas de un almacén de datos, pero CDC puede ser utilizado en cualquier sistema de base de datos o datos del repositorio.

Metodología

Desarrolladores del sistema pueden establecer mecanismos de CDC en muchas formas y en cualquiera o una combinación de capas de sistema de la lógica de la aplicación hasta el almacenamiento físico.

En un contexto de CDC simplificado, un sistema informático tiene datos cree que han cambiado desde un punto anterior en el tiempo, y un segundo sistema informático debe tomar medidas basado en los datos cambiados. El primero es la fuente, este último es el objetivo. Es posible que el origen y destino son el mismo sistema físicamente, pero eso no cambia los patrones de diseño lógicamente.

No infrecuente, múltiples soluciones de CDC pueden existir en un solo sistema.

Marcas de tiempo en las filas

Tablas cuyos cambios deben ser capturados pueden tener una columna que representa el tiempo de última cambio. Nombres como LAST_UPDATE, etc. son comunes. Cualquier fila de cualquier tabla que tiene una marca de tiempo en esa columna que es más reciente que fue capturado el último dato de tiempo se considera que han cambiado.

Números de versión en filas

Los diseñadores de la base de datos dan tablas cuyos cambios deben ser capturado una columna que contiene un número de versión. Nombres como VERSION_NUMBER, etc. son comunes. Cuando cambian los datos en una fila, su número de versión se actualiza a la versión actual. Una construcción de apoyo como una tabla de referencia con la versión actual en se necesita. Cuando se produce un cambio de captura, todos los datos con el número de versión más reciente se considera que han cambiado. Cuando haya finalizado la captura de cambio, la tabla de referencia se actualiza con un nuevo número de versión.

Existen tres o cuatro técnicas principales para hacer CDC con números de versión, el párrafo anterior es sólo uno.

Indicadores de estado en las filas

Esta técnica puede suplementar o complementar las marcas de tiempo y control de versiones. Puede configurar un if alternativo, por ejemplo, una columna de estado se configura en una fila de tabla indicando que ha cambiado la fila (por ejemplo una columna booleana que, cuando se establece en true, indica que la fila ha cambiado). De lo contrario, puede actuar como un complemento a los métodos anteriores, indicando que una fila, a pesar de tener un nuevo número de versión o una fecha anterior, todavía no debería actualizarse sobre el objetivo (por ejemplo, los datos pueden requerir validación humana).

/ Versión/estado del tiempo en las filas

Este enfoque combina los tres métodos previamente discutidos. Como se señaló, no es raro ver múltiples soluciones de CDC en el trabajo en un solo sistema, sin embargo, la combinación de tiempo, la versión y estado proporciona un mecanismo particularmente de gran alcance y los programadores deben utilizarlos como un trío donde sea posible. Los tres elementos no son redundantes o superflua. Permite utilizarlos juntos tan lógica como, "capturar todos los datos para la versión 2.1 que cambió entre el 01/06/2005 12:00 a.m. y 01/07/2005 12:00 a.m. en el código de estado indica que está listo para la producción."

Disparadores en tablas

Puede incluir un publicar o suscribir patrón a comunicar los datos cambiados a varios destinos. En este enfoque, factores desencadenantes eventos que suceden a la tabla transaccional en otra tabla de cola que puede posteriormente ser "reproducir". Por ejemplo, imaginemos una tabla de cuentas, cuando las transacciones son tomadas contra esta tabla, desencadenadores que despediría almacenaría entonces una historia del evento o incluso los deltas en una tabla separada de la cola. La tabla cola podría tener esquema con los siguientes campos: Id, TableName, RowId, TimeStamp, operación. Los datos insertados por nuestra cuenta la muestra podría ser: 1, cuentas, 76, 02/11/2008 12:15 am, actualizar. Diseños más complicados pueden registrar los datos reales que cambiaron. Esta tabla de cola podría entonces "reproducir" para replicar los datos desde el sistema de origen a un destino.

[Discusión más necesitada]

Un ejemplo de esta técnica es conocido como el patrón del gatillo de registro.

Programación de eventos

Un cambio en una aplicación en los puntos apropiados de codificación es otro método que puede dar discernimiento inteligente que modifican datos. Aunque este método implica programación vs más fácilmente implementado disparadores "tontas", puede proporcionar más precisa y deseable CDC, tales como sólo después de confirmar, o sólo después de ciertas columnas cambian a ciertos valores - está buscando sólo lo que el sistema de destino.

Escáneres de registro en bases de datos

Mayoría de los sistemas de gestión de bases de datos administrar un registro de transacciones registra los cambios realizados a los contenidos de la base de datos y a metadatos. Exploración e interpretando el contenido de la base de datos de registro de transacciones puede capturar los cambios realizados en la base de datos de una manera no intrusiva.

Utilizando registros de transacciones de cambio de datos captura ofrece un reto en que la estructura, contenido y uso de un registro de transacciones es específico de un sistema de gestión de base de datos. A diferencia de acceso a datos, ningún estándar existe para registros de transacciones. Mayoría de los sistemas de gestión de bases de datos no documentar el formato interno de sus registros de transacciones, aunque algunos proporcionan interfaces de programación para sus registros de transacciones (por ejemplo: Oracle, DB2, SQL/MP, MX/SQL y SQL Server 2008).

Otros desafíos en el uso de registros de transacciones para captura de datos de cambio incluyen:

• Coordinar la lectura de los registros de transacciones y el archiving de archivos de registro (software de gestión de base de datos normalmente archivos archivos de registro off-line de forma regular).
• Traducción entre formatos de almacenamiento físico que se registran en los registros de transacciones y los formatos lógicos típicamente esperados por los usuarios de la base de datos (por ejemplo, algunas transacciones registra guardar sólo diferencias de búfer mínimos que no son directamente útiles para cambian los consumidores).
• Lidiando con los cambios en el formato de los registros de transacciones entre las versiones del sistema de gestión de base de datos.
• Eliminación de cambios no confirmados que escribió de la base de datos para el registro de transacciones y más tarde deshace.
• Lidiando con los cambios en los metadatos de tablas en la base de datos.

CDC soluciones basadas en archivos de registro de transacciones tienen ventajas distintivas que incluyen:

• un impacto mínimo sobre la base de datos (más aún si uno utiliza trasvase de registros para procesar los logs en un host dedicado).
• No hay necesidad de cambios programáticos a las aplicaciones que utilizan la base de datos.
• baja latencia en la adquisición de cambios.
• integridad transaccional:: análisis de registro pueden producir una corriente de cambio que reproduce las transacciones originales en el orden en que se cometieron. Una corriente del cambio incluye los cambios realizados en todas las tablas que participan en la transacción capturada.
• sin necesidad de cambiar el esquema de base de datos

Factores de confusión

Como a menudo ocurre en dominios complejos, puede tener la solución definitiva a un problema de CDC equilibrar muchas preocupaciones de competencia.

Sistemas inadecuados de la fuente

Cambio datos capturan ambos aumenta en complejidad y reduce en valor si salva el sistema de origen metadatos cambios cuando los datos no se modifica. Por ejemplo, algunos Modelos de datos el usuario que último miró pero no cambiaron los datos en la misma estructura que los datos de la pista. Esto se traduce en un montón de Ruido (signal_processing) en la captura de datos de cambio.

La captura de seguimiento

Seguimiento en realidad los cambios depende del origen de datos. Si los datos se persiste en un moderno base de datos Entonces el cambio de captura de datos es una simple cuestión de permisos. Dos técnicas son de uso común:

1. Seguimiento de cambios usando Triggers de base de datos
2. Leyendo el registro de transacciones como, o poco después, está escrito.

Si los datos no están en una moderna base de datos, cambio de captura de datos se convierte en un desafío de programación.

Empuje versus tire

• Empuje:: el proceso fuente crea una instantánea de cambios dentro de su propio proceso y entrega las filas más abajo. El proceso en sentido descendiente utiliza la instantánea, crea su propio subconjunto y entrega al proceso siguiente.

• Tire:: el objetivo es inmediatamente aguas abajo de la fuente, prepara una petición para los datos de la fuente. La Diana ofrece la instantánea al siguiente objetivo, como en el modelo de empuje.

Véase también

• Cambiando lentamente la dimensión

Enlaces externos

• LinkedIn Databus
• Replicación de datos como un servicio de mejores prácticas
• Captura de datos de cambio de Attunity (CDC)
• IBM Infosphere CDC
• Tutorial sobre la creación de CDC en Oracle 9i
• Tutorial sobre la creación de captura de datos en SQL Azure cambio
• Detalles de la instalación de CDC incluidos en Microsoft Sql Server 2008 Feb ' 08 CTP
• SymmetricDS - heterogénea, cruz plataforma CDC
• Gamma-Soft CDC tecnología

Otras Páginas

• Howard R. Hughes, Sr.
• Abogado
• George Hamilton (actor) (seccion de vida Personal)
• Stagenhoe
• Audio Interchange File Format
• Stephen Kelly (futbolista)
• Tubos de timpanostomia
• Ottawa, Illinois
• Accidente de camino de Cardross