Bases de datos en DAM y DAW: cómo aprobar SQL y el modelo entidad-relación

Respuesta corta: el módulo de Bases de datos de primero de DAM y DAW se aprueba con tres cosas. Saber pasar un enunciado a un diagrama entidad-relación, convertir ese diagrama en tablas con sus claves y escribir consultas SQL con JOIN y GROUP BY sin dudar. Casi todos los suspensos vienen de una de esas tres, y casi siempre de los mismos errores.

Después de Programación, es el módulo que más alumnos nos traen a clase. Lo curioso es que mucha gente lo infravalora en septiembre porque las primeras consultas parecen fáciles. Un SELECT * FROM alumno lo escribe cualquiera. El problema llega cuando la consulta necesita tres tablas, una agrupación y un filtro sobre la media.

Qué entra en el módulo de Bases de datos

El temario es bastante parecido en todas las comunidades. El gestor cambia según el centro (MySQL, MariaDB, Oracle o PostgreSQL), pero la materia es la misma:

Bloque	Qué te piden	Dónde se atasca la gente
Diseño conceptual	Diagrama entidad-relación a partir de un enunciado	Decidir si algo es entidad, atributo o relación, y las cardinalidades
Modelo relacional	Pasar el diagrama a tablas con claves primarias y foráneas	Relaciones N:M y dónde va cada clave foránea
Normalización	Comprobar 1FN, 2FN y 3FN	Detectar dependencias parciales y transitivas
SQL DDL	CREATE TABLE, restricciones, ALTER TABLE	Orden de creación de tablas con claves foráneas
SQL DML	SELECT, INSERT, UPDATE, DELETE	JOIN, GROUP BY, HAVING y subconsultas
Programación en BD	Procedimientos, funciones, disparadores (triggers)	Sintaxis propia de cada gestor y cursores

El examen suele tener dos partes: una de diseño (te dan un enunciado y haces el diagrama y las tablas) y otra de consultas. La de consultas es la que más puntúa en muchos centros y la que más se puede entrenar.

El diseño: del enunciado a las tablas

Lee el enunciado buscando sustantivos y verbos

Un truco sencillo que funciona: los sustantivos importantes suelen ser entidades (alumno, módulo, profesor), sus características son atributos (nombre, horas, email) y los verbos que los conectan son relaciones (un alumno se matricula en un módulo).

Luego, para cada relación, hazte la pregunta en las dos direcciones: ¿un alumno puede matricularse en varios módulos? Sí. ¿Un módulo puede tener varios alumnos? Sí. Entonces es N:M.

Las tres reglas para pasar a tablas

Casi todo el paso a modelo relacional se resuelve con estas reglas:

• Relación 1:N: la clave primaria del lado "1" pasa como clave foránea a la tabla del lado "N". Un ciclo tiene muchos alumnos, así que alumno lleva ciclo_id.
• Relación N:M: se crea una tabla nueva cuya clave primaria es la combinación de las dos claves. Si la relación tiene atributos propios (como la nota), van en esa tabla.
• Relación 1:1: la clave foránea va en cualquiera de las dos tablas, con restricción UNIQUE. Normalmente en la que es opcional.

Con el ejemplo de alumnos y módulos quedaría así:

CREATE TABLE alumno (
  id     INT PRIMARY KEY,
  nombre VARCHAR(100) NOT NULL,
  ciclo  VARCHAR(10)
);

CREATE TABLE modulo (
  id     INT PRIMARY KEY,
  nombre VARCHAR(100) NOT NULL,
  horas  INT
);

CREATE TABLE matricula (
  alumno_id INT,
  modulo_id INT,
  nota      DECIMAL(4,2),
  PRIMARY KEY (alumno_id, modulo_id),
  FOREIGN KEY (alumno_id) REFERENCES alumno(id),
  FOREIGN KEY (modulo_id) REFERENCES modulo(id)
);

Fíjate en el orden: matricula se crea al final porque hace referencia a las otras dos. Si la creas primero, el gestor te dará error. Es un fallo tonto que cuesta puntos en el examen.

Las consultas: un método para no quedarte en blanco

Cuando te dan un enunciado tipo "muestra el nombre de cada alumno con su nota media, solo los que tienen media de aprobado, ordenados de mayor a menor", no empieces escribiendo SELECT. Hazte estas preguntas en este orden:

