Una base de datos tiene que ser diseada antes de que pueda ser creada y usada.

El diseo debe ajustarse a estndares que permitan ahorro de memoria, acceso rpido, fcil mantenimiento, portabilidad, facilidad de futuros mejoramientos, buen desempeo y eficiencia de costos, entre otros. El diseo lgico final de una base de datos debe ser tal que equilibre un desempeo ptimo junto con la integridad de la informacin. Esto puede ser logrado a travs de un proceso conocido como Normalizacin. La base de datos debe estar en un estado de "Forma completamente normalizada". DEFINICIN DE NORMALIZACION Normalizacin es una serie de reglas que involucra anlisis y transformacin de las estructuras de los datos en relaciones que exhiban propiedades nicas de consistencia, mnima redundancia y mxima estabilidad.

La necesidad para normalizar puede ser mejor comprendida al mencionar las distintas anomalas o desventajas de los datos NO NORMALIZADOS. Consideremos la tabla en la figura 3. La tabla contiene todos los detalles de los empleados de una compaa, y los detalles del Departamento al que pertenecen.

Figura 3

A primera vista, parece conveniente almacenar todos los detalles en una sola tabla. Pero ciertas anomalas se pueden manifestar durante la insercin, actualizacin y borrado de datos. La normalizacin provee un mtodo de remover todas estas indeseables anomalas haciendo la base de datos mas confiable y estable.

Anomala de insercin (INSERT) Suponga que un nuevo Departamento ha sido creado, el cual no tiene empleados todava, por lo tanto, en nuestra tabla original, los datos correspondientes al empelado estaran vacos (nulos), y solo tendramos la informacin del Departamento: Columnas "numDept" y "descDept". Anomala de Actualizacin (UPDATE)

Suponga que el nmero del Departamento de "Sistemas" ha sido cambiado a AB108. Esto involucra tener q1ue cambiar el numero del departamento para todos los empleados que pertenezcan al departamento de "Sistemas", lo cual representa tiempo y recursos de sistema adicionales. Anomala de borrado (DELETE)

Si todos los empleados en el Departamento de "Finanzas" abandonan la compaa, todos los registros de estos tendran que ser borrados. Hecho as, los detalles del Departamento "Finanzas" se perderan. Los datos en la tabla entonces no representan una informacin correcta sobre el estado de la compaa, y por lo tanto se pierde la integridad de los datos.

PROPIEDADES DE UNA BASE DE DATOS DESPUS DE LA NORMALIZACION Una base de datos normalizada debe representar las siguientes propiedades:

Los requerimientos para almacenamiento de datos se minimizan, dado que el proceso de normalizacin sistemticamente elimina la duplicacin de los datos. Desde que los datos son almacenados en el mnimo nmero de lugares, las posibilidades de inconsistencias en la informacin son reducidas al mnimo. Las estructuras normalizadas son ptimas para efectuar actualizaciones de los datos. Dado que los datos existen en el mnimo nmero de lugares, una operacin de actualizacin (UPDATE) necesitar acceder a una mnima cantidad de datos.

PROCEDIMIENTOS DE NORMALIZACION El proceso de normalizacin involucra bsicamente tres pasos. Despus de cada paso, la base de datos se convierte en formas llamadas "formas normales". Generalmente, la "tercera forma normal" es el estado que debe alcanzar una base de datos para que se diga que est totalmente normalizada. La cuarta y la quinta forma normal tambin existen, pero no son usadas en el diseo de una base de datos.

A continuacin, consideremos un pequeo ejercicio acerca de un Documento de Orden de Compra, el cual trataremos de convertirlo a una forma normalizada. Pero antes explicaremos unas pequeas reglas: Propiedades de una relacin

Un tabla debe satisfacer ciertos criterios previos antes de calificar para convertirse en una relacin. No duplicados

No debe haber nunca dos columnas o filas totalmente idnticas. Si dos filas son totalmente idnticas, entonces hacen falta algunos atributos que las haga diferentes y distinguibles. Ejemplo: Dos registros de discos compactos en una tienda seran idnticos si son dos copias del ltimo lbum de Shakira, si no fuera porque cada disco compacto tiene un numero cdigo que los hace diferentes. Clave nica

