Tema II.

Normalizacin

Pg. 1

INTRODUCCIN
Para desarrollar cualquier sistema se necesita trabajar con datos que deben ser guardados o almacenados para su uso posterior. Esto se logra definiendo estructuras de datos adecuadas (archivos), que eviten la duplicidad de informacin y el desperdicio de espacio en el medio de almacenamiento secundario. Es importante antes de disear un archivo o conjunto de archivos, ubicarse en el problema, definir los datos involucrados en el mismo y luego agruparlos en archivos de acuerdo a la afinidad o relacin que exista entre ellos, pudindose tener como resultado varios archivos conectados por campos de enlaces (campos claves); de esta manera se obtiene la Base de Datos asociada al problema que se intenta resolver. Pero todava no se ha considerado un asunto fundamental, a saber: Dado un conjunto de datos que se van a representar en una Base de Datos. Cmo se opta por una estructura lgica adecuada para esos datos?. En otras palabras Cmo se decide qu relaciones se necesitan y qu atributos deben tener?. He aqu el problema del diseo de Bases de Datos. La idea es definir una Base de Datos donde se evite la redundancia de informacin en tanto sea posible, ya que esta puede crear problemas en los datos al aplicar los procesos de actualizacin, de esta forma se debe asegurar que el modelo planteado en la normalizacin sea capaz de responder a cualquier pregunta que razonablemente se pueda plantear sobre l. Se sugiere comenzar con una relacin dada junto con una declaracin de ciertas restricciones, de tal manera que se reduzca sistemticamente la relacin inicial a un conjunto de relaciones que sean equivalentes a la original. Es necesario que quien disee una base de datos relacional, se familiarice con las tcnicas de normalizacin bsicas tal como se describen en esta gua. Extraer una lista de las variables involucradas en el problema. Agrupar variables de acuerdo a su afinidad. Chequear cada una de las formas normales.

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 2

...he viajado en mi juventud; he peregrinado en busca de un libro, acaso catlogo de catlogos... Yo me atrevo a insinuar una solucin del antiguo problema. La biblioteca es ilimitada y peridica. Si un eterno viajero la atravesara en cualquier direccin, comprobara al cabo de los siglos que los mismos volmenes se repiten en el mismo desorden... Jorge Luis Borges La Biblioteca de Babel

NORMALIZACION
Trminos Bsicos
1. Entidad: Es cualquier cosa, persona, lugar evento acerca de la cual se capturan, almacenan y procesan datos: 2. Atributo: Caracterstica que identifica un campo. 3. Dato: Es la materia prima con la cual se produce la informacin. 4. Informacin: Son los datos ya procesados. 5. Base de Datos: Es un conjunto de archivos, que estn relacionados entre s a travs de campo(s), para poder representar un problema situacin dada. 6. Visiones de Usuario: Conocida tambin como relacin; es la forma particular en que un usuario ve concibe una base de datos. Una visin de usuario, especifica una relacin funcional entre un conjunto de datos; como por ejemplo los reportes y las pantallas de consultas. Las visiones de usuario tienen dos componentes principales: Datos. Relaciones entre esos datos. 7. Redundancia: Cuando se repite la misma informacin dentro de un archivo. 8. Inconsistencia: La inconsistencia puede ser generada cuando hay redundancia. Por

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 3

ejemplo si se tiene un archivo con la informacin de los empleados de una empresa, y existen dos registros con la misma C.I. (campo clave) es evidente que existe una redundancia de informacin dentro del archivo; si en algn momento se desear cambiar la direccin de ste empleado y este cambio se realiza slo en uno de los registros, se est generando una inconsistencia en el archivo puesto que no es posible que un mismo empleado tenga dos direcciones diferentes. Es importante destacar que estos dos conceptos de Redundancia e Inconsistencia, se combaten aplicando la normalizacin en los archivos. La interrogante que se plantea es la siguiente:

?
Dado un conjunto de datos que se van a representar en una base de datos, cmo se agrupan (estructura lgica adecuada), qu atributos deben tener y que relaciones deben existir entre ellos para lograr un buen diseo en la estructura de los archivos y de esta manera obtener una ptima Base de Datos, sin redundancia ni inconsistencia.

