0% encontró este documento útil (0 votos)
135 vistas

Normalizacion

El documento trata sobre la normalización de bases de datos. La normalización es un proceso mediante el cual los datos complejos se transforman en estructuras más pequeñas para lograr tablas con una estructura óptima y evitar problemas como la redundancia y inconsistencia de datos. Se explican las primeras formas normales como la 1FN, 2FN y 3FN, las cuales ayudan a eliminar anomalías al momento de realizar operaciones en las bases de datos.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
135 vistas

Normalizacion

El documento trata sobre la normalización de bases de datos. La normalización es un proceso mediante el cual los datos complejos se transforman en estructuras más pequeñas para lograr tablas con una estructura óptima y evitar problemas como la redundancia y inconsistencia de datos. Se explican las primeras formas normales como la 1FN, 2FN y 3FN, las cuales ayudan a eliminar anomalías al momento de realizar operaciones en las bases de datos.
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 19

TEMA V

NORMALIZACION

Presentación
La normalización es un proceso mediante el cual datos complejos se transforman en un conjunto
de estructuras más pequeñas. Dicho de otra manera, normalización es un proceso, basado en
reglas, que pretende conseguir tablas con una estructura óptima y eficaz; es decir, la
independencia de los datos respecto a los procesos o aplicaciones que los utilizan.

Contenido:

- Introducción
- Primera Forma Normal (1FN)
- Segunda Forma Normal (2FN)
- Tercera Forma Normal (3FN)
- Forma Normal de Boyce Codd
( FNByC)
- Cuarta Forma Normal ( 4FN)
- Quinta Forma Normal (5FN)

Texto en revisión – Versión 2-2015 87 Ing. Josue O. Veizaga Gonzales


Mapa Conceptual

Texto en revisión – Versión 2-2015 88 Ing. Josue O. Veizaga Gonzales


Introducción

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las
relaciones obtenidas tras el paso del modelo orientado a objetos ( diagrama de clases) al modelo
relacional.
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.
Estas anomalías se producen al momento de realizar inserción, eliminación y actualización de
datos.

Los aspectos que se debe tomar en cuenta al momento de realizar una normalización son:

 No se debe eliminar ningún atributo.


 Tampoco se deben eliminar tuplas. Y debe evitarse la creación de tuplas nuevas.
 Deben conservarse las dependencias originales.

Texto en revisión – Versión 2-2015 89 Ing. Josue O. Veizaga Gonzales


5.1 Primera Forma Normal (1FN)

La esencia de la Primera Forma Normal es que:

Un registro en Primera Forma Normal no incluye ningún grupo repetitivo.

La definición formal es:

“ Una relación está en primera forma normal, si cumple la propiedad de que sus
dominios no tienen elementos que, a su vez, sean conjuntos”. (A. Mayne, M. Wood, 1983)

Caso 1: Dominios y valores

Supongamos que se desea guardar los nombres y los números telefónicos de los clientes, pero
nos damos cuenta que es necesario guardar múltiples números telefónicos para algunos clientes.
La manera más simple de hacer esto es permitir que el atributo "Teléfono" contenga más de un
valor :

Ci Nombre Apellido Paterno Apellido Materno Telefono

111 Joaquin Chumacero Yupanqui 3541030

222 Saturnino Mamani Yucra 7103040

3568070

333 Patricia Aguilera Gonzales 3564025

Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de
número telefónico (por ejemplo, el dominio de cadenas de 7 caracteres de longitud), la
representación de arriba no está en 1FN. La 1FN prohíbe a un campo contener más de un valor
de su dominio de columna.

Caso 2: Grupos repetidos a través de columnas


El diseñador puede evitar esta restricción definiendo múltiples columnas del número telefónico:

Texto en revisión – Versión 2-2015 90 Ing. Josue O. Veizaga Gonzales


Clientes

Ci Nombre Apellido Paterno Apellido Materno Telefono1 Telefono2 Telefono3

111 Joaquin Chumacero Yupanqui 3541030

222 Saturnino Mamani Yucra 7103040 3568070

