EVOLUCION DE DATOS

Introduccin.

En 1983 Balzer soaba con un sistema capaz de programar aplicaciones automticamente, sin fallos y sin tener que realizar un mantenimiento sobre el cdigo fuente. Hoy en da ese sueo se ha cumplido.

Durante los ltimos aos grandes lneas de investigacin han dedicado la mayor parte de sus esfuerzos en convertir en un hecho el paradigma de prototipacin automtica o de Balzer. Finalmente, se puede obtener un prototipo automticamente a partir de una especificacin. Pero... Qu pasa con los datos de esas aplicaciones?

Durante la vida de un sistema de informacin los requerimientos cambian, y las aplicaciones estn condenadas a evolucionar para dar soporte a los nuevos requisitos; al mismo tiempo, y paralelamente, las bases de datos van poblndose con datos. Estos datos constituyen la parte ms valiosa del sistema de informacin.

Los sistemas de evolucin actuales soportan la evolucin de esquemas conceptuales, generando las aplicaciones y las bases de datos; pero no migran la poblacin de las bases de datos de esos esquemas. Ver figura 1.

Figura1: Capas de evolucin en el software.

Actualmente, el problema de la migracin es tratado de forma manual, mediante ristras de sentencias SQL, o a un nivel ms elevado, mediante la construccin de aplicaciones que son capaces de migrar datos entre dos instancias concretas de esquema conceptual (cuando el sistema vuelve a evolucionar, estas aplicaciones son inservibles). Otra forma ms reciente de abordar el problema es la migracin asistida mediante los transformadores comerciales, los cuales son capaces de migrar datos entre tablas de distintos formatos; ejemplos de ellos son DTS de SQL Server, FileAid o ReTarGet. El principal problema de estas herramientas, es que no tienen en cuenta las restricciones de integridad de las bases de datos, ni tampoco son capaces de modificar los datos durante la transformacin.

El problema todava puede complicarse ms cuando hablamos de los Legacy Systems, los cuales suelen ser sistemas que llevan funcionando aos, y que por lo tanto tienen sus bases de datos llenas de informacin. Cuando se habla de evolucionar un sistema legado, se debe entender que la evolucin debe ser tanto de aplicaciones como de datos.

Podemos concluir que no tiene sentido abordar el problema de la prototipacin automtica sin dar soporte a la evolucin paralela de los datos. Se hace imprescindible para abordar el problema el establecimiento de un soporte metodolgico para la migracin de datos.

En el presente trabajo se va a presentar una forma de abordar el problema de la migracin de datos en un contexto de prototipacin automtica.

Presentacin del problema.

Vamos dar por hecho gran parte del trabajo y a comenzar directamente por la migracin de datos. Es decir, vamos a partir de un sistema capaz de prototipar automticamente una aplicacin y una base de datos a partir de un esquema conceptual. Partiremos de OO-Method tal y como se encuentra actualmente en su versin utilizada en la industria.

OO-Method es capaz de abordar la evolucin de aplicaciones, pero no lo es tanto en la evolucin de datos. A partir de un esquema conceptual modelado con OO-Method podemos obtener una aplicacin y su base de datos automticamente; si los requerimientos cambian, no hay ms que remodelar el esquema conceptual y regenerar automticamente la nueva aplicacin con su base de datos. El problema se produce cuando la aplicacin anterior haba sido utilizada y su base de datos estaba poblada con informacin. Es evidente que esta informacin es valiosa y no puede perderse, por tanto debe migrarse a la nueva base de datos; pero las dos bases de datos tienen formatos distintos y todava peor restricciones semnticas distintas. Por tanto, no basta una simple copia de una base de datos a la otra, sino que se le debe dar un tratamiento a la migracin.

Un problema tpico se produce cuando se define una nueva restriccin de integridad sobre los datos. A modo de ejemplo:

Base de datos inicial Base de datos final

NombreEdadNombreEdad

Juan22Juan22

Luis34Luis34

Marcos17

Nueva restriccin de integridad: Los clientes deben tener ms de 20 aos.

En este caso la poblacin migrada de la base de datos inicial a la final debe ser un subconjunto de los datos; solo debern migrarse aquellos datos que cumplan las restricciones de integridad. Y que hacemos con los dems datos? Deber avisarse al usuario de su inconsistencia, y l decidir si se deben despreciar, o deben ser tratados para poder cumplir las restricciones de integridad.

