separata 01 desnormalizacion

Sistema de Bases II Desnormalización

ELIMINACIÓN DE LA NORMA

Una vez que hemos terminado de desarrollar el modelo de datos para el sistema y que

éste es correcto desde un punto de vista lógico, podemos comenzar con éxito el

desarrollo físico y crear aplicaciones. Sin embargo, no hay que decir que habrá que

optimizar el diseño creado para llevar a buen puerto éste objetivo. Tampoco existirá

ningún motivo para afirmar que el modelo de datos existente es inadecuado.

Nota: Normalmente, deberá mantener su modelo físico tan cerca como sea posible de su

modelo lógico.

En los últimos años de la década de los ochenta era muy común desnormalizar

fuertemente los modelos de datos. Los registros detallados se reorganizaban en registros

maestros, cuyas estructuras se colapsaban en archivos planos, y las estructuras lógicas

limpias y transparentes se convertían en estructuras que resultaban familiares para los

programadores en COBOL/VSAM. Esta forma de proceder era el resultado del elevado

precio de los equipos informáticos y de que los módulos (engine) de las bases de datos

relacionales eran bastantes lentos. Los consultores afirmaban que podían multiplicar por

diez el rendimiento de la base de datos si realizaban una desnormalización masiva. La

creencia más extendida era que los modelos normalizados eran buenos en teoría, pero

no funcionaban correctamente en la práctica. La solución era crear modelos de datos

lógicos normalizados y construir base de datos basadas en archivos planos.

Esta estrategia tuvo resultados desastrosos. Cuando estos sistemas entraron en la fase

productiva, se encontraron con los mismos problemas que tuvieron en los sistemas

tradicionales de archivos planos. Específicamente eran poco flexibles y cualquier

modificación resultaba extremadamente cara. Si se necesitaba utilizar una funcionalidad

no diseñada explícitamente en la base de datos, hacía falta realizar modificaciones muy

profundas en la estructura de datos. Hacia finales de 1980, la comunidad de las base de

datos comenzó a darse cuenta de su error de diseño. A pesar de que el rendimiento del

sistema mejoraba cuando éste entraba en funcionamiento, el coste de mantener y

modificar estos sistemas era prohibitivo.


Sin embargo se pueden llevar a la práctica cierto tipo de desnormalización que no tendrá

un impacto muy profundo en la capacidad del sistema para dar respuesta a los futuros

requisitos. En éste capítulo analizaremos algunas de las técnicas de desnormalización

mas conocidas que se pueden utilizar sin impactar profundamente en la naturaleza

flexible de un modelo de datos de calidad.

Hay que tener presente que nunca se puede realizar una desnormalización sin algún

coste. En la mayoría de los casos, cuando se mejora el rendimiento en una parte del

sistema, se degrada en otra parte. La normalización es un estilo de de modelización que

la mayoría de los diseñadores de datos tienen bastante claro.

La denormalización es un arte idiosincrásico. Cuanto más estructuras se encuentres

desnormalizadas, más difícil será que otros diseñadores puedan trabajar con ellas.

Se trata de un problema de extrema gravedad. Los diseñadores vienen y van. Contar

con modelos que puedan leer y comprender los futuros diseñadores es de trascendental

importancia.

Tampoco se debe tomar a la ligera a la denormalización, puede o no mejorar el

rendimiento. Ciertamente, dificultará la lectura del modelo. Salvo que se realice de una

manera muy cuidada, se reducirá la flexibilidad del modelo. Entonces. ¿para que

desnormalizar? Hay varias situaciones en las que pueden ser necesarios:

Se puede desnormalizar por razones de rendimiento. Tal ves tenga un modelo de

datos complejo y extremadamente voluminoso con decenas de millones de filas

en sus tablas centrales. En estos casos, puede ocurrir que sólo consiga tener un

rendimiento aceptable si desnormaliza.

Se puede desnormalizar para simplificar la lógica de la aplicación. Puede ser que

para producir un informe determinado o una pantalla se tengan que acceder entre

10 y 20 tablas con el fin de recuperar una determinada pieza de información. Si

almacenamos de manera redundante esta información en algún lugar de la base

