30/03/2022

Alineamiento físico de los entornos: datos de parametrización y catálogo

Conseguir el alineamiento físico de los entornos -producción, preproducción, desarrollo, etc.- de una base de datos es fundamental a la hora de hacer pruebas. Así, los datos serán coherentes entre los entornos y se reducirá la incertidumbre frente a posibles errores en las ejecuciones. 

Adicionalmente, en el caso que nos ocupa, se evitará la necesidad de realizar conversiones de datos entre entornos en los movimientos de segmentación.  

A lo largo de este artículo aprenderás sobre los diferentes tipos del alineamiento físico de los entornos que existen, responderemos a la pregunta de por qué no se deben transferir directamente los datos y cómo solucionar estos retos. 

¿Estás preparado? 

¡Comenzamos! 

¿Qué tipos de alineamiento físico de los entornos existen?

A nivel de metamodelo 

A nivel de metamodelo. 

Por un lado, el alineamiento de las bases de datos se debe producir a nivel de metamodelo. Esto es que la propia estructura esté nivelada entre entornos: las tablas, los campos de estas, los índices y un largo etcétera tengan las mismas características. 

¿Por qué esto es fundamental? Si un campo no existe tu aplicación podrá fallar. Si una columna tiene un tamaño inferior, el dato no entrará en ella. Entre otros posibles ejemplos. 

A nivel de datos

A nivel de datos. 

Pero, ahora exponemos otra casuística, otro tipo de alineamiento: el de los propios datos. Principalmente de tablas de catálogo o parametrización, tablas que no se incluyen en la estructura de las entidades de negocio sobre las que realizamos movimientos de segmentación. Y que, por consiguiente, no se completan de manera habitual salvo que se usen procesos específicos para ello. 

Un caso real: el catálogo de productos. 

Pongamos el siguiente ejemplo: una tabla con el catálogo de productos de la empresa, cada uno de ellos identificado con un código único y muchas otras tablas que referencian a esos productos por dicho código. 

En este escenario, con iguales productos (o una buena parte de ellos) en dos entornos, nos encontramos con que el código de un mismo producto es diferente en ambos, en función del procedimiento de creación de estos. A todo ello añadimos que, por diversos motivos, no podemos simplemente transferir esa tabla de productos del entorno origen de los movimientos al entorno destino. 

En consecuencia, la segmentación entre estos entornos llevará, en el mejor de los casos, a problemas de integridad en los datos. Tanto de integridad referencial como a nivel funcional. 

¿Por qué no transferir directamente los datos para lograr el alineamiento físico en los entornos? 

Muchos podrían plantear esta cuestión. Lo más sencillo parece simplemente borrar la tabla o tablas que contienen el catálogo de productos, los parámetros, etc. e insertar de nuevo todos los registros desde la base de datos de referencia. 

Sin embargo, esta solución tiene importantes inconvenientes:

  • El tamaño de determinadas tablas puede exceder los volúmenes asumibles de la base de datos. 
  • Incluso suponiendo que las tablas se pueden mover por completo, si existen restricciones físicas, el orden en el que se introducen los datos es fundamental. De lo contrario, se requiere además la desactivación de las restricciones. 
  • Los datos presentes en el entorno hasta ese momento se descartan por completo. Quedan inutilizados con el consiguiente perjuicio. ¡Ningún momento es bueno para inutilizar los datos de un entorno! 

¿Cómo se ha llegado a esta situación? 

¿Por qué estos datos -productos, tarifas, etc.- no tienen el mismo identificador en todos los entornos? El motivo puede estar en muchos puntos: 

  • Porque hay secuencias y caminan a distinto ritmo en los entornos. 
  • No todas las entregas se hacen en todos los entornos así que se desalinean de manera natural o el orden de dichas entregas entre entornos varía.  
  • En función del ciclo de release se estará probando en uno u otro entorno. A desarrollo llegará siempre antes que a preproducción. Incluso en la etapa de desarrollo se descartarán configuraciones que nunca verán la luz en entornos productivos. 

Además, desde nuestra experiencia, en la mayoría de ocasiones este proceso no está procedimentado, no es responsabilidad de nadie y, por consiguiente, nadie la asume; a pesar de su importancia. 

La solución de icaria TDM para lograr el alineamiento físico de los entornos 

Con el proceso de alineamiento de datos de icaria TDM podrás olvidarte de este problema. A continuación, veamos con más detalle las distintas soluciones que ofrece el producto. 

Transferencia completa. 

Creación de planes específicos para el movimiento de tablas: permite aplicar condiciones para transferir una parte de los registros, trabajar en modalidad incremental, etc. 

No obstante, si tenemos otras tablas con integridad referencial hacia estas tablas de catálogo, este procedimiento no es la mejor solución. 

Segmentación. 

Generalmente se asocia la segmentación al movimiento de estructuras de clientes, cuentas o pólizas de seguros; pero no es el único uso. 

En catálogos de productos de importante tamaño, se muestra como una alternativa perfecta capaz de abordar los problemas de tamaño en la base de datos y de evitar errores de integridad referencial surgidos por el orden de inserción de los registros. Por el contrario, puede llegar a ser significativamente más lenta de ejecutar y compleja de diseñar, en comparación con la transferencia completa. 

Alineamiento. 

Frente a estas dos soluciones parciales, con importantes inconvenientes, icaria TDM dispone de un módulo específico para la tarea de alineamiento de entornos que se sobrepone tanto a los problemas de velocidad de la segmentación como a los de integridad referencial de la transferencia completa. 

Mantenimiento de la información. 

Pero no solo esto, también aporta un factor diferencial: conseguir mantener los datos del entorno que referencian estas tablas coherentes, válidos y usables tras el proceso. Es decir, que los clientes mantengan la misma tarifa, producto, promoción, etc. tras el alineamiento. 

El proceso de alineamiento físico de los entornos en detalle 

El proceso de alineamiento comienza con la identificación de las tablas de catálogo por parte del arquitecto de datos. Esta información se traslada a icaria y a partir de ese momento la herramienta toma el control del proceso. 

Tras hacer un reconocimiento de las tablas, se evalúan las restricciones físicas, el grado de desalineamiento entre entornos y las tablas que, no estando directamente implicadas en el proceso, será fundamental modificar. 

Durante el proceso las restricciones físicas se anulan, de ser posible, para acelerar el alineamiento. Se priorizan las tablas en función de los ciclos encontrados entre ellas. Y se procesan en paralelo los distintos dominios de datos con el mismo objetivo. 

La clave del proceso está en conseguir analizar la lista de tablas afectadas, las que tienen integridad referencial con respecto a las primeas -claves foráneas- y establecer los mecanismos de actualización de los datos de las mismas para que, habiendo cambiado el secuencial -clave primaria- de la tabla alineada, el dato externo siga apuntando funcionalmente a la misma información. 

Conclusión 

La mayoría de equipos implicados en el desarrollo de software lidian diariamente con problemas de alineamiento. Bien porque los entornos no lo están y han de ejecutar alineamientos manuales y parciales periódicamente. Bien porque estando alineados a nivel funcional no lo están a nivel de secuenciales, lo que provoca dudas en la comparación de datos. O bien porque simplemente no tienen posibilidad de alinear los entornos si no es a mano y esto es una tarea costosa, sujeta a errores y con graves impactos en las entregas de software. 

Las distintas alternativas de icariaTDM permiten atajar estos problemas y enfocar la solución desde el punto de vista más adecuado; incluso permitiendo ejecutar distintas soluciones en función del estado del entorno. 

Si quieres saber más sobre icariaTDM haz clic en este enlace.

Compartir
magnifiercrossmenuchevron-down