BDP Compendio Unidad 1 Tema 3 2022 2

BASES DE DATOS
5 créditos
Bases de datos
Unidad 1: Diseño de bases de datos relacionales
Tema 3: Normalización
TABLA DE CONTENIDO
Tabla de contenido ........................................................................................................... 2

Tabla de Ilustraciones ...................................................................................................... 3
Organización de la lectura para el estudiante por semana del compendio....................... 4
Resultado de aprendizaje.................................................................................................. 5
De la asignatura de Base de datos............................................................................. 5
Unidad 1. Diseño de bases de datos.......................................................................... 5
3.1. Introducción a la normalización................................................................................ 5
3.1.1. Nociones básicas............................................................................................. 6
3.1.2. La necesidad de normalización....................................................................... 7
4.1.3. El proceso de normalización......................................................................... 11
3.2. Tipos de normalización ........................................................................................... 11
3.2.1. Primera forma normal, segunda forma normal, tercera forma normal ......... 12
3.2.2. Las formas normales de orden superior: Forma normal de Boyce-Codd, cuarta
forma normal, quinta forma normal........................................................................ 18
3.2.3. Desnormalización ......................................................................................... 21
Bibliografía: ................................................................................................................... 23
2
Bases de datos
TABLA DE ILUSTRACIONES
La presente imagen dentro del manual mostrará

información interesante y novedosas de la asignatura.
Sabías que
La presente imagen dentro del manual permite recordar

información que es relevante y que vas necesitar en tu vida
Recuerde que profesional.
Es un cuestionario de un conjunto de preguntas que se

confecciona para obtener información con algún objetivo en
concreto. Por cada tema de la unidad se tendrá cuestionario
Comprueba tu
que el estudiante debe resolver entre preguntas teóricas y
aprendizaje
prácticas.
Para complementar contenidos de la unidad dentro del

manual se tiene videos que permitirá al estudiante revisar y
Videos explorar conocimientos auditivos y visuales.
La presente imagen en el manual mostrará información que

debe conocer de la asignatura.
Curiosidades.
La presente imagen en el manual mostrará información que

deberá tomar en cuenta para otras unidades de la asignatura
o de otras asignaturas en semestre superiores.
Datos útiles.
3
Bases de datos
ORGANIZACIÓN DE LA LECTURA PARA EL ESTUDIANTE

POR SEMANA DEL COMPENDIO
Semanas Compendio
Semana 9 Páginas 3 – 8
Semana 10 Páginas 9 – 14
Semana 11 Páginas 15 - 20
4
Bases de datos
RESULTADO DE APRENDIZAJE
De la asignatura de Base de datos
El estudiante al finalizar el curso estará en capacidad para ser parte de un equipo de

profesionales de distintas áreas del conocimiento, demostrando una efectiva cooperación,
comunicación, con habilidades para resolver conflictos y contribuyendo proactivamente en la
propuesta de líneas estratégicas desde el punto de vista informático, para la solución de
problemas de procesamiento de datos.
Unidad 1. Diseño de bases de datos
Tema 1: Explicar los componentes principales de las bases de datos y las funciones básicas de
los sistemas de gestión de bases de datos. Diferenciar los tipos de bases de datos, en especial al
modelo jerárquico, de red y relacional, mediante sus características más relevantes y su
estructura.
Tema 2: Diseñar esquemas conceptuales, utilizando el modelado entidad-relación, de sistemas

de base de datos que den solución a un problema específico.
Tema 3: Optimizar la estructura relacional, esquema lógico de datos, de las tablas aplicando la
normalización y desnormalización.
3.1. INTRODUCCIÓN A LA NORMALIZACIÓN
La normalización de la base de datos es el proceso de estructurar una base de datos,

generalmente una base de datos relacional, de acuerdo con una serie de los llamados
formularios normales para reducir la redundancia de datos y mejorar la integridad de los datos
(Elmasri et al., 2002). Fue propuesto por primera vez por Edgar F. Codd como parte de su modelo
relacional.
La normalización implica organizar las columnas (atributos) y las tablas (relaciones) de

una base de datos para garantizar que sus dependencias se apliquen correctamente mediante
las restricciones de integridad de la base de datos (Teutli, 2012). Se logra aplicando algunas
reglas formales ya sea mediante un proceso de síntesis (creando un nuevo diseño de base de
datos) o descomposición (mejorando un diseño de base de datos existente).
5
Bases de datos
3.1.1. Nociones básicas
La normalización es el proceso de organizar datos en una base de datos. La normalización es

