El documento explica la normalización de bases de datos, que es el proceso de diseñar la estructura lógica de los datos en el modelo relacional para evitar redundancia, problemas de actualización y proteger la integridad de los datos. La normalización implica aplicar reglas para dividir las tablas y asegurar que dependan sólo de la clave principal, lo que minimiza anomalías y mejora la calidad del diseño alcanzando diferentes formas normales como la primera, segunda y tercera forma normal.

1. NORMALIZACIÒN
Técnica para diseñar la estructura lógica de los datos de un sistema de información
en el modelo relacional, desarrollada por E. F. Codd en 1972.

2. Al tener las tablas ya relacionadas se deben de aplicar reglas de
normalización de todas las tablas.
• Las bases de datos relacionales se normalizan para:
• Evitar la redundancia de datos.
• Evitar problemas de actualización de los datos en las
tablas.
• Proteger la integridad de los datos.

3. Siempre que se diseña un
sistema no solo una base
de datos, si no también
cualquier tipo de solución
informática, se ha de
medir la calidad de la
misma, y sino cumple
determinados criterios de
calidad, hay que realizar,
de forma iterativa,
sucesivos refinamiento en
el diseño., para alcanzar la
calidad deseada.
Uno de los parámetros que
mide la calidad de una
base de datos es la forma
normal en la que se
encuentra su diseño. Esta
forma normal puede
alcanzarse cumpliendo
ciertas restricciones que
imponen cada forma
normal al conjunto de
atributos de un diseño.
El proceso de obligar a los
atributos de un diseño
cumplir ciertas formas
normales se llama
NORMALIZACIÒN.

4. Refinamiento de un diseño de base de datos

5. CONCEPTUALIZACIÒN
La normalización es el proceso
mediante el cual se transforman
datos complejos a un conjunto
de estructuras de datos más
pequeñas, que además de ser
más simples y más estables, son
más fáciles de mantener.
También se puede entender la
normalización como una serie
de reglas que sirven para
ayudar a los diseñadores de
bases de datos a desarrollar un
esquema que minimice los
problemas de lógica.
La normalización se adoptó
porque el viejo estilo de poner
todos los datos en un solo lugar,
como un archivo o una tabla
de la base de datos, era
ineficiente y conducía a errores
de lógica cuando se trataban
de manipular los datos
El proceso de normalización
tiene un nombre y una serie de
reglas para cada fase. Esto
puede parecer un poco
confuso al principio, pero poco
a poco se va entendiendo el
proceso, así como las razones
para hacerlo de esta manera.
En el modelo relacional es
frecuente llamar tabla a una
relación, aunque para que una
tabla sea considerada como
una relación tiene que cumplir
con algunas restricciones:
•Cada columna debe tener su
nombre único.
•No puede haber dos filas
iguales. No se permiten los
duplicados.
•Todos los datos en una
columna deben ser del mismo
tipo.

6. Dependencia funcional
Relación
entre
atributos de
una misma
tabla.
Si x e y son atributos de la relación R, se dice que y es
funcionalmente dependiente de x (se denota por x → y) si cada
valor de x tiene asociado un solo valor de y (x e y pueden constar
de uno o varios atributos).
A x se le denomina determinante, ya que x determina el valor de
y. Se dice que el atributo y es completamente dependiente de x
si depende funcionalmente de x y no depende de ningún
subconjunto de x.
La dependencia funcional es una noción semántica. Si hay o no
dependencias funcionales entre atributos no lo determina una serie
abstracta de reglas, sino, más bien, los modelos mentales del usuario y
las reglas de negocio de la organización o empresa para la que se
desarrolla el sistema de información. Cada dependencia funcional es
una restricción y representa una relación de uno a muchos (o de uno a
uno).

7. Dependencia funcional
En el proceso de normalización se debe
ir comprobando que cada tabla
cumple una serie de reglas que se
basan en la clave primaria y las
dependencias funcionales. Cada regla
que se cumple aumenta el grado de
normalización. Si una regla no se
cumple, la tabla se debe descomponer
en varias tablas que sí la cumplan.
La normalización se lleva a cabo en una
serie pasos. Cada paso corresponde a
una forma normal que tiene unas
propiedades. Conforme se va
avanzando en la normalización, las
tablas tienen un formato más estricto
(más fuerte) y, por lo tanto, son menos
vulnerables a las anomalías de
actualización.
El modelo relacional sólo requiere un
conjunto de tablas en primera forma
normal (en caso contrario no se pueden
implementar). Las restantes formas
normales son opcionales. Sin embargo,
para evitar las anomalías de
actualización, es recomendable llegar
al menos a la tercera forma normal.

8. (Y no depende de X)
Ejemplo 1
PRODUCTOS (CódigoProducto, Nombre,
Fabricante, País)
CódigoProducto Fabricante
Fabricante → País
CódigoProducto - → País, es decir,
CódigoProducto depende transitivamente
de País
Ejemplo 2:
PRODUCTOS (CódigoProducto,
Nombre, Fabricante, País)
CódigoProducto Nombre
Nombre → CódigoProducto
CódigoProducto - → Nombre

9. FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas norlames
Primera Forma Normal 1FN
•Una tabla está en primera forma normal
(1FN) si, y sólo si, todos los dominios de sus
atributos contienen valores atómicos, es
decir, no hay grupos repetitivos. Un grupo
repetitivo es un atributo que puede tener
múltiples valores para cada fila de la
relación.

11. Si se tiene la relación Alumnos con los siguientes campos:
codigo_alum, nombre_alum y asignaturas_alum, de los
cuales el campo asignaturas_alum, almacena las
asignaturas en las que recibe clases cada alumno.
Se observa en la relación Alumnos, los registros dos y tres
tienen dominios que contienen varios valores por tanto la
relación no se encuentra en primera forma normal. Para
convertir esta relación en la primera forma normal se crea
una nueva relación Asignatura, en donde cada asignatura
responderá a una clave principal.
Ejemplo

12. FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Segunda Forma Normal 2FN
•Una tabla está en segunda forma normal
(2FN) si, y sólo si, está en 1FN y, además, cada
atributo que no forma parte de la clave
primaria es completamente dependiente de
la clave primaria.
•La 2FN se aplica a las tablas que tienen claves
primarias compuestas por dos o más atributos.
Si una tabla está en 1FN y su clave primaria es
simple (tiene un solo atributo), entonces
también está en 2FN.
•Las tablas que no están en 2FN pueden sufrir
anomalías cuando se realizan actualizaciones
sobre ellas.

13. Ejemplo
la relación Pedidos ya se encuentra en su segunda forma normal
inicialmente por el hecho de estar en primera forma normal y contar
como clave principal con un único atributo
Mientras que en lo que respecta a la relación denominada
Linea_pedidos, para que logre estar en su segunda forma normal se
deberá verificar que todos sus atributos que no son considerados
clave, como lo son la descrip_art, cantidad_art y pvp_art, respondan
completamente a la clave principal, por lo tanto, lo siguiente quiere
decir que deben tener totalmente una dependencia funcional con
relación al par de atributos (codigo_ped, codigo_art):
(codigo_ped, codigo_art) ⇒ Descrip_art
(codigo_ped, codigo_art) ⇒ cantidad_art
(codigo_ped, codigo_art) ⇒ pvp_art

14. Ejemplo
Primera dependencia funcional total: No es verdadera ya que la descripción del
artículo responde únicamente al código del mismo y no al código del pedido que lo
solicita, por ende, es considerada como verdadera la dependencia parcial entre
codigo_art → descrip_art. Por este motivo se puede asegurar que la relación
Linea_pedidos no se encuentra en su segunda forma normal.
Segunda dependencia funcional total: Es considerada como verdadera ya que la
cantidad que es solicitada de un artículo por un pedido no está determinada
únicamente por el pedido con el que se está tratando o el artículo que es
requerido, sino por los dos. Es decir que se tendría lo siguiente codigo_ped →
cantidad_art, puesto que en un pedido sería posible solicitar varias y distintas
cantidades de artículos el que se está tratando o el artículo que es requerido, sino
por los dos. Es decir que se tendría lo siguiente codigo_ped → cantidad_art, puesto
que en un pedido sería posible solicitar varias y distintas cantidades de artículos.
Tercera dependencia funcional total: Es considerada verdadera cuando los valores
correspondientes a los artículos no son siempre los mismos para los pedidos. Es
común que el valor de cada artículo sea el mismo para todos y cada uno de los
clientes, es por esto que se comprueba la dependencia funcional codigo_art →
pvp_art, motivo por el cual tampoco se cumple que aquel atributo que no es clave
pvp_art vaya totalmente a depender de la clave, lo cual indicaría otra razón para
que la relación no se encuentre en su segunda forma normal. Otra manera de
observar cuando una relación se encuentra en su segunda forma normal es
examinando su diagrama de dependencias funcionales.

15. FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Tercera Forma Normal 3FN
•Una tabla está en tercera forma normal (3FN) si, y sólo si, está en
2FN y, además, cada atributo que no forma parte de la clave
primaria no depende transitivamente de la clave primaria. La
dependencia x −→ z es transitiva si existen las dependencias x
−→ y, y −→ z, siendo x, y, z atributos o conjuntos de atributos de
una misma tabla.
•La tercera forma normal se fundamenta del concepto de
dependencia transitiva, por lo tanto, se dice que una relación
está en tercera forma normal solo si sus atributos dependen
únicamente a la clave principal mas no de otros atributos.
•Para renunciar a las dependencias transitivas se debe descartar
de la relación que no se encuentra en tercera forma normal el
atributo que genera la dependencia transitiva y se crea una
relación que contenga los atributos transitivos conjuntamente
con el atributo del que requiere es decir mediante el cual
conserva su transitividad.
PRODUCTOS (CódigoProducto, Nombre, Fabricante, País).
CódigoProducto → Fabricante
Fabricante → País
CódigoProducto - -/→País
País depende transitivamente de CódigoProducto, por tanto, no está en
tercera
forma normal.

16. FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Forma normal de Boyce/Codd
• Una tabla está en la forma normal de Boyce–Codd
(BCFN) si, y sólo si, todo determinante es una clave
candidata.
• La 2FN y la 3FN eliminan las dependencias parciales y las
dependencias transitivas de la clave primaria. Pero este
tipo de dependencias todavía pueden existir sobre otras
claves candidatas, si éstas existen. La BCFN es más fuerte
que la 3FN, por lo tanto, toda tabla en BCFN está en 3FN.
• La violación de la BCFN es poco frecuente ya que se da
bajo ciertas condiciones que raramente se presentan.
• Se debe comprobar si una tabla viola la BCFN si tiene
dos o más claves candidatas compuestas que tienen al
menos un atributo en común.
NOTAS (DNIAlumno, DNIProfesor,NombreProfesor, Nota)
DNIProfesor → NombreProfesor
NombreProfesor → DNIProfesor
DNIProfesor,DNIAlumno → Nota
En este caso, la tabla está en 3FN porque no hay dependencias funcionales
transitivas, y sin embargo no está en FNBC porque NombreProfesor y DNI
Profesor son implicantes, y no son claves candidatas. Para obtener la tabla en
FNBC habría que quitar de la tabla los atributos DNIProfesor y NombreProfesor.

17. FORMAS
NORMALES
•Primera forma normal
•Segunda forma normal
•Tercera forma normal
•Forma normal de
Boyce/Codd
•Otras formas normales
Otras formas normales
• Existen más formas normales (FN4, FN5, FNDK, FN6...)
• Las formas normales 4 y 5, se ocupan de las
dependencias entre atributos multivaluados, la Forma
Normal Dominio Clave (FNDK) trata las restricciones y los
dominios de los atributos, y finalmente la FN6 trata ciertas
consideraciones con las bases de datos temporales.

18. Referentes
• López, I, Castellano, M. y Ospino, J. (2013). Bases de datos. Desarrollo de aplicaciones
multiplataforma y web DAM y DAW. Elfaomega, México.
• Marqués, M. (2009). Bases de datos. [Material online]. Departamento de Ingeniería y Ciencia de la
Computación, UNIVERSITAT JAUME I DE CASTELLÓ. España.
• Zea, M., Honores, J. y Rivas, W. (2015). Fundamentos de base de datos. Ediciones utmach, Ecuador.