333 Patricia Aguilera Gonzales 3564025

Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y por lo
tanto no se conforman con la definición de la 1NF. Por ejemplo es difícil contestar : ¿Qué
clientes tienen el teléfono X? y ¿Qué pares de clientes comparten un número de teléfono?.

Caso 3: Repetición de grupos dentro de columnas


Alternativamente una solución podría ser conservar una sola columna de número de teléfono,
pero alterando su dominio, haciendo una cadena de suficiente longitud para acomodar múltiples
números telefónicos:
Clientes

Ci Nombre Apellido Paterno Apellido Materno Telefono

111 Joaquin Chumacero Yupanqui 3541030

222 Saturnino Mamani Yucra 7103040, 3568070

333 Patricia Aguilera Gonzales 3564025

Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de la 1NF.

Un diseño conforme con 1FN

Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de cliente y una
tabla de teléfono del cliente.

Texto en revisión – Versión 2-2015 91 Ing. Josue O. Veizaga Gonzales


Cliente

Ci Nombre Apellido Paterno Apellido Materno

111 Joaquin Chumacero Yupanqui

222 Saturnino Mamani Yucra

333 Patricia Aguilera Gonzales

Teléfono del cliente

Ci Telefono

111 3541030

222 7103040

222 3568070

333 3564025

5.2 Segunda Forma Normal:

En cualquier registro que este en Segunda Forma Normal (SFN), todos sus atributos dependen de
la clave completa y no solo de una parte de esta.

La definición formal es:

“Una relación R esta es Segunda Forma Normal, si además de estar en la Primera


Forma Normal, cualquiera de sus atributos no-primarios tiene una dependencia funcional
plena con cada una de las claves candidatas de R” . (A. Mayne, M. Wood, 1983)

Caso de estudio 1 : Notas de alumnos

Supongamos la tabla ( relación) Notas_de_alumnos

Texto en revisión – Versión 2-2015 92 Ing. Josue O. Veizaga Gonzales


CI SIGLA NOMBRE DE MATERIA NOTA

111 INF110 INTRODUCCIÓN A LA INFORMATICA 70

111 MAT101 CALCULO I 90

222 INF110 INTRODUCCIÓN A LA INFORMATICA 90

222 INF312 BASES DE DATOS I 30

333 INF552 ARQUITECTURA DE SOFTWARE 100

La única clave candidata es {CI,SIGLA}, el atributo NOTA depende de forma completa de la


llave, sin embargo el NOMBRE DE LA MATERIA solo depende de una parte de ella, del
atributo SIGLA, violando la definición de la SFN.

Las anomalías de esta tabla se puede dar al insertar una nuevo tupla , por ejemplo si se ingresa la
nota de un nuevo alumno para la materia INTRODUCCIÓN A LA INFORMATICA, al
transcribir se registra con el nombre de INTRODUCCIÓN A LA INFORMA, se está dando un
problema de inconsistencia de datos. El nombre de una materia puede ser de diferentes maneras.
En el caso de una actualización del nombre de la materia de INTRODUCCIÓN A LA
INFORMATICA, por PROGRAMACIÓN I, sería necesario actualizar todas la tuplas que
coincidan con el criterio de búsqueda. En el caso de eliminación, por ejemplo si se elimina la
tupla 333, INF552, la materia ARQUITECTURA DE SOFTWARE, deja de existir.

Para que este en SFN, se realiza lo siguiente.

Notas_alumno

CI SIGLA NOTA

111 INF110 70

111 MAT101 90

222 INF110 90

222 INF312 30

333 INF552 100

Texto en revisión – Versión 2-2015 93 Ing. Josue O. Veizaga Gonzales


Materia

SIGLA NOMBRE DE MATERIA

INF110 INTRODUCCIÓN A LA INFORMATICA

MAT101 CALCULO I

INF312 BASES DE DATOS I

INF552 ARQUITECTURA DE SOFTWARE

Caso de estudio 2: Habilidades de empleados

Considere una tabla describiendo las habilidades de los empleados:


Habilidades de los empleados

Empleado Habilidad Lugar actual de trabajo

Joaquin Mecanografía Urb. Los tusequis

Joaquin Taquigrafía Urb. Los tusequis

Joaquin Tallado Urb. Los tusequis

Saturnino Limpieza ligera Av. Roca Coronado 700

Pedro Alquimia Calle Tordo S/N

Pedro Malabarismo Calle Tordo S/N

Patricia Limpieza ligera Av. Landivar 300

La única clave candidata de la tabla es {Empleado, Habilidad}.


El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave (llave) ,
llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la redundancia de la manera en
que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Joaquin trabaja
en la urb. Los tusequs, y dos veces que Pedro trabaja en calle tordo S/N. Esta redundancia hace a
la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del
Texto en revisión – Versión 2-2015 94 Ing. Josue O. Veizaga Gonzales
trabajo de Joaquin en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro
"Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el
lugar actual de trabajo de Joaquin?".
Un alternativa 2NF a este diseño representaría la misma información en dos tablas:
Empleados

Empleado Lugar actual de trabajo

Joaquin Urb. Los tusequis

Saturnino Av. Roca Coronado 700

Pedro Calle Tordo S/N

Patricia Av. Landivar 300

Habilidades de los empleados

Empleado Habilidad

Joaquin Mecanografía

Joaquin Taquigrafía

Joaquin Tallado

Saturnino Limpieza ligera

Pedro Alquimia

Pedro Malabarismo

Patricia Limpieza ligera

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.

Texto en revisión – Versión 2-2015 95 Ing. Josue O. Veizaga Gonzales


5.3 Tercera Forma Normal:

La Tercera Forma Normal (TFP) elimina las dependencias entre atributos no primarios (no
perteneciente a la clave)

La definición formal es:

Una relación R esta en Tercera Forma Normal si esta en Segunda Forma Normal y
además ningunos de sus campos no-primarios tiene dependencias transitivas respectos de las
claves candidatas R.

Caso de estudio 1: Alumnos que estudian una carrera

CI NombreAlumno Teléfono código NombreCarrera

111 Joaquin Chumacero 3567736 187 Ing. Informática

222 Saturnino Mamani 7102030 200 Medicina

333 Carla Landivar 3556655 187 Ing. Informática

444 Pedro Castro 3544566 210 Economía

555 Patricia Yucra 7082828 187 Ing. Informática

La única clave candidata es CI, el atributo NOMBREALUMNO, TELEFONO, CODIGO


depende de forma completa de la llave, sin embargo el NOMBRECARRERA solo depende de
CODGIO ( No es la llave, ni parte de la llave) , dándose un problema de transitividad, donde CI
determina a CODIGO y CODIGO determina a NOMBRECARRERA , violando la definición de
la 3FN.

Las anomalías de esta tabla se puede dar al insertar una nueva tupla , por ejemplo si se ingresa un
nuevo alumno con el nombre de la Carrera Ing. INFORMAT, se está dando un problema de
inconsistencia de datos. El nombre de la carrera puede ser de diferentes maneras. En el caso de
una actualización del nombre de la carrera de ING. INFORMATICA, por CIENCIAS DE LA
COMPUTACIÓN, sería necesario actualizar todas la tuplas que coincidan con el criterio de
búsqueda. En el caso de eliminación, por ejemplo si se elimina la tupla 444, la carrera
ECONOMIA, deja de existir.

Texto en revisión – Versión 2-2015 96 Ing. Josue O. Veizaga Gonzales


Para que este en 3FN, se realiza lo siguiente.

Alumno

CI NombreAlumno Teléfono código

111 Joaquin Chumacero 3567736 187

222 Saturnino Mamani 7102030 200

333 Carla Landivar 3556655 187

444 Pedro Castro 3544566 210

555 Patricia Yucra 7082828 187

Carrera

código NombreCarrera

187 Ing. Informática

200 Medicina

210 Economía

Caso de estudio 2: Inquilino de edificio

Inquilino

Inquilino Departamento Alquiler

100 D04 1500

200 D01 1000

300 D02 2000

400 D04 1500

Texto en revisión – Versión 2-2015 97 Ing. Josue O. Veizaga Gonzales


Dependencias funcionales:

Inquilino  Departamento

Departamento  Alquiler

Aplicando la tercera forma normal, el resultado es:

Inquilinio

Inquilino Departamento

100 D04

200 D01

