Pregunta 34 bloque I y II

[Ruben2005]

Buenas,

tengo una duda de por qué es la buena la C? Alguien me puede instruir?

Creia que siempre que hubiera un sum necesitaria un group by, no?

Muchas gracias

[Julio]

Bueno, siempre no, si en la SELECT solo se selecciona un SUM(campo), el GROUP BY se considera implícito, pero en este caso no es así porque también se selecciona un campo, así que para mí es evidente que la sentencia está mal.

Yo no le veo ningún defecto a la b), la a) está mal porque según ISO 9075 solo se puede poner un * así a palo seco si es lo único que se selecciona, si no hay que especificar el "SP."

Si alguien necesita el estándar ISO SQL, de aquí se puede bajar un draft bastante avanzado, suficiente de sobra para esto de lo que hablamos, que viene en la parte 2 - Foundation. La especificación de la SELECT se puede ver en el punto 7.12

[minotino]

Estoy de acuerdo, podemos impugnarla

[chapacan]

Por favor, ¿Alguien podría explicarme cuál es el procedimiento para impugnar una pregunta/respuesta?

Muchas gracias y un saludo.

[Ruben2005]

Julio, me referia a eso. Que si no hay otro campo no es necesario hacer un group by, pero en este caso es obligatorio.

Cómo impugnamos?

[Ruben2005]

He cogigo un texto de impugnación del TIC A. En el TIC B es igual??
Y se remite a la dirección cps@inap.map.es


D. ..., con DNI ..., con domicilio en calle ... de la localidad de ..., teléfono ..., y en calidad de opositor a las pruebas selectivas para el ingreso en el Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

EXPONE:
que en relación con la pregunta número 34 del Bloque I y II del Primer Ejercicio de las Pruebas selectivas para el ingreso en el Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado celebradas el pasado 14 de Junio, ruega se tengan por presentadas y se tomen en consideración las siguientes

ALEGACIONES:

1º.-

2º.-

SOLICITA:
que la pregunta 34 del Bloque I y II sea anulada.


Madrid, a 23 de Junio de 2008.


Fdo:

...


A la atención de la Comisión Permanente de Selección para el ingreso en el Cuerpo de Gestión de Sistemas e Informática de la Administración del Estado

[Julio]

Supongo que esa misma vale, Ruben2005.

Yo no voy a pedir que se anule, sino que se cambie a la respuesta b) porque entiendo que es una errata de la plantilla.

[Ruben2005]

Ok, estoy totalmente de acuerdo contigo.

Me puedes mandar el texto que vas a enviar y lo intento completar si veo algo más para enviarlo?

De todas formas la dirección que pongo es a la que hay que mandarla, no?

Un saludo

[Julio]

La dirección de correo es la que pones. De todas formas yo prefiero enviarlo por registro (trabajo en un Ministerio y tengo el registro a dos pasos) porque así uno se asegura de que les llega.

Yo he puesto las siguientes alegaciones:

1º.- que en dicha pregunta número 34 (Bloques I y II) se solicitaba indicar qué sentencia SQL está formada correctamente.

2º.- que la plantilla provisional de respuestas publicada indica que se trata de la opción c) SELECT SP.IdP, sum(distinct SP.Cant) from SP

3º.- que de acuerdo con el estándar SQL (ISO 9075:2003), al no incluir una cláusula GROUP BY, la sentencia anterior da lugar a una tabla no agrupada.

4º.- que de acuerdo con el estándar SQL (ISO 9075:2003), al tratarse de una tabla no agrupada, si uno de los campos seleccionados está incluido dentro una función agregada (en este caso el campo SP.Cant está incluído en la función agregada “sum”), entonces TODOS los campos seleccionados deben aparecer dentro de alguna función agregada, lo cual no se da porque el primer campo seleccionado es SP.IdP, que no está incluido en ninguna función agregada.

5º.- que de acuerdo con lo explicado, la sentencia SQL dada por el apartado c) no está formada correctamente según el estándar SQL. De hecho es sencillo comprobar que dará un error de sintaxis al ser probada en el analizador de consultas de cualquier SGBD actual.

