Módulo 6: SQL profesional y proyecto final integrador

Conocer instrucciones SQL no basta para entregar una solución profesional. Un proyecto real también debe poder reconstruirse, verificarse, mantenerse y explicarse.

En este módulo integrarás todo el curso. Diseñarás un sistema, protegerás sus reglas, cargarás datos de prueba, ejecutarás operaciones seguras y construirás reportes. Además, aprenderás tres herramientas de cierre:

• Vistas, para dar nombre a consultas reutilizables.
• Índices, para facilitar determinadas búsquedas con un costo consciente.
• `EXPLAIN QUERY PLAN`, para observar la estrategia elegida por SQLite.

Problema real
    ↓
Reglas y modelo
    ↓
Esquema con integridad
    ↓
Datos y operaciones seguras
    ↓
Consultas, vista e índice
    ↓
Verificación y documentación
    ↓
Entrega reproducible

Principio del módulo: una solución profesional no solo funciona en tu computadora; otra persona puede reconstruirla, comprobarla y comprender por qué fue diseñada así.

Debes haber aprobado los módulos 1 a 5 y poder:

• Diseñar tablas normalizadas.
• Crear claves, restricciones y relaciones.
• Insertar, actualizar y eliminar datos de forma segura.
• Utilizar transacciones.
• Construir consultas con filtros, funciones y agregaciones.
• Combinar tablas mediante JOIN.
• Utilizar subconsultas, EXISTS, CTE y operaciones de conjuntos.
• Interpretar valores NULL y casos sin coincidencia.

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

• Organizar un proyecto SQL por secciones ejecutables.
• Crear un script que reconstruya una solución desde una base vacía.
• Crear y utilizar vistas.
• Explicar qué problema resuelve un índice.
• Reconocer el costo de mantener índices.
• Elegir columnas razonables para un índice simple o compuesto.
• Evitar índices duplicados o poco útiles.
• Crear y eliminar índices.
• Interpretar SCAN, SEARCH y búsquedas mediante índice.
• Comparar un plan antes y después de un cambio.
• Entender las limitaciones de EXPLAIN QUERY PLAN.
• Explicar consultas parametrizadas e inyección SQL a nivel conceptual.
• Inspeccionar tablas, claves foráneas e índices.
• Verificar la integridad estructural y referencial.
• Preparar un respaldo verificable.
• Identificar diferencias de portabilidad.
• Documentar reglas, decisiones y consultas.
• Auditar una base de datos existente.
• Diseñar y defender un proyecto integrador completo.

Construirás un sistema de gestión hotelera con al menos estas entidades:

tipos_habitacion 1 ───< habitaciones 1 ───< reservaciones >─── 1 huespedes
                                               │
                                               ├────< pagos
                                               │
                                               └────< consumos >──── 1 servicios

El proyecto demostrará:

• Diseño relacional.
• Integridad y reglas de negocio.
• DDL, DML y transacciones.
• Consultas simples y multitabla.
• Agregaciones, subconsultas y CTE.
• Una vista útil.
• Un índice justificado.
• Evidencia del plan de consulta.
• Seguridad conceptual al conectar una aplicación.
• Portabilidad y documentación.

El proyecto final dispone de 150 minutos dentro del curso para construir una primera versión completa. La revisión personal y las correcciones solicitadas pueden requerir tiempo adicional.

Organización profesional de un proyecto SQL

Orden recomendado:

01. Configuración
02. Eliminación segura de objetos anteriores
03. Creación de tablas
04. Creación de índices necesarios
05. Carga de datos
06. Operaciones y transacciones demostrativas
07. Creación de vistas
08. Consultas y reportes
09. Verificaciones finales

En un proyecto pequeño puede utilizarse un solo archivo claramente dividido. En un equipo real suele separarse:

sql/
├── 01_esquema.sql
├── 02_datos_prueba.sql
├── 03_operaciones.sql
├── 04_vistas_indices.sql
├── 05_reportes.sql
└── 06_verificacion.sql

La entrega del curso utilizará un archivo principal para facilitar la revisión, pero deberá conservar estas secciones.

