| Autor |
Mensaje |
Anónimo
|
# Publicado: 20 Nov 2008 10:58
Hola a todos,
Tengo una duda de diseño del modelo de datos, y que o me parece un error, o no estoy entendiendo. Según mi experiencia, 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 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. ¿Y si hay un error en ese proceso? Tendríamos información incosistente.
Es decir, tengo la sensación de que no se sigue el diseño relacional. ¿Estoy en lo correcto? ¿Se me escapa algo? ¿Está es información agregada por otra razón?
Saludos y gracias.
|
dpinelo
Miembro |
# Publicado: 20 Nov 2008 11:02
He enviado este mensaje como anónimo. No me di cuenta que no me había registrado. Disculpadme.
David Pinelo
|
Anónimo
|
# Publicado: 20 Nov 2008 15:28
¿ Y si se borra un proveedor ? Se pierde la información del CIF, por ejemplo, relacionada con la factura ( que como sabemos una factura no se puede borrar ). Una cosa es el modelo relacional y otra la consistencia de la informacion, si una factura es persistente se debe almacenar en ella la informacion necesaria, no dejando enlaces a las entidades de donde viene la información, ya que si esas entidades desaparecen pierdes el enlace y pierdes la información, que en este caso es tan necesaria, como el CIF del cliente o el proveedor.
un saludo
|
Anónimo
|
# Publicado: 20 Nov 2008 19:47
Una cosa es un modelo relacional muy bonito y teoricamente perfecto, y
otra es cuando ese modelo relacional lo debes aplicar a la vida real y
a situaciones reales y se deben tomar decisiones de compromiso, no muy
bonitas teoricamente pero eficazes en la práctica. Todos los que
realmente sí trabajamos en esto o en cualquier rama de ingenieria,
sabemos que una de las principales tareas de un ingeniero es eso
"ingeniarselas" ( efectivamente ingeniero viene de tener ingenio )
para hacer funcionar en la practica y eficientemente, lo que funciona
sobre el papel en teoria.
Quien relamente trabaje es esto sabe que es muy ingenuo verlo desde
solo un enfoque teorico, propio por cierto de estudiantes o profesores
( sobre todo profesores encerrados en su burbuja académica donde
reciben todos los meses un sueldo y no dependen de su productividad )
que aún no han tomado contacto real con el trabajo productivo y
algunas veces se atreven o se sienten en la obligación de adoctrinar a
los herejes que se desvian de los libros de texto/teorias y llevarlos
al buen camino, aunque muchas veces esos mismos adoctrinadores si
alguna vez deben abandonar su altar donde es facil predicar con la
barriga llena y un sueldo seguro hagan lo que hagan, y deben descender
al tajo donde se curra de verdad, son los primeros en pegar fuego a
los libros de texto o teorias filosóficas y caer en el pecado.
En el caso de las facturas es un ejemplo que en E-R es muy dificil de
modelizar para todas las situaciones reales y no basta una relacion 1
a muchos con por ejemplo proveedores cuando hablamos de facturas de
proveedores. Por varias razones:
1 - Una factura es un registro legal, y debe ser una foto de los datos
en el momento de expedirla. Si no copias los datos en campos
cif,direccion etc.. ya me diras como mantienes intacta una factura
desde su creacion, bueno mejor dicho ya se lo explicarás a hacienda.
Podriamos crear reglas de integridad fuertes e impedir esas
modificaciones pero... seguir punto 2.
2- Un usuario quiere borrar proveedores. Si le dices que no,
seguramente pierdes a ese usuario/cliente. Por lo tanto si se pueden
borrar hay que copiar sus datos.
3- Un usuario quiere cambiar los que quiera cuando quiera. Por ejemplo
si un proveedor estaba trabajando con una forma de pago a 30 dias y
dentro de un mes pasa a 15 dias, las facturas ya hechas no deben
cambiar pero si las nuevas. ¿ Como se hace si no se copian los datos ?
4- El rendimiento si es importante para los usuarios y mucho, un JOIN
de 10.000 registros se nota, y efectivamente aunque eso en la teoria
se obvia, hay empresas y no muy grandes que tienen 10.000 facturas,
10.000 albaranes o más, que tienen maquinas no muy potentes que no van
invertir en mejorarlas, pero que dejan claro que no les da lo mismo
que una factura tarde en imprimirse 1 segundo que 10 segundos, incluso
en muchos casos te dicen que es intolerable que tarde mas de un par de
segundos
etc..
Si juntas todas estas premisas y otras más largas de explicar, te das
cuenta que tampoco es tan buena idea una relacion uno a muchos, entre
proveedores y facturas.
un saludo
|
falbujer
Miembro |
# Publicado: 21 Nov 2008 08:50 · Editado por: falbujer
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.
|
dpinelo
Miembro |
# Publicado: 21 Nov 2008 09:12
Federico,
Tu explicación me convence. Mi pregunta estaba hecha desde el punto de vista del que no conoce el modelo de datos, y buscaba entender si había algún criterio para explicar esa "duplicidad" (que no es tal, como bien explicas). No me convencía la explicación que de este hecho daban los dos mensajes anteriores (ya que sus problemas se solventaban con agregar una marca de "borrado" en los registros, y el modelo sería perfectamente válido con una clave foránea como proponía yo).
Sabiendo, además, con seguridad que "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", acepto esa réplica de los datos (aunque no me convence del todo, si bien es cierto, que esto es cuestión de criterios y aunque no esté del todo de acuerdo con él, lo acepto como un criterio válido).
Gracias por la respuesta tan rápida, y gracias por tan magnífico trabajo a la comunidad como es AbanQ.
Saludos
|
dpinelo
Miembro |
# Publicado: 21 Nov 2008 09:29
Contestando al tercero de los posts, me vais a permitir que haga algunas matizaciones.
El modelo relacional tiene más de 30 años de exitosa implementación por tener consistencia en sí mismo permitiendo soluciones eficaces ciñéndote a la práctica. Es decir, que yo también como ingeniero (y bastantes años en la implementación de sistemas de información muy grandes) no he tenido que recurrir jamás a ninguna solución de compromiso fuera del modelo relacional. El criterio que propone Federico para la replicación de datos entra dentro del modelo relacional, ya que como bien él mismo dice, "es información no útil, sino a modo de caché o para previsualización".
Mi enfoque no era ni ingenuo ni teórico. Ni soy profesor de universidad, aunque me gustaría ;-) , ni estudiante. He tenido la suerte de ver modelos relacionales muy grandes (bancarios, de la administración pública) donde éste se cumplía a rajatabla ya que era la mejor manera de garantizar la mantenibilidad del mismo.
Lo que comentas en el punto 1, se cae por su propio peso. Por el hecho de que tú no puedas borrar los datos de cliente o proveedor de una factura no implica que la solución sea la duplicidad de los datos. Existen soluciones muy elegantes que el modelo relacional contempla y propone: una es el versionado de los datos, que permite una información histórica de los mismos, que además permanece inalterable, manteniendo una coherencia lógica en el modelo de datos. Tu solución además del punto 1 tiene una repercusión mucho más grave. ¿Qué ocurriría si descubres que has creado facturas con un nombre de cliente o proveedor equivocado? ¿O quizás has introducido un CIF no válido (aunque hayas tenido la mala suerte de pasar su regla interna de validación? Tendrías que realizar la corrección de esos datos en el propio cliente y en todas y cada una de las facturas asociadas, lo cual en el caso concreto de AbanQ no sería posible, ya que esos datos en la interfaz de escritorio están deshabilitados. Ya no sólo eso, tendrías que corregirlo en todas las facturas, pedidos, presupuestos, albaranes... Y este tipo de fallos, se cometen... y mucho (¿quien no ha tenido en su empresa el caso de una empresa con su nombre mal escrito y a la que ha habido que corregirle las facturas?)
El punto 2 se soluciona simplemente con incorporar una marca de "borrado" al proveedor o al cliente y filtrar las consultas por la misma. En un ERP, y en una aplicación de gestión, no se debe NUNCA borrar un dato así. Se marca como borrado.
El punto 3 no tienen nada que ver con copiar datos. Cada factura debería conservar un enlace a la forma de pago utilizada para pagar ESA factura.
En el punto 4 sí llevas razón. Pero debe ser completado con la apreciación de Federico, se hace así además porque la información que se almacena no es útil, ya que AbanQ sólo la utiliza como presentación. Sin embargo, y ya también como administrador de PostgreSQL, un JOIN con una tabla de 50 mil registros en un Pentium IV, y un giga de RAM (ordenador con más de 4 años) tarda poco más de un segundo... claro eso sí, PostgreSQL sobre Linux y correctamente configurado...
La relación 1 a muchos entre proveedores y facturas, no es que sea mala idea, es que es un detalle fundamental y necesario, que además AbanQ modela bien, como ha explicado Federico.
Saludos
|