de datos, puede que seamos capaces de reducir enormemente la complejidad de

la lógica de la programación.


Si desea desnormalizar únicamente por el segundo motivo, siempre deberá contemplar

la alternativa de utilizar un avista actualizable en lugar de desnormalizar. En lugar de

crear una columna redundante, cree una vista mostrando dicha columna. Deberá

manejar con cuidado las vistas, ya que unirse a las vistas dificulta la puesta a punto de

las consultas. Sin embargo, si puede utilizar una vista simple de una única tabla, en la

que haya creado todas las columnas adicionales mediante funciones incrustadas. Podría

unir a la vista cualquier columna sin función sin que apenas se produjera un impacto

apreciable en el rendimiento, salvo el lógico referido a la ejecución de la función.

Utilizar vistas basadas en varias tablas suele, con frecuencia, dificultar al máximo en

análisis de la tabla completa. En cualquier caso, se podrá seguir una estrategia si el

objetivo final es simplificar la lógica de la aplicación. Si puede alcanzar un rendimiento

adecuado con las vistas, utilícelas, actuando así no complicará demasiado el modelo de

datos.

Para desnormalizar, se crean con frecuencia atributos redundantes. Un atributo

redundante es una función de otros objetos existentes en una clase de objetos, dentro de

la base de datos. Un ejemplo de ésta situación sería añadir un Precio extendido que

fuera igual a “Cantidad existente x Precio existente”. Otro ejemplo es un MAYÚS

(nombre) donde se almacenan redundantemente las letras mayúsculas de un nombre.

Se trata de una técnica bastante común y se utiliza para poder ejecutar consultas que no

distinguen en el uso de mayúsculas y minúsculas en el campo del nombre. El motivo de

que no pueda realizar la consulta en tiempo de ejecución sin más que introducir

MAYÚS en el campo es porque poner una función en una columna dentro de una

cláusula WHERE derrota al índice. El único caso en el que se utiliza siempre ésta

técnica es cuando resulte necesario introducir un índice en la columna redundante.

Técnicas de desnormalización

Hemos identificado 11 tipos de desnormalización que resultan necesarios para facilitar

la codificación o para mejorar el rendimiento. Describiremos cada uno de ellos y

mostraremos ejemplos específicos para ilustrar estas técnicas.


Campos total redundante

La desnormalización más frecuente es almacenar en una columna detallada, dentro de la

tabla maestra, el toral de una cantidad. Por ejemplo, podrá introducir un atributo en una

orden de compra que sea la suma de los detalles. Los datos almacenados en esta

columna deberán encontrarse sincronizados bien mediante el uso de desencadenadores

(triggers) que actúen sobre la clase de detalle o utilizando programas de mandato

(batch) capaces de actualizar estos valores. Teóricamente, estos detalles también

podrían sincronizarse utilizando código de aplicación. Sin embrago, esta forma de

proceder hace que el código sea poco estable y no resulta demasiado recomendable.

Si desnormaliza utilizando campos totales redundante, podrá ver lo totales sin tener que

realizar la unión en la agregación. Otra ventaja de esta técnica es que podrá generar un

índice. Esta forma de proceder resultará de utilidad si desea localizar órdenes de compra

que tengan un tamaño que se encuentre comprendido dentro de un determinado rango o

para encontrar las órdenes de compra de mayor o de menor tamaño. La única forma de

evitar el barrido completo de la tabla y el cálculo de cada uno de los detalles de la orden

de compra será mediante la creación de una columna redundante. Las columnas de este

tipo no solo tendrán que ser simples sumas de los registros detallados. También podría

generar una columna que almacenara la cantidad incluida en una cuenta de cliente, pero

esta forma de proceder exigiría un cálculo bastante complejo. En general si va a crear

una columna calculada, ésta deberá encontrarse indexada para que se puedan realizar

consultas sobre ella con gran rapidez.

ATRIBUTOS REDUNDANTES ENLA FILA DE UNA TABLA

Tal y como se comento en la introducción de este capitulo, para facilitar la búsqueda de

información textual se suele crear una columna redundante, que es, simplemente, una

transformación a mayúsculas de los datos originales (MAYÚS).

