feat(sql): resolver ejercicio 68 y solicitud sql 068

resoluciones/maria-montepeque/ejercicio-68/README.md

@@ -0,0 +1,80 @@
+# Ejercicio 68: DROP Nivel Basico
+
+**Nombre:** Maria Jose Montepeque
+**Fecha:** 2026-08-21
+
+## Descripcion del problema
+
+Una biblioteca tecnica recibio un listado de libros nuevos en una tabla
+temporal de importacion, sin las restricciones finales del modelo.
+Despues de migrar esos datos a la tabla definitiva `libros`, la tabla
+temporal ya no sirve para nada y debe eliminarse. Lo mismo ocurre con un
+indice y una vista que se usaron para un analisis puntual: una vez que
+cumplieron su proposito, se eliminan sin afectar los datos reales.
+
+## Tabla principal
+
+- `libros`: tabla definitiva y permanente (titulo, categoria,
+  disponible).
+
+## Uso de DROP
+
+En `ddl/schema.sql`, despues de crear `libros` y migrar datos desde una
+tabla temporal de importacion:
+
+1. `DROP TABLE libros_importacion_temporal;`: elimina la tabla temporal
+   una vez que sus datos ya se copiaron a `libros`. El riesgo real de
+   `DROP` se explica en un comentario: si se ejecutara antes de migrar
+   los datos, esa informacion se perderia para siempre, porque `DROP`
+   no se puede deshacer.
+2. `CREATE INDEX idx_libros_categoria ...` seguido de
+   `DROP INDEX idx_libros_categoria;`: se crea un indice para un
+   analisis puntual y se elimina despues, porque con pocos libros no
+   aporta beneficio. Los datos de `libros` no se ven afectados.
+3. `CREATE VIEW vista_libros_programacion ...` seguido de
+   `DROP VIEW vista_libros_programacion;`: se crea una vista de apoyo
+   para un reporte puntual y se elimina cuando ya no se va a
+   reutilizar. `DROP VIEW` solo borra la definicion de la vista, nunca
+   los datos de la tabla base.
+
+La consulta 5 en `dql/consultas.sql` confirma, consultando
+`sqlite_master`, que los 3 objetos (tabla temporal, indice y vista) ya
+no existen, mientras que los 3 libros que se migraron desde la tabla
+temporal siguen disponibles en `libros`.
+
+## Otras restricciones aplicadas
+
+- `PRIMARY KEY` autoincremental.
+- `NOT NULL` en todas las columnas.
+- `UNIQUE`: `libros.titulo`.
+- `CHECK`: `categoria IN (...)`, `disponible IN (0, 1)`.
+- `DEFAULT` en `disponible`.
+- `PRAGMA foreign_keys = ON;` activado al inicio del script.
+
+## Caso que falla / no recomendable (comentado en `ddl/schema.sql`)
+
+`DROP TABLE libros_importacion_temporal;` (una segunda vez) falla
+porque la tabla ya no existe: se elimino antes en el mismo script. Se
+valido ejecutandolo con Python (`sqlite3`): lanza
+`OperationalError: no such table: libros_importacion_temporal`. Esto
+demuestra por que en un script real conviene usar
+`DROP TABLE IF EXISTS` cuando no se esta seguro de si el objeto ya fue
+eliminado.
+
+## Evidencias de ejecucion
+
+Scripts validados en orden (`ddl` -> `inserts` -> `consultas`) con
+Python (modulo `sqlite3`), ya que no se tenia el binario `sqlite3`
+disponible en el entorno. Detalle completo en
+[`evidencias/resultados.md`](evidencias/resultados.md).
+
+- Datos finales: 6 libros (3 migrados desde la tabla temporal, 3
+  agregados directamente en `dml/inserts.sql`).
+
+## Como ejecutar
+
+```bash
+sqlite3 ejercicio-68.db < ddl/schema.sql
+sqlite3 ejercicio-68.db < dml/inserts.sql
+sqlite3 ejercicio-68.db < dql/consultas.sql
+```