una técnica de diseño de bases de datos que reduce la redundancia de datos y elimina
características indeseables como anomalías de inserción, actualización y eliminación (Valverde-
González et al., 2021). El propósito de la normalización en SQL es eliminar los datos redundantes
(repetitivos) y garantizar que los datos se almacenen de forma lógica. Esto incluye la creación
de tablas y el establecimiento de relaciones entre esas tablas de acuerdo con reglas diseñadas,
tanto para proteger los datos como para hacer que la base de datos sea más flexible al eliminar
la redundancia y la dependencia inconsistente.
Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si

los datos que existen en más de un lugar deben cambiarse, los datos deben cambiarse
exactamente de la misma manera en todas las ubicaciones. Un cambio de dirección de cliente
es mucho más fácil de implementar si esos datos se almacenan solo en la tabla Clientes y en
ningún otro lugar de la base de datos.
¿Qué es una "dependencia inconsistente"? Si bien es intuitivo para un usuario buscar en la tabla
Clientes la dirección de un cliente en particular, puede que no tenga sentido buscar allí el salario
del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado
o depende de él y, por lo tanto, debe trasladarse a la tabla Empleados. Las dependencias
inconsistentes pueden dificultar el acceso a los datos porque la ruta para encontrar los datos
puede faltar o estar rota.
Hay algunas reglas para la normalización de la base de datos. Cada regla se denomina "forma
normal". Si se observa la primera regla, se dice que la base de datos está en "primera forma
normal". Si se observan las tres primeras reglas, se considera que la base de datos está en
"tercera forma normal". Aunque son posibles otros niveles de normalización, la tercera forma
normal se considera el nivel más alto necesario para la mayoría de las aplicaciones. Estas reglas
serán cubiertas en las semanas 14 y 15.
La normalización es una técnica de diseño de base de datos, que se utiliza para diseñar una
tabla de base de datos relacional hasta una forma normal superior. El proceso es progresivo y
no se puede lograr un nivel más alto de normalización de la base de datos a menos que se hayan
satisfecho los niveles anteriores (Beynon-Davies, 2018). Eso significa que, teniendo datos en
forma no normalizada y con el objetivo de lograr el nivel más alto de normalización, el primer
paso sería asegurar el cumplimiento de la primera forma normal, el segundo paso sería asegurar
que se satisfaga la segunda forma normal, y así sucesivamente en el orden mencionado
anteriormente, hasta que los datos se ajusten a la sexta forma normal.
Sin embargo, vale la pena señalar que las formas normales más allá de 4NF son principalmente
de interés académico, ya que los problemas que existen para resolver rara vez aparecen en la
práctica.
6
Bases de datos
Objetivos de la normalización
Los objetivos de normalización fueron establecidos por Codd de la siguiente manera:
 Para liberar la colección de relaciones de dependencias de inserción, actualización y

eliminación no deseadas.
 Reducir la necesidad de reestructurar la recopilación de relaciones, a medida que se
introducen nuevos tipos de datos, y así aumentar la vida útil de los programas de
aplicación.
 Hacer que el modelo relacional sea más informativo para los usuarios.
 Hacer que la recopilación de relaciones sea neutral a las estadísticas de la consulta,
donde estas estadísticas pueden cambiar con el paso del tiempo.
 Proteger la integridad de los datos.
 Facilitar el acceso e interpretación de los datos.
 Reducir el tiempo y complejidad de revisión de las bases de datos.
 Optimizar el espacio de almacenamiento.
3.1.2. La necesidad de normalización
Cuando se intenta modificar (actualizar, insertar o eliminar) una relación, pueden surgir los
siguientes efectos secundarios indeseables en las relaciones que no se han normalizado:
▪ Anomalía de actualización: La misma información se puede expresar en varias filas, por

lo tanto, las actualizaciones de la relación pueden resultar en inconsistencias lógicas.
Por ejemplo, cada registro en una relación "Habilidades de los empleados" puede
contener un ID de empleado, dirección de empleado y su habilidad. Por lo tanto, es
posible que sea necesario aplicar un cambio de dirección para un empleado en particular
a varios registros (uno para cada habilidad). Si la actualización es sólo parcialmente
exitosa, la dirección del empleado se va a actualizar en algunos registros, pero no en
otros. Entonces, la relación se deja en un estado inconsistente. Específicamente, la
relación proporciona respuestas contradictorias a la pregunta de cuál es la dirección de
este empleado en particular. Este fenómeno se conoce como anomalía de actualización.
▪ Anomalía de inserción: Hay circunstancias en las que ciertos hechos no pueden
registrarse en absoluto. Por ejemplo, cada registro en una relación "Profesor y sus
Cursos" puede contener un ID de profesor, nombre de profesor, fecha de contratación
de profesor y código de curso. Por lo tanto, se pueden registrar los detalles de cualquier
miembro de la facultad que enseñe al menos un curso, pero no se puede registrar un
miembro de la facultad recién contratado que aún no haya sido asignado para enseñar
ningún curso, excepto estableciendo el código del curso en nulo. Este fenómeno se
conoce como anomalía de inserción.
▪ Anomalía de eliminación: En determinadas circunstancias, la eliminación de datos que
representan ciertos hechos requiere la eliminación de datos que representan hechos
completamente diferentes. La relación "Facultad y sus Cursos" descrita en el ejemplo
7
Bases de datos
anterior adolece de este tipo de anomalía, pues si un miembro de la facultad deja

