klondike

Y si tenéis dudas preguntad y os lo intentaré aclarar :) Happy hacking!

Hay varias formas normales más que añaden restricciones extras ( y como las anteriores tienen todas su razón de ser). Este artículo de la Wikipedia expande más el tema: https://en.wikipedia.org/wiki/Database_normalization …

Resumiendo: * UNF Clave primaria, columnas de nombre único * 1NF Además, cada columna representa un valor único * 2NF Además, ninguna columna depende de (únicamente) parte de la clave primaria. * 3NF Además, ninguna columna depende del valor de otras columnas.

Y así tenemos nuestra base de datos en 3NF.

Esto se arregla creando una nueva tabla dónde se elige uno de los valores como clave primaria y el resto como atributos y cambiando las columnas de la tabla original de modo que referencien a la nueva tabla.

Y como el sexo no es parte de la clave primaria nuestra tabla seguiría estando en 2NF.

Un operador puede equivocarse e introducir o modificar una fila en la tabla con los valores Masculino / Female y sería perfectamente válido.

Pero como somos plurilingües podemos tener otra llamada "sex" de valores "Male, Female o NULO" y una tercera en Chino (no me pidáis que lo escriba). Notad que el valor de sexo puede ser NULO y por tanto no debe ser parte de la clave primaria.

Un ejemplo más claro, imaginaos una columna llamada "sexo" que puede ser Masculino, Femenino o NULO

Volviendo al ejemplo anterior de los tipos de cliente, o los tipos de piso, hemos supuesto que la categoría y el tipo de piso eran parte de la clave primaria pero no tienen porque serlo.

Y así es como tienes tu base de datos en 2NF.

Lo que se hace en este caso es simple, creamos una nueva tabla (por ejemplo categoría o tipo de piso) con esos atributos de modo que sean únicos para todas las filas que sean del mismo tipo.

El problema se vuelve más grave cuanto más grande es el número de columnas que dependen únicamente de una parte de la clave primaria.

O con la BBDD de propiedades, si quisiéramos actualizar la medición de tamaños de todos los pisos de tipo XA de 20m² a 20.5m² tendríamos que cambiar todas las filas que tengan un piso XA. Si construimos un bloque de pisos de tipo XA tenemos que poner el valor correcto cada vez.

Esto es un problema porque implica que la información se repite una y otra vez y por tanto se puede volver inconsistente si no se cambia o introduce de forma correcta. Por ejemplo podríamos cambiar el descuento del cliente X con categoría Y por otro diferente.

Podemos encontrarnos con que hay columnas en nuestra tabla que no dependen de todas las columnas de nuestra clave primaria. Por ejemplo el descuento que apliquemos en una tienda a nuestro clientes en la categoría X o el tamaño de los pisos de tipo Y en una BBDD de propiedades.

Lo habitual es de hecho crear tres tablas si las categorías tienen atributos propios que no queremos repetir cada vez (ahora veremos el por qué).