informacion sobre tipo de tablas

[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.