jueves, 20 de septiembre de 2012

Base de Datos Tipo Cubo

                                            

                                          

                                          ~  BASE DE DATOS TIPO CUBO


Un cubo OLAP, OnLine Analytical Processing o procesamiento Analítico En Línea, término acuñado por Edgar Frank Codd de EF Codd & Associates, encargado por Arbor Software (en la actualidad Hyperion Solutions), es una base de datos multidimensional, en la cual el almacenamiento físico de los datos se realiza en un vector multidimensional.
Los cubos OLAP se pueden considerar como una ampliación de las dos dimensiones de una hoja de cálculo.
A menudo se pensaba que todo lo que los usuarios pueden querer de un sistema de información se podría hacer de una base de datos relacional. No obstante Codd fue uno de los precursores de las bases de datos relacionales, por lo que sus opiniones fueron y son respetadas.
En el mundo de las soluciones para Business Intelligence, una de las herramientas más utilizadas por las empresas son las aplicaciones OLAP, ya que las misma han sido creadas en función a bases de datos multidimensionales, que permiten procesar grandes volúmenes de información, en campos bien definidos, y con un acceso inmediato a los datos para su consulta y posterior análisis.
Como hemos mencionado en un artículo anterior, las herramientas OLAP proporcionan a las compañías un sistema confiable para procesar datos que luego serán utilizados para llevar a cabo análisis e informes que permitan mejorar las operaciones productivas, tomar decisiones inteligentes y optimizar la competitividad en el mercado

 
 
.


 
Para funcionar, las aplicaciones OLAP utilizan un tipo de base de datos que posee la peculiaridad de ser multidimensional, denominada comúnmente Cubo OLAP.
 
Básicamente, el Cubo OLAP, que acuña su nombre por su característica multidimensional, es una base de datos que posee diversas dimensiones, ampliando las posibilidades que hasta el momento ofrecían las conocidas hojas de cálculo.
 
Hasta la llegada del término Cubo OLAP, que nació de la mano de Edgar F. Codd, de la compañía EF Codd & Associates, sólo se utilizaban bases de datos relacionales para el proceso de la información, con sistemas tales como el ROLAP.
 
Gracias a la incorporación de las bases de datos de tipo multidimensional, y el nacimiento del nuevo concepto Cubo OLAP, las herramientas de soluciones para sistemas Business Intelligence han avanzado notablemente en cuanto a las prestaciones que estas aplicaciones brindan a las empresas, donde la información confiable, precisa y en el momento oportuno, son uno de los bienes más preciados.
 
Cabe destacar que los Cubos OLAP son vectores en los cuales se dispone la información, y gracias a esta ordenada jerarquía es posible llevar a cabo un análisis rápido de los datos.
 
Mediante la incorporación de estos vectores o cubos, se han ampliado las posibilidades de las bases de datos relacionales, permitiendo el procesamiento de importantes volúmenes de información, que de lo contrario sería imposible realizar.
 
Cada una de las dimensiones que posee la base de datos incorpora un campo determinado para un tipo de dato específico, que luego podrá ser comparado con la información contenida en el resto de dimensiones, para hacer posible la evaluación y posteriores informes de la información realmente relevante para una compañía.
 
Una base de datos multidimensional puede contener varios cubos o vectores que extenderán las posibilidades del sistema OLAP con el cual se trabaja.
 
Por ello, si bien en general los sistemas OLAP suelen estar compuestos por tres dimensiones, lo cierto es que existe la posibilidad de que el sistema OLAP albergue más de tres dimensiones mediante la utilización de estos Cubos OLAP.
 
A pesar de las grandes ventajas que presenta este tipo de base de datos multidimensional que incluye Cubos OLAP, la cual permite obtener mayor rapidez en las consultas y en el procesamiento de la información, lo cierto es que su gran falla reside en la imposibilidad de realizar cambios en su estructura.
 