temporalmente de estar adscrito a algún curso, se deberá eliminar el último de los
registros en los que figura dicho miembro de la facultad, y también hay que eliminar al
miembro de la facultad, a menos que el campo código de curso esté establecido en nulo.
Este fenómeno se conoce como anomalía de eliminación.
Estas anomalías se explican de forma práctica en la siguiente subsección. Adicionalmente, la

normalización minimiza el rediseño al ampliar la estructura de la base de datos. Una base de
datos completamente normalizada permite que su estructura se extienda para adaptarse a
nuevos tipos de datos sin cambiar demasiado la estructura existente. Como resultado, las
aplicaciones que interactúan con la base de datos se ven mínimamente afectadas.
Razones para la normalización de la base de datos
Hay tres razones principales para normalizar una base de datos. El primero es minimizar los
datos duplicados, el segundo es minimizar o evitar problemas de modificación de datos y el
tercero es simplificar las consultas. A medida que avanzamos en los distintos estados de
normalización, analizaremos cómo cada formulario aborda estos problemas, pero, para
empezar, veamos algunos datos que no se han normalizado y analicemos algunos posibles
errores. Considere la siguiente tabla:
PersonalVenta
IDempleado Nombre Oficina Telefono Cliente1 Cliente2 Cliente3
1003 Mary Laz Chicago 312-555-1212 Ford GM
1004 John Hunt New York 121-555-1212 Dell HP Apple
1005 Martin Hu Chicago 312-555-1212 Boeing
Nota: La columna de la clave principal está subrayada.

Con esta tabla, se puede identificar lo siguiente:
▪ Identificar a los vendedores de la organización

▪ Listado de oficinas de ventas y números de teléfono
▪ Asociación de un vendedor con una oficina de ventas
▪ Mostrar los clientes de cada vendedor
8
Bases de datos
Anomalías de duplicación y modificación de datos
Observe que para cada Nombre hemos almacenado tanto Oficina como Telefono. Hay datos de
vendedores duplicados. La información duplicada presenta dos problemas:
▪ Aumenta el almacenamiento y reduce el rendimiento

▪ Se vuelve más difícil mantener los cambios de datos
Por ejemplo, considere si trasladamos la oficina de Chicago a Evanston, IL. Para reflejar esto
correctamente en nuestra tabla, necesitamos actualizar las entradas para todos los Nombres
actualmente en Chicago. Nuestra tabla es un pequeño ejemplo, pero puede ver si fuera más
grande, que potencialmente esto podría involucrar cientos de actualizaciones. Estas situaciones
son anomalías de modificación. La normalización de la base de datos los corrige. Hay tres
anomalías de modificación que pueden ocurrir:
1. Anomalía de inserción: Hay hechos que no podemos registrar hasta que sepamos la
información de toda la fila. En nuestro ejemplo, no podemos registrar una nueva oficina
de ventas hasta que también conozcamos al vendedor, porque para crear el registro
necesitamos proporcionar una clave primaria. En nuestro caso, este es el IDempleado.
PersonalVenta
¿? ¿? Atlanta 312-555-1212
En la siguiente tabla tenemos la misma información en varias filas. Por ejemplo, si cambia el
número de la oficina, es necesario realizar varias actualizaciones. Si no actualizamos todas las
filas, aparecerán inconsistencias.
PersonalVenta
9
Bases de datos
2. Anomalía de eliminación: La eliminación de una fila provoca la eliminación de más de

un conjunto de hechos. Por ejemplo, si John Hunt se jubila, eliminar esa fila hará que
perdamos información sobre la oficina de Nueva York.
PersonalVenta
1. La normalización de la base de datos ayuda con problemas de búsqueda y clasificación:

La última razón que consideraremos es facilitar la búsqueda y la clasificación de sus
datos. En la tabla PersonalVenta si desea buscar un cliente específico como Ford,
tendría que escribir una consulta como:
SELECT Oficina FROM PersonalVenta
WHERE Cliente1 = ‘Ford’ OR Cliente2 = ‘Ford’ OR Cliente3 = ‘Ford’
Claramente, si el cliente estuviera de alguna manera en una columna, esta consulta sería más
simple. Adicionalmente, para procesos de búsquedas y clasificación esta tabla hace estos
procesos complejos ya que deberían usarse consultas UNION independientes. Puede eliminar o
reducir estas anomalías separando los datos en diferentes tablas. Esto coloca los datos en tablas
con un solo propósito. El proceso para rediseñar la tabla es la normalización de la base de datos.
10
Bases de datos
Video: En el siguiente video se abordan conceptos adicionales de normalización
https://www.youtube.com/watch?v=bO18omSzeR4
4.1.3. El proceso de normalizació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 entidad-relación 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.
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 tabla 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.
 Definir en las relaciones las columnas de clave principal y las columnas sin clave.
Existen siete niveles de normalización, cada una de estas formas tiene sus propias reglas. Cuando
una base de datos se conforma a un nivel, se considera normalizada a esa forma de
normalización. No siempre es una buena idea tener una base de datos conformada en el nivel
más alto de normalización ya que puede llevar a un nivel de complejidad que pudiera ser evitado
si estuviera en un nivel más bajo de normalización.
3.2. TIPOS DE NORMALIZACIÓN
El inventor del modelo relacional Edgar Codd propuso la teoría de la normalización con la
introducción de la primera forma normal, y continuó extendiendo la teoría con la segunda y
tercera forma normal. Más tarde se unió a Raymond F. Boyce para desarrollar la teoría de la
forma normal de Boyce-Codd.
La normalización supone el uso de formas normales con respecto a la estructura de los datos
disponibles. Hay varias reglas de normalización. Cada una de ellas se denomina forma normal
11
Bases de datos
(FN). Cada una de estas formas, excepto la primera, supone que la forma normal anterior ya se
ha aplicado a los datos. Cuando se ejecuta la primera regla, la base de datos se representa en la
primera forma normal (1FN), y cuando se ejecutan las tres reglas se representa en la tercera
forma normal (3FN). La teoría de la normalización de datos en SQL aún se está desarrollando
más. Por ejemplo, hay discusiones incluso en la sexta forma normal. Sin embargo, en la mayoría
de las aplicaciones prácticas, la normalización alcanza su mejor nivel en la tercera forma normal.
La evolución de las teorías de la normalización se ilustra a continuación:
Figura 1. Evolución de las formas normales (FN).
La normalización es una técnica utilizada para diseñar tablas en las que las redundancias de
datos se reducen al mínimo. Las primeras tres formas normales (1FN, 2FN y 3FN) son las más
utilizadas. Desde un punto de vista estructural, las formas de mayor nivel son mejores que las
de menor nivel, porque aquellas producen relativamente pocas redundancias de datos en la
base de datos. En otras palabras, 3FN es mejor que 2FN y ésta, a su vez, es mejor que 1FN. Casi
todos los diseños de negocios utilizan la 3FN como forma ideal.
3.2.1. Primera forma normal, segunda forma normal, tercera forma

normal
Para normalizar una base de datos existen principalmente 3 reglas, las cuales se
deberían cumplir para evitar redundancias e incoherencias en las dependencias. A estas reglas
se les conoce como "Forma normal" qué va de la primera a la tercera y si la base de datos cumple
con cada regla se dice que está en la "primera o segunda o tercera forma normal".
La metodología para desarrollar la normalización hasta su tercera forma normal es la siguiente:

• Paso 1. Determinar claves candidatas
• Columna que identifique de forma única cada registro.
• Paso 2. Obtener determinantes
• Dependencias funcionales y transitorias
• Paso 3. Comprobación y solución de las condiciones FN.
• 1FN
1. Atributos (columnas) con valores atómicos, únicos o indivisibles
2. No debe existir grupos de columnas repetidos
12
Bases de datos
3. Nombres de atributos (columnas) únicos

• 2FN
1. Debe existir dependencia funcional entre columnas no claves y la clave
primaria
• 3FN
1. Todos los atributos no claves deben ser independientes del resto de
atributos no claves
1. Identifique las columnas que son dependentes de otra columna
no clave
2. Elimine columnas identificadas en la tabla base
3. Crear las relaciones entre la nueva tabla y la original
Primera forma normal (1FN)
Para que una tabla esté en la 1FN, debe seguir las siguientes reglas (Jiménez, 2019):
1. Solo debe tener atributos / columnas con un valor único (atómico, es decir indivisibles)
2. No deben existir grupos de valores repetidos
3. Identificar cada grupo de datos relacionados con una clave primaria
4. Todas las columnas de una tabla deben tener nombres únicos
Supongamos que hay en una tabla una columna Dirección para almacenar la dirección
completa, dato que se compone del nombre de la calle, el número exterior, el número interior
(puerta), el código postal, el estado y la capital.
Figura 2. Tabla con un atributo divisible en varias partes.
13
Bases de datos
Una tabla con esta estructura plantea problemas a la hora de recuperar información. Imagine
que necesita conocer todas las entradas correspondientes a una determinada población, o que
quiere buscar a partir del código postal. Al ser la dirección completa una secuencia de caracteres
de estructura libre no resultaría nada fácil. Existirán más columnas, pero cada una de ellas
contendrá un valor simple e indivisible que facilitará la realización de las operaciones antes
mencionadas.
En cuanto a la segunda indicación, se debe evitar la repetición de los datos de la población y

provincia en cada una de las filas. Siempre que al muestrear la información de una tabla
aparezcan datos repetidos, existe la posibilidad de crear una tabla independiente con ellos.
Si el diseño de nuestra base de datos cumple estas premisas, está preparada para pasar de la
primera a la segunda forma normal.
Figura 3. Aislamiento de los datos repetitivos de una tabla en otra independiente.
Tomemos otro ejemplo. Digamos que queremos crear una tabla con la información de usuarios,
y los datos a guardar son el nombre, la empresa, la dirección de la empresa y algún email, o URL
si las tienen.
14
Bases de datos
Figura 4. Tabla sin normalizar.
Digamos que la tabla de la Figura 4 está sin normalizar (formalización cero) porque ninguna de
las reglas de normalización ha sido aplicada. Observe los campos url1 y url2. ¿Qué haremos
cuando en nuestra aplicación necesitemos una tercera URL? Se podría añadir otra columna para
la tercera URL, pero no es funcional. Entonces podemos empezar a normalizar esta tabla.
En la tabla de la Figura 4 se está rompiendo la regla de que no deben existir valores repetidos
en los campos de url1 y url2. En relación con la identificación de datos con una clave primaria
tampoco se cumple en esa tabla original. Por eso se podría incluir un campo tipo contador auto-
incrementable para cada registro de tal forma que sería nuestra clave primaria.
Una vez que aplicamos la 1FN nos encontraríamos con la siguiente tabla:
Figura 5. Tabla en 1FN.
Ahora la tabla de la Figura 5 está en 1FN. Hemos solucionado el problema de la limitación del
campo URL. Sin embargo, vemos otros problemas: cada vez que introducimos un nuevo registro
en la tabla usuarios, tenemos que duplicar el nombre de la empresa y del usuario. No sólo la
base de datos crecerá mucho, sino que será fácil que la base de datos se corrompa si escribimos
mal alguno de los datos redundantes. Para este propósito, aplicaremos la 2FM.
Segunda forma normal (2FN)
Además de cumplir con las dos reglas del punto previo, la 2FN añade la necesidad de que no
existan dependencias funcionales parciales. Esto significa que todos los valores de las columnas
de una fila deben depender de la clave primaria de dicha fila, entendiendo por clave primaria
los valores de todas las columnas que la formen, en caso de ser más de una.
Las tablas que están ajustadas a la primera forma normal, y además disponen de una clave
primaria formada por una única columna con un valor indivisible, cumplen ya con la segunda
forma normal. Ésta afecta exclusivamente a las tablas en las que la clave primaria está formada
por los valores de dos o más columnas, debiendo asegurarse, en este caso, que todas las demás
15
Bases de datos
columnas son accesibles a través de la clave completa y nunca mediante una parte de esa clave.
En resumen, para cumplir con la 2FN es necesario cumplir estas condiciones:
 Crear tablas separadas para aquellos grupos de datos que se aplican a varios registros
 Relacionar estas tablas mediante una clave externa.
Siguiendo con el ejemplo anterior, hemos separado el campo URL en otra tabla, de
forma que podemos añadir más en el futuro si tener que duplicar los demás datos. También
vamos a usar nuestra clave primaria para relacionar estos campos:
Hemos creado tablas separadas y la clave primaria userId en la tabla usuarios está relacionada
ahora con la clave externa en la tabla urls, relUserId. Pero ¿qué ocurre cuando queremos añadir
otro empleado a la empresa ABC? ¿o 200 empleados? Tendríamos el nombre de la empresa y
su dirección duplicándose, lo que podría inducir a errores en los datos. Así que tendríamos que
aplicar la 3FN.
Tercera forma normal (3FN)
En cuanto a la tercera forma normal, ésta indica que se deben eliminar aquellos campos que no
dependan de la clave. Esto implica que no deben existir dependencias transitivas entre las
columnas de una tabla, lo cual significa que las columnas que no forman parte de la clave
primaria deben depender sólo de la clave, nunca de otra columna no clave.
En el caso del ejemplo anterior, el nombre de empresa y su dirección no tienen nada que ver
con el campo userId, así que debe tener su propio emprId:
16
Bases de datos
Ahora tenemos la clave primaria emprId en la tabla empresas relacionada con la clave externa
relEmpresaId en la tabla usuarios, y podemos añadir 200 usuarios mientras que sólo tenemos
que insertar el nombre 'ABC' una vez. Las tablas de usuarios y urls pueden crecer sin duplicación
ni corrupción de datos.
Excepción: Adherirse a la 3FN, aunque teóricamente deseable, no siempre es práctico. Si tiene

