Estoy aprendiendo acerca de las bases de datos y SQL, para la primera vez. En el texto que estoy leyendo (Oracle 11g SQL: por Joan Casteel), dice que «muchos-a-muchos de relaciones no puede existir en una base de datos relacional.» Entiendo que debemos evitar, y entiendo cómo crear un puente de la entidad para eliminarlos, pero estoy tratando de entender plenamente la declaración «no puede existir.»

Es físicamente imposible tener muchos-a-muchos relación representada?

O es muy ineficiente, ya que conduce a una gran cantidad de duplicación de datos?

Me parece ser el caso de esta última, y el puente de la entidad minimiza la duplicación de los datos. Pero tal vez me estoy perdiendo algo? No he encontrado un motivo concreto (o mejor aún un ejemplo) que explica por qué para evitar los muchos-a-muchos de relación, ya sea en el texto o en cualquier otro lugar he buscado. He estado buscando todo el día y sólo encontrar la misma información repetida: «no hay que hacerlo, y el uso de un puente de la entidad en su lugar.» Pero me gustaría preguntar por qué. 🙂

Gracias!

  • ¿Cuál es el contexto en el que el autor hace esta afirmación? Sospecho que hay más a la declaración de lo que se ve en la superficie como M-M relaciones son fundamentales en el diseño de la solución. Dicho esto, que se implementan como múltiples de 1 M de las relaciones y tal vez eso es lo que el autor está tratando de decir.
  • Thomas, el autor explica puente entidades y cómo permiten que muchos-a-muchos relación a ser representado por dos, uno-a-muchos de relaciones. Se parece a mi cita ha comenzado un poco de controversia a continuación, pero creo que es semántica. La palabra clave en tu post es «poner en marcha». Obviamente, lo que el autor quiso decir fue que no se puede aplicar directamente la M-M las relaciones, como va a explicar cómo llevarlas a la práctica con 1-M. Todavía estoy tratando de envolver mi cabeza alrededor de ella, pero las respuestas que hasta ahora están ayudando.
  • Si desea ver el debate a continuación, parece que hay una cuestión de definición. M-M las relaciones no pueden existir en un solo extranjero-definición de clave; que no es posible, PERO… con enlace de tablas, M-M las relaciones son creadas y mantenidas, y este es un uso legítimo de una base de datos relacional del sistema.
  • A la derecha. Usted no puede declarar una M-M relación (es decir, a través de una restricción), pero se puede implementar el equivalente.
InformationsquelleAutor The111 | 2011-09-07

