Sistema de Bases II ELIMINACIN DE LA NORMA

Desnormalizacin

Una vez que hemos terminado de desarrollar el modelo de datos para el sistema y que ste es correcto desde un punto de vista lgico, podemos comenzar con xito el desarrollo fsico y crear aplicaciones. Sin embargo, no hay que decir que habr que optimizar el diseo creado para llevar a buen puerto ste objetivo. Tampoco existir ningn motivo para afirmar que el modelo de datos existente es inadecuado. Nota: Normalmente, deber mantener su modelo fsico tan cerca como sea posible de su modelo lgico. En los ltimos aos de la dcada de los ochenta era muy comn desnormalizar fuertemente los modelos de datos. Los registros detallados se reorganizaban en registros maestros, cuyas estructuras se colapsaban en archivos planos, y las estructuras lgicas limpias y transparentes se convertan en estructuras que resultaban familiares para los programadores en COBOL/VSAM. Esta forma de proceder era el resultado del elevado precio de los equipos informticos y de que los mdulos (engine) de las bases de datos relacionales eran bastantes lentos. Los consultores afirmaban que podan multiplicar por diez el rendimiento de la base de datos si realizaban una desnormalizacin masiva. La creencia ms extendida era que los modelos normalizados eran buenos en teora, pero no funcionaban correctamente en la prctica. La solucin era crear modelos de datos lgicos 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. Especficamente eran poco flexibles y cualquier modificacin resultaba extremadamente cara. Si se necesitaba utilizar una funcionalidad no diseada explcitamente en la base de datos, haca 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 diseo. A pesar de que el rendimiento del sistema mejoraba cuando ste entraba en funcionamiento, el coste de mantener y modificar estos sistemas era prohibitivo.

Sistema de Bases II

Desnormalizacin

Sin embargo se pueden llevar a la prctica cierto tipo de desnormalizacin que no tendr un impacto muy profundo en la capacidad del sistema para dar respuesta a los futuros requisitos. En ste captulo analizaremos algunas de las tcnicas de desnormalizacin 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 desnormalizacin sin algn coste. En la mayora de los casos, cuando se mejora el rendimiento en una parte del sistema, se degrada en otra parte. La normalizacin es un estilo de de modelizacin que la mayora de los diseadores de datos tienen bastante claro. La denormalizacin es un arte idiosincrsico. Cuanto ms estructuras se encuentres desnormalizadas, ms difcil ser que otros diseadores puedan trabajar con ellas. Se trata de un problema de extrema gravedad. Los diseadores vienen y van. Contar con modelos que puedan leer y comprender los futuros diseadores es de trascendental importancia. Tampoco se debe tomar a la ligera a la denormalizacin, 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 slo consiga tener un rendimiento aceptable si desnormaliza. Se puede desnormalizar para simplificar la lgica de la aplicacin. 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 informacin. Si almacenamos de manera redundante esta informacin en algn lugar de la base de datos, puede que seamos capaces de reducir enormemente la complejidad de la lgica de la programacin.

Sistema de Bases II

Desnormalizacin

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. Podra unir a la vista cualquier columna sin funcin sin que apenas se produjera un impacto apreciable en el rendimiento, salvo el lgico referido a la ejecucin de la funcin. Utilizar vistas basadas en varias tablas suele, con frecuencia, dificultar al mximo en anlisis de la tabla completa. En cualquier caso, se podr seguir una estrategia si el objetivo final es simplificar la lgica de la aplicacin. Si puede alcanzar un rendimiento adecuado con las vistas, utilcelas, actuando as no complicar demasiado el modelo de datos. Para desnormalizar, se crean con frecuencia atributos redundantes. Un atributo redundante es una funcin de otros objetos existentes en una clase de objetos, dentro de la base de datos. Un ejemplo de sta situacin sera aadir un Precio extendido que fuera igual a Cantidad existente x Precio existente. Otro ejemplo es un MAYS (nombre) donde se almacenan redundantemente las letras maysculas de un nombre. Se trata de una tcnica bastante comn y se utiliza para poder ejecutar consultas que no distinguen en el uso de maysculas y minsculas en el campo del nombre. El motivo de que no pueda realizar la consulta en tiempo de ejecucin sin ms que introducir MAYS en el campo es porque poner una funcin en una columna dentro de una clusula WHERE derrota al ndice. El nico caso en el que se utiliza siempre sta tcnica es cuando resulte necesario introducir un ndice en la columna redundante. Tcnicas de desnormalizacin Hemos identificado 11 tipos de desnormalizacin que resultan necesarios para facilitar la codificacin o para mejorar el rendimiento. Describiremos cada uno de ellos y mostraremos ejemplos especficos para ilustrar estas tcnicas.

