TRABAJO DE INVETIGACION

BASE DE DATOS I

PRESENTADO POR:

JOSE DAVID PAEZ RUIZ

PRESENTADO A:

FABIO ORTIZ

CORPORACION UNVERSITARIA LATINOAMERICANA

CUL

INGENIERIA DE SISTEMAS Y COMPUTACION

2020-1
DEFINICION, IMPORTANCIA Y CARACTERISTICAS

El proceso de normalización de una base de datos consiste en aplicar una serie de reglas a las

relaciones obtenidas tras el paso del modelo E-R (entidad-relación) al modelo relacional.

La normalización es la transformación de las vistas de usuario complejas y del almacén

de datos a un juego de estructuras de datos más pequeñas y estables. Además de ser
más simples y estables, las estructuras de datos son más fáciles de mantener que otras
estructuras de datos. (Kendall, 2005)

Para mejorar el desempeño de una base de datos, así como evitar redundancia en la
información que contiene y, en consecuencia, generar condiciones para un mejor
diseño, el analista de sistemas debe conocer las formas de normalización y condiciones
en las que la desnormalización es recomendable.

OBJETIVO DE LA NORMALIZACION

Las bases de datos relacionales se normalizan para:

 Evitar la redundancia de los datos.

 Evitar problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.

REQUISITOS

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla
bidimensional sea considerada como una relación tiene 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.

FORMAS NORMALES

Las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría de las
bases de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Codd, éste
introdujo la normalización en un artículo llamado A Relational Model of Data for Large Shared
Data Banks.

 Primera Forma Normal (1FN)

Sea α un conjunto de atributo perteneciente (Є) a la relación R, en donde R está en la Primera

Forma Normal si todos los atibutos α[n] son atómicos, es decir no pueden seguir dividiéndose. Por
ejemplo:

La Relación:

cursos: nombre, código, vacantes, horario, bibliografía

Queda después de aplicar la Forma Normal 1 de la siguiente manera:

 cursos1: nombre, código, vacantes horario1: código, día, módulo bibliografia1: código, nombre,
autor

 Segunda Forma Normal (2FN)

Dependencia completa. Está en 2FN si está en 1FN y si sus atributos no principales dependen de
forma completa de la clave principal.

 Tercera Forma Normal (3FN)

Está en segunda forma normal y todo atributo no primo es implicado por la clave primaria en una
secuencia no transitiva. Se eliminan las dependencias transitivas.

 Forma normal de Boyce-Codd (FNBC)

Una tabla está en FNBC sí y sólo sí las únicas dependencias funcionales elementales son aquellas
en las que la clave primaria determina un atributo.

 Cuarta Forma Normal (4FN)

Está en forma normal de Boyce-Codd y se eliminan las dependencias multivaluadas y se generan

todas las relaciones externas con otras tablas u otras bases de datos.

 Quinta Forma Normal (5FN)

Está en cuarta forma normal y toda dependencia-join viene implicada por claves candidatas.

EJEMPLO

Tenemos una empresa pública donde los puestos de trabajo están regulados por el Estado, de
modo que las condiciones salariales están determinadas por el puesto. Se ha creado el siguiente
esquema relacional

EMPLEADOS(nss, nombre, puesto, salario, emails) con nss como clave primaria.

nss nombre puesto salario emails

111 Juan Pérez Jefe de Área 3000 juanp@[Link]; jefe2@[Link]

222 José Sánchez Administrativo 1500 jsanchez@[Link]

333 Ana Díaz Administrativo 1500 adiaz@[Link]; ana32@[Link]

 Primera forma normal (1FN)

Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver
que el atributo emails puede contener más de un valor, por lo que viola 1FN.

En general, tenemos una relación R con clave primaria K. Si un atributo M viola la condición de

1FN, tenemos dos opciones.

Solución 1: duplicar los registros con valores repetidos

En general, esta solución pasa por sustituir R por una nueva relación modificada R', en la cual:

 El atributo M que violaba 1FN se elimina.

 Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si
R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras
palabras, para una tupla con n valores duplicados en M, en la nueva relación
habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores que
había en M.
 La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los
valores multivaluados en M.

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(a) con

clave primaria (nss, email):

nss nombre puesto salario email

111 Juan Pérez Jefe de Área 3000 juanp@[Link]

111 Juan Pérez Jefe de Área 3000 jefe2@[Link]

