AA9-Ev3-NORMALIZACIÓN DE BASES DE DATOS

PRESENTADO POR: LIZETH DANIELA ESPITIA RUIZ

PRESENTADO A: NELSON RUIZ GAMBA

SERVICIO NACIONAL DE APRENDIZAJE SENA

PROGRAMA DE FORMACIÓN
ESPECIALIZACIÓN TECNOLÓGICA EN GESTIÓN Y SEGURIDAD DE BASES
DE DATOS
MODALIDAD VIRTUAL
2019
 SERVICIO NACIONAL DE APRENDIZAJE | SENA

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 2 de 9

TABLAS

Las tablas son las unidades que almacenan los datos. 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, siendo las principales tareas las siguientes:

• Añadir información.
• Eliminar información.
• Modificar y actualizar información.
• Recoger información y mostrarla.
Comúnmente estas cuatro tareas se realizan mediante el lenguaje SQL (Structured
Query Language)

Después de analizado el problema que se quiere resolver y que se ha esbozado un

primer Diagrama E-R, 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 se toman decisiones con el objetivo de

recoger de la manera más adecuada todos los datos que se almacenarán en una
base de datos y distribuirlos en tablas.

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
 SERVICIO NACIONAL DE APRENDIZAJE | SENA

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 3 de 9

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.

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
 SERVICIO NACIONAL DE APRENDIZAJE | SENA

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 4 de 9

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 realiza 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

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 5 de 9

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.

TABLA: MEDICOS
Idmedic Nombre_espe Genero_ Genero_F Direccion Teléfono Teléfono Teléfo Turno
o cialidad Masculino emenino _1 _2 no_3
738957 AGUSTIN T F CALLE 3553355 23/04/20
36 CABEZAS ARRIBA 10
(GENERAL)
902790 NATALIA F T CALLE 4634673 2345754 36544 24/04/20
497-1 PELAEZ( ABAJO 4 64 10
UROLOGO)
902790 NATALIA F T CALLE 7744324 23/04/20
497-2 PELAEZ ABAJO 10
(UROLOGO)
642583 CONCEPCIO F T CALLE 2357435 46635 25/04/20
97 N SEGURA DEL 76 10
(NEUROLOG MEDIO
O)

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 basaremos 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.
 SERVICIO NACIONAL DE APRENDIZAJE | SENA

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 6 de 9

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.
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
 SERVICIO NACIONAL DE APRENDIZAJE | SENA

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 7 de 9

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.

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:
Idme Nombre_es Genero_ Genero_F Dire Teléf Teléf Teléf Tu
dico pecialidad Masculino emenino ccio ono_ ono_ ono_ rn
n 1 2 3 o

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 segundo 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.
 SERVICIO NACIONAL DE APRENDIZAJE | SENA

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 8 de 9

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.

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.
 SERVICIO NACIONAL DE APRENDIZAJE | SENA

Lizeth Daniela Espitia Ruiz – Cc. 1019103384 Página 9 de 9

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?