jump to navigation

Oracle – Considerando la introducción de redundancia (Desnormalización)

Fuente: http://www.ixora.com.au/tips/design/redundancy.htm

Por definición, un modelo de datos completamente normalizado, no contiene redundancia. Si algo de redundancia se introduce, entonces esta la posibilidad de inconsistencia y se necesitan utilizar triggers para asegurar que la consistencia se mantenga cuando los datos son insertados, modificados o eliminados.

Por qué introducir redundancia? 

            Dado el costo de performance que implica ejecutar dichos triggers, por qué querrías introducir redundancia a un buen modelo de datos?.  La respuesta es, si el costo de la obtención de información a partir de los datos relacionados fuera considerablemente más grande que el costo de su mantenimiento.

            Por supuesto, la medida del costo usado aquí tiene en cuenta la frecuencia de manipulación de datos y operaciones de consulta, el tiempo de estas operaciones y el tiempo en que se quiera obtener la respuesta, y no sólo los costos de E/S y CPU de las respectivas operaciones.

            Los beneficios potenciales  de introducir redundancia (o “desnormalización”) son tan diversos como los propios planes de ejecución de consultas. Sin embargo los siguientes ejemplos ilustran los alcances de estas técnicas.

Evitando Uniones (Joins) para Búsqueda:

            En muchas aplicaciones se utilizan tablas de códigos, para validar los usados en el ingreso de datos y para proveer descripciones en las consultas. Se podría elegir mantener la descripción en el registro padre en vez del código, para evitar estas uniones durante las consultas. 

            Consideremos datos jerárquicos, como una jerarquía de entidades corporativas. Si comúnmente se necesita relacionar entidades a su padre principal, se podría almacenar el código de este en cada registro, para mejorar la performance y simplificar el SQL.

Evitando Uniones (Joins) para Campos Calculables

            En un sistema de ingreso de órdenes, se podría almacenar en forma redundante el valor total  de cada orden en la tabla de órdenes, para evitar una unión con la tabla de ítems para calcular el total.

            En un sistema financiero, se podría almacenar en forma redundante los totales a la fecha en cada asiento contable general, para evitar una unión a la tabla de transacciones para obtener la suma.

Evitando  subconsultas correlativas:

            En una serie de datos temporales, donde cada registro  representa un periodo,  se puede almacenar las fechas de comienzo y fin en cada registro. Esto permite la utilización de sentencias con “BETWEEN”,  en lugar de las subconsultas correlativas que se necesitarían ejecutar para cada fila, consumiendo recursos.

            Los beneficios de la redundancia pueden ser impresionantes, no obstante, dado su costo, sólo se deberían adoptar semejantes estrategias, si hubiera una ventaja clara en la performance.


Comentarios ( Abril 2008 )

González Fernando      3301-2657
Dulcich Diego      1327-0202
Tejerina Martin Miguel      1327-0312
Takashima Ignacio      1330-0420
Fernandez, Marcelo      1330-0043

            Desde el punto de vista del grupo, consideramos que la redundancia se puede analizar desde dos puntos de vista: el teórico y el práctico.

            El punto de vista teórico, nos marca la premisa, en general, de evitar la redundancia de datos para obtener un diseño normalizado y optimizado. Pero si partimos desde la realidad cotidiana en la cual nos desenvolvemos, en la practica, dependiendo  en que contexto estemos trabajando a veces debemos desestimar parte de la normalización, para lograr (o mejorar) el comportamiento de un sistema, logrando una mejor performance en el funcionamiento del sistema. Se adiciona la variable costos en un ambiente real, que muchas veces tiene un impacto mas ponderante que el que un buen diseñador podría desear.

            Cabe destacar que a decisión de incluir redundancia en los datos (por más mínima que esta sea) debe ser perfectamente estudiada y analizada, y por otro lado los beneficios deberían  ser claramente notorios para que justifique la acción.


Pablo Balegno                         3601-0119
Julián García Tuñón                3601-0289
Melisa Berra                           3601-0555
Rosalía Panetta                       3601-1244
Yadia Saya                             3701-1513 

El artículo “Considering Introduced Redundancy (Denormalization)” plantea que un modelo normalizado no tiene redundancia, y si se introduce redundancia existe la posibilidad de que el modelo sea inconsistente. Para evitarlo se necesitarían triggers que manejen los datos a ser insertados, modificados o eliminados.

Un trigger es un tipo especial de procedimiento almacenado, que se ejecuta automáticamente como parte de una instrucción de modificación de datos. Están asociados con una tabla específica de la base de datos. Ellos solos se disparan cuando ocurre una inserción, eliminación o una actualización de filas de la tabla a la cual el trigger está asociado. Los triggers pueden ser definidos en un insert, delete o update.

Sin embargo, en ciertos casos, el introducir elementos redundantes en la tabla de índice y estructuras puede resultar beneficioso, e incluso producir mejoras en el rendimiento de bases de datos.