Este suele ser el procedimiento mas comúnmente utilizado. En muy pocos casos, se

trata de un problema difícil de resolver, particularmente cuando se manejan altos

volúmenes de datos. Un ejemplo seria la comparación de direcciones almacenadas en

dos sistemas distintos. En ocasiones, se introducen inadvertidamente espacios en blanco

adicionales entre el número y el nombre de la calle o, por ejemplo, se utilizan


abreviaturas de una manera inconsistente. Para resolver este problema se puede utilizar

el siguiente algoritmo.

1.- Convertir la dirección a mayúsculas.

2.- Eliminar todos los caracteres extraños, tales como tabuladores, espacios, retornos

duros de línea, signos de puntuación.

3.- Homogeneizar las abreviaturas de todas las palabras (por ejemplo, Oeste se

convertirá en O u Oest).

4.- Sustituir texto del tipo “1º” por “PRIMERO” para crear consistencia.

5.- Coger únicamente los diez primeros caracteres.

Mediante este algoritmo, conseguirá comparar de manera bastante fiable las direcciones.

Cuando se tenga que enfrentar con búsquedas de nombres y direcciones en sistemas de

gran tamaño, podrá almacenar cada palabra en su propia columna e indexar cada

columna para realizar búsquedas eficientes en millones de registros para localizar la

información apropiada. Cualquiera de estos métodos se puede llevar a cabo con

facilidad mediante desencadenadores de la base de datos. El diseñador de aplicaciones

sólo tendrá que utilizar estas columnas en caso necesario. Como las desencadenadores

no necesitan interactuar con el disco, el rendimiento resultante es bastante bueno.

Este método derrocha bastante espacio en el disco. Sin embargo, el cuello de botella de

las aplicaciones no suele encontrarse en el espacio de disco, sino en su rendimiento.

COLUMNAS ADICIONALES DE CLAVES EXTERNAS EN EL LUGAR EL

QUE NO PERTENECEN

Cuando tenga que trabajar con una cadena particularmente larga de relaciones maestro

detalle que se extiende por varias clases de objetos, podrá introducir una clave externa o

una referencia a un puntero de objeto desde un extremo de la cadena al otro, tal y como

se muestra en la Figura 1.1.

En este ejemplo queremos realizar búsquedas por nombre en un subconjunto de los

detalles de la reclamación. Tradicionalmente, deberíamos unir tablas para lograr este

objetivo. En cambio, al introducir una referencia de objeto o una clave externa en

Detalle de reclamaciones que apunte a Grupo, podremos recuperar con rapidez los

detalles de la reclamación que se encuentren asociados con el grupo. Esta introducción


de columnas redundantes de clave primaria puede simplificar en gran medida la

codificación de los informes y aplicaciones.

ERD

DetalleReclamaciones Reclamación

Póliza

Coste

Plan

Grupo


UML

Figura 1.1. Estructura que requiere el uso de columnas de clave externa.

COLUMNAS REDUNDANTES PARA EL HISTORICO

Incluso aunque un modelo almacene información particular, recuperar esta información

puede resultar relativamente difícil. En el diagrama mostrado en la figura 18.2, si

deseamos agregar ventas por departamento, tendremos que unir Ventas a Dep. Sólo

cuando la fecha de la transacción de la venta se encuentre comprendida entre las fechas

inicial y final en las que un determinado empleado se encontraba adscrito a dicho

departamento. Una unión normal contaría dos veces todas las ventas cuando un

empleado cambiara de departamento.

Si almacena de forma redundante una referencia a un objeto o una clave externa en la

tabla VENTAS para indicar en que departamento trabajaba el empleado cuando se

1

*

1

*

1

*1

**Detalle Reclamaciones

Reclamación Póliza

Coste

Plan

Grupo

1


efectuó dicha venta, entonces resultara sencillo agregar ventas por departamentos. En

ocasiones, podrá utilizarse esta técnica en lugar de tener que analizar la información

histórica. En el ejemplo anterior, el único motivo para tener que analizar la historia del

empleo de un determinado empleado será para poder asignar el volumen correcto de

