Ingeniería de datos I

Sesión 7: Normalización de datos

1.1 ¿Qué es la dependencia funcional?
La dependencia funcional es la relación de dependencia que existe entre los atributos
de una Entidad; estas dependencias son definidas por el mismo modelo que es el reflejo de
los objetos y su comportamiento dentro de la realidad.
En términos de dependencia entre atributos diremos que, “un Atributo B es
funcionalmente dependiente de otro atributo A si cada valor de la columna A determina uno
y solamente un valor de la columna B”.
Gráficamente, una relación de dependencia funcional entre atributos como el que se ha
señalado en el ejemplo, se indica como: A → B. En este caso, el atributo A se denomina
Determinante.
Tal como se indicó en la lección anterior, toda entidad o tabla de datos tiene un atributo
identificador primario; es decir un atributo que no acepta valores nulos y que no tiene
valores repetidos. En base a ello, se dice que la entidad está perfectamente normalizada si
todos los demás atributos de esa entidad dependen funcionalmente de su atributo
identificador. Por ejemplo; consideremos la entidad:
CLIENTE (CodCliente, NombreCompleto, Dirección, Email)
En este caso, CodCliente → NombreCompleto, Dirección, Email; entonces el
determinante es CodCliente y la entidad así definida está Normalizada.

1.1.1 Ley distributiva de las dependencias funcionales

Esta regla establece que si un atributo A es determinante de un conjunto de dos o más
atributos; entonces A será determinante de cada uno de ellos; así:
Si: A → (B, C), Entonces: A → B ^ A → C
Veamos el ejemplo anterior:
Si CodCliente → (NombreCompleto, Dirección, Email); entonces
CodCliente → NombreCompleto ^ CodCliente → Dirección ^ CodCliente → Email
Nota importante
Lo contrario no se cumple, es decir; si (CodVendedor, TotalVentas) → Comisión
No es cierto que, CodVendedor → Comisión ^ TotalVentas → Comisión

DR. LUIS BOY CHAVIL

Ingeniería de datos I

1.1.2 Dependencias funcionales parciales

Una dependencia funcional se dice que es parcial, cuando el determinante está formado
por dos o más atributos y la dependencia funcional se presenta solamente en una parte de
dicho determinante. Veamos un ejemplo:
VENTA (NroFactura, CodProducto, NombreProducto, Precio, Stock, Cantidad)
En este caso el determinante está formado por un atributo compuesto; es decir por la
concatenación de los atributos: (NroFactura, CodProducto); pero las dependencias:
- (NroFactura, CodProducto) → NombreProducto; es Parcial porque el atributo
NombreProducto solamente depende del atributo CodProducto.
- (NroFactura, CodProducto) → Precio; también tiene dependencia funcional parcial.
- (NroFactura, CodProducto) → Stock; igualmente tiene dependencia funcional parcial.
- (NroFactura, CodProducto) → Cantidad; aquí si hay una dependencia funcional completa,
pues se requieren los valores de estos dos atributos para obtener el valor de la cantidad.

1.1.3 Dependencias funcionales multivaluadas

La dependencia funcional multivaluada se presenta cuando una entidad tiene dos o más
atributos independientes entre sí, pero que cada uno de ellos dependen funcionalmente de
un tercer atributo. Veamos el siguiente ejemplo:
Sea la entidad: POSTULANTE (CodPostulante, Nombre, WorksAnteriores, VacunasPuestas)
En este caso, los atributos: WorksAnteriores y VacunasPuestas son independientes
entre sí, pero los dos atributos dependen de CodPostulante ya que estos datos se refieren
al mismo postulante en cuestión.
Gráficamente, tenemos:
CodPostulante →→ WorksAnteriores
CodPostulante →→ VacunasPuestas

1.1.4 Claves Candidatas

Se dice que un atributo o clave es Candidata cuando no existen iguales filas en el
conjunto de atributos. Por ejemplo; Sea la Entidad:
CLIENTE (CodCliente, DNI, RUC, Nombre)
En este caso, la clave primaria es CodCliente, pero las propiedades de no nulo y valor
único también se presenta en el atributo DNI, de modo tal que este nuevo atributo también
sería una clave primaria; sin embargo, para el caso, sería Clave Candidata.

DR. LUIS BOY CHAVIL

Ingeniería de datos I

