¿Tubos?…¿y eso qué es? (y iii)

Veamos con un ejemplo real la diferencia de actuación de los tubos de lista y de ficha.

Supongamos una aplicación en la que hacemos albaranes y facturas con una estructura de tablas como la siguiente.

He puesto las tablas de cabeceras de albaranes y de facturas como submaestra de años para aprovechar su código como contador y así que comience a contar en 1 en cada año ( ver articulo )

Así mismo las lineas son a su vez submaestras de las cabeceras correspondientes.

Los campos que tenemos en las tablas cabeceras son practicamente los mismo en una y en otra tabla , al igual que ocurre con los campos de las tablas lineas.

Hagamos ahora los objetos visuales que nos permitirán facturar un albarán.

El proceso general para hacerlo sérá: tenemos una ficha de Cabecera de Albarán de la que

 cuelgan sus históricos Lineas de Albarán. Tomaremos los datos de la CAlbarán y los pasaremos a un ficha de CFacturas. Una vez hecho esto, he de recorrer las lineas de LAlbaranes para hacer lo mismo, es decir, llevarlas a LFacturas pero indicándoles a dichas lineas a qué CFactura pertenecen. Para ello usaremos dos métodos. El primero mediante dos tubos de ficha y el segundo con un tubo de ficha y otro de lista.

Método 1: dos tubos de ficha

Crearemos primero el tubo de ficha para pasar datos desde una Cabecera de Albarán a una Cabecera de factura

Vemos que los capilares que usamos son pocos, no  utilizamos todos los campos, sólamente los que son necesarios para definir la factura al final del tubo, el cliente, el año y el almacén, en caso de ser multialmacén. El resto de los campos de CFactura, se “rellenarán” o bien por contenidos iniciales de los mismos o bien mediante actualizaciones desde las lineas 

Después creamos el tubo de ficha para las lineas en el que usaré dos capilares, el puntero al Artículo y la cantidad de unidades vendidas.

El proceso para facturar un único albarán será el siguiente.

 Proceso en el que ser realiza la facturación de un albarán.

Con lo que obtenemos la factura con sus lineas correspondientes. 

 Método dos: un tubo de ficha para las cabeceras y un tubo de lista para las lineas

Creamos el tubo de lista desde LAlbaranes a LFacturas, con los mismos capilares que los usados en el tubo de ficha. Los cambios irán en el proceso de facturación que se lanza desde la ficha de CAlbarán

Observar que en el post del primer tubo, ya no uso los Set para guardar valores en varialbles locales sino la instrucción de proceso

Guardar ficha, lo que nos permitirá usar un Tubo de lista con inducción. Esta inducción nos permite indicar a todas y cada una de las lineas de factura que se van creando a la salida del tubo de lista a qué ficha de maestro( CFactura) pertenecen.

La inducción hace que cada línea de la factura apunte a la misma cabecera, es decir, introduce el código del registro de la cabecera de la factura en el campo enlazado de los registros de Líneas de Factura.

Cualquiera de los dos métodos es válido. El primero, con tubo de ficha en las lineas, nos permite modificar los registros de salida del tubo, en cambio el tubo de lista no lo permite.

En el caso de tener que facturar varios albaranes en una única factura, podríamos hacer un proceso con origen lista de CAlbaranes para poder lanzarlo como una opción desde una toolbar en una  búsqueda de albaranes presentada en una rejilla multiselección, para ejecutarlo contra los seleccionados. Dividiremos así mismo el proceso en dos. En el primero, ordenamos la lista por Cliente para luego multipartirlo por ese mismo campo. Con ello logramos una “minilista” con cada todos los albaranes de un cliente, y por cada una de esas minilistas, ejecutamos el proceso que los factura.

 Proceso llamador 

  

Proceso llamado en el que se realiza la facturación de la minilista de los albaranes de un único cliente. Este proceso se repetirá por cada una de las multiparticiones que se obtengan en el proceso llamador.

Análisis : segunda fase

Una vez que hemos visto cómo usando las frases podemos establecer qué tablas actúan como maestras y cuáles como históricas, vamos a plasmarlo en del vDeveloper. Para ello usaremos el esquema de tablas          al que accederemos con el icono de la derecha del todo de la imagen.

El esquema de tablas, aparecido en la versión 2.1 , es un importante asistente a la hora de establecer enlaces entre las tablas de nuestras aplicaciones.

 

Podemos tener en nuestra aplicación tantos esquemas de tablas como necesitemos, pintando en ellos las tablas que  necesitemos. Por ejemplo, podemos tener un esquema para reflejar las relaciones de las tablas de Ventes, otra para las Compras, otra para la Facturación… En el esquema podemos apreciar un area grande a la derecha, en donde se irán pintando las tablas y en la izquierda y de arriba abajo, tres partes, la superior en la que nos vienen listados todos los esquemas que tenemos ( para cambiar de nombre a un esquema sólo hay que posicionarse sobre él y pulsar la tecla F2 ), las tablas del esquema que nos lista las tablas que tenemos en ese esquema en concreto, y las tablas no usadas que son las que no hemos incluido en el esquema en que estamos. Para “sacar” al esquema una tabla que no está, basta ponerse sobre ella en Tablas no usadas y hacer doble click con el botón izquierdo del ratón. Para eliminarla del esquema, que no de la aplicación basta posicionarse sobre ella y pulsar Supr.( eliminar una tabla de un esquema no hace que esta se borre de la aplicación )

Podemos desde aquí crear las tablas, o bien acudiendo al almacén de objetos o a la barra que aparece en la parte  izquierda del editor de esquemas. En ella podemos encontrar, de arriba abajo      

