Facultad de Ingeniería de Sistemas e Informática

Sesión 10:
Normalización
Asignatura: Base de Datos I
César Luza Montero
cluzam@unmsm.edu.pe

2020
 Motivación

Base de Datos I 2
 Saberes previos
 Transforme MER a MR

Base de Datos I 3
 Conflicto cognitivo
 Caso de diseño de BD Relacional:
 La compañía de seguros PREVISORA necesita una Base de Datos para
guardar la información de los vehículos asegurados y de sus propietarios,
así como de clientes potenciales (no tienen ningún vehículo asegurado).
 De momento, sólo necesita tener de cada vehículo su número de
matrícula, fecha de matriculación, precio, modelo, potencia, color y
fabricante.
 En cuanto a los propietarios, desea guardar sus nombres y apellidos, DNI,
y dirección (calle, número, ciudad y distrito postal).
 Evidentemente, es posible que un cliente tenga asegurados varios
vehículos, y que algunos vehículos figuren a nombre de varios
propietarios.

Base de Datos I 4
 Objetivos de aprendizaje
 Al finalizar esta sesión, el estudiante será capaz de:
 Realiza el proceso de normalización de base de datos relacional según la
teoría de las formas normales y dependencias funcionales valorando la
importancia de estos temas para evitar anomalías en el diseño de base de
datos.

Base de Datos I 5
 Contenido

Diseño BD Relacional

Dependencia Funcional

Formas Normales

Proceso de normalización

Base de Datos I 6
 Diseño BD Relacional
 Enfoques:
 Directo, mediante Relación Universal
 Por fases (conceptual, lógico y físico)

Base de Datos I 7
 Diseño BD Relacional
 Enfoque Directo
Relación Universal
(DNI, nombre, calle, n°, Ciudad; DP, matricula, modelo, pot., fecha, precio; fabricante, color)

Requiere un proceso de normalización

Base de Datos I 8
 Diseño BD Relacional
 Enfoque Directo
 Normalización
 Técnica para producir un conjunto de relaciones con propiedades
deseables, dados los requisitos de datos de una empresa.
 Propósito: Identificar un conjunto adecuado de relaciones que
respalden los requisitos de datos de una empresa.
 Características de relaciones adecuadas:
 El número mínimo de atributos necesarios para soportar los requisitos de
datos de la empresa;
 Los atributos con una relación lógica cercana (descrita como dependencia
funcional) se encuentran en la misma relación;
 Redundancia mínima, con cada atributo representado solo una vez, con la
importante excepción de los atributos que forman la totalidad o parte de las
claves externas que son esenciales para la unión de relaciones relacionadas.

Base de Datos I 9
 Diseño BD Relacional
 Enfoque Por Fases

DER

Esquema Relacional
CLIENTE (DNI, nombre, ciudad, calle, num, codPost)
VEHÍCULO (matricula, fecha, idModelo, fabricante, potencia, precio; color);
ASEGURAR (DNI, matricula);
PK = (DNI,matricula)
FK = (DNI), referencia a CLIENTE; borrado en cascada
FK = (matricula), referencia a VEHÍCULO; borrado en cascada

Base de Datos I 10
 Diseño BD Relacional
 Enfoque por fases

Base de Datos I 11
 Diseño BD Relacional
 Enfoque Por Fases
 Normalización
 Técnica usada para validar la estructura de las relaciones
obtenidas mediante la trasformación MER a MR.

Base de Datos I 12
 Diseño BD Relacional
 Propósito de la normalización
 No importa qué enfoque se use, el objetivo es el mismo; crear un
conjunto de relaciones bien diseñadas que cumplan con los
requisitos de datos de la empresa.

Base de Datos I 13
 Diseño BD Relacional
Propósito de la normalización

Base de Datos I 14
 Diseño BD Relacional
 Sea el esquema relacional:
 PEDIDO (Articulo, Cliente, cantidad, precio, ciudad, área)
 Instancias de PEDIDO:

Articulo Cliente cantidad precio ciudad área

A1 C1 12 100 Madrid 400
A1 C2 30 100 Valencia 200
A1 C3 15 100 Alicante 80
A2 C1 35 250 Madrid 400
A2 C2 20 250 Valencia 200
A2 C4 10 250 Madrid 400
A3 C3 25 175 Alicante 80

Analice las tuplas, que problemas o anomalías observa?

Base de Datos I 15
 Diseño BD Relacional
 Problemas y anomalías en el diseño de BD Relacional:
 Redundancia
 Anomalía de inserción
 Anomalía de modificación
 Anomalía de borrado

Base de Datos I 16
 Diseño BD Relacional
 Problemas y anomalías en la tabla PEDIDOS
Redundancia Anomalía de Anomalía de Anomalía de
Inserción modificación borrado
El nombre de la ¿Podemos registrar ¡Podemos tener el Si eliminamos el
ciudad se repite nuevo articulo? mismo articulo con artículo A3, se
en todas las filas ¿Nuevo cliente? dos precios pierde dato de la
donde esta el ¿Nueva ciudad? distintos¡ cantidad
mismo cliente Igual, una misma De igual forma, si
ciudad con dos se elimina al
El área de una
areas cliente C4
ciudad y
Problemas de Pérdida de
El precio de un inconsistencias información.
articulo

Base de Datos I 17
 Contenido

Diseño BD Relacional

Dependencia Funcional

Formas Normales

Proceso de normalización

Base de Datos I 18
 Dependencia Funcional
 Observe la tabla PEDIDO
Articulo Cliente cantidad precio ciudad área
A1 C1 12 100 Madrid 400
A1 C2 30 100 Valencia 200
A1 C3 15 100 Alicante 80
A2 C1 35 250 Madrid 400
A2 C2 20 250 Valencia 200
A2 C4 10 250 Madrid 400
A3 C3 25 175 Alicante 80

Todas las filas de un mismo articulo tienen el mismo valor de precio,

El atributo precio depende funcionalmente de articulo,
Articulo  Precio
¿Que otras dependencias existen?

Base de Datos I 19
 Dependencia Funcional
 Definición
 Sea R = (A, B, C, …., Z)
 Sean A y B atributos de una relación R.
 Se dice que B es funcionalmente dependiente de A (A  B) si cada valor
de A esta asociado con un único valor de B.
 A y B pueden ser atributos simples o compuestos.

Determinante

David Maier (1983)

http://web.cecs.pdx.edu/~maier/TheoryBook/TRD.html

Base de Datos I 20
 Dependencia Funcional
 Ejemplo 01:
 Sea R = PEDIDO (artículo, cliente, cantidad, precio, ciudad, área)
 DF:
 artículo  precio,
 cliente  ciudad,
 ciudad  área
 (artículo, cliente)  {cantidad,precio}

Base de Datos I 21
 Dependencia Funcional
 Ejemplo 02:

1:1 1:N

Base de Datos I 22
 Dependencia Funcional
 Ejemplo 03:
 staffNo  sName
 sName  staffNo

Base de Datos I 23
 Dependencia Funcional
 Dependencia funcional completa
 Sea X (conjunto de atributos).
 Se dice que Y tiene dependencia funcional completa de X, si depende
funcionalmente de X pero no depende de ningún subconjunto del mismo-
 La dependencia funcional X  Y es una dependencia funcional completa
si la eliminación de cualquier atributo de X hace que la dependencia ya
no exista.
 Una dependencia funcional X  Y es una dependencia funcional parcial
si hay algún atributo que se puede eliminar de X y, sin embargo, la
dependencia aún se mantiene.

Base de Datos I 24
 Dependencia Funcional
 Ejemplo 04
 Sea R = PEDIDO (artículo, cliente, cantidad, precio, ciudad, área)
 DF:
 (artículo, cliente)  (cantidad) es una DF Completa
 (artículo, cliente)  (precio) no es una DF Completa (DF
Parcial), por que también artículo  precio.

Base de Datos I 25
 Dependencia Funcional
 Ejemplo 05
 staffNo, sName  branchNo (DF Parcial)
 staffNo  branchNo

Base de Datos I 26
 Dependencia Funcional
 Dependencia funcional transitiva
 Sea A, B, C atributos de una relación
 Si A  B y B  C ,
 Entonces, C es transitivamente dependiente de A (vía B, siempre que A no
sea funcionalmente dependiente de B o C)
 A -- C (C depende transitivamente de A)

Base de Datos I 27
 Dependencia Funcional
 Ejemplo 06
 Sea R = PEDIDO (artículo, cliente, cantidad, precio, ciudad, área)
 DF:
 cliente  ciudad,
 ciudad -/-> cliente (no determina funcionalmente), y
 ciudad  área,
 Entonces, cliente -- área (área depende “transitivamente”
de cliente).

Base de Datos I 28
 Dependencia Funcional
 Ejemplo 07

Base de Datos I 29
 Dependencia Funcional
 Identificando dependencias funcionales
 Sea la relación StaffBranch
 Examinemos la semántica de sus atributos
 Asumamos que position (cargo) y branchNo (sucursal)
determinan el salario de un miembro del personal.
 Identificamos las dependencias funcionales basadas en nuestra
comprensión de los atributos en la relación como:
 staffNo  sName, position, salary, branchNo, bAddress
 branchNo  bAddress
 bAddress  branchNo
 branchNo, position  salary
 bAddress, position  salary

Base de Datos I 30
 Dependencia Funcional
 Identificando dependencias funcionales

A ® C (fdl)
C ® A (fd2)
B ® D (fd3)
A, B ® E (fd4)
B, C ® E (fd5)

Base de Datos I 31
 Dependencia Funcional
 Identificando Primary key
 A, B, C, (A,B) y (B,C) son determinantes.
 Los únicos determinantes que determinan todos los demás
atributos de la relación son (A, B) y (B, C).
 En (A,B),
 A  C, B  D, y (A, B)  E.
 Entonces, los atributos del determinante (A, B) pueden determinar a los otros
atributos en la relación, sea como A o B o como (A, B).
 Una clave candidata son los atributos de un determinante ya sea
individualmente o trabajando juntos, debe poder determinar funcionalmente
todos los demás atributos en la relación.
 Esta característica también es cierta para el determinante (B, C), pero no es una
característica de los otros determinantes en la relación (es decir, A, B o C), ya
que en cada caso solo pueden determinar otro atributo en el relación.

Base de Datos I 32
 Contenido

Problemas en el diseño relacional

Dependencia Funcional

Formas Normales

Proceso de normalización

Base de Datos I 33
 Formas Normales
 1ª FN (Codd, 1970)
 Concepto de relación normalizada.
 2ª, 3ª FN (Codd, 1970), FNBC (Boyce/Codd, 1974)
 Basadas en análisis de dependencias funcionales.
 4ª FN. Fagin, 1977
 Basada en análisis de dependencias multivaluadas .
 5ª FN. Fagin, 1979
 Basada en análisis de dependencias de proyección / combinación.

Base de Datos I 34
 Formas Normales
 1ª FN
 Un esquema o relación está en 1ª FN
 Si el dominio asociado a cada atributo contiene únicamente valores
atómicos; es decir, no tiene atributos multivalorados (repetidos)

EMPLEADO
Nom_empleado dependientes grado sueldo
Juan Pérez Lucia Gonzáles Esposa 2 500
Javier Pérez Hijo
María Pérez Hijo
Aníbal Campos Carmen Soto Esposa 3210

Base de Datos I 35
 Formas Normales
 2ª FN
 Un esquema o relación R (A,DF) está en 2ª FN,
 Si y sólo si está en 1ª FN (es decir, si la relación está normalizada) y
 Sus atributos no primarios dependen completamente de la clave primaria
