El modelo entidad-relación es la herramienta que se usa para diseñar una base de datos antes de crearla: representa qué entidades existen (clientes, pedidos, empleados), qué atributos tiene cada una y cómo se relacionan entre sí. La normalización, por su parte, es el proceso posterior que organiza esas tablas para evitar datos repetidos e inconsistencias. Los dos conceptos forman parte del Bloque III (Desarrollo de Sistemas) del temario TAI, y son distintos del modelo relacional y SQL: aquí no se trata de consultar datos, sino de diseñar bien la estructura antes de que exista una sola fila de datos.
¿Qué es el modelo entidad-relación y para qué sirve en el Bloque III?
El modelo entidad-relación (modelo E-R) es una técnica de diseño conceptual propuesta por Peter Chen en 1976. Su objetivo es representar de forma gráfica la realidad que se quiere almacenar en una base de datos, antes de traducirla a tablas concretas. Se usa en la fase de análisis y diseño, previa a la implementación física, y es independiente del gestor de base de datos que se acabe usando después (MySQL, PostgreSQL, Oracle, etc.).
En el examen TAI este contenido suele aparecer en preguntas sobre qué representa cada elemento de un diagrama, qué tipo de cardinalidad corresponde a un caso descrito, o qué forma normal cumple o incumple una tabla dada.
¿Qué son las entidades, los atributos y las relaciones?
El modelo E-R se construye con tres elementos básicos:
- Entidad: un objeto o concepto del mundo real sobre el que se quiere guardar información (un empleado, un producto, una factura). Se representa con un rectángulo.
- Atributo: una propiedad de una entidad (el DNI y el nombre de un empleado, el precio de un producto). Se representa con un óvalo unido a la entidad.
- Relación (o interrelación): una asociación entre dos o más entidades (un empleado "gestiona" un proyecto). Se representa con un rombo.
Dentro de los atributos hay una distinción importante para el examen: el atributo clave (o identificador) es el que permite distinguir de forma única cada ejemplar de una entidad, como el DNI en la entidad Empleado. Sin un atributo clave, dos empleados con el mismo nombre serían indistinguibles para el sistema.
¿Qué tipos de cardinalidad hay entre entidades?
La cardinalidad indica cuántos ejemplares de una entidad pueden asociarse con cuántos ejemplares de otra a través de una relación. Hay tres tipos básicos:
| Cardinalidad | Ejemplo |
|---|---|
| 1 a 1 | Un empleado tiene un único despacho asignado, y ese despacho pertenece a un solo empleado |
| 1 a N (uno a muchos) | Un departamento tiene varios empleados, pero cada empleado pertenece a un solo departamento |
| N a M (muchos a muchos) | Un alumno puede matricularse en varias asignaturas, y cada asignatura tiene varios alumnos matriculados |
Esta distinción no es solo teórica: condiciona cómo se traduce después el diagrama a tablas relacionales. Las relaciones N a M, por ejemplo, necesitan una tabla intermedia propia cuando se pasa al modelo relacional.
¿Cómo se dibuja un diagrama E-R básico?
Un diagrama E-R sencillo sigue estos pasos:
- Identificar las entidades principales del sistema (por ejemplo, Alumno y Asignatura).
- Asignar los atributos relevantes a cada entidad, marcando cuál es la clave.
- Trazar las relaciones entre entidades con un rombo.
- Indicar la cardinalidad en cada extremo de la relación (1, N o M).
Con Alumno y Asignatura relacionadas mediante "se matricula en", y cardinalidad N a M, el diagrama ya cuenta toda la historia: cada alumno puede tener varias asignaturas y cada asignatura, varios alumnos. Ese matiz es justo el que hay que saber leer en el examen cuando se presenta un diagrama ya dibujado.
¿Qué es la normalización de bases de datos y por qué importa?
La normalización es el proceso de organizar los atributos de una base de datos en tablas para reducir la redundancia (datos repetidos innecesariamente) y evitar anomalías al insertar, actualizar o borrar registros. Se aplica sobre el diseño ya traducido a tablas, después del diagrama E-R, y se hace a través de una serie de reglas llamadas formas normales. En el TAI, lo habitual es que se pregunte por las tres primeras: 1FN, 2FN y 3FN.
¿Cómo se aplican la 1FN, 2FN y 3FN? Ejemplo práctico paso a paso
Partamos de una tabla única, sin normalizar, que guarda pedidos de una tienda:
| Pedido | Cliente | Teléfono cliente | Productos (varios) |
|---|---|---|---|
| 1001 | Ana Pérez | 600111222 | Teclado, Ratón |
1FN (primera forma normal): exige que cada campo contenga un único valor atómico, sin listas ni grupos repetidos. La columna "Productos" incumple esto porque guarda varios valores en una sola celda. Para cumplir 1FN, cada producto pasa a su propia fila, repitiendo el resto de datos del pedido.
2FN (segunda forma normal): exige cumplir 1FN y, además, que todo atributo no clave dependa de la clave completa (esto aplica cuando la clave está compuesta por varios campos, como Pedido + Producto). El campo "Teléfono cliente" depende solo del Cliente, no de la combinación Pedido y Producto, así que se separa en una tabla Cliente aparte.
3FN (tercera forma normal): exige cumplir 2FN y que no existan dependencias transitivas, es decir, que un atributo no clave dependa de otro atributo no clave en lugar de depender directamente de la clave. Si en la tabla Cliente guardamos también la Ciudad y el Código Postal, y el Código Postal determina la Ciudad, esa dependencia (Ciudad depende de Código Postal, no directamente del Cliente) hay que separarla en su propia tabla.
El resultado final, tras aplicar las tres formas normales, son varias tablas pequeñas y relacionadas entre sí (Pedido, Línea de pedido, Producto, Cliente, Localidad) en lugar de una única tabla con datos repetidos y mezclados.
¿Quieres el Bloque III completo y bien explicado?
El modelo E-R, la normalización y el resto de Desarrollo de Sistemas están en los apuntes del Bloque III, listos para estudiar sin depender de una academia.
Ver el Bloque III →Preguntas frecuentes
¿Cuál es la diferencia entre el modelo entidad-relación y el modelo relacional?
El modelo E-R es una herramienta de diseño conceptual, previa a la creación de la base de datos, que representa entidades y relaciones de forma gráfica. El modelo relacional es el que organiza ya los datos en tablas con filas y columnas, listo para implementarse en un gestor como MySQL o PostgreSQL. El E-R se traduce después al modelo relacional.
¿Por qué es importante normalizar una base de datos?
Porque evita que un mismo dato se repita en varias filas de forma innecesaria, lo que reduce el riesgo de inconsistencias cuando se actualiza o se borra información, y ahorra espacio de almacenamiento.
¿Existen formas normales más allá de la 3FN?
Sí, existen la forma normal de Boyce-Codd (FNBC), la 4FN y la 5FN, pero para el temario TAI lo habitual es centrarse en 1FN, 2FN y 3FN, que son las que se preguntan con más frecuencia.
¿Qué pasa si una base de datos no está normalizada?
Puede funcionar igualmente, pero es más propensa a datos duplicados, inconsistencias al actualizar información repetida en varias filas, y un diseño más difícil de mantener a medida que crece.
¿Se puede tener una cardinalidad N a M directamente en una tabla relacional?
No de forma directa. Las relaciones N a M del diagrama E-R se traducen, al pasar al modelo relacional, en una tabla intermedia que contiene las claves de ambas entidades relacionadas.