Este problema no es ni mucho menos un problema infrecuente, sino que se da prcticamente en casi todas las evoluciones de esquemas. Sin embargo, OO-Method no proporciona ningn soporte metodolgico que resuelva la migracin de datos.

Tratamiento del problema.

Para abordar el problema de la evolucin de datos en el contexto OO-Method, debemos tener presentes las siguientes consideraciones:

1) Se dispondr de los esquemas conceptuales inicial y final, y de las bases de datos generadas automticamente a partir de esos esquemas. Por lo tanto la migracin consistir en leer datos de la base de datos inicial e insertarlos en la base de datos final.

2) Puede ocurrir, y de hecho ser frecuente, que exista una parte de la poblacin de la base de datos origen que no pueda ser migrada porque no cumple las restricciones de integridad.

3) Sera interesante que al mismo tiempo que se migran datos, se pudiera fijar una funcin de transformacin sobre los mismos.

4) Del mismo modo que cambian los requisitos sobre las aplicaciones, cambian los requisitos sobre los datos. Los datos son de y para el usuario, y el debe decidir que poblacin debe ser migrada.

La migracin de datos se debera realizar cada vez que se realiza una evolucin de esquema conceptual (ver figura 2). Pero puede darse el caso de que se quieran realizar sucesivas migraciones entre dos cambios de esquemas con el fin de migrar la poblacin paulatinamente.

Figura2: Proceso de evolucin de aplicaciones y datos.

Diseo de la solucin.

Vamos a intentar solucionar el problema de una manera elegante, y que por otro lado es la manera ms sensata posible; esto es, modelando la solucin con el propio OO-Method, y generando automticamente la aplicacin que resuelve el problema.

Para poder modelar la solucin, deberamos establecer primero una metodologa para abordar la migracin de datos. En primer lugar, toda migracin debera pasar por los siguientes pasos:

- Comparar dos Esquemas Conceptuales.- Obtener las Diferencias.

- Proponer un Plan de Migracin.

- Facilidades de Edicin al analista.

- Traducir el Plan de Migracin.

- Ejecucin.

- Localizacin de Inconsistencias.

A partir de una comparacin entre los esquemas conceptuales inicial y final, se obtienen las diferencias y se propone un plan de migracin entre las bases de datos. Este plan no tiene porque ser el que el analista quiere, puede ser editado y cambiado. Una vez se tiene el plan de migracin, se traduce en sentencias de transformacin (SQL, DTS...) y se ejecuta la migracin. Finalmente, debe haber una fase de localizacin de inconsistencias, y de aviso al analista de que poblacin ha sido migrada, y que poblacin queda por analizar para su posterior migracin.

En segundo lugar, se debe tener en cuenta que, una vez generada la aplicacin en algn lenguaje de programacin como pueda ser Visual Basic, quedarn por implementar manualmente los mtodos algortmicos de comparacin de esquemas, y el compilador del plan de migracin.

En tercer lugar, est el hecho de que de todos los elementos de los esquemas conceptuales solo debemos considerar para la migracin aquellos que tengan una repercusin sobre las bases de datos.

En nuestro caso esos elementos son los siguientes:

Clases

Atributos

Relaciones de Agregacin

Relaciones de Especializacin

Por otro lado, se ha tomado la decisin de diseo de considerar un esquema conceptual como un rbol etiquetado. De esta manera, la comparacin de esquemas conceptuales se convierte en una comparacin de rboles, lo cual simplifica bastante la tarea. En la figura 3 se puede observar la representacin de un esquema conceptual en forma de rbol.

Figura3: Representacin de un esquema conceptual en forma de rbol.

Tal y como se puede observar en el rbol presentado, las restricciones de integridad vendrn siempre asociadas a las clases del modelo. Por otro lado, las relaciones siempre sern entre clases, puesto que se trata de relaciones de especializacin y de agregacin.

Es obvio que solo con el modelo conceptual no tenemos todo el trabajo hecho, faltaran por determinar muchos aspectos de la herramienta. Podemos dividir la herramienta en tres partes con funcionalidad muy diferente: un comparador de esquemas conceptuales, un editor de planes de migracin y un compilador traductor de esos planes de migracin.