resoluciones/maria-montepeque/ejercicio-68/ddl/schema.sql

@@ -0,0 +1,62 @@
+PRAGMA foreign_keys = ON;
+
+-- Ejercicio 68: DROP Nivel Basico
+-- Tema central: DROP
+-- Contexto: prestamos de libros tecnicos de una biblioteca.
+
+-- Tabla principal, permanente.
+CREATE TABLE libros (
+    id_libro     INTEGER PRIMARY KEY AUTOINCREMENT,
+    titulo       TEXT NOT NULL UNIQUE,
+    categoria    TEXT NOT NULL
+                     CHECK (categoria IN ('programacion', 'redes', 'bases_de_datos', 'sistemas_operativos')),
+    disponible   INTEGER NOT NULL DEFAULT 1 CHECK (disponible IN (0, 1))
+);
+
+-- Tabla temporal de importacion: la biblioteca recibio un listado de
+-- libros nuevos en un formato plano, sin las restricciones finales, y
+-- se uso esta tabla solo para migrar los datos a la tabla definitiva.
+CREATE TABLE libros_importacion_temporal (
+    titulo_bruto      TEXT,
+    categoria_bruta   TEXT
+);
+
+INSERT INTO libros_importacion_temporal (titulo_bruto, categoria_bruta) VALUES
+    ('Clean Code', 'programacion'),
+    ('Redes de Computadoras', 'redes'),
+    ('Designing Data-Intensive Applications', 'bases_de_datos');
+
+-- Se migran los datos ya validados hacia la tabla definitiva.
+INSERT INTO libros (titulo, categoria)
+SELECT titulo_bruto, categoria_bruta FROM libros_importacion_temporal;
+
+-- DROP TABLE: la tabla de importacion ya cumplio su proposito (los
+-- datos ya viven en `libros`) y se elimina para no dejar datos
+-- duplicados ni confundir a quien use la base de datos despues. Este es
+-- el riesgo de DROP: si se ejecutara antes de migrar los datos, esa
+-- informacion se perderia para siempre.
+DROP TABLE libros_importacion_temporal;
+
+-- Se crea un indice para acelerar busquedas por categoria...
+CREATE INDEX idx_libros_categoria ON libros (categoria);
+
+-- ...pero la biblioteca decide que, con tan pocos libros, el indice no
+-- aporta beneficio y prefiere no mantenerlo. DROP INDEX lo elimina sin
+-- afectar los datos de la tabla.
+DROP INDEX idx_libros_categoria;
+
+-- Se crea una vista de apoyo para un reporte puntual...
+CREATE VIEW vista_libros_programacion AS
+    SELECT id_libro, titulo, disponible
+    FROM libros
+    WHERE categoria = 'programacion';
+
+-- ...y una vez entregado el reporte, se elimina porque ya no se va a
+-- reutilizar. DROP VIEW solo borra la definicion de la vista: los datos
+-- de `libros` siguen intactos.
+DROP VIEW vista_libros_programacion;
+
+-- Caso que debe fallar / no recomendable (queda comentado): intentar
+-- eliminar una tabla que no existe (por ejemplo, por un error de tipeo
+-- o porque ya se elimino antes) falla si no se usa IF EXISTS.
+-- DROP TABLE libros_importacion_temporal;

resoluciones/maria-montepeque/ejercicio-68/dml/inserts.sql

@@ -0,0 +1,13 @@
+PRAGMA foreign_keys = ON;
+
+-- Ejercicio 68: DROP Nivel Basico
+-- Se ejecuta despues de que ddl/schema.sql migro los datos y elimino la
+-- tabla temporal, el indice y la vista de apoyo. Aqui solo se agregan
+-- libros nuevos directamente a la tabla definitiva.
+
+INSERT INTO libros (titulo, categoria) VALUES
+    ('Kafka: The Definitive Guide', 'bases_de_datos'),
+    ('Sistemas Operativos Modernos', 'sistemas_operativos');
+
+INSERT INTO libros (titulo, categoria, disponible) VALUES
+    ('Computer Networking: A Top-Down Approach', 'redes', 0);

