Módulo 5: Consultas multitabla y resolución avanzada con SQL

Una base relacional evita repetir información. El nombre de una carrera se guarda una vez, el curso se describe una vez y cada matrícula conecta a un estudiante con un curso.

Esa organización protege los datos, pero crea una necesidad: para responder preguntas reales debes volver a reunir las piezas correctas.

¿Qué estudiante cursa qué materia, con cuál docente y qué nota obtuvo?

estudiantes → matriculas → cursos → docentes
                    ↓
             calificaciones

En este módulo aprenderás a recorrer relaciones, conservar registros sin coincidencia, detectar multiplicaciones inesperadas y dividir consultas complejas en etapas comprensibles.

También aprenderás que JOIN, una subconsulta y una CTE no son premios por escribir SQL “avanzado”. Son herramientas diferentes. La mejor elección es la que expresa con claridad la pregunta y produce un resultado comprobable.

Principio del módulo: antes de unir tablas, dibuja el camino entre sus claves y predice qué representa cada fila del resultado.

Debes haber aprobado los módulos 1 a 4. Necesitarás poder:

• Reconocer claves primarias y foráneas.
• Interpretar relaciones uno a muchos y muchos a muchos.
• Seleccionar, filtrar y ordenar filas.
• Utilizar NULL correctamente.
• Crear expresiones y clasificaciones con CASE.
• Aplicar funciones de agregación.
• Diferenciar WHERE de HAVING.
• Leer un diagrama relacional sencillo.

No se estudiarán índices, planes de ejecución, vistas ni optimización avanzada. Esos temas pertenecen al módulo 6.

Al completar el módulo serás capaz de:

• Trazar el recorrido de claves necesario para responder una pregunta.
• Predecir la granularidad y una cantidad razonable de filas.
• Explicar y evitar un producto cartesiano accidental.
• Combinar coincidencias mediante INNER JOIN.
• Conservar filas sin coincidencia mediante LEFT JOIN.
• Utilizar CROSS JOIN solamente cuando todas las combinaciones sean intencionales.
• Comprender RIGHT JOIN y FULL OUTER JOIN y reconocer diferencias entre motores.
• Resolver nombres de columnas mediante alias de tablas.
• Unir tres o más tablas de forma legible.
• Recorrer una relación muchos a muchos mediante su tabla intermedia.
• Relacionar una tabla consigo misma mediante una autounión.
• Distinguir filtros colocados en ON de filtros colocados en WHERE.
• Escribir subconsultas escalares, de lista y correlacionadas.
• Utilizar IN, EXISTS y NOT EXISTS con seguridad.
• Evitar el problema de NOT IN cuando una subconsulta contiene NULL.
• Organizar consultas mediante CTE ordinarias con WITH.
• Combinar resultados compatibles con UNION y UNION ALL.
• Elegir entre unión, subconsulta y CTE según la necesidad.
• Detectar duplicados causados por una cardinalidad mal comprendida.
• Comprobar que una consulta conserva exactamente las entidades solicitadas.

El proyecto obligatorio será un sistema de reportes universitarios:

carreras 1 ─────< estudiantes 1 ─────< matriculas >───── 1 cursos
                                      │                     │
                                      │                     └──── 0..1 docentes
                                      │                                │
                                      └──── 0..1 calificaciones        └── supervisor

Construirás reportes sobre:

• Estudiantes y carreras.
• Cursos y docentes.
• Matrículas y calificaciones.
• Entidades que todavía no tienen registros relacionados.
• Relaciones muchos a muchos.
• Promedios generales y por curso.
• Personas por encima del promedio.
• Existencia y ausencia de matrículas.
• Directorios combinados.
• Resultados organizados por etapas mediante CTE.

Los ejercicios adicionales de profundización son opcionales. Prioriza las prácticas guiadas, el mini proyecto, las actividades marcadas como esenciales y el proyecto obligatorio.

Pensar en caminos, no en tablas aisladas

Pregunta:

¿En qué carrera está inscrita cada persona estudiante?

Camino:

estudiantes.carrera_id → carreras.id

Pregunta:

¿Qué cursos matriculó cada estudiante?

Camino:

estudiantes.id
    ↓ matriculas.estudiante_id
