Qué puede evaluarse
RA1: Desarrolla aplicaciones que gestionan información almacenada en ficheros identificando el campo de aplicación de los mismos y utilizando clases específicas.
FicheroDirectorioRuta (Path)Flujo de entrada/salida (Stream)Acceso secuencialAcceso aleatorioIOExceptiontry-with-resourcesXMLDOM (Document Object Model)
RA2: Desarrolla aplicaciones que gestionan información almacenada en bases de datos relacionales identificando y utilizando mecanismos de conexión.
Persistencia de datosSistema Gestor de Bases de Datos (SGBD)Conector de Base de Datos (Driver)JDBCADO.NETBase de Datos EmbebidaBase de Datos IndependienteURL de conexiónDriverManagerDataSource
RA3: Gestiona la persistencia de los datos identificando herramientas de mapeo objeto relacional (ORM) y desarrollando aplicaciones que las utilizan.
ORM (Object-Relational Mapping)Discrepancia de impedanciaJPA (Java Persistence API)HibernateMaven/Gradlepersistence.xmlUnidad de PersistenciaDialecto SQLJDBCEntidad JPA
RA4: Desarrolla aplicaciones que gestionan la información almacenada en bases de datos objeto relacionales y orientadas a objetos valorando sus características y utilizando los mecanismos de acceso incorporados.
Brecha de impedancia objeto-relacionalBases de Datos Orientadas a Objetos (BDOO)Bases de Datos Objeto-Relacionales (BDOR)Identidad de objetoTipos de datos definidos por el usuarioHerencia de tablas (PostgreSQL)Persistencia de objetosInteroperabilidad con herramientas de tercerosConexión a base de datos (apertura y cierre)Ciclo de vida de la conexión y liberación de recursos
RA5: Desarrolla aplicaciones que gestionan la información almacenada en bases de datos nativas XML evaluando y utilizando clases específicas.
Base de Datos Nativa XML (NXDB)Datos semiestructuradosXQueryXPathFlexibilidad de esquemaColección XMLBaseX como gestor de base de datos nativa XMLModo servidor vs. modo escritorio (GUI)Puertos PORT (cliente-servidor) y HTTPPORT (REST/HTTP)Gestión de usuarios y contraseñas (ALTER USER, CREATE USER, GRANT)
RA6: Programa componentes de acceso a datos identificando las características que debe poseer un componente y utilizando herramientas de desarrollo.
Componente de softwareReusabilidadEncapsulaciónInterfazAcoplamientoCohesiónIDEControl de versionesGestor de dependenciasPersistencia de datos
Trampas habituales antes del examen
- Confundir una clase con un componente: Una clase es una plantilla para objetos, mientras que un componente es una unidad de software autocontenida y desplegable que puede estar compuesta por varias clases. Corrección: Un componente debe tener una interfaz bien definida, ser autocontenido y reutilizable en diferentes contextos, no solo una clase aislada.
- Ignorar la gestión de dependencias: No usar un gestor de dependencias puede llevar a conflictos de versiones (DLL Hell en .NET, Jar Hell en Java) o a la falta de librerías necesarias. Corrección: Integrar Maven, Gradle o NuGet desde el inicio del proyecto para declarar y resolver dependencias de forma automática y consistente.
- No cerrar recursos (ficheros, conexiones DB): Esto puede llevar a fugas de memoria, bloqueos de ficheros o agotamiento de conexiones a la base de datos. Corrección: Utilizar bloques `try-with-resources` en Java o sentencias `using` en C# para asegurar el cierre automático de los recursos, o cerrar explícitamente en bloques `finally`.
- Inyección SQL: Construir consultas SQL concatenando cadenas directamente con la entrada del usuario. Corrección: Usar `PreparedStatement` en JDBC o `SqlCommand` con parámetros en ADO.NET para evitar la inyección SQL, ya que los parámetros se envían por separado de la consulta.
- Problemas de rendimiento con ORM (N+1 selects, carga perezosa mal gestionada): un uso ingenuo del ORM puede generar muchas consultas pequeñas en vez de una consulta optimizada. Corrección: entender cómo el ORM traduce las operaciones a SQL, elegir estrategias de carga adecuadas (eager/lazy) según el caso y recurrir a consultas nativas o proyecciones (DTOs) cuando el mapeo automático no sea eficiente.
- Ignorar el esquema en bases de datos XML: aunque son flexibles, no definir una estructura esperada para los documentos puede provocar inconsistencias difíciles de consultar. Corrección: usar XML Schema (XSD) o DTD para validar los documentos antes de insertarlos, facilitando consultas XQuery consistentes.
- Confundir 'no necesito SQL' con 'no necesito entender el modelo de datos': usar un ORM no exime de diseñar bien las entidades y sus relaciones; un mal diseño de entidades genera consultas ineficientes independientemente de la herramienta usada.
- Falta de cobertura de pruebas: No probar todos los escenarios (casos límite, errores) del componente de acceso a datos. Corrección: Diseñar pruebas que cubran el 100% de las ramas de código importantes, incluyendo escenarios de éxito, error, datos nulos y volúmenes grandes.
- Documentación desactualizada o inexistente: Un componente sin documentación es difícil de usar y mantener. Corrección: Integrar la generación de documentación en el proceso de desarrollo (ej. Javadoc, XML Comments) y mantenerla actualizada con cada cambio significativo en el API del componente.
- Confundir NXDB con bases de datos que simplemente almacenan XML como CLOB/BLOB: La NXDB entiende y procesa la estructura XML internamente, no solo la guarda como un texto. Esto afecta la eficiencia de las consultas. Corrección: Entender que la 'nativa' implica indexación y consulta directa de la estructura.
- Aplicar NXDB a datos puramente relacionales: Intentar modelar datos tabulares simples en XML puede introducir complejidad innecesaria y penalizar el rendimiento. Corrección: Evaluar la naturaleza de los datos y si su estructura jerárquica es intrínseca o artificial.
- Subestimar la curva de aprendizaje de XQuery/XPath: Asumir que son triviales para un desarrollador SQL puede llevar a retrasos. Corrección: Planificar tiempo para la formación y práctica en estos lenguajes de consulta.