Normalización de bases de datos
De Wikipedia, la enciclopedia libre
Saltar a navegación, búsqueda
Para otros usos de este término, véase Normalización (desambiguación).
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 columna 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.
Terminología relacional equivalente [editar]
Figura 1.0: Trabajo (Código, Nombre, Posición, Salario), donde Código es
- Relación = tabla o archivo
- Tupla = registro, fila o renglón
- Atributo = columna o campo
- Clave = llave o código de identificación
- Clave Candidata = superclave mínima
- Clave Primaria = clave candidata elegida
- Clave Ajena = clave externa o clave foránea
- Clave Alternativa = clave secundaria
- Dependencia Multivaluada = dependencia multivalor
- RDBMS = Del inglés Relational Data Base Manager System que significa, Sistema Gestor de Bases de Datos Relacionales.
- 1FN = Significa, Primera Forma Normal o 1NF del inglés First Normal Form.
Los términos Relación, Tupla y Atributo derivan del álgebra y cálculo relacional, que constituyen la fuente teórica del modelo de base de datos relacional.
Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo, suele haber algunas diferencias con la analogía matemática, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede razonarse matemáticamente como un elemento del producto cartesiano entre los dominios.
Dependencia [editar]
Dependencia funcional [editar]
B es funcionalmente dependiente de A.
Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.
Las dependencias funcionales del sistema se escriben utilizando una flecha, de la siguiente manera:
FechaDeNacimiento 
Edad
Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o real) puede ser sugerible tener éstas dependencias funcionales para lograr la eficiencia en las tablas.
Propiedades de la Dependencia funcional [editar]
Existen 3 axiomas de Armstrong:
Dependencia funcional Reflexiva [editar]
Si "y" está incluido en "x" entonces x y
Si la dirección o el nombre de una persona están incluidos en el DNI, entonces con el DNI podemos determinar la dirección o su nombre.
Dependencia funcional Aumentativa [editar]
entonces 
dni nombre
dni,dirección nombre,dirección
Si con el dni se determina el nombre de una persona, entonces con el dni más la dirección también se determina el nombre o su dirección.
Dependencia funcional transitiva [editar]
Dependencia funcional transitiva.
Sean X, Y, Z tres atributos (o grupos de atributos) de la misma entidad. Si Y depende funcionalmente de X y Z de Y, pero X no depende funcionalmente de Y, se dice entonces que Z depende transitivamente de X. Simbólicamente sería:
X Y Z entonces X Z
FechaDeNacimiento Edad
Edad Conducir
FechaDeNacimiento Edad Conducir
Entonces tenemos que FechaDeNacimiento determina a Edad y
Propiedades deducidas [editar]
Unión [editar]
y 
entonces 
Pseudo-transitiva [editar]
y 
entonces 
Descomposición [editar]
y z está incluido en y entonces
Claves [editar]
Una clave primaria es aquella columna (pueden ser también dos columnas o más) que identifica únicamente a esa fila. La clave primaria es un identificador que va a ser único para cada fila. Se acostumbra a poner la clave primaria como la primera columna de la tabla pero esto no tiene que ser necesario, si no es más una conveniencia. Muchas veces la clave primaria es autonumérica.
En una tabla puede que tengamos más de una clave, en tal caso se puede escoger una para ser la clave primaria, las demás claves son las claves candidatas. Además es la posible clave primaria.
Una clave ajena (foreign key o clave foránea) es aquella columna que existiendo como dependiente en una tabla, es a su vez clave primaria en otra tabla.
Una clave alternativa es aquella clave candidata que no ha sido seleccionada como clave primaria, pero que también puede identificar de forma única a una fila dentro de una tabla. Ejemplo: Si en una tabla clientes definimos el número de documento (id_cliente) como clave primaria, el número de seguro social de ese cliente podría ser una clave alternativa. En este caso no se usó como clave primaria porque es posible que no se conozca ese dato en todos los clientes.
Una clave compuesta es una clave que está compuesta por más de una columna.
Formas Normales [editar]
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la forma normal N.
En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd.[1]
Primera Forma Normal (1FN) [editar]
Artículo principal: Primera forma normal
Una tabla está en Primera Forma Normal si:
- Todos 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 llave primaria no contiene atributos nulos.
- No posee ciclos repetitivos.
Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X)
Esta forma normal elimina los valores repetidos dentro de una BD
Segunda Forma Normal (2FN) [editar]
Artículo principal: Segunda forma normal
Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales.
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos atributos 
que pueden ser eliminados de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y.
Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es completamente dependiente dado que ni DNI HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.
Tercera Forma Normal (3FN) [editar]
Artículo principal: Tercera forma normal
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre los atributos que no son clave.
Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que DNUMBER no es una clave de EMP_DEPT.
Forma normal de Boyce-Codd (FNBC) [editar]
Artículo principal: Forma normal de Boyce-Codd
La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es clave candidata. Deberá registrarse de forma anillada ante la presencia de un intervalo seguido de una formalizacion perpetua, es decir las variantes creadas, en una tabla no se llegaran a mostrar, si las ya planificadas, dejan de existir
Cuarta Forma Normal (4FN) [editar]
Artículo principal: Cuarta forma normal
Una tabla se encuentra en 4FN si , y sólo si, para cada una de sus dependencias múltiples no funcionales X->->Y, siendo X una super-clave que, X es o una clave candidata o un conjunto de claves primarias.
Quinta Forma Normal (5FN) [editar]
Artículo principal: Quinta forma normal
Una tabla se encuentra en 5FN si:
- La tabla está en 4FN
- No existen relaciones de dependencias no triviales que no siguen los criterios de las claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación de dependencia se encuentra definida por las claves candidatas.
Reglas de Codd [editar]
Codd se percató de que existían bases de datos en el mercado las cuales decían ser relacionales, pero lo único que hacían era guardar la información en las tablas, sin estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema relacional debería tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema podrá considerarse "más relacional" cuanto más siga estas reglas.
Regla No. 1 - La Regla de la información [editar]
Toda la información en un RDBMS está explícitamente representada de una sola manera por valores en una tabla.
Cualquier cosa que no exista en una tabla no existe del todo. Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos. Esto significa que todo tiene que estar almacenado en las tablas.
Toda la información en una base de datos relacional se representa explícitamente en el nivel lógico exactamente de una manera: con valores en tablas. Por tanto los metadatos (diccionario, catálogo) se representan exactamente igual que los datos de usuario. Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos y a los metadatos (regla 4)
Regla No. 2 - La regla del acceso garantizado [editar]
Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el nombre de la tabla, su clave primaria, y el nombre de la columna.
Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón la definición de claves primarias para todas las tablas es prácticamente obligatoria.
Regla No. 3 - Tratamiento sistemático de los valores nulos [editar]
La información inaplicable o faltante puede ser representada a través de valores nulos.
Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables.
Regla No. 4 - La regla de la descripción de la base de datos [editar]
La descripción de la base de datos es almacenada de la misma manera que los datos ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.
La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc, debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles igual que todas las tablas, a través de sentencias de SQL (o similar).
Regla No. 5 - La regla del sub-lenguaje Integral [editar]
Debe haber al menos un lenguaje que sea integral para soportar la definición de datos, manipulación de datos, definición de vistas, restricciones de integridad, y control de autorizaciones y transacciones.
Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que pueda ser usado para administrar completamente la base de datos.
Regla No. 6 - La regla de la actualización de vistas [editar]
Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema mismo.
La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos de actualizar vistas complejas.
Regla No. 7 - La regla de insertar y actualizar [editar]
La capacidad de manejar una base de datos con operandos simples aplica no sólo para la recuperación o consulta de datos, sino también para la inserción, actualización y borrado de datos'.
Esto significa que las cláusulas para leer, escribir, eliminar y agregar registros (SELECT, UPDATE, DELETE e INSERT en SQL) deben estar disponibles y operables, independientemente del tipo de relaciones y restricciones que haya entre las tablas.
Regla No. 8 - La regla de independencia física [editar]
El acceso de usuarios a la base de datos a través de terminales o programas de aplicación, debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos almacenados, o sean cambiados los métodos de acceso a los datos.
El comportamiento de los programas de aplicación y de la actividad de usuarios vía terminales debería ser predecible basados en la definición lógica de la base de datos, y éste comportamiento debería permanecer inalterado, independientemente de los cambios en la definición física de ésta.
Regla No. 9 - La regla de independencia lógica [editar]
Los programas de aplicación y las actividades de acceso por terminal deben permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados) en las tablas de la base de datos.
La independencia lógica de los datos especifica que los programas de aplicación y las actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.
Regla No. 10 - La regla de la independencia de la integridad [editar]
Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el catalogo, no en el programa de aplicación.
Las reglas de integridad [editar]
- Ningún componente de una clave primaria puede tener valores en blanco o nulos (ésta es la norma básica de integridad).
- Para cada valor de clave foránea deberá existir un valor de clave primaria concordante. La combinación de estas reglas aseguran que haya integridad referencial.
Regla No. 11 - La regla de la distribución [editar]
El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de aplicación.
El soporte para bases de datos distribuidas significa que una colección arbitraria de relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas operativos y que esté conectada por una variedad de redes, pueda funcionar como si estuviera disponible como en una única base de datos en una sola máquina.
Regla No. 12 - Regla de la no-subversión [editar]
Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de alto nivel (como SQL).
Algunos productos solamente construyen una interfaz relacional para sus bases de datos No relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad. Esto no debe ser permitido.
Referencias [editar]
- ↑ A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387 [1]
- E.F.Codd (junio de 1970). "A Relational Model of Data for Large Shared Databanks". Communications of the ACM.
- C.J.Date (1994). "An Introduction to Database Systems". Addison-Wesley.
Véase también [editar]
- 1NF - 2NF - 3NF - BCNF - 4NF - 5NF - DKNF - 6NF - Denormalización
- Edgar Frank Codd
- Base de datos
FORMAS NORMALES Y DEPENDENCIAS FUNCIONALES
Autor: Carlos Carmona
Este artículo está bajo licencia CopyLeft. Se permite pués su libre distribución con la única condición de incluir el nombre del autor y un enlace a la web original.
La normalización es un proceso que pretende conseguir tablas con una estructura óptima y eficaz. El proceso de normalización está basado en lograr la independencia de los datos respecto a las aplicaciones que los usan.
Antes de empezar el proceso, se han de conocer las tablas que intervendrán y las relaciones que las unen. Si no se conocen a partir del análisis previo, se buscan todos los nombres (sustantivos) que han sido empleados en la definición del problema. Algunos de esos nombres serán las entidades, otros dependerán de ellas y serán los atributos. Otros no formarán parte ni de las entidades ni de los atributos, son parte del lenguaje necesario para describir el problema a solucionar mediante la creación de una base de datos.
| Ejemplo |
| Ejemplo práctico. |
| <<...a cada cliente, al pasar por Caja... se marcan por la caja registradora los artículos que ha comprado. Con los datos de los artículos se hace una factura por el importe total de las mercancías adquiridas que se imprime y se entrega al cliente. Los datos de la factura se almacenan para su posterior tratamiento informático que comprende...>>. |
Las tablas son sustantivos, por lo que tenemos los siguientes: cliente, Caja, caja registradora, artículos, datos de los artículos, factura, importe total, mercancías adquiridas, datos de la factura. De estos nombres, algunos son atributos de otros: datos de los artículos y artículos, datos de la factura, importe total y factura. De cada cliente no se piden datos, por lo que aunque sea una tabla, si no se necesitan sus datos, no se creará esa entidad. Caja con mayúscula se refiere a un objeto con el que se realizan procesos, por lo que no se necesita almacenar información de ellos. De cada una de las cajas registradoras, tal vez se necesite para las facturas, el número de caja, por lo que se considera una entidad más. Mercancías adquiridas y artículos que ha comprado son sinónimos, por lo que solo se tratará de artículos.
Las tablas encontradas tras el análisis son: artículos, factura y caja registradora. Caja registradora se puede considerar un atributo de factura, por lo que tenemos dos tablas.
Las relaciones se pueden encontrar conociendo todos los verbos que aparecen en la definición del problema. Se eliminan aquellos verbos que son necesarios para el lenguaje y se buscan aquellos que implican dos o más entidades (sustantivos) que ya se han encontrado.
En el ejemplo han aparecido los verbos: pasar, se marcan, ha comprado, se hace una factura, imprime, entrega, almacena. De estos verbos, los que asocian entidades son: marcar, comprar. Los verbos pasar, hacer factura, imprimir, entregar, almacenar, se refieren a procesos que se van a realizar, no a asociaciones entre entidades.
Se han obtenido las siguientes entidades con sus relaciones: clientes, comprar artículos y marcar artículos en factura. Como no se necesitan los datos de los clientes, queda la relación marcada (en la caja registradora) que une las tablas artículos, y factura. La operación marcar en la caja registradora significa que los artículos se incluyen en una factura que se entregará al cliente para su liquidación, consiguiéndose obtener el modelo entidad-relación siguiente:
Hay cinco niveles de normalización, siendo cada vez más complejo el proceso de obtención de tablas normalizadas. Para bases de datos relativamente sencillas se puede terminar la normalización en el tercer nivel o tercera forma normal.
El proceso de normalización se basa en la descomposición sin pérdida de las tablas que están en una forma normal inferior, obteniéndose una forma normal superior. El proceso de descomposición sin pérdida, significa que se ha de dividir o descomponer la tabla en otras con menor cantidad de atributos sin que haya perdida de información.
Formas normales y dependencias funcionales.
Primera Forma Normal o 1FN:
| Tabla de una base de datos | ||||||
| NIF | Ape | Nom | Dir | CPost | Pobl | Prov |
| 1 | García | Francisco | C/Marín 16 | 33698 | Oviedo | Asturias |
| 2 | Sanchez | Luisa | C/Tenerías 34
| 85458
| Cigales
| Valladolid
|
Esta tabla no está en 1FN, ya que el cliente con Id 2 tiene dos direcciones. Para poder tener esta tabla en 1FN se hace el siguiente cambio:
| Tabla de una base de datos | ||||||
| NIF | Ape | Nom | Dir | CPost | Pobl | Prov |
| 1 | García | Francisco | C/Marín 16 | 33698 | Oviedo | Asturias |
| 2 | Sanchez | Luisa | C/Tenerías 34 | 85458 | Cigales | Valladolid |
| 2 | Sanchez | Luisa | C/Ramorta 65 | 54585 | Bueu | Pontevedra |
Segunda Forma Normal o 2FN:
Se dice que un atributo o conjunto de atributos tiene dependencia funcional de otro u otros si a cada uno de los primeros le corresponde sólo uno de los segundos.
Por ejemplo, hay una dependencia funcional entre CIF y el atributo Razón Social, ya que a cada CIF le corresponde una única Razón Social.
Una tabla está en Segunda Forma Normal o 2FN cuando está en 1FN y todo atributo que no pertenece a la clave primaria tiene una dependencia funcional de la clave completa y no de parte de ella. Luego, si la clave principal está formada por un solo atributo y ya está en 1FN, ya estará en 2FN.
Para transformar una tabla con dependencias funcionales, cuya clave está formada por más de un campo, en una tabla en 2FN se necesitan crear tablas nuevas para eliminar las dependencias funcionales, las tablas nuevas tendrán los atributos que dependen funcionalmente de la clave y los que forman la parte de la clave de la que dependen. Una vez creadas las nuevas tablas, se eliminan de la tabla primera los atributos que tenían dependencias funcionales.
En el ejemplo anterior, tanto el nombre como los apellidos dependen del NIF. Se crea una nueva tabla que contiene los atributos: NIF, nombre y apellidos, eliminándose de la tabla cliente los atributos nombre y apellidos, quedando las siguientes tablas:
| Tabla en segunda forma normal | ||||
| NIF | Dir | CPost | Pobl | Prov |
| 1 | C/ Marín nº16 | 33698 | Oviedo | Asturias |
| 2 | C/ Tenerías nº34 | 85458 | Cigales | Valladolid |
| 2 | C/ Ramorta nº65 | 54585 | Bueu | Pontevedra |
| Tabla en segunda forma normal | ||
| NIF | Ape | Nom |
| 1 | García | Francisco |
| 2 | Sanchez | Luisa |
Tercera Forma Normal o 3FN:
Se dice que hay dependencia funcional transitiva entre dos atributos cuando un atributo que no pertenece a la clave primaria permite conocer el valor de otro atributo.
Por ejemplo: dada la tabla clientes, entre los atributos provincia y prefijo telefónico hay una dependencia funcional transitiva, ya que el primero permite conocer el valor del segundo.
Una tabla está en Tercera Forma Normal o 3FN si está en 2FN y no existen atributos que no pertenezcan a la clave primaria que puedan ser conocidos mediante otro atributo que no forma parte de la clave primaria, es decir, no hay dependencias funcionales transitivas.
Siguiendo con el ejemplo anterior, cuando hay dependencias funcionales transitivas, se crea una nueva tabla con los atributos que tienen dependencia funcional transitiva, eliminándose el atributo dependiente de la tabla original.
Si nos fijamos en esta tabla:
| Tabla en segunda forma normal | ||||
| NIF | Dir | CPost | Pobl | Prov |
| 1 | C/ Marín nº16 | 33698 | Oviedo | Asturias |
| 2 | C/ Tenerías nº34 | 85458 | Cigales | Valladolid |
| 2 | C/ Ramorta nº65 | 54585 | Bueu | Pontevedra |
La dirección, la población y la provincia dependen del código postal, que no forma parte de la clave primaria. Descomponiendo sin perdida una vez más, obtenemos estas dos tablas:
| Tabla en tercera forma normal | |
| NIF | Dir |
| 1 | C/ Marín nº16 |
| 2 | C/ Tenerías nº34 |
| 2 | C/ Ramorta nº65 |
| Tabla en tercera forma normal | |||
| CPost | Dir | Pobl | Prov |
| 33698 | C/ Marín nº16 | Oviedo | Asturias |
| 85458 | C/ Tenerías nº34 | Cigales | Valladolid |
| 54585 | C/ Ramorta nº65 | Bueu | Pontevedra |
Para solucionar algunos problemas de dependencias funcionales, que no se podían resolver solo con la normalización en 3FN, se han propuesto tres formas normales adicionales. La normalización más allá de 3FN queda al juicio del diseñador de la base de datos. A partir de esa forma normal, la eliminación de dependencias funcionales pasa por la creación de tablas con multitud de información redundante, con un posible aumento de tamaño, por lo que se ha de optar entre una optimización del diseño y una optimización del tamaño. Llegándose a diversas soluciones de compromiso entre ambos parámetros. Salvo excepciones, con la 3FN o a lo sumo,
Forma Normal de Boyce-Codd o FNBC:
Una tabla está en Forma Normal de Boyce-Codd o FNBC si solo existen dependencias funcionales elementales que dependan de la clave primaria o de cualquier clave alternativa. Si la clave primaria está formada por un solo atributo y está en 3FN, ya está en FNBC.
Un ejemplo típico para mostrar una tabla que, estando en 3FN, mantiene dependencias funcionales, sin relación con el ejemplo seguido hasta este momento, es una tabla que posee los atributos dirección, código postal y población, suponiendo que a poblaciones diferentes le corresponden códigos postales distintos.
| Tabla en tercera forma normal | ||
| CPost | Dir | Pobl |
| 30009 | C/ Pantano Camarillas nº16 | Murcia |
| 48596 | Av. Buenos Aires nº12 | Madrid |
En este caso hay dependencia entre el código postal y la población, ya que, conocido el código postal se puede conocer la población, y conocida la dirección y la población, se conoce el código postal. Para transformar la tabla en una tabla en FNBC se crea una tabla de códigos postales y poblaciones, eliminando de la tabla original la población, obteniéndose dos tablas, una con los atributos dirección y código postal y otra con el código postal y la población:
| Tabla en forma normal de Boyce-Codd | |
| CPost | Dir |
| 30009 | C/ Pantano Camarillas nº16 |
| 48596 | Av. Buenos Aires nº12 |
| Tabla en forma normal de Boyce-Codd | |
| CPost | Pobl |
| 30009 | Murcia |
| 48596 | Madrid |
Cuarta Forma Normal o 4FN:
Existe dependencia funcional multivalorada o de múltiples valores si, dados tres atributos de una tabla, si para cada valor del primer atributo existen múltiples valores en el segundo atributo y no hay ninguna relación entre el tercer atributo y el primero, a no ser a través del segundo atributo.
Una tabla está en Cuarta Forma Normal o 4FN si está en FNBC y las únicas dependencias funcionales multivaloradas que existen son las dependencias funcionales de la clave con los atributos que no forman parte de la misma. Estas dependencias multievaluadas de la clave con los atributos que no forman parte de la misma son dependencias triviales, por lo que algunos autores dicen que no existen dependencias multievaluadas en 4FN.
Supongamos que los atributos de la tabla transporte son conductor, tipo de vehículo y tipo de carga, formando los tres campos la clave primaria. A cada conductor se le puede asignar un vehículo u otro y cada vehículo puede transportar varios tipos de carga.
| Tabla que no esta en cuarta forma normal | ||
| Transporte | ||
| Conductor | Tipo Vehículo | Tipo Carga |
| Juan | Furgoneta | Perecederos |
| Marcos | Furgoneta | Perecederos |
| Juan | Furgoneta | Muebles |
| Marcos | Furgoneta | Muebles |
| Juan | Camión | Mudanza |
| Marcos | Camión | Mudanza |
Con estas condiciones, los conductores son independientes de la carga; el tipo de vehículos depende del conductor y el tipo de vehículo depende de la carga. En este caso hay dependencias funcionales multivaloradas, ya que algunos atributos que forman la clave dependen de otro atributo que también la forman.
Para conseguir que esta tabla esté en 4FN se necesita crear dos nuevas tablas en lugar de la tabla actual, manteniendose en cada una de ellas una dependencia múltiple. La primera tabla tendrá los atributos conductor y tipo de vehículo y la segunda, tipo de vehículo y tipo de carga. De este modo la tabla en 4FN debido a que la clave primaria de ambas tablas son todos los campos que la forman. Resultado:
| Tabla en cuarta forma normal | |
| Tipo Vehículo | Tipo Carga |
| Furgoneta | Perecederos |
| Furgoneta | Perecederos |
| Furgoneta | Muebles |
| Furgoneta | Muebles |
| Camión | Mudanza |
| Camión | Mudanza |
| Tabla en cuarta forma normal | |
| Conductor | Tipo Vehículo |
| Juan | Furgoneta |
| Marcos | Furgoneta |
| Juan | Furgoneta |
| Marcos | Furgoneta |
| Juan | Camión |
| Marcos | Camión |
Quinta Forma Normal o 5FN:
Se dice que hay dependencia de JOIN, de unión o de producto si una tabla tiene dependencia de *unión con varias de sus *proyecciones y se puede obtener la tabla por medio de la unión de dichas proyecciones.
| Proyeccion |
| *Proyección: |
| Creación de una tabla cuyos elementos forman un subconjunto de una tabla dada. Se incluyen todas las filas y algunas columnas. |
| Union |
| *Unión: |
| Formar, a partir de dos tablas, una nueva con todos los campos de una de ellas y los registros de ambas, excepto los repetidos. Ambas tablas han de tener el mismo grado y las mismas columnas. |
Una tabla esta en Quinta Forma Normal (5FN) o Forma Normal de Proyección-Unión si está en 4FN y las únicas dependencias que existen son las dependencias de unión de una tabla con sus proyecciones relacionándose entre las distintas proyecciones mediante la clave primaria o cualquier clave alternativa. La 5FN se emplea cuando en una misma tabla tenemos mucha información redundante, con pocos atributos o cuando una tabla posee una gran cantidad de atributos y se hace por ello inmanejable.
Para conseguir que una tabla 4FN con gran cantidad de atributos esté en 5FN, se parte la tabla original en tantas tablas como se desee, teniendo cada una de ellas en común con las demás los campos que forman la clave primaria en la tabla original.
Ejemplo para el caso de una tabla que posee una gran cantidad de atributos:
| Tabla | ||||||||||||
| Id | Datos Familiares | Datos Profesionales | Datos Personales | Datos Clínicos | ||||||||
| 1 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 |
En este caso tenemos una empresa donde se guardan los datos personales, familiares, profesionales y clínicos de cada empleado en una única tabla llamada Empleados. Si esta tabla está ya en 4FN, se puede partir en las tablas empleados-personal, empleados-familia, empleados-profesional, empleados-clínicos; de este modo, la velocidad de acceso y la gestión de datos por cada departamento de la empresa se simplifica, al no tenerse que crear ningún tipo de restricción sobre determinados atributos que no han de ser vistos por el personal que no los necesite.
El resultado sería:
| Tabla en quinta forma normal | |||
| Id | Datos Familiares | ||
| 1 | D1 | D2 | D3 |
| Tabla en quinta forma normal | |||
| Id | Datos Profesionales | ||
| 1 | D4 | D5 | D6 |
| Tabla en quinta forma normal | |||
| Id | Datos Personales | ||
| 1 | D7 | D8 | D9 |
| Tabla en quinta forma normal | |||
| Id | Datos Clínicos | ||
| 1 | D10 | D11 | D12 |
Ejemplo para el caso de una tabla que posee mucha información redundante, con pocos atributos:
| Tabla que no esta en quinta forma normal | ||
| Biblioteca | ||
| Título | Fecha | Socio |
| T1 | FT | S1 |
| T2 | FU | S2 |
| T3 | FV | S1 |
| T4 | FG | S4 |
| T1 | FH | S3 |
| T2 | FT | S4 |
| T3 | FV | S3 |
Si se tiene una tabla de préstamo de libros de una biblioteca, con los atributos título, fecha de préstamo y número de socios que ha tomado prestado el libro, existen multitud de registros que se crean diariamente en esa tabla, pero para cada libro o para cada socio habrá pocos registros, con lo que una consulta para esa tabla como: ¿Cuáles son los libros leídos por un determinado socio?, puede tener una velocidad de respuesta elevada. Si esta tabla se parte en las tablas título-fecha, título-socio y socio-fecha, cualquier consulta similar a la anterior tendrá un tiempo de respuesta tolerable, y cuando sea necesario, se podrán realizar consultas que impliquen los datos de las tres tablas.
El resultado sería pues:
| Tabla en quinta forma normal | |
| Título-Fecha | |
| Título | Fecha |
| T1 | FT |
| T2 | FU |
| T3 | FV |
| T4 | FG |
| T1 | FH |
| T2 | FT |
| T3 | FV |
| Tabla en quinta forma normal | |
| Título-Socio | |
| Título | Socio |
| T1 | S1 |
| T2 | S2 |
| T3 | S1 |
| T4 | S4 |
| T1 | S3 |
| T2 | S4 |
| T3 | S3 |
| Tabla en quinta forma normal | |
| Fecha-Socio | |
| Fecha | Socio |
| FT | S1 |
| FU | S2 |
| FV | S1 |
| FG | S4 |
| FH | S3 |
| FT | S4 |
| FV | S3 |
Y con esto concluyo el artículo, espero haber resuelto todas las dudas posibles sobre optimización de tablas mediante las formas normales.
PD: Mi más sincera enhorabuena a todos los que hayáis tenido el valor de leeros todo el artículo...
Este artículo está bajo licencia CopyLeft. Se permite pués su libre distribución con la única condición de incluir el nombre del autor y un enlace a la web original.