Importante
Toda entidad solo puede identificarse por una única clave primaria.

1.2 ¿Qué es la Normalización de datos?

La Normalización de datos se refiere a la aplicación de un conjunto de reglas bien definidas
sobre aquellas entidades que presentan anomalías en los atributos que las describen. El objetivo
principal apunta a la eliminación o disminución al máximo de la redundancia de datos y de datos
innecesarios. Una de las razones más importantes por las que se debe tener mucho cuidado en
el diseño de un modelado de datos es que siempre hay que proyectarnos al futuro de la
empresa, tomar en cuenta, por ejemplo, el nivel de crecimiento de la empresa, su capacidad de
expansión en nuevos mercados, con nuevos productos o con productos innovadores, la
implementación de nuevas políticas administrativas y de operaciones en el negocio; todo ello,
evidentemente afectará al modelado de datos e irremediablemente causará que en el futuro se
tenga que desarrollar cambios en el diseño de las bases de datos, por ello, es muy importante
que no nos enredemos con las entidades y sus relaciones pues de lo contrario todo nuestro
trabajo podría colapsar rápidamente por estas inconsistencias y redundancias no controladas.

1.3 Reglas de la Normalización de datos

Las reglas que se aplican para lograr una base de datos lo suficientemente consistente
como para afianzar su crecimiento y desarrollo sin dificultades son puestas en marcha en forma
ordenada, desde la primera forma normal, conocida como 1NF, luego de ella se aplicará la
segunda forma normal (2NF), se continua con la tercera forma normal (3NF). En este punto, se
puede decir que la base de datos ya se encuentra en un nivel medianamente sólida en su
definición; sin embargo, todavía hay algunos problemas adicionales que de no ser atendidas
desde la definición de la base de datos, podría producir errores e inconsistencias posteriores;
por ello, hay más reglas, como por ejemplo la normalización de Boyce y Codd, conocida como
forma normal extendida (BCNF), luego otras inconsistencias podrían solucionarse con la
aplicación de las reglas de la cuarta forma normal (4NF), y finalmente podemos llegar hasta la
quinta forma normal (5NF).

DR. LUIS BOY CHAVIL

Ingeniería de datos I

Entidad No Normalizada
Analicemos la Entidad PEDIDO cuyo detalle de atributos se
muestra en la siguiente figura.

Figura 1: Entidad PEDIDO

PEDIDO (NroPedido, Fecha, DNICliente, Nombre, Dirección, Artículo, Descripción,

Precio, Stock, Cantidad)
En este caso observamos inconsistencia de datos para ingresar nuevas filas; pues
hay redundancia en los casos donde el pedido tiene muchos artículos.

1.3.1 Normalización en Primera Forma Normal - 1NF

Se dice que una Entidad o tabla de datos se encuentra normalizada en 1NF cuando no
existen filas de datos con grupos de atributos repetitivos.
Analizando el ejemplo anterior; se detecta que hay un grupo de datos repetitivos
conformado por los atributos: (Artículo, Descripción, Precio, Stock, Cantidad). La regla nos
indica que en estos casos deberíamos separar en dos entidades, tal como se indica en la
siguiente gráfica:
PEDIDO (NroPedido, Fecha, DNICliente, Nombre, Dirección)
DETALLE_PEDIDO (NroPedido, Artículo, Descripción, Precio, Stock, Cantidad)

Figura 2: Normalización en 1NF

DR. LUIS BOY CHAVIL

Ingeniería de datos I

1.3.2 Normalización en Segunda Forma Normal - 2NF

La aplicación de la regla de la Segunda Forma Normal se desarrolla en aquellas entidades
que en primer lugar ya se encuentran normalizadas en 1NF y que ahora se definen con
atributos concatenados cuya inconsistencia que se debe resolver se encuentra en que las
dependencias funcionales esperadas de los atributos del cuerpo de la entidad, solo tiene
dependencia parcial de la clave concatenada. En estos casos, la regla establece que se debe
separar las entidades, tal como se muestra en el siguiente ejemplo:
PEDIDO (NroPedido, Fecha, DNICliente, Nombre, Dirección)
DETALLE_PEDIDO (NroPedido, Artículo, Precio, Cantidad)
ARTICULO (Artículo, Descripción, Precio, Stock)
Gráficamente, tenemos:

Figura 3: Normalización en 2NF

1.3.3 Normalización en Tercera Forma Normal - 3NF

La regla de normalización en 3NF se aplica a las entidades que previamente se
encuentran en 2NF y establece que todos los atributos del cuerpo de la entidad deben
depender funcionalmente de su atributo de clave primaria, de lo contrario es mejor crear
nuevas entidades. Asimismo, la regla también establece que los atributos que se pueden
calcular pueden obviarse de la entidad. En el ejemplo; observamos que la entidad PEDIDO
tiene inconsistencia en cuanto al atributo DNICliente el cual actúa como atributo
identificador y los demás atributos (Nombre, Dirección) actúan con dependencia funcional.
En este caso, las entidades quedarían así:
PEDIDO (NroPedido, Fecha, DNICliente)
CLIENTE (DNICliente, Nombre, Dirección)
DETALLE_PEDIDO (NroPedido, Artículo, Precio, Cantidad)
ARTICULO (Artículo, Descripción, Precio, Stock)

DR. LUIS BOY CHAVIL

Ingeniería de datos I

Gráficamente, tenemos:

Figura 4: Normalización en 3NF

En este punto, podremos decir que el proceso de normalización de la base de datos ha

concluido ya que en la mayoría de los casos las inconsistencias serían mínimas; sin embargo,
todavía podría presentarse otras anomalías que valen la pena ser analizadas, veamos:

1.3.4 Normalización en la Forma Normal de Boyce y Codd – BCNF

La regla de la normalización en BCNF se aplica a las entidades que previamente se
encuentran en 3NF y que tienen atributos determinantes que a su vez son claves candidatas.
El ejemplo que venimos analizando no tiene estas particularidades por ello decimos que se
encuentra normalizada en BCNF; Sin embargo, el ejemplo que se analiza más adelante si ha
sido propuesto con las características de esta mencionada forma normal.

1.3.5 Normalización en Cuarta Forma Normal - 4NF

La regla de la normalización en 4NF se aplica a las entidades que se encuentran
normalizadas en su forma BCNF y que no tienen dependencia de valores múltiples. Este tipo
de normalización facilita la relación entre las entidades con relacionamiento de muchos a
muchos. Este caso, se analiza con mayor detalle en el ejemplo que se presenta más adelante.

1.3.6 Normalización en Quinta Forma Normal - 5NF

Esta regla se aplica a las entidades que ya se encuentran en la forma 4NF. Se conocen
como la forma normal de proyección unión; pues las únicas dependencias que existe son las
dependencias de unión de la entidad con sus proyecciones cuya relación se lleva a cabo a
través de su clave primaria o de alguna de sus claves candidatas.

DR. LUIS BOY CHAVIL

Ingeniería de datos I

En el presente ejemplo no hay necesidad de evaluar estas proyecciones, por ello,

consideramos que el modelo descrito ya se encuentra en 5NF. Más adelante se presentará
este caso con mayor detalle.

2. Planteamiento de un ejemplo completo de Normalización de datos

La empresa Palermo S.A.C. Rent a Car, alquila autos y camionetas para ser utilizados por
sus clientes en el Perú; para ello, su departamento de Sistemas y Comunicaciones ha
encargado la elaboración del modelado de datos debidamente normalizado que pueda
permitir el procesamiento de la siguiente Hoja de Alquiler de Vehículos.

Figura 5: Formato de hoja de alquiler de vehículos

Consideraciones de importancia para comprender los detalles de la figura anterior

- El Tipo de Cliente es: N. Cliente Natural, J. Cliente Jurídico
- Un Cliente Natural; es una persona que no requiere el uso del Registro único del
contribuyente; es decir Número de RUC.
- Un cliente Jurídico; es básicamente una empresa. Aquí el Nº de RUC es fundamental e
indispensable.
- El tipo de documento (TipoDoc); puede ser uno de los siguientes:
o Para Clientes naturales: DNI o Pasaporte

DR. LUIS BOY CHAVIL

Ingeniería de datos I

o Para Clientes jurídicos: RUC

