TALLER DE MODELAMIENTO

Seccin
Asignatura
Docente

: ..
: Sistemas de base de datos
: Daniel Gamarra Moreno

Apellidos
Nombres
Fecha

: ..
: ..
: // Duracin: .

NORMALIZACIN
INTRODUCCIN
La normalizacin es usada para definir la estructura de cada tabla de una base de datos.
La normalizacin permite mediante la redundancia controlada eliminar los problemas: de
redundancia no controlada, insercin y eliminacin, y su uso facilita la actualizacin.
La meta de normalizar una base de datos es que las tablas estn en por lo menos la tercera forma
normal (3FN), pero hay casos en que es necesario llegar a la quinta forma normal (5FN).

EJEMPLO:
Si tuviramos la siguiente tabla que guarda informacin de los proyectos que desarrolla la empresa
de software HACKER:
PROY
A101

COD
NOM
NOM
CAT PAGO
EMP
PROY
EMPLEADO
841
CTAS.CTES. E. OLIVARES AJ 1200

A102

841

AHORROS

A103

837

AS

2400

A102

837

CONT. DE
S. MORA
PERSONAL
AHORROS S. MORA

AS

2400

A104

855

LINEAS DE
CREDITO

AJ

1200

E. OLIVARES AJ

B. GARCIA

1200

En esta tabla pueden presentarse las siguientes anomalas:

1. Si se elimina el proyecto A104, los datos del empleado 855 tambin es eliminado, perdindose
la informacin de este trabajador, puesto que este no trabaja en otro proyecto. En este caso se
ha presentado el problema o anomala de Eliminacin.
2. Si el pago del trabajador depende de su categora, y este tuviera un incremento, se deber
actualizar todos los registros que contenga a dicha categora. En este caso se ha presentado el
problema o anomala de Actualizacin.
3. Si se desea aadir una nueva categora, se debe esperar hasta que un trabajador sea asignado
a dicha categora, porque no se debera dejar campos en blanco o nulos. En este caso se ha
presentado el problema o anomala de Insercin.
Las anomalas sealadas lneas arriba es producto de una tabla no normalizada.

CONCEPTOS PARA NORMALIZAR

DEPENDENCIA FUNCIONAL
Dados 2 atributos, A y B, se dice que B es funcionalmente dependiente de A, si para cada valor de
A existe un valor de B, y slo uno, asociado a l (en cualquier instante). A y B pueden ser conjunto
1

de atributos, en lugar de atributos simples. Su representacin es: A B, B depende funcionalmente

de A.

Ejemplo:
En las siguientes tablas, determine la dependencia funcional:
TABLA1

(CODIGO, AP_PATER, AP_MATER, NOMBRE, FECH_NAC)

TABLA2

(COD_CUR, NOM_CUR, NUM_HOR)

DEPENDENCIA TRANSITIVA
Existe dependencia transitiva cuando: A B y B C, por lo tanto A C. Siempre que no se
cumpla B A y C B

Ejemplo:
En la siguiente tabla, determine la dependencia transitiva:
TABLA

(CODIGO, NOMBRE, COD_CUR, NOM_CUR)

DEPENDENCIA FUNCIONAL COMPLETA (DFC)

Un atributo o conjunto de atributos B es DFC de otro conjunto de atributos A, si A B, pero de
ningn subconjunto de A.

PRIMERA FORMA NORMAL (1FN)

Para que una relacin este en 1FN no debe contener campos repetitivos. Para convertir la relacin
a 1FN se deber dividir en 2 tablas. La primera relacin esta compuesta slo por los campos no
repetitivos. La segunda relacin deber tener como clave primaria la clave primaria del grupo no
repetitivo ms la clave primaria del grupo repetitivo y los dems atributos repetidos. El objetivo es
eliminar los campos repetitivos o elementos tales como arreglos.

Ejemplo:
Para almacenar el promedio final del los alumnos del IV semestre se tiene la siguiente tabla:
ARCHIVO1

(CODIGO, NOMBRE, {COD_CUR, PROM})

Convertirlo a 1FN.

SEGUNDA FORMA NORMAL (2FN)

Una tabla se encontrara en 2FN si y slo si esta en 1FN y adems cumple que los atributos que
NO FORMAN LA CLAVE PRIMARIA, dependen de la CLAVE PRIMARIA (cada atributo NO CLAVE
es DFC de la CLAVE). Para convertir una relacin a la 2FN, se deber descomponer la tabla en 2
nuevas tablas, separando para la primera tabla los atributos que no dependen de la clave primaria.
Para la segunda tabla, los atributos separados contienen como clave primaria la clave primaria
parcial del cual dependen funcionalmente.
El objetivo es eliminar la dependencia funcional parcial, en aquellas tablas que tienen como clave
primaria a ms de un atributo.

Ejemplo:
Para almacenar las notas de los cursos de los estudiantes del IV ao de Ingeniera de sistemas se
tiene la siguiente tabla que esta 1FN:
2

ARCHIVO1

(COD_EST, COD_CUR, NOM_CUR, PROM)

Convertirlo a 2FN.
Para determinar la dependencia funcional completa recomendamos que se represente los datos de
3 a 5 registros y luego por cada campo que no se clave se realice preguntas que nos permitan
determinar la dependencia. Por ejemplo; para el campo NOM_CUR nos preguntamos:
El campo nombre de curso queda determinando con TODA la clave primaria o SOLO con parte
de los atributos de la clave?
Si la respuesta es s el campo depende parcialmente de la clave por lo que no esta en 2FN.
COD_EST
111111
111111
222222
222222

COD_CUR
001
002
001
002

NOM_CUR
Matemtica
Lenguaje
Matemtica
Lenguaje

PROM
12
11
14
18

TERCERA FORMA NORMAL (3FN)

Una tabla se encontrar en 3FN si slo si se encuentra en 2FN y adems no tiene dependencias
transitivas. Para convertir una relacin a 3FN se deber eliminar dicha transitividad
descomponiendo la tabla en 2 tablas. El objetivo es eliminar la dependencia transitiva.
De:

ABC

A:

AB
BC

Ejemplo:
Para almacenar en que cursos estn matriculados los estudiantes del IV ao de Ingeniera de
sistemas se tiene la siguiente tabla en 2FN:
ARCHIVO1

(CODEST, NOMEST, COD_CURSO, NOM_CUR)

Convertirlo a 3FN.

EJERCICIOS
Normalice las siguientes bases de datos:

TABLA PARA ALMACENAR FACTURAS

BASE1

(NUM_FACTURA, FECHA, RUC_CLIE, NOM_CLIE, {COD_PRO, DESC, CANT, PU, SUBTOTAL},

TOTAL)

SOLUCIN
FACTURA

(NUM_FACTURA, FECHA, NUM_CLIE)

CLIENTE

(RUC_CLIE,NOM_CLIE)

ITEM

(NUM_PEDIDO, COD_PRO, CANT)

PRODUCTO

(COD_PRO, DESC, PU)

TABLA PARA ALMACENAR LAS ACTAS DE EVALUACIN DE UN INSTITUTO

SUPERIOR:
BASE

(SEMESTRE, SECCIN, EVALUACIN,

{CDIGO_MATRICULA, NOMBRE_ALUMNO, CONDICIN,

{ASIGNATURA, PROMEDIO,
NOMBRE_PROFESOR}}

DEPENDENCIAS MULTIVALUADAS
Existe una dependencia multivaluada en una tabla cuando un valor de una columna o conjunto de
columnas, determina un conjunto de otros valores de otra columna (uno a muchos).

Ejemplo
Una persona trabaja en varios proyectos y tiene un numero de conocimientos.
Id_PersonaConocimientos
Id_PersonaId_Proyecto
Id_persona
001
001
001
001
002
002
003
003

Conocimiento
Informtica
Francs
Informtica
Francs
Francs
Economa
Informtica
Informtica

Id_proj
Proj1
Proj1
Proj3
Proj3
Proj1
Proj1
Proj1
Proj2

CUARTA FORMA NORMAL (4FN)

Las relaciones en 4FN no deben contener ms de una dependencia multivaluada independiente o
una dependencia multivaluada independiente junto con una dependencia funcional.
Para formar la 4FN se divide las dependencias multivaluadas en otras tablas.

Tabla conocimientos:
Id_persona
001
001
002
002
003
003

Conocimiento
Informtica
Francs
Francs
Economa
Informtica
Informtica

Tabla asignaciones:
Id_persona
001
001
002
003
003

Id_proj
Proj1
Proj3
Proj1
Proj1
Proj2

QUINTA FORMA NORMAL (5FN)

La 5FN se puede considerar como una extensin de la 4FN en el sentido que las dependencias
multivauladas no son independientes.

Ejemplo
S para un proyecto se necesitan un conjunto de conocimientos.
Id_persona
001
001

Conocimiento
Informtica
Informtica

Id_proj
Proj1
Proj3

Id_persona
001
002
002
003
003

Conocimiento
Francs
Francs
Economa
Informtica
Informtica

Id_proj
Proj3
-----Proj1
Proj1
Proj2

En este caso se divide en tres tablas, la primera contiene la dependencia multivaluada dependiente.
Las otras dos tablas son iguales al de la 4FN.

Tabla conocimientos-necesarios
Id_proj
Proj1
Proj1
Proj2
Proj3
Proj3

Conocimiento
Informtica
Economa
Informtica
Informtica
Francs

Id_persona
001
001
002
002
003
003

Conocimiento
Informtica
Francs
Francs
Economa
Informtica
Informtica

Tabla conocimientos:

Tabla asignaciones:
Id_persona
001
001
002
003
003

Id_proj
Proj1
Proj3
Proj1
Proj1
Proj2

DISEO DE BASE DE DATOS CON DESNORMALIZACIN

Las reglas de normalizacin no consideran el rendimiento. En algunos casos, es necesario
considerar la desnormalizacin para mejorar el rendimiento.
Durante el diseo fsico, los analistas transforman las entidades en tablas y los atributos en
columnas. Considere de nuevo el ejemplo del apartado Segunda forma normal.

La columna de direccin de almacn aparece primero como parte de una tabla que contiene
informacin sobre componentes y almacenes. Para normalizar adicionalmente el diseo de la tabla,
los analistas eliminan la columna de direccin de almacn de la tabla. Los analistas tambin definen
la columna como parte de una tabla que contiene informacin nicamente sobre almacenes.

La normalizacin de tablas es la propuesta que se suele recomendar. Pero qu sucede si las

aplicaciones necesitan informacin sobre componentes y almacenes, incluida las direcciones de
los almacenes? La premisa de las reglas de normalizacin es que las sentencias de SQL pueden
recuperar la informacin uniendo las dos tablas. El problema es que, en algunos casos, se pueden
5

producir problemas de rendimiento como resultado de una normalizacin. Por ejemplo, algunas
consultas de usuario pueden ver datos que estn en una o ms tablas relacionadas; el resultado
es demasiadas uniones. A medida que crece el nmero de tablas, los costes de acceso pueden
aumentar, segn el tamao de las tablas, los ndices disponibles, etc. Por ejemplo, si no hay ndices
disponibles, la unin de numerosas tablas grandes puede tardar demasiado tiempo. Puede que
necesite desnormalizar las tablas. La desnormalizacin es la duplicacin intencionada de columnas
en varias tablas y esto aumenta la redundancia de datos.

Ejemplo 1:
Considere el diseo en que ambas tablas tienen una columna que contiene las direcciones de
almacenes. Si este diseo hace que no sean necesarias operaciones de unin, podra ser que la
redundancia valga la pena. Las direcciones de almacenes no cambian a menudo y si cambia alguna
puede utilizar SQL para actualizar todas las instancias con bastante facilidad.
Consejo: No suponga automticamente que todas las uniones tardan demasiado tiempo. Si une
tablas normalizadas, no es necesario mantener los mismos valores de datos sincronizados en
varias tablas. En muchos casos, las uniones son el mtodo de acceso ms eficaz, a pesar de la
sobrecarga que suponen. Por ejemplo, algunas aplicaciones alcanzan 44 uniones en un tiempo de
respuesta de sub-segundos.
Cuando crea el diseo fsico, el usuario y sus colegas necesitan decidir si deben desnormalizarse
los datos. Especficamente, necesita decidir si deben combinarse tablas o partes de tablas a las
que accedan con frecuencia uniones que tienen requisitos de alto rendimiento. Se trata de una
decisin compleja sobre la cual esta informacin no puede proporcionar un consejo especfico. Para
tomar esta decisin necesita evaluar los requisitos de rendimiento, los diferentes mtodos de
acceder a los datos y los costes de desnormalizacin de los datos. Debe tener en cuenta el coste
y el resultado; es la duplicacin, en varias tablas, de columnas solicitadas con frecuencia menos
costosa que el tiempo de llevar a cabo las uniones?
Recomendaciones:
No desnormalice tablas a menos que tenga una buena comprensin de los datos y las
transacciones empresariales que acceden a los datos. Consulte con los desarrolladores de
aplicaciones antes de desnormalizar tablas para mejorar el rendimiento de las consultas de
los usuarios.

Cuando decida si va a desnormalizar una tabla, considere todos los programas que accedan
de forma regular a la tabla, tanto para lectura como para actualizacin. Si los programas
actualizan con frecuencia una tabla, la desnormalizacin de la tabla afecta al rendimiento de
los programas de actualizacin puesto que las actualizaciones se aplican ms a varias tablas
que a una sola tabla.

En la figura siguiente, la informacin sobre componentes, almacenes y direcciones de almacenes

aparecen en dos tablas, ambas en la forma normal.

Figura 1. Dos tablas que cumplen la segunda forma normal

La siguiente figura ilustra la tabla desnormalizada.

Figura 2. Tabla desnormalizada
La resolucin de relaciones de muchos a muchos es una actividad especialmente importante puesto
que ayuda a mantener la claridad e integridad en el diseo fsico de bases de datos. Para resolver
relaciones de varios con varios, se introducen tablas asociativas, que son tablas intermedias que
se utilizan para enlazar, o asociar, dos tablas entre s.

Ejemplo 2:
Los empleados trabajan en muchos proyectos. Los proyectos tienen muchos empleados. En el
diseo lgico de bases de datos, esta relacin se muestra como una relacin de muchos a muchos
entre proyecto y empleado. Para resolver esta relacin, se crea una nueva tabla asociativa,
EMPLOYEE_PROJECT. Para cada combinacin de empleado y proyecto, la tabla
EMPLOYEE_PROJECT contiene una fila correspondiente. La clave primaria para la tabla estara
formada por el nmero de empleado (EMPNO) y el nmero de proyecto (PROJNO).
Otra decisin que debe tomar est relacionada con la utilizacin de grupos repetitivos.

Ejemplo 3:
Suponga que una transaccin que se utiliza mucho necesita el nmero de cables que se venden al
mes en un ao especfico. Los factores de rendimiento podran justificar cambiar una tabla de modo
que viole la regla de la primera forma normal almacenando grupos repetitivos. En este caso, el
grupo repetitivo sera: MONTH, WIRE. La tabla contendra una fila para el nmero de cables
vendidos para cada mes (cables de enero, cables de febrero, cables de marzo, etc.).
Recomendacin: Si decide desnormalizar los datos, documntese en profundidad sobre la
desnormalizacin. Describa, de forma detallada, la lgica de la desnormalizacin y los pasos que
ha seguido. A continuacin, si en el futuro la organizacin necesita normalizar los datos, los
encargados de realizar este trabajo dispondrn de un registro preciso