La introducción de redundancia puede mejorar la velocidad de las consultas SQL y garantizar que sean atendidas lo más rápido posible.

Para determinar los niveles de normalización a utilizar en la base de datos se deberán tener en cuenta varios factores como el tamaño de la aplicación, el número de accesos concurrentes sobre las tablas, la velocidad de las consultas, entre otros.

Entendemos entonces que, una base de datos normalizada consigue evitar al máximo la redundancia de datos, impide las dependencias funcionales de los datos para que el proceso de actualización de la base de datos sea fácil y eficiente. Sin embargo, la realización de consultas en la base de datos puede requerir la combinación de varias tablas para unir la información. A medida que el número de tablas combinadas crece, el tiempo de ejecución de la consulta aumenta considerablemente. Por este motivo, el uso de una base de datos normalizada no es siempre la mejor alternativa.

Para solucionar esto, se lleva a cabo el proceso de desnormalización. Por lo general, si un número importante de las consultas precisan de la combinación de más de cinco o seis tablas, es aconsejable su uso.

Una base de datos con la medida justa de desnormalización reduce el número de tablas que deben combinarse sin dificultar en exceso el proceso de actualización. Entonces, tendrá consecuencias de redundancia de datos, pero mejorará el rendimiento ya que se evitarían juntas y subconsultas, pero es importante tener en cuenta que sólo se debería implementar si presenta notables ventajas de performance.


Andrade Darriba, Gonzalo                 3701-0189
Fernández, Juan Gabriel                  3101-3421
García, Manuel                  3601-1518
Seguí, María Victoria                  3701-0508
Suarez, Pablo                 3501-2656
Sutz Kaelin, Guillermo                 3701-1192

Después de haber llevado a cabo la exposición y posterior estudio del artículo en cuestión, nos encontramos en condiciones de plantear que a pesar de las definiciones ideales en el campo teórico acerca de las cuestiones asociadas al diseño de base de datos eficientes, poniendo énfasis primordial en lo que es la erradicación de la duplicación innecesaria de información, en el contexto de sistemas de la vida real, obligan a los diferentes responsables a considerar potenciales excepciones en el diseño del ente, para garantizar un funcionamiento más óptimo.

En este sentido, debemos partir del concepto que los sistemas de base de datos sin redundancia absoluta no existen, sin embargo en la medida que esta variable sea menor hace que se logre una mejor optimización en el funcionamiento, como el mantenimiento de lo que son los datos contenidos dentro de la estructura de la base datos; sin embargo, como se explayó en el párrafo previo, aunque esto es la tendencia principal a la que se debe pretender alcanzar por parte de todo equipo de desarrollo, esta meta no puede ser sin considerar el entorno y sus cualidades del ente a llevar cabo.

Es aquí, donde se destaca que el artículo hace un quiebre y plantea: dos clases de base datos principales, las cuales son distinguibles básicamente por el predominio en sus operaciones por parte de los usuarios intervinientes: Altas, Bajas, Modificaciones por un lado y Consultas por otro. Para el primer caso, el artículo a partir de sus conceptos expresados deja entender como es conveniente ante una alta volatilidad de los datos contenidos, el promover la menor redundancia existente a través de las herramientas o algoritmos que se dispongan por parte del equipo de desarrollo, como el administrador.

Sin embargo, no ocurre la misma consideración con el segundo tipo. Se puede decir, que el texto promueve en cierta medida algo que parecería descabellado para un equipo de desarrollo en una primera aproximación por los preceptos teóricos que se tienen, lo cual se resume en llevar a cabo un procedimiento de desnormalización de ciertos fragmentos del esquema de la base de datos, con tal de promover una mayor velocidad en las averiguaciones de datos del sistema en cuestión; para justificar y mostrar la validez de esto, el artículo expresa como la utilización de mecanismos típicos en motores de base de datos como son los Triggers o disparadores, juntas o Joins de diversa índole en grandes proporciones o volumen informativo, generan una pérdida de tiempo mayor respecto a lo que sería el mantenimiento de las “redundancias” que se produzcan sobre un mismo esquema, con el peligro que esto implica, debido a que se estaría pudiendo generar un defasaje de información de un mismo dato vinculado a un elemento del sistema, lo cual en términos generales se identifica bajo la nomenclatura de “Pérdida de Información” por el adicionamiento espurio de datos a los originales, o en su defecto la desaparición de una fracción de los mismos en la organización de la base de datos.

Sin embargo, se resalta que el escrito seleccionado también pone de manifiesto que los responsables en generar la construcción de la base de datos, como sus futuros administradores evalúen el contexto y coyuntura del dominio del sistema, para establecer si la desnormalización o la presencia de redundancias en ciertos esquemas de datos, otorga la ventaja en su funcionamiento, traducido en una mayor velocidad de respuesta y procesamiento hacia el usuario interviniente, que se espera respecto a las técnicas tradicionales; si dicho procedimiento no plantea una optimización notoria, es preferible en consecuencia mantenerse en los estándares conocidos de normalización, ya sea bajo la Tercera Forma Normal, o la denominada como Forma Normal de Boyce – Codd en forma esencial, las cuales se vinculan esencialmente a las restricciones asociadas a las dependencias funcionales del entorno de desarrollo.