El diseo de una buena base de datos es una actividad compleja, que se resuelve con la aplicacin de la Teora de la Normalizacin, la cual basa sus fundamentos en las Formas Normales. Se dice que una relacin (archivo o tabla) se encuentra en una forma normal en particular si satisface cierto conjunto especfico de reglas y restricciones. Se han definido numerosas Formas Normales y la aplicacin de cada una de ellas va reduciendo la estructura del archivo (nmero de campos) por un lado y va generando nuevos archivos por otro. La figura siguiente muestra las numerosas formas normales:

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 4

Universo de las Relaciones Normalizadas y no Normalizadas (Todos los campos, datos del problema que se esta analizando) Relaciones en Primera Forma Normal (1FN) Relaciones en Segunda Forma Normal (2FN) Relaciones en Tercera Forma Normal (3FN) Relaciones en Forma Normal de Boyce-Codd (FNBC) Relaciones en Cuarta Forma Normal (4FN) Relaciones en Quinta Forma Normal (5FN)

El principio bsico en la normalizacin es la eliminacin de la redundancia por medio de la descomposicin sin prdida (la capacidad de dividir relaciones sin que se pierda informacin). Este principio se formaliza en los conceptos de las formas normales. Las tres primeras formas normales (1FN, 2FN, 3FN), son las que se aplican normalmente (formas bsicas) , las tres formas normales restantes (FNBC, 4FN, 5 FN) slo se utilizan en casos excepcionales. Para efectos de esta gua se detallaran las tres formas normales bsicas que son indispensables en la normalizacin.

PRIMERA FORMA NORMAL (1FN, PFN): Se dice que un archivo se encuentra

en 1FN si y solo si, contiene nicamente campos en forma atmica. Un campo se encuentra en forma atmica cuando no se puede descomponer ms, es decir es un componente elemental (representado por el tomo), se encuentra en su mnima expresin. La estructura generada con esta primera forma normal generalmente es indeseable (podra contener redundancia y generar inconsistencias). A continuacin se cita un ejemplo en el que se aplicarn las tres primeras formas Prof. Margarita Pereira, Leonardo Ponte Agosto 2012

Tema II. Normalizacin

Pg. 5

normales, con el objetivo de aclarar los conceptos. La clave principal de las Tablas se denotar colocando el carcter * al principio del campo. Supngase que el archivo de Empleados de una compaa est diseado con la siguiente estructura: Nombre del Campo *Cdula Nombre Direccin Telfono Fecha de ingreso Estatus Examinando cada uno de sus campos para detectar si sta o no en forma atmica, se tiene lo siguiente: 1. El campo Cdula podra ser representado de varias maneras. As una cdula puede estar formada por puros nmeros, pero tambin puede estar formada por una letra V E (indica la nacionalidad) seguida del nro. de cdula. Quiere decir entonces que el campo cdula no est en forma atmica ya que pudiera ser descompuesto en dos campos: Nacionalidad y Nro. de Cdula. Segn esta descomposicin, podemos saber la nacionalidad de un empleado con slo examinar el campo Nacionalidad. Claro esta que esta descomposicin NO ES ESTRICTAMENTE OBLIGATORIA, ya que con una simple instruccin del lenguaje de programacin que se este usando se podra extraer la nacionalidad del campo cdula (tomando como base que el campo cdula contendr la letra de la nacionalidad seguida del nro. de la cdula), es decir podramos averiguar la nacionalidad de un empleado aunque su cdula no est descompuesta, haciendo uso de alguna instruccin del lenguaje de programacin que permita extraer el primer carcter del dato cdula, algo as: nacionalidad = empleados.cdula[1] Podremos obtener la nacionalidad del empleado. Nombre del Campo Nacionalidad *Cdula Nombre Direccin Telfono Fecha de ingreso Estatus Prof. Margarita Pereira, Leonardo Ponte Agosto 2012

Tema II. Normalizacin

Pg. 6

2. El campo Nombre, pudiera ser descompuesto en Nombre y Apellido, para llevarlo a su forma atmica. La situacin es este caso pudiera ser similar a la anterior. La descomposicin NO ES ESTRICTAMENTE OBLIGATORIA. 3. El campo Direccin, es un caso muy particular. Es de hacer notar que no existen reglas definidas para representar una direccin; as dentro de la direccin se puede especificar la ciudad y el estado, entonces tratemos de responder las siguientes preguntas:

?
Podemos listar los empleados que viven en algn Estado especfico Podemos listar los empleados que viven en una Ciudad especfica

Ninguna de las preguntas anteriores puede ser respondida de manera automtica, en vista de que sera imposible crear un procedimiento capaz de general los listados anteriores. En este caso, si se requiere satisfacer los requerimientos anteriores (requerimientos del usuario), necesariamente se debe descomponer el campo direccin en tres campos: Direccin, Ciudad, Estado. Aqu la descomposicin ES ESTRICTAMENTE OBLIGATORIA.

Tabla de Empleados
Nombre del Campo Nacionalidad *Cdula Nombre Direccin Ciudad Estado Telfono Fecha de ingreso Estatus Con esta nueva estructura si podemos producir los listados de empleados por

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 7

estado y ciudad. Usando las siguientes instrucciones de SQL: Listado de Empleados que viven en el Estado Lara SELECT Cdula, Nombre FROM Empleados WHERE Estado = Lara AND Estatus =A Listado de Empleados que viven en la Ciudad de Barquisimeto SELECT Cdula, Nombre FROM Empleados WHERE Ciudad = Barquisimeto AND Estatus =A Sin embargo esta solucin presenta un problema Qu pasa si en la tabla hay empleados cuya ciudad dice Barqto y no Barquisimeto? Obviamente las filas de la tabla que no contengan Barquisimeto no aparecern en el listado, entonces el resultado no es correcto. Una forma de resolver este inconveniente es codificando las ciudades y los estados para ello se generan las siguientes tablas:

Tabla de Ciudades
Nombre del Campo *Cod_ciudad Nombre_ciudad

Tabla de Estados
Nombre del Campo *Cod_estado Nombre_estado

Y por consiguiente la Tabla de Empleados quedara as:

Nombre del Campo

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 8

Nacionalidad *Cdula Nombre Direccin Cod_Ciudad Cod_Estado Telfono Fecha de ingreso Estatus Esta solucin es mejor que la anterior, sin embargo presenta otro detalle, no hay forma de verificar que el dato Ciudad pertenezca al dato Estado, es decir si Cod_ciudad = 01 y corresponde a Barquisimeto y el Cod_Estado = 03 y corresponde a Zulia este dato es invalido ya que Barquisimeto no pertenece al Estado Zulia. Para resolver esta inconsistencia debemos hacer un cambio en la Tabla de Ciudades Nombre del Campo *Cod_Estado *Cod_Ciudad Nombre_ciudad Esta nueva tabla no permite tener Ciudades que no se correspondan con su Estado y la Clave Primaria sera una clave compuesta 4. El campo Telfono, pudiera ser descompuesto en Cdigo de rea y Nmero, para llevarlo a su forma atmica. La situacin es este caso pudiera ser similar a la del campo Cdula. La descomposicin NO ES ESTRICTAMENTE OBLIGATORIA. 5. El campo Fecha de ingreso, pudiera ser descompuesto en Da, Mes y Ao, para llevarlo a su forma atmica. La situacin es este caso pudiera ser similar a la del campo Cdula. La descomposicin NO ES ESTRICTAMENTE OBLIGATORIA. 6. El campo Estatus, se encuentra en su forma atmica ya que no puede descomponerse ms. Finalmente al aplicar la 1FN (descomposicin de campos obligatorios de acuerdo a los requerimientos del usuario) nuestra tabla de empleados quedara como sigue: Nombre del Campo

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 9

*Cdula Nombre Direccin Ciudad Estado Telfono Fecha de ingreso Estatus En conclusin, las descomposiciones deben seguir un criterio. DESCOMPOSICIONES OBLIGATORIAS Y NO OBLIGATORIAS. En otras palabras, NO es necesario descomponer siempre hasta la mnima expresin. Como se observ en el ejemplo anterior con los campos Cdula, Telfono y Fecha de Ingreso. En el caso del campo Direccin pudieran hacerse otras descomposiciones como agregar los campos Avenida, Calle, Edificio y otros, sin embargo las descomposiciones tan detalladas son poco comunes. Surge entonces un DILEMA:

? HASTA DONDE DEBO DESCOMPONER

Aparentemente no existe una regla fija al respecto, sin embargo existen dos elementos que pueden ayudar: 1. Los requerimientos del usuario: son muy importantes ya que determina como el usuario desea la informacin. As si el usuario desea saber cuales empleados viven en un edificio determinado, entonces el diseador deber crear el Campo Edificio para satisfacerlo; aunque este nivel de detalle es poco comn. 2. La experiencia del diseador: puede ayudar porque quizs el usuario no exprese la necesidad de obtener algn listado de los empleados por la ciudad donde viven, sin embargo el diseador puede hacer la sugerencia y el usuario evaluar la importancia no del detalle de la informacin.

SEGUNDA FORMA NORMAL (2FN, SFN): Se dice que un archivo se

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 10

encuentra en 2FN, si y solamente s: 2. Esta en 1FN. 2. Cada uno de los campos no claves dependen funcionalmente de la clave principal (se recuerda que la clave principal debe ser nica). Nace un nuevo concepto DEPENDENCIA FUNCIONAL: Un valor determina funcionalmente a otro, si para cada valor del primero existe un nico valor del segundo; en otras palabras: Dada una relacin R, el atributo Y de R es funcionalmente dependiente del atributo X de R si y slo si cada valor de X en R tiene asociado a l exactamente un valor de Y en R en cualquier instante. Luego se puede decir que una dependencia funcional es en cierta forma una restriccin de integridad. Es importante aclarar que los campos que no dependan funcionalmente de la clave principal deben ser extrados del archivo para formar nuevo(s) archivo(s). Se presenta un ejemplo para aclarar el concepto de DEPENDENCIA FUNCIONAL: * NOTA (Escala 100) NOTA (Escala 20) 97 19 67 13 48 10 47.4 9 ... ...

Aqu la Nota (Escala de 100) determina funcionalmente a Nota (Escala 20) y se denota matemticamente as Nota(Escala 100) -> Nota(Escala 20) Examinando la Tabla de Empleados resultante del ejemplo anterior: Primero: se determina el campo clave principal, para el caso de estudio es el campo Cdula. Segundo: se evala el resto de los campos para chequear si dependen Prof. Margarita Pereira, Leonardo Ponte Agosto 2012

Tema II. Normalizacin

Pg. 11

funcionalmente de la clave. As para un valor de Cdula existe un slo Nombre, una sola Direccin, un solo Estado, una sola Ciudad, un slo Telfono y una sola fecha de ingreso; por lo tanto ste archivo se encuentra en 2FN. Cdula (campo clave) Nombre (campo no clave); se interpreta como Nombre depende funcionalmente del campo Cdula. Tercero: Una forma de verificar que las dependencias funcionales sean las correctas es chequeando que no ocurran problemas con las tres operaciones bsicas de Actualizacin: Insercin, Modificacin y Eliminacin, conocidas comnmente como Anomala de Inclusin, Modificacin y Eliminacin respectivamente. Para entender mejor el trmino siguiente ejemplo: de dependencias funcionales se presenta el

Filopmenes Ulacio (De los Ulacio de Mene Grande Estado Zulia), es un Comerciante que comenz vendiendo ropa a crdito de casa en casa utilizando una bicicleta como transporte. Con el tiempo y como suele suceder en este hermoso pas de las oportunidades, el negocio comenz a crecer. Al principio, las cuentas eran tan pequeas que las llevaba en la mente. Luego pas a un cuaderno caribe, (Esos que tiene un Indio en la portada) y el negocio segua creciendo!!!. Fue en ese instante, donde realiz un Curso de Excel y dise una Hoja para controlar a sus clientes. Como resultado, Filo (As le decimos sus Panas) dijo a su Esposa y pequeos hijos que el negocio estaba automatizado. Sin embargo, con el pasar del tiempo surgieron varios problemas en el diseo, en vista de que toda la informacin se coloc en un solo Archivo (La Hoja de Clculo) El Archivo en cuestin fue denominado Transacciones, y se encuentra conformado como sigue:
*Nro.deTrans. C.I. cliente Nombre FechaTrans Monto Trans Calificacin Lmite Crdito

