Inicio‎ > ‎Recursos‎ > ‎

Criterios de corrección de prácticas

La mayor parte de las prácticas de FBD se evalúan a partir de ejercicios basados en los conceptos resaltados en nuestras páginas sobre SQL y de la base de datos TiendaOnLine.

Supuesto uno de estos ejercicios, teniendo en cuenta que la casuística es bastante extensa y, por tanto, no abarcable en su totalidad, sí podemos dar unas ideas generales de aquello que consideramos errores más frecuentes. Evidentemente, algunos de ellos son casos que pudieran no haberse visto todavía en clase según haya avanzado el curso más o menos. La acumulación de estos errores en la respuesta a un ejercicio es lo que hace que la escala de penalizaciones se haya establecido en:

  • Sin fallos relevantes (-0 %)
  • Fallos menores (-10 %)
  • Fallos leves (-20 %)
  • Fallos importantes (-50 %)
  • Fallos graves (-100 %)
Eso no quita el que, en determinadas circunstancias, la nota se modifique ligeramente y no coincida con esos porcentajes, tanto positiva como negativamente. Igualmente, salvo que se puedan considerar eximentes ocasionales, la norma básica es que el ejercicio debe obtener el resultado esperado según el estado de la base de datos; es posible que se obtenga el resultado esperado pero en otro orden o faltando alguna columna solicitada en el enunciado, siendo estos errores tratados como importantes o menores según corresponda. Y, sobre todo, la dificultad del ejercicio también obliga a que ciertos criterios deban matizarse y no aplicarse con rigurosidad extrema. En definitiva, esto es una guía, no un sistema automático de corrección.

Clasificación de errores

Fallos graves (-100 %)

  1. Falta alguna tabla.
  2. Poner tablas de más, que no son necesarias y que afectan al resultado.
  3. Tablas que no están correctamente enlazadas.
  4. Poner condición not null a columna con restricción primary key.
  5. Select distinct (clave primaria); se entiende que cuando no se utilizan otras columnas.
  6. Faltan condiciones de filtrado de filas y afecta al resultado.
  7. Fallos de sintaxis graves.
  8. Cualquier error, si la orden es muy simple y sencilla de resolver.

Fallos importantes (-50 %)

  1. Poner más tablas de las necesarias (estando bien enlazadas) aunque no afecte al resultado.
  2. No utilizar distinct, order by, etc. cuando se ha pedido en el enunciado.
  3. Ausencia de paréntesis para modificar la precedencia de operadores and y or.
  4. Falta alguna columna de las solicitadas en el enunciado como salida.
  5. Se confunde count(x) con sum(x) y similares.

Fallos leves (-20 %)

  1. Poner más tablas de las necesarias (estando bien enlazadas) si no afecta al resultado.

Fallos menores(-10 %)

  1. Falta columna ‘no clave’ en group by (ejemplo, articulo.cod para poder visualizar articulo.nombre, en ciertos casos que sí es recomendable usarlo).
  2. Orden inverso o distinto al solicitado.
  3. Poner condiciones extra (por ejemplo, A=B and B=C and A=C).
  4. Usar operador like como una igualdad ( columna like 'hola' ).
  5. Utilizar operador IN para comparar con un solo valor. ( columna IN ('hola') ).
  6. Uso inadecuado operador like (por ejemplo, ‘%%L’ o like ‘10%’ para comparar fechas ‘del día 10’).
  7. No usar comillas en datos tipo carácter o fechas siempre que no genere un error de sintaxis o de ejecución (hay casos especiales como pedir year(fecha) que devuelve un tipo especial que podemos considerar un entero).
  8. Datos tipo numérico entre comillas.
  9. Otros fallos de sintaxis leves.

Comentarios

Fallos graves

Si la orden tiene errores de sintaxis graves (poner el where delante del from, por ejemplo), le faltan tablas, no se han enlazado o se han utilizado más de las debidas con el resultado de que la salida no es la esperada, se considera que el ejercicio está completamente mal. Si faltan condiciones en el where lo normal es que el resultado tampoco sea el esperado o que, coincidiendo con el resultado esperado, se deba a una casualidad, a que en el estado de base de datos actual ocurre así pero en uno futuro ya no coincidiría.

Otros conceptos tienen que ver con la comprensión del funcionamiento de las restricciones del modelo relacional como, por ejemplo, where articulo.cod is not null, condición totalmente innecesaria puesto que articulo.cod es una clave primaria.

Fallos importantes

Por ejemplo, usar el modificador distinct en una salida de ciertos ejercicios se considera un error de concepto: select distinct cod, nombre from articulo es imposible que genere filas duplicadas. Téngase en cuenta que otros ejercicios, aunque muestren una columna clave, sí pueden generar duplicados y este criterio no es aplicable. 

Si no se realizan ordenaciones o eliminación de duplicados cuando explícitamente se solicita en el ejercicio, también se considera un error grave, así como otros casos que afectan al resultado como puede ser el correcto parentizado de las condiciones lógicas (and y or).

Fallos menores

Aquí se mezclan pequeños fallos de comprensión de ciertos operadores con usos que cargan, potencialmente, al motor de base de datos con trabajo adicional. Piénsese en escribir un número como si fuera una cadena de caracteres (entre comillas). El gestor de la base de datos detecta que el tipo de datos no es el adecuado y antes de poder hacer nada, realiza un cambio automático de tipos de datos (de varchar a int, por ejemplo) con lo que el resultado final sí es el esperado. No obstante, si nos ponemos en un contexto en el que esa misma consulta se lance miles de veces, ese mínimo tiempo se multiplica y puede generar una degradación importante en el tiempo de respuesta del motor de base de datos.