Sql dominio de clave forma normal (dk / nf) y forma anormal

Después de una base de datos SQL está en tercera forma normal, que ha eliminado la mayoría, pero no todas, las posibilidades de anomalías de modificación. Las formas normales más allá de la tercera se definen para aplastar esos pocos errores restantes.

forma normal de dominio-clave (DK / NF)

Boyce-Codd forma normal (BCNF), cuarta forma normal (4NF), y quinta forma normal (5NF) son ejemplos de tales formas. Cada forma elimina una posible anomalía modificación, pero no garantiza la prevención de todas las posibles anomalías de modificación. forma normal dominio-llave, sin embargo, ofrece una garantía de este tipo.

Una relación es en dominio-clave forma normal (DK / NF) si cada restricción en la relación es una consecuencia lógica de la definición de las llaves y dominios. UN restricción en esta definición es una regla que es lo suficientemente precisa que pueda evaluar si es o no es verdad. UN llave es un identificador único de una fila en una tabla. UN dominio es el conjunto de valores permitidos de un atributo.

Mira esta base de datos, que está en 1NF, para ver lo que hay que hacer para poner esa base de datos en DK / NF.

Mesa: VENTAS (Identificación del cliente, Producto, Precio)

Llave: Identificación del cliente

limitaciones:

Identificación del cliente determina Producto

Para hacer cumplir Constraint 3 (que Identificación del cliente debe ser un entero mayor que 1000), sólo tiene que definir el dominio de Identificación del cliente para incorporar esta restricción. Eso hace que la restricción de una consecuencia lógica del dominio de la Identificación del cliente columna. Producto depende de Identificación del cliente, y Identificación del cliente es una clave, por lo que no tendrá ningún problema con la restricción 1, que es una consecuencia lógica de la definición de la llave.

restricción 2 es un problema. Precio depende de (es una consecuencia lógica de) Producto, y Producto No es una clave. La solución es dividir la tabla de ventas en dos mesas. Uno de ellos utiliza la tabla Identificación del cliente como una clave, y los otros usos Producto como clave. La base de datos, además de estar en 3NF, también está en DK / NF.

Diseño de sus bases de datos para que estén en DK / NF si es posible. Si puede hacer eso, hacer cumplir las restricciones de clave y de dominio hace que todas las restricciones que deben cumplirse, y anomalías de modificación no son posibles. Si la estructura de una base de datos está diseñado para evitar que su puesta en DK / NF, entonces usted tiene que construir las restricciones en el programa de aplicación que utiliza la base de datos. La base de datos en sí no garantiza que se cumplan las restricciones.

forma anormal

Como en la vida, por lo que en las bases de datos: A veces ser anormal vale la pena. Puede dejarse llevar por la normalización e ir demasiado lejos. Puede dividir una base de datos en tantas mesas que todo el asunto se vuelve difícil de manejar e ineficiente. El rendimiento puede caer en picado. A menudo la estructura óptima para su base de datos es algo desnormalizará.

De hecho, las bases de datos prácticos (los realmente grandes, de todos modos) casi nunca se normalizaron hasta el final a DK / NF. Desea normalizar las bases de datos que diseñe lo más posible, sin embargo, para eliminar la posibilidad de corrupción de datos que resulta de anomalías de modificación.

Después de normalizar la base de datos en la medida que pueda, hacer algunas recuperaciones como un ensayo general. Si el rendimiento no es satisfactorio, examinar su diseño para ver si desnormalización selectiva mejoraría el rendimiento sin sacrificar la integridad. Añadiendo cuidadosamente redundancia en lugares estratégicos y desnormalización sólo lo suficiente, se puede llegar a una base de datos que es más eficiente y segura de anomalías.