-- ================================================================
-- COA - SQL y Bases de Datos Relacionales
-- Proyecto: Sistema de gestion de hotel
-- Estudiante: Nombre Apellido
-- Version: 1.0
-- Motor: SQLite
-- ================================================================

PRAGMA foreign_keys = ON;

Un script reproducible:

• Se ejecuta en una base vacía.
• Crea los objetos en orden válido.
• Carga datos suficientes.
• No depende de clics o correcciones manuales.
• Termina en un estado conocido.
• Puede volver a probarse en una copia.

Si se incluyen instrucciones DROP, deben respetar dependencias:

Eliminar primero: vistas y tablas hijas
Eliminar al final: tablas padre

Crear primero: tablas padre
Crear al final: tablas hijas

No ejecutes un script destructivo sobre una base con información valiosa. Utiliza una copia de práctica.

Vistas con CREATE VIEW

Una vista guarda la definición de una consulta, no una copia independiente de sus resultados.

CREATE VIEW vista_reservaciones_activas AS
SELECT
    r.id AS reservacion_id,
    h.nombre AS huesped,
    hb.numero AS habitacion,
    r.fecha_entrada,
    r.fecha_salida,
    r.estado
FROM reservaciones AS r
INNER JOIN huespedes AS h
    ON h.id = r.huesped_id
INNER JOIN habitaciones AS hb
    ON hb.id = r.habitacion_id
WHERE r.estado IN ('Confirmada', 'Hospedada');

Después puede consultarse como una tabla:

SELECT huesped, habitacion, fecha_entrada, fecha_salida
FROM vista_reservaciones_activas
ORDER BY fecha_entrada, habitacion;

• Reutiliza una consulta frecuente.
• Oculta complejidad accidental.
• Presenta nombres claros.
• Ofrece una interfaz de lectura estable.
• Puede exponer solo columnas necesarias.

• No garantiza un orden. Utiliza ORDER BY al consultarla.
• No reemplaza restricciones de las tablas.
• No mejora automáticamente el rendimiento.
• No acepta parámetros.
• No guarda resultados de forma materializada en SQLite.

En SQLite, las vistas son de solo lectura de forma predeterminada. Es posible hacerlas modificables con disparadores INSTEAD OF, pero ese tema queda fuera del alcance.

DROP VIEW IF EXISTS vista_reservaciones_activas;

Define nombres de columnas claros dentro de SELECT. Evita SELECT *, pues un cambio en las tablas puede alterar inesperadamente la interfaz de la vista.

Índices: una ruta adicional hacia los datos

Un libro puede leerse página por página para encontrar un concepto. El índice permite localizar una referencia y saltar a la página adecuada.

Sin índice: revisar muchas filas
Con índice: buscar una clave y localizar un subconjunto

Un índice es una estructura adicional mantenida por el motor. Puede acelerar determinadas lecturas, pero consume espacio y debe actualizarse al insertar, modificar o eliminar datos.

SQLite crea estructuras automáticamente para:

• Una clave INTEGER PRIMARY KEY, integrada con el identificador interno.
• Restricciones UNIQUE, mediante índices automáticos cuando son necesarios.

Por eso este índice suele ser redundante:

CREATE TABLE huespedes (
    id INTEGER PRIMARY KEY,
    correo TEXT NOT NULL UNIQUE
);

-- Generalmente innecesario: UNIQUE ya protege y apoya la búsqueda
CREATE INDEX idx_huespedes_correo ON huespedes(correo);

SQLite no crea automáticamente un índice para cada clave foránea hija. Una columna foránea utilizada con frecuencia en uniones puede ser candidata, pero debe justificarse.

CREATE INDEX idx_reservaciones_habitacion_fechas
ON reservaciones (habitacion_id, fecha_entrada, fecha_salida);

Nombre recomendado:

idx_<tabla>_<columnas>

Un índice (habitacion_id, fecha_entrada) ayuda especialmente a consultas que comienzan por:

WHERE habitacion_id = ?
  AND fecha_entrada >= ?