• Botón para ocultar la parte izquierda                                                                    
• Botón para nueva tabla Maestra
• Botón para nueva tabla Submaestra
• Botón para nueva tabla Maestra de Clave Arbolada          
• Botón para nueva tabla Histórica.

Usaremos el de la tabla maestra para crear una tabla de Cordilleras y otra de Montañas. Tal y como habíamos analizado en el anterior artículo, Cordilleras es maestra de Montañas. Recomiendo que a la hora de utilizar los esquemas, coloqueis las maestras en la parte de arriba del esquema, y sus histórcas por debajo, esto os dará una ventaja a posteriori pues con un simple vistazo del esquema sabreis qué tablas actúan como maestras y cuáles como históricas.

 Una vez colocadas en el esquema, nos queda establecer la relación entre ambas. Para ello usaremos el enlazador.Vamos a establecer la relación Cordilleras es maestra de Montañas, de singular Cordilleras a plural Montañas. Si posiciono el ratón sobre el cuadrante gris superior izquierda de la tabla Cordilleras, aparecerá el icono de una mano además del tooltip que se ve en la imagen. Una vez que aparezca la mano pulsamos botón izq del ratón y aparece una flecha roja. Esta flecha roja nos indica que vamos a establecer una relación de Maestro-Histórico con otra tabla. Arrastraremos sin soltar( con la flecha roja visible ) hasta la tabla Montañas y una vez sobre ella dejaremos de pulsar el botón.

Con ello ya habremos logrado enlazar las dos tablas. El puntero azul, indica que la relación entre Montañas y Cordilleras es de uno a uno ( Una Montaña está en una y sólo en una Cordillera ) mientras que el puntero rojo indica una relación de uno a muchos ( una Cordillera puede tener muchas Montañas )

Esta forma de “pintar” las relaciones entre tablas que Velneo nos proporciona, resulta una herramienta muy potente a la hora del análisis e implementación de nuestras bases de datos. Es básico y fundamental aprender a analizar bien y sacarle así todo el rendimiento al vDeveloper.

 Siguiendo el mismo procedimiento de creación de enlaces, podemos enlazar también las tablas del ejemplo de los Artículos y los Almacenes con la histórica de ambas ( recordemos que las frases válidas y más lógicas eran  LOS ALMACENES DE LOS ARTÍCULOS y LOS ARTICULOS DE LOS ALMACENES  plural-plural ) que nos permitirán navegar desde la tabla de Almacenes hasta la de artículos y viceversa.

Hemos de tener en cuenta que , si existen distintos punteros por los que navegara para moverse por las disitintas tablas, esto indica que desde una tabla se puede acceder a los datos de la otra. Es decir, desde Almacenes, puedo navegar al histórico de Existencias, para ver los Artículos que contine, y al revés, desde Artículos puedo navegar al histórico de Existencias para luego navegar por el maestro Almacenes

Análisis: primera fase

El modelo real de Velneo me encanta. No he encotrado una forma más sencilla, intuitiva y directa para diseñar las relaciones entre las tablas que las  que Velneo establece. Su modelo no obliga a que la información se adapte a la informática sino que la informática se adapta a la información, de una manera que yo suelo llamar natural.

Cuando asistí al primer curso , Juan nos enseñó una forma de analizar que me parece fácil e infalible, se trata del método de las frases. Escojamos dos tablas cualesquiera e intentemos crer las frases de singular y plural y ambos plurales. Veamos.

Cordilleras y Montañas. Construyamos las frases

1. La Cordillera de una Montaña
2. Las Cordilleras de una Montaña
3. Las Cordilleras de unas Montañas
4. La Montaña de una Cordillera 
5. Las Montañas de una Cordillera.

¿De las cincon frases cuál de ellas tiene más sentido? La número 5 es la más lógica. Por tanto Cordillera es el singular y Montañas es el plural: el singular es siempre la tabla que actúa como maestra y el plural la que actúa como histórica. La tabla Cordilleras es la maestra de Montañas.

Clientes y Cabeceras de Facturas o Facturas.

1. Los Clientes de una Factura
2. El cliente de una Factura
3. Las Facturas de un Cliente
4. La Factura de los Clientes
5. Las Facturas de los Clientes

La más lógica es la número 3, un cliente tiene muchas facturas, y una factura sólo se le puede imputar a un cliente. El singular es Cliente y el plural Facturas, luego Clientes es maestra de Facturas.

Veamos un caso en el que la frase correcta es la plural-plural.

Tenemos Artículos y Almacenes en una aplicación  multialmacén.

1. El Articulo de los almacenes
2. Los Artículos de los almacenes
3. El Artículo de un almacén.
4. Los almacenes de un artículo
5. Los almacenes  de los artículos

Todas las frases tienen sentido, por tanto no podemos decir que una tabla es maestra de la otra. Para poder solucionar esta situación necesitaremos una tabla intermedia que nos permita relacionarlas. Creemos por ejemplo una tabla llamada Existencias. Haremos que tanto Artículos como Almacenes sean maestras de Existencias, con lo que tendremos conectados a través de ella los datos de las dos tablas, así  de un Artículo veré las Existencias en los distintos Almacenes, y en un Almacén las Existencias de los distintos Artículos.

Siguiendo este método de las frases, aunque la aplicación vaya teniendo cada vez más tablas, no tendremos fallos en el análisis y por tanto en la estructuración de las tablas que es la piedra angular sobre la que se deben basar nuestras aplicaciones.