1. ¿De qué tablas salen los datos? Nombre está en alumno, nota en matricula. Necesito las dos.
2. ¿Cómo se unen? matricula.alumno_id = alumno.id.
3. ¿Hay que filtrar filas sueltas? No, el filtro es sobre la media. Eso no va en WHERE.
4. ¿Hay que agrupar? Sí, "por cada alumno". GROUP BY por alumno.
5. ¿Hay que filtrar grupos? Sí, media de 5 o más. Eso va en HAVING.
6. ¿Qué columnas salen y en qué orden? Nombre y media, de mayor a menor.

Y ahora sí, escribes:

SELECT a.nombre, AVG(m.nota) AS media
FROM alumno a
JOIN matricula m ON m.alumno_id = a.id
GROUP BY a.id, a.nombre
HAVING AVG(m.nota) >= 5
ORDER BY media DESC;

Este orden de preguntas no es casual. Es el orden en que el gestor ejecuta la consulta por dentro: primero FROM y JOIN, luego WHERE, luego GROUP BY, luego HAVING, luego SELECT y al final ORDER BY. Cuando lo entiendes, muchos errores dejan de parecer arbitrarios.

Los errores de SQL que más suspenden

Poner en el SELECT columnas que no están en el GROUP BY

-- Mal: ¿qué módulo enseña si hay varios por alumno?
SELECT a.nombre, m.modulo_id, AVG(m.nota)
FROM alumno a JOIN matricula m ON m.alumno_id = a.id
GROUP BY a.nombre;

Cuando agrupas, cada grupo se convierte en una sola fila. Cualquier columna que muestres tiene que estar en el GROUP BY o dentro de una función de agregado (COUNT, SUM, AVG, MAX, MIN). Oracle y PostgreSQL te dan error. MySQL, según cómo esté configurado, puede ejecutarlo y devolver un valor cualquiera, que es peor porque no te enteras.

Filtrar agregados con WHERE

WHERE AVG(nota) >= 5 da error. WHERE filtra filas antes de agrupar, cuando la media todavía no existe. Los filtros sobre COUNT, AVG y compañía van en HAVING.

Usar JOIN cuando necesitas LEFT JOIN

"Muestra todos los alumnos con el número de módulos en que están matriculados." Si usas JOIN, los alumnos sin ninguna matrícula desaparecen del resultado. Cuando el enunciado dice "todos", "incluidos los que no tienen" o "aunque no tengan", piensa en LEFT JOIN:

SELECT a.nombre, COUNT(m.modulo_id) AS num_modulos
FROM alumno a
LEFT JOIN matricula m ON m.alumno_id = a.id
GROUP BY a.id, a.nombre;

Y fíjate en el COUNT(m.modulo_id). Con COUNT(*) los alumnos sin matrícula saldrían con 1 en vez de con 0, porque COUNT(*) cuenta filas y LEFT JOIN genera una fila con valores nulos para ellos.

Comparar con NULL usando el igual

WHERE nota = NULL nunca devuelve nada. NULL significa "desconocido" y cualquier comparación con él da desconocido, no verdadero. Se escribe WHERE nota IS NULL o IS NOT NULL. Con esto puedes sacar, por ejemplo, los alumnos que no tienen ninguna matrícula:

SELECT a.nombre
FROM alumno a
LEFT JOIN matricula m ON m.alumno_id = a.id
WHERE m.alumno_id IS NULL;

Olvidar la condición del JOIN

Si unes dos tablas sin ON (o con la sintaxis antigua de comas sin WHERE), obtienes todas las combinaciones posibles. Con 30 alumnos y 200 matrículas salen 6.000 filas. Si el resultado tiene muchas más filas de las que esperabas, revisa esto lo primero.

Cómo practicar para el examen

Monta la base de datos en tu ordenador

Practicar SQL en papel está bien para el último repaso, pero para aprender necesitas ver el resultado. Instala el mismo gestor que usáis en clase, crea las tablas de los ejercicios y mete unos pocos datos a mano, incluyendo casos raros: un alumno sin matrículas, una nota nula, dos alumnos con el mismo nombre.

Predice el resultado antes de ejecutar