0221 0528 1010 2525

7544 7833 7544 7117

Antonio Mara Carlos Enrique

12-02-99 01-02-99 23-12-98 25-01-99

50.000,00 99.000,00 10.000,00 98.000,00

Regular Bueno Regular Bueno

25.000,00 75.000,00 25.000,00 80.000,00

NOTA: El Lmite de Crdito pertenece al cliente y la Calificacin se establece de acuerdo al Lmite de Crdito. Observemos los siguientes detalles en los datos de la tabla anterior:

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 12

La C.I. 7544 aparece dos veces en la tabla, la primera vez se corresponde con el Nombre Antonio y la segunda vez aparece con el Nombre Carlos, esto es una inconsistencia ya que dos personas no pueden tener el mismo nro. de cdula de identidad. Se presenta una ANOMALA DE INCLUSIN porque para poder incluir un nuevo cliente necesariamente tengo que incluir una transaccin, de la misma manera para incluir un lmite de crdito con su calificacin necesito incluir una transaccin, estas situaciones son inadecuadas y carecen de sentido comn. Se presenta una ANOMALA DE MODIFICACIN ya que se pueden modificar algunos campos y crear inconsistencia en los datos. Esto debi ocurrir con la Cdula 7544. Se presenta una ANOMALA DE ELIMINACIN ya que al eliminar una transaccin se corre el riesgo de eliminar un cliente. En la tabla del ejemplo si se elimina la Transaccin 0528 se elimina el cliente Mara. En importante que observe que si no hay ANOMALA DE INCLUSIN tampoco habr de MODIFICACIN ni ELIMINACIN. Entonces ahora apliquemos por paso el concepto de dependencia funcional a la tabla de Transaccin de la siguiente manera: 1. Ubicamos el campo clave principal. En este caso es el Nro. de Trans., que es un campo clave nico (clave principal). 2. Examinemos las dependencias funcionales de los campos no claves (C.I., Nombre, Fecha Trans., Monto, Calificacin, Lmite de Crdito). Se observa las siguientes dependencias funcionales: Nro. de Trans. Nro. de Trans. Nro. de Trans. C.I. cliente (una transaccin involucra un slo cliente el cual est identificado por su Cdula de Identidad) Fecha Trans. (una transaccin es realizada en una fecha en particular ) Monto (una transaccin tiene un monto especfico)

La interrogante a plantear sera:

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 13

? Qu pasa con el resto de los campos

Existen campos que no forman parte de la clave y an as no dependen funcionalmente de la misma, lo cual es incorrecto y no satisface el concepto de 2FN. Este es el caso de los campos Nombre, Calificacin y Lmite de Crdito. Analizando cada uno de ellos se tiene que: El Nombre de una persona esta dado por su C.I. (Nombre depende de C.I,). Es obvio que el nombre de una persona no va a depender del nmero de la transaccin que se est realizando, ya que una persona puede realizar varias transacciones cada una identificada por un nro. de transaccin diferente (campo clave nico). C.I. Cliente Nombre Cliente El Lmite de Crdito de un cliente depende del cliente y no del nro. de la transaccin que este realizando. Qu campo identifica a un cliente? . La respuesta es la C.I. por lo tanto: C.I. Cliente Lmite de Crdito Un cliente tiene una sola Calificacin, la cual esta dada de acuerdo al lmite de crdito que tenga el cliente, por lo tanto se tiene que: C.I. Cliente Calificacin Estos tres campos deben ser eliminados del archivo de transacciones y se deben colocar en otro archivo. Este nuevo archivo creado con los campos no dependientes de la clave debe ser evaluado de la misma manera que el archivo de transacciones hasta que se encuentre en la 2FN. Al evaluar los campos no claves resultan dos archivos. 1. Archivo de Transacciones Nombre del Campo *Nro. de Trans. C.I. cliente Fecha Trans. Monto Trans.

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 14

