Normalizo yo o GeneXus?

Cuando se trabaja en grupo, y fundamentalmente cuando el grupo de desarrollo es numeroso, suele pasar que hay problemas en el diseño del modelo de datos.

Los hay de diferentes tipos, gravedades y consecuencias y algunos de ellos son:

• Cosas iguales que se llaman diferente
• Cosas diferentes que se llaman igual
• Diferente semántica de algun campo o relación (uno piensa que un atributo tiene determinado significado y otro integrante del grupo, piensa diferente).
• Diseños no compatibles.
• Combinaciones de los anteriores
• Varios mas menos fáciles de describir en un post por un perezoso como yo.
  

Los dos primeros, pueden minimizarse, utilizando metodologías de nomenclatura (GIK por ejemplo) de forma de uniformizar la forma en que se nombran los campos / tablas / dominios / índices / grupos de la aplicación.

Dentro de los diseños no compatibles, agrupo a los problemas de diferencias de tipos / largos de los campos. Por ejemplo si una desarrollador decide representar los importes con atributos N(10.2) y otro lo hace con N(15.3), ambas aplicaciones pueden funcionar correctamente, pero al ser consolidadas pueden aparecer problemas.

El caso de diseño no compatible al que me queria referir hoy, es a cuando tenemos diferencia en la normalización de la tablas. Para sacar el máximo provecho de la normalización automática que realiza GeneXus, se recomienda la utilización de la Universal Relation Assumption (URA para los amigos). Que dice la URA?. Que atributos iguales deben tener el mismo nombre en todas las relaciones en las que participe.

Esto, no es posible usarlo en todos los casos, por ejemplo, si se tiene una autorelación (un objeto se relaciona con otr de la misma tabla). No es posible tener una Tabla que tenga dos campos que se llamen igual y tampoco seria muy fácil saber a cual de ellos me estoy refiriendo. Esto se soluciona con los subtipos.

Bueno, volviendo al tema. Que pasa cuando tenemos mucha gente utilizando la URA y consolidando cada uno de esos modelos en uno mas grande?. Algunas veces pasa que la suma de modelos coherentes, no es un modelo coherente.

Poniendo un ejemplo:

Juan Ramon tiene lo siguiente

CLIENTES
*ClienteClave
ClienteNombre
PaisClave //Pais del cliente

PAISES
*PaisClave
PaisNombre
ContinenteClave //Continente al que pertenece el pais

CONTINENTES
*ContienenteClave
ContinenteNombre

Pablo Javier tiene el diseño

CLIENTES(PJ)
*ClienteClave
ClienteNombre
ContinenteClave //Continente donde ese cliente puede revender mis productos.

CONTINENTES(PJ)
*ContinenteClave
ContinenteNombre

Al consolidar estas dos visiones de la realidad que son validas por separado, Pablo Javier va a tener una diferencia entre lo que el tiene y el modelo consolidado, pues el atributo ContinenteClave, va a salir de la tabla de Clientes pues puede deducirse desde paises. El problema que el significado de este atributo es diferente al que tenia para Juan Ramon.

Todos sabemos que es muy difícil que Juan Ramón haga autocrítica, la forma de evitarlo es definir subtipos para cada relación que tenga en mi modelo. Entonces Pablo Javier pondria:

CLIENTES(PJ)
*ClienteClave
ClienteNombre
ClienteContinenteClave subtipo de ContinenteClave.

Con lo cual se evita el problema, de forma que todo quede como deseamos, pero entonces, terminamos haciendo la normalización en forma manual, a través de la definición de subtipos.

La forma de solucionar esto, es poner a una persona que sea la que solucione este tipo de conflictos entre los modelos de datos (seria el equivalente al papel que cumplen los DBA en equipos de desarrollo que no utilizan GeneXus). De esta forma, esta persona podría saber que modelo de datos se quiere y lograrlo a traves de las transacciones. La ventaja de la normalización automática que realiza GeneXus se ve un poco disminuida cuando los modelos creces muchos (cientos de tablas).

Dado que tenemos una normalizacion automática, es facil detectar las diferencias entre el modelo esperado y el modelo normalizado por GeneXus y corregirlo.