Professional Documents
Culture Documents
INTRODUCCIN
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.
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
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
No duplicados
Un tabla debe satisfacer ciertos criterios No debe haber nunca dos columnas o filas
previos antes de calificar para convertirse en totalmente idnticas. Si dos filas son
una relacin.
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
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 tambien se les ha hecho el anlisis ARD, y se establecern
relaciones entre ellos.
Grupo NO Repetitivo
Grupo Repetitivo
ORD-NO
CODIGO
ORD-DATE
TITULO
PROV-NO
CANT
PROV-NAME
VR-UNIT
PROV-DIR
PROV-NIT
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
GRUPO 2
ORD-NO
ORD-NO
CODIGO
ORD-DATE
TITULO
PROV-NO
CANT
PROV-NAME
VR-UNIT
PROV-DIR
PROV-NIT
GRUPO 1
GRUPO 2
GRUPO 3
ORD-NO
ORD-NO
CODIGO
ORD-DATE
CODIGO
TITULO
CANT
VR-UNIT
PROV-NO
PROV-NAME
PROV-DIR PROV-NIT
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
1NF PRIMERA FORMA NORMAL
2NF SEGUNDA FORMA NORMAL
3NF TERCERA FORMA NORMAL
Diccionario de datos
Separar el grupo repetitivo
Separar dependencias de llaves compuestas
Separar dependencias de los campos no llaves
Mantener los datos bien diferenciados (p.ej., el primero y el ltimo de los nombres van
separados). Acercar unas columnas a otras posteriormente sobre la marcha es, en
general, bastante fcil, pero separarlas no
Primero, definir la clave primaria. Utilizar un nombre descriptivo (EMPLEADO_ID, no
slo ID).
El uso de nombres descriptivos permite que los nuevos usuarios tengan alguna
oportunidad de adivinar lo que es cada una de las columnas (p.ej., utilizar
CUENTA_BANCO en lugar de CTBC
Siempre que sea posible, utilizar una sola columna para la clave primaria; las claves
primarias de ms de una columna son adecuadas para las interrelaciones de muchos a
muchos.
Utilizar tablas de referencia en lugar de almacenar valores de gran longitud
Emplear claves de tipo numrico siempre que sea posible
Evitar las claves autonumricas (salvo en las tablas de referencia).
No incluir dos columnas cuyos valores estn entrelazados (p.ej., el nombre del
Departamento y el ID de Departamento), salvo que una de las columnas sea la clave
primaria de la tabla
Evitar utilizar varias tablas con estructuras similares para representar pequeas
variaciones de la misma entidad (p.ej., poner las Universidades de Atlntico y las de
Cundinamarca en distintas tablas).
Planear con antelacin la transferencia de datos a una base de datos distinta. Por
ejemplo, puede que nos interese mover algunos datos de Oracle a DBF, o de Microsoft
Access a Oracle. Esto es:
Evitar poner en los nombres de las columnas caracteres que no sean maysculas (A-Z),
nmeros (0-9) o el subrayado (_). Cualquier otro caracter puede no ser aceptado por la
base de datos. Algunos sistemas de bases de datos son sensibles al uso de maysculas
y minsculas en los nombres de las columnas, otros no.
Procurar que los nombres de las columnas sean relativamente cortos. Cada tipo de
base de datos soporta un nmero distinto de caracteres (p.ej., 30 en el caso de Oracle,
64 para Microsoft Access o 10 si es DBF). Intentar que los nombres de las columnas
varen en los primeros caracteres y no en los ltimos, con el fin de evitar que se
duplique alguno de los nombres por error al cortarlos para abreviar durante el proceso
de conversin (p.ej., utilizar COL1 y COL2, en lugar de NOMBRE_COLUMNA_LARGA_1 Y
NOMBRE_COLUMNA_LARGA_2).
Observar que el poner nombres cortos a las columnas puede ser incompatible con procurar que
sean descriptivos para los nuevos usuarios. Comprobar que se est realizando una buena
combinacin.
Es importante recordar que stas son reglas no escritas, basadas nicamente en la experiencia,
no leyes absolutas! Se pueden romper las reglas si es necesario, pero justificando la decisin