2. Archivo Identificacin del Cliente (Archivo Nuevo) Nombre del Campo C.I. cliente (Clave) Nombre Calificacin Lmite de Crdito En este momento tenemos dos archivos, Transacciones y Cliente los cuales estn enlazados por el campo C.I. cliente. En general en el proceso de reduccin de un archivo (disminucin del nro. de campos y creacin de nuevos archivos enlazados a travs de campo(s)) es lo que se conoce con el nombre de la descomposicin sin prdidas, no se debe perder ninguna informacin, es decir cualquier informacin que se pueda derivar de la estructura original tambin se puede derivar de la estructura nueva. No obstante, la recproca no es verdadera; en ste sentido la estructura nueva es un reflejo algo ms fiel del mundo real. Archivo de Transacciones
*Nro.deTrans. C.I. cliente FechaTrans Monto Trans

0221 0528 1010 2525

7544 7833 7544 7117 Archivo de Clientes

12-02-99 01-02-99 23-12-98 25-01-99

50.000,00 99.000,00 10.000,00 98.000,00

*C.I. cliente Nombre

Calificacin Lmite Crdito

7544 7833 7544 7117

Antonio Mara Carlos Enrique

Regular Bueno Regular Bueno

25.000,00 75.000,00 25.000,00 80.000,00

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 15

!
En general, en esta forma normal, se identifican los grupos repetitivos de informacin y se extraen para otro archivo que debe tener un enlace ( campo clave) con el archivo original. Para ello se identifica la clave y las variables que son dependientes de la misma para formar un archivo, las variables no dependientes de la clave se extraen para otro archivo.

TERCERA FORMA NORMAL (3FN, TFN): Se dice que un archivo se encuentra en 3FN, si y solamente s: 1. Esta en 2FN. 2. No existen dependencias Transitivas, es decir s A ByB C entonces A C.

Analizando los dos archivos resultantes de la 2FN se tiene que: En el Archivo 1 (Transacciones) no se presenta esta situacin, pero en el Archivo 2 se observa que: C.I. Cliente Lmite de Crdito Calificacin, entonces por transitividad se tiene que

Lmite de Crdito C.I. Cliente

Calificacin

Para resolver esto debo eliminar del Archivo 2 el campo que se obtiene por transitividad que es el Campo Calificacin y crear un nuevo archivo con este campo y el campo que lo identifica. Finalmente el resultado de la aplicacin de las tres formas normales es el siguiente:

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 16

1. Archivo de Transacciones Nombre del Campo *Nro. de Trans. (Clave) C.I. cliente Fecha Trans. Monto Trans. 2. Archivo Identificacin del Cliente (Archivo Nuevo) Nombre del Campo *C.I. cliente (Clave) Nombre Lmite de Crdito 3. Archivo Calificacin del Crdito (Archivo Nuevo) Nombre del Campo *Lmite de Crdito (Clave) Calificacin Verificando las ANOMALIAS DE ACTUALIZACIN se observa que si se quiere incluir un nuevo cliente slo grabo una vez sus datos nombre, lmite de crdito en el ARCHIVO IDENTIFICACIN DE CLIENTE (no hay redundancia). De la misma forma se puede analizar el archivo de Calificacin de Crdito, si el banco decide abrir una nueva Calificacin slo se incluye una vez en el Archivo 3 sin importar cuantos clientes vayan a tener dicha calificacin ni cuantas transacciones se hayan realizado. Finalmente al incluir una transaccin especifico el Nro. de la transaccin, fecha de la transaccin, monto y un solo dato que identifica el cliente que es la (C.I) con este dato voy al Archivo de Identificacin del Cliente y puedo saber cual es su nombre y su lmite de Crdito. Estando en el Archivo Identificacin del Cliente y teniendo el dato de Lmite de Crdito voy al Archivo Calificacin del Crdito y puedo saber cual es la calificacin que tiene ese cliente. Como se observa en el proceso de descomposicin no se ha perdido ningn dato. Grficamente:

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 17

Archivo Transacciones Nro. Trans.(Clave Primaria) C.I. Fecha Monto

Archivo Identificacin Clientes C.I. (Clave Primaria) Nombre Lmite de Crdito