Cada registro tiene que tener una llave nica que lo identifique. Cualquier atributo puede ser una llave, pero en lo posible trataremos de elegir como llave nica al atributo que tenga una longitud menor y fija, como por ejemplo un numero de ID. Si un atributo es insuficiente para identificar un registro de manera nica, entonces mas de un atributo puede conformar la llave nica. En tal caso, el nmero de atributos que conformen una llave debe ser el mnimo necesario y suficiente. Insignificancia del orden

La secuencia en la cual los atributos son escritos no debe importar. Podemos escribir el ID del empleado de primero, o el nombre y el apellido de primero, y esto no afectar las relaciones que establezcamos con otras tablas. Por otro lado, los registros deben ser totalmente independiente de su secuencia o posicin en la base de datos (dependencia posicional). Esto significa que si intentamos identificar un registro por su posicin dentro de la tabla, estaremos creando una llave invlida. Forma no-normalizada

Los datos, en su forma elemental, no estn normalizados. Por lo tanto, lo primero con lo que debemos comenzar es con los datos elementales o bsicos que conformarn el diccionario de datos. El diccionario de datos es creado a partir de los documentos o diagramas de flujo de la compaa. Se deben listar los elementos uno debajo del otro. As, obtendremos la forma nonormalizada para el ejercicio de ARD (Anlisis Relacional de Datos), con el cual deberemos obtener al final distintos grupos de elementos. Mas tarde, dichos grupos se combinarn con los grupos de otros documentos al cual tambin se les ha hecho el anlisis ARD, y se establecern relaciones entre ellos. Consideremos el documento ORDEN DE COMPRA de la figura 4, usado para colocar una orden de pedido al proveedor de discos compactos.

Figura4 Esta es la descripcin general del Anuncio. es una breve explicacin del cursos que sirva como gua al estudiante. Esta es la descripcin general del curso. es una breve explicacin del cursos que sirva como gua al estudiante. Esta es la descripcin general del curso. es una breve explicacin del cursos que sirva como gua al estudiante. ORD-NO: Nmero de Oreden de Compra

ORD-DATE : Fecha de la Orden de Compra

PROV-NO: Numero del Proveedor

PROV-NAME: Nombre del Proveedor

PROV-DIR: Direccin del Proveedor

PROV-NIT: NIT o Cdula del Proveedor

CODIGO: Cdigo del CD o lbum

TITULO: Titulo del CD o lbum

CANT : Cantidad de CDs a pedir

VR-UNIT: Valor unitario del CD o lbum

Incluso las formas no normalizadas deben tener una llave. En el ejemplo de arriba, podemos deducir que ORD-NO es la llave. Las llaves usualmente son subrayadas durante el anlisis ARD.

PRIMERA FORMA NORMAL (1FN) Regla 1. Separar el grupo repetitivo:

En la lista de arriba, los tems despus de PROV-NIT son repetitivos, esto quiere decir, que para una misma orden aparecen varias veces, dado que en una misma orden se pueden encargar varias categoras, o varios ttulos de la misma categora.

Los grupos repetitivos deben ser separados de la UNF y ser escritos como un grupo independiente con su respectiva llave. Este grupo debe relacionarse con el grupo no repetitivo

Grupo NO Repetitivo ORD-NO

ORD-DATE

PROV-NO

PROV-NAME

PROV-DIR

PROV-NIT Grupo Repetitivo CODIGO

TITULO

CANT

VR-UNIT El grupo repetitivo tiene a CODIGO como llave. Sin embargo, esta llave no es nica, dado que se puede repetir en otros nmeros de orden. Necesita ser combinada con la llave del primer grupo. Al combinar el campo ORD-NO junto con el campo CODIGO para el segundo grupo, podemos deducir que esta combinacin puede actuar como llave nica, ya que no puede haber una misma orden que tenga 2 cdigos iguales. Por lo tanto, despus de aplicar la primera forma normal, obtenemos estos grupos:

GRUPO 1 ORD-NO

ORD-DATE

PROV-NO

PROV-NAME

PROV-DIR

