Apuntes: Cardinalidades múltiples muchos: También conocida como “Muchos a Muchos”. Es el tipo de cardinalidad en el que muchas entidades de un tipo, pertenecen a muchas entidades de otro, la cual debe ser normalizada y relacionada a partir de llaves foráneas.
Creo que es más correcto decir N a M ya que N a N está diciendo que ambos números de la cardinalidad son iguales (ejemplo: 2 a 2, 3 a 3), cuando en realidad llegan a ser diferentes (ejemplo, 4 a 2 ,8 a 1).
Lo que noto es que modificas el verbo cuando cambias la dirección de la relación. Por ejemplo, 1 alumno “pertenece” a 1 o muchas clases. Pero luego cuando la relación es en la otra dirección, dice algo como 1 clase “contiene”… Entonces el verbo ya no es el mismo. Esto lo noté en varias oportunidades. Mi duda es, hasta que tan estricto se es con el verbo, ya que pertenece no es lo mismo que contiene, y me imagino en situaciones más complejas como podría impactar.
Una relación de muchos a muchos se produce cuando varios registros de una tabla se asocian a varios registros de otra tabla. Por ejemplo, existe una relación de muchos a muchos entre los clientes y los productos: los clientes pueden comprar varios productos y los productos pueden ser comprados por muchos clientes.
Cardinalidad 1 a N
Cliente – Ventas: Un cliente puede tener varias ventas, pero una vente sólo puede tener un cliente
Productos- Almacén: Un producto tiene un almacén y un almacén tiene muchos productos.
Usuario—(Almacén, compras, ventas): Un usuario puede registrar varios movimientos, pero un movimiento es registrado por un usuario.
Cardinalidad N a N
Producto— Proveedores: Un producto, puede tener varios proveedores, un proveedor puede surtir varios productos
Producto—Compra: Un producto puede tener varias compras, una compra puede tener varios productos
Por lo general, cuando una relación es N:N (Muchos a Muchos), se agrega una entidad intermedia en dónde tiene una relación 1:N a una entidad y N:1 a la otra. Los registros de esta entidad depende de ambas entidades.
este es mi proyecto, es de un salón de belleza, pero al hacer la relación entre empleados y servicios me surgió una duda, ¿esta mal decir que un servicio puede ser prestado por muchos empleados?
quisiera que también opinaran, cualquier critica me ayudaría
Cuando se está armando el modelo, y se encuentran entidades con relaciones muchos a muchos hay que siempre romper esa relación con otra tabla adicional que contenga la relación con ambas entidades
Una relación de muchos a muchos se produce cuando varios registros de una tabla se asocian a varios registros de otra tabla. Por ejemplo, existe una relación de muchos a muchos entre los clientes y los productos: los clientes pueden comprar varios productos y los productos pueden ser comprados por muchos clientes.
Por lo general, los sistemas de bases de datos relacionales no permiten implementar una relación directa de muchos a muchos entre dos tablas. Tenga en cuenta el ejemplo de seguimiento de facturas. Si había muchas facturas con el mismo número de factura y uno de sus clientes preguntó acerca de ese número de factura, no sabría a qué número se refería. Este es el motivo por el que se debe asignar un valor exclusivo a cada factura.
Para evitar este problema, puede dividir la relación de muchos a muchos en dos relaciones de uno a muchos mediante el uso de una tercera tabla denominada tabla de unión. Cada registro de una tabla de unión incluye un campo de coincidencia que contiene el valor de las claves principales de las dos tablas que se unen. (En la tabla de unión, estos campos de coincidencia son claves externas). Estos campos de clave externa se rellenan con datos, ya que los registros de la tabla de unión se crean desde cualquiera de las tablas que se unen.
Un ejemplo típico de una relación de muchos a muchos es aquella entre los estudiantes y las clases. Un estudiante puede matricularse en muchas clases y una clase puede incluir muchos estudiantes.
En el siguiente ejemplo, se incluye una tabla Alumnos, que contiene un registro para cada estudiante, y una tabla Clases, que contiene un registro para cada clase. Una tabla de unión, Matrículas, crea una relación de uno a muchos, una entre cada una de las dos tablas.
A ver si lo he entendido bien… yo tengo un sistema de donación de libros, tengo la entidad libro, la entidad donación y la entidad solicitud
La relación libro donación es una relación 1:N porque cada libro puede ser donado una vez, (una vez donado sale de la base) y cada donación pero en cada donación pueden donarse varios libros; lo mismo ocurriría cuando se solicita un libro.
No sé si lo hago bien.
Cardinalidad: N a N
Entidades: Alumno y clase
Enunciado de cardinalidad:
Un alumno puede tener varias clases y una clase puede ser tomada por varios alumnos (N:N)
Una relacion muchos a muchos, eje proyecto personal:
Fundador y empresa
Un fundador puede tener muchas empresar y una empresa pudo ser creada por varias personas.
is it ok ?
Desde la teoría de la cardinalidad, las relaciones múltiples a muchos en SQL se refieren a una asociación entre dos conjuntos de entidades, donde cada entidad en el primer conjunto puede estar relacionada con múltiples entidades en el segundo conjunto, y viceversa.
La cardinalidad describe el número de entidades que participan en una relación entre conjuntos. En el caso de una relación múltiple a muchos, se tiene lo siguiente:
Para el primer conjunto de entidades (A), una entidad puede estar relacionada con múltiples entidades del segundo conjunto (B).
Para el segundo conjunto de entidades (B), múltiples entidades pueden estar relacionadas con una entidad del primer conjunto (A).
Esta relación se representa mediante una tabla de enlace o tabla de unión en la base de datos. Esta tabla contiene las claves primarias de las tablas involucradas en la relación y puede contener información adicional relacionada con la asociación.
La cardinalidad se puede expresar utilizando los siguientes símbolos:
1 (uno): Indica una relación de uno a uno.
N (muchos): Indica una relación de uno a muchos o de muchos a muchos.
En el caso de una relación múltiple a muchos, se utiliza el símbolo N para representar la cardinalidad “muchos” en ambos conjuntos.
Al diseñar la estructura de la base de datos, es importante tener en cuenta la cardinalidad y definir correctamente las claves primarias, las claves foráneas y las relaciones entre las tablas involucradas. Esto garantiza la integridad de los datos y permite realizar consultas precisas para recuperar la información relacionada.
En resumen, desde la teoría de la cardinalidad, una relación múltiple a muchos en SQL implica una asociación donde cada entidad en un conjunto puede estar relacionada con múltiples entidades en otro conjunto, y viceversa. La cardinalidad “muchos” se representa mediante una tabla de enlace que conecta las claves primarias de las tablas involucradas en la relación.
Super corta y directa la clase, me pareció interesante el tipo de relaciones entre las entidades, la que mas me captó, N:N, veo y sigo meditando en la cardinalidad de las relaciones de mi proyecto.
las explicaciones de Israel son mucho mejores de las que me han dado en la universidad y gracias a el voy pasando la materia con conocimientos que ni el profesor de la universidad me ha dado, gracias
(Siento que me estoy complicando muchísimo la existencia con esto de los múltiples muchos y tener todas las entidades de mi proyecto con esta cardinalidad). Corríjanme por favor si está bien.
Primera relación: Un videojuego puede ser lanzado por varias compañías o una compañía puede lanzar muchos videojuegos.
Segunda relación: Un videojuego puede estar en distintas plataformas, y muchos videojuegos pueden estar en una plataforma.
Tercera relación: Un videojuego puede tener muchos géneros, y un género puede tener muchos videojuegos.
Hasta donde entiendo según la dinámica, creo que también podría existir una cardinalidad de múltiples a muchos opcional. Por ejemplo:
Una tienda minorista puede tener muchos productos, y un producto puede ser poseído por varias tiendas minoristas.
Pero esto no siempre es así, dado que puede pasar que un producto no esté disponible (no sea poseído) por una o varias tiendas o bien, una tienda no tenga uno o varios productos.
Esto varía dado a la rotación de stock de las tiendas. Espero haberme explicado y que sirva de aporte teórico complementario 😃
En mi proyecto personal sobre notas para reparación de equipos celulares, identifico que un cliente puede solicitar varios servicios y los servicios pueden ser solicitados por varios clientes. 💚
Yo estoy realizando unos apuntes en Notion, de Bases de datos y de todo lo que tenga que ver con Progrmación Web y Programación. Les dejo el link a la página de Bases de Datos Relacionales. Desde ahí tienen las demás, lo iré completando poco a poco 😃
Hola buenas noches me ayudan a revisar mi diagrama.
Ya con esto me tocara cambiar de programa para hacer los diagramas
En mi proyecto de un planer del tiempo, una meta puede estar compuesta de muchos habitos. Pero un habito también puede estar dentro de muchas metas.
Si tomar el habito de hacer ejericio, este puede estar dentro del la meta de "Desarrollar masa muscular" y "Tener más energia"
* N a N es cardinalidad es muy especial, ya que varias entidades pertenecen a varias entidades y esa misma entidad puede pertenecer a varias entidades
📌 **RESUMEN: N a N, este tipo de cardinalidad es especial ya que tiene muchos retos a resolver**
Imagina que tienes una librería. En esta librería, tienes muchos libros y muchos autores. Un autor puede escribir muchos libros, y un libro puede tener muchos autores. Esta es una relación de muchos a muchos.
En términos de bases de datos, no puedes representar directamente una relación N:N en una tabla. En su lugar, se utiliza una tabla de unión o tabla intermedia para dividir la relación N:N en dos relaciones 1:N.
Siguiendo con el ejemplo de la librería, tendrías tres tablas: una para los Autores, una para los Libros y una tercera tabla, digamos AutorLibro. La tabla AutorLibro tendría las claves foráneas de las tablas Autor y Libro, y cada entrada en la tabla AutorLibro representaría una relación única entre un Autor y un Libro.
(P.D ya se que es de una AI pero me ayudó mucho a entender mejor este tipo de relación, y espero que también le pueda ayudar a alguien más)
![]()Hola! Ayudaaaa!! Les anexo como va mi trabajo, tengo algunas dudas y me serviria un montón sus correcciones. Gracias.  5.39.49 p.m.>)
Espero que esta aclaración sea útil. Las relaciones “Múltiples muchos” (N:N) se aplican a la relación entre Productos y Categorías, lo que significa que un producto puede pertenecer a múltiples categorías y una categoría puede contener múltiples productos.
En el contexto de las bases de datos, una entidad débil es aquella que depende de otra entidad para existir. En otras palabras, una entidad débil no puede ser identificada de forma única sin la existencia de otra entidad relacionada.
Una entidad débil se caracteriza por tener una clave primaria compuesta, donde una parte de la clave es una clave externa que se relaciona con otra entidad, llamada entidad fuerte. La clave externa de la entidad débil también se conoce como identificador parcial, ya que solo proporciona una identificación parcial de la entidad.
La existencia de una entidad débil está condicionada a la existencia de la entidad fuerte a la que está vinculada. Si la entidad fuerte se elimina, la entidad débil también se eliminará o perderá su identificación única. Esta dependencia se establece mediante una restricción de integridad referencial en la base de datos.
Un ejemplo común de entidad débil es la relación entre un “Cliente” (entidad fuerte) y su “Dirección” (entidad débil). La dirección de un cliente no tiene identidad propia y solo puede ser identificada a través del cliente al que está asociada.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?