Normalización de Base

de Datos
 Normalización de Base de Datos

Poniéndonos en Contexto

La semana pasada discutimos elementos de Modelado de Datos,

incluso, comenzamos a realizar nuestro ejemplo. En este recurso
expondremos los atributos de nuestras entidades, a través de lo que
se conoce como Normalización.

Normalización de Base de Datos

En si, ¿Qué es la normalización?, la definición es una sola línea:

es el proceso de organizar los datos de una base de datos. Para
explicar un poco mejor lo anterior, diremos que lo que se busca es
eliminar redundancia y garantizar independencia e integridad de los
datos, elementos discutidos a detalle en la semana pasada.
Al momento de normalizar una base de datos, se debe tener en
cuenta lo siguiente:
- Minimizar la cantidad de datos duplicados almacenados en una
base de datos. Por lo general, esto lo hacemos de manera
quizás intuitiva. En efecto, si revisamos nuestro modelo
tendemos a evitar esto, mediante la creación de entidades
denominadas Maestros, como por ejemplo Carrera,
Departamento de nuestro ejemplo de la semana pasada.
- Perfeccionar la organización de los datos de tal manera que
cuando se requiera efectuar una modificación, la misma se
aplique en un solo lugar. En el ejemplo de la semana pasada
¿Qué ocurre si el Decanato cambia de nombre?, ¿debo cambiar
toda la información de los alumnos, carreras, materias,

Gerencia virtual 2
 Normalización de Base de Datos

departamentos?, no, una base de datos normalizada debe

contemplar la entidad Decanato dentro de ella.
- Construir una base de datos que se pueda acceder de manera
rápida y donde sea posible manipular los datos con máxima
eficiencia sin comprometer su integridad.

Formas Normales

Existen varias formas normales, procedamos a explicarlas. La

primera es la Forma Normal Cero. Acá es lógico suponer que no
existe ningún tipo de normalización. Por ejemplo
Cédula Nombre Carrera Materia1 Materia2
12345678 Rómulo Domínguez Ing Informática Cálculo I Programación I
7654321 Manuel Crespo Ing Producción Física I Cálculo Integral

Lo anterior es una entidad que no está normalizada, pero, ¿en

que nos afecta?. Veamos, ¿Qué ocurre si se desea cursar una
materia adicional?, se deben crear atributos tantas materias se cursen.
En este sentido, alguien con criterio podría explicar “colocar los
atributos de materias hasta el máximo permitido”, por ejemplo, siete
materias. Lo anterior, en apariencia soluciona el problema, nada más
alejado de la realidad, ya que se tendría almacenado en la base de
datos una enorme cantidad de datos nulos (sin información), debido a
que muy pocos alumnos cursan siete materias, y, nuestra base de
datos crecería de una manera desproporcionada, no acorde con lo

Gerencia virtual 3
 Normalización de Base de Datos

realmente almacenado. De allí vamos entonces a nuestra primera

forma normal.

Primera Forma Normal

Para la primera forma normal básicamente debemos hacer lo
siguiente:
1. Eliminar los grupos repetitivos de las tablas individuales.
2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave
primaria.
Para nuestro ejemplo, la siguiente estructura estaría en primera
forma normal.
Cédula Nombre Cod Carrera Cod Materia
12345678 Rómulo Domínguez Ing01 Cal01
12345678 Rómulo Domínguez Ing01 Pro01
7654321 Manuel Crespo Ing02 Fis01
7654321 Manuel Crespo Ing02 CIn01

Tal como se aprecia, se ha aplicado todo lo referente a la

Primera Forma Normal. Se crearon las claves tanto para la carrera
como las materias. Sin embargo, tenemos otra consideración. Se
debe repetir un registro casi con la misma información cada vez que
un alumno se inscriba en una materia, lo que hace que nuestra base
de datos crezca de manera desproporcionada sin mucho sentido. De
allí, pasamos entonces a nuestra Segunda Forma Normal.

Gerencia virtual 4
 Normalización de Base de Datos

Segunda Forma Normal

La segunda forma normal lo que intenta es resolver el problema
descrito anteriormente. En otras palabras, lo que se debe hacer es lo
siguiente:
1. Crear tablas separadas para aquellos grupos de datos que se
aplican a varios registros.
2. Relacionar estas tablas mediante una clave externa.

Retomando nuestro ejemplo, lo que se debe hacer es crear una

tabla nueva (casualmente lo discutimos la semana pasada), la cual no
es más que la tabla de inscritos la cual se relacionaría tanto con
alumnos y sección. Sería como sigue
Alumno
Cédula Nombre Cod Carrera
12345678 Rómulo Domínguez Ing01
7654321 Manuel Crespo Ing02

Sección
Cod Sección Cod Materia Nombre Materia
01 Cal01 Cálculo I
02 Pro01 Programación I
03 Fis01 Física I
04 CIn01 Cálculo Integral

Finalmente, la tabla de inscrito sería como sigue

Gerencia virtual 5
 Normalización de Base de Datos

Inscrito
Cod Lapso Cedula Cod Seccion Calificacion
2018I 12345678 01 78
2018I 12345678 02 65
2018I 7654321 03 81
2018I 7654321 04 67

Acá se aprecia entonces que en la tabla de inscrito se muestran

