Qué puede evaluarse
RA1: Reconoce los elementos de las bases de datos analizando sus funciones y valorando la utilidad de sistemas gestores.
Base de datosModelo de datosSistema lógico de almacenamientoModelo lógico vs almacenamiento físicoModelo jerárquicoModelo en redModelo relacionalClave primaria y clave foráneaModelo orientado a objetosRDBMS
RA2: Diseña modelos lógicos normalizados interpretando diagramas entidad/relación.
EntidadAtributoRelaciónCardinalidadOpcionalidadModelo E/RSimbología Crow's FootModelo Lógico RelacionalTablaCampo
RA4: Consulta la información almacenada manejando asistentes, herramientas gráficas y el lenguaje de manipulación de datos.
SQL (Structured Query Language)Sentencia SELECTCláusula FROMCláusula WHERECláusula ORDER BYOperadores de comparación y lógicosHerramientas gráficas de consultaFunciones de agregación (COUNT, SUM, AVG, MIN, MAX)Cláusula GROUP BYCláusula HAVING
RA5: Modifica la información almacenada utilizando asistentes, herramientas gráficas y el lenguaje de manipulación de datos.
DMLINSERTUPDATEDELETEHerramientas gráficas de SGBDCláusula WHEREINSERT INTO SELECTIntegridad de datosConsistencia de datosPRIMARY KEY
RA6: Ejecuta tareas de aseguramiento de la información, analizándolas y aplicando mecanismos de salvaguarda y transferencia.
Backup lógico vs backup físicomysqldump / mysqlpump (MySQL-MariaDB)pg_dump / pg_dumpall / pg_basebackup (PostgreSQL)RMAN y Data Pump (Oracle)BACKUP DATABASE y SSMS (SQL Server)mongodump / mongorestore (MongoDB)Herramientas gráficas de administración de backups por SGBDRTO y RPO como criterios de elección de herramientaConsistencia transaccional durante la copiaFormatos de intercambio (CSV, JSON, XML, dump SQL)
Trampas habituales antes del examen
- {"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`.