Modelo entidad-relación y diagrama entidad-relación (Periodo III - Actividad II)

GUÍA DE APRENDIZAJE

MODELO ENTIDAD-RELACIÓN Y DIAGRAMA ENTIDAD-RELACIÓN

Asignatura: Bases de Datos
Grado: Séptimo de Bachillerato
Duración: 2 clases
Modalidad: Clase-taller en parejas

---

1. CONCEPTOS FUNDAMENTALES DEL MODELO ENTIDAD-RELACIÓN

¿Qué es el Modelo Entidad-Relación?

El Modelo Entidad-Relación (MER) es una herramienta visual que nos permite diseñar bases de datos de manera organizada, mostrando cómo se relacionan los diferentes elementos de información antes de crear las tablas en un sistema de bases de datos.

Conceptos Clave

ENTIDAD

Es un objeto o concepto del mundo real sobre el cual queremos almacenar información. Las entidades se representan con rectángulos y su nombre va en singular y con mayúscula inicial.

Ejemplos de entidades:

• Cliente
• Producto
• Estudiante
• Libro
• Pedido

ATRIBUTOS

Son las características o propiedades que describen a una entidad. Se representan con óvalos conectados a la entidad.

Ejemplo: La entidad Cliente puede tener los atributos:

• ID_Cliente (identificador único)
• Nombre
• Apellido
• Email
• Teléfono

Tipos especiales de atributos:

• Atributo clave o llave primaria: Identifica de manera única cada registro (se subraya en el diagrama)
• Atributos simples: No se pueden dividir (ejemplo: Edad)
• Atributos compuestos: Se pueden dividir en partes más pequeñas (ejemplo: Dirección = Calle + Ciudad + Código Postal)

INSTANCIA

Es cada registro específico o fila dentro de una entidad. Representa un caso particular con valores concretos.

Ejemplo: En la entidad Estudiante, cada estudiante específico es una instancia:

• Instancia 1: ID=001, Nombre=“Carlos Pérez”, Curso=“7A”
• Instancia 2: ID=002, Nombre=“María González”, Curso=“7B”

RELACIONES

Son las conexiones o asociaciones entre dos o más entidades. Se representan con rombos y describen cómo interactúan las entidades entre sí.

---

2. ENTENDIENDO LAS RELACIONES EN PROFUNDIDAD

Las relaciones son el corazón del modelo entidad-relación. Permiten conectar la información de diferentes entidades de manera lógica.

Cardinalidad de las Relaciones

La cardinalidad indica cuántas instancias de una entidad pueden relacionarse con instancias de otra entidad.

Relación UNO a UNO (1:1)

Una instancia de la entidad A se relaciona con exactamente una instancia de la entidad B.

Ejemplo: Un ciudadano tiene un único pasaporte y un pasaporte pertenece a un único ciudadano.

Ciudadano (1) -------- POSEE -------- (1) Pasaporte

Relación UNO a MUCHOS (1:N)

Una instancia de la entidad A se relaciona con múltiples instancias de la entidad B, pero cada instancia de B se relaciona con solo una de A.

Ejemplo: Un cliente puede realizar muchos pedidos, pero cada pedido pertenece a un solo cliente.

Cliente (1) -------- REALIZA -------- (N) Pedido

Relación MUCHOS a UNO (N:1)

Es la misma relación 1:N pero vista desde el otro lado. Múltiples instancias de la entidad A se relacionan con una única instancia de la entidad B.

Ejemplo: Muchos empleados trabajan en un departamento, pero cada empleado pertenece a un solo departamento.

Empleado (N) -------- PERTENECE -------- (1) Departamento

Relación MUCHOS a MUCHOS (N:M)

Múltiples instancias de la entidad A se relacionan con múltiples instancias de la entidad B.

Ejemplo: Un estudiante puede inscribirse en muchos cursos y un curso puede tener muchos estudiantes.

Estudiante (N) -------- SE_INSCRIBE -------- (M) Curso

Importante: Las relaciones N:M requieren una tabla de asociación (también llamada tabla intermedia o tabla puente) que contenga las llaves foráneas de ambas entidades.

Representación de Relaciones en Diagramas

[tomado de informaticosinlimites.com]

[tomado de dannyrangel20.blogspot.com]

