Sql dominio-llave forma normal (DK / NF) y forma anormal

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

Forma normal-Domain clave (DK / NF)

Forma Boyce-Codd normal (BCNF), cuarta forma normal (4NF), y la 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 dominios clave, sin embargo, ofrece una garantía de tal.

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

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

Mesa: VENTAS (ID de cliente, Producto, Precio)

Llave: ID de cliente

Restricciones:

• ID de cliente determina Producto

• Producto determina Precio

• ID de cliente debe ser un entero> 1 000

Para hacer cumplir Restricción 3 (que ID de cliente debe ser un número entero mayor que 1000), sólo tiene que definir el dominio de ID de cliente incorporar esta restricción. Eso hace que la restricción de una consecuencia lógica del dominio del ID de cliente columna. Producto depende de ID de cliente, y ID de 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 (es una consecuencia lógica de) Producto, y Producto no es una clave. La solución es dividir la tabla de ventas en dos tablas. Uno usos de mesa ID de cliente como una clave, y los otros usos Producto como una clave. La base de datos, además de estar en 3NF, también está en DK / NF.

Diseñe 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 paga apagado. Puede dejarse llevar con la normalización e ir demasiado lejos. Puede dividir una base de datos en tantas tablas que toda la cosa se vuelve difícil de manejar e ineficaz. 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 DK / NF. Usted quiere 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, examine su diseño para ver si desnormalización selectiva podría mejorar el rendimiento sin sacrificar la integridad. Al añadir cuidadosamente redundancia en lugares estratégicos y desnormalizar suficiente, se puede llegar a una base de datos que es más eficiente y segura de anomalías.