Id Pregunta 10166 -Test10 - Pr90 - BBDD - Normalización

[mjlpbfgpgr]

Muchas gracias smaug1985

[a1cuevas]

El dni y el teléfono corresponden a Manolo, pero por un error el nombre está mal, no esquey haya otra persona con el mismo dni. Por esto nombre y telefono, sí dependen del dni.
Y no puede haber atributos que no dependan funcionalmente de la clave primaria para que esté en 2FN.
Así que la 2ª y 3ª forma normal, descartada....

Errores se pueden introducir en la fecha, en el teléfono, en el dni, en el nombre... para evitarlos se tienen las diferentes restricciones como check-unique para el atributo dni y podrías tener la misma definición de tabla sin la fila del dni q has respetido.
En mi opinión si codigo es clave primaria (identificador único) la tabla se encuentra en segunda forma normal

[smaug1985]

El dni y el teléfono corresponden a Manolo, pero por un error el nombre está mal, no esquey haya otra persona con el mismo dni. Por esto nombre y telefono, sí dependen del dni.
Y no puede haber atributos que no dependan funcionalmente de la clave primaria para que esté en 2FN.
Así que la 2ª y 3ª forma normal, descartada....

Errores se pueden introducir en la fecha, en el teléfono, en el dni, en el nombre... para evitarlos se tienen las diferentes restricciones como check-unique para el atributo dni y podrías tener la misma definición de tabla sin la fila del dni q has respetido.
En mi opinión si codigo es clave primaria (identificador único) la tabla se encuentra en segunda forma normal

Según lo que yo entiendo por objetivo de la tabla, es necesario tener varias veces el mismo DNI, ya que son solicitudes, si no dni sería también parte de la clave. El problema esque teléfono y nombre dependen de dni y no de la clave primaria.
De todas formas, revisando bien lo que comentais y mirandolo, yo estaba equivocado, con un identificador único la tabla se considera directamente en 2FN, siempre que antes esté en 1FN. Pero cómo suponemos que podemos poner varios teléfonos... no está en primera forma normal. De todas formas, falta información en el enunciado, ya que la pregunta tiene diferentes interpretaciones.

[IngenieroInformatico]

En la pregunta

Sea la relación SOLICITUD (CODIGO, FECHA, DNI_SOLICITANTE, NOM_SOLICITANTE, TEL_SOLICITANTE) y el atributo
CODIGO su clave primaria, ¿en qué forma normal se encuentra?
a) Sin normalizar
b) 1ª Forma normal
c) 2ª Forma normal
d) 3ª Forma normal

Dan como respuesta correcta la a) pero si Codigo es único y clave primaria como dice el enunciado ¿por qué no está en primera e incluso en este caso 2ª forma normal?

Está en segunda forma normal.

En este caso, CODIGO es clave primaria y DNI_SOLICITANTE sería clave candidata. No existen dependencias parciales entre los aributos, por eso está en 2FN.

[IngenieroInformatico]

Yo tampoco entiendo muy bien esto. La 1FN se supone que son los grupos repetitivos, es decir, que para que no estuviese en 1FN alguno de los atributos debería aceptar múltiples valores, y así en principio parece que todos los atributos son únicos, ¿no?

Tampoco entiendo la visión viciada

Exacto, con el enunciado así como está, la C podría considerarse correcta, porque estaría en 1FN ya que no hay ninguna especificación sobre relaciones entre atributos y se podría asumir que los datos del solicitante dependen de la solicitud; y la clave primaria es simple, por lo que también está en 2FN.

La "versión viciada" que digo es referente a los que, por nuestra experiencia con BDs, ya con ver los nombres de los atributos asumimos relaciones de dependencia entre ellos. En ese caso, como dice ticvman: NOM_SOLICITANTE y TEL_SOLICITANTE dependen funcionalmente de DNI_SOLICITANTE (que no forma parte de la clave) por lo que la respuesta correcta sería la A.

DNI_SOLICITANTE no es parte de la clave primaria pero es una clave por sí misma, en este caso, clave candidata. Al no existir dependencias parciales de ninguna de las dos claves, por no ser no ser compuesta ninguna de las dos claves, la relación está en 2FN.