matriculas.curso_id
    ↓ cursos.id
cursos

La tabla intermedia no es un obstáculo. Representa el hecho real de que muchos estudiantes pueden matricular muchos cursos.

Antes de escribir SQL, completa:

Si un estudiante posee tres matrículas, una unión con matriculas producirá tres filas para esa persona. Eso no es necesariamente un duplicado incorrecto: cada fila representa una matrícula distinta.

Antes: una fila por estudiante
Después: una fila por matrícula

Solo puedes decidir si una repetición es incorrecta después de definir qué representa cada fila.

Producto cartesiano: todas las combinaciones

Si una tabla contiene 4 estudiantes y otra 3 cursos, combinarlas sin condición produce:

4 × 3 = 12 combinaciones

Consulta peligrosa:

SELECT e.nombre, c.nombre
FROM estudiantes AS e, cursos AS c;

También es accidental omitir ON:

SELECT e.nombre, c.nombre
FROM estudiantes AS e
JOIN cursos AS c;

Una clave foránea no hace que SQLite adivine la unión. Debes expresarla.

• La cantidad de filas crece de forma desproporcionada.
• Aparecen combinaciones imposibles.
• Un total se multiplica.
• Cada elemento de una tabla aparece con todos los de la otra.

CROSS JOIN expresa que sí deseas todas las combinaciones:

SELECT t.nombre AS turno, a.nombre AS aula
FROM turnos AS t
CROSS JOIN aulas AS a;

Puede servir para crear una matriz de turnos y aulas, tallas y colores, o escenarios que después se evaluarán. Si no puedes explicar por qué necesitas N × M filas, probablemente no necesitas un CROSS JOIN.

INNER JOIN: conservar coincidencias

SELECT
    e.carnet,
    e.nombre AS estudiante,
    c.nombre AS carrera
FROM estudiantes AS e
INNER JOIN carreras AS c
    ON c.id = e.carrera_id
ORDER BY e.nombre;

INNER JOIN conserva filas que cumplen la condición de ON en ambos lados.

estudiantes       coincidencia       carreras
     A  ───────── carrera_id = id ───── X
     B  ───────── carrera_id = id ───── Y

Si no existe coincidencia, la fila no aparece. Una clave foránea obligatoria normalmente garantiza coincidencia, pero la técnica también se utiliza cuando la relación es opcional.

En este contexto:

FROM estudiantes AS e
JOIN carreras AS c ON c.id = e.carrera_id

equivale a escribir INNER JOIN. Utilizar la palabra INNER puede ser útil al comenzar porque hace explícita la intención.

Regla correcta:

ON c.id = e.carrera_id

Error común:

ON c.id = e.id

Que dos columnas compartan valores numéricos no significa que estén relacionadas. Sigue la clave foránea, no la coincidencia visual.

Alias de tablas y columnas ambiguas

Varias tablas contienen una columna id o nombre. Esta consulta es ambigua:

SELECT id, nombre
FROM estudiantes
JOIN carreras ON carreras.id = estudiantes.carrera_id;

Utiliza alias breves y consistentes:

SELECT
    e.id AS estudiante_id,
    e.nombre AS estudiante,
    c.nombre AS carrera
FROM estudiantes AS e
INNER JOIN carreras AS c
    ON c.id = e.carrera_id;

Un buen alias recuerda la tabla:

No uses letras que cambien de significado dentro del mismo script.

LEFT JOIN: conservar el lado izquierdo

Pregunta:

Mostrar todos los cursos, aunque todavía no tengan docente.

SELECT
    cu.codigo,
    cu.nombre AS curso,
    COALESCE(d.nombre, 'Sin asignar') AS docente
FROM cursos AS cu
LEFT JOIN docentes AS d
    ON d.id = cu.docente_id
ORDER BY cu.codigo;

Todos los cursos se conservan porque están a la izquierda. Cuando no hay docente, las columnas de d contienen NULL.

cursos (se conservan todos)
    ├── coincide con docente → datos del docente
    └── no coincide          → NULL en columnas del docente

Cursos sin matrícula:

SELECT cu.codigo, cu.nombre
FROM cursos AS cu
LEFT JOIN matriculas AS m
    ON m.curso_id = cu.id
WHERE m.id IS NULL;

Este patrón significa:

