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!
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.
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.
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.
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:
¿Por qué estos datos -productos, tarifas, etc.- no tienen el mismo identificador en todos los entornos? El motivo puede estar en muchos puntos:
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.
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.
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.
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.
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.
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 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.
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.