Normalizacion
El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
- Evitar la redundancia de los datos.
- Evitar problemas de actualización de los datos en las tablas.
- Proteger la integridad de los datos.
- En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:
- Cada tabla debe tener su nombre único.
- No puede haber dos filas iguales. No se permiten los duplicados.
- Todos los datos en una columna deben ser del mismo tipo.
Primera Forma Normal (1FN)
La primera forma normal (1FN o forma mínima) es una forma normal usada en normalización de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Estos criterios se refieren básicamente a asegurarse que la tabla es una representación fiel de una relación1 y está libre de "grupos repetitivos".
Grupos repetidos
La cuarta condición de Date, que expresa "lo que la mayoría de la gente piensa como la característica que define la 1FN",7 concierne a grupos repetidos. El siguiente ejemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de grupos, en violación de la 1NF.
Ejemplos
Ejemplo 1: Dominios y valores
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 de un requisito para guardar múltiples números teléfonicos 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 |
Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representación de arriba no está en 1FN. La 1FN (y, para esa materia, el RDBMS) prohíbe a un campo contener más de un valor de su dominio de columna.
[ ]Ejemplo 2: Grupos repetidos a través de columnas
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; el dividir del número de teléfono en tres encabezados es artificial y causa problemas lógicos. Estos problemas incluyen:
- 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.
[ ]Ejemplo 3: Repetición de grupos dentro de columnas
El diseñador puede, alternativamente, conservar una sola columna de número de teléfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar múltiples números telefónicos:
| 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 |
Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de la 1FN. El encabezado "Teléfono" llega a ser semánticamente difuso, ya que ahora puede representar, o un número de teléfono, o una lista de números de teléfono, o de hecho cualquier cosa. Una consulta como "¿Qué pares de clientes comparten un número telefónico?" es virtualmente imposible de formular, dada la necesidad de proveerse de listas de números telefónicos así como números telefónicos individuales. Con este diseño en la RDBMS, son también imposibles de definir significativas restricciones en números telefónicos.
[editar]Un diseño conforme con 1FN
Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de teléfono del cliente.
| ID Cliente | Nombre | Apellido |
|---|---|---|
| 123 | Rachel | Ingram |
| 456 | James | Wright |
| 789 | Cesar | Dure |
-
-
Teléfono del cliente ID Cliente Teléfono 123 555-861-2025 456 555-403-1659 456 555-776-4100 789 555-808-9633
-
En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso, cada enlace Cliente-a-Teléfono aparece en su propio registro.
Segunda Forma Normal (2FN)
La segunda forma normal (2NF) es una forma normal usada en normalización de bases de datos. La 2FN fue definida originalmente por E.F. Codd en 1971. Una tabla que está en la primera forma normal (1FN) debe satisfacer criterios adicionales para calificar para la segunda forma normal. Específicamente: una tabla 1FN está en 2FN si y solo si, dada una clave primaria y cualquier atributo que no sea un constituyente de la clave primaria, el atributo no clave depende de toda la clave primaria en vez de solo una parte de ella.
Ejemplo
Considere una tabla describiendo las habilidades de los empleados:
| 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 2FN. 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?".
Un alternativa 2FN 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 2FN.
Tercera Forma Normal (3FN)
La tercera forma normal (3FN) es una forma normal usada en la normalización de bases de datos. La 3FN fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3FN si y solo si las dos condiciones siguientes se mantienen:
- La tabla está en la segunda forma normal (2FN)
- Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria
"Nada excepto la clave"
Un memorable resumen de la definición de Codd de la 3FN, fue dado por Bill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la clave, la clave entera, y nada más excepto la clave".
Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla esté en 2FN; un requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave" asegura que la tabla esté en 3FN.
Ejemplo
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.
Normalización más allá de la 3NF
La mayoría de las tablas 3NF están libres anomalías de actualización, inserción, y borrado. Ciertos tipos de tablas 3NF, que en la práctica raramente se encuentran, son afectadas por tales anomalías; éstas son tablas que no satisfacen la forma normal de Boyce-Codd (BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las formas normales más altas 4NF o 5NF.
Comentarios
Publicar un comentario