300 D02

400 D04

Departamento

Departamento Alquiler

D04 1500

D01 1000

D02 2000

5.4 Forma Normal de Boyce-Codd (FNBC)

La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la normalización


de bases de datos. Es una versión ligeramente más fuerte de la Tercera forma normal (3FN). La
forma normal de Boyce-Codd requiere que no existan dependencias funcionales no triviales de
los atributos que no sean un conjunto de la clave candidata.

Texto en revisión – Versión 2-2015 98 Ing. Josue O. Veizaga Gonzales


La definición formal es:

Se dice que una tabla está en FNBC si y solo si está en 3FN y cada dependencia funcional
no trivial tiene una clave candidata como determinante. En terminos menos formales, una tabla
está en FNBC si está en 3FN y los únicos determinantes son claves candidatas.

Caso de estudio 1: Tutorias

CI MATERIA TUTOR

111 Lenguaje Eva

111 Matematica Andres

222 Lenguaje Eva

333 Matematicca Guillermo

333 Lenguaje Julia

(ci,materia)  tutor y tutor materia. En este caso la redundancia ocurre por la mala
selección de la clave. La redundancia de la materia es completamente evitable.

TUTOR-MATERIA

Materia Tutor

Lenguaje Eva

Matematicas Andres

Matemáticas Guillermo

Lenguaje Julia

Texto en revisión – Versión 2-2015 99 Ing. Josue O. Veizaga Gonzales


TUTORIAS

CI TUTOR

111 Eva

111 Andres

222 Eva

333 Guillermo

333 Julia

5.5 Cuarta Forma Normal:

La cuarta forma normal (4NF) es una forma normal usada en la normalización de bases de datos.
La 4NF se asegura de que las dependencias multivaluadas independientes estén correcta y
eficientemente representadas en un diseño de base de datos. La 4NF es el siguiente nivel de
normalización después de la forma normal de Boyce-Codd (BCNF).

La definición formal es:

“ Una tabla está en 4NF si y solo si esta en Tercera forma normal o en BCNF (Cualquiera
de ambas) y no posee dependencias multivaluadas no triviales”.

Una tabla con una dependencia multivaluada es una donde la existencia de dos o más relaciones
independientes muchos a muchos causa redundancia; y es esta redundancia la que es suprimida
por la cuarta forma normal.

Caso de estudio 1: Permutaciones de envíos de pizzas

Restaurante Variedad de Pizza Área de envío

Horno Caliente Corteza gruesa Distrito 1

Horno Caliente Corteza gruesa Distrito 2

Horno Caliente Corteza fina Distrito 1

Texto en revisión – Versión 2-2015 100 Ing. Josue O. Veizaga Gonzales


Elite Pizza Corteza fina Distrito 3

Elite Pizza Corteza rellena Distrito 3

Pizza Delicia Corteza gruesa Distrito 1

Pizza Delicia Corteza gruesa Distrito 2

Pizza Delicia Corteza gruesa Distrito 3

Pizza Delicia Corteza rellena Distrito 1

Pizza Delicia Corteza rellena Distrito 2

Pizza Delicia Corteza rellena Distrito 3

Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un área
dada.

Las anomalías en esta tabla se puede evidenciar en lo siguiente:

- El restaurante HORNO CALIENTE, al comenzar tenía una sola variedad de pizza,


CORTEZA GRUESA, pero si se distribuía a dos áreas de envío, DISTRITO 1 Y
DISTRITO 2.

Restaurante Variedad de Pizza Área de envío

Horno Caliente Corteza gruesa Distrito 1

Horno Caliente Corteza gruesa Distrito 2

En esta caso, para poder ingresar DISTRITO1 Y DISTRITO 2 Es necesario repetir la


variedad de pizza CORTEZA GRUESA ( Duplicidad de datos).

- ELITE PIZZA, tiene dos variedades CORTEZA RELLENA, CORTEZA FINA, pero
solo un solo área de envío.

Texto en revisión – Versión 2-2015 101 Ing. Josue O. Veizaga Gonzales


Elite Pizza Corteza fina Distrito 3

Elite Pizza Corteza rellena Distrito 3

