Bases de Datos (Nivel Intermedio)

Una empresa de comercio electrónico necesita almacenar millones de transacciones diarias. Considerando los principios de normalización y rendimiento, ¿qué estrategia de diseño de base de datos sería más adecuada para equilibrar la integridad de los datos y la velocidad de consulta?

• Almacenar todos los datos en una sola tabla desnormalizada para simplificar las consultas

• Aplicar normalización hasta la tercera forma normal (3FN) y luego desnormalizar selectivamente las tablas más consultadas

• Usar únicamente claves primarias compuestas en todas las tablas para evitar redundancias

• Crear una base de datos separada para cada tipo de transacción sin ninguna relación entre ellas

• Normalizar hasta la quinta forma normal (5FN) en todas las tablas sin excepción para garantizar la integridad

Dado el siguiente esquema relacional de una biblioteca: **Libro**(*ISBN*, Título, Año), **Autor**(*ID_Autor*, Nombre), **Escrito_Por**(*ISBN*, *ID_Autor*) Si se desea obtener todos los autores que han escrito más de 3 libros publicados después del año 2000, ¿cuál es la consulta SQL que resuelve correctamente este problema?

• SELECT Nombre FROM Autor WHERE ID_Autor > 3 AND Año > 2000

• SELECT Nombre FROM Autor JOIN Escrito_Por ON Autor.ID_Autor = Escrito_Por.ID_Autor WHERE Año > 2000

• SELECT A.Nombre FROM Autor A JOIN Escrito_Por E ON A.ID_Autor = E.ID_Autor JOIN Libro L ON E.ISBN = L.ISBN WHERE L.Año > 2000 GROUP BY A.ID_Autor, A.Nombre HAVING COUNT(L.ISBN) > 3

• SELECT Nombre FROM Autor GROUP BY Nombre HAVING COUNT(*) > 3

• SELECT Nombre FROM Autor, Libro WHERE Año > 2000 AND COUNT(ISBN) > 3

Un sistema hospitalario registra pacientes, médicos y citas. Se detecta que la tabla **Cita** contiene los atributos: *ID_Cita*, *ID_Paciente*, *Nombre_Paciente*, *ID_Médico*, *Especialidad_Médico*, *Fecha*, *Diagnóstico*. ¿Qué problema de diseño presenta esta tabla y cuál sería la solución más apropiada?

• La tabla está en 3FN porque tiene una clave primaria definida; no requiere cambios

• Existe una dependencia transitiva porque *Nombre_Paciente* depende de *ID_Paciente* y *Especialidad_Médico* depende de *ID_Médico*; se deben crear tablas separadas para Paciente y Médico

• El problema es que falta una clave foránea; se debe agregar *ID_Hospital* como clave primaria compuesta

• La tabla tiene demasiados atributos y se debe dividir aleatoriamente en dos tablas iguales

• No existe ningún problema porque todas las columnas son necesarias para describir una cita médica

• SELECT ID_Depto FROM Empleado WHERE Salario > 0.75

• SELECT D.Nombre_Depto FROM Departamento D WHERE D.Presupuesto * 0.75 > AVG(Salario)

• SELECT D.Nombre_Depto FROM Departamento D JOIN Empleado E ON D.ID_Depto = E.ID_Depto GROUP BY D.ID_Depto, D.Nombre_Depto, D.Presupuesto HAVING AVG(E.Salario) > 0.75 * D.Presupuesto

• SELECT Nombre_Depto FROM Departamento WHERE Presupuesto > 75

• SELECT Nombre FROM Empleado JOIN Departamento ON ID = ID_Depto HAVING Salario > Presupuesto

En el diseño de una base de datos para una red social, se necesita modelar que un usuario puede seguir a muchos otros usuarios y a su vez ser seguido por muchos. ¿Cuál es la estrategia de modelado más adecuada y por qué?

• Crear una tabla **Usuario** con columnas *Seguidores* y *Seguidos* que almacenen listas separadas por comas

• Crear dos tablas separadas: **Seguidores** y **Seguidos**, cada una con una clave foránea hacia **Usuario**

• Crear una tabla de asociación **Sigue**(*ID_Seguidor*, *ID_Seguido*) con ambas columnas como claves foráneas que referencian a la misma tabla **Usuario**, modelando así una relación recursiva muchos a muchos

• Agregar a la tabla **Usuario** una columna *ID_Amigo* como clave foránea que apunte a otro usuario

• Usar una sola tabla con los atributos *Usuario1* y *Usuario2* sin definir claves foráneas para mayor flexibilidad

Un analista detecta que en la base de datos de ventas, las consultas sobre reportes mensuales tardan demasiado tiempo. La tabla **Venta** tiene 50 millones de registros con los campos: *ID_Venta*, *Fecha*, *ID_Cliente*, *Monto*, *ID_Producto*. ¿Qué combinación de estrategias justificaría mejor la optimización del rendimiento?

• Eliminar todos los índices existentes para reducir el espacio en disco y mejorar la velocidad de escritura

• Crear un índice compuesto sobre (*Fecha*, *ID_Producto*) y considerar la partición de la tabla por rangos de fecha, ya que las consultas filtran principalmente por estos campos

• Duplicar la tabla completa en otra base de datos para distribuir la carga de consultas

• Agregar más columnas a la tabla para evitar los JOIN con otras tablas

• Convertir todos los tipos de datos a VARCHAR para uniformizar la estructura y acelerar las búsquedas

Se tiene el siguiente diagrama entidad-relación parcial: una entidad **Pedido** se relaciona con **Producto** mediante una relación *Contiene* con atributos propios (*Cantidad*, *Precio_Unitario*). Al transformar este modelo al esquema relacional, ¿cuál es la representación más correcta?

• **Pedido**(*ID_Pedido*, *Cantidad*, *Precio_Unitario*) y **Producto**(*ID_Producto*)

• **Pedido**(*ID_Pedido*), **Producto**(*ID_Producto*), y **Contiene**(*ID_Pedido*, *ID_Producto*, *Cantidad*, *Precio_Unitario*) donde (*ID_Pedido*, *ID_Producto*) es la clave primaria compuesta

• **Pedido**(*ID_Pedido*, *ID_Producto*, *Cantidad*) con *ID_Producto* como clave primaria

• Fusionar todo en una sola tabla **Pedido_Producto**(*ID_Pedido*, *ID_Producto*) sin atributos adicionales

• **Producto**(*ID_Producto*, *ID_Pedido*, *Cantidad*, *Precio_Unitario*) con *ID_Pedido* como clave primaria

• Viola la primera forma normal (1FN); la solución es agregar más columnas a la tabla

• Viola la segunda forma normal (2FN) porque *ID_Profesor* depende solo de *ID_Curso* y no de toda la clave primaria compuesta (*ID_Estudiante*, *ID_Curso*); se debe crear una tabla separada **Curso**(*ID_Curso*, *ID_Profesor*)

• Viola la tercera forma normal (3FN); la solución es eliminar la columna *Nota* de la tabla

• No viola ninguna forma normal porque todas las columnas son necesarias para identificar una inscripción

• Viola la forma normal de Boyce-Codd (FNBC); la solución es agregar *ID_Inscripción* como nueva clave primaria simple

Un sistema bancario requiere garantizar que una transferencia entre cuentas sea atómica: se debe debitar de una cuenta y acreditar en otra. Si el sistema falla a mitad del proceso, ¿qué mecanismo de base de datos y qué propiedad ACID garantizan la consistencia de los datos, y cómo se implementaría?

• Se usa un índice único en la columna *Saldo* para evitar valores duplicados y garantizar la consistencia

• Se aplica la propiedad de Durabilidad mediante la creación de una copia de seguridad manual antes de cada operación

• Se utiliza una transacción que agrupa ambas operaciones (débito y crédito); la propiedad de Atomicidad garantiza que si alguna operación falla, se ejecuta un ROLLBACK que revierte todos los cambios, dejando la base de datos en su estado original

• Se crea un disparador (trigger) que verifica el saldo antes de cada operación, lo cual reemplaza la necesidad de transacciones

• Se usa la propiedad de Aislamiento para ejecutar ambas operaciones en paralelo y combinar los resultados al final

• **Proyecto**(*ID_Proyecto*, *Nombre_Proyecto*, *Ubicación_Proyecto*, *Horas*) y **Empleado**(*ID_Empleado*)

• **Trabaja_En**(*ID_Empleado*, *ID_Proyecto*, *Horas*) y **Proyecto**(*ID_Proyecto*, *Nombre_Proyecto*, *Ubicación_Proyecto*)

• **Proyecto**(*ID_Proyecto*, *Nombre_Proyecto*) y **Empleado**(*ID_Empleado*, *Ubicación_Proyecto*, *Horas*)

• Mantener la tabla original sin cambios porque ya está en 3FN al tener una clave primaria compuesta

• **Proyecto**(*ID_Proyecto*, *Nombre_Proyecto*, *Ubicación_Proyecto*, *ID_Empleado*) con *ID_Proyecto* como única clave primaria