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.

Comentarios

  1. Hola!
    la solución posiblemente se de al trabajar con lideres de proyectos con formación en Ontología, Semántica y Meta datos basados en Neurolingüística y Coaching Esencial

    Saludos
    Jorge Panzariello

    ResponderEliminar
  2. No conozco la formación en Ontología, Semántica y Meta datos basados en Neurolingüística y Coaching Esencial, que seguramente ayude mucho en este aspecto y otros del proyecto.

    De cualquier forma, el problema se plantea a nivel de los desarrolladores y no a nivel de los gerentes o lideres del proyecto.

    La aparición de este problemas (y otro mas causados por la interaccion de varias personas), hace necesaria la aparicion de "normalizadores", "consolidadores", "administradores del nucleo", "DBA (Data Base Admin)", y varios etcereas mas que son las personas que permiten resolver las discrepancias entre los modelos que se plantean. Es burocracia que mitiga y amortigua las diferencias.
    Cuanto mas capacitados esten dichos lideres (y lo que tu planteas puede ser una opcion) mejor van a resolver estos problemas.

    ResponderEliminar
  3. La formación en Ontología, Semántica y Meta datos recién la estamos creando, y es el resultado de mi experiencia como empresario cliente (Muñecas Nicoletta)de Artech en 1987 o 1988 cuando Karina Santo hizo nuestro sistema integral de produccion administracion y ventas (el primero de su tipo)mas 13 años de estudio,investigacion y desarrollo de Ontologia Aplicada.

    Como tu dices, esperamos que se interesen tambien los desarrolladores asi con Ontologia Esencial podran crear entre todos los como tu llamas..."normalizadores", "consolidadores", "administradores del nucleo", "DBA (Data Base Admin)"
    Saludos
    Jorge

    ResponderEliminar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

El Sordo

StackOverflow Documentation

Paleta de colores en GeneXus