Debido a su forma de funcionamiento y almacenamiento de la información, cuando los usuarios requieren realizar modificaciones en la estructura de este tipo de base de datos, deben rediseñar el Cubo OLAP, sin posibilidades de poder utilizar la estructura en la que se trabajó hasta el momento.
 
Para tener una idea más simple de la función de los Cubos OLAP dentro de una base de datos multidimensional, cabe destacar que cada una de las dimensiones o escalas del cubo corresponde básicamente a una jerarquía de datos. 

¿Qué es un cubo en BD?

 Si alguna vez les ha tocado programar un reporte o informe que tome la información de una base de datos sabrán que es un dolor de cabeza. Para hacerlo hay que definir de que tabla, de qué campo y con qué condiciones se saca cada cosa que muestra el reporte. Ahora piense que ese reporte que tanto trabajo le costó en vez de tener cortes o subtotales por cliente ahora lo quieren por tienda o producto, el de al lado lo quiere por familia y el departamento de compras lo quiere por proveedor con el añadido que lo quiere en dólares o Euros y con información de Costos y Margen.
 
Usted tendría prácticamente que hacer un nuevo reporte para cada caso, esto debido a la complejidad (que es normal) en las bases de datos transaccionales. Así es como nació la necesidad de las herramientas donde la información mostrada en el informe o reporte fuera manipulada dinámicamente.
 
No era fácil hacer que el reporte fuera manipulado dinámicamente debido a la complejidad de donde se sacaban los datos. Hacer un cambio de variables implicaba en vez de 1 tabla acceder a 4 o más. Para resolver esta situación los fabricantes de este tipo de software idearon extraer la información de la base de datos transaccional y colocarla en una base de datos que tuviera una estructura estándar para almacenar las diferentes variables de la información.
 
De esta forma el reporte podía ser cambiante debido a que la estructura donde se almacenaba el dato siempre era conocida. Como en el fútbol, se pusieron los datos “de pechito”.
 
Esto es lo que son los cubos. No son otra cosa que esas “bases de datos” de donde las herramientas OLAP toman la información que muestran; bases de datos que están diseñadas especialmente para que las herramientas puedan hacer esos cruces espectaculares de información en su pantalla.
Note que hacer cubos tiene un costo. Hay que tomar los datos de los sistemas transaccionales y llevarlos a esa base de datos. Esto se hace a lo mejor una vez al día, una vez cada hora o a lo mejor una vez al mes. Todo depende de la frecuencia con la que quiere que la información esté actualizada.
Es debido a esto que los cubos se procesan.
 
Hay muchas herramientas para hacer cubos y explotarlos, yo uso las herramientas de BITAM, uso Artus.
 
 
 
En la se muestra un modelo multidimensional, donde de hechos es la tabla ventas y las dimensiones son almacén, producto y tiempo.
 
Ejemplo de cubo: En la  se tiene una BD que maneja tres dimensiones: países, productos y períodos de entrega (tiempo).
Los datos pueden representarse como un cubo de tres dimensiones; cada valor individual de una celda representa la cantidad total de un producto vendido a un país en una fecha determinada.
 
 

Almacenamiento MOLAP (multidimensional OLAP)

Un sistema MOLAP usa una BD multidimensional (BDMD), en la que la información se almacena multidimensionalmente.
  • El sistema MOLAP utiliza una arquitectura de dos niveles: la BDMD y el motor analítico.
  • La BDMD es la encargada del manejo, acceso y obtención de los datos.
  • El nivel de aplicación es el responsable de la ejecución de las consultas OLAP.
  • El nivel de presentación se integra con el de aplicación y proporciona una interfaz a través de la cual los usuarios finales visualizan los análisis OLAP.
La información procedente de los sistemas transaccionales se carga en el sistema MOLAP. Una vez cargados los datos en la BDMD, se r
ealiza una serie de cálculos para obtener datos agregados a través de las dimensiones del negocio, poblando la estructura de la BDMD.
 
