separata 01 Desnormalizacion
Transcript of 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.
Sistema de Bases II Desnormalización
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.
Sistema de Bases II Desnormalizació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.
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalizació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
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalización
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.
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalización
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.
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalización
ERD
UML
Figura 1.6. Presupuesto flexible.
1
Detalle presupuesto
Presupuesto
ProrrateoDetalle presupuesto
*
1
*
ProrrateoDetalle presupuesto
FECHA _ INICIOFECHA _ FINAL
Presupuesto
Detalle presupuesto
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalización
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:
Sistema de Bases II Desnormalización
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
Sistema de Bases II Desnormalización
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