database - tipos - Normalización-2NF vs 3NF
segunda forma normal (5)
2NF permite que los atributos no primos sean funcionalmente dependientes de atributos no primos
pero
3NF permite que los atributos no principales dependan funcionalmente solo de la súper clave
Por lo tanto, cuando una tabla está en 3NF, está en 2NF y 3NF es más estricta que 2NF
Espero que esto ayude...
Luchando para ver las diferencias entre ellos. Sé que decimos que 2NF es "la clave completa" y 3NF "nada más que la clave".
Haciendo referencia a esta gran respuesta de Smashery: ¿Qué son 1NF, 2NF y 3NF en el diseño de la base de datos?
El ejemplo utilizado para 3NF es exactamente lo mismo que 2NF: es un campo que depende de un solo atributo clave. ¿Cómo es el ejemplo de 3NF diferente del de 2NF?
Gracias
2NF sigue la dependencia parcial, mientras que 3NF sigue la dependencia funcional transitiva. Es importante saber que el 3NF debe estar en 2NF y admitir la dependencia funcional transitiva.
Dado que usted hace una pregunta muy específica acerca de una respuesta para la pregunta existente aquí, hay una explicación de eso (y básicamente diré lo que dportas ya dijo en su respuesta, pero en otras palabras).
Los ejemplos de diseño que no están en 2NF ni en 3NF no son lo mismo.
Sí, la dependencia en ambos casos está en un solo campo.
Sin embargo, en el ejemplo no 2NF:
- la dependencia está en la parte de la clave primaria
mientras que en el ejemplo no 3NF (que está en 2NF):
- la dependencia está en un campo que no es parte de la clave primaria (y también se da cuenta de que en ese ejemplo sí satisface 2NF; esto es para mostrar que incluso si marca 2NF también debe verificar 3NF)
En ambos casos, para normalizar crearía una tabla adicional que no presentaría anomalías de actualización (ejemplo de anomalía de actualización: en ejemplo 2NF, ¿qué sucede si actualiza Coursename para IT101|2009-2 , pero no para IT101|2009-1 ? inconsistente = sin sentido = datos inutilizables).
Entonces, si memoriza la clave, la clave completa y nada más que la clave , que abarca tanto 2NF como 3NF, eso debería funcionar para usted en la práctica al normalizar. La distinción entre 2NF y 3NF puede parecerle sutil (pregunte si en la dependencia adicional los atributos de los que dependen los datos son parte de la clave candidata o no) y, bueno, así es, simplemente acéptelos.
Has logrado la 3ª FN cuando no hay relaciones entre la tecla y otras columnas que no dependen de ella.
No estoy seguro de que mi profesor lo haya dicho así, pero esto es lo que es.
Si estás "en el campo". Olvídate de las definiciones. Busque las "mejores prácticas". Uno es SECO: No te repitas.
Si sigues ese principio, ya dominas todo lo que necesitas para NF.
Aquí hay un ejemplo. Su tabla tiene el siguiente esquema:
PERSONS : id, name, age, car make, car model
La edad y el nombre están relacionados con la entrada de persona (=> id) pero el modelo depende del automóvil y no de la persona.
Entonces, lo dividirías en dos tablas:
PERSONS : id, name, age, car_models_id (references CAR_MODELS.id)
CAR_MODELS : id, name, car_makes_id (references CAR_MAKES.id)
CAR_MAKES : id, name
Puede tener replicación en 2FN pero ya no en 3FN.
La normalización tiene que ver con la no replicación, la coherencia y, desde otro punto de vista, las claves externas y las UNIONES.
Cuanto más normalizado mejor para los datos, pero no para el rendimiento, ni para entender si se vuelve demasiado complicado.
Supongamos que alguna relación satisface una dependencia funcional no trivial de la forma A-> B, donde B es un atributo no primordial.
2NF se infringe si A no es una superclave, sino que es un subconjunto propio de una clave candidata.
3NF se viola si A no es una superclave
Ha detectado que el requisito 3NF es solo un caso especial (pero no tan especial) del requisito 2NF. 2NF en sí mismo no es muy importante. El problema importante es si A es una superclave, no si A pasa a ser parte de una clave candidata.