de R.
Articulo Cliente cantidad precio ciudad área
A1 C1 12 100 Madrid 400
A1 C2 30 100 Valencia 200
A1 C3 15 100 Alicante 80
A2 C1 35 250 Madrid 400
A2 C2 20 250 Valencia 200
A2 C4 10 250 Madrid 400
A3 C3 25 175 Alicante 80

(artículo, cliente)  precio no es una DF completa, porque artículo  precio.

Base de Datos I 36
 Formas Normales
 3ª FN
 Un esquema o relación R(A,DF) está en 3ª FN,
 Si y sólo si, está en 2ª FN y
 Ninguno de sus atributos no primarios depende transitivamente de la
clave primaria de R.
 Es decir no hay dependencias funcionales transitivas.

Cliente ciudad área

C1 Madrid 400
C2 Valencia 200 cliente  ciudad,
C3 Alicante 80 ciudad  área,
C1 Madrid 400
Entonces, cliente --  área
C2 Valencia 200
C4 Madrid 400
C3 Alicante 80

Base de Datos I 37
 Contenido

Problemas en el diseño relacional

Dependencia Funcional

Formas Normales

Proceso de normalización

Base de Datos I 38
 Normalización
 Es una técnica formal de análisis y organización de datos que trata
de evitar la redundancia y anomalías de inserción, modificación y
borrado
 El proceso de normalización consiste en aplicar una serie de reglas
(Formas Normales) a las relaciones obtenidas tras el paso del MER al
MR o por el enfoque directo
 Formaliza el diseño lógico de base de datos relacional con los
criterios matemáticos de Formas Normales

La Normalización es una técnica para producir un conjunto de

relaciones con propiedades deseables, a partir de los requisitos de
datos de una empresa.

Base de Datos I 39
 Normalización
 Formas Normales
 Un esquema de relación está en una determinada forma normal si
satisface un determinado conjunto específico de restricciones
(dependencia funcional) definidas sobre los atributos del
esquema.

Base de Datos I 40 40
 Proceso de Normalización

Base de Datos I 41
 Proceso de Normalización
FERRETERIA Fecha:
“Las Lomas “ 02/09/2004
Av. Abancay Nro. 362 - Lima
FACTURA
Cliente: 335 Nro. 00273
Nombre: Roberto Antonio CHAVEZ

Cant. CodPro Descripción Precio

Unitario
12 Importe
P2 Pernos 6 “
2.00
24 P3 24.00
Tuercas acero inoxidable 1.50
02 36.00
P4 Clavos de 2”
0.50 1.0020

TOTAL 61.00

Base de Datos I 42
 Proceso de Normalización

Relación Universal

FACCOD FACFEC CLICOD CLINOM PROCOD PRODES PROCAN PROPRE

273 2/09/04 335 Chávez P2 Pernos 12 2.0

P3 Tuercas 24 1.5
P4 Clavos 2 2 0.5

Base de Datos I 43
 Proceso de Normalización

Algoritmo para pasar al 1FN

SI
Relación Hay grupos Separar
Universal repetitivos relaciones

NO
Existe
SI unicidad
de llave
1FN
NO

Necesita llave de
anterior

Base de Datos I 44
 Proceso de Normalización
 Pasando a 1FN

Columnas cuyos datos Columnas que representan

representan sólo un valor datos con más de un valor

FACCOD FACFEC CLICOD CLINOM PROCOD PRODES PROCAN PREUNI

273 2/ 09/ 04 335 Chavez P2 Pernos 12 2.0
P3 Tuercas 24 1.5
P4 Clavos 2 2 0.5
274 3/ 09/ 04 875 Borja P3 Tuercas 12 1.5
P5 Terokal 3 4.0

Base de Datos I 45
 Proceso de Normalización
 Pasando a 1FN (cont.)
FACTURA
FACCOD FACFEC CLICOD CLINOM
273 2/ 09/ 04 335 Chavez
274 3/ 09/ 04 875 Borja