Antes de darle a ejecutar, escribe cuántas filas crees que va a devolver y cuáles. Si no coincide, ahí hay algo que no has entendido. Este hábito te prepara para el examen en papel mejor que nada.

Construye las consultas por capas

No escribas la consulta entera de golpe. Primero el FROM con los JOIN y un SELECT * para ver que las filas cuadran. Luego añade el WHERE. Luego agrupa. Luego el HAVING. Si algo falla, sabrás en qué capa ha sido. Es la misma idea que explicamos en cómo depurar código paso a paso, aplicada a SQL.

Haz exámenes de otros años con reloj

En el examen no hay autocompletado ni tiempo para probar diez veces. Haz los de otros años en el tiempo real y sin ejecutar hasta el final. Tienes más ideas para este formato en cómo preparar un examen práctico de programación.

Por qué Bases de datos importa más de lo que parece

En segundo, el módulo de acceso a datos en DAM y el de programación en servidor en DAW dan por hecho que sabes SQL. Vas a lanzar consultas desde Java, PHP o Node, y si la consulta está mal, el fallo parecerá del programa cuando en realidad es de la base de datos. Lo mismo en el proyecto final: casi todos tienen una base de datos detrás, y un mal diseño en las tablas se paga durante meses. Si ya estás pensando en el tuyo, aquí tienes ideas de proyecto final para DAM y DAW.

Y fuera de clase, SQL es de las pocas cosas que vas a usar en casi cualquier trabajo de desarrollo, sea cual sea el lenguaje.

Cuándo merece la pena pedir ayuda

Si haces los ejercicios, los resultados te cuadran y entiendes por qué, vas bien. Conviene buscar ayuda cuando:

• Los diagramas entidad-relación te salen distintos a los del profesor y no entiendes por qué.
• Las consultas con una tabla te salen, pero con dos o tres te pierdes.
• Te sale el resultado correcto "a base de probar" y no sabrías repetirlo.
• Tienes la recuperación cerca y no sabes por qué bloque empezar.

En nuestras clases particulares de SQL y bases de datos trabajamos con tus enunciados y con el gestor que uséis en clase, y te dejamos ejercicios para comprobar que ya te salen solo. Si además Programación también se te está atragantando, lo vemos todo junto en las clases para DAM y DAW. Son online, uno a uno, a 25 € la hora y sin matrícula ni permanencia.

Preguntas frecuentes

¿Es difícil el módulo de Bases de datos de DAM?

Suele costar menos que Programación, pero tiene trampa: la primera parte parece fácil y mucha gente se confía. Donde más se suspende es en el diseño entidad-relación y en las consultas con varias tablas y agrupaciones. Si te preocupa el curso en general, te interesa leer qué cuesta de verdad en primero de DAM.

¿Qué gestor de bases de datos se usa en DAM y DAW?

Depende del centro. Los más habituales son MySQL o MariaDB y Oracle; algunos usan PostgreSQL. El SQL básico es casi igual en todos. Las diferencias aparecen sobre todo en tipos de datos, funciones de fechas y en la parte de procedimientos y triggers, así que practica con el mismo gestor que uséis en clase.

¿Cuál es la diferencia entre WHERE y HAVING?

WHERE filtra filas individuales antes de agrupar. HAVING filtra los grupos después de agrupar, y por eso es el único sitio donde puedes poner condiciones sobre COUNT, SUM o AVG. Si no hay GROUP BY en la consulta, casi seguro que lo que necesitas es WHERE.

¿Cuándo uso JOIN y cuándo LEFT JOIN?

JOIN solo devuelve las filas que tienen pareja en las dos tablas. LEFT JOIN devuelve todas las filas de la tabla de la izquierda, tengan pareja o no, y rellena con NULL lo que falta. Si el enunciado dice "todos", "aunque no tengan" o pregunta por los que "no tienen", es LEFT JOIN.

¿Cómo practico SQL si no tengo ejercicios?

Coge cualquier base de datos de ejemplo de clase y plantéate preguntas tú: ¿qué alumno tiene la nota más alta en cada módulo?, ¿qué módulos no tienen ningún aprobado?, ¿cuántos alumnos hay por ciclo? Escribir la pregunta en castellano y luego traducirla a SQL es exactamente lo que te piden en el examen.