Acuña Walter                (3501-1248 )
Amador Cintia                (3501-0251)
Ghidella Pablo                (3501-1293)
Núñez Verónica                (3401-0843)
Puch Pablo              3501-0234)
Sartoris Federico                (3601-0620)

 Para comenzar el detalle de los artículos sugeridos, creemos que es muy indicado hacer referencias al significado de “afinación o tuning” mediante los dos fragmentos siguientes:

Primer fragmento

Afinación

 La afinación se refiere a ajustes y cambios en la organización del almacén de datos después de que el sistema ha entrado en servicio y se han aclarado suficientemente las pautas de uso. Este proceso de ajuste de la base de datos se llama afinación (Tunning).

El uso de la base de datos evoluciona continuamente, a medida que más personas se van familiarizando con ella y se van creando más programas de aplicación. Los ajustes en la organización del almacén para el óptimo desempeño se convierten en un proceso continuo.

El responsable de realizar la afinación de la base de datos es el administrador de o su grupo, y es importante que este tenga libertad para introducir los cambios que sean necesarios, sin hacer estragos en los programas de aplicación.

Requisitos para una correcta afinación:

Independencia física de los datos: Es la capacidad de modificar el esquema interno sin alterar el esquema conceptual, ni los programas de aplicación.

Medios: Para supervisar automáticamente el uso de la base de datos con el fin de que puedan hacerse los ajustes necesarios.

Los manejadores actuales de bases de datos ya incorporan medios para la afinación automática.

Fuente: Yahoo! answers.

Segundo fragmento

La manipulación de datos y programas de administración de bases de datos son cosas que nos suceden más a menudo de lo que nosotros creemos; transacciones con cajeros automáticos, compras de productos, etc. , involucran dichos movimientos detrás para satisfacer los requerimientos.

Las velocidades de procesamiento de las computadoras ha aumentado considerablemente, así también lo ha hecho la cantidad de información. El costo de almacenamiento ha bajado considerablemente, a veces no al ritmo de aumento de la cantidad almacenada y su costo.

Para un correcto Sistema Gestor de Base de Datos Relacional se debe:

Fuente: Oracle Performance Tuning and Optimization – Edward Whalen 1996.

Nota

Como explicamos anteriormente, la solución nunca es absoluta, depende de las necesidades y capacidades de nuestro sistema. Estas son las decisiones que deberá tomar un buen DBA, su función es implementar la mejora correcta en tiempo y forma, en base al estado actual del sistema y las capacidades económicas de la empresa.

Un buen DBA puede detectar que para ciertas condiciones, es beneficioso para la base de datos introducir redundancia, lo cual podrá mejorar otro aspecto del sistema que cause problemas y que no tenga otra forma de solucionarlo. 


Carretero Soledad
De Cenzo Romina
Gallardo Jorge
Poleschi Sebastián
Traverso Carolina
Vazquez Hess Matias

En conclusión a lo escrito anteriormente, se analiza el porque es necesario a veces la desnormalización (introducción de redundancia), debido a que nosotros frecuentemente, normalizamos para mantener la consistencia de datos.

Asimismo  al aplicar esta técnica en ciertos casos donde necesitamos juntar las tablas que hemos anteriormente normalizado, utilizamos un tiempo de ejecución el cual se podría evitar si no hubiésemos normalizado las tablas que estamos juntando.

El motivo por el cual se desnormaliza, es para evitar excesivas juntas que nos quitan tiempo de ejecución, aunque esto nos genere redundancia. Para ello, hay que realizar un análisis para garantizar cuando es conveniente quitar redundancia o ganar tiempo de ejecución.

Lo cual se vincula directamente con el tipo de aplicación que se este desarrollando, donde se debe considerar:


Fernandez, Santiago 3401-1570
Gricar, Francisco 3401-2219
Kambic, Gastin 3401-0191
De La Vecchia, Martin 3401-1366
Gonzalez, Matias 3301-2528
Caserta, Nicolas 3401-1131

Por definición un modelo de datos completamente normalizado no posee redundancia. Si se introduce redundancia al modelo, existe la posibilidad de inconsistencias, entonces se debería pensar en utilizar triggers para asegurar que la consistencia de datos se mantenga cuando realizamos operaciones de agregado, actualización y borrado de datos.

Los beneficios potenciales de agregar redundancia (o desnormalizacion) son diversos como los planes de ejecución de consultas por si mismos.

Los beneficios de mantener redundancia pueden ser importantes. Sin embargo, dado los costos de utilizar Triggers, solamente se debería adoptar esta estrategia si obtenemos un gran beneficio en cuando a performance.

A %d blogueros les gusta esto: