Normalización

AGENDA

• Proceso de Normalización
• Dependencias Funcional, Funcional
Completa y Transitiva
• Primera, Segunda y Tercera Formas
Normales
 El Proceso de Normalización

• La teoría de la normalización permite reconocer

propiedades indeseables en las relaciones y
convertirlas para solucionar los problemas que
presentan
• Se dice que una relación está en una determinada
forma normal si satisface un cierto conjunto de
restricciones
• El proceso de normalización es reversible, es decir,
se puede volver de una forma normal superior a
otra inferior sin perder información
 Objetivos de la Normalización

• Eliminar ciertos tipos de redundancia

• Evitar ciertas anomalías en la actualización de datos
• Producir un diseño que sea una “buena”
representación del mundo real: que sea fácil de
entender intuitivamente y constituya una buena
base para un crecimiento futuro
• Facilitar la recuperación de la información
 Formas Normales

Universo de las relaciones (normalizadas y no normalizadas)

Relaciones en primera forma normal (1FN)

Relaciones en segunda forma normal (2FN)

Relaciones en tercera forma normal (3FN)

Relaciones en forma normal Boyce & Codd (FNBC)

Relaciones en cuarta forma normal (4FN)

Forma normal de reunión por proyección (5FN)
 Normalización - Definiciones
Todas las formas normales se definen en base al concepto de
DEPENDENCIA FUNCIONAL

DEPENDENCIA FUNCIONAL:
•Relación semántica entre dos o más atributos: el valor de un
atributo X determina el valor de otro atributo Y.
Es decir, si se conoce el valor del atributo X podemos conocer
con seguridad el valor que toma el atributo Y.

•Para poder identificar las dependencias funcionales (DF) entre los

atributos es necesario tener muy claro su significado y las reglas
del negocio al que describen.
 Normalización - Definiciones
RELACIÓN:

•Para los fines de este capítulo, consideraremos al término

“RELACIÓN” como sinónimo de “TABLA”.
•De la misma manera, el término “tupla” será considerado como
equivalente a una “fila” de una tabla.

Posteriormente en el curso conoceremos más del modelo

relacional y precisaremos, entonces, las diferencias entre estos
términos.
 Dependencia Funcional (definición
formal)

• Dada una Relación R, el atributo “y” de R, depende

funcionalmente (DF) del atributo “x” de R, si el valor de “y”
está determinado por el valor de “x”.

R.x  R.y

Se lee: R.x determina funcionalmente a R.y

o
R.y depende funcionalmente de R.x
 Dependencia Funcional
Ejemplo:
Relación Alumno: (CoAlumno, NoAlumno, CoPostal,
NoEspecialidad)

Reglas de negocio:
• Cada alumno tiene un código único que lo identifica
• Se guarda registro del nombre del alumno, el código postal de su domicilio y
la especialidad en la que está matriculado
• Cada alumno solamente puede estar inscrito en una especialidad
 Dependencia Funcional
Ejemplo: Relación Alumno
CoAlumno NoAlumno CoPostal NoEspecialidad

201800101 Salazar L14 Industrial

201810126 Jiménez L27 Electrónica
201812536 Bernales L01 Sistemas
201820016 Cordova L20 Sistemas
201820010 Alvarez L27 Civil

CoAlumno  NoAlumno
CoAlumno  CoPostal
CoAlumno  NoEspecialidad

CoAlumno  (NoAlumno, CoPostal, NoEspecialidad)

 Dependencia Funcional
Ejemplo:
Relación Matrícula: (CoAlumno, CoProfesor, NoAlumno, CoCurso,
QtNota)

Reglas de negocio:
• El alumno, el profesor y el curso tienen códigos únicos que los identifican
• Un alumno lleva un curso con un solo profesor
• Se registra la nota final obtenida por el alumno en el curso
• Un profesor podría enseñar varios cursos
 Dependencia Funcional
Ejemplo: Relación Matrícula

CoAlumno CoProfesor Noalumno CoCurso QtNota

3456 0301 José Pérez SI03 15.00
1256 2005 María Antúnez SI20 16.50
0101 0312 Lourdes Sánchez SI03 17.00
3456 2002 José Pérez SI20 13.50
1234 0304 Pilar García SI03 18.00

CoAlumno  NoAlumno
CoAlumno, CoCurso  (CoProfesor, QtNota)
 Dependencia Funcional
• Dada una relación R, el atributo “y” depende funcionalmente
del atributo “x” si y sólo si, siempre que dos tuplas
concuerden en el valor de “x”, deben por fuerza concordar
también en el valor de “y”.
• Si una restricción de R (una regla de negocio) establece que
no puede haber más de una tupla con un valor “x” (x es clave
candidata de R), eso implica que para cualquier subconjunto
de atributos R.y de R se cumple que: R.x  R.y
• Sin embargo, la definición de Dependencia Funcional (DF) no
requiere que el determinante x sea una clave candidata de R:
no es obligatorio que un valor dado de x aparezca en una sola
tupla de R.
 Dependencia Funcional
Ejemplo:
Relación Evaluación:
(CoAlumno, NoAlumno, CoCurso, QtNota)
Reglas de Negocio:
•Cada alumno tiene un código que lo identifica de manera única

•Cada curso tiene un código que lo identifica de manera única

•Un alumno en un curso obtiene una nota (QtNota) que es su promedio final
 Dependencia Funcional
Relación Evaluación
CoAlumno NoAlumno CoCurso QtNota

201810025 Jiménez S03 15.00

201810025 Jiménez S20 16.50
201810025 Jiménez S25 13.25
201820026 La Madrid SI03 17.00
201820026 La Madrid HU2 14.00

• En este ejemplo vemos que CoAlumno  NoAlumno

Sin embargo CoAlumno no es clave candidata de la relación
Evaluación (los valores de CoAlumno se repiten en las tuplas)
 Dependencia Funcional Completa

Definición previa: CLAVE PRIMARIA (PK):

•Es un atributo o conjunto de atributos que representan de
forma única a cada tupla de una relación (o fila de una tabla). Es
decir, nunca se repiten en dos o más tuplas de la misma
relación (en dos o más filas de la tabla).
•Cuando en una relación hay más de un atributo o conjunto de
atributos que pueden cumplir esta función, se les denomina
“claves candidatas”, y se debe designar una de ellas como la
clave primaria.
•La clave primaria (PK) puede ser un solo atributo o puede estar
compuesta de varios atributos.
•(Usualmente los atributos que conforman la PK se presentan subrayados)
 Dependencia Funcional Completa

• Dada una Relación R, el atributo “z” de R, está en

dependencia funcional completa (DFC) de la clave
primaria PK de R, si el valor de “z” depende
funcionalmente de toda la clave PK y no de un
subconjunto de la misma

R.(x,y) R.z

Donde PK=(x,y)
 Dependencia Funcional Completa

Ejemplo:
Relación Pedido: (CoPedido, CoProducto, QtPedida)

Reglas de negocio:
•El producto y el pedido tienen códigos únicos de identificación
•En un pedido pueden figurar varios productos
•Se registra la cantidad de unidades de cada producto solicitadas
en cada pedido
 Dependencia Funcional Completa

Ejemplo:
PEDIDO
CoPedido Coproducto QtPedida
10025 p20 16
10025 p85 15
25036 p49 14

CoPedido
QtPedida
CoProducto

(CoPedido, Coproducto)  QtPedida

 Dependencia Funcional Completa

Ejemplo:
Relación Consultoría: (CoConsultor, CoProyecto,
NoConsultor, NoProyecto, QtHorasTrabajadas)

Reglas de negocio:
•El consultor y el proyecto tienen códigos de identificación únicos
•Se lleva registro de la cantidad total de horas que cada consultor ha
trabajado en cada proyecto
 Dependencia Funcional Completa

Ejemplo: Relación Consultoría

Co Co No No QtHoras
Consultor Proyecto Consultor Proyecto trabajadas
C1 P1 Juan Auditoria 25
C1 P2 Juan DW 80
C2 P1 Pedro Auditoria 35
C3 P3 María CRM 20
C3 P4 María ERP 50

CoConsultor
QtHoras_Trabajadas
CoProyecto

(CoConsultor, CoProyecto)  QtHoras_Trabajadas

 Dependencia Transitiva
• Dada una Relación R, el atributo “z” de R, está en
dependencia transitiva (DT) de la clave primaria PK de
R, si el valor de “z” depende funcionalmente de otro
atributo no clave “y”.

