Ejercicios y práctica · Bases de Datos · DAM

Qué deberías ser capaz de hacer

Errores frecuentes que la práctica debería detectar

• Confundir una BDOR con una Base de Datos Orientada a Objetos (BDOO): Las BDOR mantienen el modelo relacional como base, añadiendo características de objetos, mientras que las BDOO son puramente orientadas a objetos y no se basan en el modelo relacional. La causa es no entender la naturaleza híbrida de las BDOR. Corrección: Recordar que las BDOR son una extensión del modelo relacional, no un reemplazo.
• Intentar aplicar la normalización relacional de forma estricta a los tipos objeto: Aunque la normalización es importante, el uso de tipos objeto y colecciones puede implicar cierta desnormalización controlada para mejorar el rendimiento y la cohesión de los datos. La causa es la aplicación rígida de reglas relacionales. Corrección: Evaluar el equilibrio entre normalización y encapsulación de objetos para optimizar el diseño.
• No implementar el cuerpo de un método declarado: Si se declara un método en el `CREATE TYPE` pero no se define su lógica en un `CREATE TYPE BODY`, el tipo de objeto será inválido y no se podrá usar. Causa: Olvido o desconocimiento de la necesidad del `TYPE BODY`. Corrección: Asegurarse de que cada método declarado tenga su implementación correspondiente en un `CREATE TYPE BODY`.
• Exceder el tamaño máximo de un VARRAY: Intentar insertar más elementos en un VARRAY de los que su tamaño máximo permite generará un error. Causa: No planificar adecuadamente el tamaño del VARRAY o usarlo para colecciones de tamaño impredecible. Corrección: Usar `NESTED TABLE` para colecciones de tamaño ilimitado o reevaluar el tamaño máximo del `VARRAY` si es posible.
• Omitir la cláusula `NESTED TABLE ... STORE AS` al crear una tabla con una columna de tipo `NESTED TABLE`: Esto resultará en un error de sintaxis o de compilación, ya que el SGBD necesita saber dónde almacenar los datos de la tabla anidada. Causa: Desconocimiento de que las tablas anidadas requieren un almacenamiento físico separado. Corrección: Incluir siempre `NESTED TABLE nombre_columna_coleccion STORE AS nombre_tabla_almacenamiento`.
• Intentar crear una `REF` a una tabla que no es una tabla de objetos o no tiene OID: Las referencias a objetos solo funcionan con tablas de objetos que tienen un identificador de objeto. Causa: No comprender el requisito de OID para las referencias. Corrección: Asegurarse de que la tabla a la que se hace referencia se haya creado con `OF nombre_tipo_objeto OBJECT IDENTIFIER IS SYSTEM GENERATED`.
• Intentar acceder a atributos de un objeto sin la notación de punto: Por ejemplo, `SELECT e.ciudad FROM EMPLEADOS e` en lugar de `SELECT e.direccion.ciudad FROM EMPLEADOS e`. Causa: Tratar los atributos de un objeto anidado como columnas de la tabla principal. Corrección: Recordar que los atributos de objetos anidados se acceden a través de la notación de punto, siguiendo la jerarquía del objeto.
• Modificar colecciones de forma incorrecta: Intentar actualizar elementos individuales de un `VARRAY` sin reemplazar la colección completa, o no usar `TABLE()` para modificar `NESTED TABLE`. Causa: Desconocimiento de las limitaciones y sintaxis específicas para la manipulación de colecciones. Corrección: Para `VARRAY`, generalmente se reemplaza la colección completa. Para `NESTED TABLE`, usar `UPDATE TABLE(...)` o `DELETE FROM TABLE(...)`.
• No identificar correctamente las claves primarias y foráneas.
• No aplicar las reglas de normalización, resultando en redundancia de datos.
• Ignorar la integridad referencial, llevando a datos inconsistentes.
• No documentar restricciones que no se pueden modelar directamente.
• Confundir el diseño conceptual con el lógico.
• **No usar delimitadores adecuados:** En algunos SGBD (como MySQL en modo script), las sentencias deben terminar con un delimitador (`;`). Si un script contiene bloques de código (procedimientos, funciones) que usan `;` internamente, es necesario cambiar el delimitador temporalmente. *Causa:* Desconocimiento del comportamiento del parser SQL. *Corrección:* Antes de definir un procedimiento/función, usar `DELIMITER //` (o similar) y restaurarlo con `DELIMITER ;` después del bloque.
• **Ejecutar scripts incompletos o con errores de sintaxis:** Un error en una sentencia puede detener la ejecución del script o dejar la base de datos en un estado inconsistente. *Causa:* Falta de revisión o prueba del script. *Corrección:* Probar siempre los scripts en un entorno de desarrollo antes de aplicarlos en producción. Utilizar transacciones si el SGBD lo permite para revertir cambios en caso de error.
• Asumir que todas las funciones de un SGBD existen igual en otro (por ejemplo, dar por hecho que MySQL soporta funciones con valor de tabla como SQL Server). Causa: generalizar sintaxis entre motores distintos. Corrección: verificar en la documentación oficial del SGBD concreto qué tipos de UDF soporta antes de diseñar la solución.
• Declarar una UDF como DETERMINISTIC cuando internamente usa CURDATE(), NOW() o una tabla que puede cambiar. Causa: no distinguir entre el resultado deseado y la dependencia real de la función. Corrección: si el resultado puede variar sin cambiar los parámetros de entrada, la función debe declararse NOT DETERMINISTIC, o rediseñarse pasando esos valores como parámetros explícitos.
• **Bucles infinitos:** No incluir una condición de salida o una modificación de la variable de control que garantice la terminación del bucle. *Causa:* Lógica de bucle incorrecta o incompleta. *Corrección:* Revisar cuidadosamente la condición del bucle y asegurarse de que la variable que controla la condición se actualice en cada iteración de manera que eventualmente la condición de salida se cumpla.