- El tipo de contrato puede ser: Contrato Personal, o contrato corporativo (para empresas)
- El Rubro de la empresa se refiere al giro de negocios; puede ser: 1. Textil, 2. Construcción,
3. Imprenta, 4. Metalurgia, 5. Educación, …. Etc.
- El tipo de vehículo puede ser: 1. Auto deportivo, 2. Auto convencional, 3. Camioneta 4 x 4,
4. Camioneta 4x2; … Etc.
- El código del vehículo es en realidad su número de placa.
- Los Accesorios del vehículo se refiere a aquellos que se agregan al vehículo en forma
adicional; como, por ejemplo: Palanca de seguridad contra robos para timón, Botiquín de
primeros auxilios, Extinguidor; etc.
- La duración en días será calculada en número de días a partir de la fecha de inicio hasta la
fecha de término del contrato de alquiler.
- El precio por día es el precio diario de alquiler del vehículo.
- SubParcial = Duración x PrecioDía
- El Número de días de reserva se calcula entre la diferencia de días de la fecha del contrato
y la fecha de inicio del alquiler. Se calcula en cantidad de días, para asignar un descuento
por reserva oportuna. Las reservas menores a 2 meses no tienen descuento, si el tiempo
está entre 2 y 4 meses, el descuento es de 10% del SubParcial, y si el tiempo es mayor a 4
meses, el descuento es de 15%.
- Importe = SubParcial – Descuento
- Un Garante puede avalar a más de un cliente, pero un cliente sólo puede presentar un
garante.
- Los clientes naturales solo pueden alquilar un vehículo, siempre y cuando su edad sea mayor
de 25 años, y cuente con licencia de conducir vigente.
- Sólo las empresas pueden hacer alquileres corporativos de varios vehículos dentro de un
mismo contrato.

Solución al caso planteado

La solución al caso planteado inicia con la elaboración de la entidad no Normalizada,

veamos:

DR. LUIS BOY CHAVIL

 Ingeniería de datos I

2.1 Entidad no normalizada

Esta entidad está conformada por la relación de todos y cada uno de los atributos
necesarios para replicar el documento Hoja de Alquiler de vehículos.

2.2 Normalización en 1NF

Separando en una nueva entidad a los grupos de datos
repetidos, tenemos:

Figura 6: Entidad no Normalizada Figura 7: Normalización en 1NF

DR. LUIS BOY CHAVIL

Ingeniería de datos I

2.3 Normalización en 2NF

Separando en nuevas entidades a los datos que tienen dependencia funcional parcial en
entidades con atributos identificadores concatenados, tenemos:

Figura 8: Normalización en 2NF

2.4 Normalización en 3NF

Tomando en cuenta los atributos de las entidades normalizadas en 2NF, verificaremos
aquellos atributos que tienen dependencia funcional transitiva entre atributos no clave, y
otros atributos que podríamos eliminar si el proceso los puede calcular con cierta facilidad,
veamos:

DR. LUIS BOY CHAVIL

Ingeniería de datos I

1. Datos para los Clientes

CodCliente → (TipoCliente, NameCliente, DirCliente, TipoDoc, NroDoc, TfFijo, Email, Facebook,
Instagram, Twitter, Otro)
CLIENTE (CodCliente, TipoCliente, NameCliente, DirCliente, TipoDoc, NroDoc, TfFijo, Email,
Facebook, Instagram, Twitter, Otro)
2. Datos para los Tipos de Cliente
TipoCliente → (DescripcionTC)
TIPO_CLIENTE (TipoCliente, DescripcionTC)
3. Datos para Los Representantes Legales
DniRepLegal → (NameRepLegal, CelRepLegal, EmailRepLegal)
REPRESENTANTE (DniRepLegal, NameRepLegal, CelRepLegal, EmailRepLegal)
4. Datos para el Cliente Jurídico
CodCliente → (DniRepLegal)
CLIENTE_JURIDICO (CodCliente, DniRepLegal)
5. Datos para el Cliente Natural
CodCliente → (NroLicencia, VigLicencia, FechaNacim, LugarNacim, CodRegion, NameGarante,
TrabajoCliente)
CLIENTE_NATURAL (CodCliente, NroLicencia, VigLicencia, FechaNacim, LugarNacim,
CodRegion, DniGarante, TrabajoCliente)
6. Datos para las Regiones
CodRegion → (RegionProced)
REGION (CodRegion, RegionProced)
7. Datos para Los Garantes
DniGarante → (NameGarante)
GARANTE (DniGarante, NameGarante)
8. Datos del Trabajo del Cliente Natural
TrabajoCliente → (CodRubro, DirTrabCliente, EmailTrabCli, TfFijoTrabCli)
TRABAJO_CLIENTE (TrabajoCliente, CodRubro, DirTrabCliente, EmailTrabCli, TfFijoTrabCli))
9. Datos del Rubro de la Empresa donde trabaja el cliente natural
CodRubro → (DescripRubro)
RUBRO (CodRubro, DescripRubro)