R.x R.y, R.z

Donde PK=x
Se lee “R.z es funcionalmente dependiente de
R.y y transitivamente dependiente de R.x”
 Dependencia Transitiva

Ejemplo:
Relación Comprobante: (NuComprobante, CoCliente,
NoCliente, FeVenta)
Reglas de negocio:
•Cada transacción de venta se identifica con un número de
comprobante
•Cada comprobante es emitido en una fecha y a un solo cliente

•Cada cliente tiene un código único de identificación

 Dependencia Transitiva

Ejemplo:
COMPROBANTE

NuComprobante CoCliente NoCliente FeVenta

0040 C01 Juan 20/05/18

0050 C01 Juan 18/04/18
0010 C02 María 15/04/18
0020 C02 María 15/04/18

NuComprobante  CoCliente, FeVenta, NoCliente

 Dependencia Transitiva

Ejemplo:
Relación Empleado: (CoEmpleado, NoEmpleado,
SsSalario, CoProyecto, FeProyectoTermino)

Reglas de negocio:
•Los empleados y los proyectos tienen códigos únicos de
identificación
•De cada empleado se conoce, además de su nombre, su salario y
el proyecto en el que está trabajando (uno solo)
•Se lleva registro de la fecha en la que cada proyecto debe
terminar, de acuerdo al plan
 Dependencia Transitiva

Ejemplo: Relación Empleado

Co FeProyecto-
CoEmpleado NoEmpleado SsSalario
Proyecto Termino
E1 Juan 3,500 P1 31/10/18
E2 Pedro 3,000 P1 31/10/18
E3 María 3,800 P2 15/11/18
E4 Andrés 3,000 P2 15/11/18
E5 Ana 2,800 P1 31/10/18

CoEmpleado  CoProyecto, FeProyectoTermino

 Normalización

Datos sin normalizar

1FN: Las relaciones no deben
contener grupos repetitivos

1ra. Forma Normal

2FN: Cada atributo no clave
debe depender de toda la clave

2da. Forma Normal

3FN: Cada atributo no clave
debe depender de toda la
3ra. Forma Normal clave de esa relación y no de
otros atributos.
 Anomalías

Se presentan cuando tratamos de almacenar

información en tablas no normalizadas:
• De actualización: inconsistencia de los datos como
consecuencia de actualizaciones parciales en datos
redundantes
• De inserción: imposibilidad de adicionar datos en la
base de datos (BD) por la ausencia de otros
• De borrado: pérdida no intencionada de datos
debido a la eliminación de otros
 Primera Forma Normal (1FN)
Una relación está en primera forma normal (1FN)
si todos los atributos de cada tupla contienen un
solo valor tomado de sus dominios respectivos
(valores atómicos)

• Todos los atributos de una relación tienen valores simples

• Todos losvalores de cualquier columna son del mismo tipo
• No hay grupos ni arreglos repetidos como valores
• Está definida una clave primaria (PK)

Note que siempre la clave primaria determina funcionalmente

a todos los demás atributos de la relación. Es decir, todos los
atributos no clave dependen funcionalmente (DF) de la
clave.
 Segunda Forma Normal (2FN)
Una relación está en segunda forma normal (2FN) si
está en 1FN y además cada atributo no clave de la
relación es total y funcionalmente dependiente
(DFC) de su clave primaria
• Es decir, la dependencia funcional de todos los atributos con
respecto a la PK es una dependencia funcional completa (DFC).
• Note que, si la PK de la relación no es compuesta,
necesariamente se cumple también la DFC y en consecuencia
se cumple también la condición de 2FN
 Tercera Forma Normal (3FN)

Una relación está en tercera forma normal (3FN) si

está en 2FN y además ningún atributo no-clave en la
relación esta en DF con algún otro atributo no-clave
• Es decir, está en 3FN si está en 2FN (existe DFC) y además no
tiene dependencias transitivas
• Eso equivale a que la dependencia funcional (DF) de cada uno
de los atributos con respecto a la PK, además de ser completa
(DFC) no es transitiva
 Proceso de Normalización

Veamos ahora la aplicación del proceso de normalización

con un caso práctico: la relación VtaDiaria.
Reglas de Negocio:
•La relación VtaDiaria representa el consolidado de ventas por
cliente, producto y fecha de operación
•De cada cliente se registra un código único, nombre, ciudad y el
flete que se le cobra por el envío de la mercadería
•De cada producto se registra un código de identificación y el
precio unitario
•El monto a cobrar por concepto de flete se establece de acuerdo
a la ciudad de envío
 Primera Forma Normal (1FN)
Relación: VtaDiaria
CoCliente NoCliente NoCiudad SsFlete SsPrecio CoProducto Qtpedida FeVenta
Unitario

C1 JUAN LIMA 0.75 8.20 I3 1 5-Jun

C1 JUAN LIMA 0.75 8.20 I3 2 12-Oct

C2 MARIA TUMBES 1.95 4.00 I2 1 15-May

C2 MARIA TUMBES 1.95 8.20 I3 1 15-May

C2 MARIA TUMBES 1.95 2.00 I5 3 15-May

C3 PEDRO LIMA 0.75 4.00 I2 1 10-Oct

C3 PEDRO LIMA 0.75 2.00 I3 2 10-Oct

C4 ANA ICA 1.05 10.50 I4 1 5-May

 Primera Forma Normal (1FN)

• La relación VtaDiaria está en 1FN porque:

– Todos los atributos de una relación tienen valores simples
– Todos losvalores de cualquier columna son del mismo tipo
– No hay grupos ni arreglos repetidos como valores
– Está definida una clave primaria (PK)
• Sin embargo, VtaDiaria todavía presenta múltiples
anomalías.
– Analiza detalladamente la relación identificando los problemas
concretos que presenta
 Primera Forma Normal (1FN)

Problemas (algunos de ellos)

– Si se desea registrar los datos de un cliente potencial,
no es posible hacerlo mientras no se le haga alguna
venta
– Si se desea registrar un nuevo producto, no es posible
mientras no tenga alguna venta
– Si se elimina la venta del producto I4 al cliente C4 del
día 5 de mayo se elimina también los datos de ese
cliente y de ese producto
– Si se desea modificar la ciudad del cliente C2 (un solo
dato) se requiere modificar varios registros, pues esa
información figura redundantemente registrada
 Normalización y Verificación de 1FN

• Las fallas en el almacenamiento de una relación en 1FN se

deben a la presencia de uno o más atributos no-clave que no
están en dependencia funcional completa (no son DFC) de la
clave primaria (PK).
• Los defectos se pueden eliminar con el siguiente
procedimiento
– Quitar de la relación 1FN todos los atributos no-clave que no estén
en DFC de la PK, es decir, que dependan funcionalmente de solo una
parte de la clave primaria.
– Guardar esos atributos no-clave en relaciones nuevas y adecuadas
(donde la PK sea el determinante).
CoCliente NoCliente NoCiudad SsFlete SsPrecio CoProducto Qtpedida FeVenta
Unitario

C1 JUAN LIMA 0.75 8.20 I3 1 5-Jun

C1 JUAN LIMA 0.75 8.20 I3 2 12-Oct

C2 MARIA TUMBES 1.95 4.00 I2 1 15- May

C2 MARIA TUMBES 1.95 8.20 I3 1 15-May

C2 MARIA TUMBES 1.95 2.00 I1 3 15-May

C3 PEDRO LIMA 0.75 4.00 I2 1 10-Ago

C3 PEDRO LIMA 0.75 2.00 I1 2 10-Oct

C4 ANA ICA 1.05 10.50 I4 1 5-May

 Normalización 2 FN
• NoCliente, NoCiudad y SsFlete dependen funcionalmente de
CoCliente
Cliente:
(CoCliente, NoCliente, NoCiudad, SsFlete)
• SsPrecioUnitario depende funcionalmente de CoPrecio

Producto:
(CoProducto, SsPrecio Unitario)

• QtPedida depende funcionalmente de CoCliente, CoProducto y

