informacion sobre tipo de tablas

[cacho22]

Saludos estimado Delphius:

Exactamente, lo mas aconsejable seria tener un historico de las ABM (altas,bajas,modificaciones) que ha hecho el USR a la tabla clientes, esto se puede hacer automaticamente en manejadores de base de datos ultimos (mediante triggers) quedando la ultima version del reg. en la tabla (en este caso clientes).

Si entendi bien, si quiero sacar un reporte de ventas de un lapso de tiempo largo, por ej. del 2005 al 2007 tendria q cruzar las tablas ventas con h_cliente (historico de cliente) para sacar una información mas correcta, en vez de ventas con cliente?.

Si es esto, desarrollar el reporte me resultaria mas complejo, sin embargo sacaria una información coherente.

No crees que una mejor alternativa seria 'bloquear de por vida' el nombre o razon social para los clientes una vez que estos ya han realizado un movimiento en la tabla ventas?, es decir, nunca mas dejar modificar el nombre o razon_social para este cliente una vez este haya realizado una compra?

Gracias por tu respuesta tan rapida....

Saludos

[[Delphius]]

Empezado por cacho22

Saludos estimado Delphius:

Exactamente, lo mas aconsejable seria tener un historico de las ABM (altas,bajas,modificaciones) que ha hecho el USR a la tabla clientes, esto se puede hacer automaticamente en manejadores de base de datos ultimos (mediante triggers) quedando la ultima version del reg. en la tabla (en este caso clientes).

Si entendi bien, si quiero sacar un reporte de ventas de un lapso de tiempo largo, por ej. del 2005 al 2007 tendria q cruzar las tablas ventas con h_cliente (historico de cliente) para sacar una información mas correcta, en vez de ventas con cliente?.

Si es esto, desarrollar el reporte me resultaria mas complejo, sin embargo sacaria una información coherente.
Saludos

Hola de nuevo cacho22.
Tu lo haz dicho, obtener el histórico ahora es más complicado... es el precio que se paga cuando se elevan los "requisitos".

Empezado por cacho22

No crees que una mejor alternativa seria 'bloquear de por vida' el nombre o razon social para los clientes una vez que estos ya han realizado un movimiento en la tabla ventas?, es decir, nunca mas dejar modificar el nombre o razon_social para este cliente una vez este haya realizado una compra?
Saludos

Yo al comienzo he dicho que no se si soy el más indicado. Por lo que no soy dueño de la verdad absoluta. Y lo que he planteado no deja de ser una simple idea (mejor dicho alternativa).
Lo que dices es correcto. Correcto en cuanto al dominio que tu estás estudiando y entendiendo.
Pero... claro... como todo análisis, no es único. Tu desarrollo es una representación de tu entendimiento y si consideras que la razón social y/o el nombre de un cliente no puede ser alterado. Todo tu sistema lo reflejará y seguirá funcionando en cuanto la realidad se apegue a tu concepto del problema.

En fin... será cuestión de "gustos". La idea de hacer fijo los datos del cliente funciona, pero no es la única. Y hay otros factores que entran en juego: la progragación de requisitos y funcionalidades.

Imponer una restricción (que el cliente no pueda cambiar su razón social ha dejado de ser un requisito, ahora en tu concepto es una restricción) podría provocar cambios en el modo de operar tu sistema. Una restricción nunca debería cambiar a lo largo del ciclo de vida, por tanto condiciona al sistema (entendido a este como el todo: el software, la base de datos, etc) muy fuertemente y lo sujeta a un modelo rígido de la realidad.

Considero que si uno se plantea interrogantes es porque hay un elemento o punto del análisis y/o del dominio que no ha sido totalmente comprendido (o más común que sea opuesto o ambiguo a una parte de si mismo) Y hasta que en tu concepto no esté totalmente forjada la idea y comprensión seguirá siendo un elemento débil.

