Un principiante en las Artes Gráficas Una experiencia en un sector que nos envuelve… El blog personal de David Pinelo.

Detalles que no me van gustando…

Estoy ya enfrascado en adaptar tanto AbanQ como OpenBravo a mis necesidades de almacenaje de materias primas para el proceso productivo (que en el caso de las artes gráficas, es papel, tintas o barnices, y determinados consumibles para maquinaria, que aunque no son materias primas, sí inciden en la producción, como mantillas, solución de mojado, etc).

La primera en la frente con AbanQ. Una de las premisas básicas de los sistemas ERPs es la de la no duplicidad de la información en el modelo de datos. Para ello, por ejemplo, se tiene un maestro de proveedores (que puede ser una tabla donde se almacenan todos los proveedores). Y cuando debemos hacer una referencia a un proveedor desde cualquier otra entidad (por ejemplo, un pedido a proveedor o un albarán de proveedor), incluimos en esta otra tabla una columna o campo que almacena un dato, el identificador único de la tabla maestra de proveedores. De esta forma, tenemos una relación establecida y los datos no duplicados.

Veo que el modelo de datos de los módulos oficiales de AbanQ en su versión 2.2, duplican la información. Tenemos una tabla de proveedores, donde existen campos o columnas como el nombre o el CIF del mismo. Sin embargo, veo, con desagrado, que en la tabla de pedidos a proveedores, encuentro campos que duplican información: veo en esa tabla, el id del proveedor (lógico), pero también el nombre del mismo o su cif. ¿Para qué quiero tener repetida la información del proveedor en la tabla de pedidos de proveedores? Pero ya no es sólo la repetición. Imaginemos que modificamos el nombre del proveedor. Estamos obligando al sistema a que extienda esa modificación del nombre a todos las tablas que también almacenan el nombre del proveedor.

Este es un error de diseño grave del modelo relacional. Voy a preguntarlo en los foros, a ver qué respuesta obtengo, porque también existe la posibilidad, de que esté interpretando mal el modelo de datos.

Este error no ocurre en OpenBravo, donde de hecho existe un maestro genérico, "Terceros" que almacena todas las entidades ajenas a la empresa pero que influyen en la misma: Clientes, Proveedores, Acreedores, Empleados, etc. OpenBravo y su modelo de datos, respeta ese diseño básico del modelo relacional de bases de datos.

Actualizado a 21 de Noviembre de 2008. Me ha contestado Federico Albujer  en los foros de AbanQ a esta inquietud en el modelo. Reproduzco aquí su respuesta, ya que me ha parecido muy interesante:

Hola, 

estoy de acuerdo que una cosa es la teoría y otra la práctica, pero en este caso no va
exactamente de eso. 

Habría que explicar algunas interioridades de AbanQ, pero resumiendo, es una técnica para
evitar utilizar el CREATE VIEW, es decir, crear vistas o tablas temporales. AbanQ está
pensado para trabajar en principio con cualquier base de datos SQL, y esta sentencia no
se comporta igual en todas o su rendimiento es muy bajo. 

Simplificando podríamos decir que muchas de las tablas de AbanQ, son consideradas a nivel
de la lógica de negocio como vistas y no como tablas donde toda su información es
persistente y útil, aunque se creen a bajo nivel de la base de datos como tablas.
Esto supone almacenar en la base de datos mas campos, pero evita usar el CREATE VIEW y
en muchos casos, como las facturas, utilizarlo como vista persistente ( una foto en el tiempo )
como registro histórico. 

La mayoría de esos campos son datos auxiliares, pero no información duplicada, ya que son
usados en su mayoría como algo parecido a "buffers" temporales, para simular la creación
de una vista, sobre la que por ejemplo se abre un formulario o un informe, y así evitar
repetir constantemente busquedas por la clave primaria de las tablas relacionadas. Es decir,
hay una capa intermedia, el motor, si miras a través de esa capa hay un modelo relacional
hecho y derecho, pero si miras directamente la estructura física de las tablas no lo parecerá,
ya que como todos sabemos el concepto de ENTIDAD es un concepto lógico que no necesariamente
se debe corresponder con el concepto TABLA física de la base de datos. 

De hecho un modelo relacional es una estructura lógica, un modelo y una abstracción, que no
tiene porque tener una relación directa con la estructura física de las tablas. Yo puedo crear
un modelo relacional con tres entidades, y luego los datos almacenarlos físicamente en una sola
tabla, no es lo normal, porque las consultas serían mucho mas complejas y necesitarías mas
lógica para tratarlo, pero conceptualmente se puede hacer y debe funcionar perfectamente
simulando a tres tablas con sus relaciones ( además esto me recuerda a un típico problema
de examen, o por lo menos lo era cuando yo estudiaba, modelizar N entidades sobre N-M tablas,
y sí es bastante chungo ). 

En general, si en una tabla ves campos que se pueden obtener mediante la clave primaria de
la tabla relacionada, esos no son campos con información persistentemente útil, salvo que
en algunos casos se utilicen como histórico, como en las facturas. AbanQ nunca los usa como
origen de información útil, solo como temporales que actualiza por ejemplo al abrir un
formulario y para evitar repetir consultas. 

Por ejemplo, si en la tabla de direcciones de clientes tienes el campo nombre de cliente,
además de su código como clave foránea, no se rompe el modelo relacional si siempre que se
quiera obtener la información útil del nombre del cliente de una dirección, se haga la consulta 

"select c.nombre from clientes c inner join dirclientes d on c.codcliente=d.codcliente where d.id=174" 

en vez de 

"select nombre from dirclientes where id=174" 

Esto supone crear tablas mas grandes y ocupar mas espacio, pero creemos que hoy en dia es
asumible, ya que ganas velocidad en muchas situaciones, permite evitar consultas problemáticas,
reduce la complejidad de las consultas y mantiene la posibilidad de poder usar AbanQ en
varias bases de datos al crear una capa de abstracción con el modelo lógico algo mas
independiente de la estructura física de las tablas. 

En definitiva, dato no es igual a información, tu puedes obtener y copiar datos en muchos sitios
para mejorar el rendimiento, simplificar, simular vistas, etc.. pero sólo desde una sola
fuente de información consistente, y lo que haces no es duplicar, sino replicar por conveniencia. 

Saludos.