1. Conserva todos los cursos.
2. Intenta encontrar matrículas.
3. Quédate con aquellos donde la tabla derecha no produjo una fila.

SELECT
    cu.codigo,
    cu.nombre,
    COUNT(m.id) AS matriculas
FROM cursos AS cu
LEFT JOIN matriculas AS m
    ON m.curso_id = cu.id
GROUP BY cu.id, cu.codigo, cu.nombre;

Utiliza COUNT(m.id), no COUNT(*). Un curso sin matrícula todavía produce una fila extendida con valores NULL; COUNT(*) la contaría como uno. COUNT(m.id) devuelve cero porque ignora el valor nulo del lado derecho.

ON y WHERE no siempre son intercambiables

Pregunta:

Mostrar todos los estudiantes y, si poseen una matrícula activa en 2026-I, mostrarla.

Versión que conserva a todos:

SELECT
    e.carnet,
    e.nombre,
    m.id AS matricula_id
FROM estudiantes AS e
LEFT JOIN matriculas AS m
    ON m.estudiante_id = e.id
   AND m.periodo = '2026-I'
   AND m.estado = 'Activa'
ORDER BY e.nombre;

Las condiciones dentro de ON deciden qué filas de matriculas cuentan como coincidencia. Quienes no poseen esa coincidencia siguen apareciendo con NULL.

Versión que elimina a quienes no coinciden:

SELECT
    e.carnet,
    e.nombre,
    m.id AS matricula_id
FROM estudiantes AS e
LEFT JOIN matriculas AS m
    ON m.estudiante_id = e.id
WHERE m.periodo = '2026-I'
  AND m.estado = 'Activa';

WHERE se aplica después de construir la unión. Las filas sin matrícula poseen m.periodo = NULL; no cumplen la condición y desaparecen. En la práctica, esa parte de la consulta se comporta como una unión interna.

En una unión externa, coloca en ON los filtros del lado opcional cuando quieras conservar las filas principales sin coincidencia.

Unir tres o más tablas

SELECT
    e.carnet,
    e.nombre AS estudiante,
    cu.codigo AS codigo_curso,
    cu.nombre AS curso,
    m.periodo,
    m.estado
FROM matriculas AS m
INNER JOIN estudiantes AS e
    ON e.id = m.estudiante_id
INNER JOIN cursos AS cu
    ON cu.id = m.curso_id
ORDER BY e.nombre, cu.nombre;

La entidad que define la granularidad es matriculas: cada fila representa una matrícula.

SELECT
    e.nombre AS estudiante,
    cu.nombre AS curso,
    COALESCE(d.nombre, 'Sin docente') AS docente,
    m.periodo,
    m.estado AS estado_matricula,
    cl.nota
FROM matriculas AS m
INNER JOIN estudiantes AS e
    ON e.id = m.estudiante_id
INNER JOIN cursos AS cu
    ON cu.id = m.curso_id
LEFT JOIN docentes AS d
    ON d.id = cu.docente_id
LEFT JOIN calificaciones AS cl
    ON cl.matricula_id = m.id
ORDER BY e.nombre, cu.nombre;

Los primeros INNER JOIN exigen estudiante y curso, pues las claves son obligatorias. Los LEFT JOIN conservan matrículas aunque el curso no tenga docente o la nota todavía no exista.

Promedio por curso, conservando cursos sin notas:

SELECT
    cu.codigo,
    cu.nombre,
    COUNT(cl.id) AS notas_registradas,
    ROUND(AVG(cl.nota), 2) AS promedio
FROM cursos AS cu
LEFT JOIN matriculas AS m
    ON m.curso_id = cu.id
LEFT JOIN calificaciones AS cl
    ON cl.matricula_id = m.id
GROUP BY cu.id, cu.codigo, cu.nombre
ORDER BY promedio DESC, cu.nombre;

Antes de sumar o promediar, comprueba que una fila de calificación no se haya multiplicado por otra relación uno a muchos añadida innecesariamente.

Relaciones muchos a muchos

Estudiantes y cursos tienen una relación muchos a muchos:

estudiantes 1 ─────< matriculas >───── 1 cursos

matriculas contiene datos propios de la relación: período, estado y fecha.

Lista de estudiantes por curso:

SELECT
    cu.codigo,
    cu.nombre AS curso,
    e.carnet,
    e.nombre AS estudiante,
    m.periodo,
    m.estado
FROM cursos AS cu
INNER JOIN matriculas AS m
    ON m.curso_id = cu.id
INNER JOIN estudiantes AS e
    ON e.id = m.estudiante_id
ORDER BY cu.codigo, e.nombre;

No unas directamente estudiantes con cursos: no existe una clave que describa esa relación sin pasar por la matrícula.

Autounión: una tabla se relaciona consigo misma

docentes.supervisor_id apunta a docentes.id.

docente ── supervisor_id ──> otro docente

La misma tabla participa con dos papeles:

SELECT
    d.nombre AS docente,
    d.especialidad,
    COALESCE(s.nombre, 'Sin supervisor') AS supervisor
FROM docentes AS d
LEFT JOIN docentes AS s
    ON s.id = d.supervisor_id
ORDER BY d.nombre;

Los alias d y s no representan tablas diferentes. Representan dos funciones dentro de la misma relación.

Otros tipos de unión

Conserva todas las filas del lado derecho. Una consulta puede reescribirse normalmente como LEFT JOIN intercambiando los lados:

-- Conserva todos los cursos
SELECT d.nombre, cu.nombre
FROM docentes AS d
RIGHT JOIN cursos AS cu
    ON cu.docente_id = d.id;

-- Mismo propósito expresado con LEFT JOIN
SELECT d.nombre, cu.nombre
FROM cursos AS cu
LEFT JOIN docentes AS d
    ON d.id = cu.docente_id;

Las versiones modernas de SQLite admiten RIGHT JOIN, pero LEFT JOIN continúa siendo más reconocible y fácil de adaptar a entornos antiguos.

Conserva coincidencias, filas sin pareja del lado izquierdo y filas sin pareja del lado derecho. SQLite moderno lo admite, pero otros entornos o versiones antiguas pueden requerir una combinación alternativa.

En este módulo debes comprender qué filas conserva. No es necesario utilizarlo en el proyecto.

NATURAL JOIN decide automáticamente qué columnas con el mismo nombre debe comparar. Un nuevo campo compartido puede cambiar el resultado sin modificar la consulta. Para aprendizaje profesional, utiliza JOIN ... ON y expresa las claves.

Subconsultas

Una subconsulta es un SELECT dentro de otra instrucción.

Devuelve un solo valor. Estudiantes con nota superior al promedio general:

SELECT
    e.nombre AS estudiante,
    cu.nombre AS curso,
    cl.nota
FROM calificaciones AS cl
INNER JOIN matriculas AS m
    ON m.id = cl.matricula_id
INNER JOIN estudiantes AS e
    ON e.id = m.estudiante_id
INNER JOIN cursos AS cu
    ON cu.id = m.curso_id
WHERE cl.nota > (
    SELECT AVG(nota)
    FROM calificaciones
)
ORDER BY cl.nota DESC, e.nombre;

Si una subconsulta escalar devuelve varias filas, la intención es ambigua y otros motores pueden generar un error. Diseña la consulta para producir exactamente un valor.

Estudiantes que poseen alguna matrícula en 2026-I:

SELECT carnet, nombre
FROM estudiantes
WHERE id IN (
    SELECT estudiante_id
    FROM matriculas
    WHERE periodo = '2026-I'
)
ORDER BY nombre;

IN es expresivo cuando la pregunta es “pertenece a este conjunto”. Si además necesitas columnas de la tabla interna, utiliza un JOIN.

La subconsulta utiliza una fila de la consulta externa:

SELECT
    cu.codigo,
    cu.nombre
FROM cursos AS cu
WHERE (
    SELECT COUNT(*)
    FROM matriculas AS m
    WHERE m.curso_id = cu.id
) >= 3
ORDER BY cu.codigo;

Conceptualmente, la subconsulta se relaciona con cada curso mediante m.curso_id = cu.id. Para conteos y reportes completos, una agrupación puede ser más clara. La correlación es especialmente útil con EXISTS.

EXISTS, NOT EXISTS y la trampa de NOT IN

Comprueba si la subconsulta produce al menos una fila:

SELECT e.carnet, e.nombre
FROM estudiantes AS e
WHERE EXISTS (
    SELECT 1
    FROM matriculas AS m
    WHERE m.estudiante_id = e.id
      AND m.estado = 'Activa'
)
ORDER BY e.nombre;

SELECT 1 comunica que solo importa la existencia, no las columnas internas.

Estudiantes sin ninguna matrícula:

SELECT e.carnet, e.nombre
FROM estudiantes AS e
WHERE NOT EXISTS (
    SELECT 1
    FROM matriculas AS m
    WHERE m.estudiante_id = e.id
)
ORDER BY e.nombre;

Este patrón expresa ausencia sin depender de cómo se traten los valores nulos en una lista.

Si la subconsulta utilizada por NOT IN devuelve al menos un NULL, el resultado puede volverse desconocido para todas las filas:

WHERE id NOT IN (1, 2, NULL)

No puede afirmarse que un valor sea distinto de una identidad desconocida. Para antirrelaciones, prefiere NOT EXISTS.

CTE ordinarias con WITH

Una expresión común de tabla asigna un nombre temporal al resultado de una consulta durante una sola instrucción.

WITH promedios_curso AS (
    SELECT
        cu.id AS curso_id,
        cu.codigo,
        cu.nombre AS curso,
        COUNT(cl.id) AS notas,
        AVG(cl.nota) AS promedio
    FROM cursos AS cu
    LEFT JOIN matriculas AS m
        ON m.curso_id = cu.id
    LEFT JOIN calificaciones AS cl
        ON cl.matricula_id = m.id
    GROUP BY cu.id, cu.codigo, cu.nombre
)
SELECT
    codigo,
    curso,
    notas,
    ROUND(promedio, 2) AS promedio
FROM promedios_curso
WHERE notas >= 2
  AND promedio >= 85
ORDER BY promedio DESC, curso;

WITH construye un resultado intermedio con nombre
        ↓
SELECT final lo consulta como si fuera una tabla temporal

La CTE no queda almacenada y no sustituye una vista permanente. En este módulo utilizarás CTE ordinarias para mejorar claridad. Las CTE recursivas quedan fuera del alcance.

• La consulta posee una etapa lógica con nombre propio.
• Un cálculo largo se utilizará en el resultado final.
• Una subconsulta anidada resulta difícil de leer.
• Necesitas revisar el resultado intermedio por separado.

No crees una CTE que solamente esconda una consulta de dos líneas sin mejorar su significado.

UNION y UNION ALL

Estas operaciones apilan resultados verticalmente. No relacionan columnas mediante claves.

Directorio de estudiantes y docentes:

SELECT
    nombre,
    correo,
    'Estudiante' AS tipo_persona
FROM estudiantes

UNION ALL

SELECT
    nombre,
    correo,
    'Docente' AS tipo_persona
FROM docentes
ORDER BY nombre;

Reglas:

• Cada SELECT debe devolver la misma cantidad de columnas.
• Las columnas en la misma posición deben tener significados y tipos compatibles.
• Los encabezados finales proceden del primer SELECT.
• ORDER BY se coloca al final del conjunto completo.

UNION elimina filas duplicadas. UNION ALL las conserva. Utiliza UNION ALL cuando cada fila debe mantenerse o cuando ya sabes que no hay duplicados. No elimines datos solo para que el resultado “se vea limpio”.

JOIN        → añade columnas siguiendo una relación
UNION ALL   → añade filas de resultados compatibles

Elegir la herramienta adecuada

Dos soluciones pueden ser correctas. Elige la que haga más evidente:

• Qué entidades se conservan.
• Qué claves se recorren.
• Qué representa cada fila.
• Dónde se aplican los filtros.
• Cómo comprobar el resultado.

Método de verificación de una consulta multitabla

1. Dibuja el camino de claves. No comiences por la sintaxis.
2. Define la fila final. Persona, matrícula, curso, carrera u otra unidad.
3. Predice coincidencias. Cero, una o muchas por cada paso.
4. Elige qué debe conservarse. Esa entidad suele quedar a la izquierda de un LEFT JOIN.
5. Une una tabla cada vez. Ejecuta y cuenta filas después de cada paso.
6. Añade columnas explícitas. Evita SELECT *.
7. Aplica filtros conscientemente. Revisa ON frente a WHERE.
8. Agrega al final. Comprueba que ninguna medida se multiplicó.
9. Busca casos sin coincidencia. Deben aparecer o desaparecer según la pregunta.
10. Explica una fila. Señala de qué registro procede cada valor.

