Debería reducir esta base de datos?

[barry17]

Hola a todos. He estado estudiando un poco acerca del diseño de bases de datos, modelo relacional, modelo E-R... y me ha surgido una duda con respecto a un caso que me aparece frecuentemente...

Supongamos que yo tengo un esquema con lo siguiente:

Compra = (fecha_creacion, monto, impuesto, descuento, usuario_operacion)

Venta = (fecha_creacion, monto, impuesto, descuento, usuario_operacion)


Como ven, ambas entidades poseen los mismos atributos pero refieren a cosas completamente diferentes... ahora, por simple observación, quizá podría generar una entidad como la siguiente:

CompraVenta = (fecha_creacion, monto, impuesto, descuento, usuario_operacion, tipo)

donde tipo sería el discriminante para saber si la tupla se refiere a una compra o a una venta... me parece buena idea, ya que si quiero manejar la base de datos desde otra tecnología (Java, ASP, PHP...), reduzco a la mitad el código que necesito para manejar la base de datos (al menos en clases manejadoras). En este ejemplo no parece mucho ahorro, pero suponiendo que cada una de las relaciones Compra y Venta tengan relaciones a otras entidades cuyos campos también son iguales, y que esto se presenta varias veces en la misma base de datos, entonces se va haciendo mas y mas código que quizá podría ahorrarse...

pero... ahora tengo entendido que al unir las dos tablas y poner un atributo discriminante, aumenta considerablemente el tiempo máquina necesario para realizar operaciones sobre la base de datos... simplemente al hacer una consulta de todas las compras, debe de revisarse el valor del atributo tipo, lo cual se puede evitar si mantengo las entidades separadas. Quizá esto tampoco parece mucho, pero en una base de datos en la que se tiene acceso concurrente por parte de muchos usuarios, y con registros que pueden tener el orden de millones creo que es algo que vale la pena discutir...

Como dije antes, tengo este tipo de casos frecuentemente, me gustaría si pudieran compartir su conocimiento o experiencia, estaría más que agradecido... :)

Saludos a todos y gracias!!

[gnzsoloyo]

Compras y ventas son conceptos totalmente distintos. No se pueden ni deben integrar como una sola entidad. Eso seria un error garrafal.
Que dos entidades parezcan tener atributos iguales no quiere decir que no sean funcionalmente distintas y diferenciadas. En todo caso tus subsistemas de compra y venta están mal modelados, porque ambas entidades no tienen en la realidad tanta similitud, además que sus relaciones son completamente diferentes.
Te conviene profundizar en Análisis de Sistemas. Te están faltando conceptos en tu modelado.

[HackmanC]

Hola,

Iniciado por barry17

... Como ven, ambas entidades poseen los mismos atributos pero refieren a cosas completamente diferentes... ...

En mi opinión, y eso solamente es mi opinión, depende completamente de las características de la aplicación, en cada caso por aparte hay que averiguar detalladamente su funcionalidad y sus características.

Tu dices que allí están tus ventas y compras, yo miro una cuenta corriente. Las cuentas corrientes normalmente se llevan en una sola tabla. Pero si mas adelante la estructura de la información va a mutar de alguna forma, escalar, tendrías que preverlo con suficiente antelación, como en este momento.

Con lo de conceptos, estoy de acuerdo en que compras y ventas sean conceptos diferentes, cuando realmente son diferentes, en tu caso no miro mas que un campo de diferencia, así como puede ser el tipo de operación, puede ser cualquier otra característica de los documentos; que igual llevarías en ventas y compras, si estuvieran independientes, por ejemplo contado o crédito. Lógicamente vas a necesitas un índice en ese campo para saberlo, al igual que en el tipo si las llevaras juntas.

Ahora, no voy a detallar porque en ese caso en específico; con la estructura exacta que estás mostrando, considero que es preferible una sola tabla, tendría que adentrarme en todos los detalles de programación y comenzar un hilo de mensajes interminable, discutiendo los motivos.

Para mi en este caso no es que tengas problema con el pensamiento de la estructura de una base de datos, para mi llegaste a una conclusión muy lógica.

Posiblemente y solamente posiblemente, porque me puedo equivocar, no tienes el conocimiento sobre una contabilidad con compras y ventas. Al final una contabilidad lleva el libro diario (si es que así se llama en tu país) y de allí saca tus conclusiones.

Saludos,

ps:

No miro las compras y ventas, sino una cuenta corriente, posiblemente porque no miro el número de documento.

[barry17]

antes que nada gracias a todos por sus comentarios.

bien, he pensado en lo que han escrito y es verdad, una compra y una venta son entidades completamente diferentes, aunque se comportan de manera parecida en este ejemplo... creo que sería mejor mantenerlas separadas por la forma en la que pueden llegar a comportarse en un futuro... acerca de la cuenta corriente la verdad desconozco como se comporta una cuenta corriente pero voy a hechar un vistazo :)

sin embargo este tipo de casos me aparecen frecuentemente: dos entidades parecen comportarse de manera similar, y pudieran fusionarse colocando un campo para distinguir entre una y otra; suponiendo que no fuera el ejemplo de las compras y ventas sino cualquier otro caso en el que esto ocurra:

se recomienda hacer esta "mezcla" entre las entidades aparentemente similares?? solo considerando el tema del tiempo máquina, a la hora de hacer operaciones sobre la base de datos, independientemente del diseño y análisis de sistemas, solo viéndolo por el lado "de los fierros"...

eso por un lado... ahora me surge la duda... a ustedes no les pasa este tipo de cosas frecuentemente?? porque si a ustedes no les pasa, seguramente (y en verdad seguramente XD) estoy muy deficiente en mi modelado de bases de datos... de ser así creo que necesito estudiar un poco mas acerca de análisis de sistemas... cierto?? alguien tiene alguna fuente bibliográfica que pudiera compartirme??

saludos y gracias de nuevo!!!

[HackmanC]

Hola,

Iniciado por barry17

... se recomienda hacer esta "mezcla" entre las entidades aparentemente similares?? ...

Desde mi punto de vista, como indiqué al principio, "en cada caso por aparte hay que averiguar detalladamente su funcionalidad y sus características".

Cambiemos el ejemplo de compras y ventas, tenemos carros y perros, aviones y carros, trenes y carros. ¿Son cosas parecidas? Realmente no, los carros no tienen nada en común con los perros; ahora los carros, aviones y trenes tienes cualidades parecidas, pero depende del detalle que yo quiero obtener.

Es decir, los carros, aviones y trenes pueden heredar de medio de transporte. Pero si en general cumplen con las características de un medio de transporte y no necesito mayor información, es mucho mas simple usar una entidad genérica, donde tenga los datos de la velocidad, precio, etc., y el tipo de medio de transporte.

Ahora, si se necesita mayor información sobre cada uno, o las cualidades tienden a ser demasiado diferentes, pues es lógico que necesite una entidad por aparte, para cada uno. Como el caso de los carros y perros, los perros tienen alimento, que es diferente al combustible, es decir, no vas a usar un campo en común llamado consume para diferencia entre alimento y combustible.

El problema aquí no es de estructura de base de datos, el problema es de conceptos, por ejemplo, aplicando el concepto que mencioné antes a las compras y ventas: en tu ejemplo no llevas número de documento, código de cliente o proveedor, contado o crédito, el detalle del documento, etc. En los dos casos, tanto compras como ventas, manejan información que normalmente es diferente, si los miras a detalle, pero sino son casi iguales.

Si no llevas toda esa información entonces no son compras o ventas, son documentos de ingreso y egreso, lo que aquí se llama cuenta corriente, y entonces no son dos cosas muy diferentes realmente, son documentos y nada mas, y en base al debe y el haber sabes si suma o resta.

Así que para saber si debes o no mezclar tendrías que saber que son exactamente en cada caso por aparte. Unir cosas que son parecidas, pero no mezclar cosas que realmente son diferentes.

Iniciado por barry17

... solo considerando el tema del tiempo máquina, a la hora de hacer operaciones sobre la base de datos, independientemente del diseño y análisis de sistemas, solo viéndolo por el lado "de los fierros"...

El tiempo de máquina y las estructuras de tu modelo de datos en la capa de programación van a ser mucho mas eficientes con una estructura de base de datos lógica y bien diseñada. Donde no mezcles perros con carros, pero tampoco separes compras y ventas cuando solo quieres verlos como documentos simples.

Iniciado por barry17

... estoy muy deficiente en mi modelado de bases de datos... de ser así creo que necesito estudiar un poco mas acerca de análisis de sistemas... cierto?? ...

No lo creo así, el problema en este caso específico no creo que sea problema de modelado, lo que estabas haciendo es normalizar datos, el problema aquí es no conoces "qué" estas modelando.

Iniciado por barry17

... acerca de la cuenta corriente la verdad desconozco como se comporta una cuenta corriente pero voy a hechar un vistazo :) ...

Exactamente allí esta el problema, para ser hacer un programa de contabilidad no es suficiente que sepas modelado de datos, ni seas un gurú de programación, es necesario que sepas contabilidad, así igual en todas las demás disciplinas.

Allí radica el problema en algunos programadores, que solo saben los for y los if de memoria, pero no saben aplicarlos porque no conocen la disciplina en la cual lo van a aplicar. Pensándolo bien, técnicamente para ser un profesional de la materia, normalmente se llevan estos cursos, ¿creo?, en cualquier universidad; y por eso se llevan, sino entonces tienes que estudiarlos por tu cuenta o lo que sea. Pero bueno, el punto es que tienes que entender qué estas haciendo para poder hacerlo.

Las computadoras son herramientas para facilitar ciertos procesos en otras disciplinas, no son útiles por si solas. Casi nunca vas a realizar un programa para que la computadora haga algo para ella, no hablo de mantenimiento posiblemente solo de mantenimiento, como por ejemplo algo que nunca vas a usar sino solamente le va a servir a la computadora.

Saludos,