PROV-NIT GRUPO 2 ORD-NO CODIGO

TITULO

CANT

VR-UNIT SEGUNDA FORMA NORMAL (2FN) Regla 2. Separar dependencias de las llaves compuestas.

Solo aquellos grupos de datos que tengan llaves combinadas son analizados. (llaves que tengan mas de un campo o atributo para lograr unicidad). Por lo tanto, para la segunda forma normal, nos concentraremos solo en el grupo 2, el cual tiene una llave compuesta.

En el grupo2 , cualquier atributo que no dependa enteramente de la llave compuesta (es decir, que no dependa de todos los atributos de la llave a la vez sino de solo uno de ellos) es separado del grupo principal, y es aislado en un grupo independiente junto con el atributo de la llave inicial del cual s es dependiente. Veamos el proceso para que haya mayor claridad:

Al analizar el grupo 2, encontramos que el campo TITULO depende enteramente del campo CODIGO, y no de la llave compuesta. Llegamos a esta conclusin deduciendo que el ttulo del CD esta asociado a un nico cdigo, por lo cual podramos pensar que CODIGO y TITULO son campos redundantes ya que con cualquiera de ellos podemos identificar al elemento, pero pensemos en que el diseo no nos permite deshacernos de ninguno de los campos, ya que las instrucciones nos obligan a usar y almacenar TODA la informacin disponible en el diccionario de datos.

Por ello, lo que s podemos hacer, aplicando la segunda forma normal, es aislar un tercer grupo, que tenga a CODIGO como llave, y TITULO como campo de la tabla. Igua sucede con el campo VR-UNIT. Este campo esta asociado exclusivamente al campo CODIGO. Esto es, cada Titulo de CD con un cdigo determinado, debe corresponder a un valor de evnta que se establece una sola vez por cada elemento. De esta manera, si en algun momento necesitamos alterar el valor unitario de un CD, solo debemos hacerlo en la tabla del grupo 3, una nica vez por elemento.

En conclusin , despus de aplicar la segunda forma normal, obtenemos estos grupos: GRUPO 1 ORD-NO

ORD-DATE

PROV-NO

PROV-NAME

PROV-DIR PROV-NIT GRUPO 2 ORD-NO CODIGO

CANT GRUPO 3 CODIGO

TITULO

VR-UNIT

En este nivel, ya nos podemos imaginar mentalmente la utilidad de separar el diccionario de datos en distintos grupos. Imaginmonos que queremos ingresar 50 ordenes al sistema, y en todas est incluido el CD de Juanes, cuyo cdigo es 1520. El ttulo asociado al cdigo 1520 es "Fjate bien". Si no existiera el grupo 3, para cada una de las ordenes estaramos ingresando no solo 50 veces el cdigo 1520, sino que tambin nos toca digitar 50 veces el texto "Fjate bien" . Consideramos que esto ltimo es un trabajo que se puede ahorrar al aplicar la segunda forma normal, ya que si dejamos una tabla separada para CODIGO y TITULO, al ingresar las ordenes solo nos toca digitar 50 veces el cdigo 1520 en la tabla del grupo 2 (cada vez asociado a un nmero de orden distinto y nico), y UNA sola vez el mismo cdigo en la tabla 3, con lo cual el texto "Fjate bien" solo tendra que ser digitado una sola vez por ende. En el

evento en que se nos pida consultar el titulo del CD en un registro de la tabla 2, simplemente usaremos el valor del campo CODIGO de dicho registro para trasladar la consulta a la tabla 3, quien nos devolver la informacin buscada del Titulo.

Si han logrado entender la justificacin de la normalizacin con el ejemplo anterior, tenemos ya un gran terreno ganado en el proceso de aprender a disear bases de datos.

TERCERA FORMA NORMAL (3FN) Regla 3. Examinar las interdependencias entre los campos o atributos que no son llaves.

Todos los campos o atributos en cada grupo que no sean llaves, deben ser examinados para chequear que no existan interdependencias entre ellos. Si se encuentran algunas, tales dependencias deben ser separadas en distintos grupos cuya llave debe ser el campo del cual son dependientes, dejando este campo llave tambin en el grupo original.