Si una unión genera repeticiones inesperadas, no añadas DISTINCT de inmediato. Primero pregunta:

• ¿La relación es uno a muchos?
• ¿Cada fila representa una matrícula diferente?
• ¿Se añadió una tabla innecesaria?
• ¿Falta una parte de la condición de unión?

DISTINCT puede ocultar el síntoma sin corregir la causa.

Errores comunes

ON e.id = cu.id

Corrección: recorrer matriculas y sus dos claves foráneas.

Produce todas las combinaciones. Escribe la condición de clave de manera explícita.

Filtrar una columna opcional en WHERE elimina sus filas NULL. Coloca la condición en ON si necesitas conservar el lado izquierdo.

Para contar coincidencias reales del lado derecho, utiliza una columna no nula de esa tabla: COUNT(m.id).

Unir dos relaciones uno a muchos puede combinar cada detalle con cada otro detalle. Comprueba conteos antes de sumar.

Cada matrícula puede ser legítimamente una fila. Define la granularidad antes de eliminar resultados.

Si la pregunta contiene “todos, incluso quienes no...”, considera LEFT JOIN o NOT EXISTS.

Prefiere NOT EXISTS para expresar ausencia.

Una comparación con = necesita un solo valor. Agrega, filtra o utiliza IN, según la pregunta.

UNION requiere la misma cantidad de columnas y significados compatibles en la misma posición.

Para ordenar el resultado compuesto, coloca ORDER BY al final.

Una CTE debe nombrar una etapa útil. Más niveles no significan mejor SQL.

Buenas prácticas

1. Dibuja las claves antes de escribir el JOIN.
2. Comienza desde la entidad que define la granularidad.
3. Utiliza alias cortos y consistentes.
4. Califica las columnas: e.nombre, cu.nombre.
5. Escribe cada JOIN en un bloque separado.
6. Usa ON para expresar relaciones y filtros del lado opcional.
7. Conserva en WHERE los filtros del resultado completo.
8. Cuenta claves del lado derecho después de LEFT JOIN.
9. Prueba cada unión de forma incremental.
10. Compara el conteo antes y después de añadir una tabla.
11. Prefiere NOT EXISTS para encontrar ausencia.
12. Utiliza CTE para nombrar etapas, no para impresionar.
13. Usa UNION ALL si no necesitas eliminar duplicados.
14. Evita NATURAL JOIN y uniones con comas.
15. No dependas de extensiones extrañas aceptadas por SQLite.
16. Revisa el comportamiento en el motor de destino.
17. Documenta qué representa cada fila del reporte.
18. Explica por qué elegiste cada técnica.

Videos recomendados

Tema exacto: conservación de coincidencias y filas sin pareja en consultas multitabla. Momento recomendado: después de las secciones 3 a 6. Objetivo: reforzar visualmente qué lado conserva cada unión. Nota: el curso utiliza principalmente LEFT JOIN porque permite colocar a la izquierda la entidad que debe conservarse.

Tema exacto: consultas dentro de otras consultas. Momento recomendado: antes de las prácticas 4 y 5. Objetivo: reconocer cuándo una consulta interior produce un valor, una lista o una comprobación de existencia.

Los videos complementan la práctica. Si un ejemplo utiliza otro motor, conserva el concepto y comprueba la sintaxis en la documentación de SQLite.

Documentación y recursos confiables

• 📖`SELECT`, cláusula `FROM` y uniones — documentación oficial de SQLite

Busca FROM clause processing, LEFT JOIN, RIGHT JOIN, FULL JOIN, WHERE y compound SELECT.

• 📖Expresiones y subconsultas — documentación oficial de SQLite

Busca subquery expressions, IN, EXISTS y NOT IN.

• 📖Cláusula `WITH` y CTE — documentación oficial de SQLite

Concéntrate en ordinary common table expressions. Las CTE recursivas no son necesarias en este módulo.

• 📖Sintaxis de cláusulas de unión — documentación oficial de SQLite

