Tengo un problema con la segunda forma normal (2NF) y no he podido resolverlo usando Google. Me está volviendo loco porque soy maestra y no quiero enseñar cosas equivocadas a mis alumnos.

Tengamos una tabla con 5 campos.

Graduaciones = {StudentName, SubjectCode, SubjectName, #Exam, Grade}

Las dependencias son de esta manera:

StudentName, SubjectCode, #Exam -> Grade

SubjectCode -> SubjectName

SubjectName -> SubjectCode

Por lo tanto, la clave candidata 1 es {StudentName, SubjectCode, #Exam} y la clave candidata 2 es {StudentName, SubjectName, #Exam} .

Los atributos principales son {StudentName, SubjectCode, SubjectName, #Exam} y los atributos no principales son Grade

Según la definición de la segunda forma normal, un atributo no primo no puede depender de una parte de una clave candidata. El único atributo no principal (Grado) no depende de una parte de una clave candidata, por lo que esta tabla aparece en 2NF.

El problema es que creo que algo anda mal (y podría estar equivocado). Creo que los sujetos deberían tener su propia mesa.

Graduaciones = {StudentName, Código de materia, #Exam, Grado}

Sujetos = {Código del sujeto, Nombre del sujeto}

Pero 2NF no produce esto. 3NF se trata de dependencias entre atributos no primos, por lo que tampoco produce esto. Pero me parece que este es el resultado correcto, porque no tiene redundancia.

Supongo que si el atributo no primo se definiera como "atributo que no es una clave candidata", 2NF produciría el resultado deseado. Pero lo he comprobado una y otra vez y el atributo no principal se define como "atributo que no PERTENECE a una clave candidata".

¿Qué estoy haciendo mal?

Su relación está en 3NF, (y no solo en 2NF), ya que, como usted dice, el único atributo no primo es Grade , que solo aparece en el lado derecho de sus FD.

La relación no está en BCNF, porque el lado izquierdo de los dos FD pequeños no es una superclave.

Sin embargo, puede descomponer sin pérdidas la relación con ( SubjectCode , SubjectName ) y ( StudentName, SubjectCode, #Exam, Grade ) o ( StudentName, SubjectName, #Exam, Grade )

Esta descomposición le proporciona dos relaciones BCNF y conserva todas las dependencias funcionales. Esto no siempre es posible (siempre se puede descomponer una relación con 3NF, pero no necesariamente con BCNF).

2NF

Si desea un ejemplo de 2NF (y no de 3NF), su relación debe contener dependencias transitivas.

Por ejemplo, supongamos que tiene una columna de Puntuación. Intuitivamente Puntaje-> Calificación ya que todos los exámenes con el mismo puntaje deberían obtener la misma calificación (de lo contrario sería bastante injusto), pero tenga en cuenta que no podemos decir Grado-> Puntaje ya que varios puntajes pueden tener la misma calificación (11% y 12% probablemente sería "Fail", por ejemplo).

Ahora tu relación es:

Graduaciones ( StudentName, SubjectCode, SubjectName, #Exam, Score, Grade )

y tiene una nueva forma de redundancia ya que cada vez que ingresa un resultado con el mismo puntaje que otro registro de Graduaciones, también tiene que repetir la calificación correspondiente. Para llegar a 3NF, puede descomponerse en

ScoreGrades ( puntaje, grado )

con Score como clave, y

Puntuaciones ( StudentName, SubjectCode, SubjectName, #Exam, Score )

Tienes razón en todo lo que dices. El código de sujeto y el nombre de sujeto deben ir en su propia tabla para imponer las dependencias deseadas. Este es un buen ejemplo de por qué 2NF y 3NF no son suficientes para producir buenos diseños de bases de datos; en su lugar, necesita el formulario normal de Boyce Codd (BCNF).

2NF y 3NF son reemplazados por BCNF, que prácticamente hace que los NF menores queden obsoletos *. BCNF es el más importante y posiblemente más simple de explicar y aplicar. Como profesor, le sugiero que pase más tiempo en BCNF y menos en 2NF y 3NF. Si una tabla satisface los requisitos de BCNF, entonces también satisface 2NF y 3NF.

* 3NF no es la forma normal con mayor preservación de dependencia. La forma normal de la clave elemental (EKNF) es. Estrictamente hablando, es EKNF, no BCNF, lo que hace que 3NF sea obsoleto, pero EKNF se descuida injustamente y la mayoría de los libros de texto y cursos ni siquiera lo mencionan. Lo que equivale a lo mismo es diseñar en BCNF y luego verificar que todas las dependencias deseadas y cualquier otra regla de integridad se pueda hacer cumplir adecuadamente; de ​​lo contrario, modifique el diseño. Ninguno de los NF es una solución completa para la integridad de los datos, pero BCNF generalmente se acerca y es el más fácil de explicar y usar.

No diré cuánto tiempo ha pasado desde que aprendí todo esto. Pero sí recuerdo que tenía un profesor que, después de enseñarnos debidamente el significado apropiado de "dependencia funcional" y "atributo no primo" y todas las demás palabras de moda, nos dio una serie de preguntas simples para ver si un normal particular Se alcanzó la forma. Veamos si puedo recordar eso hace mucho tiempo ...

Hemos identificado la (s) clave (s) candidata (s) por lo que hacemos esta pregunta sobre los atributos no primos restantes. En este caso, solo hay uno: grado.

¿Cuál es la información mínima absoluta que necesitamos para identificar de manera única la calificación? Necesitamos conocer al estudiante, la materia y el examen que se está tomando. Bien, esta es una de las claves candidatas.

EDITAR: VVV

Pero la respuesta podría haber sido el nombre del estudiante, el nombre de la asignatura y el examen. Esto coincidiría con la segunda clave candidata.

Suponiendo que SubjectCode y SubjectName son claves candidatas para la entidad Subject, no hay ninguna razón para tener estos dos campos aquí. Una referencia única a una fila en la tabla Temas es suficiente. Por lo tanto, podemos deshacernos por completo del campo SubjectName sin sacrificar la integridad del modelo.

Sin embargo, en mi respuesta original, en mi deseo de mostrar otro nivel de normalización, ignoré que SubjectName se había utilizado en una clave candidata y lo consideré simplemente otro atributo no primo. Supongo que era tan obvio para mí que este era un campo inútil, pensé que sería igual de obvio para todos y dado que de cualquier manera nos libramos del campo, ¿qué importaba?

Pero en lugar de eliminar esa parte de la respuesta, la guardaré para comparar.

EDICIÓN FINAL: ^ ^ ^

¿Cuál es la información mínima absoluta que necesitamos para identificar de forma exclusiva el nombre del sujeto?

SubjectName depende solo de SubjectCode, un subconjunto de la clave candidata. Entonces esta tupla no está en 2nf. SubjectCode debe ser la clave principal de una tabla de Subject para que sea la ubicación adecuada para colocar SubjectName. Elimínalo de esta tupla y ahora está en 2nf.

Si hacemos la pregunta de un atributo y la respuesta no es toda o parte de la clave candidata, entonces la tupla no está en 3nf. Pero esta tupla también es trivial en 3nf y más, ya que nos hemos quedado sin campos para hacer preguntas. ;)

Nota: cuando decimos "normalizar", nos referimos a un proceso que se aplica a una entidad lógica. Como la tupla suministrada parece ser la definición de una entidad llamada "grado", podemos normalizarla. Sin embargo, en un momento dije "esta tupla no está en 2nf", que más correctamente debería haber estado, "esta entidad no está en 2nf". Pido disculpas si esto ha causado confusión.

El único atributo no principal (Grado) no depende de una parte de una clave candidata, por lo que esta tabla aparece en 2NF.

Está en 2NF.

El problema es que creo que algo anda mal (y podría estar equivocado). Creo que los sujetos deberían tener su propia mesa.

No hay razón para esperar que los sujetos tengan su propia tabla para una descomposición de la tabla original a 2NF . Estás confundiendo una vaga noción de "debería" con lo que realmente te da cualquier forma normal en particular.

3NF se trata de dependencias entre atributos no primos, por lo que tampoco produce esto.

"3NF se trata de dependencias entre atributos no primos" no es una definición adecuada de 3NF, por lo que "tampoco produce esto" no es una conclusión sólida. Aunque la aplicación de una definición real muestra que la tabla está en 3NF, no se necesita una tabla de estudiante. Pero, de nuevo, no hay razón para esperar que lo haya.

Pero me parece que este es el resultado correcto, porque no tiene redundancia.

Una vez más, la "redundancia" es vagamente inútil, por lo que su "porque" y la expectativa de la mesa del estudiante no son correctos. Diferentes formas normales están libres y sujetas a tipos particulares de anomalías y "redundancia" asociada. Pero puede quedar otra "redundancia" no abordada por la normalización.

Esta tabla no está en BCNF, ya que tiene FD que no están fuera de CK. Descomponerlo por BCNF lleva a tener la mesa del estudiante. BCNF es la forma normal más alta para tratar con JD (dependencias de unión) que acompañan a los FD. Sin embargo, otros JD pueden ser problemáticos (es decir, no "implicados por las CK") y deberían eliminarse mediante la normalización a 5NF.

PD La tabla original también satisface el FD {StudentName, SubjectName, #Exam} -> Grade.

Las dependencias son de esta manera:

¿Qué se supone que significa esto? No es un claro.

¿Quiere decir, "Estos son todos los DF no triviales que tienen"? No, porque implican el cuarto. "¿Aquí hay algunos FD que aguantan"? No, eso significa que los FD en el cierre transitivo se mantienen, pero no dice que otros no se mantengan, sin embargo, usted pudo determinar los CK. "¿Los FD que se mantienen son exactamente los que están en el cierre transitivo de estos"? Si quisieras decir eso, solo lo sabrías si lo hubieras mostrado , es decir, deberías haber encontrado ese cierre (generalmente, a través de una cubierta mínima / canónica) y luego haber demostrado que no hay otros DF; ¿Tuviste? De todos modos, lo que escribiste simplemente no significa eso. Así que espero que no estés razonando a fondo sobre la situación de FD y CK.

Tienes razón, los sujetos requieren su propia tabla. Si elige una de sus claves candidatas, subject_codeo se subject_nameconvierte en una clave candidata no primaria. Luego elimina el campo de materias no primarias de la tabla de calificaciones.

Tiene una dependencia funcional en el tema para el que tiene dos identificadores únicos. Esto se demuestra por la dependencia transitiva entre subject_codey subject_name. Esto indica un requisito para crear una tabla que contenga esos dos campos y eliminar uno de estos campos de todas las demás tablas. Esta tabla bien podría tener columnas dependientes adicionales, aunque no veo ninguna en este ejemplo. En la tercera forma normal que ha seleccionado.

la calificación depende de los otros tres campos (clave de candidato) en la nueva tabla de calificaciones. Como se indicó anteriormente, debe elegir uno de los campos candidatos para la tabla de temas. Normalmente, este sería un valor de código si está disponible, ya que tienden a ser más estables. El modelo resultante está en 3nf ya que todos los campos sin clave dependen completamente de los campos en la clave primaria.

Es probable que un análisis posterior del problema (requisitos) produzca una tabla de sesiones en la que se apliquen las marcas. Es poco probable que el modelo actual cubra a un estudiante que repite un curso. Esto se trataría en una lección posterior.

También es probable que los estudiantes se conviertan en una mesa separada, ya que es posible tener varios estudiantes con el mismo nombre. Esto probablemente se resolvería mediante la adición de una clave primaria sintética (¿número de estudiante?).

subjects --->  sessions ---+--> grades
students  -----------------+

Me estoy preparando para eliminar esto, ya que se considera incorrecto

El nombre del sujeto también es un atributo no primo y depende de una parte de la clave primaria Código del sujeto (rompe la regla; no debe existir ninguna dependencia parcial de ninguna columna en la clave primaria).

Esto está prohibido en la segunda forma normal y, por lo tanto, debe colocarse en su propia mesa como sospechaba.

Creo que lo que descubrió es identificar dos conjuntos de claves candidatas, cuando crea la tabla debe elegir un conjunto de claves candidatas para hacer la clave primaria. Las columnas restantes se convierten en atributos no primos, es decir, si elige su segunda clave candidata, el Código de sujeto se convierte en un atributo no primo que depende de parte de la clave primaria (Nombre del sujeto) y debe colocarse en su propia tabla.

Es importante enseñar las formas normales primera, segunda y tercera en orden a medida que se desarrollan entre sí. El BCNF también es esencialmente una extensión a la tercera forma normal, por lo que es esencial una fuerte comprensión de los niveles inferiores.

Más lejos; Un desarrollador experimentado no considerará los niveles independientes de normalización porque muchas reglas se vuelven intuitivas.

También sabrán cuándo romper las reglas de normalización para resolver ciertos problemas de diseño y optimización. La normalización debe tratarse como una guía para un buen diseño, no como una regla estricta, creo que también sería un buen punto de enseñanza.