Luego de llenar esta estructura, se generan índices y se emplean algoritmos de tablas hash para mejorar los tiempos de accesos de las consultas. Una vez que el proceso de poblado ha finalizado, la BDMD está lista para su uso.
 
Los usuarios solicitan informes a través de la interfaz y la lógica de aplicación de la BDMD obtiene los datos. 
 

Almacenamiento ROLAP (Relational OLAP)

En ROLAP se utiliza una arquitectura de tres niveles. La BD relacional maneja el almacenamiento de datos, el motor OLAP proporciona la funcionalidad analítica, y alguna herramienta especializada es empleada para el nivel de presentación.
  
  • El nivel de aplicación es el motor OLAP, que ejecuta las consultas de los usuarios.
  • El motor OLAP se integra con el nivel de presentación a través del cual los usuarios realizan los análisis OLAP.
  • Después de que el modelo de datos para el DW se ha definido, los datos se cargan desde los sistemas transaccionales.
  • Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor OLAP, el cual transforma sus datos a consultas en SQL ejecutadas en las BD relacionales y sus resultados son devueltos a los usuarios.
  • La arquitectura ROLAP es capaz de usar datos precalculados (si estos están disponibles), o de generar dinámicamente los resultados desde la información elemental (menos resumida). Esta arquitectura accede directamente a los datos del DW y soporta técnicas de optimización para acelerar las consultas como tablas particionadas, soporte a la desnormalización, soporte de múltiples reuniones, precalculado de datos, índices etcétera.
 

Almacenamiento HOLAP (Hybrid OLAP)

Se han desarrollado soluciones de OLAP híbridas que combinan el uso de las arquitecturas ROLAP y MOLAP. En una solución con HOLAP, los registros detallados (los volúmenes más grandes) se mantienen en la BD relacional, mientras que los agregados lo hacen en un almacén MOLAP independiente (Ibarzábal, 2003).
 
 

Introducción

La propuesta de Codd consistía en realizar una disposición de los datos en vectores para permitir un análisis rápido. Estos vectores son llamados cubos. Disponer los datos en cubos evita una limitación de las bases de datos relacionales, que no son muy adecuadas para el análisis instantáneo de grandes cantidades de datos.
Las bases de datos relacionales son más adecuados para registrar datos provenientes de transacciones (conocido como OLTP o procesamiento de transacciones en línea). Aunque existen muchas herramientas de generación de informes para bases de datos relacionales, éstas son lentas cuando debe explorarse toda la base de datos.
 
  1. Por ejemplo, una empresa podría analizar algunos datos financieros por producto, por período, por ciudad, por tipo de ingresos y de gastos, y mediante la comparación de los datos reales con un presupuesto.
  • Estos parámetros en función de los cuales se analizan los datos se conocen como dimensiones. Para acceder a los datos sólo es necesario indexarlos a partir de los valores de las dimensiones o ejes.
  • El almacenar físicamente los datos de esta forma tiene sus pros y sus contras. Por ejemplo, en estas bases de datos las consultas de selección son muy rápidas (de hecho, casi instantáneas). Pero uno de los problemas más grandes de esta forma de almacenamiento es que una vez poblada la base de datos ésta no puede recibir cambios en su estructura. Para ello sería necesario rediseñar el cubo.
En un sistema OLAP puede haber más de tres dimensiones, por lo que a los cubos OLAP también reciben el nombre de hipercubos. Las herramientas comerciales OLAP tienen diferentes métodos de creación y vinculación de estos cubos o hipercubos (véase Tipos de OLAP en el artículo sobre OLAP).
 
 

Dimensiones y jerarquías

Cada una de las dimensiones de un cubo OLAP puede resumirse mediante una jerarquía. Por ejemplo si se considera una escala (o dimensión) temporal "Mayo de 2005" se puede incluir en "Segundo Trimestre de 2005", que a su vez se incluye en "Año 2005".
 
