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
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
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.
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.
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 ?
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.
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
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
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.
(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 😃
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.
En esta cardinalidad es donde se implementan las tablas intermedias que otorgan beneficios como:
1.- Resuelve la ambigüedad: Las tablas intermedias resuelven la ambigüedad de cómo representar una relación de muchos a muchos en una base de datos relacional. Proporcionan una estructura clara y explícita para almacenar y administrar esta relación compleja.
2.- Flexibilidad y expansión: Las tablas intermedias permiten la flexibilidad para agregar información adicional relacionada con la relación entre las entidades. Puedes incluir atributos específicos de la relación, como una fecha de inicio, un estado de inscripción, una calificación, etc.
3.- Integridad referencial: Al utilizar tablas intermedias, puedes mantener la integridad referencial entre las entidades relacionadas. Las claves foráneas en la tabla intermedia aseguran que solo se realicen conexiones válidas entre las entidades asociadas.
4.- Consultas y operaciones más eficientes: Las tablas intermedias facilitan la realización de consultas y operaciones de filtrado, búsqueda y agregación relacionadas con la relación de muchos a muchos. Puedes obtener fácilmente la lista de estudiantes inscritos en un curso o los cursos en los que está matriculado un estudiante.
Gracias a la cardinalidad podemos determinar un orden categórico entre las entidades determinado cual contiene a otras en relaciones jerárquicas y permitiéndonos hacer una base de datos mas ordenada.
Cardinalidad Muchos a muchos: Es cuando los registros de la tabla a se relacionan con varios registros de la tabla b. En esta relación nace una tabla intermedia que es la entidad débil. Por ejemplo Un cliente pueden tener un proveedores y un proveedor puede tener muchos clientes.
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?
o inicia sesión.