[IngenieroInformatico]

Yo tampoco entiendo muy bien esto. La 1FN se supone que son los grupos repetitivos, es decir, que para que no estuviese en 1FN alguno de los atributos debería aceptar múltiples valores, y así en principio parece que todos los atributos son únicos, ¿no?

Tampoco entiendo la visión viciada

Estoy de acuerdo, para mí la correcta es 1FN ya que no existen grupos repetitivos.

Quizá la trampa de la pregunta sea que en el enunciado deberían haber especificado este punto y, como no lo hacen, dan pie a que exista una solicitud con varios DNI solicitantes en el modelo.

Efectivamente, el que se repita el DNI, es decir, que DNI no sea clave como yo he supuesto en mis respuestas anteriores, sería indicativo de que la relación estaría sin normalizar, ya que no habría forma de discernir entre una tupla y otra.

Vaya trucos que se gastan

[IngenieroInformatico]

Aporto mi granito, aunque cómo la mayoría de vosotros, creo que falta un punto por explicar.

Primero voy a por qué no puede ser la 2FN
Pongo la siguiente tabla cómo ejemplo:
| CODIGO | FECHA | DNI_SOLICITANTE | NOM_SOLICITANTE | TEL_SOLICITANTE |
-----------------------------------------------------------------------------
| 4 | 01-01-1970 | 45000001A | Pepito | 952111333 |
| 5 | 01-01-1970 | 45000002A | Manolo | 952111332 |
| 6 | 01-01-1970 | 45000003A | Juanito | 952111331 |
| 7 | 01-01-1970 | 45000001A | Pepito | 952111333 |
| 8 | 01-01-1970 | 45000002A | Manolo | 952111332 |

Cómo podeis ver, se ve claramente que nombre y telefono dependen del dni. No es vicio. Podría ocurrir el caso de que se añadiera la siguiente fila:
| 9 | 01-01-1970 | 45000002A | Melani | 952111332 |

El dni y el teléfono corresponden a Manolo, pero por un error el nombre está mal, no esquey haya otra persona con el mismo dni. Por esto nombre y telefono, sí dependen del dni.
Y no puede haber atributos que no dependan funcionalmente de la clave primaria para que esté en 2FN.
Así que la 2ª y 3ª forma normal, descartada.

Ahora viene la duda de si es 1FN o sin normalizar. Para que esté en 1FN, no puede haber grupos repetitivos. Yo entiendo, aunque falta información o bien en la descripción de la relación o en el enuciado, que en teléfono se puede poner
uno o varios teléfonos. Aunque no se especifica en ningún sitio. Si el atributo se llamara TELEFONOS_SOLICITANTE no habría duda. Pero mejor ponernos siempre en el peor caso.
Asi que al poder introducirse varios teléfonos, tampoco está en 1FN, con lo que sólo queda que la relación está sin normalizar.
Esta última conclusión, la saco sabiendo la respuesta, en el examén no me la juego y la dejaría sin contestar, porque tiene trampa :D:D

De acuerdo en todo salvo un apunte (relativo a lo que está en negrita). La definción de 2FN no es ésa, sino que "no pueden existir dependencias parciales de cualquier clave". Ejemplo.

Relación ABCDE. A y BC son clave. A es clave primaria. BC, por tanto, es clave candidata. Si existe una dependencia C->D, la relación no estaría en 2FN y habría que sacar esa dependencia a otra tabla y dejar la principal como ABCE.

[El1del0]

Atendiendo a los nombres de las columnas y de la tabla, y entendiendo el dominio funcional y dependencia de éstos (esto es básico, y creo que no hay confusión en los campos yel nombre de tabla de la pregunta, al ser de uso común): la respuesta es la a)

Explicación:
Ni siquiera cumple la 1FN al no cumplirse que todos los campos que no forman parte de la clave primaria dependan de ésta. (siendo concreto, una persona puede hacer n solicitudes en fechas diferentes, por tanto a partir del código de solicitud no se puede identificar únivocamente los valores de dichas columnas)

ver definición de 1FN: http://es.wikipedia.org/wiki/Normalizac ... s_de_datos

Un saludo