sql - una - ¿Por qué no hay relaciones de muchos a muchos?
solucion relacion muchos a muchos (9)
dice que "las relaciones de muchos a muchos no pueden existir en una base de datos relacional".
Sospecho que el autor solo está siendo polémico. Técnicamente, en el lenguaje SQL, no hay medios para declarar explícitamente una relación MM. Es un resultado emergente de declarar múltiples relaciones 1-M a la tabla. Sin embargo, es un enfoque común para lograr el resultado de una relación MM y se utiliza con frecuencia en bases de datos diseñadas en sistemas de administración de bases de datos relacionales.
No he encontrado una razón concreta (o mejor aún, un ejemplo) que explique por qué evitar la relación de muchos a muchos,
Deben usarse donde sean apropiados para ser utilizados, sería una manera más precisa de decir esto. Hay momentos, como los ejemplos de libros y autores dados por Joe Stafanelli, donde cualquier otra solución sería ineficiente e introduciría otros problemas de integridad de datos. Sin embargo, las relaciones MM son más complicadas de usar. Añaden más trabajo por parte del diseñador de GUI. Por lo tanto, solo deben usarse donde tenga sentido usarlos. Si tiene plena confianza en que una entidad nunca debe asociarse con más de una entidad, entonces, con toda seguridad, restrinja a 1-M. Por ejemplo, si estaba rastreando el estado de un envío, cada envío puede tener un solo estado en un momento dado. Complicaría en exceso el diseño y no tendría sentido lógico permitir que un envío tenga múltiples estados.
Estoy aprendiendo sobre bases de datos y SQL por primera vez. En el texto que estoy leyendo (Oracle 11g: SQL de Joan Casteel), dice que "las relaciones de muchos a muchos no pueden existir en una base de datos relacional". Entiendo que debemos evitarlos, y comprendo cómo crear una entidad puente para eliminarlos, pero estoy tratando de comprender completamente la afirmación de que "no puede existir".
¿Es en realidad físicamente imposible tener una relación de muchos a muchos representada?
¿O es simplemente muy ineficiente ya que conduce a una gran cantidad de duplicación de datos?
Me parece que es el último caso, y la entidad puente minimiza los datos duplicados. Pero tal vez me esté perdiendo algo? No he encontrado una razón concreta (o mejor aún, un ejemplo) que explique por qué evitar la relación de muchos a muchos, ya sea en el texto o en cualquier otro lugar que haya buscado. He estado buscando todo el día y solo encontré la misma información repetida: "no lo hagas y usa una entidad puente en su lugar". Pero me gusta preguntar por qué. :-)
¡Gracias!
Bueno, por supuesto, la relación MM existe en las bases de datos relacionales y también tiene capacidad de manejo en algún nivel a través de tablas de conexión, sin embargo, a medida que aumenta el grado de la relación MM, también aumenta la complejidad, lo que resulta en ciclos de RW y latencia lentos. Se recomienda evitar tales relaciones MM complejas en una base de datos relacional. Las bases de datos de gráficos son la mejor alternativa y la mejor forma de manejar la relación de muchos a muchos y es por eso que los sitios de redes sociales usan las bases de datos de gráficos para manejar la relación de MM entre el usuario y los amigos, los usuarios y los eventos, etc.
Es correcto. La relación de muchos a muchos se divide en varias relaciones de uno a muchos. ¡Esencialmente, no existe una relación de muchos a muchos!
Es imposible crear una verdadera relación de muchos a muchos que involucre dos tablas en una base de datos relacional. Creo que a eso se refieren cuando dicen que no puede existir. Para implementar muchos a muchos, se necesita una tabla intermedia con básicamente 3 campos, un ID, un ID adjunto a la primera tabla y un ID adjunto a la segunda tabla.
La razón para no querer relaciones de muchos a muchos, es que usted dijo que son increíblemente ineficientes y que administrar todos los registros vinculados a cada lado de la relación puede ser difícil, por ejemplo, si borra un registro de un lado, lo que le suceda a la ¿Registros en la tabla relacional y la tabla en el otro lado? Las eliminaciones en cascada son una pendiente resbaladiza, al menos en mi opinión.
Las relaciones M: N no deben existir en el diseño de la base de datos. Son extremadamente ineficientes y no conforman bases de datos funcionales. Dos tablas (entidades) con una relación de muchos a muchos (aeronave, aeropuerto, maestro, estudiante) no pueden ser hijos entre sí, no habría dónde colocar las claves externas sin una tabla de intersección. aeronave-> vuelo <- aeropuerto; profesor <- clase -> estudiante.
Una tabla de intersección proporciona un lugar para una entidad que depende de otras dos tablas, por ejemplo, una calificación necesita una clase y un estudiante, un vuelo necesita una aeronave y un aeropuerto. Las relaciones de muchos a muchos ocultan datos. Las tablas de intersección revelan estos datos y crean relaciones de uno a muchos que se pueden entender y trabajar más fácilmente . Entonces, surge la pregunta de qué tabla debería ser el vuelo en avión o aeropuerto. Tampoco, deben ser claves foráneas en la tabla de intersección, Vuelo.
Las relaciones de muchos a muchos son, de hecho, muy útiles y también comunes. Por ejemplo, considere un sistema de gestión de contactos que le permita poner a las personas en grupos. Una persona puede estar en muchos grupos, y cada grupo puede tener muchos miembros.
La representación de estas relaciones requiere una tabla adicional. ¿Tal vez eso es lo que realmente dice su libro? En el ejemplo que acabo de dar, tendrías una tabla de persona (id, nombre, dirección, etc.) y una tabla de grupo (id, nombre de grupo, etc.). Tampoco contiene información sobre quién está en qué grupo; para hacerlo, tiene una tercera tabla (llámela PersonGroup) en la que cada registro contiene una Identificación de persona y una Identificación de grupo; ese registro representa la relación entre la persona y el grupo.
¿Necesitas encontrar a los miembros de un grupo? Su consulta podría tener este aspecto (para el grupo con ID = 1):
SELECT Person.firstName, Person.lastName
FROM Person JOIN PersonGroup JOIN Group
ON (PersonGroup.GroupID = 1 AND PersonGroup.PersonID = Person.ID);
Normalmente (juego de palabras), usaría una tabla de enlaces para establecer muchos a muchos
Como lo describió Joe Stefanelli, digamos que tuvo autores y libros.
SELECT * from Author
SELECT * from Books
usted crearía una tabla JOIN llamada AuthorBooks
Entonces,
SELECT * from Author a JOIN AuthorBooks ab on a.AuthorId = ab.AuthorId JOIN Books b on ab.BookId = b.BookId
Espero que ayude.
Piense en una relación simple como la que existe entre autores y libros. Un autor puede escribir muchos libros. Un libro podría tener muchos autores. Ahora, sin una tabla puente para resolver la relación de muchos a muchos, ¿cuál sería la alternativa? Tendría que agregar varias columnas Author_ID a la tabla Libros, una para cada autor. ¿Pero cuántos añades? 2? 3? 10? Independientemente de los muchos que elija, probablemente terminará con una gran cantidad de filas dispersas donde muchos de los valores de Author_ID son NULOS y hay una buena probabilidad de que se encuentre con un caso en el que necesite "solo uno más". Entonces, o bien estás modificando constantemente el esquema para intentar acomodarlo o estás imponiendo alguna restricción artificial ("ningún libro puede tener más de 3 autores") para obligar a que las cosas encajen.
Por supuesto que pueden (y existen) existir. Eso me suena como una declaración de caja de jabón. Son necesarios para una gran cantidad de aplicaciones de negocios.
Hecho correctamente, no son ineficientes y tampoco tienen datos duplicados.
Echa un vistazo a FaceBook. ¿Cuántas relaciones de muchos a muchos existen entre amigos y amigos de amigos? Esa es una necesidad empresarial bien definida.
La afirmación de que "las relaciones de muchos a muchos no pueden existir en una base de datos relacional". es claramente falso.