Beruflich Dokumente
Kultur Dokumente
INTRODUCCIÓN
Una base de datos tiene que ser diseñada antes de que pueda ser creada y
usada. El diseño debe ajustarse a estándares que permitan ahorro de memoria,
acceso rápido, fácil mantenimiento, portabilidad, facilidad de futuros
mejoramientos, buen desempeño y eficiencia de costos, entre otros. El diseño
lógico final de una base de datos debe ser tal que equilibre un desempeño óptimo
junto con la integridad de la información. Esto puede ser logrado a través de un
proceso conocido como Normalización. La base de datos debe estar en un estado
de "Forma completamente normalizada".
DEFINICIÓN DE NORMALIZACION
FIGURA 3
A primera vista, parece conveniente almacenar todos los detalles en una sola
tabla. Pero ciertas anomalías se pueden manifestar durante la inserción,
actualización y borrado de datos. La normalización provee un método de remover
todas estas indeseables anomalías haciendo la base de datos mas confiable y
estable.
PROCEDIMIENTOS DE NORMALIZACION
El proceso de normalización involucra básicamente tres pasos. Después 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 también existen, pero no son usadas en el diseño de una base de
datos.
A continuación, consideremos un pequeño ejercicio acerca de un Documento de
Orden de Compra, el cual trataremos de convertirlo a una forma normalizada. Pero
antes explicaremos unas pequeñas reglas:
EJERCICIO DE EJEMPLO
Consideremos el documento ORDEN DE COMPRA de la figura 4, usado para
colocar una orden de pedido al proveedor de discos compactos.
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 análisis.
En la lista de arriba, los ítems después 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 categorías, o varios títulos de la misma
categoría.
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 (del cual se sustrajo) enlazando la llave del grupo no
repetitivo junto con la llave del repetitivo (foránea). De esta manera tenemos:
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 números 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
combinación puede actuar como llave única, ya que no puede haber una misma
orden que tenga 2 códigos iguales. Por lo tanto, después 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
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.
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.
Igual sucede con el campo VR-UNIT. Este campo esta asociado exclusivamente al
campo CODIGO. Esto es, cada Titulo de CD con un código determinado, debe
corresponder a un valor de venta que se establece una sola vez por cada
elemento. De esta manera, si en algún momento necesitamos alterar el valor
unitario de un CD, solo debemos hacerlo en la tabla del grupo 3, una única vez por
elemento.
CODIGO TITULO
ORD-DATE
CANT VR-UNIT
PROV-NO
PROV-NAME
PROV-DIR PROV-NIT
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
también en el grupo original.
PROV-NIT
RESUMEN DE LA NORMALIZACION
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 fácil, pero separarlas no
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 más de una columna son adecuadas para las interrelaciones
de muchos a muchos.
No incluir dos columnas cuyos valores estén 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 pequeñas
variaciones de la misma entidad (p.ej., poner las Universidades de Atlántico y las
de Cundinamarca en distintas tablas).
Planear con antelación 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:
• Procurar que los nombres de las columnas sean relativamente cortos. Cada tipo
de base de datos soporta un número 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 varíen 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 conversión (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 combinación.
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 decisión.