11 Comentarios

  1. 47

    Pensar en una simple relación como la que existe entre los Autores y los Libros. Un autor puede escribir muchos libros. Un libro que podría tener muchos autores. Ahora, sin una tabla de puente para resolver los muchos-a-muchos de relación, cuál sería la alternativa? Tendrías que añadir múltiples Author_ID columnas a la tabla de Libros, uno para cada autor. Pero ¿cuántos de agregar? 2? 3? 10? Sin embargo muchos de los que usted elija, usted probablemente va a terminar con un montón de escasa filas donde muchos de los Author_ID valores son NULOS y hay una buena probabilidad de que usted va a ejecutar a través de un caso en el que necesite «sólo una más.» Así, entonces usted está constantemente modificando el esquema para tratar de acomodar o estás imponiendo algunos la restricción artificial («ningún libro puede tener más de 3 autores») para forzar las cosas para que se ajuste.

    • Gracias por la respuesta. Pero, ¿por qué la necesidad de múltiples Author_ID columnas? ¿Por qué no crear varias filas, una para cada Author_ID? Supongo que para responder a mi propia pregunta… en ese momento no tendría buena PK candidato en el libro de la tabla, ya que Book_ID conseguiría repetir cuando había varios autores (a menos que usted hizo el PK de un compuesto de Book_ID y Author_ID que parece una especie de torpe supongo). Aún así, «torpe» es diferente de imposible. Independientemente de esto, creo que estoy empezando a comprender. Quisiera saber si esto tiene sentido: (continua abajo)
    • (continuación de la anterior) 1-M ejemplo: Editor< Libro : En el Editor de la tabla, la lista sólo Pub_ID, pero en el Libro de la tabla de la lista, tanto Book_ID y Pub_ID del. Esto permite que la lógica PK no se repiten en la tabla (no Pub_ID repite en el Editor de tabla y no Book_ID se repite en el Libro de la tabla). Pub_ID a hacer repetir en el Libro de la tabla, lo cual es correcto, ya que las filas serán diferentes para cada atributo. Esto me lleva a una regla general que un atributo sólo puede ser repetido en una «mesa» si el otro lado de la conexión es una «mesa». (continua abajo)
    • (continuación de la anterior) M-M ejemplo: Libro >-< Autor : En el Libro de la tabla, no se puede repetir Author_ID, y en el Autor de la tabla, no se puede repetir Book_ID del… a causa de la «regla» que describí anteriormente. Así que no hay manera de vincular las tablas sin necesidad de crear el puente mesa de enlace. Sin embargo, ¿cuál es el resultado de romper esa regla? Supongamos que hacemos. (continua abajo)
    • (continuación de la anterior) de la REGLA-BREAK: En el Libro de la tabla, tenemos la repetición de Book_ID y Author_ID del. Supongo que el problema aquí es que aunque usted podría usar un compuesto de los dos como un PK… sería tonto ya que no hay ninguna fila que representa a un solo libro. Tienes que combinar múltiples filas para obtener toda la información acerca de un libro. Mismo en sentido inverso (la repetición de ambos valores en el Autor de la tabla). Aún así, no parece que sea posible para mí. Sólo como una idea realmente mala. Toda la información todavía estaría disponible, incluso si mucho duplicado y más difícil de interpretar.
    • Creo que tengo menos comentarios que esta en mi tesis de Maestría! 🙂 Pero creo que usted está consiguiendo la correcta comprensión de ahora.
    • Jaja, gracias por leer todo. Supongo que sólo estoy siendo un purista en la definición de «imposible». He leído originalmente como el DB sería «imposible el uso de» si se aplica de esa manera. Me parece ahora que sólo sería una de las principales PITA.

  2. 5

    Una verdadera muchos-a-muchos en la relación que implica dos tablas se puede crear en una base de datos relacional. Creo que es a lo que se refieren cuando dicen que ella no puede existir. Con el fin de implementar un de muchos a muchos que necesita de un intermediario tabla básicamente con 3 campos, una IDENTIFICACIÓN, una identificación adjunta a la primera tabla y un id adosada a la segunda tabla.

    La razón para no querer que muchos-a-muchos de relaciones, es como usted dice que son increíblemente ineficiente y la gestión de todos los registros vinculados a cada lado de la relación puede ser difícil, por ejemplo, si elimina un registro en un lado lo que sucede a los registros de la tabla relacional y la mesa en el otro lado? Eliminaciones en cascada es una pendiente resbaladiza, al menos en mi opinión.

    • No hay ningún requisito de que haya una 3ª campo «ID» en la que el intermediario de la tabla. Es simple hacer una clave compuesta a partir de la IDENTIFICACIÓN de las otras dos tablas.
    • Me gusta usar un solo primaria de la columna de claves pero las claves compuestas tienen sus usos. Creo que es muy situacional. Pero, sí, para este ejemplo muy básico que usted puede conseguir lejos con usar las otras dos columnas como una clave compuesta.
  3. 3

    Normalmente (juego de palabras) debe usar una tabla de enlaces a establecer muchos-a-muchos

    Como los descritos por Joe Stefanelli, digamos que había Autores y Libros

    SELECT * from Author
    SELECT * from Books

    tendría que crear un JOIN tabla 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.

  4. 2

    dice que «muchos-a-muchos de relaciones no puede existir en una base de datos relacional.»

    Sospecho que el autor acaba de ser controvertido. Técnicamente, en el lenguaje SQL, no hay ningún medio para declarar explícitamente un M-M relación. Es un emergente resultado de declarar múltiples de 1 M de las relaciones de la tabla. Sin embargo, es un enfoque común para alcanzar el resultado de un M-M relación y es absolutamente utiliza con frecuencia en bases de datos diseñadas en base de datos relacional de los sistemas de gestión.

    No he encontrado un motivo concreto (o mejor aún un ejemplo) que explica por qué para evitar los muchos-a-muchos de relación,

    Deben ser usados cuando son apropiados para ser utilizados fuera más exacto manera de decir esto. Hay veces, como los libros y los autores en el ejemplo dado por Joe Stafanelli, donde cualquier otra solución sería ineficiente y la introducción de otros problemas de integridad de datos. Sin embargo, M-M las relaciones son más complicadas de utilizar. Que agregar más trabajo en la parte de la interfaz de usuario del diseñador. Por lo tanto, sólo deben ser utilizados en las que tiene sentido el uso de ellos. Si usted está muy seguro de que una entidad no debe nunca ser asociada con más de una de alguna otra entidad, entonces por todos los medios restringir a un 1-M. Por ejemplo, si usted fuera un seguimiento del estado de un envío, cada envío sólo puede tener un único estado en cualquier momento dado. Sería más de complicar el diseño y no en un sentido lógico para permitir un envío a tener varios estados.

  5. 1

    De curso, pueden (y lo hacen) existe. De que me suena a una caja de jabón declaración. Son necesarios para que un gran número de aplicaciones de negocio.

    Se hace correctamente, no son ineficaces y no hemos duplicado los datos.

    Echar un vistazo a FaceBook. Cómo muchos, muchos-a-muchos existen relaciones entre amigos y amigos de amigos? Que es una bien definida la necesidad del negocio.

    La afirmación de que «muchos-a-muchos de relaciones no puede existir en una base de datos relacional.» es totalmente falso.

    • Pero se implementan como dos relaciones de uno a muchos, que estoy bastante seguro de que es el punto de la cuestión.
    • No importa cómo se mire, es una de muchos-a-muchos de relación, y afirman que no hay tal cosa existe porque sólo estás buscando en la mitad de una relación es claramente absurdo.
    • Sí y no. Las limitaciones fundamentales en SQL tienen ninguna disposición para declarar explícitamente un M-M relación. Un M-M es un emergente resultado de múltiples de 1 M de las relaciones de la misma tabla intermedia. En la raíz de los conceptos de diseño de bases de datos descritas por Codd sin embargo, lo más definitivamente existe. Como dijo Martin, supongo que el autor se está intencionadamente polémico para hacer un punto sobre cómo el M-M sean realmente aplicadas. (O eso, o el autor es un tarado).
    • eres adicto a la patente. Dejar ir 🙂 un directo de muchos a muchos relación no puede existir en el RDBMS. Usted no puede tener una matriz de teclas (como una columna. es por eso que no puede trabajar. (al menos no de forma nativa)
    • Puede que haya sido en contraste con Codasyl o OO bases de datos, pero estoy saliendo de mi fondo aquí, como nunca he usado bien.
    • si la cita fue «un directo de muchos a muchos relación no puede existir en RDBMS» yo estaría de acuerdo con usted. Que no era la cita, aunque. M-M, las relaciones, y hacer, y debe existir en la base de datos relacional de los sistemas.
    • tal vez la diferencia semántica entre el resumen modelo ER y su realización como un conjunto de tablas, columnas, y las llaves?
    • Sí creo que estamos hablando de definiciones específicas. Me tomó como una ofensa por la afirmación generalizada (posiblemente tomadas fuera de contexto) acerca de algo que es, al final del día, simplemente no es cierto, sin embargo, reclamado por un experto en la materia hasta el punto de confundir a uno de sus lectores.

  6. 1

    Muchos-a-muchos las relaciones son de hecho muy útil, y también común. Por ejemplo, considere la posibilidad de un contacto con el sistema de gestión que le permite poner a la gente en grupos. Una persona puede estar en varios grupos, y cada grupo puede tener muchos miembros.

    La representación de estas relaciones requiere una tabla extra-tal vez eso es lo que su libro está diciendo en realidad? En el ejemplo que acabo de dar, que tendría una Persona de la tabla (id, nombre, dirección, etc) y un Grupo de la tabla (id, nombre de grupo, etc). No contiene información sobre quién está en qué grupo; hacer que usted tiene una tercera tabla (llamada PersonGroup) en el que cada registro contiene una IDENTIFICACIÓN de la Persona y un ID de Grupo–registro que representa la relación entre la persona y el grupo.

    Necesidad de encontrar a los miembros de un grupo? La 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);
  7. 1

    Es correcta. La relación de muchos a Muchos se divide en varias relaciones de Uno a Muchos. Así que, esencialmente, NO hay muchos a muchos relación existe!

  8. 0

    Bien, de curso M-M relación no existe en las bases de datos relacionales y también tienen la capacidad de manejo, en algún nivel, a través de puente tablas, sin embargo, como el grado de M-M relación aumenta también aumenta la complejidad que se traduce en lentitud R-W ciclos y la latencia.
    Se recomienda evitar tales complejo M-M las relaciones en una Base de datos Relacional. Gráfico de Bases de datos son la mejor alternativa y bueno en el manejo de muchos a Muchos relación entre los objetos y es por eso que los sitios de redes sociales utiliza el Gráfico de bases de datos para el manejo de M-M relación entre el Usuario y los Amigos, a los Usuarios y Eventos etc.

  9. 0

    Vamos a inventar una ficción relación (relación de muchos a muchos) entre los libros y la tabla de ventas. Supongamos que usted está comprando los libros y cada libro que usted compra debe generar un número de factura para ese libro. Supongamos también que el número de factura para un libro puede representar múltiples ventas para el mismo cliente (en realidad no, pero vamos a suponer). Tenemos una relación de muchos a muchos entre los libros y las ventas de las entidades.
    Ahora, si ese es el caso, ¿cómo podemos obtener información acerca de sólo 1 libro dado que hemos comprado 3 libros, ya que todos los libros, en teoría, tienen el mismo número de factura? Que presenta el principal problema de la utilización de una relación de muchos a muchos, supongo. Ahora bien, si añadimos un puente de la entidad entre los Libros y las ventas de tal manera que cada libro vendido sólo tienen 1 número de factura, no importa cómo muchos de los libros son las compras todavía podemos identificar correctamente cada uno de los libros.

  10. 0

    De muchos-a-muchos de relación no es evidente redundancia, así como insertar, actualizar y eliminar anomalía que debe ser eliminado mediante la conversión de 2 de uno a muchos relación a través de un puente de tabla.

  11. -1

    M:N relaciones no deben existir en la base de datos de diseño. Son extremadamente ineficientes y no hacer para bases de datos funcionales. Dos tablas (entidades) con una relación muchos-a-muchos (relación de los aviones, aeropuerto, profesor, alumno) no pueden ser hijos de cada uno de los otros, no habría donde poner las llaves extranjeras sin una intersección de la tabla. aviones-> vuelo <- aeropuerto; maestro <- clase -> estudiante.

    Una intersección tabla proporciona un lugar para que una entidad que depende de otras dos tablas, por ejemplo, un grado de las necesidades de una clase y un alumno, de un vuelo de las necesidades de un avión y de un aeropuerto. Muchos-a-muchos de relaciones de ocultar datos. Intersección tablas revelan estos datos y crear uno-a-muchos de relaciones que se pueden más fácilmente comprendido y trabajado con. Así, surge la pregunta, ¿qué tabla el vuelo con el ser en-una aeronave o en el aeropuerto. Ninguno de los dos, que deben ser claves foráneas en la intersección de la tabla, el Vuelo.

    • Su ejemplo es una elección extraña ya que Flight es claramente una entidad por derecho propio, con sus propios datos (por ejemplo,routeId, takeOffTime) y que debe ser referencia directa a través de FKs (por ejemplo, por Ticket). Un mejor ejemplo sería un simple puente de tabla sin datos adicionales. Algunas relaciones son semánticamente M:N por lo que afirman que no deben existir en el diseño de base de datos es engañoso, ya que su respuesta debe distinguir la semántica y la implementación.

Dejar respuesta

Please enter your comment!
Please enter your name here