SERVICIO NACIONAL DE APRENDIZAJE SENA

ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES

DE DATOS
AA9-Ev3-Normalización de Bases de Datos

AA9-Ev3-Normalización de Bases de Datos

Estudiante
Ing. Jesús Antonio Londoño Muñoz

Fecha
10/Octubre/2019

Docente
Ing. Alonso Rafael Ocampo Arrieta

Sena - Bogotá D.C.

2019
 SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AA9-Ev3-Normalización de Bases de Datos

Las tablas son objetos que almacenan la información de una entidad especifica; dichas tablas están
compuestas por Filas y Columnas, donde en las columnas se encuentran las propiedades de la entidad
como, por ejemplo: la base de datos de la secretaria de salud de la alcaldía de san Antonio, se va
tomar la tabla “Persona” y está compuesta por los siguientes campos o columnas:
• IdPersona
• Tipoidentificacion
• Nombre
• Apellido
• FechaNacimiento
• Sexo
y las filas hacen referencia a la información por cada persona de la secretaria de salud, como, por
ejemplo:

idPersona tipoidentificacion nombre apellido fechaNacimiento sexo

250025 4 LIZET GORDO 23/06/2000 F
250344 4 KELLY REINO 23/05/2000 F
1082019 1 MIGUEL PEREZ 9/02/1934 M

En este caso tenemos tres personas con sus respectivos datos o atributos.

Como norma general se suele imponer que cada tabla, almacena información común sobre una
entidad en particular. Esta norma se conoce como normalización. La mayor parte de la actividad
producida en una base de datos se produce sobre las tablas, acreditando como principales acciones
el CRUD
 Create
 Read
 Update
 Delete
Lo que significa que realiza las siguientes operaciones Insertar información, leer información,
actualizar información y eliminar la información.
Comúnmente estas cuatro operaciones se realizan mediante el lenguaje SQL (Structured Query
Language) y procedimientos almacenados, como estándar se suele usar la siguiente nomenclatura:
 SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AA9-Ev3-Normalización de Bases de Datos

SPR_GET_PERSONA (Trae los registros de persona)

SPR_INS_PERSONA (Inserta un registro de persona)
SPR_UPD_PERSONA (Actualiza un registro de una persona)
SPR_DEL_PERSONA (Elimina un registro de una persona)

Después de analizado el problema que se quiere resolver y que se ha esbozado un primer Diagrama
Entidad-Relaciòn, se debe continuar aplicando el proceso de Normalización, el cual dará como
resultado una modificación en el número de entidades o tablas, de tal manera que puede aumentar el
número de tablas, pero disminuir la cantidad de información que almacena en cada una. Este proceso
de normalización es de vital importancia.
La normalización es el mecanismo mediante el cual se toman decisiones con el fin de recoger de la
manera más adecuada todos los datos que se almacenarán en una base de datos y distribuirlos en
tablas.
Las formas normales son aplicadas a las tablas de una base de datos. Decir que una base de datos
está en la forma normal N es decir que todas sus tablas están en la forma normal N.
En general, las primeras tres formas normales son el mínimo que deben cubrir la mayoría de las bases
de datos. El creador de estas 3 primeras formas normales (o reglas) fue Edgar F. Coddt
Para tomar estas decisiones se cuenta con un número de formas normales que ayudarán a diseñar la
mejor estructura lógica con el mayor rendimiento posible. Las formas normales, son los modelos o
maneras en que se pueden representar la estructura de tablas. Gracias a estos modelos
conseguiremos mayor eficacia. Pero no se debe entender por eficacia como una reducción del tamaño,
nos estamos refiriendo a que se obtendrá una estructura muy bien organizada, de tal modo que será
escalable fácilmente, permitiendo realizar modificaciones en un futuro sin muchos ni mayores
problemas. Aunque habrá veces donde gracias a la normalización también se reduzca el tamaño, este
no es el objetivo que se busca.
La función de la normalización es favorecer la integridad de los datos. Trata de evitar lo máximo posible
la posibilidad de introducir datos que no sean razonables.
Dentro del proceso de normalización se distinguen tres tipos de integridades:
• Integridad de entidad.
• Integridad de dominio.
• Integridad referencial.
 SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AA9-Ev3-Normalización de Bases de Datos