FeVenta (es el único atributo de la relación que está en DFC de la PK
Pedido 1:
(CoCliente, CoProducto, FeVenta, QtPedida)
 Segunda Forma Normal (2FN)
• Las relaciones Cliente, Producto y Pedido están en 2FN
porque:
– En cada una de ellas se cumple la 1FN, y
– En cada una de ellas cada atributo no clave de la relación es total y
funcionalmente dependiente (DFC) de su clave primaria

• Sin embargo, particularmente la relación Cliente todavía

presenta anomalías.
– Analiza detalladamente la relación identificando los problemas
concretos que presenta
 Segunda Forma Normal (1FN)

Problemas (algunos de ellos)

– Si se desea registrar el flete que se cobraría para los
despachos a un nuevo destino (por ejemplo Ucayali), no
es posible hacerlo mientras no se registre un cliente
para esa ciudad
– Si se elimina el cliente C4 se pierde la información del
costo del flete a la ciudad de Ica
– Si se desea modificar el flete a la ciudad de Lima (un
solo dato) se requiere modificar varios registros, pues
esa información figura redundantemente registrada
 Normalización y Verificación de la
2FN
• Los defectos de almacenamiento de una relación
2FN son causados por la dependencia transitiva
(DT) de atributos no-clave con la clave primaria
• Se puede normalizar como sigue:
– Examinar cada atributo no-clave para ver si está
en DF con otro atributo diferente de la PK
– Crear una nueva relación para almacenar la no-
clave transitivamente dependiente
 Normalización - 3FN

Cliente:
(CoCliente, NoCliente, NoCiudad, SsFlete)
 Esquema “Venta Diaria”
Producto:
(CoProducto, SsPrecio Unitario)

Cliente 1: Ciudad:
(CoCliente, NoCliente, NoCiudad) (NoCiudad, SsFlete)

Pedido 1:
(CoCliente, CoProducto, FeVenta, QtPedida)

El conjunto de relaciones mostrado se encuentra en 3FN porque:

•Está en 1FN:
• Todos los atributos de cada relación tienen valores simples
• Todos losvalores de cualquier columna son del mismo tipo
• No hay grupos ni arreglos repetidos como valores
• Está definida una clave primaria (PK) para cada relación

•Está en 2FN: en todas las relaciones se cumple la DFC

•Está en 3FN: no hay dependencias transitivas (DT)
 La Normalización
(en términos prácticos)

• Nos permite diseñar esquemas donde cada concepto, tema o “cosa”

sobre la que el negocio requiera registrar información tendrá un solo
lugar.
• La clave primaria (PK) de cada relación es el identificador del concepto
que ella representa y que en ella se guardará.
• De esa manera, cuando estamos diseñando un esquema relacional, el
procedimiento a seguir para decidir dónde colocar cada atributo (¿en
qué relación debe figurar?) debe ser:
– ¿Cuál es su determinante?, ¿de qué atributo o grupo de atributos
depende funcionalmente?
– Ubicarlo en aquella relación cuya clave primaria sea el determinante
identificado (si no existe tal relación, significa que hace falta crearla
porque se trata de un concepto que aún no tiene ubicación en el esquema
que se está diseñando)
 La Normalización
(en términos prácticos)
Producto:
(CoProducto, SsPrecio Unitario)

Cliente 1: Ciudad:
(CoCliente, NoCliente, NoCiudad) (NoCiudad, SsFlete)

Pedido 1:
(CoCliente, CoProducto, FeVenta, QtPedida)
De acuerdo al criterio propuesto en la diapositiva anterior, analice cómo
habría que cambiar el esquema propuesto si:
1. Necesitamos registrar el nombre del producto?
2. Queremos registrar la fecha de despacho a cada cliente, cuando:
2.1. (Escenario de negocio 1): Todos los productos vendidos en el
mismo día se despachan juntos?
2.2. (Escenario de negocio 2): Puede haber despachos separados por
productos?
 Resumen de 1FN, 2FN y 3FN

Primera Forma Normal

• Una relación está en primera forma normal o (1FN) si
todos los atributos de cada tupla contienen un solo valor
tomado de sus dominios respectivos (valores atómicos)
Segunda Forma Normal
• Una relación está en segunda forma normal o (2FN) si es
1FN y cada atributo no clave de la relación es total y
funcionalmente dependiente (DFC) de su clave primaria
 Resumen de 1FN, 2FN y 3FN

Tercera Forma Normal

• Una relación está en tercera forma normal o
(3FN) si es 2FN y ningún atributo no-clave en la
relación esta en DF con algún otro atributo no-
clave