Criterios de corrección SQL

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 %)

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

Fallos graves (-100 %)

Falta alguna tabla.
Poner tablas de más, que no son necesarias y que afectan al resultado.
Tablas que no están correctamente enlazadas.
Poner condición not null a columna con restricción primary key.
Faltan condiciones de filtrado de filas y afecta al resultado.
Fallos de sintaxis graves, la orden no se ejecuta.
Cualquier error, si la orden es muy simple y sencilla de resolver.

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 (-50 %)

No utilizar distinct, order by, etc. cuando se ha pedido en el enunciado.
Ausencia de paréntesis para modificar la precedencia de operadores and y or.
Falta alguna columna de las solicitadas en el enunciado como salida.
Se confunde count(x) con sum(x) y similares.
Poner condiciones del where en having.

Por ejemplo, usar el modificador distinct en una salida de ciertos ejercicios se considera un error de concepto: select cod, nombre from articulo es imposible que genere filas duplicadas y no necesita select distinct. 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 leves (-20 %)

Poner más tablas de las necesarias (estando bien enlazadas) si no afecta al resultado.
Utilizar group by para eliminar duplicados.
Usar left join sin motivo.
Otros usos que demuestren poca comprensión de la función de cada elemento de una consulta.

Aquellos que no alteran el resultado pero, hablando de la consulta en su conjunto, son fruto de conceptos y mecánicas mal comprendidas, vicios o incluso falta de atención.

Fallos menores(-10 %)

Falta columna ‘clave’ en group by (ejemplo, de group by articulo.nombre puede ser aconsejable group by articulo.nombre,articulo.cod) en ciertos casos que sí es recomendable usarlo.
Orden inverso o distinto al solicitado.
Poner condiciones extra (por ejemplo, A=B and B=C and A=C).
Usar operador like como una igualdad ( columna like 'hola' ).
Utilizar operador IN para comparar con un solo valor. ( columna IN ('hola') ).
Uso inadecuado operador like (por ejemplo, ‘%%L’ o like ‘10%’ para comparar fechas ‘del día 10’).
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).
Datos tipo numérico entre comillas.
Select distinct x... cuando x no admite duplicados.
Select distinct x... group by x puesto que group by ya elimina duplicados.
Otros fallos de sintaxis leves.

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.

Preguntas de definición y manipulación de datos

En aquellas preguntas acerca de create/drop table e insert/delete/update que están enunciadas por apartados, la corrección consistirá en una cuenta de errores, de apartados mal contestados:

- 0 % de penalización: todos los apartados correctos, puntuación máxima
- -20 %: 1 apartado incorrecto o incompleto.
- -50 %: 2 apartados incorrectos o incompletos.
- -100 %: 3 o más apartados incorrectos o incompletos.

Google Sites

Report abuse