Por ejemplo: puede darse el caso que dependiendo de la razón social de tu cliente se computen ciertos descuentos, impuestos o algunas reglas de negocio. Si los datos de tu cliente necesitan ser fijos y como dices... que ante el cambio de razón social debe agregarse un nuevo cliente... esta imposición puede que lleve consigo una inconsistencia en algún otro punto del sistema si no se tienen las precuaciones y el debido análisis de las situaciones.

Ojo... no digo que tu planteo está mal. Como he dicho: podría traer consecuencias, no quiere decir que vas a tener problemas. No aseguro ni niego nada. Tu planteo debe ajustarse al mejor concepto de la realidad que tu comprendas.

Puedo aceptar tu propuesta y la aceptaré siempre y cuando considere que el modelo del diseño me lo permita. Y haya considerado (en lo que mi poca experiencia me lo diga) que implementarlo de dicha manera no traiga consigo malestares.

Esto te lo digo por lo que he visto en mi último trabajo. Uno cree que lo diseñado funciona y funciona hasta que viene el señor cambio y te lo da vuelta. Me ha tocado ser "DBA" y he encontrado un diseño que ha venido funcionando... pero claro... cuanto más me empapé del negocio puede ver y ser testigo de las complicaciones y artilugios que se tuvieron que implementar en el sistema para conseguir manteniendo la consistencia. He llegado a percatarme de que con unos pocos cambios en las tablas se hubieran solucionado algunos males.

Bueno en fin... no deja de ser un planteo. Y es así como se vive en el desarrollo del software: vivimos en un mundo en que se desea controlar pequeños y grandes caos y somos nosotros quienes deben darle cierto orden. Simulando la realidad e irnos preparandonos hacia los posibles nuevos cambios.

Sería muy interesante escuchar otros puntos de vista.
Saludos,

[cacho22]

Delphius:

Me parece muy importante tu opinion y mucho mas al saber que trabajaste o trabajas como DBA, yo igualmente soy DBA en mi empresa, y actualmente estoy en el proceso de analisis de un nuevo sistema para el manejo de caja y como tu dices uno no es dueño de la verdad, sin embargo tu opinion es muy respetable y me abre muchas ideas alternativas para solucionar los problemas q a futuro se puedan presentar.

Respecto a lo que citaste:

Imponer una restricción (que el cliente no pueda cambiar su razón social ha dejado de ser un requisito, ahora en tu concepto es una restricción) podría provocar cambios en el modo de operar tu sistema. Una restricción nunca debería cambiar a lo largo del ciclo de vida, por tanto condiciona al sistema (entendido a este como el todo: el software, la base de datos, etc) muy fuertemente y lo sujeta a un modelo rígido de la realidad.

de nuevo tienes toda la razon, por q si bien uno pone esta restriccion en todo el ciclo de vida del software o programa, puede ser q por ordenes superiores se te obligue a modificar la tabla citada, en este caso la razon_del_cliente, entonces todo el analisis ya no funcionará y esto llevará a inconsistencias futuras.

Por eso como tu dices, imponer esta restriccion haria el modelamiento de la realidad demasiado rigido (segun el caso, o la comprension q uno tenga).

Por tanto, sabiendo q en un futuro se tenga necesariamente que cambiar el nombre de ciertos clientes (yo creo q seran muy pocos en el transcurso de los años) el planteamiento q tu sugieres seria realizar los reportes de ventas cruzando la tabla de historico de clientes (h_cliente) con la tabla ventas?, claro q como decias:
es el precio que se paga cuando se elevan los "requisitos". Sin embargo el resultado es "obtener una información coherente y sin incosistencias" q es lo que uno busca.

Me parece que este diseño lo deben utilizar el servicio de impuestos internos de mi pais, por q en sus reportes t dan una información muy coherente de todo lo que hiciste en un lapso de tiempo prolongado.

Me es muy importante saber tu opinion, o plantear otra solución alternativa a las dos q se estan analizando de este caso en específico, gracias por tu colaboracion.

Saludos
cacho22

[[fjcg02]]

Pienso que las solución no está ni en una de las propuestas ni en la otra, pero sí en las dos.