De igual manera, otra dimensión de un cubo que refleje una situación geográfica, las ciudades se pueden incluir en regiones, países o regiones mundiales; los productos podrían clasificarse por categorías, y las partidas de gastos podrían agruparse en tipos de gastos.
 
En cambio, el analista podría comenzar en un nivel muy resumido, como por ejemplo el total de la diferencia entre los resultados reales y lo presupuestado, para posteriormente descender en el cubo (en sus jerarquías) para poder observar con un mayor nivel de detalle que le permita descubrir en el cubo los lugares en los que se ha producido esta diferencia, según los productos y períodos.
 

 

Dispersión en cubos OLAP

Vincular o enlazar cubos es un mecanismo para superar la dispersión. Ésta se produce cuando no todas las celdas del cubo se rellenan con datos (escasez de datos o valores nulos). El tiempo de procesamiento es tan valioso que se debe adoptar la manera más efectiva de sumar ceros (los valores nulos o no existentes).
 
Por ejemplo los ingresos pueden estar disponibles para cada cliente y producto, pero los datos de los costos pueden no estar disponibles con esta cantidad de análisis. En lugar de crear un cubo disperso, a veces es mejor crear otro cubo distinto, pero vinculado, en el que un subconjunto de los datos se pueden analizar con gran detalle. La vinculación asegura que los datos de los dos cubos mantengan una coherencia.

Acceso y cálculo de un cubo OLAP

Los datos de los cubos pueden ser actualizados de vez en cuando, tal vez por personas diferentes de forma concurrente. Para solventar este problema a menudo es necesario bloquear partes de un cubo mientras otro usuario está escribiendo, para volver a calcular los totales en el cubo. Otras implementaciones añaden la posibilidad de mostrar una alerta que indique que los totales calculados previamente ya no son válidos tras los nuevos datos.
 
 También hay algunos productos que calculan los totales cuando se les necesita con los últimos datos producidos en el sistema.

Definición técnica

En teoría de bases de datos, un cubo OLAP es una representación abstracta de la proyección de una relación de un RDBMS (Sistema administrador de bases de datos relacionales). Dada una relación de orden N, se considera la posibilidad de una proyección que dispone de los campos X, Y, Z como clave de la relación y de W como atributo residual. Categorizando esto como una función se tiene que:
W : (X,Y,Z) → W
Los atributos X, Y, Z se corresponden con los ejes del cubo, mientras que el valor de W devuelto por cada tripleta (X, Y, Z) se corresponde con el dato o elemento que se rellena en cada celda del cubo.
 
Debido a que los dispositivos de salida (monitores, impresoras, ...) sólo cuentan con dos dimensiones, no pueden caracterizar fácilmente cuatro dimensiones, es más práctico proyectar "rebanadas" o secciones de los datos del cubo (se dice proyectar en el sentido clásico vector analítico de reducción dimensional, no en el sentido de SQL, aunque los dos conceptos son claramente análogos), tales como la expresión:
W : (X,Y) → W
Aunque no se conserve la clave del cubo (al faltar el parámetro Z), puede tener algún significado semántico, sin embargo, también puede que una sección de la representación funcional con tres parámetros para un determinado valor de Z también resulte de interés.
 
La motivación que hay tras OLAP vuelve a mostrar de nuevo el paradigma de los informes de tablas cruzadas de los sistema de gestión de base de datos de los 80. Se puede desear una visualización al estilo de una hoja de cálculo, donde los valores de X se encuentran en la fila $1, los valores de Y aparecen en la columna $A, y los valores de W: (X,Y) → W se encuentran en las celdas individuales a partir de la celda $B2 y desde ahí, hacia abajo y hacia la derecha. Si bien se puede utilizar el Lenguaje de Manipulación de Datos (o DML) de SQL para mostrar las tuplas (X,Y,W), este formato de salida no es tan deseable como la alternativa de tablas cruzadas. El primer método requiere que se realice una búsqueda lineal para cada par (X,Y) dado, para determinar el correspondiente valor de W, mientras que el segundo permite realizar una búsqueda más convenientemente permitiendo localizar el valor W en la intersección de la columna X apropiada con la fila Y correspondiente.
 