Si analizamos el grupo 1, encontramos que los campos PROV-NAME, PROV-DIR y PROV-NIT son enteramente dependientes del campo PROV-NO.

Del grupo 2 ya sacamos las interdependencias durante la segunda forma normal, y el grupo tres es precisamente el resultado de esa separacin en la segunda forma normal, por lo tanto lo ignoramos en esta etapa. Nos concentramos solo en el grupo 1.

Al separar en un grupo la informacin del proveedor, dejando un cuarto grupo con esta informacin, obtenemos la tercera forma normal, la cual queda de la siguiente manera: GRUPO 1 ORD-NO

ORD-DATE

PROV-NO GRUPO 2 ORD-NO

CODIGO

CANT GRUPO 3 CODIGO

TITULO

VR-UNIT GRUPO 4 PROV-NO PROV-NAME

PROV-DIR

PROV-NIT RESUMEN DE LA NORMALIZACION UNF - FORMA NO NORMALIZADA Diccionario de datos 1NF - PRIMERA FORMA NORMAL

Separar el grupo repetitivo 2NF - SEGUNDA FORMA NORMAL Separar dependencias de llaves compuestas 3NF - TERCERA FORMA NORMAL Separar dependencias de los campos no llaves ""

A travs del siguiente ejercicio se intenta afirmar los conocimientos de normalizacin con un ejemplo simplificado de una base de datos para una pequea biblioteca.

CodLibro 1001 1004 1005 1006 1007

Titulo Variable compleja Visual Basic 5 Estadstica Oracle University Clipper 5.01

Autor Murray Spiegel E. Petroustsos Murray Spiegel Nancy Greenberg y Priya Nathan Ramalho

Editorial McGraw Hill Anaya McGraw Hill Oracle Corp. McGraw Hill

NombreLector

FechaDev

Prez Gmez, Juan 15/04/2005 Ros Tern, Ana Roca, Ren Garca Roque, Luis 17/04/2005 16/04/2005 20/04/2005

Prez Gmez, Juan 18/04/2005

Esta tabla no cumple el requisito de la Primera Forma Normal (1NF) de slo tener campos atmicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla. 1NF
CodLibro 1001 1004 1005 1006 1006 1007 Titulo Variable compleja Visual Basic 5 Estadstica OracleUniversity OracleUniversity Clipper 5.01 Autor Murray Spiegel E. Petroustsos Murray Spiegel Editorial Paterno Materno Nombres Gmez Tern Juan Ana Ren Roque Roque Gmez Luis Luis Juan FechaDev 15/04/2005 17/04/2005 16/04/2005 20/04/2005 20/04/2005 18/04/2005

McGraw Hill Prez Anaya Ros

McGraw Hill Roca

NancyGreenberg Oracle Corp. Garca Priya Nathan Ramalho Oracle Corp. Garca McGraw Hill Prez

Como se puede ver, hay cierta redundancia caracterstica de 1NF. La Segunda Forma Normal (2NF) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave deben depender por completo de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como atributo clave el cdigo del libro.

Por ejemplo, el ttulo es completamente identificado por el cdigo del libro, pero el nombre del lector en realidad no tiene dependencia de este cdigo, por tanto estos datos deben ser trasladados a otra tabla. 2NF
CodLibro 1001 1004 1005 1006 1006 1007 Titulo Variable compleja Visual Basic 5 Estadstica Oracle University Oracle University Clipper 5.01 Autor Murray Spiegel E. Petroustsos Murray Spiegel Editorial McGraw Hill Anaya McGraw Hill

NancyGreenberg Oracle Corp. Priya Nathan Ramalho Oracle Corp. McGraw Hill

La nueva tabla slo contendr datos del lector.

CodLector Paterno Materno Nombres 501 502 503 504 Prez Ros Roca Garca Roque Gmez Tern Juan Ana Ren Luis

Hemos creado una tabla para contener los datos del lector y tambin tuvimos que crear la columna CodLector para identificar unvocamente a cada uno. Sin embargo, esta nueva disposicin de la base de datos necesita que exista otra tabla para mantener la informacin de qu libros estn prestados a qu lectores. Esta tabla se muestra a continuacin:

CodLibro CodLector 1001 1004 1005 1006 1007

FechaDev

501 15/04/2005 502 17/04/2005 503 16/04/2005 504 20/04/2005 501 18/04/2005

Para la Tercera Forma Normal (3NF) la relacin debe estar en 2NF y adems los atributos no clave deben ser mutuamente independientes y dependientes por completo de la clave primaria. Tambin recordemos que dijimos que esto significa que las columnas en la tabla deben contener solamente informacin sobre la entidad definida

por la clave primaria y, por tanto, las columnas en la tabla deben contener datos acerca de una sola cosa. En nuestro ejemplo en 2NF, la primera tabla conserva informacin acerca del libro, los autores y editoriales, por lo que debemos crear nuevas tablas para satisfacer los requisitos de 3NF. 3NF
CodLibro Titulo 1001 Variable compleja 1004 Visual Basic 5 1005 Estadstica 1006 Oracle University 1007 Clipper 5.01

CodAutor

Autor

801 Murray Spiegel 802 E. Petroustsos 803 Nancy Greenberg 804 Priya Nathan 806 Ramalho

CodEditorial

Editorial

901 McGraw Hill 902 Anaya 903 Oracle Corp.

Aunque hemos creado nuevas tablas para que cada una tenga slo informacin acerca de una entidad, tambin hemos perdido la informacin acerca de qu autor ha escrito qu libro y las editoriales correspondientes, por lo que debemos crear otras tablas que relacionen cada libro con sus autores y editoriales.

CodLibro 1001 1004 1005 1006 1006 1007

codAutor 801 802 801 803 804 806

CodLibro 1001 1004 1005 1006 1007

codEditorial 901 902 901 903 901

Y el resto de las tablas no necesitan modificacin.

CodLector Paterno Materno Nombres 501 Prez 502 Ros 503 Roca 504 Garca Roque Gmez Tern Juan Ana Ren Luis

CodLibro CodLector 1001 1004 1005 1006 1007

FechaDev

501 15/04/2005 502 17/04/2005 503 16/04/2005 504 20/04/2005 501 18/04/2005

El proceso de normalizacin de bases de datos relacionales

La normalizacin de bases de datos relacionales toma un esquema relacional y le aplica un conjunto de tcnicas para producir un nuevo esquema que representa la misma informacin pero contiene menos redundancias y evita posibles anomalas en las inserciones, actualizaciones y borrados.

Breve recordatorio del modelo (formal) relacional

El modelo relacional de bases de datos se basa en un modelo formal especificado de acuerdo a la teora de conjuntos. Una base de datos relacional puede considerarse como un conjunto de relaciones o tablas de la forma R(A1, ..., An), donde R es el nombre de la relacin, que se define por una serie de atributos Ai. Sobre las tablas relacionales se pueden definir diferentes restricciones. La integridad de entidad es una restriccin que nos indica que cada entidad representada por una tupla tiene que ser diferente de las dems en su relacin, es decir, debe haber algunos atributos cuyos valores identifiquen unvocamente las tuplas. La integridad referencial indica que una clave ajena solo debe contener valores que o bien sean nulos, o bien existan en la relacin referenciada por la clave ajena.

El proceso de normalizacin
El proceso de normalizacin consiste en comprobar en secuencia si el esquema original est en 1FN, 2FN y 3FN, analizando las dependencias funcionales en cada paso.

Un ejemplo completo

Tenemos una empresa pblica donde los puestos de trabajo estn regulados por el Estado, de modo que las condiciones salariales estn determinadas por el puesto. Se ha creado el siguiente esquema relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.

nss nombre puesto salario emails 111 Juan Prez Jefe de rea 3000 juanp@ecn.es; jefe2@ecn.es 222 Jos Snchez Administrativo 1500 jsanchez@ecn.es 333 Ana Daz Administrativo 1500 adiaz@ecn.es; ana32@gmail.com ... ... ... ... ...
TABLE 1
Primera forma normal (1FN)
Una tabla est en 1FN si sus atributos contienen valores atmicos. En el ejemplo, podemos ver que el atributo emailspuede contener ms de un valor, por lo que viola 1FN. En general, tenemos una relacin R con clave primaria K. Si un atributo M viola la condicin de 1FN, tenemos dos opciones.

