Modelo entidad-relación
Mapa conceptual
- Bases de Datos
- Modelo E-R
- Entidades
- Relaciones
- Cardinalidad
- Normalización
- 1FN
- 2FN
- 3FN
- SQL
- SELECT
- JOIN
- GROUP BY
- Transacciones
- ACID
- Bloqueos
- Índices
- B-tree
- Hash
- Modelo E-R
Entidades
Una entidad es un objeto del dominio sobre el que queremos guardar información y que tiene identidad propia: cliente, producto, pedido, asignatura. En el diagrama se dibuja como un rectángulo. Una entidad se materializará más tarde como una tabla.
Atributos
Los atributos son las propiedades de una entidad: nombre, correo, fecha. En el modelo se representan como elipses unidas a su entidad y se traducen en columnas. Un atributo clave (subrayado) identifica sin ambigüedad cada instancia.
Claves
La clave primaria es el atributo, o combinación de ellos, que distingue inequívocamente cada entidad: el documento, el número de pedido. Debe ser única y no nula. Cuando ningún atributo natural sirve, se introduce un identificador artificial.
Relaciones
Una relación conecta entidades y captura su interacción con un verbo: cliente HACE pedido, alumno CURSA asignatura. Se dibuja como rombo o línea y se traduce, según su cardinalidad, en clave foránea o en tabla intermedia.
Cardinalidad
- Uno a uno: una entidad se empareja a lo sumo con una del otro lado, como persona y pasaporte.
- Uno a muchos: un cliente tiene muchos pedidos, pero cada pedido es de un cliente.
- Muchos a muchos: un alumno cursa muchas asignaturas y una asignatura tiene muchos alumnos.
- La cardinalidad decide si basta una clave foránea o hace falta tabla puente.
Participación y obligatoriedad
No toda relación es obligatoria. Un pedido requiere cliente (participación total), pero un cliente puede existir sin pedidos (participación parcial). Modelar si una relación es obligatoria y cuántas instancias mínimo y máximo admite evita esquemas que luego no reflejan la realidad.
De ER a tablas
- Cada entidad se convierte en una tabla con sus atributos como columnas.
- La clave primaria de la entidad es la clave primaria de la tabla.
- Una relación uno-a-muchos se resuelve poniendo la clave primaria del lado «uno» como foránea en el lado «muchos».
- Una relación muchos-a-muchos se materializa en una tabla intermedia con dos claves foráneas.
- Una uno-a-uno puede resolverse con una foránea única en cualquiera de los dos lados.
Atributos de relación
A veces la propia relación lleva datos: la fecha en que un alumno se matriculó en una asignatura no pertenece ni al alumno ni a la asignatura, sino a la matrícula. En muchos a muchos esos atributos van a la tabla intermedia.
Generalización y herencia
Entidades que comparten rasgos pueden organizarse en una superclase y subclases: Vehículo con subtipos Coche y Moto. Se modela la herencia para no duplicar atributos comunes y capturar la relación «es-un».
Clave natural frente a artificial
El correo identifica a un usuario, pero puede cambiar. Las claves naturales que mutan obligan a re-propagar la foránea por todas partes. Por eso es habitual usar un identificador artificial e inmutable, reservando la natural para la búsqueda del usuario.
Dependencia y entidades débiles
Ciertas entidades no existen sin su dueño: los elementos de un pedido carecen de sentido fuera de él. Son entidades débiles cuya clave primaria incluye la clave de la entidad dueña: una clave parcial más el identificador del pedido.
| Elemento ER | Se traduce a | Ejemplo |
|---|---|---|
| Entidad | tabla | Cliente |
| Atributo | columna | correo del cliente |
| Relación uno-muchos | clave foránea | cliente id dentro de Pedido |
| Relación muchos-muchos | tabla intermedia | Matricula con alumno id y asignatura id |
¿Cómo se materializa normalmente una relación muchos a muchos entre alumno y asignatura?
Notación y lectura
Existen varias notaciones (pie de cuervo, Chen). Más que la forma, importa leer igual las cuatro preguntas: ¿cuántos como máximo?, ¿cuántos como mínimo?, ¿es obligatoria?, ¿dónde va la clave? Una convención clara y constante evita malentendidos entre diseñador y desarrollador.
Errores frecuentes
- Modelar como atributo algo que es una entidad con vida propia (una dirección con múltiples campos).
- Olvidar la cardinalidad y acabar con relaciones que no capturan «cuántos».
- Elegir una clave natural mutable que obligue a reescribir foráneas al cambiar un dato.
En el paso de modelo entidad-relación a esquema, toda relación se resuelve siempre con una única clave foránea.
Validar el modelo
Se prueba el modelo redactando preguntas reales del negocio y comprobando que el esquema las responde: ¿puedo saber todos los pedidos de un cliente? ¿un producto sin ventas? Un buen modelo responde sin forzar ni duplicar, y anticipa consultas futuras.
Piezas del modelo ER
Toca una tarjeta para ver la respuesta.
Ordena el proceso de modelar un dominio:
Arrastra cada ficha a su categoría (o tócala y luego toca la categoría). También puedes usar el teclado.
draw.ioHerramienta gratuita para dibujar diagramas entidad-relación.
Modela una biblioteca: socios, libros, préstamos. Decide entidades, atributos, relaciones y su cardinalidad. ¿Un libro físico admite varios préstamos históricos? ¿Cómo lo resolverías?
Tu texto se guarda sólo en este dispositivo.
Documentación PostgreSQLReferencia oficial de SQL y bases de datos.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.