Se ha desarrollado el lenguaje MDX (MultiDimensional eXpressions o expresiones multidimensionales) para poder expresar problemas OLAP de forma fácil. Aunque es posible traducir algunas sus sentencias a SQL tradicional, con frecuencia se requieren expresiones SQL poco claras incluso para las sentencias más simples del MDX. Este lenguaje ha sido acogido por la gran mayoría de los proveedores de OLAP y se ha convertido en norma de hecho para estos sistemas.

Un ejemplo claro de ello podría ser el siguiente caso:

Dentro de una escala temporal para incluir datos determinados a un periodo de tiempo, que llevara el nombre de "Enero de 2009", seguramente incluirá un dimensión denominada "Primer Trimestre de 2009", la cual además incluirá otra dimensión llamada "Año 2009" y así sucesivamente, de acuerdo a las necesidades de cada empresa.
 
Asimismo, también pueden utilizarse otras dimensiones del cubo para recabar información referente a situaciones geográficas, clasificación de los productos por categorías, gastos realizados por la empresa, y demás.
 
Esta confluencia de la información permite llevar a cabo un análisis completo de diversas situaciones, para hallar las soluciones correctas a los problemas de los negocios.
 

COMPARACION


Cada sistema OLAP tiene ciertos beneficios (aunque existe desacuerdo acerca de las características específicas de los beneficios entre los proveedores).
Algunas implementaciones MOLAP son propensas a la "explosión" de la base de datos; este fenómeno provoca la necesidad de grandes cantidades de espacio de almacenamiento para el uso de una base de datos MOLAP cuando se dan ciertas condiciones: elevado número de dimensiones, resultados precalculados y escasos datos multidimensionales.
 
Las técnicas habituales de atenuación de la explosión de la base de datos no son todo lo eficientes que sería deseable.
 
Por lo general MOLAP ofrece mejor rendimiento debido a la especializada indexación y a las optimizaciones de almacenamiento. MOLAP también necesita menos espacio de almacenamiento en comparación con los especializados ROLAP porque su almacenamiento especializado normalmente incluye técnicas de compresión.
 
ROLAP es generalmente más escalable. Sin embargo, el gran volumen de preprocesamiento es difícil de implementar eficientemente por lo que con frecuencia se omite; por tanto, el rendimiento de una consulta ROLAP puede verse afectado.
 
Desde la aparición de ROLAP van apareciendo nuevas versiones de bases de datos preparadas para realizar cálculos, las funciones especializadas que se pueden utilizar tienen más limitaciones.
HOLAP (OLAP Híbrido) engloba un conjunto de técnicas que tratan de combinar MOLAP y ROLAP de la mejor forma posible. Generalmente puede pre-procesar rápidamente, escala bien, y proporciona una buena función de apoyo.
 
CONCLUSION:
 
Las bases de datos se encuentran presentes en nuestra vida cotidiana de la forma más simple que nos podamos imaginar, desde los registros en simples hojas hasta la mejor estructura moderna digitalizada, es nuestro deber detectar las oportunidades para automatizar la información y adecuarla a nuestras necesidades y la de los organismos en los que laboramos. Para esto, es importante conocer los diferentes tipos de bases de datos así como los modelos existentes.
 
 
 
BIBLIOGRAFIAS:
 
 
 

4 comentarios:

  1. Muy buena información y el video muuy bien solo que estaría mucho mejor si tuviera sonido. (:

    ResponderEliminar
  2. buena informacion, me ayudo a aclarar como buscar mi tema ya que no encontraba nada, je saludos a y buen video

    ResponderEliminar
  3. quedo padre tu informacion mas con el video y su diseño

    ResponderEliminar
  4. buena informacion comáñero, pero el fondo no tiene nada que ver con el tema. no crees.

    ResponderEliminar