Relaciones entre los datos: ¿cómo las identifico?

netzima

Conocer las relaciones entre los datos es fundamental para mejorar la calidad de tu software y reducir los costes de la gestión de los datos de prueba. 

Para obtener los datos adecuados debemos realizar un proceso de segmentación gracias al cual extraeremos subconjuntos coherentes de datos de un entorno de origen y realizamos su entrega en un entorno de destino.  

¿Cómo puede ayudarnos el descubrimiento de las relaciones entre los datos en la estrategia de TDM?  

En este artículo encontrarás la respuesta a esta pregunta y, además, abordaremos qué procedimiento usamos habitualmente para el diseño de la segmentación en base a estas relaciones y las necesidades de la prueba y descubriremos cuáles son las capacidades que debe tener una herramienta de segmentación. 

¡Comenzamos! 

¿Por qué es tan necesario identificar las relaciones entre los datos? 

La segmentación de datos se basa en el conocimiento de las relaciones entre dominios de datos para descubrir de entre todos los registros de una base de datos cuáles pertenecen a la estructura que deseamos mover. 

De este modo, a través de las relaciones identificamos el camino que permite transitar de un dato o un registro a otro. 

Por tanto, es indispensable realizar una investigación para descubrirlo, sin esta información el proceso de segmentación no será completo ni acertado. 

El descubrimiento de las relaciones entre los datos. 

Cuando planteamos esta técnica en el diseño de una estrategia TDM, la primera pregunta que nos encontramos es: ¿cómo averiguamos las relaciones entre los datos? 

Es una buena pregunta.  

Si se trata de extraer un subconjunto coherente de datos, el primer reto es saber cómo recorrer la base de datos de forma ordenada.  

¿De dónde sacamos esta información?  

¿Quién puede decírnoslo? 

A continuación, expondremos tres fuentes a las que podemos recurrir para obtener esta información: 

  1. Aplicaciones cuya base de datos implementa las relaciones de forma explícita, a través de las claves ajenas.  
  2. Documentación que describe el modelo de datos. A veces, está actualizada.  
  3. El equipo de desarrollo y mantenimiento de la aplicación sabe mucho, también de las relaciones del modelo de datos. Siempre o casi siempre.  

Sin embargo, ¿qué pasaría si en las aplicaciones no están las relaciones explícitas, la documentación no está actualizada o el equipo de desarrollo es nuevo? 

Generalmente, llegados a este punto, alguien comenta alarmado que conocer todas las relaciones del modelo de datos es una tarea descomunal y de difícil acceso. 

Incluso, cuando están definidas en la base de datos no están todas y que únicamente el propio software, el código, «conoce» todas las relaciones.  

Entonces, ¿hay que revisarse todo el código de la aplicación? 

Afortunadamente, no.  

Hemos movido cientos de miles, millones de clientes, cuentas, pólizas, servicios, pedidos y reclamaciones en procesos de segmentación y aún no hemos tenido que revisar el código fuente de ninguna de las decenas de aplicaciones que hemos manejado.  

El diseño de la segmentación. 

La primera clave es darse cuenta de que nuestro problema no es documentar todas las relaciones del modelo de datos de la aplicación, únicamente las que necesitamos.

Esto es un reto, pero de una magnitud más pequeña.  

A partir de aquí hay que aprovechar lo que tenemos y realizar el siguiente proceso: 

  1. Recopilemos la documentación del modelo disponible y averigüemos si hay integridad referencial activa en la base de datos. Si es el caso, tenemos mucho adelantado, aunque no hay que confiarse.
  2. Identifiquemos las entidades fuertes que los probadores demandan. Generalmente nos dicen: «necesito clientes con tales o cuales características«, o facturas, o pedidos, o cualquier otro concepto funcional relevante. Es raro que pidan «registros de auditoría de la tabla HJK«. Esa entidad nos da el punto de entrada al modelo. 
  3. Si tenemos documentación y/o relaciones en la base de datos, identificamos la entidad en el modelo y las relaciones 
  4. Si no es el caso, preguntemos. Esas tablas las conocen todos los programadores o probadores. Y las relacionadas principales, también.  
  5. En cualquier caso, ya tenemos por dónde empezar a trabajar en el diseño de la segmentación. A partir de aquí identifiquemos los dominios de datos y. de manera incremental. podremos avanzar en el descubrimiento del modelo de datos. 