En serio, bajo mi punto de vista, el problema es de uso. Dudo que un cliente cambie de nombre, de tipo de compañía ( SRL a SA ) y no cambie de NIF - nº de identificación fiscal -, es decir el DNI para entendernos.

En el caso de que cambie el NIF, el cliente es nuevo, por lo que habría que haberse creado un nuevo cliente y asignarles las ventas a ése.
También puede darse el caso de que se haya registrado mal el nombre de un cliente por error, por lo que debería permitir la aplicación cambiarlo, aunque sea de una manera restrictiva y sabiendo lo que se hace.

Por lo tanto, yo dejaría la aplicación como está, ya que según mi opinión, está bien.

Espero haber aportado algo, aunque no tenga nada que ver con las tablas maestras, submaestras ni históricas.

He dicho.

Saludos

[cacho22]

Exactamente, en el ejemplo que estamos tratando, yo pienso q se tendria q restringir el nombre_del_cliente para que no se modifique, y si en algun caso se tiene q modificar, eso lo haga el DBA, claro q tendria q ser un pequeño detalle como por ejemplo arreglar una letra mal escrita o aumentarle un pqueño detalle, pero es importante saber bien que es lo que se esta haciendo, porque si se va cambiar completamente el nombre_del_cliente esto llevaria a una inconsistencia real.

Talvez si conoces alguna direccion q hable de estos temas o parecidos te estaria muy agradecido.

Muchas gracias por tu colaboración.

[[Delphius]]

Bueno, considerando el ritmo que viene tratandose en este hilo tal vez sea conveniente tratarlo fuera pues creo que esto ya toma un curso diferente al que se vino tratando originalmente.

Teniendo en cuenta el hecho de que ya fue hecho el diseño y que está en operación el sistema. Lo más económico y menos riesgoso sería continuar trabajando como tu venías haciendolo. Pero claro... igualmente creería que habrá que hacer unos ajustes menores.
Por más que deba agregarse un nuevo cliente, tengo entendido que debe tenerse referencia de que el cliente anterior se ha "transformado" en uno nuevo. Yo al menos lo veo así, si yo fuera parte de la gerencia (o el encargado de saber dicho movimiento) me gustaría tener constancia de que porqué pepito ya no opera con dicho nombre sino que lo hace bajo el nombre luisito. Si es que esta información le es útil a alguien (y por tanto la necesita) no basta con sólo agregar un nuevo cliente con los nuevos datos. Claro... la solución barata es que si dispone del campo Observaciones, una leyenda que diga "El cliente ha cambiado la razón social y ahora opera bajo el nombre Fulano"

Igualmente como dices, es una situación que poco sucede. Al mediano plazo lo bueno sería ir agregando clientes como te aconsejan.... Pero... si vez que esto se escapa de las manos la opción es alterar la estructura y hacer los ajustes necesarios. (1)

(1) Esta tendría que haber sido la opción que debería haberse llevado en mi ex trabajo (ya no trabajo). Te comento lo que ha sucedido en mi caso: el dueño del negocio había cerrado por 3 años. Abrió de nuevo y la mayoría de los proveedores que tenía habian cambiado de razón social, o desaparecieron... como al momento de cerrar había quedado mercadería a vender.. siguió con eso... ¿que pasó? La lista de los proveedores y la de los materiales que entregaron, sumado al hecho de que no se tenía cargado registros de las ventas y compras del ejercicio anterior (y por consiguiente algunos de los nuevos) hizo un gran lio. La solución: agregar los nuevos clientes y asociarlos con las nuevas mercaderías e investigar a mano (si a mano) cada caso en particular con aquellos viejos proveedores y sus mercaderias (mediante factura en mano) Bueno hize mi tarea, quedó bonito. Me tomó un mes conseguir armonizarla. Cumplida mi tarea bueno... el resto es historia. El que diseñó el sistema reconoce que actualmente la base de datos no estaba preparada para esa situación.

Es por ello, en base a mi experiencia en aquella oportunidad, que me digo a mi mismo preparate a las consecuencias. Y por ello defiendo mi idea de que tengas esa tabla de movimientos (aunque estoy abierto a escuchar otras)

