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:

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

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

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

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


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: