Normalización:
En un conjunto de reglas que sirven para ayudar a los diseñadores a desarrollar un esquema que minimice los problemas de lógica.
Cada regla esta basada en la que le antecede. Se la adopto por que el viejo estilo de poner todos los datos en un solo lugar, como un archivo o tabla de base de datos, es ineficiente y conducía a errores de lógica.
Existen tres niveles básico de normalización:
Primera forma normal (1NF).
Segunda forma normal (2NF).
Tercera forma normal (3NF).
Existen cuatro niveles mas de normalizacion:
Forma Normal Boyce-Codd(BCNF)
Cuarta forma normal(4NF).
Quinta forma normal o forma normal de proyección-unión(5NF).
Forma normal de dominio/clave.
Primera Forma Normal (1NF)
- Todo los atributos son atómicos. Un atributo es atómico si los elementos del dominio son indivisibles, mínimos.
- La tabla contiene una clave primaria.
- La clave primara no contiene atributos nulos.
- No posee ciclos repetitivos.
- No debe de existir una variación en el numero de columnas.
Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes. Procede a definir una tabla de cliente como la que sigue:
| ID Cliente | Nombre | Apellido | Teléfono |
|---|---|---|---|
| 123 | Rachel | Ingram | 555-861-2025 |
| 456 | James | Wright | 555-403-1659 |
| 789 | Cesar | Dure | 555-808-9633 |
En este punto, el diseñador se da cuenta que un requerimiento es guardar múltiples números telefónicos para algunos clientes. Razona que la manera más simple de hacer esto es permitir que el campo "Teléfono" contenga más de un valor en cualquier registro dado:
| ID Cliente | Nombre | Apellido | Teléfono |
|---|---|---|---|
| 123 | Rachel | Ingram | 555-861-2025 |
| 456 | James | Wright | 555-403-1659 555-776-4100 |
| 789 | Cesar | Dure | 555-808-9633 |
El diseñador puede evitar esta restricción definiendo múltiples columnas del número telefónico:
| ID Cliente | Nombre | Apellido | Teléfono 1 | Teléfono 2 | Teléfono 3 |
|---|---|---|---|---|---|
| 123 | Rachel | Ingram | 555-861-2025 | ||
| 456 | James | Wright | 555-403-1659 | 555-776-4100 | |
| 789 | Cesar | Dure | 555-808-9633 |
Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y por lo tanto no se conforman con la definición de la 1NF de Date. Incluso si se contempla la posibilidad de columnas con valores nulos, el diseño no está en armonía con el espíritu de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten exactamente el mismo dominio y exactamente el mismo significado; dividir los números de teléfono en tres encabezados es artificial y causa problemas lógicos.
- Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales como "¿Qué clientes tienen el teléfono X?" y "¿Qué pares de clientes comparten un número de teléfono?".
- La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un valor para el Teléfono 2 que es exactamente igual que el valor de su Teléfono 1.
- La restricción de los números de teléfono por cliente a tres. Si viene un cliente con cuatro números de teléfono, estamos obligados a guardar solamente tres y dejar el cuarto sin guardar. Esto significa que el diseño de la base de datos está imponiendo restricciones al proceso del negocio, en vez de (como idealmente debe ser el caso) al revés.
Ejemplos:
- Múltiples valores:
 |
| Multiples datos en número de teléfono |
La forma correcta sería:
 |
| Número de teléfono normalizado |
- Redundancia de datos:
 |
| Datos redundantes en dos registros |
La forma correcta de representar la tabla sería:
 |
| Sin redundancia. Cabe mencionar que la llave primaria de la segunda tabla es compuesta |
- Columnas que permiten valores nulos:
La forma correcta de representar esta tabla seria como en el ejemplo anterior
- Tabla sin llave principal:
La forma correcta sería agregando una llave principal
Segunda forma normal:
Una tabla 1NF estará en 2NF si y solo si, dada una clave candidata y cualquier atributo que no sea un constituyente de la clave candidata, el atributo no clave depende de toda la clave candidata en vez de solo una parte de ella.
Observe que cuando una tabla 1NF no tiene ninguna clave candidata compuesta(claves candidatas consistiendo en mas de un atributo), la tabla esta automaticamente en 2NF.
Ejemplos:
- Ejemplo1:
Esto se soluciona separando el atributo N_TRABAJADOR a una tabla separada
- Ejemplo 2:
en este caso se puede separar la tabla en 3 tablas diferentes para cumplir con la 2FN
Ejemplo3:
Esta tabla esta en FN2
Ejemplo4:
Esta tabla esta en FN2
La Segunda Forma Normal presenta anomalias, en donde si existe dependencia funcional completa entre los atributos. como en el ejemplo siguiente:
| Empleado | Habilidad | Lugar actual de trabajo |
|---|---|---|
| Jones | Mecanografía | 114 Main Street |
| Jones | Taquigrafía | 114 Main Street |
| Jones | Tallado | 114 Main Street |
| Bravo | Limpieza ligera | 73 Industrial Way |
| Ellis | Alquimia | 73 Industrial Way |
| Ellis | Malabarismo | 73 Industrial Way |
| Harrison | Limpieza ligera | 73 Industrial Way |
La única clave candidata de la tabla es {Empleado, Habilidad}.
El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".
Una alternativa 2NF a este diseño representaría la misma información en dos tablas:
| Empleado | Lugar actual de trabajo |
|---|---|
| Jones | 114 Main Street |
| Bravo | 73 Industrial Way |
| Ellis | 73 Industrial Way |
| Harrison | 73 Industrial Way |
-
-
Habilidades de los empleados Empleado Habilidad Jones Mecanografía Jones Taquigrafía Jones Tallado Bravo Limpieza ligera Ellis Alquimia Ellis Malabarismo Harrison Limpieza ligera
-
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.
Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es:
| Torneo | Año | Ganador | Fecha de nacimiento del ganador |
|---|---|---|---|
| Des Moines Masters | 1998 | Chip Masterson | 14 de marzo de 1977 |
| Indiana Invitational | 1998 | Al Fredrickson | 21 de julio de 1975 |
| Cleveland Open | 1999 | Bob Albertson | 28 de septiembre de 1968 |
| Des Moines Masters | 1999 | Al Fredrickson | 21 de julio de 1975 |
| Indiana Invitational | 1999 | Chip Masterson | 14 de marzo de 1977 |
Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa {Torneo, Año} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros. Este problema es tratado por la tercera forma normal (3NF).
Tercera forma normal(3NF):
Es una forma normal usada en la normalización de bases de datos. Para que la tabla esté en 3NF, se debe cumplir que la tabla ya esté en 2NF. Adicionalmente, ningun atributo no primario de la tabla debe ser dependiende transitivamente de una clave primaria.
Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF es:
| Torneo | Año | Ganador | Fecha de nacimiento del ganador |
|---|---|---|---|
| Indiana Invitational | 1998 | Al Fredrickson | 21 de julio de 1975 |
| Cleveland Open | 1999 | Bob Albertson | 28 de septiembre de 1968 |
| Des Moines Masters | 1999 | Al Fredrickson | 21 de julio de 1975 |
| Indiana Invitational | 1999 | Chip Masterson | 14 de marzo de 1977 |
La única clave candidata es {Torneo, Año}.
La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros.
Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en dos:
| Torneo | Año | Ganador |
|---|---|---|
| Indiana Invitational | 1998 | Al Fredrickson |
| Cleveland Open | 1999 | Bob Albertson |
| Des Moines Masters | 1999 | Al Fredrickson |
| Indiana Invitational | 1999 | Chip Masterson |
-
-
Fecha de nacimiento del jugador Ganador Fecha de nacimiento Chip Masterson 14 de marzo de 1977 Al Fredrickson 21 de julio de 1975 Bob Albertson 28 de septiembre de 1968
-
Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3NF.
Referencias:
http://basesdedatosjc.blogspot.com/2012/04/primera-forma-normal-en-bases-de-datos.html
No hay comentarios.:
Publicar un comentario