DR. LUIS BOY CHAVIL

Ingeniería de datos I

10. Datos del Operador

CodOperador → NameOperador
OPERADOR (CodOperador, NameOperador)
11. Datos del Tipo de Vehículo
TipoVehiculo → DescripTipoVeh
TIPO_VEHICULO (TipoVehiculo, DescripTipoVeh)
12. Datos de la Garantía
(DniGarante, CodCliente) → CodVehiculo
GARANTIA (DniGarante, CodCliente, CodVehiculo)

Modelo de datos normalizado en 3NF

Figura 9: Normalización en 3NF

2.5 Normalización en BCNF

Observemos la entidad GARANTIA; podremos concluir lo siguiente:
- Un Garante puede garantizar a muchos Clientes; entonces: DniGarante → → CodCliente
- Un Garante puede ser garante de muchos Vehículos; luego: DniGarante →→ CodVehículo

DR. LUIS BOY CHAVIL

Ingeniería de datos I

- Pero DniGarante; NO puede ser clave primaria; ¡¡ya que se encuentra en una clave
Compuesta!!
- Por lo anterior, tenemos dos claves candidatas:
(DniGarante, CodCliente) → CodVehículo
(DniGarante, CodVehículo) → CodCliente
Además;
DniGarante →→ CodCliente ^ CodCliente → CodVehiculo
Entonces: CodCliente es un determinante.
- Se requiere conocer cuáles son los clientes de un garante y cuáles son los vehículos que ha
garantizado.
- Tomaremos la clave candidata: (DniGarante, CodCliente); como clave primaria.
Veamos los cambios a la tabla GARANTIA; al aplicar BCNF:

Sub modelo de datos para la normalización de BCNF

Figura 10: Nuevas entidades para la normalización BCNF

DR. LUIS BOY CHAVIL

Ingeniería de datos I

Modelo de datos normalizado en BCNF

Figura 11: Normalización en BCNF

2.6 Normalización en 4NF

El modelo de datos se encuentra en 2NF porque no existen dependencias funcionales
parciales. También se encuentra en 3NF porque no existe dependencias funcionales
transitivas; y se encuentra en BCNF ya que no existe determinantes que no son claves
primarias. Sin embargo, este modelo de datos no se encuentra en 4NF debido a que hay una
dependencia funcional multivaluada en la entidad DETALLE_ALQUILER, de la siguiente
manera: (NroHoja, CodVehículo) → → AccesoriosVeh.
El caso muestra que un Vehículo alquilado puede contener una lista de accesorios
adicionales solicitados por el cliente. Por ello, la entidad DETALLE_ALQUILER ha sufrido el
cambio en los atributos de la clave compuesta; así: (NroHoja, CodVehículo, AccesoriosVeh),
siendo los valores de AccesoriosVeh, un valor autogenerado por el mismo sistema de
administración de la base de datos. Lo anterior nos permitirá efectuar una relación de
muchos-a-muchos con la entidad ACCESORIO.

DR. LUIS BOY CHAVIL

Ingeniería de datos I

Recordemos que cuando se desarrolla una relación de muchos-a-muchos entre dos

entidades; su representación física obliga a crear una entidad intermedia para facilitar este
relacionamiento, tal como se indica a continuación:
Sub modelo de datos para la 4NF

Figura 12: Relacionamiento de muchos-a-muchos para la 4NF

Modelo de datos normalizado en 4NF

Figura 13: Modelo de datos normalizado en 4NF

DR. LUIS BOY CHAVIL

Ingeniería de datos I

2.7 Normalización en 5NF

La Proyección Unión que se observa se encuentra en la entidad Operador; pero como
un Operador puede gestionar varias Hojas de Alquiler; entonces haremos la extensión a
través de una Operación, veamos:
Sub modelo de datos para la 5NF

Figura 14: Relacionamiento de Proyección para la 5NF

Modelo de datos normalizado en 5NF

Figura 15: Normalización en 5NF

DR. LUIS BOY CHAVIL