Solucin 1: duplicar los registros con valores repetidos

En general, esta solucin pasa por sustituir R por una nueva relacin modificada R', en la cual:

El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que tenamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relacin habr n tuplas, que slo varan en que cada una de ellas guarda uno de los valores que haba en M.

La clave primaria de R' es (K, M'), dado que podr haber valores de K repetidos, para los valores multivaluados en M.

Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con clave primaria(nss, email):

nss nombre puesto salario email 111 Juan Prez Jefe de rea 3000 juanp@ecn.es 111 Juan Prez Jefe de rea 3000 jefe2@ecn.es 222 Jos Snchez Administrativo 1500 jsanchez@ecn.es 333 Ana Daz Administrativo 1500 adiaz@ecn.es 333 Ana Daz Administrativo 1500 ana32@gmail.com ... ... ... ... ...
TABLE 2
Solucin 2: separar el atributo que viola 1FN en una tabla
En general, esta solucin pasa por:

sustituir R por una nueva relacin modificada R' que no contiene el atributo M. Crear una nueva relacin N(K, M'), es decir, una relacin con una clave ajena K referenciando R', junto al atributoM', que es la variante mono-valuada del atributo M. La nueva relacin N tiene como clave (K, M'). Siguiendo el ejemplo, tendramos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

nss nombre puesto salario 111Juan Prez Jefe de rea 3000 222Jos Snchez Administrativo 1500 333Ana Daz Administrativo 1500 ... ... ... ...
TABLE 3
Y adems tendramos una nueva tabla EMAILS con clave primaria (nss, email):

nss email 111 juanp@ecn.es 111 jefe2@ecn.es 222 jsanchez@ecn.es 333 adiaz@ecn.es 333 ana32@gmail.com ... ...
TABLE 4
Segunda forma normal (2FN)
Un esquema est en 2FN si: Est en 1FN. Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave. La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o ms atributos. Si una relacin est en 1FN y su clave primaria es simple (tiene un solo atributo), entonces tambin est en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) est en 1FN (y la tabla EMAILS no tiene atributos no clave), por lo que el esquema est en 2FN. Sin embargo, tenemos que examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a).Las dependencias funcionales que tenemos son las siguientes:

nss->nombre, salario, email puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo que la relacin no est en 2FN. En general, tendremos que observar los atributos no clave que dependan de parte de la clave.

Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con dependencia incompleta M: Eliminar de R el atributo M. Crear una nueva relacin N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'. La clave primaria de la nueva relacin ser K'. Siguiendo el ejemplo anterior, crearamos una nueva relacin con los atributos que tienen dependencia incompleta:

nss nombre puesto salario 111Juan Prez Jefe de rea 3000 222Jos Snchez Administrativo 1500 333Ana Daz Administrativo 1500 ... ... ... ...
TABLE 5
Y al eliminar de la tabla original estos atributos nos quedara:

nss email 111 juanp@ecn.es 111 jefe2@ecn.es 222 jsanchez@ecn.es 333 adiaz@ecn.es 333 ana32@gmail.com ... ...
TABLE 6
Como vemos, la solucin a la que llegamos es la misma que en la otra opcin de solucin para el problema de 1FN.

Tercera forma normal (3FN)

Una relacin est en tercera forma normal si, y slo si: est en 2FN y, adems, cada atributo que no est incluido en la clave primaria no depende transitivamente de la clave primaria. Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre atributos que no estn en la clave. En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solucin a este tipo de dependencias est en separar en una tabla adicional N el/los atributos B, y poner como clave primaria de N el atributo que define la transitividad A. Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto puesto->salario
Por lo tanto la descomposicin sera la siguiente:

nss nombre puesto 111 Juan Prez Jefe de rea 222 Jos Snchez Administrativo 333 Ana Daz Administrativo ... ... ...
TABLE 7
En la nueva tabla PUESTOS, la clave sera el puesto, que tambin queda como clave ajena referenciando la tablaEMPLEADOS. El resto de las tablas quedan como estaban.