Sistema de Bases II Campos total redundante

Desnormalizacin

La desnormalizacin ms 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 debern encontrarse sincronizados bien mediante el uso de desencadenadores (triggers) que acten sobre la clase de detalle o utilizando programas de mandato (batch) capaces de actualizar estos valores. Tericamente, estos detalles tambin podran sincronizarse utilizando cdigo de aplicacin. Sin embrago, esta forma de proceder hace que el cdigo sea poco estable y no resulta demasiado recomendable. Si desnormaliza utilizando campos totales redundante, podr ver lo totales sin tener que realizar la unin en la agregacin. Otra ventaja de esta tcnica es que podr generar un ndice. Esta forma de proceder resultar de utilidad si desea localizar rdenes de compra que tengan un tamao que se encuentre comprendido dentro de un determinado rango o para encontrar las rdenes de compra de mayor o de menor tamao. La nica forma de evitar el barrido completo de la tabla y el clculo de cada uno de los detalles de la orden de compra ser mediante la creacin de una columna redundante. Las columnas de este tipo no solo tendrn que ser simples sumas de los registros detallados. Tambin podra generar una columna que almacenara la cantidad incluida en una cuenta de cliente, pero esta forma de proceder exigira un clculo 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 introduccin de este capitulo, para facilitar la bsqueda de informacin textual se suele crear una columna redundante, que es, simplemente, una transformacin a maysculas de los datos originales (MAYS). Este suele ser el procedimiento mas comnmente utilizado. En muy pocos casos, se trata de un problema difcil de resolver, particularmente cuando se manejan altos volmenes de datos. Un ejemplo seria la comparacin de direcciones almacenadas en dos sistemas distintos. En ocasiones, se introducen inadvertidamente espacios en blanco adicionales entre el nmero y el nombre de la calle o, por ejemplo, se utilizan

Sistema de Bases II

Desnormalizacin

abreviaturas de una manera inconsistente. Para resolver este problema se puede utilizar el siguiente algoritmo. 1.- Convertir la direccin a maysculas. 2.- Eliminar todos los caracteres extraos, tales como tabuladores, espacios, retornos duros de lnea, signos de puntuacin. 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 bsquedas de nombres y direcciones en sistemas de gran tamao, podr almacenar cada palabra en su propia columna e indexar cada columna para realizar bsquedas eficientes en millones de registros para localizar la informacin apropiada. Cualquiera de estos mtodos se puede llevar a cabo con facilidad mediante desencadenadores de la base de datos. El diseador de aplicaciones slo tendr que utilizar estas columnas en caso necesario. Como las desencadenadores no necesitan interactuar con el disco, el rendimiento resultante es bastante bueno. Este mtodo 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 bsquedas por nombre en un subconjunto de los detalles de la reclamacin. Tradicionalmente, deberamos 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 reclamacin que se encuentren asociados con el grupo. Esta introduccin

Sistema de Bases II

Desnormalizacin

de columnas redundantes de clave primaria puede simplificar en gran medida la codificacin de los informes y aplicaciones. ERD

Detalle Reclamaciones

Reclamacin

Pliza

Coste

Plan

Grupo

Sistema de Bases II UML

Detalle Reclamaciones

Desnormalizacin

*
1

Reclamacin

*
1

Pliza

1
Coste

1
Plan

1
Grupo

Figura 1.1. Estructura que requiere el uso de columnas de clave externa. COLUMNAS REDUNDANTES PARA EL HISTORICO Incluso aunque un modelo almacene informacin particular, recuperar esta informacin puede resultar relativamente difcil. En el diagrama mostrado en la figura 18.2, si deseamos agregar ventas por departamento, tendremos que unir Ventas a Dep. Slo cuando la fecha de la transaccin 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 unin normal contara 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

Sistema de Bases II

Desnormalizacin

efectu dicha venta, entonces resultara sencillo agregar ventas por departamentos. En ocasiones, podr utilizarse esta tcnica en lugar de tener que analizar la informacin histrica. 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 relacin 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 podrn describir mediante las relaciones adicionales existentes entre Dep. y Ventas. Tendremos que agregar un desencadenador con el fin de poblar automticamente 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 simplificacin de este tipo slo deber realizarse despus de haber realizado un anlisis 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 histrica de ventas. Recientemente, trabajamos en un proyecto en el que deba mantenerse la historia, finalmente, la opinin 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 podan 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 ms flexible es, normalmente, mucho menor que el vernos obligados despus a tener que modificar un sistema completo para acomodar un requisito nuevo o, simplemente, que fue pasado por alto.

Sistema de Bases II ERD

Historia del empleo

Desnormalizacin

Departament o

Venta

Empresa

Historia del empleo FECHA _ INICIAL FECHA _ FINAL

*
Venta

Realizado por 1

Empresa *

Departamento

Figura 1.2. Estructura que puede utilizar columnas histricas redundantes.

Venta

Empresa

Departamento

UML Venta Realizado por Empresa

Trabaja actualmente para Acreditado para

Departamento

Figura 1.3. Seguimiento alternativo de la historia.

Sistema de Bases II Nivel de Recursividad

Desnormalizacin

Para ciertas aplicaciones que contengas estructuras recursivas que representan un rbol, red lista vinculada, etc. Resulta til en que nivel de una jerarqua 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 jerarqua, tal ves no resulte posible determinar el nivel deseado o los niveles devueltos tendrn un elevado grado de inexactitud. La columna Nivel no resulta necesaria con frecuencia. Sin embrago, puede resultar de utilidad durante la fase de depuracin de aplicaciones. El desencadenador que se necesita para mantener esta funcin es barato y ocupa un espacio despreciable. La existencia de la columna Nivel tambin alerta a los diseadores de la presencia de una estructura recursiva. Por nuestra parte, recomendamos la inclusin de Nivel como columna redundante en muchas estructuras recursivas. Escritura de tablas maestras Si una clase de generalizacin 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 generalizacin. Ser necesario mirar todos los registros contenidos en cada una de las tablas de especializacin para determinar el lugar en el que se encuentra un determinado registro. Una solucin a este problema es almacenar el nombre de la tabla de especializacin aplicable en la generalizacin. De esta forma, tal y como se encuentra en la figura 1.4 podremos modificar nuestro ejemplo de generalizacin estndar de los empleados por horas y asalariados. Utilizando esta estructura, almacenaremos el tipo de empleo (asalariado o por horas) en la tabla Empleado.

Sistema de Bases II UML

Desnormalizacin

Empleado

* 1 Consistente con

Tipo de empleo

Asalariado muestra la generalizacin.

Por horas Figura 1.4. Tabla redundante que

Redundancia en el Desarrollo COBS Como mencionamos en el captulo 14, en el desarrollo de objetos complejos (COBS) no se suelen utilizar columnas redundantes. Podr encontrar ms detalles sobre este tema en el captulo 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, imagnese 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, adems, 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

Sistema de Bases II

Desnormalizacin

justificar la transgresin 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 modificacin.

ERD
Detalle presupuesto

UML Detalle Presupuesto. Trimestre 1 Trimestre 2 Trimestre 3 Trimestre 4

Presupuesto

1 Presupuesto

Figura 8.5 de la Primera Forma Normal.

Sistema de Bases II ERD

Desnormalizacin

Prorrateo Detalle presupuesto

Detalle presupuesto

1
Presupuest o

UML

Prorrateo Detalle presupuesto

* 1

Detalle presupuesto

* FECHA _ INICIO FECHA _ FINAL

Presupuesto

Figura 1.6. Presupuesto flexible.

Sistema de Bases II

Desnormalizacin

Columnas Sobrecargadas Sobrecargar columnas puede disminuir el nmero 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 slo un tipo de informacin. Las nicas excepciones a esta regla pueden ocurrir en modelizaciones genricas en las que se utilice columnas del tipo valor. Cada vez que se almacenen diferentes tipos de informacin 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 nmero de horas de trabajo que han sido necesarias. A nivel factura, el vendedor factura un nmero que representa una cantidad de dinero o el nmero de otras que han sido necesarias dependiente de lo que se est facturando. Esta forma de modelizar la estructura disminuye en una unidad el nmero de atributos que hay que mantener, pero incrementa en docenas de horas el tiempo de desarrollo de la aplicacin para manejar este error al sobrecargar una columna. No confunda este error con una columna utilizada en la generalizacin a nivel clase., que puede ser de mucha ayuda. Por ejemplo, en un mdulo denominado Demogrfico, los pases se dividen en subunidades para enviar el correo. Estas subunidades pueden ser estados, provincias o algn otro tipo de unidad. Normalmente para manejar esta situacin, existir una nica clase para pases y otra clase para las subdivisiones del pas que pueden representar un estado, provincia, etc. En este caso, el atributo nombre de la subdivisin se referir al nombre del estado o de la provincia. Desde una perspectiva terica, 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 informacin, estamos ante un caso claro de

Sistema de Bases II

Desnormalizacin

empleo de columna sobrecargada. En caso contrario, la columna sobrecargada causar problemas de manera inevitable en algn instante posterior. Columnas Multiatributos Una estrategia utilizada con frecuencia en campos tales como Nmeros de Partes o Nmeros de contratos es incluir la informacin 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 almacenarn juntos el ao 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 podrn utilizar las columnas multiatributos. Sin embargo, hay que reconocer que esta forma de proceder no es la mejor forma de modelizar un sistema. La informacin del sistema cambiar de manera inevitable. Es muy raro que todos los campos mantengan siempre fija la informacin que almacenan. Tablas Histricas 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 informacin perteneciente al primer nivel de agregacin. 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 podra utilizar una tabla redundante para almacenar la informacin peridica sobre una estructura. Tal y como se muestra en la figura 18.7, esta estructura incluir una clase compuesta que comtendra toda la informacin que deseamos supervisar. Los campos contenidos en la tabla historia son los siguientes:

Sistema de Bases II

Desnormalizacin

Fecha del valor (la fecha en la que deseamos analizar la informacin) Valor actual de la cartera de valores en un determinado da. 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, tendramos 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 nmero de ingresos/gastos producidos en cualquier periodo arbitrario de tiempo, solo tendramos que recuperar dos registros: el tiempo inicial y final del intervalo. Finalmente, tan solo tendramos que restar dos valores: esta forma de proceder resulta mucho ms eficaz que sumar los valores almacenados en todo un rango. Podr utilizar este tipo de tablas histricas para mejorar en gran medida el rendimiento del sistema y, con frecuencia, puede hacer innecesario la construccin de un almacn de datos independiente.

ERD Histori a cartera valores

UML Historia cartera valores Fecha valor Valor de la cartera Gastos mensuales Gastos anuales Gastos acumulados Revisin mensual Revisin anual Revisin acumulada * 1

Cartera FIGURA 1.7. Ejemplo de clase compuesta

Sistema de Bases II

Desnormalizacin

CONTENIDO

ELIMINACION DE LA NORMA TECNICAS DE DESNORMALIZACION CAMPOS TODTAL REDUNDANTE ATRIBUTOS REDUNDANTES EN LA FILA DE UNA TABLA COLUMNAS ADICIONALES DE CLAVES EXTERNAS COLUMNAS REDUNDANTES PARA EL HISTORICO NIVELES DE RECUSIVIDAD ESCRITURA DE TABLAS MAESTRAS REDUNDANCIA EN EL DESARROLLO COBS VIOLACION EN LA PRIMERA FORMA NORMAL COLUMNAS SOBRECARGADAS COLUMNAS MULTIATRIBUTOS TABLAS HISTORICAS REDUNDANTES

1 3 4 4 5 7 10 10 11 11 14 15 15