una tabla Clientes y desea eliminar todas las posibles dependencias entre campos, debe crear
tablas separadas para ciudades, códigos postales, representantes de ventas, clases de clientes y
cualquier otro factor que pueda estar duplicado en varios registros. En teoría, vale la pena
alcanzar la normalización. Sin embargo, muchas tablas pequeñas pueden degradar el
rendimiento o superar las capacidades de memoria y archivos abiertos. Puede ser más factible
aplicar la 3FN sólo a los datos que cambian con frecuencia. Si quedan algunos campos
dependientes, diseñe su aplicación para requerir que el usuario verifique todos los campos
relacionados cuando se cambie alguno.
Sabías que: Aunque son posibles otros niveles de normalización, la tercera forma
normal se considera el máximo nivel necesario para la mayoría de las aplicaciones.
17
Bases de datos
3.2.2. Las formas normales de orden superior: Forma normal de Boyce-Codd,

cuarta forma normal, quinta forma normal
Forma normal de Boyce-Codd (FNBC)
La FNBC es una variante de la 3FN. Una relación está en FNBC si cualquier atributo sólo facilita
información sobre claves candidatas y no sobre atributos que no formen parte de ninguna clave
candidata. No deben existir relaciones entre atributos fuera de las claves candidatas.
Figura 8. Tablas normalizadas en FNBC.
En el ejemplo presentado en la Figura 8, las columnas Licenciatura y Coordinador sólo

proporcionan información entre ellos y ninguno es clave candidata. Por esta razón, la
información se separa y se maneja en tablas diferentes.
Antes de definir la cuarta forma normal (4FN), veremos tres tipos de relaciones entre los datos:
uno a uno (1:1), uno a muchos (1:M) y muchos a muchos (M:N). Observe la tabla usuarios en la
Figura 5 del 1FN mostrada anteriormente. Por un momento imaginemos que ponemos el campo
url en una tabla separada y cada vez que introducimos un registro en la tabla usuarios también
introducimos una sola fila en la tabla urls. Entonces tendríamos una relación 1:1: cada fila en la
tabla usuarios tendría exactamente una fila correspondiente en la tabla urls. Para los propósitos
de nuestra aplicación no sería útil la normalización.
18
Bases de datos
Ahora, observe las tablas en el ejemplo del 2FN en la Figura 6. Estas tablas permiten a un solo
usuario tener asociadas varias urls. Esta es una relación 1:M, el tipo de relación más común hasta
que se presentó el dilema del Tercer Nivel de F/N. La relación M:N, sin embargo, es ligeramente
más compleja. Observe el ejemplo de la Figura 7 del 3FN en el que hay un usuario relacionado
con varias urls. Como dijimos, vamos a cambiar la estructura para permitir que varios usuarios
estén relacionados con varias urls y así existirá una relación M:N. Veamos como quedarían las
tablas antes de seguir con este planteamiento:
Figura 9. Tablas con relaciones M:N.
Para disminuir la duplicación de los datos (este proceso va a llevar al 4FN), se ha creado una
tabla que sólo tiene claves externas y primarias url_relations. Hemos sido capaces de remover
las entradas duplicadas en la tabla urls creando la tabla url_relations. Ahora podemos expresar
fielmente la relación que Joe y Jill tienen entre cada uno de ellos, y entre ambos, las urls. Así que
veamos exactamente lo que abarca el 4FN.
19
Bases de datos
Cuarta forma normal (4FN)
En las relaciones M:N, las entidades independientes no pueden ser almacenadas en la misma
tabla. Ya que sólo se aplica a las relaciones M:N, la mayoría de los desarrolladores pueden
ignorar esta regla de forma correcta. Pero es muy útil en ciertas situaciones, tal como la que se
expresó en el párrafo anterior. Se ha optimizado la tabla urls eliminado duplicados y se ha
puesto las relaciones en su propia tabla.
Una tabla está en 4NF si y solo si esta en 3FN o en BCNF (cualquiera de ambas) y no posee
dependencias multivaluadas no triviales. La definición de la 4NF confía en la noción de una
dependencia multivaluada. Una tabla con una dependencia multivaluada es una donde la
existencia de dos o más relaciones independientes M:M causa redundancia. Esta redundancia
es suprimida por la 4FN.
Quinta forma normal (5FN)
Existe otro nivel de normalización que se aplica a veces, pero en la mayoría de los casos no es
necesario para obtener la mejor funcionalidad de la estructura de datos o aplicación. Una
relación se encuentra en 5FN, o forma normal de Proyección-Unión, si se encuentra en 4FN y las
únicas dependencias que existen son las denominadas dependencias de Join de una tabla con
sus proyecciones, relacionándose entre sí mediante la clave primaria, o cualquier clave
alternativa.
El beneficio de aplicar la 5FN asegura que no se ha creado ninguna columna extraña en las tablas
y que la estructura de las tablas que se ha creado sea del tamaño justo que tiene que ser. Es una
buena práctica aplicar esta forma normal, pero se la suele utilizar cuando se trabajan con una
extensa estructura de datos. En ocasiones puede generar que se creen muchas tablas, lo que
complica el manejo de las tablas. La 5FN se aplica en forma de proyección para reducir la
complejidad de una tabla a través de la división de tablas una vez que se considera la unión de
las tablas.
20
Bases de datos
Figura 10. Tablas en 5FN.
3.2.3. Desnormalización
La desnormalización es una técnica de optimización de bases de datos en la que se agregan