resoluciones/maria-montepeque/ejercicio-68/dql/consultas.sql

@@ -0,0 +1,36 @@
+.headers on
+.mode column
+
+-- Ejercicio 68: DROP Nivel Basico
+-- Consultas de validacion.
+
+-- 1. Mostrar todos los datos principales.
+SELECT id_libro, titulo, categoria, disponible FROM libros;
+
+-- 2. Consulta con WHERE.
+SELECT titulo, categoria
+FROM libros
+WHERE disponible = 1;
+
+-- 3. Consulta con ORDER BY.
+SELECT titulo, categoria
+FROM libros
+ORDER BY categoria, titulo;
+
+-- 4. Conteo o resumen.
+SELECT categoria, COUNT(*) AS total_libros
+FROM libros
+GROUP BY categoria;
+
+-- 5. Validacion especifica de DROP: la tabla temporal, el indice y la
+-- vista que se usaron y luego se eliminaron ya no existen en el
+-- catalogo de la base de datos, pero los libros migrados si siguen ahi.
+SELECT name, type
+FROM sqlite_master
+WHERE name IN ('libros_importacion_temporal', 'idx_libros_categoria', 'vista_libros_programacion');
+-- Debe devolver 0 filas: los 3 objetos se eliminaron con DROP.
+
+SELECT titulo, categoria
+FROM libros
+WHERE titulo IN ('Clean Code', 'Redes de Computadoras', 'Designing Data-Intensive Applications');
+-- Los 3 libros migrados desde la tabla temporal siguen disponibles.

resoluciones/maria-montepeque/ejercicio-68/evidencias/resultados.md

@@ -0,0 +1,67 @@
+# Evidencias - Ejercicio 68
+
+## Tema
+
+DROP
+
+## Comandos ejecutados
+
+No se conto con el binario `sqlite3` en el entorno de trabajo, por lo que
+la ejecucion se valido con Python (`sqlite3`), aplicando los mismos
+scripts en el mismo orden:
+
+```bash
+sqlite3 ejercicio-68.db < ddl/schema.sql
+sqlite3 ejercicio-68.db < dml/inserts.sql
+sqlite3 ejercicio-68.db < dql/consultas.sql
+```
+
+## Resultados
+
+Estado justo despues de `ddl/schema.sql` (migracion + DROP de tabla,
+indice y vista):
+
+```text
+libros: [(1, 'Clean Code', 'programacion', 1),
+         (2, 'Redes de Computadoras', 'redes', 1),
+         (3, 'Designing Data-Intensive Applications', 'bases_de_datos', 1)]
+
+sqlite_master (tabla temporal, indice, vista): []   -- los 3 ya no existen
+```
+
+Caso que debe fallar (comentado en `ddl/schema.sql`):
+
+```text
+DROP TABLE libros_importacion_temporal;   -- segunda vez
+Fallo como se esperaba: OperationalError: no such table: libros_importacion_temporal
+```
+
+Estado final (despues de `inserts.sql`), 6 libros en total:
+
+```text
+categoria             total_libros
+bases_de_datos          2
+programacion            1
+redes                   2
+sistemas_operativos     1
+```
+
+Consulta 5 (validacion especifica de DROP):
+
+```text
+5a. sqlite_master para los 3 objetos eliminados: sin filas
+5b. libros migrados desde la tabla temporal, siguen disponibles:
+    ('Clean Code', 'programacion')
+    ('Designing Data-Intensive Applications', 'bases_de_datos')
+    ('Redes de Computadoras', 'redes')
+```
+
+## Aprendizaje
+
+`DROP` elimina de forma permanente una tabla, un indice o una vista, y
+no se puede deshacer: por eso es indispensable migrar o respaldar los
+datos importantes antes de usarlo, como se hizo aqui con la tabla
+temporal de importacion. `DROP INDEX` y `DROP VIEW` son mas seguros en
+el sentido de que nunca afectan los datos de la tabla base, solo
+eliminan la definicion del objeto auxiliar. Consultar `sqlite_master`
+es una forma directa de confirmar que un objeto realmente se elimino.