Archivo Calificacin del Crdito Lmite de Crdito (Clave Primaria) Calificacin

En este momento tenemos tres archivos.

!
Es importante aclarar que en algunos casos existen campos que son totales, es decir se obtienen como resultado de operaciones aritmticas aplicadas a otros campos. La evaluacin de s estos campos totales deben ser almacenados en algn archivo u obtenerse aplicando la operacin matemtica depender de las necesidades y requerimientos del problema planteado; es decir se evaluarn dos factores: espacio de almacenamiento Vs. tiempo de procesamiento. Esto debe evaluarse despus de la 3FN.

Se concluye entonces que el nivel de normalizacin de una relacin dada es un asunto de semntica, no de valores de datos que casualmente aparezcan en esa relacin en algn instante especfico. No slo es posible mirar la tabulacin (extensin) de una relacin dada en un instante dado y decir si la relacin est o no en 3FN, es necesario conocer el significado de los datos, esto es, las dependencias implcitas antes de que se

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 18

pueda formular un juicio. En particular, no se puede asegurar que una relacin est en 3FN o cualquier otra forma dada, excepto 1FN sin tener la informacin de todas las dependencias pertinentes; sin embargo para una relacin en 3FN todo lo que se necesita es informarle al manejador de bases de datos sobre esas dependencias es una indicacin de el (los) atributo(s) que constituye(n) la clave primaria. El manejador entonces sabr que todos los otros atributos son funcionalmente dependientes de ese atributo o combinacin de atributos y ser capaz de hacer cumplir esa restriccin. Para una relacin que no este en 3FN se necesitaran especificaciones adicionales. Incorporemos un pequeo cambio al ejercicio anterior. El archivo inicial de Transacciones esta formado por los siguientes campos: Nro. de Transaccin C. I. Cliente Nombre Cliente Direccin Cliente Tlf. Cliente Fecha Nacimiento Cliente. Nro. Cuenta Tipo de Cuenta (c corriente, a ahorro, l activos lquidos) Fecha de Apertura de la Cuenta Saldo de la Cuenta Fecha Transaccin Tipo de Transaccin (d deposito, r retiro) Monto Transaccin Lmite de Crdito Calificacin En este caso en particular un cliente puede tener varias cuentas en el Banco. Por cada cuenta tendr un lmite de Crdito (ahora el lmite de crdito no depende slo del cliente sino de una cuenta en particular del cliente). Por ejemplo si un cliente tiene tres cuentas tendr tres lmites de crdito. Pero la calificacin ahora no depende del lmite de crdito sino que el banco le otorga una calificacin a cada cliente, independientemente de la cantidad de cuentas que tenga el cliente. Aplique las tres formas normales. Al finalizar el proceso de normalizacin los archivos resultantes para el problema anterior sern los siguientes:

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012

Tema II. Normalizacin

Pg. 19

Archivo Identificacin Clientes C.I. (Clave Primaria) Nombre Cliente Direccin Cliente Tlf. Cliente Fecha Nacimiento Calificacin

Archivo Identificacin Cuentas Nro. de Cuenta (Clave Primaria) C.I. Tipo de Cuenta Fecha de Apertura Saldo cuenta Lmite de Crdito de la Cuenta

Archivo Transacciones Nro. Trans.(Clave Primaria) Nro. de Cuenta Fecha Trans Tipo Trans. Monto

Cmo se observa con un simple cambio en las especificaciones del problema los archivos resultantes de la normalizacin no son los mismos. Si hacemos otro cambio en las especificaciones anteriores. Ahora el cliente tendr una calificacin por cada una de las cuentas que tenga en el Banco. Es decir si el cliente tiene tres cuentas tendr tres calificaciones. En este cambio se ven afectados dos archivos. El archivo de Identificacin de Clientes y el archivo de Identificacin de Cuentas. El campo Calificacin debe eliminarse del Archivo Identificacin de Clientes y debe agregarse al Archivo de Identificacin de Cuentas esto se debe a que ahora la Calificacin depende directamente de la Cuenta del Cliente.

Prof. Margarita Pereira, Leonardo Ponte

Agosto 2012