¿Cuáles son las capacidades deseables en una herramienta de segmentación? 

Evidentemente, la segmentación no se hace a mano.  

Si llegados a este punto eres de los que realizas esta tarea de forma manual tenemos que cambiarlo y te interesa conocer las características que debe tener esa herramienta digital que te vaya a ayudar. 

Si, por el contrario, ya empleas un software para esta tarea igualmente esto te hará verificar si el utilizas cumple con estos requisitos.  

Las 3 capacidades que podemos pedirle a nuestra herramienta de segmentación son: 

1. Debe permitir diseñar y modificar el proceso de segmentación, las entidades y relaciones, de forma sencilla y ágil.  

El conocimiento a priori que obtengamos de las relaciones del modelo será, casi con toda seguridad, incompleto. Una forma de completarlo es entrar en un proceso iterativo de diseño-ejecución-comprobación-mejora, y eso requiere que sea sencillo mantener. 

2. Debe permitir diseñar relaciones en un metamodelo. 

Sin que necesariamente existan en la base de datos o en el código de las aplicaciones que la usan.  

Los motivos son varios. Por ejemplo, para segmentar se pueden usar caminos alternativos, no necesariamente funcionales, con el objetivo de mejorar la eficiencia del proceso de lectura y entrega de datos. 

 Además, añadir físicamente las relaciones en la base de datos conlleva, por parte de estas, unas comprobaciones constantes que para los equipos de diseño y servicio no siempre son fáciles de asumir. 

3. Debe ofrecer herramientas de descubrimiento automatizado de relaciones.  

Es un extraordinario complemento a las fuentes de información anteriores y, con frecuencia, la principal. En el caso de icaria esto es gestionado mediante la prospección de datos. 

¿Cómo icaria TDM aborda el descubrimiento, configuración y tratamiento de las relaciones entre datos? 

icaria TDM cumple las características mencionadas anteriormente, pero, ¿cómo lo hace?  

La herramienta de icaria permite configurar y modificar el árbol de extracción de manera sencilla a través de una interfaz gráfica diseñada para tal efecto. 

De este modo, permite configurarlas y documentarlas en su propio metamodelo de tal modo que este sirva de guía para las distintas fases de: 

  • Diseño. 
  • Implementación. 
  • Mantenimiento de la segmentación. 

Gracias a ello conseguiremos reducir el tiempo de aplicación de horas a minutos.  

Debido a que una relación configurada en icaria puede transitar de manera ágil, sin requerir reinicios, generar código o propuestas similares de otros aplicativos, hacia el entorno de ejecución. 

Además, icaria cuenta con una herramienta de autodescubrimiento de relaciones que permite obtener una estimación de las relaciones existentes, tanto físicas como lógicas. La prospección. 

Conclusión. 

La pregunta clave para entender las relaciones entre los datos es cómo averiguar las relaciones entre ellos.  

En este sentido hay 3 fuentes principales para entender la relación entre los datos: la propia aplicación te aporta esta información, documentación donde estas relaciones quedan registradas o el equipo de desarrollo. 

Gracias a la segmentación de los datos no es necesario revisar todo el código de la aplicación para poder testarla. Además, existen herramientas de segmentación que te permiten identificar de forma automática estas relaciones, lo que supone un gran ahorro a nivel de tiempos y costes. 

 

¿Quieres reducir los tiempos de espera y los costes de tus pruebas? Contacta ahora con icaria Technology y comienza a mejorar la calidad del software de gestión de datos de prueba.

También te puede interesar:

¿Por qué la protección de datos en los entornos de prueba no debería ser una preocupación?

¿Cómo se pueden mejorar las pruebas en el desarrollo de software?

Para probar software, ¿muchos datos o datos adecuados?

Compartir:

Share on facebook
Share on twitter
Share on pinterest
Share on linkedin