resoluciones/maria-montepeque/solicitudes-sql/ejercicio-068/README.md

@@ -0,0 +1,80 @@
+# Ejercicio 068: Solicitud de cliente - Escuela de Dibujo
+
+**Nombre:** Maria Jose Montepeque
+**Fecha:** 2026-08-21
+
+## Que entendi de la solicitud
+
+La escuela de dibujo quiere consultar rankings, totales y casos
+pendientes directamente desde la base de datos. Se necesita una base de
+datos que permita registrar entregas de obras, corregir su estado al
+evaluarlas, y sacar reportes, como saber que alumno tiene mas actividad
+o cual tiene el mejor promedio. El detalle completo del analisis esta
+en [`analisis/requerimiento.md`](analisis/requerimiento.md).
+
+## Tablas y por que se crearon
+
+- `profesores`: catalogo de docentes.
+- `cursos`: catalogo de cursos, cada uno de un profesor.
+- `alumnos`: catalogo de estudiantes inscritos.
+- `entregas`: tabla transaccional central; un alumno entrega una obra
+  para un curso.
+- `evaluaciones`: se separa de `entregas` porque tiene su propia nota y
+  comentario, y no toda entrega esta evaluada todavia; relacion 1:1
+  con `entregas` mediante `UNIQUE (id_entrega)`.
+
+## Como se relacionan
+
+`profesores` 1—N `cursos`; `cursos` 1—N `entregas`; `alumnos` 1—N
+`entregas`; `entregas` 1—1 `evaluaciones`.
+
+## Datos de prueba
+
+2 profesores, 3 cursos, 5 alumnos, 10 entregas (con estados variados) y
+7 evaluaciones.
+
+## Operaciones (`dml/operaciones.sql`)
+
+- `UPDATE`: una entrega `'pendiente'` se evalua y pasa a `'evaluada'`
+  (con su evaluacion correspondiente).
+- `UPDATE`: se corrige la nota de una evaluacion tras una segunda
+  revision.
+- `DELETE` controlado (con `WHERE`): se elimina una entrega
+  `'pendiente'` que el alumno retiro.
+- Caso comentado que debe fallar: eliminar un alumno con entregas
+  asociadas viola la `FOREIGN KEY` de `entregas.id_alumno`.
+
+## Consultas que responden al cliente
+
+1. Todas las entregas con alumno y curso (`JOIN`).
+2. Entregas filtradas por estado (`pendiente`, `evaluada`,
+   `rechazada`).
+3. Ranking de alumnos por numero de entregas (`GROUP BY` +
+   `ORDER BY`).
+4. Entregas ordenadas por fecha, de la mas reciente a la mas antigua.
+5. Reporte de decision de negocio: promedio de notas por alumno, para
+   decidir a quien destacar o becar (`GROUP BY` + `HAVING`).
+
+## Evidencias de ejecucion
+
+Scripts validados en orden (`ddl` -> `inserts` -> `operaciones` ->
+`consultas`) con Python (modulo `sqlite3`), ya que no se tenia el
+binario `sqlite3` disponible en el entorno. Detalle completo en
+[`evidencias/resultados.md`](evidencias/resultados.md).
+
+- Datos base: 2 profesores, 3 cursos, 5 alumnos, 10 entregas, 7
+  evaluaciones.
+- Tras `operaciones.sql`: 9 entregas (se elimino la retirada), 8
+  evaluaciones (se agrego la de la entrega 4, se corrigio la de la
+  entrega 3).
+- Reporte final: Alejandra Chinchilla es la alumna con mejor promedio
+  (93.5), seguida de Manuel Estrada (87.5).
+
+## Como validar
+
+```bash
+sqlite3 ejercicio-068.db < ddl/schema.sql
+sqlite3 ejercicio-068.db < dml/inserts.sql
+sqlite3 ejercicio-068.db < dml/operaciones.sql
+sqlite3 ejercicio-068.db < dql/consultas.sql
+```