Normalizacion de tablas
0 recomendaciones44 vistas
La normalización es un método para mejorar el diseño lógico de bases de datos relacionales mediante la eliminación de redundancias, anomalías de actualización, borrado e inserción. Esto se logra mediante la aplicación de Formas Normales que garantizan que los atributos dependan totalmente de la clave. La primera forma normal evita valores atómicos y grupos repetidos, la segunda elimina dependencias parciales de la clave, y la tercera dependencias transitivas.
Normalizacion de tablas
- 1. Bases de datos. Normalización Profesor: José Javier Bermúdez Hernández
- 2. ¿Qué es la normalización? La teoría de la normalización, desarrollada por Codd en 1972, es un método de análisis y diseño que permite mejorar el diseño lógico de una Base de datos relacional. Se fundamenta en las Formas Normales, que son un conjunto de restricciones que deben cumplir las relaciones. La normalización persigue evitar: La redundancia de los datos: repetición de datos en un sistema. Anomalías de actualización: inconsistencias de los datos como resultado de datos redundantes y actualizaciones parciales. Anomalías de borrado: pérdidas no intencionadas de datos debido a que se han borrado otros datos. Anomalías de inserción: imposibilidad de adicionar datos en la base de datos debido a la ausencia de otros datos.
- 3. Por ejemplo: redundacia Tomado como ejemplo esta tabla, se plantea el problema: Redundancia: cuando un autor tiene varios libros, se repite la nacionalidad.
- 4. Por ejemplo: anomalías de actualización Tomado como ejemplo esta tabla, se plantea el problema: Anomalías de modificación: Si Adoración de Miguel y Mario Piattini desean cambiar de editor, se tendría que modificar en al menos esos 2 lugares, en esas dos filas. A priori no podemos saber cuántos autores tiene un libro. Los errores son frecuentes al olvidar la modificación de un autor. Se pretende modificar en un sólo sitio.
- 5. Por ejemplo: anomalías de inserción Tomado como ejemplo esta tabla, se plantea el problema: Anomalías de inserción: Se desea dar de alta un autor sin libros, en un principio. NOMBRE y CODLIBRO son campos que forman parte de la clave, una clave no puede tomar valores nulos.
- 6. Por ejemplo: anomalías de borrado Tomado como ejemplo esta tabla, se plantea el problema: Anomalías de borrado: si se borra el registro del único libro de un autor que tiene un solo libro (Emilio Carrillo) se perdería toda la información de la editorial, si solo tiene ese libro y del autor. Sería deseable poder borrar ese libro pero no al autor ni la editorial.
- 7. 1FN Sólo se permiten valores atómicos en una columna. Un ejemplo de esto es cuando en un campo de texto metemos varios valores del mismo dominio, como por ejemplo tres números de teléfono Para evitar esto hay que definir una nueva tabla que tendrá el identificador de la tabla de la que parte y el campo multivaluado, haciendo juntos de clave única compuesta.
- 8. 1FN No se permiten grupos repetidos en varias columnas Esto es una variante de lo anterior: separamos los campos de un mismo dominio en varias columnas, haciendo un grupo difícilmente procesable a la hora de consultarlo. En el ejemplo anterior sería tener el campo telefono1, telefono2… y así. Es evidente que este fallo del diseño es incluso peor que el anterior pues habrá muchos campos nulos, y en caso de necesitar más tendríamos que redimensionar la tabla con un nuevo campo (telefono3). Pero la solución es sencilla: la misma que en el anterior caso.
- 9. Dependencia funcional Dada una relación (tabla) R, el atributo y de R depende funcionalmente del atributo x de R R.x ------------> R.y si x determina el valor de y, es decir, un valor y en R está asociado a cada valor x en R. Tanto x como y pueden ser atributos compuestos. Ejemplo, dada la tabla: PERSONA(NIF, nombre, apellidos, edad) Podemos observar al menos esta dependencia funcional: NIF ------------> nombre
- 10. 2FN Una tabla está en segunda forma normal siempre que esté en primera forma normal y todos sus atributos (campos) dependan totalmente de la clave sin ser parte de ella. Es decir, si un campo de la tabla no depende totalmente de la clave (que puede ser compuesta), debe sacarse fuera con la parte de la clave principal de la que es dependiente.
- 11. 3FN Una relación está en 3FN si, y sólo si, está en 2FN y, además, cada atributo no clave no depende transitivamente de la clave primaria. Ejemplo, dada esta tabla, analizando los datos podemos ver que para el mismo inquilino tenemos el mismo importe de alquiler. cod_inquilino --- cod_edificio cod_edificio --- alquiler Por lo que hay una transitiva: cod_imquilino --- alquiler ¡No está en 3FN!
- 12. 3FN ¿Cómo se soluciona el problema? Se extraen los atributos dependientes en otra tabla. En la tabla original se deja el atributo del que dependen otros, que será clave ajena a la nueva tabla. INQUILINO(cod_inquilino, cod_edificio) ------------ EDIFICIO(cod_edificio, alquiler)