0% encontró este documento útil (0 votos)
0 vistas18 páginas

Base de Datos II.docx

El examen tipo coloquio de la asignatura Base de Datos II de la UTN se centra en mejorar y profesionalizar un sistema de base de datos real desarrollado por los estudiantes. Los grupos deben abordar aspectos como integridad de datos, transacciones, seguridad, mantenimiento y mejoras técnicas, justificando sus decisiones y demostrando los cambios implementados. El objetivo es evaluar la capacidad de los estudiantes para aplicar buenas prácticas y llevar un sistema a un nivel profesional.
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
0 vistas18 páginas

Base de Datos II.docx

El examen tipo coloquio de la asignatura Base de Datos II de la UTN se centra en mejorar y profesionalizar un sistema de base de datos real desarrollado por los estudiantes. Los grupos deben abordar aspectos como integridad de datos, transacciones, seguridad, mantenimiento y mejoras técnicas, justificando sus decisiones y demostrando los cambios implementados. El objetivo es evaluar la capacidad de los estudiantes para aplicar buenas prácticas y llevar un sistema a un nivel profesional.
Derechos de autor
© All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd

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

También podría gustarte