Modelado de datos con GeneXus.

Me ha tocado varias veces realizar el primer  modelo de datos de un sistema (o de un modulo de un sistema).

En dicho modelo, se define a grandes rasgos como se comportara el sistema y si bien a lo largo de la vida del sistema, el modelo de datos va a cambiar bastante, la experiencia indica que un buen modelado inicial es fundamental para que el desarrollo de todo el sistema sea fluido. Esto muchas veces, determina el exito o fracaso de los proyectos, por lo tanto, conviene tomarse un buen tiempo para definir un modelo de datos que nos convenza.

Las técnicas que pueden utilizarse para la realización de modelos de datos, son muy variadas.
Voy a presentar una muy sencilla que me ha dado buen resultado.

Para dimensionar un poco el problema, supongamos que consiste en un modelo de datos de unas 20 tablas relaciondas, que tiene poco contacto con las existentes (aunque podria no ser este el caso).

Los pasos a seguir son los siguientes

1) Preparación de la KB

La idea es comenzar con una KB vacía, donde pueda prototipar rápido.

Sobre dicha KB, consolido todos los dominios habituales de mi empresa, que van a ser compartidos entre las aplicaciones. También consolido SOLO aquellas tablas ya existente con las cuales voy a tener relaciones.
Es importante que sean solo las indispensables.

2) Definición de Transacciones

Partiendo de esto, hago el modelado de las tablas, como es habitual en GeneXus, definiendo las nuevas transacciones, si definirle reglas, parámetros, eventos, sino solamente su estructura.

Tampoco me preocupo mucho en esta etapa en la definicion del tipo de los atributos. Puden quedar todos con N(4) lo default de GeneXus, pues esto lo voy a resolver mas adelante.

Luego de tener las transacciones que necesito, visualizo las relaciones entre las mismas a través del Diagrama de Tablas. Esto me permite ver, si me estoy olvidando de la definición de subtipos o si hay alguna relación que no esta definida como quiero. Tengo que revisar cuidadosamente las claves primarias y foraneas de todas las tablas, hasta que este convencido de mi modelo.

Chequeos de esta etapa. 

• Nombre de las tablas. Es conveniente (casi obligatorio) poner los nombres de las tablas que representen lo que van a almacenar. 
• Hacer un Create Database Tables, para probar que se pueda crear sin problemas. 

3) Definición y ajustes de atributos

En esta etapa vamos a hacer los ajustes de los atributos para que cumplan con lo que yo quiero. Se recorren todos los atributos nuevos definidos y se les asigna un dominio.

Chequeos en esta etapa

• Definición de nuevos dominios. Si se necesitan nuevos dominios, hay que hacerlo en forma detallada, con valores enumerados cuando se necesiten y poniendo el Control Type correspondiente.
• Todos  los atributos tienen que tener dominio. Aunque los campos sean del tipo DATE, es bueno que compartan un dominio de forma de mostrar las fechas igual en todo el sistema. 
• Definición de atributos. A los nuevos atributos hay que ponerles Descripción, Titulo, Titulo de columna, Picture, etc,  Corregir las faltas, usar tildes y mayúsculas cuando correspondan. 
• Hacer un Create Database Tables, para probar que se pueda hacer sin problemas. 

4) Carga de datos de prueba.

Cambiar la propiedad de la KB, para definir la integridad referencial en la base de datos. Esto lo hacemos para poder adelantarnos a los chequeos que se van a realizar en la aplicación cuando agreguemos datos.

La definicion de la integridad referencial el conveniente hacerla, aunque en la aplicación final  no se vaya a usar de esta forma, porque permite encontrar inconsistencias en la definición de campos que puedan ser nulables y tambien en que orden hay que realizar el agregado de datos. 

Para cada tabla nueva, hacer un procedure muy sencillo, que agregue datos en la misma. 

Yo los programo de la siguiente forma (*)

//NewTable_Inicializacion
Msg(&PgmName,status)
new
    Clave='EJEMPLO1'
    Descripcion='Descripcion Ejemplo2'
    Fecha = &Today - 3 
endnew

new
    Clave='EJEMPLO2'
    Descripcion='Descripcion Ejemplo2'
    Fecha = &Today
endnew

No se necesitan mas de 10 registros por tabla.

Hacer un procedimiento Inicializacion (main, command line), que llame a todos los procedimientos creados en el paso anterior.
Hay que ordenar la llamada a los procedimientos de inicialización, poniendo a lo ultimo las tablas que no tengan referencias de integridad, y al principio las que son referenciadas.

Chequeos en esta etapa. 
Al lograr el programa de inicialización de ya se tiene un dominio bastante bueno de la estructura de las tablas y sus relaciones. Tambien se demuestra que puede hacerse  correctamente los inserts. 

5) Prueba del modelo de datos.

Esta me parece que es la parte mas jugosa de todas. Viendo los datos y usándolos se puede detectar algunos problemas de usabilidad, de tipos de datos, pictures, descripciones que falten, errores, etc.

Para esto, conviene aplicarle a todas las transacciones, algun pattern de WorkWith  (WorkWith, WorkWithPlus, K2BTools, PXTools, etc).

• Hacer un Create Database
• Correr el programa de inicialización
• Ejecutar cada uno de los WorkWith para ver los datos y  analizar cada uno de las relaciones. 
• Navegando entre los datos, se pueden entender mejor el modelo, detectar problemas en forma temprana en el modelo de datos. 

Estos cinco pasos, son un ciclo,  (generalmente del 2 al 5) volviendo a repetir el ciclo hasta que este totalmente convencido.
La idea es poder entrar a cada uno de los WorkWith para cada una de las tablas creadas

6) Mostrar el diseño a otro desarrollador o a un usuario final.

Despues de terminar, conviene mostrar el modelo de datos y los programas generados con el pattern, a otro desarrollador que conozca los requerimientos, para que opine sobre el mismo.
En el intercambio suelen surgir cambios interesantes, que en el enfoque personal no habian sido tomados en cuenta.

7) Ajustes.

Cuando le estructura de las tablas esta definida y los atributos están como los queremos, puede empezarse a ajustar las reglas de las transacciones y demás validaciones necesarias.
También pueden definirse los indices que van a ser necesarios.

8) Limpieza. 

En caso que no se utilicen patterns en el desarrollo, deben eliminarse todas las instancias del pattern de la KB. También deben borrarse los atributos que no estén en ninguna tabla y los dominios que no estan siendo usados.
Si no se va a utilizar la integridad referencial definida en la base de datos, hay que volver la propiedad de la KB a su valor anterior.
Los programas de incializacion de las tablas, no deben borrarse, pues le pueden servir al resto de los desarrolladores para empezar a trabajar con las nuevas tablas.

A partir de este momento, pueden utilizarse las transacciones para la creación del resto del sistema.

Esta es una técnica modesta y para nada novedosa, pero permite generar modelos de datos robustos que son la base de buenas aplicaciones. 

(*) Esto es ideal para generarlo con un pattern. Si tengo tiempo, voy a  desarrollar algo sencillo para hacerlo.  Se deberian usar Business Component y puede quedar mejor programado.