datos redundantes a una o más tablas. Esto puede ayudarnos a evitar costosas uniones en una
base de datos relacional. Tenga en cuenta que la desnormalización no significa no realizar la
normalización. Es una técnica de optimización que se aplica después de realizar la normalización.
En una base de datos normalizada tradicional, almacenamos datos en tablas lógicas separadas
e intentamos minimizar los datos redundantes. Podemos esforzarnos por tener solo una copia
de cada pieza de datos en la base de datos. Por ejemplo, en una base de datos normalizada,
21
Bases de datos
podríamos tener una tabla Cursos y una tabla Profesores. Cada entrada en Cursos almacenaría
el ID del profesor para un curso, pero no el nombre del profesor. Cuando necesitamos recuperar
una lista de todos los cursos con el nombre del profesor, hacemos una combinación entre estas
dos tablas. De alguna manera, esto es bueno ya que, si un profesor cambia su nombre, sólo
tenemos que actualizar el nombre en un lugar. El inconveniente es que, si las tablas son grandes,
podemos pasar un tiempo innecesariamente largo haciendo uniones en las tablas.
La desnormalización alcanza un compromiso diferente. Bajo la desnormalización, decidimos

que estamos de acuerdo con algo de redundancia y un esfuerzo adicional para actualizar la base
de datos a fin de obtener las ventajas de eficiencia de un menor número de uniones. Entre las
ventajas de la desnormalización están
 La recuperación de datos es más rápida ya que hacemos menos uniones

 Las consultas para recuperar pueden ser más simples. Por lo tanto, es menos probable
que tengan errores ya que necesitamos mirar menos tablas.
Con respecto a las desventajas de la desnormalización observamos las siguientes:
 La desnormalización puede dificultar la escritura de la actualización y la inserción de

código
 Los datos pueden ser inconsistentes. ¿Cuál es el valor "correcto" para un dato?
 La redundancia de datos requiere más almacenamiento.
En un sistema que exige escalabilidad, como el de cualquier empresa de tecnología, casi siempre
usamos elementos de bases de datos tanto normalizadas como desnormalizadas.
¿En qué se diferencia la desnormalización de la normalización?
La desnormalización es diferente de la normalización de la siguiente manera:
 La desnormalización es una técnica que se utiliza para fusionar datos de varias tablas en
una sola tabla que se puede consultar rápidamente. La normalización, por otro lado, se
usa para eliminar datos redundantes de una base de datos y reemplazarlos con datos
confiables y no redundantes.
 La desnormalización se usa cuando las combinaciones son costosas y las consultas se
ejecutan regularmente en las tablas. La normalización, por otro lado, se usa
generalmente cuando se realiza una gran cantidad de operaciones de inserción,
actualización, eliminación, y las uniones entre esas tablas no son costosas.
22
Bases de datos
Lectura complementaria de la
asignatura:
• Teutli (2012)
• Mendoza & López (2018)
BIBLIOGRAFÍA:
Beynon-Davies, P. (2018). Sistemas de bases de datos. Reverté.
Elmasri, R., Navathe, S. B., Castillo, V. C., Pérez, G. Z., & Espiga, B. G. (2002). Fundamentos de
sistemas de bases de datos (Issue QA76. 9D3 E553 2007.). Addison-Wesley.
Jiménez, J. A. (2019). Buenas prácticas en el diseño de bases de datos. Arandu UTIC, 6(1), 193–
210.
Mendoza, A., & López, R. (2018). Bases de datos.
Teutli, J. (2012). Base de datos.
Valverde-González, V. L., Paredes-Castelo, L. E., & Hidalgo-Solórzano, G. X. (2021). Propuesta
metodológica para la elaboración de una base de datos a partir del modelo relacional.
Polo Del Conocimiento, 6(1), 536–548.
23

