EXAMEN TIPO COLOQUIO – ORIENTADO A PROYECTO REAL
2026
TECNICATURA
UNIVERSITARIA EN
PROGRAMACIÓN
UTN – F.R. Resistencia
SEDE FORMOSA
● Asignatura: Base de Datos II
● Nivel: Segundo año - Tercer cuatrimestre
Docente
● Federico Horacio Britez
Alumnos:
• ARCE ANGEL
• CASTILLO RODRIGO
• BENITEZ ALEXANDER
-
Base de Datos II
EXAMEN TIPO COLOQUIO – ORIENTADO A PROYECTO
REAL
Enfoque del Coloquio
Cada grupo trabajará sobre su propio sistema ya desarrollado (organismo público o
empresa privada) y deberá:
MEJORAR, JUSTIFICAR Y PROFESIONALIZAR SU BASE DE DATOS
OBJETIVO Comprobar si el estudiante puede:
• Llevar un sistema real a nivel profesional.
• Aplicar buenas prácticas de bases de datos.
• Justificar decisiones técnicas.
• Integrar todos los contenidos de la materia
CONSIGNA DEL COLOQUIO
Cada grupo deberá presentar su sistema y demostrar mejoras en:
1. INTEGRIDAD DE DATOS (Aplicado al proyecto) Tienen que:
• Revisar su modelo actual
• Detectar problemas de integridad
• Implementar o mejorar:
o Claves primarias
o Claves foráneas
o CHECK, UNIQUE, NOT NULL
Explicar:
Qué problemas tenía el modelo original
Qué errores se evitan ahora
Ejemplo real de inconsistencia corregida
2. TRANSACCIONES Y CONCURRENCIA (CASO REAL) Tienen que:
• Identificar un proceso crítico del sistema (ej: ventas, turnos, pagos, inscripciones)
• Implementar una transacción real: START TRANSACTION; COMMIT;
• Simular un problema de concurrencia
• Resolverlo usando
Deben explicar:
• Qué problema ocurría antes
• Qué propiedad ACID aplicaron
• Por qué eligieron ese nivel de aislamiento
3. SEGURIDAD Y CONTROL DE ACCESO
El grupo tiene que:
• Definir roles reales del sistema (ej: admin, operador, auditor)
• Crear:
o Usuarios
o Roles
• Asignar permisos con:
o GRANT
o REVOKE Deben justificar:
• Por qué cada usuario tiene esos permisos
• Qué riesgos evita
4. MANTENIMIENTO Y CONTINUIDAD OPERATIVA
El grupo tiene que:
• Realizar:
o Backup
o Restore
• Proponer:
o Plan de mantenimiento
o Frecuencia de backup
o Estrategia ante fallos Deben explicar:
• Qué pasaría si el sistema falla hoy
• Cómo recuperarían la información
5. MEJORA TÉCNICA DEL SISTEMA (VALOR AGREGADO)
Pueden incluir:
• Índices
• Optimización de consultas (EXPLAIN)
• Automatización (eventos, tareas)
• Logs o auditoría
6. DEMOSTRACIÓN DEL SISTEMA El grupo deberá mostrar:
✔ Su base de datos real
✔ Cambios implementados
✔ Ejecución de consultas
✔ Evidencia de funcionamiento
1) INTEGRIDAD DE DATOS
A) Claves Primarias
Se agregaron claves primarias compuestas en tablas puente.
Beneficio: Evita relaciones duplicadas.
B) Claves Foráneas
Ya existían muchas claves foráneas correctas en el proyecto, por ejemplo:
Se verificaron y fortalecieron.
Beneficio: Evita registrar préstamos con usuarios o libros inexistentes.
C) CHECK
Se agregaron validaciones.
Beneficio: Evita valores absurdos o inválidos.
D) UNIQUE
Se reforzaron campos únicos como:
Beneficio: No se repiten datos que deben ser exclusivos.
E) NOT NULL
Se aplicó a campos obligatorios:
Beneficio: Evita registros incompletos.
2. TRANSACCIONES Y CONCURRENCIA:
Proceso crítico identificado
El proceso más crítico del sistema biblioteca es el registro de préstamos de libros,
porque intervienen varias operaciones sobre datos sensibles:
1. Verificar disponibilidad del ejemplar
2. Registrar el préstamo en la tabla movimiento
3. Descontar la cantidad disponible en ejemplar
Si dos usuarios solicitan el mismo libro al mismo tiempo, puede producirse inconsistencia.
Problema que ocurría antes
Supongamos que queda 1 solo ejemplar disponible.
Dos usuarios realizan préstamo simultáneamente: Ambos continúan el proceso.
Resultado: Eso genera sobre préstamo.
Solución implementada con transacción: Se utilizó transacción con nivel de aislamiento
SERIALIZABLE.
Simulación del problema de concurrencia
Sesión A y sesión B al mismo tiempo
Resultado: La segunda transacción espera o se serializa hasta que termine la primera.
¿Qué problema se resolvió?
Antes podían ejecutarse operaciones simultáneas leyendo el mismo stock. Ahora las
transacciones se ejecutan como si fueran una detrás de otra, evitando conflictos.
Propiedad ACID aplicada
Atomicidad: Si falla una parte del préstamo, se revierte todo.
Consistencia: Nunca habrá stock negativo ni préstamos duplicados.
Aislamiento: Cada transacción trabaja aislada de otras concurrentes.
Durabilidad: Después de COMMIT, los cambios quedan guardados.
¿Por qué se eligió SERIALIZABLE?
Se eligió porque es el nivel de aislamiento más alto y garantiza máxima seguridad en
operaciones críticas de inventario.
Ventajas:
• Evita lecturas sucias
• Evita lecturas no repetibles
• Evita phantom reads
• Evita que dos usuarios tomen el último ejemplar al mismo tiempo
En este proyecto se priorizó integridad de datos sobre rendimiento, ya que un
préstamo incorrecto afecta todo el sistema.
3. SEGURIDAD Y CONTROL DE ACCESO
Definición de roles reales del sistema
Para proteger la base de datos se definieron distintos roles según las tareas reales dentro
de una biblioteca.
Roles creados
1. Administrador
Responsable total del sistema.
Funciones:
• Gestionar usuarios
• Crear libros
• Modificar tablas
• Ver reportes
• Configurar permisos
2. Operador
Empleado que atiende préstamos y devoluciones.
Funciones:
• Registrar préstamos
• Registrar devoluciones
• Consultar usuarios
• Consultar stock de libros
3. Auditor
Encargado de revisar movimientos y cambios del sistema.
Funciones:
• Consultar auditorías
• Consultar préstamos
• Ver multas y pagos
No puede modificar datos.
Uso de REVOKE
Se quitó permiso peligroso al operador:
Justificación de permisos
Operador
Solo permisos necesarios para atención diaria.
No puede borrar datos ni alterar auditorías.
Riesgos que se evitan
1. Borrado accidental de información: Sin restricciones un operador podría
ejecutar: Ahora no puede.
2. Alteración de auditorías: Sin control cualquiera podría modificar historiales.
Ahora solo lectura.
3. Acceso total innecesario: No todos los empleados necesitan acceso completo.
Se aplica principio de mínimo privilegio.
4. Manipulación de multas o pagos: El auditor no puede cambiarlos, solo revisarlos.
4. MANTENIMIENTO Y CONTINUIDAD OPERATIVA
Importancia
El sistema biblioteca almacena información crítica:
• Usuarios registrados
• Libros
• Préstamos
• Multas
• Pagos
• Auditorías
Si la base de datos falla y no existe respaldo, se pierde información importante para el
funcionamiento diario.
Backup realizado
Se utilizó respaldo completo de la base de datos MySQL mediante mysqldump. Se genera
un archivo:
Ese archivo contiene:
• Estructura de tablas
• Datos almacenados
• Relaciones
• Procedimientos
• Triggers
Restore realizado
Para recuperar la base de datos: Esto restaura completamente el sistema.
Plan de mantenimiento propuesto
Diario
• Verificar funcionamiento del servidor MySQL
• Revisar espacio en disco
• Confirmar backup automático
Semanal
• Optimizar tablas
• Revisar errores en logs
• Validar integridad de datos
Mensual
• Prueba real de restauración backup
• Cambio de contraseñas administrativas
• Revisión de usuarios y permisos
Frecuencia de backup recomendada
✓ Backup diario automático: Todos los días al finalizar horario laboral.
✓ Backup semanal externo: Guardar copia en otro disco o nube.
✓ Backup mensual histórico: Mantener versiones antiguas por seguridad.
Estrategia ante fallos
Caso 1: Se borra información accidentalmente. Recuperar desde último backup.
Caso 2: Falla disco duro. Instalar servidor nuevo y restaurar respaldo externo.
Caso 3: Corrupción de base de datos. Detener sistema y restaurar última copia válida.
Caso 4: Ataque o acceso no autorizado. Cambiar credenciales y restaurar versión
segura.
¿Qué pasaría si el sistema falla hoy?
Si el sistema de biblioteca falla hoy, las operaciones diarias quedarían afectadas
inmediatamente.
Consecuencias principales:
No se podrían registrar préstamos ni devoluciones
Se perdería control del stock real
Usuarios sin historial
Riesgo económico
Pérdida administrativa
¿Cómo recuperarían la información?
Paso 1: Instalar MySQL nuevamente.
Paso 2: Crear base vacía:
Paso 3: Ejecutar restore:
Paso 4: Verificar tablas y datos:
Medidas preventivas adicionales
• UPS para cortes eléctricos
• Antivirus actualizado
• Control de accesos
• Monitoreo del servidor
• Copias en la nube
5. MEJORA TÉCNICA DEL SISTEMA
Para mejorar el rendimiento, control y automatización del sistema biblioteca, se
implementaron mejoras técnicas orientadas a velocidad de consultas, mantenimiento
automático y trazabilidad de operaciones.
Índices
Se agregaron índices en campos muy consultados para acelerar búsquedas.
Beneficio
• Búsqueda más rápida de préstamos por usuario
• Consultas por estado más eficientes
• Localización rápida de libros por título
Optimización de consultas con EXPLAIN
Se analizó rendimiento de consultas frecuentes.
• Consulta original
• Análisis
• Resultado esperado
Antes del índice
Después del índice
Beneficio: Menor consumo de recursos y mayor velocidad.
Automatización con eventos
Se propuso evento automático para detectar préstamos vencidos diariamente.
Beneficio: No depende de control manual.
Logs y auditoría
El sistema ya cuenta con tablas de auditoría:
• auditoria_libro
• auditoria_usuario
• auditoria_ejemplar
• movimiento_auditoria
Registran:
• INSERT
• UPDATE
• DELETE
• Usuario que ejecutó cambios
• Fecha y hora
Beneficio: Permite rastrear errores, cambios indebidos y actividad del sistema.
Ejemplo real
Si un operador modifica stock: Queda guardado en auditoría.
Valor agregado obtenido
Rendimiento: Consultas más rápidas gracias a índices.
Seguridad: Historial completo de modificaciones.
Automatización: Tareas repetitivas ejecutadas solas.
Escalabilidad; El sistema soporta más datos y más usuarios.
Situación vivida durante el proyecto
Durante el desarrollo del proyecto cometimos un error importante relacionado con el
respaldo de la base de datos. Inicialmente pensamos que habíamos guardado toda la
base de datos, pero en realidad solo habíamos conservado:
• El script SQL de creación (estructura de tablas, relaciones, claves, triggers,
procedimientos).
• El diagrama gráfico del modelo relacional.
Es decir, teníamos la estructura del sistema, pero no los datos cargados.
Aprendimos la diferencia entre:
Script SQL
Sirve para reconstruir la base:
• tablas
• relaciones
• índices
• triggers
• procedimientos
Backup real
Incluye todos los datos almacenados en las tablas
Riesgo que detectamos
Podíamos recuperar la estructura, pero no la información operativa. Eso significa
pérdida de trabajo y necesidad de volver a cargar datos manualmente.
Implementamos un plan correcto de respaldos usando:
De esta forma se guarda:
• estructura
• datos
• procedimientos
• triggers
Con la experiencia que recibimos y la investigación realizamos esto:
Binlog en MySQL Configuración, Funcionamiento y Recuperación
El Binary Log (Binlog) es un sistema de registros de MySQL que almacena todas las
operaciones que modifican datos dentro de la base de datos. Se utiliza para recuperación,
auditoría y continuidad operativa.
PASO 1 — verificar si tenemos BINLOG En MySQL Workbench
se ejecuta: SHOW VARIABLES LIKE 'log_bin'; Si dice ON significa que esta activado. Si dice OOF
significa que hay que activarlo.
PASO 2 — ACTIVAR BINLOG BINLOG
ABRIR [Link] En Windows suele estar en: C:\ProgramData\MySQL\MySQL Server 8.0\[Link]
VERIFICÁ LOS ARCHIVOS
SHOW BINARY LOGS;
APARECE ESTO:
AHORA A DEMOSTRARLO HACER UNA OPERACIÓN INSERT INTO: editorial (Nombre_Editorial)
VALUES ('Editorial Recuperable'');
¿CÓMO SABER CUÁL ESTÁ ACTIVO? SHOW MASTER STATUS;
BORRAR DELETE FROM editorial WHERE Nombre_Editorial = 'Editorial Recuperable';
HACER BACKUP
En CMD: mysqldump -u TU_USUARIO -p biblioteca > "C:\Users\alexa\Desktop\[Link]"
SIMULAR DESASTRE En Workbench:
DROP DATABASE biblioteca; CREAR NUEVAMENTE LA BASE CREATE DATABASE biblioteca;
RESTAURAR TODO
En CMD: mysql -u root -p biblioteca < "C:\Users\alexa\Desktop\[Link]"
VERIFICAR En Workbench:
USE biblioteca;
SHOW TABLES;
APLICAR BINLOG
CMD: mysqlbinlog "C:\ProgramData\MySQL\MySQL Server 8.0\Data\LAPTOPDRG9N5NR-
bin.000023" | mysql -u root -p biblioteca