Con respecto a tu duda de como hacer el reporte es así: deberías cruzar los datos con la tablas h_cliente, y puede que también con la cliente.

No conozco algún sitio que trate estos asuntos. Si lo hay, avisen que esto ya me intriga.

Bueno... se que dije poco en esta oportunidad. No quiero que esto se convierta en un monólogo... a ver... quisiera que otros comentasen al respecto.

Saludos,

[[Delphius]]

Buen día, buenas tardes, y/o buenas noches a todos.

Hace poco he dado una respuesta en YR y considero, a mi entender, que posiblemente lo dicho en aquella oportunidad sería un buen complemento a lo expuesto en este extenso hilo.
Me pareció justo exponerlo aqui pues puede que a alguien le sirva. No creí conveniente iniciar un nuevo hilo debido a que algo del tema puede estar relacionado con esto...

Bueno... se que no soy de las mejores palabras. No me creo dueño de la verdad, pero en fin... si no suena tan tonto lo que digo, algo de sentido debe tener. Aqui vá:

¿Porqué no existe la relación muchos a muchos en base de datos?

Una relación M:M siempre puede romperse con la ayuda de una tabla intermedia. Esta tabla intermedia aunque no lo creas existe en el dominio del problema pero en un nivel de abstracción mayor que el visto inicialmente.

A ver si se me entiende:
El diseño de un DER responde a un estudio o análisis de un problema, de una realidad. A lo que en la jerga denominamos dominio. Tanto en la POO como en el diseño de un DER seguimos una simple regla: designación de responsabilidades. Esto es un paradigma que se ajusta muy bien en la gran mayoría de las veces cuando uno estudia un problema. A cada entidad (una tabla, o un objeto si estamos en POO) se le asocia la responsabilidad de suministrar la información que le compete, como sucede en la mayoría de las veces la información está ligada y dispersada por distintas entidades. Y esí como uno va formando relaciones entre las distintas entidades hasta responder a las necesidades del problema o dominio a resolver.
El problema de M:M debe verse como un suceso general (en una expresión del tiempo a futuro) Futuro entendido como un resumen de varios sucesos que sucedieron en distintos instantes del tiempo (la tabla intermedia). Es decir que el modelo que se entiende por M:M es un resumen realizado auna parte del dominio. Este resumen (la relación 1:M entre alguna la tabla A y la intermedia) hace referencia entonces a una situación que abarca diferentes valores en distintos momentos. La tabla intermedia está alli para mantener guardado detalladamente cada instancia o suceso. Cada posible combinación entre ambas entidades. En objetos diríamos que un suceso M:M está formado por una colección de INSTANCIAS de dos o más entidades. Cada instancia es un suceso único. Recuerda que una instancia existe por un período de tiempo relativamente breve.
Velo así: su muchos vendedores pueden vender muchos muebles y muchos muebles pueden ser vendidos, pero esto no quiere decir que en un MISMO INSTANTE de tiempo TODOS los vendedores van a vender TODOS los muebles.
Aquella parte del problema que ha sido expresada en forma genérica debe ser detallada. Uno se pregunta ¿Pero como es posible concebir que todos venden a la misma vez? ¿No será que un instante del tiempo un vendedor vende x muebles? Ahora si... Aquello que se ha entendido en el dominio como algo genérico está formado por una serie de sucesos que unidos entre si responden a una situación global.
Se ha necesitado cambiar el nivel de abstracción para entender cada suceso del problema. En algunas ocasiones es fácil encontrar el nombre adecuado para dicha tabla intermedia (mejor dicho encontrar el nombre para ese nivel de abstracción del dominio), en otras ocasiones no es tan sencillo. Pero siempre es posible llegar a entender la entidad que hace a cada instancia de A y B única en un instante de tiempo.
En fin: una relación M:M no es más que un caso especial en el que se desea conocer la información global entre tres entidades (A, B y la intermedia)