ventas al departamento adecuado. Si éste es el único requisito del sistema, podrá

modelizar la relación tal y como se mue4stra en la Fig 1.3

Si utiliza esta estructura, nunca necesitaremos la clase historia del ejemplo, ya que todas

las relaciones se podrán describir mediante las relaciones adicionales existentes entre

Dep. y Ventas. Tendremos que agregar un desencadenador con el fin de poblar

automáticamente la referencia Dep. cada vez que se genere una nueva venta.

Este ejemplo es de gran importancia, ya que demuestra que estamos intentando

encontrar las reglas del sistema que definen nuestro modelo de datos. Como se podrá

imaginar, podremos plasmar las mismas reglas del sistema utilizando modelos

diferentes. Sin embargo, una simplificación de este tipo sólo deberá realizarse después

de haber realizado un análisis profundo. En este caso, no creemos adecuado simplificar

el modelo eliminando la estructura de la historia del Empleo. Para hacerlos, tendrá que

estar absolutamente convencido de que el único motivo para seguir conservando la

historia del empleo es analizar el funcionamiento del departamento mediante la

contabilidad histórica de ventas. Recientemente, trabajamos en un proyecto en el que

debía mantenerse la historia, finalmente, la opinión del cliente fue la que se logró

imponer. Antes de que el sistema llegara a ponerse en marcha, descubrimos que varios

de los informes necesarios no se podían producir de manera segura sin mantener la

historia del empleo.

Nota: El coste asociado con el hecho de tener que modelizar una entidad de manera

más flexible es, normalmente, mucho menor que el vernos obligados después a tener

que modificar un sistema completo para acomodar un requisito nuevo o, simplemente,

que fue pasado por alto.


ERD

Figura 1.2. Estructura que puede utilizar columnas históricas redundantes.

UML

Figura 1.3. Seguimiento alternativo de la historia.

Trabaja actualmente para

Acreditado para

Realizado por

1*

*

1

Realizado por

Historia del empleo

Empresa

Departamento

Venta Historia del empleo

FECHA _ INICIALFECHA _ FINAL

Venta Empresa Departamento

Departamento

EmpresaVenta

Departamento

Venta Empresa


Nivel de Recursividad

Para ciertas aplicaciones que contengas estructuras recursivas que representan un árbol,

red lista vinculada, etc. Resulta útil en que nivel de una jerarquía se encuentra un

determinado registro. Si utiliza CONNECT BY podrá conocer el nivel como un valor

almacenado en una columna del sistema. Si no utiliza CONNECT BY o si no ha

comenzado en el nivel superior de la jerarquía, tal ves no resulte posible determinar el

nivel deseado o los niveles devueltos tendrán un elevado grado de inexactitud. La

columna Nivel no resulta necesaria con frecuencia. Sin embrago, puede resultar de

utilidad durante la fase de depuración de aplicaciones. El desencadenador que se

necesita para mantener esta función es barato y ocupa un espacio despreciable.

La existencia de la columna Nivel también alerta a los diseñadores de la presencia de

una estructura recursiva. Por nuestra parte, recomendamos la inclusión de Nivel como

columna redundante en muchas estructuras recursivas.

Escritura de tablas maestras

Si una clase de generalización no es abstracta (es decir, que se haya instanciado en

forma de tabla), no existe manera de determinar con facilidad el tipo de cada registro al

analizar una fila de la tabla de generalización. Será necesario mirar todos los registros

contenidos en cada una de las tablas de especialización para determinar el lugar en el

que se encuentra un determinado registro. Una solución a este problema es almacenar el

nombre de la tabla de especialización aplicable en la generalización. De esta forma, tal y

como se encuentra en la figura 1.4 podremos modificar nuestro ejemplo de

generalización estándar de los empleados por horas y asalariados.

Utilizando esta estructura, almacenaremos el tipo de empleo (asalariado o por horas) en

la tabla Empleado.


UML

Figura 1.4. Tabla redundante que muestra la generalización.

Redundancia en el Desarrollo COBS

Como mencionamos en el capítulo 14, en el desarrollo de objetos complejos (COBS) no

se suelen utilizar columnas redundantes. Podrá encontrar más detalles sobre este tema