Quedaran pues, por determinar los lenguajes de comunicacin entre las partes, es decir, el comparador de esquemas necesita un lenguaje de diferencias para comunicarle su resultado al editor de planes de migracin, y este a su vez necesita un lenguaje que sea capaz de entender el compilador y que tenga una expresividad suficiente para especificar cualquier plan de migracin.

Tambin habra que resolver la problemtica de determinar algoritmos de comparacin de rboles, y criterios de comparacin para esos algoritmos; esto es, comparacin por nombre, por Oid (Object Identifier), por similitud de atributos, etc.

En cualquier caso, vamos a pasar por alto todos estos aspectos, y nos vamos a centrar en la arquitectura de la herramienta y en su modelado conceptual.

A continuacin se va a presentar el modelo conceptual del migrador de datos basndonos en las consideraciones anteriores.

Modelado conceptual.

El siguiente diagrama muestra el modelo conceptual del cual ser generada automticamente la herramienta de migracin. El esquema ha sido modelado con Rational Rose por razones de confidencialidad de OO-Method, pero durante la creacin del proyecto real, este mismo modelo deber ser modelado con OO-Method.

Figura4: Modelo de datos UML generado con Rational Rose.

Ntese que la estructura del modelo viene determinada por la representacin en rbol del esquema conceptual.

De seguido se presenta la explicacin del modelo de datos anterior.

Clase Esquema Conceptual:

nicamente tiene un mtodo, Obtener Esquema Conceptual, el cual es el encargado de inicializar un nuevo esquema conceptual y cargarlo en las estructuras de datos de memoria para poder ser comparado. El atributo Nombre indica el nombre del esquema.

Clase Clase:

Representa las clases del esquema conceptual. Sus atributos relevantes de cara a la comparacin son Oid y Nombre, los cuales representan el identificador y el nombre de la clase.

Clase Atributo:

Igual que el anterior; representa los atributos de las clases del esquema conceptual.

Clase Agregacin:

Representa las relaciones de agregacin del esquema conceptual. Sus atributos relevantes de cara a la comparacin son Oid y las clases agregada y componente de la agregacin, adems son interesantes las cardinalidades.

Clase Especializacin:

Representa las relaciones de especializacin del esquema conceptual. Sus atributos relevantes de cara a la comparacin son Oid y las clases padre e hija de la especializacin, adems son interesantes las cardinalidades.

Clase Comparacin:

Representa el comparador de esquemas. Toda la funcionalidad de la herramienta, es implementada mediante los servicios de esta clase. Entre ellos estn:

Comparar por Oid: Establece un mapeo de elementos por Oid.

Comparar por Nombre: Establece un mapeo de elementos por nombre.

Establecer correspondencia: Establece una correspondencia de Oids entre los elementos de ambos esquemas. Utilizable cuando se trata con bases de datos legadas.

Generar comparacin: Genera las diferencias entre los esquemas conceptuales, una vez ya se ha establecido un mapeo con los anteriores servicios.

Como puede apreciarse, una comparacin siempre se realiza entre dos esquemas conceptuales. Por otro lado, se observa que esta clase es la clase compuesta de la clase Mapeo, la cual representa el mapeado entre elementos de los esquemas como veremos a continuacin.

Clase Mapeo:

Un mapeo viene a ser una tabla de dos columnas con los Oids de los esquemas que se comparan. En una columna se dispondrn los Oids del esquema inicial, y en otra los de la final. El resultado es una perfecta identificacin de los objetos de ambos esquemas.

Esta clase se agrega a su vez en parejas de objetos comparables.

Clase Pareja Oids:

Cada pareja de Oids viene ser una pareja de objetos comparables de ambos esquemas. Puesto que se utiliza su Oid para comparar, tenemos asegurado que los objetos estarn perfectamente identificados.

Clase Objeto Comparable:

Como ya se haba especificado anteriormente, los objetos comparables de ambos esquemas sern aquellos que tengan una repercusin directa sobre los datos; esto es las clases, los atributos, las relaciones de especializacin y las relaciones de agregacin.

Una vez generada automticamente la aplicacin tan solo quedara refinar el cdigo generado y aadir la parte puramente algortmica a los mtodos correspondientes.