BDP Compendio Unidad 1 Tema 3 2022 2

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

BDP Compendio Unidad 1 Tema 3 2022 2

Cargado por

Copyright:

Formatos disponibles

BASES DE DATOS

Tabla de contenido ........................................................................................................... 2

La presente imagen dentro del manual mostrará

La presente imagen dentro del manual permite recordar

Es un cuestionario de un conjunto de preguntas que se

Para complementar contenidos de la unidad dentro del

La presente imagen en el manual mostrará información que

La presente imagen en el manual mostrará información que

ORGANIZACIÓN DE LA LECTURA PARA EL ESTUDIANTE

De la asignatura de Base de datos

El estudiante al finalizar el curso estará en capacidad para ser parte de un equipo de

Unidad 1. Diseño de bases de datos

Tema 2: Diseñar esquemas conceptuales, utilizando el modelado entidad-relación, de sistemas

3.1. INTRODUCCIÓN A LA NORMALIZACIÓN

La normalización de la base de datos es el proceso de estructurar una base de datos,

La normalización implica organizar las columnas (atributos) y las tablas (relaciones) de

3.1.1. Nociones básicas

La normalización es el proceso de organizar datos en una base de datos. La normalización es

Los datos redundantes desperdician espacio en disco y crean problemas de mantenimiento. Si

Los objetivos de normalización fueron establecidos por Codd de la siguiente manera:

 Para liberar la colección de relaciones de dependencias de inserción, actualización y

3.1.2. La necesidad de normalización

▪ Anomalía de actualización: La misma información se puede expresar en varias filas, por

anterior adolece de este tipo de anomalía, pues si un miembro de la facultad deja

Estas anomalías se explican de forma práctica en la siguiente subsección. Adicionalmente, la

Razones para la normalización de la base de datos

IDempleado Nombre Oficina Telefono Cliente1 Cliente2 Cliente3

1003 Mary Laz Chicago 312-555-1212 Ford GM

1004 John Hunt New York 121-555-1212 Dell HP Apple

1005 Martin Hu Chicago 312-555-1212 Boeing

Nota: La columna de la clave principal está subrayada.

▪ Identificar a los vendedores de la organización

Anomalías de duplicación y modificación de datos

▪ Aumenta el almacenamiento y reduce el rendimiento

IDempleado Nombre Oficina Telefono Cliente1 Cliente2 Cliente3

1003 Mary Laz Chicago 312-555-1212 Ford GM

1004 John Hunt New York 121-555-1212 Dell HP Apple

1005 Martin Hu Chicago 312-555-1212 Boeing

IDempleado Nombre Oficina Telefono Cliente1 Cliente2 Cliente3

1003 Mary Laz Chicago 312-555-1212 Ford GM

1004 John Hunt New York 121-555-1212 Dell HP Apple

1005 Martin Hu Chicago 312-555-1212 Boeing

2. Anomalía de eliminación: La eliminación de una fila provoca la eliminación de más de

IDempleado Nombre Oficina Telefono Cliente1 Cliente2 Cliente3

1003 Mary Laz Chicago 312-555-1212 Ford GM

1004 John Hunt New York 121-555-1212 Dell HP Apple

1005 Martin Hu Chicago 312-555-1212 Boeing

1. La normalización de la base de datos ayuda con problemas de búsqueda y clasificación:

SELECT Oficina FROM PersonalVenta

WHERE Cliente1 = ‘Ford’ OR Cliente2 = ‘Ford’ OR Cliente3 = ‘Ford’

Video: En el siguiente video se abordan conceptos adicionales de normalización

4.1.3. El proceso de normalización

 Evitar la redundancia de los datos

 Cada tabla debe tener su nombre único.

3.2. TIPOS DE NORMALIZACIÓN

Figura 1. Evolución de las formas normales (FN).

3.2.1. Primera forma normal, segunda forma normal, tercera forma

La metodología para desarrollar la normalización hasta su tercera forma normal es la siguiente:

3. Nombres de atributos (columnas) únicos

Primera forma normal (1FN)

Figura 2. Tabla con un atributo divisible en varias partes.

En cuanto a la segunda indicación, se debe evitar la repetición de los datos de la población y

Figura 3. Aislamiento de los datos repetitivos de una tabla en otra independiente.

Figura 4. Tabla sin normalizar.