La integridad de entidad pretende que cada entidad que se guarda en la base de datos sea identificable
de un modo único, es decir, que evitemos la información redundante. La integridad de entidad define
una fila o registro como una única ocurrencia para una tabla en particular. La integridad de entidad
asegura la integridad de la columna de identificación o la clave primaria de una tabla (a través de
índices, restricciones UNIQUE, restricciones PRIMARY KEY, o propiedades IDENTITY).
Con la integridad de dominio conseguimos controlar la información que guardamos en cada uno de
los campos que conforman las tablas de la base de datos, La integridad de dominio es la validación
de las entradas en un determinado campo. Como dominio, se entiende el conjunto de posibles valores
lógicos y legales que un dato puede almacenar en un determinado campo de una tabla. A mayor
número de limitaciones, mejor aseguraremos el correcto funcionamiento de nuestra base de datos.
Estas normas o reglas de integridad de dominio pueden indicar que campos son necesarios tener
obligatoriamente con valores (no se pueden dejar vacíos, NULL) para que la base de datos no tenga
datos sin conectar en el caso de tener relaciones o dependencias entre tablas.
Las herramientas que nos ofrece SQL Server para asegurar la integridad de dominio son: los Tipos de
datos, la restricción CHECK, la definición DEFAULT, las claves foráneas (FOREIGN KEY) y las
definiciones NOT NULL. La integridad referencial preserva las relaciones definidas entre tablas,
cuando se entran, modifican o borran registros. En SQL Server, la integridad referencial está basada
en interrelaciones entre claves ajenas y claves primarias o entre claves ajenas y claves únicas (a
través de las restricciones FOREIGN KEY y CHECK). La integridad referencial asegura que los valores
de las claves son consistentes a través de distintas tablas. Tal consistencia requiere que no existan
referencias a valores inexistentes.
Con esta integridad limitaremos la actividad que puede realizar un usuario sobre la base de datos.
Cuando se fuerza la integridad referencial, SQL Server previene a los usuarios de realizar lo siguiente:
• Agregar registros a una tabla relacionada si no hay registros asociados en la correspondiente
tabla primaria.
• Cambiar valores en la tabla primaria que resulten en registros huérfanos en las tablas
relacionadas.
• Borrar registros desde una tabla primaria si existen registros relacionados en la tabla ajena.
Por lo tanto, lo que debemos comprender de la integridad referencial es que existen relaciones entre
tablas que deben permanecer invariables sea cual sea la actividad sobre ellas.
Para mantener esta integridad SQL Server nos ofrece:
• Restricciones FOREIGN KEY.
• Restricciones CHECK.
• Desencadenadores y procedimientos almacenados
 SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AA9-Ev3-Normalización de Bases de Datos

Formas de normalización
Las formas normales definen una serie de normas o reglas que ayudan a organizar los datos en la
estructura lógica de una base de datos.
Cada una de las formas heredan las reglas de su antecesora, así la forma normal C, incluye las reglas
de las formas A y B.
Para entender desde un sentido práctico los diferentes modos de normalización, vamos a tomar como
ejemplo la base de datos de un Hospital.

Idmedico Nombre_Especialidad Mas Fem Dirección Tel 1 Tel 2 Tel 3 Turno

73895736 Agustín Cabezas T F Cra 10 No 6c - 28 3553355 23/04/2010
(Médico General)
902790497-1 Natalia Peláez F T Cll 26 No 69 - 78 4634673 23457544 3654464 24/04/2010
(Urólogo)
902790497-2 Natalia Peláez F T Cll 26 No 69 - 78 7744324 23/04/2010
(Urólogo)
64258397 Concepción Segura F T Diag 63 No 15 -34 2357435 4663576 25/04/2010
(Neurólogo)

Se debe tener claro que esta tabla contiene los datos sin ser normalizados, si bien son los datos que
se van a almacenar. Vamos a basarnos en esta tabla para ver cómo aplicar sobre ella el proceso de
normalización.
Primera Forma Normal.
Las normas que se deben aplicar en la primera forma normal son muy básicas y sencillas.
Regla: Cada uno de los campos de la tabla solo puede almacenar un tipo de datos, y además cada
dato se debe almacenar por separado, es decir individualmente.

Para entender mejor el significado de esta regla, vamos a explicar cómo se podría solucionar. En la
tabla “MEDICOS”, se observa que se están guardando los datos del nombre del médico y su
especialidad en un solo campo. De este modo no se está cumpliendo la norma, ya que estamos
guardando información de diferentes características en un único campo.
Otra manera de no cumplir la primera forma normal es la repetición de un campo (teléfonos). Esta
técnica es muy común en administradores que se están iniciando en el desarrollo de bases de datos.
 SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AA9-Ev3-Normalización de Bases de Datos

Este tipo de soluciones provoca bastantes problemas, el principal causante de estos problemas es la
poca flexibilidad que nos ofrece esta estructura. La tabla dejará de cumplir con las necesidades en el
momento en que un médico solicite que se almacenen más de tres teléfonos que además no se
distingue si son fijos, celulares o empresariales.
Por lo tanto, esta estructura lejos de ser sencilla es muy compleja, es imposible definir en un principio
los diferentes tipos de números telefónicos que debemos controlar. Ahora, se puede pensar, que se
van a poner suficientes campos de modo que nuestras necesidades nunca superen ese número de
campos. Como ya se supondrá, tomar este tipo de soluciones es un error enorme. Estaremos
reservando memoria sin ninguna necesidad, muchas personas solo tendrán un teléfono y tendremos
campos vacíos que resultarán completamente inútiles. Para solucionar el problema que hemos
planteado como ejemplo, tenemos varias soluciones, como almacenar la misma persona en diferentes
registros de la tabla. Esta es una solución válida, pero muy poco o nada eficaz desde el punto de vista
del rendimiento.
La solución es determinar cuáles son los números telefónicos importantes para el hospital y determinar
para ellos el nombre más adecuado (Residencia, Celular, etc) y limitarlo solo a dos o máximo tres
teléfonos por persona.
Para solucionar el problema de almacenar el nombre con la especialidad del médico, es adicionando
un campo “Especialidad” y si llegaran a ser varias las especialidades de un mismo médico, se
solucionaría, sacando "fuera" una tabla con las especialidades llamada “MEDICOS-ESPEC” por
ejemplo y utilizar la integridad referencial para relacionarla con la tabla “MEDICOS” e idealmente, crear
una tabla adicional llamada “ESPECIALIDADES”. Con esta solución se hace una especialización de
la base de datos.
La tabla que hemos presentado al principio podemos decir que NO cumple la primera forma normal.
Si se tiene por ejemplo una tabla donde se almacene la placa de un vehículo registrado en Colombia,
alguien podría pensar que como la placa consta de tres caracteres alfabéticos y tres numéricos, divide
ese campo en dos con diferentes tipos de datos y los muestra como si fueran uno solo en las consultas
SQL mediante la sentencia SELECT. Lo que debe hacer es almacenarlo en un solo campo llamado
“Placa” con tipo de dato “CHAR” y longitud “6” haciendo la restricción CHECK que permita el
almacenamiento correcto de los seis caracteres.
Segunda Forma Normal.
La primera condición que debemos cumplir en esta forma normal, es que se cumplan las reglas fijadas
en la primera forma normal. La principal regla de esta segunda norma es: Cada tabla sólo puede
almacenar información de una única entidad.
 SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AA9-Ev3-Normalización de Bases de Datos

Se va a entender mejor esta condición, explicando cómo quebrantarla. En la base de datos, se puede
tener entre otras entidades los MEDICOS y el PERSONAL ADMINISTRATIVO. Para ambas entidades
se almacenan prácticamente los mismos datos:
Idmedico Nombre_Especialidad Mas Fem Dirección Tel 1 Tel 2 Tel 3 Turno

El primer error que suelen cometer muchos diseñadores de la base de datos es decidir que todo el
personal puede ser almacenado en una misma tabla. Esta decisión errónea la tomamos por el hecho
de que ambas entidades comparten muchos de los campos.
Esta decisión incumple la regla de la segunda forma normal que exige tener los datos en entidades
separadas a no ser que se incluya un campo que distinga claramente cada tipo de persona dentro del
Hospital y esa distinción puede hacerse mediante el campo “Cargo” lo que nos lleva a tener que crear
otra entidad llamada “CARGOS” y conformada por un código y una descripción.
Esta regla también aplica para casos como CLIENTES y PROVEEDORES que comparten
exactamente los mismos datos, pero mediante algún identificador puede saber quién es un cliente y
quién es un proveedor. En la tabla del ejemplo, además se está cometiendo otro error a la segunda
forma normal porque se están almacenando datos que nada tienen que ver con el resto (campo
“Turno”) dicho dato amerita que se cree una tabla llamada “TURNOS” donde se relacione el “idmedico”
con los días que va a atender y así ese campo desaparece de la tabla entre otras cosas porque una
persona puede tener varios turnos durante una misma semana.
Un caso más de incumplimiento a esta regla es cuando se incluye por ejemplo el nombre del cliente
y/o su dirección en los campos de la factura. Serían redundancias que llevarían a errores futuros por
la repetición innecesaria de datos.
Tercera Forma Normal
Para cumplir con la tercera forma normal se debe cumplir la segunda forma normal y la siguiente regla:
Todos los campos que no contengan una clave están obligados a depender de forma directa con la
clave principal (Dependencia funcional).
La definición de esta regla puede parecer complicada, pero es tan sencilla como las dos anteriores y
se explica en dos formas, la primera es que en una tabla no deben existir campos calculados pues a
ellos se puede llegar en las consultas mediante cualquier operación matemática; y la segunda, es que
los campos que formen las tablas deben describir completamente el contenido de las mismas, por ello
el campo “turno” quebrante esta norma pues hace parte de otra tabla diferente a MEDICOS. De otro
lado, las tablas no deben tener ningún campo que sea irrelevante, o sea, que no de valor a la misma,
como podría ser que en la tabla MEDICOS se almacenara el nombre de los padres de cada médico.
Ese dato no aportaría valor en ningún aspecto a la base de datos.
 SERVICIO NACIONAL DE APRENDIZAJE SENA
ESPECIALILZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
AA9-Ev3-Normalización de Bases de Datos

Cuarta Forma Normal.

Para cumplir con la cuarta forma normal se debe cumplir la tercera forma normal y la siguiente regla:
Debe ser posible realizar cambios en cualquier campo que no forme parte de la clave principal sin que
para ello se vea afectado cualquier otro campo.
Lo anterior simplemente dice que, si las anteriores reglas se han cumplido, se podrá modificar el
nombre de cualquier médico o sus teléfonos, sin afectar la base de datos.
Las reglas 3 y 4 van de la mano, por ello se deben evitar datos innecesarios para poder hacer cambios
sin afectar el funcionamiento y la consistencia de la base de datos, para entenderlo, hágase las
siguientes preguntas: ¿qué pasaría si se almacenara el nombre del médico en cada factura y por
alguna razón se tuviera que modificar su nombre?, ¿dónde habría que hacer los cambios?, ¿sería una
operación sencilla?

Quinta Forma Normal (5FN)

Una tabla se encuentra en 5FN si:

La tabla está en 4FN
No existen relaciones de dependencias de reunión (join) no triviales que no se generen desde las
claves. Una tabla que se encuentra en la 4FN se dice que está en la 5FN si, y sólo si, cada relación
de dependencia de reunión (join) se encuentra definida por claves candidatas. Por lo que si se aplicara
una consulta entre al menos tres relaciones independientes entre sí dentro de la 4FN y se obtuvieran
tuplas espurias, entonces no estaría dentro de la 5FN.