No se si se me entienda. Sólo quiero hacerte saber que a pesar de que el mundo real existan asociacones de M:M, existe una particularidad en dicha relación general.

El tema original lo pueden ver aquí.

Ojo. No es por hacerme publicidad, me pareció que puede ser útil. Si no es conveniente exponer el contenido borro el mensaje.

Saludos,

[cacho22]

Estimado Delphius:

En la literatura q he leido, Se da una regla:

Si existe una relacion m:n esta se puede convertir es sus equivalentes relaciones: m:1 y 1:n, es decir introducir una nueva tabla intermedia q tenga una relacion m:1 con la 1era tabla y una relacion 1:n con la segunda tabla.

Pero como explicabas, el porq existe una relacion de este tipo... A mi parecer es que no se ha hecho un analisis correcto o como dices se ha tomado un lapso de tiempo prolongado(historico) en el analisis. Si no limitamos nuestro espacio de tiempo todas nuestras relaciones tenderian a ser mucho a muchos. Un ejemplo claro de esto puede ser una relacion 'esta casado' entre dos entidades 'hombre' y 'mujer'; si no tomamos en cuenta el espacio de tiempo o como se entienda 'tomamos un gran espacio de tiempo' (puede ser 20 años) seria una relacion es m:n ya que un hombre x puede haberse casado mas de 2 veces en ese transcurso de tiempo o viceversa, pero si tomamos un momento especifico del tiempo (puede ser el presente) se vuelve una relacion 1:1 ya que un hombre en momento especifico del tiempo no puede estar casado con 2 mujeres o viceversa.

Esto, como decias, responde a un estudio o analisis del problema de la realidad, y considerar cual de los casos (m:n o 1:1) es el q le interesa al USR final.

Me llama mucho la atencion la jerga que utilizas, como ser dominio, designacion de responsabilidades, asignacion de tareas,.. etc.. me podrias decir donde puedo encontrar una bibliografia sencilla acerca de todo esto?. Mi formación en lo relacionado a Base de datos se limita al modelo relacional, si bien conozco la POO no he profundizado en el diseño POO de Base de datos, su forma de encarar la realidad, abstraccion de la realidad, etc. ya que me intereza bastante.


Gracias de antemano....

[cacho22]

Estimado Delphius:

En la literatura q he leido, Se da una regla:

Si existe una relacion m:n esta se puede convertir es sus equivalentes relaciones: m:1 y 1:n, es decir introducir una nueva tabla intermedia q tenga una relacion m:1 con la 1era tabla y una relacion 1:n con la segunda tabla.

Pero como explicabas, el porq existe una relacion de este tipo... A mi parecer es que no se ha hecho un analisis correcto o como dices se ha tomado un lapso de tiempo prolongado(historico) en el analisis. Si no limitamos nuestro espacio de tiempo todas nuestras relaciones tenderian a ser mucho a muchos. Un ejemplo claro de esto puede ser una relacion 'esta casado' entre dos entidades 'hombre' y 'mujer'; si no tomamos en cuenta el espacio de tiempo o como se entienda 'tomamos un gran espacio de tiempo' (puede ser 20 años) seria una relacion es m:n ya que un hombre x puede haberse casado mas de 2 veces en ese transcurso de tiempo o viceversa, pero si tomamos un momento especifico del tiempo (puede ser el presente) se vuelve una relacion 1:1 ya que un hombre en momento especifico del tiempo no puede estar casado con 2 mujeres o viceversa.

Esto, como decias, responde a un estudio o analisis del problema de la realidad, y considerar cual de los casos (m:n o 1:1) es el q le interesa al USR final.

Me llama mucho la atencion la jerga que utilizas, como ser dominio, designacion de responsabilidades, asignacion de tareas,.. etc.. me podrias decir donde puedo encontrar una bibliografia sencilla acerca de todo esto?. Mi formación en lo relacionado a Base de datos se limita al modelo relacional, si bien conozco la POO no he profundizado en el diseño POO de Base de datos, su forma de encarar la realidad, abstraccion de la realidad, etc. ya que me intereza bastante.


Gracias de antemano....

