¿Qué significa decir que una tabla de base de datos está en tercera forma normal (3NF)?

Obviamente, la respuesta más correcta pero no tan útil es: significa que cumple con el requisito de que para todas las dependencias funcionales que se mantienen para su tabla donde la columna dependiente no está en una clave candidata, el lado izquierdo de la dependencia es una superclave de la mesa.

Entonces, ¿por qué querríamos que ese fuera el caso? El objetivo de la normalización puede resumirse como “asegurarse de que cada hecho se almacene solo una vez en su base de datos”. El proceso de normalización de la base de datos, como se entiende generalmente, consiste en dividir sus tablas en tablas más pequeñas que son proyecciones de la original para reducir las posibilidades de que los hechos se almacenen más de una vez. Si viola el requisito de 3NF, es muy posible que ciertos datos se almacenen el doble, y esa posibilidad se elimina cuando divide la tabla. Puede encontrar los ejemplos relevantes en los libros de texto.

No es el caso de que todas estas redundancias se hayan hecho imposibles si cumple con los requisitos de 3NF, pero (1) en la práctica cubre muchos de ellos y (2) si va a formas normales más altas como BCNF, 4NF y 5NF, otros problemas potenciales pueden comenzar a ocurrir como ciertas dependencias funcionales que ahora se mantienen entre diferentes tablas. Esto último es difícil y costoso de mantener para un DBMS.

Wikipedia tiene una buena respuesta para esto, y muchas otras preguntas similares:
http://en.wikipedia.org/wiki/Thi

Básicamente, significa que ha definido tablas separadas para cada tipo de datos que está almacenando, y que solo usa claves para conectar tablas juntas.

Aquí hay un ejemplo de 3NF. Es bastante sencillo. La regla es “No se repita”. Si se repite un valor (que no sea una clave externa) en la base de datos, entonces probablemente no tenga el esquema en 3NF. Así es como funciona…

  1. Cada valor que se pueda usar más de una vez debe estar en su propia tabla.
  2. Use una clave sintética (contador incrementado) como PK (clave primaria) para cada fila.
  3. Si se espera que una columna en una tabla haga referencia a una PK en otra tabla, se llama FK (clave externa).
  4. También puede indexar otras columnas para mejorar el rendimiento de búsqueda, y esa columna se denominará SK (clave secundaria), a pesar de que realmente no tiene nada que ver con las relaciones PK / FK.

Por supuesto, puede tener columnas para “descripciones”, “comentarios”, etc. que podrían contener valores duplicados en diferentes filas, pero probablemente sería excesivo normalizarlos.

Probablemente el factor más difícil de comprender para los novatos es que la relación FK → PK a menudo les parece al revés. Por ejemplo, en este ejemplo, las compras hacen referencia a los pedidos en los que se encuentran, en lugar de al revés. Esto se hace porque una relación uno a muchos no se puede representar fácilmente en SQL, por lo que debe darse la vuelta y tratarse como una relación muchos a uno.

Si usa 3NF, obtendrá un rendimiento óptimo porque el tamaño de la clave afecta la velocidad de búsqueda mucho más que el número de tablas a las que se hace referencia. Además, cuando su esquema esté en 3NF, será mucho más fácil mantener la base de datos. Por ejemplo, un cambio de dirección o una alteración en el nombre del producto se puede hacer con un cambio en lugar de buscarlo y cambiarlo en cientos o miles de lugares. Le sugiero que use restricciones (en su DDL, el SQL que se usa para crear el esquema / tablas) para preservar la integridad referencial.

Para comprender el esquema de otra persona, siempre es mejor comenzar con las tablas que contienen más de un FK, como T_Purchases y T_Orders en este ejemplo. Del mismo modo, para escribir el DML de SQL (SQL usado para crear, leer, agregar o eliminar datos) siempre es más fácil comenzar escribiendo la cláusula FROM usando una tabla que tenga múltiples FK y uniéndose a las tablas referenciadas desde esos FK. Entonces, en el ejemplo anterior, podríamos escribir SQL (DML) de esta manera:

  SELECCIONAR
   T_Dates.Date as Date, T_Names.Name as Name, 
   T_Addrs.Addr como dirección, T_Prod.Prod como comprado
 DESDE 
   T_Compras
   ÚNETE A T_Orders EN T_Purchases.FK_Ord = T_Orders.PK_Ord
   ÚNETE A T_Prods EN T_Purchases.FK_Prod = T_Prod.PK_Prod
   ÚNETE A T_Dates EN T_Orders.FK_Date = T_Dates.PK_Date
   ÚNETE A T_Names EN T_Orders.FK_Name = T_Names.PK_Name
   ÚNETE A T_Addrs EN T_Names.FK_Addr = T_Addrs.PK_Addr
 DÓNDE
   T_Dates.PK_Date> = DATE ("Jan 1") Y 
     T_Dates.PK_Date> = DATE ("2 de enero")
 ORDENAR POR
   Fecha ASC;

Tenga en cuenta que estoy usando un formulario de fecha corta aquí en lugar de mostrar la fecha completa en zulú y me tomo tanta libertad porque cada DBMS tiene su propia forma loca de representar las fechas. Espero que esto ayude.