Base de datos de restricciones

Conozco la intuición detrás de la programación de restricciones, por así decirlo, nunca experimenté realmente la programación usando un solucionador de restricciones. Aunque creo que es una situación diferente poder lograr lo que definiríamos como datos consistentes.

Contexto:

Tenemos un conjunto de reglas para implementar en un servidor ETL. Estas reglas son:

• actuando en una fila.
• actuando entre filas, en una o diferentes tablas.
• actuar de la misma manera entre dos ejecuciones (debe mantener la misma restricción en todos los datos, o solo las últimas n ejecuciones);

El tercer caso es diferente del segundo, ya que se cumple cuando se cumple el segundo caso, pero para un número bien definido de ejecuciones. Puede aplicarse para una sola ejecución (un archivo) o entre (1 a n (anterior) o en Todos los archivos).

Técnicamente, como concebimos el ETL, no tiene memoria entre dos ejecuciones: dos archivos (pero esto se debe repensar)

Para la aplicación del tercer tipo de regla, ETL necesita tener memoria (creo que terminaríamos respaldando datos en ETL); O al volver a verificar infinitamente (un Trabajo) en toda la base de datos después de un intervalo de tiempo, por lo que los datos que terminan en la base de datos no necesariamente cumplen el tercer tipo de regla en el tiempo.

Ejemplo:

Si bien tenemos un flujo continuo de datos, aplicamos restricciones para tener una base de datos restringida completa, al día siguiente recibiremos una copia de seguridad o datos de corrección durante, por ejemplo, un mes, para esta ventana de tiempo, nos gustaría tener restricciones satisfechas solo por esto ejecutar (esta ventana de tiempo), sin preocuparse por toda la base de datos, para futuras ejecuciones todos los datos deben estar restringidos como antes sin preocuparse por datos pasados. Puedes imaginar otras reglas que podrían ajustarse a la lógica temporal .

Por ahora, solo tenemos implementado el primer tipo de reglas. La forma en que pensé es tener una base de datos minimizada (de cualquier tipo: MySQL, PostgreSQL, MongoDB ...) que haga una copia de seguridad de todos los datos (solo columnas restringidas, probablemente con valores hash) con indicadores que se refieren a la consistencia basada en anteriores tipo de reglas

Pregunta: ¿Existen soluciones / alternativas de concepción que facilitarían este proceso?

Para ilustrar en un lenguaje de programación Cook; Un ejemplo de un conjunto de reglas y acciones siguientes:

run1 : WHEN tableA.ID == tableB.ID AND tableA.column1 > tableB.column2
       BACK-UP 
       FLAG tableA.rule1
AFTER run1 : LOG ('WARN')

run2 : WHEN tableA.column1 > 0
       DO NOT BACK-UP 
       FLAG tableA.rule2
AFTER run2 : LOG ('ERROR')

Nota : Si bien la programación de restricciones es en teoría un paradigma para resolver problemas combinatorios y en la práctica puede acelerar el desarrollo y la ejecución de problemas; Creo que esto es diferente a un problema de resolución de restricciones; Como el primer propósito no es optimizar las restricciones antes de la resolución, probablemente ni siquiera limitar los dominios de datos; Su principal preocupación es aplicar reglas sobre la recepción de datos y ejecutar algunas acciones básicas (Rechazar una línea, Aceptar una línea, Registro ...).

Realmente espero que esta no sea una pregunta muy amplia y este sea el lugar correcto.

Encontré una solución sofisticada para lograr más de lo que pensaba; hablando de verificar la consistencia de los datos. Aparentemente, esto es lo que llamaríamos análisis de datos basados ​​en pruebas.

Así que ahora con esta implementación estamos obligados a Python y Pandas, pero afortunadamente, no solo. Incluso podemos verificar la consistencia de los datos en las tablas MySQL, PostgreSQL ...

La ventaja que no pensé es que podemos inferir reglas basadas en datos de muestra. Esto podría ser útil para establecer reglas. Es por eso que hay tdda.constraints.verify_dfy el tdda.constraints.discover_df.

Por lo que he leído, no propone una solución para verificar la consistencia (más débil) en los últimos (n) archivos. Algo en lo que pensé que podríamos llamar consistencia de archivos por lotes, que solo garantiza una satisfacción de la regla para un conjunto de ejecuciones (últimas n ejecuciones) y no todos los datos. Solo actúa en archivos individuales, necesita un cableado de nivel superior para poder acondicionar (n) archivos que llegan sucesivamente.

Para más información: https://tdda.readthedocs.io/en/latest/constraints.html#module-tdda.constraints

assertCSVFilesCorrect Comprueba un conjunto de archivos en un directorio, lo mismo es posible para los marcos de datos de Pandas, etc.

De la documentación oficial:

La biblioteca tdda.constraints se usa para descubrir restricciones de un Marco de datos (Pandas), escribirlas como JSON y verificar que los conjuntos de datos cumplan las restricciones en el archivo de restricciones. También admite tablas en una variedad de bases de datos de relaciones. También hay una utilidad de línea de comandos para descubrir y verificar restricciones, y detectar registros defectuosos.

PD: todavía estoy abierto a otras soluciones, avíseme, ya que imagino que este es un caso de uso para cualquier solución ETL.

También abro una recompensa para enriquecer aún más las respuestas.

También puede buscar en SQL transactions. Una transacción consta de una o más declaraciones, que un solo usuario o una aplicación deben ejecutar. Pueden leer o incluso modificar datos en una base de datos.

START TRANSACTION
Do DB stuff, check if constraints are violated
COMMIT

Puede especificar ciertas restricciones y usarlas ROLLBACKsi se viola una de estas restricciones. El desarrollador puede codificar explícitamente la reversión, pero también puede arrojarse desde el sistema. (p. ej., cuando apareció un error que no es manejado explícitamente por el desarrollador, o al ejecutar un disparador). Es posible que las transacciones no se interpongan entre sí. Deben ejecutarse de manera "aislada". varias transacciones simultáneas deben producir los mismos resultados en los datos que esas mismas transacciones ejecutadas secuencialmente, en algún orden (no especificado). Dado que todos los DBMS modernos garantizan las propiedades de ACID cuando se trata de transacciones, la ejecución de las transacciones es confiable, por lo que el estado de su base de datos no debería tener inconsistencias.

No estoy seguro de si esto es lo que quieres decir, pero tal vez sea útil.