TECNOLÓGICO NACIONAL DE MEXICO

INSTITUTO TECNOLOGICO DE POCHUTLA

NOMBRE: Angel Emmanuel García Becerra.

Núm. Control: 181160153.

SEMESTRE: 4°

CARRERA: Ing. En Sistemas Computacionales.

DOCENTE: Ing. Miguel Morgan Matus.

MATERIA: Fundamentos de Base de Datos.

ACTIVIDAD: NBD-01-Reporte de Investigación

Contenido
Introducción. ........................................................................................................................... 3
¿Qué es la normalización de base de datos? ........................................................................... 4
Formas Normales.................................................................................................................... 6
Reglas de Codd ..................................................................................................................... 11
Desnormalización ................................................................................................................. 14
Conclusión. ........................................................................................................................... 17
Bibliografía ........................................................................................................................... 18
Introducción.
En este tema vamos a observar las formas de normalización, las cuales generalmente son
utilizadas en el análisis, desarrollo e implementación de sistemas de bases de datos.

Estos nos sirven para mejorar el desempeño de una base de datos, así como también evitar la
redundancia en la información que contiene y, en consecuencia, poder generar condiciones
para así tener un mejor diseño.
¿Qué es la normalización de base de datos?

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

creación de tablas y el establecimiento de relaciones entre esas tablas de acuerdo con las
reglas diseñadas tanto para proteger los datos como para que la base de datos sea más flexible
mediante la eliminación de la redundancia y la dependencia incoherente.

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

Si es necesario cambiar los datos que se encuentran en más de un lugar, los datos deben
cambiarse exactamente de la misma forma en todas las ubicaciones. El cambio de dirección
de un cliente es mucho más fácil de implementar si los datos se almacenan solo en la tabla
clientes y en ninguna otra parte de la base de datos.

¿Por qué se normalizan?

Las bases de datos relacionales se normalizan para:

• Evitar la redundancia de los datos.

• Disminuir problemas de actualización de los datos en las tablas.
• 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.
• Prevenir borrados indeseados de datos.

¿Cuáles son los beneficios de la normalización?

• Nos permite representar un conjunto de datos complejos en estructuras más simples

y estables.
• Asegura de que los atributos se ubiquen apropiadamente a la entidad a la que
pertenecen y que estén en un solo lugar, con un solo nombre y con un solo valor a la
vez.
• Simplifica la lógica de la base de datos.
• Facilita la estandarización, lectura y entendimiento de las bases de datos.
• Reduce el consumo de espacio.
 • Optimiza la ejecución de las consultas.
• Reduce la redundancia de datos.
• Facilita el mantenimiento de la base de datos y de las aplicaciones.
• Protege la integridad de los datos.
• Facilita el diseño de consultas.
• Aumenta el número de usuarios concurrentes que la base de datos puede soportar.

Objetivos generales.

A Nivel Base:

• Elimina la repetición de grupos.

• Minimizar redundancia.
• Facilitar el mantenimiento de la base de datos.
• Optimizar el rendimiento de la base.

A Nivel Tabla:

• Cada tabla debe representar sólo un tipo de entidad (como una persona, un lugar, un
pedido de cliente o un producto).
• Eliminar repetición de columnas.
• Definir una clave primaria por tabla.
• Eliminar el uso de claves compuestas.
• Separar los campos que no sean de esa tabla y/o clave primaria y ubicarlos en la
tabla/entidad correcta.
• Crear una nueva tabla para mover la repetición de grupos de la tabla original.
(generación de catálogos)
• Cada registro debe de tener una clave primaria única e irrepetible.

A Nivel Campo:

• Todos los campos deben depender de la clave primaria, ya sea directamente o

indirectamente.
• Cada campo debe de representar un hecho de la clave primaria y nada más.
• Eliminar dependencias de los campos a claves no primarias.
 • Todos los campos deben contener un único valor.
• Todos los valores de cada campo debe tener el mismo tipo de dato.

¿Cuáles son los requisitos de la normalización?

Para que las tablas de nuestra BD estén normalizadas deben cumplir las siguientes reglas:

• 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.

Formas Normales.

Existen 5 formas de normalización (FN: Forma normal)

I. 1FN: Eliminar grupos repetitivos

II. 2FN: Eliminar datos redundantes
III. 3FN: Eliminar columnas no depende de clave
IV. 4FN: Aislar Relaciones Múltiples Independientes
V. 5FN: Aislar relaciones semánticamente relacionadas múltiples

Primera Forma Normal (1FN)

La primera forma normal significa que los datos están en un formato de entidad, lo que
significa que se han cumplido las siguientes condiciones:
 • Eliminar grupos repetidos en tablas individuales
• Crear una tabla independiente para cada conjunto de datos relacionados
• Identificar cada conjunto de relacionados con la clave principal

No utilice varios campos en una sola tabla para almacenar datos similares

Ejemplo de Normalización

En el ejemplo tenemos una tabla No Normalizada que contiene Estudiantes, Tutor,

Habitación y las Clases 1,2 y 3. Vamos a implementar la primera forma normal, luego la
segunda y la tercera. Al aplicarle la primera forma normal eliminamos los grupos repetidos
quedándonos con una sola columna de clases y repitiendo los datos del estudiante tutor y
habitación y ahora no tenemos grupos repetidos porque aplicamos la primera forma normal
(1FN).

Segunda Forma Normal (2FN)

La segunda forma normal asegura que cada atributo describe la entidad

Crear tablas separadas para el conjunto de valores y los registros múltiples, estas tablas se
deben relacionar con una clave externa.

Los registros no deben depender de otra cosa que la clave principal de la tabla, incluida la
clave compuesta si es necesario
Al pasar a la segunda forma normal vamos a eliminar los datos redundantes, y para lograrlo
vamos a crear dos tablas. Una tabla se llamará Estudiantes donde eliminaremos los datos
redundantes quedándonos con los datos únicos (Estudiante, Tutor y Habitación) y en una
segunda tabla que llamaremos Registro para el numero de estudiante y las clases que llevará
en el ejemplo el estudiante 1606 y 2602 llevará cada uno tres clases. El contenido de la (1FN)
Primera Forma Normal que estaba en una tabla ha sido divido en dos tablas para eliminar los
datos redundantes e introducirlo a la (2FN) Segunda Forma Normal.

Tercera forma normal (3FN)

La tercera forma normal comprueba las dependencias transitivas, eliminando campos que
no dependen de la clave principal.

Los valores que no dependen de la clave principal no pertenecen a la tabla

Los campos que no pertenecen a la clave principal colóquelos en una tabla aparte y relacionen
ambas tablas por medio de una clave externa.
Para pasar a la tercera forma normal tenemos que eliminar los campos de No Dependen de
la Clave y para lograrlo dividimos la tabla estudiante en dos tablas y creamos la tabla Facultad
donde trasladaremos la columna habitación que No Depende de la Clave que es la columna
estudiante, el nombre del tutor será el enlace con la tabla estudiante aunque también podría
ser la columna estudiante.

Otras formas de normalización

La cuarta forma normal también se llama la forma normal de Boyce Codd (BCNF) y la quinta
forma normal existe, pero rara vez se consideran en el diseño práctico.

El no tener en cuenta estas dos reglas de normalización adicionales puede resultar en un

diseño de base de datos menos perfecto pero no debería afectar a la funcionalidad

La normalización de base de datos es un punto muy importante que deberíamos de tomar

muy en serio para establecer cimientos sólidos sobre los cuales podemos construir
aplicaciones robustas que en el futuro no presenten problemas de base de datos difíciles de
solucionar.

Anomalías que se resuelven.

1FN:

• Solo debe de existir un solo valor atómico (indivisible) por columna, el cual hay que
evitar que sea nulo(null).
• No se deben almacenar campos calculados (como el promedio).
2FN:

• La base de datos debe de estar normalizada a la forma 1FN.

• Cada registro debe depender de la clave primaria de la tabla a la que pertenece.
• Cada clave primaria debe determinar una solo ocurrencia para cada registro.
Normalmente un entero autoincrementar hace el trabajo aquí.

3FN:

• La base de datos debe de estar normalizada a la forma 2FN.

• Generar catálogos (relaciones uno a muchos). Cada columna se debe de separar y
colocar en su respectiva tabla.
• Cada campo debe de representar un hecho acerca de la llave primaria y nada más.
• Los atributos que no sean clave única y que dependan de otra tabla deberán ser llaves
foráneas que hagan referencia a las llaves primarias de la tabla a la que pertenecen.
• No almacenar valores calculados como por ejemplo un promedio.

4FN:

• La base de datos debe de estar normalizada a la forma 3FN.

• Generación de tablas muchos a muchos. Esto para resolver las dependencias
multivaluadas.

5FN:

• La base de datos debe de estar normalizada a la forma 4FN.

• Generación de tablas muchos a muchos, pero usando únicamente llaves foráneas.
Reglas de Codd

Codd se dio de cuenta que existían bases de datos en el mercado las cuales decían ser
relacionales, pero lo único que hacían era guardar la información en las tablas, sin estas tablas
estar literalmente normalizadas; entonces éste publicó 12 reglas que un verdadero sistema
relacional debería de tener, en la práctica algunas de ellas son difíciles de realizar. Un sistema
podrá considerarse "más relacional" cuanto más siga estas reglas.

Regla No. 1 - La Regla de la información

Toda la información en un RDBMS está explícitamente representada de una sola manera por
valores en una tabla. Cualquier cosa que no exista en una tabla no existe del todo.

Toda la información, incluyendo nombres de tablas, nombres de vistas, nombres de

columnas, y los datos de las columnas deben estar almacenados en tablas dentro de las bases
de datos. Las tablas que contienen tal información constituyen el Diccionario de Datos.

Regla No. 2 - La regla del acceso garantizado

Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que combine el
nombre de la tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado el
nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por esta razón
la definición de claves primarias para todas las tablas es prácticamente obligatoria.

Regla No. 3 - Tratamiento sistemático de los valores nulo s

La información inaplicable o faltante puede ser representada a través de valores nulos.

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de soportar el
uso de valores nulos en el lugar de columnas cuyos valores sean desconocidos o inaplicables.
Regla No. 4 - La regla de la descripción de la base de dato s

La descripción de la base de datos es almacenada de la misma manera que los datos

ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios autorizados.

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc., debe ser
almacenada exactamente de la misma manera: En tablas. Estas tablas deben ser accesibles
igual que todas las tablas, a través de sentencias de SQL.

Regla No. 5 - La regla del sub lenguaje Integral

Debe haber al menos un lenguaje que sea integral para soportar la definición de datos,
manipulación de datos, definición de vistas, restricciones de integridad, y control de
autorizaciones y transacciones.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida que
pueda ser usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualización de vistas

Todas las vistas que son teóricamente actualizables, deben ser actualizables por el sistema
mismo.

La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los intentos
de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

La capacidad de manejar una base de datos con operandos simples aplica no solo para la
recuperación o consulta de datos, sino también para la inserción, actualización y borrado de
datos.

Esto significa que las cláusulas SELECT, UPDATE, DELETE e INSERT deben estar
disponibles y operables sobre los registros, independientemente del tipo de relaciones y
restricciones que haya entre las tablas.
Regla No. 8 - La regla de independencia física

El acceso de usuarios a la base de datos a través de terminales o programas de aplicación,

debe permanecer consistente lógicamente cuando quiera que haya cambios en los datos
almacenados, o sean cambiados los métodos de acceso a los datos.

El comportamiento de los programas de aplicación y de la actividad de usuarios vía

terminales debería ser predecible basados en la definición lógica de la base de datos, y este
comportamiento debería permanecer inalterado, independientemente de los cambios en la
definición física de ésta.

Regla No. 9 - La regla de independencia lógica

Los programas de aplicación y las actividades de acceso por terminal deben permanecer
lógicamente inalteradas cuando quiera que se hagan cambios (según los permisos asignados)
en las tablas de la base de datos.

La independencia lógica de los datos especifica que los programas de aplicación y las
actividades de terminal deben ser independientes de la estructura lógica, por lo tanto los
cambios en la estructura lógica no deben alterar o modificar estos programas de aplicación.

Regla No. 10 - La regla de la independencia de la integrida d

Todas las restricciones de integridad deben ser definibles en los datos, y almacenables en el
catálogo, no en el programa de aplicación.

Las reglas de integridad son:

• Ningún componente de una clave primaria puede tener valores en blanco o nulos.
(esta es la norma básica de integridad).
• Para cada valor de clave foránea deberá existir un valor de clave primaria
concordante. La combinación de estas reglas aseguran que haya Integridad
referencial.
Regla No. 11 - La regla de la distribución

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos esté
distribuida físicamente en distintos lugares sin que esto afecte o altere a los programas de
aplicación.

El soporte para bases de datos distribuidas significa que una colección arbitraria de
relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos sistemas
operativos y que esté conectada por una variedad de redes, pueda funcionar como si estuviera
disponible como una única base de datos en una sola máquina.

Regla No. 12 - Regla de la no-subversión

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera pueden ser
usados para violar la integridad de las reglas y restricciones expresadas en un lenguaje de
alto nivel (como SQL).

Algunos productos solamente construyen una interfaz relacional para sus bases de datos No
relacionales, lo que hace posible la subversión (violación) de las restricciones de integridad.
Esto no debe ser permitido.

Desnormalización

Las reglas de normalización no consideran el rendimiento. En algunos casos es necesario

considerar la desnormalización para mejorar el rendimiento. La desnormalización es la
duplicación intencionada de columnas en varias tablas, lo cual aumenta la redundancia de
datos.

La normalización crea más tablas al avanzar hacia formas normales más altas, sin embargo,
a mayor número de tablas, mayor número de combinaciones al recuperar los datos; lo que
contribuye a la ralentización de las consultas. Por esta razón, para mejorar la velocidad de
determinadas consultas, se pueden anular las ventajas de la integridad de datos y devolver la
estructura de los datos a una forma normal inferior.
Adicionalmente, Coronel, Morris y Rob (2011), al referir al proceso de desnormalización,
señalan que la unión de muchas tablas requiere operaciones de entrada/salida (I/O) y lógica
de procesamiento adicional en el disco, con lo que se reduce la velocidad del sistema. Por lo
tanto, pueden existir circunstancias fortuitas que permitan algún grado de desnormalización
para incrementar la velocidad de procesamiento. Debemos tomar en cuenta que la ventaja de
una mayor velocidad de procesamiento debe evaluarse cuidadosamente contra la desventaja
de datos anómalos.
Conclusión.
Podemos observar que la normalización es una técnica utilizada para el diseño de tablas en
las que las redundancias de los datos se reducen al mínimo.

Todo esto es muy importante para poder realizar y editar correctamente una base de datos,
esto es debido a que si no se toma en cuenta esto, nuestra base de datos presentaría muchos
errores y tendría un pésimo funcionamiento.
Bibliografía
Anonimo. (s.f.). EcuRed. Obtenido de
https://www.ecured.cu/Normalizaci%C3%B3n_de_una_base_de_datos
CVVA WEBLOG. (s.f.). Obtenido de
https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-
formas-normales/
EDteam. (s.f.). Obtenido de https://ed.team/blog/normalizacion-de-bases-de-datos
Microsoft. (s.f.). Obtenido de https://docs.microsoft.com/es-
es/office/troubleshoot/access/database-normalization-description
Normalización de Bases de Datos. (s.f.). Obtenido de
https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/872/mod_reso
urce/content/1/contenido/index.html
Sarmiento, M. (s.f.). Obtenido de
http://www.marcossarmiento.com/2017/06/28/normalizacion-de-base-de-datos/
VIDELCLOUD. (s.f.). Obtenido de https://videlcloud.wordpress.com/2017/01/06/las-
reglas-de-normalizacion-explicadas-facilmente/