DETALLE DE FACTURA
Necesito llave
FACCOD PROCOD PRODES PROCAN PREUNI
anterior
273 P2 Pernos 12 2.0
273 P3 Tuercas 24 1.5
273 P4 Clavos 2 2 0.5
274 P3 Tuercas 12 1.5
274 P5 Terokal 3 4.0

Base de Datos I 46
 Proceso de Normalización

Algoritmo para pasar a 2FN

SI
1FN Tiene Llave
Compuesta

Hay Atributos
dependientes
NO NO parcialmente
de la llave

2FN
SI

Separar la llave parcial

y sus atributos en relaciones
separadas

Base de Datos I 47
 Proceso de Normalización
 Pasando a 2FN
FACTURA
FACCOD FACFEC CLICOD CLINOM
273 2/ 09/ 04 335 Chavez
274 3/ 09/ 04 875 Borja

DETALLE DE FACTURA
FACCOD PROCOD PRODES PROCAN PREUNI
273 P2 Pernos 12 2.0
273 P3 Tuercas 24 1.5
273 P4 Clavos 2 2 0.5
274 P3 Tuercas 12 1.5
274 P5 Terokal 3 4.0

Base de Datos I 48
 Proceso de Normalización
 Pasando a 2FN (Cont.)

DETALLE DE FACTURA
FACCOD PROCOD PROCAN
273 P2 12
273 P3 24
PRODUCTO
273 P4 2
274 P3 12 PROCOD PRODES PREUNI
274 P5 3 P2 Pernos 2.0
P3 Tuercas 1.5
P4 Clavos 2 0.5
P5 Terokal 4.0

Base de Datos I 49
 Proceso de Normalización

Algoritmo para pasar a 3FN

Atributos
NO
dependientes
2FN directamente
de la llave

Abrir en
SI relaciones
separadas

3FN

SI
Atributos
dependientes no
directamente
de la nueva
llave

Base de Datos I 50 50
 Proceso de Normalización
 Pasando a 3FN

FACTURA
FACCOD FACFEC CLICOD CLINOM
273 2/ 09/ 04 335 Chavez
274 3/ 09/ 04 875 Borja
DETALLE DE FACTURA
FACCOD PROCOD PROCAN PRODUCTO
273 P2 12 PROCOD PRODES PREUNI
273 P3 24 P2 Pernos 2.0
273 P4 2 P3 Tuercas 1.5
274 P3 12 P4 Clavos 2 0.5
274 P5 3 P5 Terokal 4.0

Base de Datos I 51
 Proceso de Normalización
 Pasando a 3FN (cont.)
FACTURA
FACCOD FACFEC CLICOD CLINOM
273 2/ 09/ 04 335 Chavez
274 3/ 09/ 04 875 Borja
275 3/ 09/ 04 335 Chavez

FACTURA
FACCOD FACFEC CLICOD
273 2/ 09/ 04 335 CLIENTE
274 3/ 09/ 04 875 CLICOD CLINOM
275 3/ 09/ 04 335 335 Chavez
875 Borja

Base de Datos I 52
 Proceso de Normalización
 Esquema Final

FACTURA
CLIENTE
FACCOD FACFEC CLICOD
CLICOD CLINOM
273 2/ 09/ 04 335
335 Chavez
274 3/ 09/ 04 875 875 Borja

DETALLE DE FACTURA
PRODUCTO
FACCOD PROCOD PROCAN
PROCOD PRODES PREUNI
273 P2 12
P2 Pernos 2.0
273 P3 24
P3 Tuercas 1.5
273 P4 2
P4 Clavos 2 0.5
274 P3 12
P5 Terokal 4.0
274 P5 3

Base de Datos I 53
 Bibliografía
 Connolly, Thomas; Begg, Carolyn (2015) Database Systems. A
Practical Approach to Design, Implementation, and Management.
SIXth edition. Pearson Education Limited.

Base de Datos I 54