Símbolos de cardinalidad

---

3. RECORDANDO LOS EJERCICIOS PREVIOS

En las clases anteriores trabajamos con normalización e integración de tablas. Ahora veremos cómo se representan esos mismos casos usando diagramas entidad-relación.

Ejercicio 1: Sistema de Pedidos

Tablas trabajadas:

• Clientes: ID_Cliente, Nombre_Cliente, Ciudad_Cliente
• Productos: ID_Producto, Nombre_Producto, Precio_Unitario
• Pedidos: ID_Pedido, Fecha_Pedido, ID_Cliente, ID_Producto, Cantidad

Diagrama Entidad-Relación:

Diagrama ER mostrando:

• Entidad Cliente con sus atributos
• Entidad Producto con sus atributos
• Entidad Pedido como tabla de asociación
• Relación REALIZA entre Cliente (1) y Pedido (N)
• Relación CONTIENE entre Producto (1) y Pedido (N)]

Análisis:

• Un cliente puede realizar muchos pedidos → Relación 1:N
• Un producto puede aparecer en muchos pedidos → Relación 1:N
• Pedidos actúa como tabla de asociación que conecta clientes y productos

---

Ejercicio 2: Sistema de Reservas de Viajes

Tablas trabajadas:

• Clientes: id_cliente, nombre, apellido, email
• Destinos: id_destino, nombre_destino, pais
• Viajes: id_viaje, id_destino, precio, fecha
• Reservas: id_reserva, id_cliente, id_viaje, id_pasajero, fecha_reserva

Diagrama Entidad-Relación:

Diagrama ER mostrando:

• Entidad Cliente
• Entidad Destino
• Entidad Viaje (relacionada con Destino mediante 1:N)
• Entidad Reserva como tabla de asociación entre Cliente y Viaje]

Análisis:

• Un destino puede tener muchos viajes → Relación 1:N
• Un cliente puede hacer muchas reservas → Relación 1:N
• Un viaje puede tener muchas reservas → Relación 1:N
• Reservas conecta clientes con viajes específicos

---

Ejercicio 3: Sistema de Biblioteca

Tablas trabajadas:

• Autores: ID_Autor, Nombre_Autor, Nacionalidad
• Libros: ID_Libro, Titulo, ID_Autor, Año_Publicacion
• Usuarios: ID_Usuario, Nombre_Usuario
• Prestamos: ID_Prestamo, ID_Libro, ID_Usuario, Fecha_Prestamo

Diagrama Entidad-Relación:

Diagrama ER mostrando:

• Entidad Autor
• Entidad Libro (relacionada con Autor mediante N:1)
• Entidad Usuario
• Entidad Prestamo como tabla de asociación entre Libro y Usuario]

Análisis:

• Un autor puede escribir muchos libros, pero cada libro tiene un autor → Relación 1:N
• Un usuario puede tener muchos préstamos → Relación 1:N
• Un libro puede prestarse muchas veces → Relación 1:N

---

Ejercicio 4: Sistema de Inscripciones Académicas

Tablas trabajadas:

• Estudiantes: ID_Estudiante, Nombre_Estudiante
• Profesores: ID_Profesor, Nombre_Profesor
• Cursos: ID_Curso, Nombre_Curso, ID_Profesor
• Inscripciones: ID_Inscripcion, ID_Estudiante, ID_Curso

Diagrama Entidad-Relación:

Diagrama ER mostrando:

• Entidad Estudiante
• Entidad Profesor
• Entidad Curso (relacionada con Profesor mediante N:1)
• Entidad Inscripcion como tabla de asociación entre Estudiante y Curso]

Análisis:

• Un profesor puede dictar muchos cursos → Relación 1:N
• Un estudiante puede inscribirse en muchos cursos → Relación N:M
• Un curso puede tener muchos estudiantes → Relación N:M
• Inscripciones es la tabla de asociación que resuelve la relación N:M

---

4. EJEMPLOS DETALLADOS DE BASES DE DATOS COMPLEJAS

Ejemplo 1: Sistema de Hospital

Contexto: Un hospital necesita gestionar información sobre pacientes, médicos, citas, tratamientos y medicamentos.

Entidades:

• Paciente: ID_Paciente, Nombre, Fecha_Nacimiento, Tipo_Sangre, Telefono
• Medico: ID_Medico, Nombre, Especialidad, Telefono
• Cita: ID_Cita, ID_Paciente, ID_Medico, Fecha, Hora, Motivo
• Tratamiento: ID_Tratamiento, Nombre_Tratamiento, Descripcion
• Prescripcion: ID_Prescripcion, ID_Cita, ID_Tratamiento, Dosis, Duracion

Relaciones:

• Un paciente puede tener muchas citas → 1:N
• Un médico puede atender muchas citas → 1:N
• Una cita puede resultar en muchas prescripciones → 1:N
• Un tratamiento puede prescribirse muchas veces → 1:N

Diagrama ER completo del sistema de hospital mostrando todas las entidades, atributos y relaciones con su cardinalidad

Análisis del flujo de información:

1. Los pacientes y médicos son entidades independientes
2. Cita actúa como tabla de asociación conectando pacientes y médicos (resuelve relación N:M)
3. Prescripcion conecta las citas con los tratamientos específicos
4. Este es un ejemplo de relaciones multinivel donde una tabla de asociación (Cita) se relaciona con otra tabla de asociación (Prescripcion)

---

Ejemplo 2: Sistema de Tienda Online

Contexto: Una tienda online necesita gestionar clientes, productos, categorías, carritos de compra y órdenes.

Entidades:

• Cliente: ID_Cliente, Nombre, Email, Direccion, Telefono
• Categoria: ID_Categoria, Nombre_Categoria, Descripcion
• Producto: ID_Producto, Nombre_Producto, ID_Categoria, Precio_Unitario, Stock
• Orden: ID_Orden, ID_Cliente, Fecha_Orden, Estado, Total
• Detalle_Orden: ID_Detalle, ID_Orden, ID_Producto, Cantidad, Precio
• Pago: ID_Pago, ID_Orden, Tipo_Pago, Monto, Fecha_Pago

Relaciones:

• Una categoría tiene muchos productos → 1:N
• Un cliente puede realizar muchas órdenes → 1:N
• Una orden pertenece a un cliente → N:1
• Una orden puede tener muchos detalles (productos) → 1:N
• Un producto puede aparecer en muchos detalles de orden → 1:N
• Una orden puede tener múltiples pagos (pagos parciales) → 1:N

Diagrama ER completo del sistema de tienda online mostrando todas las entidades, sus atributos clave y las relaciones con cardinalidad

Análisis de relaciones complejas:

1. Categoria → Producto (1:N): Organización jerárquica simple
2. Cliente → Orden (1:N): Un cliente puede tener historial de compras
3. Orden → Detalle_Orden (1:N) y Producto → Detalle_Orden (1:N): Estructura de tres niveles
   • Una orden puede tener muchos detalles (múltiples productos) → Relación 1:N
   • Un producto puede aparecer en muchos detalles de diferentes órdenes → Relación 1:N
   • Detalle_Orden es la tabla de asociación que resuelve la relación N:M entre Orden y Producto
   • Permite que una orden contenga múltiples productos con diferentes cantidades, y que un producto se venda en múltiples órdenes
4. Orden → Pago (1:N): Una orden puede tener múltiples pagos
   • Permite pagos parciales o diferentes métodos de pago para una misma orden
   • La llave foránea ID_Orden en la tabla Pago establece la relación

---

Ejemplo 3: Sistema Universitario Completo

Contexto: Una universidad necesita gestionar estudiantes, profesores, cursos, programas académicos, aulas y calificaciones.

Entidades:

• Programa: ID_Programa, Nombre_Programa, Duracion_Semestres
• Estudiante: ID_Estudiante, Nombre, ID_Programa, Fecha_Ingreso
• Profesor: ID_Profesor, Nombre, Departamento, Email
• Aula: ID_Aula, Numero_Aula, Edificio, Capacidad
• Curso: ID_Curso, Nombre_Curso, Creditos, ID_Programa
• Seccion: ID_Seccion, ID_Curso, ID_Profesor, ID_Aula, Horario, Semestre
• Matricula: ID_Matricula, ID_Estudiante, ID_Seccion, Fecha_Matricula
• Calificacion: ID_Calificacion, ID_Matricula, Nota_Parcial1, Nota_Parcial2, Nota_Final