los alumnos que cursan las diferentes materias en determinado lapso
y su calificación, lo cual fue el punto de discusión durante la semana
pasada.
En otro orden de ideas si notamos la tabla de sección se aprecia
que uno de sus atributos es el nombre de la materia, lo cual es un
aspecto que no debería suceder, lo que nos lleva a la Tercera Forma
Normal.

Tercera Forma Normal

La tercera forma normal nos expone eliminar aquellos campos
que no dependan de la clave. En este orden de ideas tenemos la
tabla de Sección, la cual entre sus atributos contiene el nombre de la
materia, la cual no depende del código de la sección, sino más bien de
la materia en sí.
Lo anterior trae como consecuencia que se deba introducir el
nombre de la materia cada vez que se crea una sección, ocasionando
posible inconsistencias en la base de datos. Por ejemplo, si existen
dos (2) secciones de Cálculo Integral, podría ocurrir lo siguiente:

Gerencia virtual 6
 Normalización de Base de Datos

Cod Sección Cod Materia Nombre Materia

01 CIno1 Calc.Integral
02 CIn01 Cálculo Integral

Si deseamos consultar en nuestra base de datos todas aquellas

secciones de Cálculo Integral, escribiríamos una sentencia SQL como
sigue:
Select *
From Seccion
Where Nombre_Materia =”Cálculo Integral”;
La sentencia nos traería un solo registro, la sección 02, ya que la
01 no tiene ese nombre. De allí que la solución sea eliminar el nombre
de la materia como atributo, crear la tabla materia y relacionarla con
sección, aspecto que ya teníamos en nuestro modelo. En ese orden
de ideas, nuestra sentencia SQL sería:
Select S.cod_seccion, m.nombre_materia
From Seccion As S, Materia As M
Where S.cod_materia = m.cod_materia;
Allí nos arrojaría las dos (2) secciones con el nombre adecuado
de la material. Más allá de pretender exponer sentencias de SQL, lo
que se pretende acá es determinar la importancia de aplicar dichas
reglas de diseño en nuestra base de datos. Existen dos (2) formas
normales adicionales, las cuales son poco aplicadas e incluso pueden
ser ignoradas.

Gerencia virtual 7
 Normalización de Base de Datos

Consideraciones adicionales
Más allá de las formas normales, las cuales las aplicamos de
manera hasta empírica sin reparar en ello, existen otros que debemos
tener en consideración a la hora de diseñar nuestra base de datos.
Una de las premisas en nuestros sistemas de información es que
deben ser flexibles y adaptables a los cambios. Bien, una manera de
lograr ello es mediante el diseño de nuestra base de datos; ¿de que
manera?, simple, creando entidades catálogo (maestros) en nuestra
base de datos.
Por ejemplo, quizás no reparemos en crear una entidad país en
nuestras aplicaciones, “¿para que?, el nombre del país no cambia”.
Suponga los cambios que hubo que hacer en aquellas aplicaciones
gubernamentales (en caso de haberlas) en la antigua Checoslovaquia,
hoy Eslovaquia y República Checa, en la antigua Yugoslavia, y sin ser
más drásticos en Venezuela, hoy República Bolivariana de Venezuela.
Imagine el trabajo (innecesario) que hubo que hacer en cambiar la
gran cantidad de reportes cuyo encabezado se plasmaba el nombre
del país de manera estática y no mediante una consulta a la base de
datos.
Del mismo modo, quizás no reparemos en mantener una entidad
llamada moneda, el mismo comentario aplica para aquellos países que
actualmente pertenecen a la Comunidad Europea que cambiaron su
moneda por el Euro.
Para ir a un caso más terrenal y asociado a nuestro ejemplo.
Tenemos el caso del Decanato (“el nombre del decanato no cambia”),
pues bien, en la facultad (Decanato) donde imparte clases este

Gerencia virtual 8
 Normalización de Base de Datos

servidor que escribe ha cambiado de nombre tres (3) veces. Del

mismo modo, independientemente de los posibles cambios o no del
nombre, supongamos (que es lo más seguro) que necesitamos
consultas y reportes que necesite el nombre del Decano de la facultad
(este si cambia en períodos de tiempo), ¿de dónde obtenemos esa
información?, ¿vamos a estar cambiando los reportes para actualizar
el nombre del Decano?, obvio no, de allí, la importancia de la entidad
Decano en nuestra base de datos, la cual no necesariamente está
asociada a la aplicación de ninguna de las formas normales
anteriormente descritas.
Asimismo, otra premisa de los Sistemas de Información es que
deben ser configurables, pues bien, ¿dicha configuración en donde se
almacena? ¿en donde se cambia?. De allí, la importancia en crear
una entidad denominada Sistema en nuestra base de datos.
Existen otras consideraciones adicionales que escapan de este
curso, por ejemplo, se deben crear entidades de auditoria en donde se
almacenen el registro de las transacciones para aquellas entidades
muy críticas. De igual manera ¿nuestra base de datos soporta
históricos?, ¿en dónde se consideran?.
Con base a lo anteriormente expuesto, queda de manifiesto
nuestra actividad esta semana: avanzar en nuestro modelo de datos
creando los atributos a nuestras entidades, aplicando las reglas de
normalización y las consideraciones adicionales.

Gerencia virtual 9