También puede ayudar con habitacion_id por sí solo. Normalmente no equivale a un índice que comience solamente por fecha_entrada. El orden debe reflejar los filtros y órdenes más frecuentes.

• Columnas buscadas frecuentemente con igualdad o rangos selectivos.
• Claves foráneas usadas en uniones frecuentes.
• Combinaciones que apoyan filtro y orden.
• Columnas utilizadas para localizar pocas filas dentro de muchas.

• La tabla es muy pequeña.
• La consulta recupera gran parte de las filas.
• La columna posee muy pocos valores distintos, como un indicador binario.
• La columna cambia constantemente y casi no se consulta.
• Ya existe un índice equivalente por PRIMARY KEY o UNIQUE.
• No existe una consulta real que lo necesite.

No crees índices para todas las columnas. Cada índice debe responder: ¿qué consulta frecuente y concreta se beneficiará?

DROP INDEX IF EXISTS idx_reservaciones_habitacion_fechas;

Eliminar un índice no elimina filas ni columnas, pero puede cambiar el rendimiento de consultas.

EXPLAIN QUERY PLAN

EXPLAIN QUERY PLAN
SELECT id, codigo, fecha_registro
FROM paquetes
WHERE ruta_id = 3
  AND fecha_registro BETWEEN '2026-07-01' AND '2026-07-31';

Dos palabras esenciales:

Después de crear:

CREATE INDEX idx_paquetes_ruta_fecha
ON paquetes (ruta_id, fecha_registro);

repite exactamente el mismo plan. Puede aparecer:

SEARCH paquetes USING INDEX idx_paquetes_ruta_fecha
    (ruta_id=? AND fecha_registro>? AND fecha_registro<?)

Un recorrido completo puede ser razonable cuando:

• La tabla es pequeña.
• Se necesitan casi todas las filas.
• No existe un filtro selectivo.
• Mantener otro índice cuesta más de lo que aporta.

El objetivo no es eliminar cada palabra SCAN, sino comprender el plan.

Puede aparecer:

USE TEMP B-TREE FOR ORDER BY

Significa que SQLite necesita una estructura temporal para ordenar. Un índice compatible puede evitarla en algunos casos, pero no debes crear uno sin una consulta frecuente y una mejora justificada.

EXPLAIN QUERY PLAN:

• Describe una estrategia de alto nivel.
• No mide por sí solo el tiempo real.
• Puede cambiar según datos, estadísticas, versión e índices.
• Tiene un formato de salida que SQLite puede modificar entre versiones.
• Sirve para análisis interactivo; una aplicación no debe depender del texto exacto.

En una base con 30 filas, una diferencia de velocidad será imperceptible. La evidencia del curso demuestra comprensión del plan, no una afirmación de rendimiento a gran escala.

Mejoras básicas antes de añadir índices

Un índice no corrige una consulta mal planteada.

-- Evita en un reporte final
SELECT * FROM reservaciones;

-- Expresa la necesidad
SELECT id, huesped_id, habitacion_id, fecha_entrada, fecha_salida
FROM reservaciones;

Aplica condiciones que pertenecen a las filas antes de agregar. No cargues datos que luego serán descartados.

Un índice sobre fecha_entrada puede no ayudar de la misma forma si la consulta transforma cada valor:

WHERE strftime('%Y', fecha_entrada) = '2026'

Una alternativa con intervalo suele expresar mejor el rango:

WHERE fecha_entrada >= '2026-01-01'
  AND fecha_entrada < '2027-01-01'

Proceso mínimo:

1. Define la consulta real.
2. Guarda el plan inicial.
3. Crea un índice justificado.
4. Ejecuta el mismo plan.
5. Describe el cambio.
6. Conserva o elimina el índice según la evidencia y el costo.

Consultas parametrizadas e inyección SQL

Una aplicación no debe construir una consulta uniendo texto recibido:

"SELECT * FROM huespedes WHERE correo = '" + correo_ingresado + "'"

Un valor malicioso podría cambiar la estructura de la instrucción. Eso se conoce como inyección SQL.