Relaciones:

• Un programa tiene muchos cursos → 1:N
• Un programa tiene muchos estudiantes → 1:N
• Un curso puede tener muchas secciones (en diferentes horarios/semestres) → 1:N
• Una sección es dictada por un profesor → N:1
• Una sección se realiza en un aula → N:1
• Un estudiante puede matricularse en muchas secciones → N:M (a través de Matricula)
• Una sección puede tener muchos estudiantes → N:M (a través de Matricula)
• Cada matrícula tiene una calificación → 1:1

Diagrama ER completo del sistema universitario mostrando la estructura completa con múltiples niveles de relaciones

Análisis de la estructura multinivel:

1. Nivel organizacional:

   • Programa → Estudiante (1:N)
   • Programa → Curso (1:N)

2. Nivel operacional:

   • Curso → Seccion (1:N): Un curso se puede ofrecer múltiples veces
   • Profesor → Seccion (1:N): Un profesor puede dictar varias secciones
   • Aula → Seccion (1:N): Un aula puede albergar varias secciones en diferentes horarios

3. Nivel de asociación compleja:

   • Matricula conecta Estudiante y Seccion (tabla de asociación que resuelve N:M)
   • Calificacion depende de Matricula, creando un tercer nivel de relación

Este ejemplo muestra:

• Relaciones 1:N en múltiples niveles
• Tabla de asociación (Matricula) conectando estudiantes con secciones específicas
• Entidades dependientes (Seccion depende de Curso, Calificacion depende de Matricula)
• Cómo una tabla de asociación puede tener sus propias relaciones con otras entidades

---

5. ACTIVIDAD PRÁCTICA

Descripción de la Actividad

Trabajando en parejas, deberán poblar (llenar) las tablas de una base de datos a partir del siguiente diagrama entidad-relación. Cada tabla debe contener 10 registros (filas) con información coherente y realista.

Sistema: Red Social de Proyectos Estudiantiles

Contexto: Una plataforma donde estudiantes pueden crear proyectos, unirse a equipos, asignar tareas y registrar el progreso.

Entidades:

• Usuario: ID_Usuario (PK), Nombre, Email, Grado, Fecha_Registro
• Proyecto: ID_Proyecto (PK), Nombre_Proyecto, Descripcion, Fecha_Inicio, Estado
• Equipo: ID_Equipo (PK), ID_Proyecto (FK), Nombre_Equipo, Fecha_Creacion
• Membresia: ID_Membresia (PK), ID_Usuario (FK), ID_Equipo (FK), Rol, Fecha_Union
• Tarea: ID_Tarea (PK), ID_Proyecto (FK), Nombre_Tarea, Descripcion, Fecha_Limite
• Asignacion: ID_Asignacion (PK), ID_Tarea (FK), ID_Usuario (FK), Fecha_Asignacion, Estado_Tarea

Relaciones:

• Proyecto → Equipo (1:N)
• Proyecto → Tarea (1:N)
• Usuario ↔ Equipo (N:M a través de Membresia)
• Usuario ↔ Tarea (N:M a través de Asignacion)]

Instrucciones

1. Analicen el diagrama: Identifiquen las entidades, atributos y relaciones

2. Creen las tablas en su cuaderno o en Excel con 10 filas cada una:

   • Tabla Usuario (10 usuarios)
   • Tabla Proyecto (10 proyectos)
   • Tabla Equipo (10 equipos)
   • Tabla Membresia (10 membresías)
   • Tabla Tarea (10 tareas)
   • Tabla Asignacion (10 asignaciones)

3. Asegúrense de que:

   • Los ID sean únicos y consecutivos
   • Las llaves foráneas correspondan a registros existentes en las otras tablas
   • Los datos sean coherentes (fechas lógicas, estados válidos, etc.)
   • Cada proyecto tenga al menos un equipo
   • Cada equipo tenga al menos un miembro
   • Cada tarea esté asignada a al menos un usuario

4. Prepárense para sustentar: El profesor puede pedirles que expliquen sus tablas y justifiquen las relaciones entre los datos

Criterios de Éxito

• ✓ Todas las tablas tienen exactamente 10 registros
• ✓ Los datos son coherentes y realistas
• ✓ Las relaciones entre tablas están correctamente establecidas
• ✓ No hay errores de referencia (llaves foráneas inválidas)
• ✓ Pueden explicar el flujo de información entre las tablas

---

6. RÚBRICA DE EVALUACIÓN

Criterio	Deficiente (0.0-1.9)	Insuficiente (3.0-3.9)	Aceptable (4.0-4.4)	Sobresaliente (4.5-4.9)	Excelente (5.0)
Completitud de datos	Menos de 6 tablas completadas o menos de 7 registros por tabla	6 tablas con 7-9 registros cada una	Todas las tablas con 10 registros pero con algunas omisiones de campos	Todas las tablas con 10 registros completos con información básica	Todas las tablas con 10 registros completos con información detallada y variada
Coherencia de relaciones	Más del 40% de llaves foráneas inválidas o sin relación lógica	20-40% de llaves foráneas con errores o incoherencias	Menos del 20% de errores en llaves foráneas, relaciones mayormente correctas	Todas las llaves foráneas válidas, relaciones correctas con mínimos errores lógicos	Todas las relaciones perfectamente establecidas y con lógica consistente en todo el sistema
Realismo y calidad de datos	Datos inventados sin sentido, repetitivos o incoherentes (fechas ilógicas, estados inexistentes)	Datos poco realistas o con muchas repeticiones, algunas incoherencias temporales	Datos realistas pero simples, algunas repeticiones, coherencia temporal básica	Datos variados y realistas, sin repeticiones significativas, coherencia temporal correcta	Datos creativos, diversos y completamente realistas, con coherencia temporal perfecta y contexto bien pensado
Comprensión conceptual (sustentación)	No puede explicar las tablas ni las relaciones, no comprende el modelo	Explica parcialmente las tablas pero confunde las relaciones o el propósito del modelo	Explica las tablas y relaciones básicas correctamente, comprensión moderada del modelo	Explica claramente las tablas, relaciones y su funcionamiento, buena comprensión del modelo ER	Explica con profundidad el sistema completo, justifica decisiones, demuestra dominio total del modelo ER
Presentación y organización	Trabajo desorganizado, difícil de leer, sin estructura clara	Organización básica, legible pero con confusiones en la estructura	Bien organizado, estructura clara, fácil de seguir	Muy bien organizado, estructura clara con formato consistente	Impecablemente organizado, formato profesional, estructura clara con identificación precisa de llaves

Nota: Para aprobar se requiere mínimo 3.0. La sustentación oral puede ajustar hasta 0.5 puntos la calificación final.

---

7. RECURSOS ADICIONALES

Videos Recomendados

1. "Modelo Entidad Relación - Conceptos Básicos" - Código Facilito
   https://www.youtube.com/watch?v=3cFcMGr2yk4
   (Duración: 15 min - Explica conceptos fundamentales de manera clara)

2. "Diagrama Entidad-Relación desde cero" - Programación ATS
   https://www.youtube.com/watch?v=AKfReg2r9qA
   (Duración: 20 min - Incluye ejemplos prácticos)

3. "Cardinalidad en Bases de Datos" - La Geekipedia De Ernesto
   https://www.youtube.com/watch?v=NFL3PqlZpbE
   (Duración: 12 min - Enfocado en entender las relaciones)

Herramientas Online

• Lucidchart (https://www.lucidchart.com) - Para crear diagramas ER de forma gratuita
• Draw.io (https://app.diagrams.net) - Herramienta gratuita para diagramación
• dbdiagram.io (https://dbdiagram.io) - Diseño rápido de bases de datos

Lecturas Complementarias

• Mandatory Relationship
  https://www.sciencedirect.com/topics/computer-science/mandatory-relationship
• Qué es un diagrama entidad-relación
  https://www.lucidchart.com/pages/es/que-es-un-diagrama-entidad-relacion
• Modelo entidad-relación
  https://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n

Práctica Adicional

• SQLBolt (https://sqlbolt.com/lesson/select_queries_introduction) - Ejercicios interactivos de SQL que complementan el diseño ER

---

Fecha de elaboración: Septiembre 2025
Tiempo estimado: 2 sesiones de clase