en el capítulo 16.

Violaciones de la Primera Forma Normal

No recomendamos transgredir la primera forma normal. Sin embargo, hemos

considerado esta posibilidad en diferentes ocasiones. Por ejemplo, imagínese el caso en

que se modeliza un presupuesto con todos sus detalles. Cada detalle del presupuesto

incluye la parte de sus fondos correspondiente a cada uno de los cuatro trimestres. Este

sistema se puede modelizar tal y como se muestra en la figura 1.5.

Si utiliza esta estructura y, además, las reglas del sistema cambian siempre, y, por otro

lado, se necesitan asignaciones semianuales o mensuales. Habrá que modificar el

modelo y todas las aplicaciones. Para modelizar este sistema tal y como se muestra en la

figura 18.6 tendremos que hacer el modelo mas flexible para que pueda trabajar con

prorrateos de presupuestos en cualquier intervalo temporal.

Este tipo de estructura requiere un mayor tiempo de desarrollo y proporciona un menor

rendimiento. Si el rendimiento es un objetivo primario, las circunstancias pueden

1

*Empleado

Por horasAsalariado

Tipo de empleo

Consistente con


justificar la transgresión de la primera forma normal. Recuerde que si utiliza el primer

modelo, nos encontraremos con problemas de gran calibre si, posteriormente, se

necesita realizar alguna modificación.

UML

Figura 8.5 de la Primera Forma Normal.

1

*

DetallePresupuesto.

Trimestre 1Trimestre 2Trimestre 3Trimestre 4

Presupuesto

ERD

Detalle presupuesto

Presupuesto


ERD

UML

Figura 1.6. Presupuesto flexible.

1

Detalle presupuesto

Presupuesto

ProrrateoDetalle presupuesto

*

1

*

ProrrateoDetalle presupuesto

FECHA _ INICIOFECHA _ FINAL

Presupuesto

Detalle presupuesto


Columnas Sobrecargadas

Sobrecargar columnas puede disminuir el número de atributos que se deben mantener en

una tabla. No recomendamos el empleo de esta estrategia.

Nota.- Es importante que cada atributo almacene uno y sólo un tipo de información.

Las únicas excepciones a esta regla pueden ocurrir en modelizaciones genéricas en las

que se utilice columnas del tipo “valor”. Cada vez que se almacenen diferentes tipos de

información en la misma columna, inevitablemente surgen los problemas. Un ejemplo

de las dificultades que se presentan cuando utilizan columnas sobrecargadas ocurre en

un sistema de control de contratos. A nivel detalle, los contratos se descomponen en

materiales y trabajo. A nivel material, los fabricantes ofertan un precio para los

materiales necesitados. El precio del trabajo se encuentra fijado y los fabricantes

facturan el número de horas de trabajo que han sido necesarias. A nivel factura, el

vendedor factura un número que representa una cantidad de dinero o el número de otras

que han sido necesarias dependiente de lo que se esté facturando. Esta forma de

modelizar la estructura disminuye en una unidad el número de atributos que hay que

mantener, pero incrementa en docenas de horas el tiempo de desarrollo de la aplicación

para manejar este error al sobrecargar una columna. No confunda este error con una

columna utilizada en la generalización a nivel clase., que puede ser de mucha ayuda.

Por ejemplo, en un módulo denominado Demográfico, los países se dividen en

subunidades para enviar el correo. Estas subunidades pueden ser estados, provincias o

algún otro tipo de unidad.

Normalmente para manejar esta situación, existirá una única clase para países y otra

clase para las subdivisiones del país que pueden representar un estado, provincia, etc.

En este caso, el atributo “nombre” de la subdivisión se referirá al nombre del estado o

de la provincia. Desde una perspectiva teórica, los nombres de estado provienen de un

dominio diferente que los nombres de las provincias, pero ambos se utilizan en la

misma forma. Desde una perspectiva del sistema, ambos nombres son equivalentes. Por

tanto, si el sistema siempre utiliza igual la información, estamos ante un caso claro de


empleo de columna sobrecargada. En caso contrario, la columna sobrecargada causará

problemas de manera inevitable en algún instante posterior.

Columnas Multiatributos

Una estrategia utilizada con frecuencia en campos tales como Números de Partes o

Números de contratos es incluir la información en la columna. Solo deberá utilizar esta

estrategia si la única actividad que va a realizar con los componentes pertenecientes al

campo es ensamblarlos. Por ejemplo, siempre se almacenarán juntos el año con un ID

generado por el sistema. Una ves que se instancia el campo nunca se deberá alterar los

componentes. Si se cumplen todas estas condiciones, se podrán utilizar las columnas

multiatributos.

Sin embargo, hay que reconocer que esta forma de proceder no es la mejor forma de

modelizar un sistema. La información del sistema cambiará de manera inevitable. Es

muy raro que todos los campos mantengan siempre fija la información que almacenan.

Tablas Históricas Redundantes

Si estamos intentando controlar la contabilidad almacenada en el libro mayor, la

actividad de una cartera de valores, o contabilizar los gastos de un departamento, el

volumen de estas transacciones suele ser suficientemente elevado y requiere una

estructura muy compleja. Para generar informes, solo tendremos que recoger la

información perteneciente al primer nivel de agregación. Para calcular los gastos totales

o los ingresos obtenidos durante un determinado periodo de tiempo, necesitaremos

agregar todas las transacciones que hayan tenido lugar durante dicho periodo de tiempo.

Resolver un problema de este tipo puede ser un autentico quebradero de cabeza desde

el punto de vista del rendimiento del sistema. Se podría utilizar una tabla redundante

para almacenar la información periódica sobre una estructura. Tal y como se muestra

en la figura 18.7, esta estructura incluirá una clase compuesta que comtendra toda la

información que deseamos supervisar.

Los campos contenidos en la tabla historia son los siguientes:


Fecha del valor (la fecha en la que deseamos analizar la información)

Valor actual de la cartera de valores en un determinado día.

Cifras de gastos e ingresos a nivel mensual.

Cifras de gastos e ingresos a nivel anual.

En un lugar de almacenar diariamente los gastos e ingresos, utilizaremos un truco. Si

almacenamos diariamente los gastos y queremos calcular el total de ingresos obtenidos

durante un determinado periodo de tiempo, tendríamos que sumar los ingresos diarios

que hubieran tenido lugar durante dicho periodo de tiempo. En lugar de proceder a si,

podemos almacenar de manera acumulativa los ingresos y gastos desde un instante

inicial arbitrario. De esta forma, para determinar el número de ingresos/gastos

producidos en cualquier periodo arbitrario de tiempo, solo tendríamos que recuperar

dos registros: el tiempo inicial y final del intervalo. Finalmente, tan solo tendríamos que

restar dos valores: esta forma de proceder resulta mucho más eficaz que sumar los

valores almacenados en todo un rango. Podrá utilizar este tipo de tablas históricas para

mejorar en gran medida el rendimiento del sistema y, con frecuencia, puede hacer

innecesario la construcción de un almacén de datos independiente.

FIGURA 1.7. Ejemplo de clase compuesta

Historia cartera valores

Fecha valorValor de la carteraGastos mensualesGastos anualesGastos acumuladosRevisión mensualRevisión anualRevisión acumulada

1

*

ERD

Historia cartera valores

Cartera

UML


CONTENIDO

ELIMINACION DE LA NORMA 1

TECNICAS DE DESNORMALIZACION 3

CAMPOS TODTAL REDUNDANTE 4

ATRIBUTOS REDUNDANTES EN LA FILA DE UNA TABLA 4

COLUMNAS ADICIONALES DE CLAVES EXTERNAS 5

COLUMNAS REDUNDANTES PARA EL HISTORICO 7

NIVELES DE RECUSIVIDAD 10

ESCRITURA DE TABLAS MAESTRAS 10

REDUNDANCIA EN EL DESARROLLO COBS 11

VIOLACION EN LA PRIMERA FORMA NORMAL 11

COLUMNAS SOBRECARGADAS 14

COLUMNAS MULTIATRIBUTOS 15

TABLAS HISTORICAS REDUNDANTES 15

separata 01 desnormalizacion

Documents