Conceptualmente, una consulta parametrizada mantiene dos elementos separados:

SELECT id, nombre, correo
FROM huespedes
WHERE correo = ?;

Instrucción SQL: SELECT ... WHERE correo = ?
Valores:        ['persona@correo.test']

La biblioteca del lenguaje envía la estructura y los datos mediante su API. No debes añadir comillas manuales ni utilizar reemplazos de texto como protección.

Los marcadores varían: ?, :nombre, %s o $1, según biblioteca y motor. El principio es el mismo.

Los parámetros representan valores. Normalmente no sustituyen nombres de tabla, nombres de columna ni palabras clave. Si una aplicación permite elegir una columna de orden, debe validarla contra una lista controlada.

Las consultas parametrizadas son necesarias, pero la seguridad también requiere permisos mínimos, validación, manejo de errores, protección de credenciales y actualizaciones. Este módulo prepara el concepto para conectar posteriormente un lenguaje.

Inspección y verificación de SQLite

PRAGMA table_info('reservaciones');

Permite revisar nombres, tipos, NOT NULL, valores predeterminados y clave primaria.

PRAGMA foreign_key_list('reservaciones');

Comprueba tabla y columna referenciadas y acciones ON UPDATE y ON DELETE.

PRAGMA index_list('reservaciones');

Después inspecciona uno:

PRAGMA index_info('idx_reservaciones_habitacion_fechas');

PRAGMA integrity_check;
PRAGMA foreign_key_check;

Resultado esperado:

integrity_check  → ok
foreign_key_check → cero filas

integrity_check revisa la estructura de la base. foreign_key_check localiza incumplimientos referenciales. Ninguno sustituye las pruebas de reglas comerciales.

SELECT type, name, tbl_name, sql
FROM sqlite_schema
WHERE type IN ('table', 'view', 'index')
ORDER BY type, name;

Los índices automáticos pueden aparecer sin una definición SQL escrita por ti.

Respaldo y recuperación básica

Una base no está respaldada solo porque “existe en la computadora”.

Guarda una copia con otro nombre después de confirmar todos los cambios y cerrar operaciones pendientes. Abre la copia y ejecuta verificaciones.

En la interfaz de línea de comandos:

.backup hotel_respaldo.db

.backup es un comando de la herramienta, no una instrucción SQL.

En versiones compatibles:

VACUUM INTO 'hotel_respaldo.db';

No sobrescribas un archivo existente. Conserva respaldos fuera de la carpeta de trabajo y prueba que puedan abrirse.

Una política profesional define frecuencia, versiones, ubicación, acceso y pruebas de restauración. La administración avanzada de respaldos queda fuera del alcance.

Portabilidad

No reescribas el proyecto para todos los motores. Documenta qué puntos revisarías.

Videos recomendados

Tema exacto: propósito y creación de índices. Momento recomendado: antes de la práctica guiada 3. Objetivo: reforzar la relación entre consulta e índice. Precaución: no adoptes una regla de rendimiento sin comprobar el plan del motor y el patrón real de datos.

Tema exacto: creación y consulta de vistas. Momento recomendado: después de la sección 2. Objetivo: comprender una vista como una consulta reutilizable con nombre.

Documentación oficial

• 📖`CREATE VIEW` — SQLite

Revisa creación, columnas y naturaleza de solo lectura de las vistas en SQLite.

• 📖`CREATE INDEX` — SQLite

Consulta índices simples, compuestos y únicos.

• 📖`EXPLAIN QUERY PLAN` — SQLite

Concéntrate en SCAN, SEARCH, uso de índices y árboles temporales.

• 📖Planificador de consultas — SQLite

Utilízalo como lectura de ampliación; no necesitas memorizar sus algoritmos.

• 📖Interfaz de línea de comandos — SQLite

Busca .backup, .schema, .indexes y .eqp.

• 📖`VACUUM INTO` — SQLite

Revisa condiciones y limitaciones antes de generar una copia.

La salida exacta de EXPLAIN QUERY PLAN puede cambiar entre versiones. Documenta el resultado que observaste, la versión utilizada y su significado general.

