Preparar el examen · Bases de Datos · DAM

Qué puede evaluarse

Trampas habituales antes del examen

• 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.