Úsala como referencia rápida de JOIN, ON y USING.

• 📖Expresiones de tabla y uniones — documentación oficial de PostgreSQL

Compara uniones calificadas, externas y cruzadas. La lógica relacional se transfiere aunque existan diferencias de sintaxis o versión.

1. Lee primero el procesamiento de FROM en SQLite.
2. Revisa qué filas añade una unión externa.
3. Observa por qué WHERE se aplica después de ON.
4. Busca la forma de EXISTS.
5. Lee la introducción a CTE ordinarias.
6. Consulta las operaciones compuestas UNION y UNION ALL.

Portabilidad entre motores

Los conceptos del módulo funcionan en SQLite, MySQL, PostgreSQL, SQL Server, MariaDB y Oracle, pero existen diferencias que debes comprobar.

Reglas para escribir SQL adaptable:

• Utiliza sintaxis estándar y explícita.
• Prefiere LEFT JOIN sobre invertir mentalmente un RIGHT JOIN.
• Evita combinaciones de palabras de unión no estándar que SQLite pueda aceptar.
• No mezcles uniones con comas y uniones con JOIN.
• Documenta las funciones o construcciones específicas del motor.
• Prueba la consulta en el motor final antes de utilizarla en producción.

Material complementario

Este módulo requiere un solo archivo descargable:

⬇️`datos_universidad_m05.sql`

El archivo contiene la estructura y los datos del proyecto. El mapa de relaciones, la guía de recorridos, los esquemas de tipos de unión y las listas de comprobación ya están integrados en el contenido; no necesitas PDFs adicionales.

Glosario

Resumen final

En este módulo pasaste de consultar una tabla a reconstruir información distribuida en un modelo relacional.

Pregunta
   ↓
Camino de claves
   ↓
Granularidad
   ↓
Tipo de unión
   ↓
Filtros en ON o WHERE
   ↓
Subconsulta o CTE si aporta claridad
   ↓
Comprobación de filas y medidas

Ahora puedes:

• Evitar productos cartesianos accidentales.
• Combinar coincidencias con INNER JOIN.
• Conservar ausencias con LEFT JOIN.
• Contar coincidencias reales después de una unión externa.
• Recorrer múltiples tablas con alias claros.
• Consultar relaciones muchos a muchos.
• Construir autouniones.
• Proteger el significado de una unión externa al colocar filtros.
• Comparar valores con subconsultas.
• Comprobar existencia y ausencia.
• Organizar consultas mediante CTE ordinarias.
• Apilar resultados con UNION y UNION ALL.
• Detectar repeticiones legítimas e incorrectas.
• Elegir una técnica por claridad y no por complejidad aparente.

Al aprobar el módulo habrás demostrado que puedes:

• Diseñar reportes sobre una base normalizada.
• Explicar de dónde procede cada columna.
• Conservar correctamente entidades sin actividad.
• Evitar conteos y promedios multiplicados por uniones defectuosas.
• Dividir un problema complejo en etapas verificables.
• Adaptar conceptos relacionales a otros motores SQL.
• Revisar y corregir consultas multitabla existentes.

Debes poder responder:

1. ¿Qué representa un producto cartesiano?
2. ¿Cuándo elegirías INNER JOIN y cuándo LEFT JOIN?
3. ¿Por qué COUNT(*) puede ser incorrecto después de LEFT JOIN?
4. ¿Cómo cambia un filtro del lado derecho al moverlo de ON a WHERE?
5. ¿Qué tabla se recorre en una relación muchos a muchos?
6. ¿Por qué una repetición puede ser legítima?
7. ¿Cuándo utilizarías EXISTS en lugar de JOIN?
8. ¿Qué riesgo existe con NOT IN y NULL?
9. ¿Qué problema resuelve una CTE ordinaria?
10. ¿Cuál es la diferencia entre JOIN y UNION ALL?

Si no puedes explicar una unión dibujando sus claves y señalando la granularidad, vuelve a las secciones 1, 5, 6 y 16. Esa explicación será esencial en el diseño, auditoría y optimización del módulo final.

Completa el mini proyecto, aprueba la evaluación y entrega el proyecto obligatorio. Continúa únicamente cuando el módulo aparezca como aprobado.