6º.- que la misma argumentación permite comprobar que la respuesta d) tampoco sería válida.

Se incluye a continuación la parte de la especificación del formato para la cláusula SELECT según el estándar ISO 9075:2003 necesaria para comprobar las siguientes alegaciones (punto 7.12 del citado estándar):

Código: Seleccionar todo

<query specification> ::=
    SELECT [ <set quantifier> ] <select list> <table expression>

<select list> ::=
    <asterisk>
  | <select sublist> [ { <comma> <select sublist> }... ]

<select sublist> ::=
    <derived column>
  | <qualified asterisk>

<qualified asterisk> ::=
    <asterisked identifier chain> <period> <asterisk>
  | <all fields reference>

<asterisked identifier chain> ::=
    <asterisked identifier> [ { <period> <asterisked identifier> }... ]

<asterisked identifier> ::= <identifier>

<derived column> ::= <value expression> [ <as clause> ]

7º.- que de acuerdo con esta especificación, si uno de los campos seleccionados en una cláusula SELECT es un asterisco (*), entonces no pueden aparecer más campos en la cláusula (definición de “<select list>”).

8º.- que de acuerdo a lo anterior, la sentencia especificada por la respuesta a) del formulario de examen estaría incorrectamente formada.

9º.- que de acuerdo con esta especificación, la sentencia especificada por la respuesta b) del formulario está correctamente formada, pues se selecciona un “qualified asterisk” y una “value expression”, concretamente una “numeric value expression”, especificada por el punto 6.26 del estándar referido anteriormente.

10º.- que según lo expuesto, se entiende que hay una errata en la plantilla provisional de respuestas, puesto que la única sentencia correctamente formada de las que aparecen en el formulario de examen es la b) y no la c)

[emejou]

Solo tengo una duda que me hace pensar que la b no sería tampoco correcta, y por tanto ninguna sería valida (aunque preferiría que diesen por buena la b ) que anularla. ¿el estandar permite operaciones +, - , / ?. ¿Eso no es una añadido que hace cada SGBD?

[Julio]

Sí, emejou, sí lo permite, lo comprobé en el estándar, lo que pasa es que tampoco he querido meter medio estándar en las alegaciones porque iba a quedar muy engorroso y eso dificulta la lectura, he preferido limitarme a que quede claro lo del *, que quizás es menos conocido, pero bueno, a lo mejor es buena idea que alguno que quiera impugnar incluya esa parte, así tienen un poco de todo para tener claras las cosas.

[jp]

Hola es la primera vez que escribo en este foro,
estoy mirando tambien las impugnables.

Yo tambien he puesto la b y estoy de acuerdo en lo que decis pero me hecho un ejemplillo es postgres y tanto a) como b) producen el mismo resultado ...


=# select *, (sp.cant/12) from sp;
ids | idp | cant | ?column?
-----+-----+------+--------------------
1 | 1 | 1 | 0.0833333333333333
1 | 2 | 2 | 0.166666666666667
2 | 1 | 3 | 0.25
2 | 2 | 4 | 0.333333333333333
(4 filas)

=# select sp.*, (sp.cant/12) from sp;
ids | idp | cant | ?column?
-----+-----+------+--------------------
1 | 1 | 1 | 0.0833333333333333
1 | 2 | 2 | 0.166666666666667
2 | 1 | 3 | 0.25
2 | 2 | 4 | 0.333333333333333
(4 filas)

[Julio]

Sí, jp, los SGBD no suelen implementar SQL siendo 100% fieles al estándar, pero en el examen nos preguntan por el SQL estándar (ISO 9075), y por lo que he puesto por ahí arriba, según el estándar si pones un * solitario en la SELECT ya no puedes poner nada más, si quieres poner algo más tienes que ponerlo con el cualificador, en este caso "SP.", que es lo que hace la b)

[jp]

Pues na entonces, si me lo permites yo tambien empleare tu texto

[Julio]

La verdad es que creo que sería bueno que cada cual usara su propia argumentación, porque para el CPS recibir 10 copias de lo mismo lo único que les va a aportar es aburrimiento. Si quereis que nos hagan caso, intentad aportar cada uno vuestro punto de vista.