Referencias de portabilidad

No deben estudiarse completas. Sirven para ubicar el equivalente cuando cambies de motor.

• 📖Tutorial SQL oficial de PostgreSQL
• 📖Sentencias SQL de MySQL 8.4
• 📖Referencia de Transact-SQL — Microsoft Learn
• 📖Sentencias SQL de MariaDB
• 📖Referencia SQL de Oracle Database

Material complementario

Este módulo incluye solamente:

1. ⬇️`datos_mensajeria_m06.sql`, necesario para realizar la auditoría sobre la misma base.
2. ⬇️`plantilla_documentacion_hotel.md`, editable y opcional, para organizar la memoria del proyecto.

El enunciado, la rúbrica y la lista técnica ya están dentro del módulo. No necesitas descargar un PDF que duplique el contenido.

Glosario

Resumen final del módulo

En este módulo integraste el curso completo:

Diseñar
  ↓
Proteger
  ↓
Cargar y modificar
  ↓
Consultar y relacionar
  ↓
Reutilizar con vistas
  ↓
Analizar índices y planes
  ↓
Verificar y respaldar
  ↓
Documentar y entregar

Ahora puedes:

• Organizar scripts reproducibles.
• Crear vistas útiles.
• Proponer índices con una consulta real como justificación.
• Detectar índices redundantes.
• Interpretar un plan elemental.
• Diferenciar SCAN de SEARCH sin convertirlos en etiquetas absolutas.
• Explicar parametrización e inyección SQL.
• Inspeccionar esquema, relaciones e índices.
• Verificar integridad estructural y referencial.
• Crear y probar un respaldo.
• Documentar portabilidad.
• Construir y defender una base relacional completa.

Al aprobar habrás demostrado que puedes:

• Pasar de un problema real a un modelo implementado.
• Proteger reglas con la técnica adecuada.
• Resolver reportes sin duplicar medidas.
• Auditar una solución existente mediante evidencia.
• Reconocer los límites de una prueba de rendimiento pequeña.
• Preparar una base para conectarla posteriormente a una aplicación.
• Entregar documentación suficiente para mantenimiento y revisión.

Cierre del curso

Has recorrido:

Fundamentos relacionales
        ↓
Diseño y normalización
        ↓
Gestión segura de datos
        ↓
Consultas y análisis
        ↓
Consultas multitabla
        ↓
Proyecto profesional completo

Debes:

• Completar los seis módulos.
• Realizar las actividades obligatorias.
• Aprobar las seis evaluaciones prácticas.
• Aprobar los proyectos de los módulos 1 a 5.
• Aprobar el proyecto final integrador.
• Presentar las correcciones obligatorias.
• Cumplir el formato de entrega y las normas de autoría académica de COA.

El certificado demuestra que completaste satisfactoriamente una ruta práctica de 24 horas. No sustituye una certificación profesional de un fabricante ni afirma experiencia laboral.

Ahora estás preparado para continuar con:

• Conexión de Python con SQLite.
• Desarrollo de Software con Python.
• Persistencia de datos en aplicaciones.
• PostgreSQL, MySQL o SQL Server.
• Administración y optimización especializada de bases de datos.

Debes poder responder y demostrar:

1. ¿Cómo traduces una regla de negocio a una restricción o proceso?
2. ¿Cómo decides las tablas y relaciones?
3. ¿Cómo modificas datos sin ejecutar cambios a ciegas?
4. ¿Cómo diferencias filtros de filas y grupos?
5. ¿Cómo evitas perder entidades en un LEFT JOIN?
6. ¿Cómo detectas una medida multiplicada por relaciones?
7. ¿Qué consulta justifica tu índice?
8. ¿Qué cambió en el plan antes y después?
9. ¿Cómo impides que datos externos se conviertan en SQL?
10. ¿Cómo demuestra otra persona que tu solución es reproducible?

Si puedes responder con el script, el diagrama, las consultas y la evidencia de tu proyecto, has alcanzado el objetivo del curso.