Conclusiones.

Los sistemas estn condenados al cambio y a la evolucin. Por ello deben ser diseados con el pensamiento constante de que hoy el sistema es completo pero maana no lo ser porque habrn cambiado los requerimientos que sobre l pesaban.

Durante la vida de un sistema de informacin, las bases de datos van poblando con datos, y estos datos son la parte ms valiosa del sistema de informacin. Por ello, parece poco sensato tratar la evolucin de sistemas de informacin olvidando la evolucin de la propia informacin: los datos.

Para tratar el problema de la evolucin de datos en un contexto de prototipacin automtica, debemos preguntarnos hasta que punto es posible automatizar el trasvase de informacin entre bases de datos de sistemas con distinto esquema conceptual. Es evidente que siempre pueden existir datos que, por su naturaleza, solo tenan sentido en el sistema antiguo, y que por tanto no podrn ser migrados al nuevo sistema si no sufren una transformacin. Esta transformacin en algunos casos no podr ser generalizada sino que deber darse un trato especial a cada dato o tipo de dato del sistema.

Por todo ello, se hace necesaria la interaccin del usuario con la herramienta para resolver el problema; con lo cual, la migracin en algunos casos no podr ser totalmente automatizada. En este documento se ha presentado una manera de abordar el problema teniendo en cuenta todos estos aspectos.

Aunque el problema que aqu se ha tratado, ha sido resuelto mediante la herramienta OO-Method, debe quedar patente que cualquier otro generador de cdigo como OmTroll, OBLOG, etc. podra haber resuelto el problema de la misma forma. Con esto se quiere decir que cualquier herramienta que desarrolle software siguiendo el paradigma de prototipacin automtica, presenta el mismo problema de la evolucin de datos, y dicho problema debera ser resuelto de la misma manera que se resuelve el de la evolucin de esquemas.

En cualquier caso, no podemos pensar que el problema queda totalmente resuelto, puesto que siempre podramos pensar en posibles mejoras, como puede ser la automatizacin de la reparacin de inconsistencias que se producen al migrar datos que no cumplen ciertas restricciones de integridad; o como contemplar la posibilidad de que existan datos migrados en estado inconsistente, y este hecho est contemplado en el modelo dinmico del esquema conceptual. De esta forma, podra definirse una transicin de estado entre un estado inconsistente y uno consistente, y los datos solamente podran ser utilizados en el consistente...

Por otro lado quedan los Legacy Systems. La herramienta podra llegar a ser poderossima si se consiguiera generar un esquema conceptual a partir de una base de datos legada. Si as fuera, podramos llegar a migrar poblacin entre sistemas de distinta naturaleza. Los sistemas evolucionaran, y los datos seguiran el mismo curso consiguiendo que los programas se adaptaran a los cambios de requerimientos, conservando la valiosa informacin. Pero este es otro sueo como el que tuvo Blazer en 1983 y que seguro que en un futuro ser el presente.

Referencias.

[1]Ramos I., OASIS/OO-METHOD: Un Mtodo Orientado a Objetos para la produccin automtica de cdigo. DSIC 1996.[2]Letelier P., Snchez P., Ramos I., Pastor O. OASIS 3.0: Un enfoque formal para el modelado conceptual orientado a objeto. Servicio de Publicaciones, Universidad Politcnica de Valencia, SPUPV -98.4011, ISBN 84-7721-663-0, 1998.

[3]Cars J.A., OASIS como marco conceptual para la evolucin del software, Tesis Doctoral, Departamento de Sistemas Informticos y Computacin, Universidad Politcnica de Valencia, 1999.

[4] Letelier P., Generacin de Cdigo a partir de Modelos de Objetos: Estado del Arte. DSIC 1999.

Persistencia

BD

2

Lgica Negocio

Presentacin

Persistencia

BD

1

Lgica Negocio

Presentacin

EC1

EC2

EC3

EC4

Mod 1

Mod 2

Mod 3

BD

2

BD

1

BD

3

BD

4

Mig 1

Mig 2

Mig 3

Relacin j

EC

Clase1

Clase i

Relacin 1

Atributo k

Restric. 1

Atributo 1

...

...

...

ARBOL

...

Restric. n

Relacin j

EMBED PBrush

PAGE