En este caso, en el área de envío se duplica ( DISTRITO 3)

Todo esto se debe a:

a) RESTAURANTE determina a VARIEDAD DE PIZZA

b) RESTAURANTE determina a AREA DE ENVIO

Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza ofrecidas en una
tabla diferente de los hechos sobre áreas de envío:

Variedades por restaurante

Restaurante Variedad de Pizza

Horno Caliente Corteza gruesa

Horno Caliente Corteza fina

Elite Pizza Corteza fina

Elite Pizza Corteza rellena

Pizza Delicia Corteza gruesa

Pizza Delicia Corteza rellena

Áreas de envío por restaurante

Restaurante Área de envío

Horno Caliente Distrito 1

Horno Caliente Distrito 2

Texto en revisión – Versión 2-2015 102 Ing. Josue O. Veizaga Gonzales


Elite Pizza Distrito 3

Pizza Delicia Distrito 1

Pizza Delicia Distrito 2

Pizza Delicia Distrito 3

Texto en revisión – Versión 2-2015 103 Ing. Josue O. Veizaga Gonzales


5.6 Ejercicios de retroalimentación

Ejercicio 1. Indicar que forma normal no cumple. Realizar el proceso de normalización.

ALUMNO
#REGISTRO NOMBRE SEXO TELEFONO CARRERA CARRERA CARRERA
1 2 3

Ejercicio 2. Dada la siguiente relación:

VENTA
#COCHE FECHA_VENTA #VENDEDOR COMISION DESCUENTO

NORMALIZAR.
Suponiendo que un coche puede ser vendido por múltiples vendedores y por lo tanto [coche,
vendedor] es la clave primaria. Otras dependencias funcionales son:
DF1) FECHA_VENTA --> DESCUENTO
DF2) #VENDEDOR --> COMISION

Ejercicio 3. Cada despacho de una oficina es identificado por un #despacho y tiene precisamente
un teléfono. Cada teléfono tiene su propio #extensión. Hay dos tipos de teléfonos, solo para
llamadas internas (tipo I), y para llamadas externas/internas (tipo E). los costes de alquiler de
extensión dependen únicamente del tipo, teléfonos de tipo I son cargados con la tarifa T1, los del
tipo E con la tarifa T2. La información sobre despachos y teléfonos será almacenada en la
siguiente relación.

OFICINA
#DESPACHO NUMERO_OCUPANTES #EXTENSION TIPO_TELEFONO TARIFA

Ejercicio 4. La escuela de deportes tiene la siguiente estructura para la inscripción de sus


alumnos a los deportes que desempeñaran sus deportistas.

INSCRIPCION

#Estudiante #Actividad Precio


100 Tenis 500
100 Futbol 700
200 Tenis 500
300 Karate 400

La llave principal es #Estudiante, #Actividad

Dependencia funcional es: #Actividad  Precio

Texto en revisión – Versión 2-2015 104 Ing. Josue O. Veizaga Gonzales


Ejercicio 5. Un Aficionado a la música decide automatizar la administración de su colección
pues empieza a ser muy grande. Los datos a considerar son los siguientes:

El título del volumen (T) es único.


Cada título tiene un único tipo de soporte (S) que es DVD o CD.
Varios títulos pueden ser de un mismo cantante o grupo (CG), con una año (A) de edición.
Además en un título pueden intervenir varios cantantes o grupos.
También se conoce la estantería (E) donde está ubicado el título existiendo al menos una
estantería por año de edición.
Además, se conocen las canciones (C) de cada título, no existiendo en un título dos canciones
con el mismo nombre.
La duración (D) de una canción puede variar en los distintos títulos en los que se incluye,
pudiendo ser o no interpretada por el mismo cantante o grupo.

Ejercicio 6. El Seguro Social desea conocer los pacientes (DNI) que han sido atendidos en sus
hospitales (COD_H) y el doctor (COD_D) que los atiende. Se supone que un doctor sólo puede
atender en un hospital y que, aunque un paciente puede ser atendido en varios hospitales, en cada
uno de ellos sólo le atiende un doctor.

Texto en revisión – Versión 2-2015 105 Ing. Josue O. Veizaga Gonzales

También podría gustarte