Ejercicios y práctica · Gestión de Bases de Datos · ASIR

Qué deberías ser capaz de hacer

Errores frecuentes que la práctica debería detectar

• {"error":"Confundir el modelo lógico con el almacenamiento físico.","causa":"El modelo lógico describe cómo se organiza conceptualmente la información para el usuario y las aplicaciones, mientras que el almacenamiento físico se refiere a cómo se guardan realmente los datos en disco; son capas de abstracción distintas gestionadas por el SGBD.","correccion":"Entender que el modelo lógico es la 'vista' de los datos para el usuario, y que el SGBD se encarga internamente de traducirla al almacenamiento físico subyacente."}
• {"error":"Pensar que el modelo en red o el orientado a objetos son simplemente 'peores' que el relacional.","causa":"El dominio actual del modelo relacional lleva a infravalorar otros modelos lógicos, cuando cada uno resuelve necesidades distintas (rutas jerárquicas rápidas, relaciones N:M complejas, persistencia de objetos, etc.).","correccion":"Analizar cada modelo según la función que cumple y el tipo de relación que representa mejor, en lugar de establecer una jerarquía de calidad entre ellos."}
• {"error":"Subestimar la complejidad de la consistencia en bases de datos distribuidas.","causa":"Es fácil pensar que replicar datos es suficiente, pero mantener todas las copias idénticas y actualizadas en tiempo real es un desafío significativo, especialmente con latencias de red.","correccion":"Comprender los modelos de consistencia (ej. fuerte, eventual) y sus implicaciones para el diseño de sistemas distribuidos. No todos los sistemas necesitan consistencia fuerte en todo momento."}
• {"error":"Intentar gestionar datos complejos sin un SGBD.","causa":"Algunos desarrolladores novatos pueden intentar almacenar datos directamente en archivos o estructuras simples para evitar la 'complejidad' de un SGBD.","correccion":"Reconocer que, para cualquier aplicación que requiera persistencia, integridad, seguridad y acceso concurrente a datos, un SGBD es una herramienta indispensable que simplifica enormemente el desarrollo y la gestión a largo plazo."}
• {"error":"Confundir el SGBD con la base de datos en sí.","causa":"A menudo se usan indistintamente, pero el SGBD es el software que gestiona la base de datos (la colección de datos).","correccion":"Visualizar el SGBD como el 'administrador' o 'interfaz' que permite interactuar con los datos almacenados en la base de datos."}
• {"error":"No considerar el tipo de carga de trabajo (OLTP vs. OLAP) al elegir un SGBD.","causa":"Asumir que un SGBD es bueno para todo tipo de operaciones. Un SGBD optimizado para transacciones no siempre es el mejor para análisis complejos.","correccion":"Analizar los requisitos funcionales y no funcionales del proyecto. Si la aplicación es transaccional, un RDBMS OLTP es adecuado. Si es para análisis de datos, se debe considerar un SGBD OLAP o un data warehouse."}
• Confundir un atributo con una entidad: A veces, se intenta modelar una característica como una entidad separada cuando debería ser un atributo. Por ejemplo, 'Dirección' como entidad en lugar de atributo de 'Cliente'. Causa: No entender la granularidad de la información. Corrección: Una entidad debe tener atributos propios y una identidad única; si solo describe otra entidad, es un atributo.
• Interpretar incorrectamente la cardinalidad: Por ejemplo, pensar que '1:N' significa que cada instancia de N debe tener una de 1. Causa: No distinguir entre 'uno o muchos' y 'exactamente uno'. Corrección: Dibujar ejemplos concretos de las relaciones y verificar si la cardinalidad y opcionalidad reflejan la realidad del negocio.
• No crear una tabla intermedia para relaciones N:M: Esto lleva a la duplicación de datos o a la imposibilidad de representar la relación correctamente. Causa: Desconocimiento de la regla de transformación para N:M. Corrección: Siempre que veas una relación N:M en el E/R, planifica una tabla intermedia con las PKs de ambas entidades como FKs y parte de su PK compuesta.
• Colocar la clave foránea en el lado incorrecto en relaciones 1:N: Por ejemplo, poner la FK de 'Empleado' en la tabla 'Departamento'. Causa: Confusión sobre qué entidad 'posee' la referencia. Corrección: La FK siempre va en la tabla del lado 'N' (muchos) y apunta a la PK de la tabla del lado '1' (uno).
• No definir acciones de integridad referencial adecuadas: Esto puede llevar a datos inconsistentes (registros huérfanos) o a bloqueos inesperados. Causa: Desconocimiento de las opciones `ON DELETE`/`ON UPDATE` o no analizar el impacto en el negocio. Corrección: Para cada FK, analizar qué debería ocurrir con los registros hijos cuando el padre es modificado o eliminado, y elegir la acción más apropiada (`CASCADE`, `SET NULL`, `RESTRICT`).
• Permitir NULL en campos que deberían ser obligatorios: Esto puede generar datos incompletos y dificultar consultas. Causa: No distinguir entre opcionalidad en el E/R y `NULL` en el lógico. Corrección: Si un atributo era obligatorio en el E/R, su campo correspondiente en el lógico debe ser `NOT NULL`.
• Normalizar en exceso o en defecto: Normalizar demasiado puede llevar a un gran número de tablas pequeñas, complicando las consultas (joins). Normalizar poco causa redundancia y anomalías. Causa: No entender el equilibrio entre normalización y rendimiento. Corrección: Apuntar a 3FN/BCNF para la mayoría de los casos. Desnormalizar solo si hay un problema de rendimiento probado y documentado.
• No documentar restricciones no plasmables: Esto lleva a que los desarrolladores no las implementen, resultando en fallos de lógica de negocio o datos inconsistentes. Causa: Asumir que todo se resuelve en la BD o que la lógica es 'obvia'. Corrección: Crear una sección específica en la documentación del diseño lógico para estas reglas, describiéndolas y sugiriendo su implementación.
• Omitir la cláusula FROM: Causa un error de sintaxis porque el SGBD no sabe de qué tabla recuperar los datos. Corrección: Asegurarse de incluir `FROM nombre_tabla`.
• Errores de sintaxis en WHERE: Usar comillas incorrectas para cadenas de texto o no encerrar valores de texto. Causa: La condición no se evalúa correctamente o produce un error. Corrección: Usar comillas simples para cadenas de texto (`'valor'`) y verificar la sintaxis de los operadores.
• Seleccionar `*` en producción sin necesidad: Causa: Recupera columnas innecesarias, aumentando el tráfico de red y el consumo de memoria. Corrección: Especificar explícitamente solo las columnas requeridas.
• Usar columnas no agregadas en SELECT sin incluirlas en GROUP BY: Causa un error de sintaxis porque el SGBD no sabe cómo agrupar esas columnas. Corrección: Incluir todas las columnas no agregadas de SELECT en la cláusula GROUP BY.