222 José Sánchez Administrativo 1500 jsanchez@[Link]

333 Ana Díaz Administrativo 1500 adiaz@[Link]

333 Ana Díaz Administrativo 1500 ana32@[Link]

... ... ... ... ...

 Solución 2: separar el atributo que viola 1FN en una tabla

En general, esta solución pasa por:

sustituir R por una nueva relación modificada R' que no contiene el atributo M.

Crear una nueva relación N(K, M'), es decir, una relación con una clave ajena K referenciando R',
junto al atributo M', que es la variante mono-valuada del atributo M.

La nueva relación N tiene como clave (K, M').

Siguiendo el ejemplo, tendríamos el siguiente esquema para la nueva tabla EMPLEADOS'(b)

nss nombre puesto salario

111 Juan Pérez Jefe de Área 3000

222 José Sánchez Administrativo 1500

333 Ana Díaz Administrativo 1500

... ... ... ...

Y además tendríamos una nueva tabla EMAILS con clave primaria (nss, email):

nss email

111 juanp@[Link]

111 jefe2@[Link]

222 jsanchez@[Link]

333 adiaz@[Link]
333 ana32@[Link]

... ...

Segunda forma normal (2FN)

Un esquema está en 2FN si:

Está en 1FN.

Todos sus atributos que no son de la clave principal tienen dependencia funcional completa
respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada
atributo no clave se necesita la clave primaria completa, no vale con una subclave.

La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos.
Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces
también está en 2FN. Por tanto, de las soluciones anteriores, la tabla EMPLEADOS'(b) está en 1FN
(y la tabla EMAILS no tiene atributos no clave), por lo que el esquema está en 2FN. Sin embargo,
tenemos que examinar las dependencias funcionales de los atributos no clave
de EMPLEADOS'(a). Las dependencias funcionales que tenemos son las siguientes:

nss->nombre, salario, email

puesto->salario

Como la clave es (nss, email), las dependencias de nombre, salario y email son incompletas, por lo
que la relación no está en 2FN.

En general, tendremos que observar los atributos no clave que dependan de parte de la clave.

Para solucionar este problema, tenemos que hacer lo siguiente para los gupos de atributos con
dependencia incompleta M:

Eliminar de R el atributo M.

Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende,
que llamaremos K'.

La clave primaria de la nueva relación será K'.

Siguiendo el ejemplo anterior, crearíamos una nueva relación con los atributos que tienen
dependencia incompleta:

nss nombre puesto salario

111 Juan Pérez Jefe de Área 3000

222 José Sánchez Administrativo 1500

333 Ana Díaz Administrativo 1500

... ... ... ...

Y al eliminar de la tabla original estos atributos nos quedaría:

nss email

111 juanp@[Link]

111 jefe2@[Link]

222 jsanchez@[Link]

333 adiaz@[Link]

333 ana32@[Link]

... ...

Como vemos, la solución a la que llegamos es la misma que en la otra opción de solución para el
problema de 1FN.

Tercera forma normal (3FN)

Una relación está en tercera forma normal si, y sólo si:

 está en 2FN

y, además, cada atributo que no está incluido en la clave primaria no depende transitivamente de
la clave primaria.

Por lo tanto, a partir de un esquema en 2FN, tenemos que buscar dependencias funcionales entre
atributos que no estén en la clave.

En general, tenemos que buscar dependencias transitivas de la clave, es decir, secuencias de

dependencias como la siguiente: K->A y A->B, donde A y B no pertenecen a la clave. La solución a
este tipo de dependencias está en separar en una tabla adicional N el/los atributos B, y poner
como clave primaria de N el atributo que define la transitividad A.

Siguiendo el ejemplo anterior, podemos detectar la siguiente transitividad:

nss->puesto

puesto->salario

Por lo tanto la descomposición sería la siguiente:

nss nombre puesto

111 Juan Pérez Jefe de Área

222 José Sánchez Administrativo

333 Ana Díaz Administrativo

... ... ...

En la nueva tabla PUESTOS, la clave sería el puesto, que también queda como clave ajena
referenciando la tabla EMPLEADOS. El resto de las tablas quedan como estaban.
BIBLIOGRAFIA

 [Link]
 [Link]
/content/1/contenido/[Link]
 [Link]
bases-de-datos-relacionales-hasta-3FN