You are on page 1of 7

Desnormalización de

Base de Datos
Desnormalización de Base de Datos

Poniéndonos en Contexto

La semana pasada discutimos elementos de Normalización de


Base de Datos, incluso, vimos sencillos ejemplos que exponían la
importancia de aplicar dichas reglas de diseño. Bajo estas
consideraciones nos estemos preguntando ¿desnormalizar la base de
datos?, ¿para qué?.
Antes de dar respuesta a lo anterior resulta prudente aclarar que
la desnormalización no es igual a una base de datos no normalizada.
En efecto, se desnormaliza la base de datos si y solo sí antes ha sido
normalizada. Por su parte, una base de datos no normalizada es
aquella que no cumple con varias reglas de diseño vistas durante la
semana anterior.

Aspectos para desnormalizar la base de datos

En primer lugar aclaremos algo: no se desnormaliza la base de


datos por cuestiones propias de programación. ¿Cómo así?, quizás (o
casi seguro), “desnormalizabamos” nuestra base de datos como
artificio para ahorrarnos esfuerzo (un par de horas de trabajo) de
programación y “hacer que nuestro programa funcionara como fuera”
con el propósito de aprobar nuestra asignatura.
Apoyándonos en nuestro ejemplo, supongamos (es más que
evidente) que necesitemos ver las calificaciones de determinada
sección, en donde se muestre el nombre del alumno, su cédula, su
calificación, el código de la sección, el nombre de la materia, el lapso
académico y por supuesto, el nombre del docente que impartió la

Gerencia virtual 2
Desnormalización de Base de Datos

misma. ¿Cuántas entidades están involucradas?, ¡muchas!, a simple


vista están: docente, materia, carrera, sección, inscritos y semestre (si
se me escapó alguna, ofrezco mis excusas). Nada más pensar en las
sentencias SQL para obtener dicho reporte nos agobie de momento.
En este sentido, nuestra solución (más cómoda) es crear a lo
sumo dos entidades (cuidado si no una) con una enorme cantidad de
atributos para facilitar nuestro reporte (“lo más seguro, que el docente
no repare en ello”)
Bien, en el mundo real no funciona de esa manera. El artificio
anterior puede que funcione para unos pocos registros (nuestra
aplicación no llega a 100 registros en nuestra base de datos). En una
empresa, el volumen de registros de nuestra base de datos crece de
manera exponencial, lo que ocasiona que “las dos grandes entidades”
no funcionen, con toda certeza se generarán datos inconsistentes, el
rendimiento de la base de datos será muy deficiente, la cantidad de
usuarios inconformes será muy grande, y lo más importante, el tiempo
que se requerirá para reacomodar el desastre de la base de datos
será mucho mayor que “el par de horas que nos ahorramos en la
programación”. Dicho lo anterior, no es “negocio” crear dichos
artificios.
Lo anteriormente comentado nos lleva a nuestra pregunta
original: ¿para qué desnormalizar?. Para explicar ello, recurramos a
un ejemplo muy trillado: el clásico modelo de factura.

Gerencia virtual 3
Desnormalización de Base de Datos

Este ejemplo no tiene mayor explicación, es ampliamente


conocido por todos. Acá se aplican las reglas de diseño de base de
datos, especialmente en la entidad Detalle_factura, en donde se
reflejan los artículos adquiridos en la factura. Del mismo modo,
aprendimos que en la entidad detalle no se debía colocar como
atributo el precio, puesto que el mismo se almacena en la entidad
producto. Bien, ¿Qué ocurre si el precio del producto cambia?,
sencillo, cuando se genera una factura nueva se toma el precio
actualizado en la tabla de productos.
Bajo la consideración anterior, ¿qué ocurre si el precio del
producto cambia y se desea consultar una factura previamente

Gerencia virtual 4
Desnormalización de Base de Datos

generada (con el precio anterior)?, allí cambia radicalmente nuestro


asunto. Ya no se puede consultar la factura con el precio anterior,
puesto que el modelo no lo soporta. ¿Solución?, simple:
desnormalizar la base de datos. Para ello, colocaríamos en nuestra
entidad detalle_factura el precio con el cual fue vendido el producto
con lo que resolveríamos el problema.

Otro de los aspectos a considerar a la hora de desnormalizar es


el rendimiento ¡de la base de datos, no de la programación!. Para
explicar ello, recurramos al ejemplo que hemos visto durante estas
semanas. En este sentido, supongamos que deseamos generar el

Gerencia virtual 5
Desnormalización de Base de Datos

reporte de calificaciones una vez finalizado el semestre (lapso), de


todos los estudiantes del Decanato, en donde se aprecie por alumno
las calificaciones obtenidas de cada una de las asignaturas cursadas,
así como también el índice académico actualizado.
Una de las reglas de normalización nos expresa que los campos
calculados no deberían formar parte de los atributos de una entidad.
En este orden de ideas, es más que obvio que el índice académico es
un campo que se calcula por lo que no tiene que ser un atributo de la
entidad alumno.
Ahora bien, ¿en cuánto tiempo se generará dicho reporte si para
cada uno de los alumnos (que deben ser muchos) del decanato se
debe calcular su índice académico?. En este caso ¿no es más
recomendable que sea un atributo de Alumno?. A simple vista
podríamos decir ¡claro!. Ahora, tenemos otra consideración ¿en que
momento actualizamos dicho índice académico?. La pregunta anterior
probablemente nos haga pensar un poco más.
El índice académico ase actualiza cada vez que obtiene la
calificación definitiva por cada asignatura. En este caso, es más que
evidente que se registra en la base de datos ésta una vez que el
docente transcribe al sistema las calificaciones de los alumnos
pertenecientes a una sección. Llegado a este punto podríamos pensar
“es lo mismo, se debe actualizar el índice académico para cada uno de
ellos”. Obviamente, pero, queda más que claro que el número de
registros a actualizar es mucho menor si lo comparamos con todo el
decanato. En este sentido, el tiempo empleado para actualizar el
índice académico de los alumnos de una sección es mucho menor al

Gerencia virtual 6
Desnormalización de Base de Datos

que se emplea para generar el reporte, por lo que se podría considerar


desnormalizar la base de datos agregando el índice académico a la
entidad alumno.

Con base a lo anterior, como última actividad, desnormalizaremos


nuestro modelo de datos y explicaremos las razones que nos llevaraon
a ello para cada caso.

Gerencia virtual 7

You might also like