[[Delphius]]

Hola cacho22.
Admito que es posible que no me haya explicado bien cuando escribí dicho texto. Lo hice a medida que se me salían las palabras y no le presté demasiada atención.

Me gusta mejor el término que tu dices: espacio de tiempo. Considero que tu lo haz sabido expresar mejor.

En fin, lo que trata una relación m:n es una relación temporal a gran escala y ésta, a las finalidades de su implmentación debe ser "reducida" a una escala menor (m:1, 1:n)

Es natural que esto es aplicable dependiendo del contexto, del problema. O como se debe decir del dominio. En algunos aspectos de problema será necesario reducir la abstracción, en otros no... El análisis lo dirá.

Con respecto a la POO en BD, debo decirte que no me refiero a Base de Datos orientada a objetos sino que los mismos principios que se aplican para constituir un diseño POO se pueden llevar a cabo para asistir en el diseño de la base de datos. En POO lo que se busca es que cada objeto trabaje con lo que sabe y si necesita alguna información externa, se la solicita a otro. Es así como cada objeto aprende a formar relaciones entre otros y responde a su trabajo. Hay muchos patrones que ayudan a determinar que responsabilidades tiene un objeto. Los más comunes son los GRAPS.

En fin un objeto tiene un objetivo y en función de éste solicitará y aportará los datos necesarios.

Asi mismo, en el diseño de una base de datos contamos con tabla. Cada Tabla es un reflejo de una realidad, es una entidad. Cada entidad (tabla) lleva un registro ordenado de los datos (las tuplas y campos) con los cuales trabaja.

Se trata en fin de un mismo principio que puede ser enfocado tanto para POO como para un DER. De hecho, si uno mira el diagrama de clase se le asemeja a un DER. Pero claro, no hay que caer en la idea de que todo el modelo y diagrama de clase corresponde a un diseño DER. El mayor peligro es asumir que un diagrama de clase es un DER (y viceversa). La asignación de responsabilidades a una tabla es diferente que la asignación a los objetos. Solo parcialmente puede ser empleado.

Sobre que bibliografía puedes consultar... Veamos yo uso:
UML Gota a Gota. De Martin Flower (no recuerdo si asi es el apellido) y Kendall Scott
UML y Patrones y una introducción al anpalisis y diseño orientado a objetos y al proceso unificado. De Craig Larman
Ingeniería de Software. Un enfoque práctico. De Roger S. Presman

No recuerdo bien el libro que usé para base de datos. Creería que el autor es Yourdon.

De cualquier manera te digo que esto no es más que una filosofía de como ver las cosas. Empecé a unir conceptos, ideas, y con lo que tengo de experiencia he hecho de POO una "traslación" hacia la BD. Sobre todo debido a que considero que para conseguir una base de datos se necesita del estudio del dominio, y UML tiene un buen diagrama que puede ser de utilidad para encarar este estudio.

Por el momento no se que más decirte. Puede que si logro reordenar ideas consiga ampliarte estos dichos, aunque es probable de que debas esperar ya que tengo un dia bastante apurado.

Saludos,

[zeta2]

Amigos de Club Dephi soy un integrante muy viejito de este foro, he posteado muy pocas veces, no he sacado tantas dudas como mucho pero algo he ayudado XD.

Lo que el amigo Gabrielflower o como se llame no entiende es que esta gente que esta acá sacando las dudas de muchisima gente que entra a diario, y lo hace gratis...

Acá en Argentina los cursos salen mucho dinero y no tengo para ello, por lo tanto me las he ingeniado aprendiendo en Internet (Club Delphi) lo cual lo agradezco tanto.
Si no se esta conforme con las respuesta, páguense un tutor o un curso, ahí seguro encontraran la respuesta. Pero no exijan de esa manera a esta gente que se molesta posteando y solucionando los problemas de otros de manera gratuita a tanta gente!!!

Propongo que cuando aparezca gente así, indeseable, sea baneada enseguida para mantener la seriedad de este sitio al que tanto estimo...

Atte. Marco.