Bases de datos multidimensionales y DataWarehouse

Vista previa del material en texto

Base de Datos 
Multidimensionales 
 
 
Data 
Warehousing 
 
 
 
 
 
 
 
 
 
 
INDICE 
 
 
 
· INTRODUCCION ............................................................................................................................... - 6 - 
· INFORMACIÓN HISTORICA....................................................................................................... - 8 - 
· VENTAJAS DE LAS BASES DE DATOS MULTIDIMENSIONALES ........................... - 10 - 
· LIMITACION CON RESPECTO AL TAMAÑO DE LA BASE DE DATOS................... - 11 - 
· FORMA DE ABORDAR EL PROBLEMA................................................................................. - 12 - 
· TECNICAS DE DISEÑO................................................................................................................ - 15 - 
PROCESOS Y METODOLOGIAS.............................................................................................- 15 - 
· MODELAMIENTO MULTIDIMENCIONAL............................................................................ - 17 - 
MODELOS DE DATOS....................................................................................................................................- 18 - 
CARACTERÍSTICAS DEL MER.......................................................................................................................- 19 - 
CARACTERÍSTICAS DEL MODELO MULTIDIMENSIONAL..............................................................................- 19 - 
Tablas DW: .......................................................................................................................................... - 19 - Tablas Fact:.................................................................................................................................................- 19 - 
Tablas Lock_up:.........................................................................................................................................- 20 - 
Esquemas DW:................................................................................................................................... - 21 - Esquema Estrella.......................................................................................................................................- 22 - 
Esquema Snowflake.................................................................................................................................- 23 - 
Profundizaciones de Diseño........................................................................................................... - 24 - La Dimensión Tiempo ..............................................................................................................................- 24 - 
Dimensiones que varían lentamente en el tiempo........................................................................- 24 - 
Niveles...........................................................................................................................................................- 24 - 
Sobre Jerarquías........................................................................................................................................- 24 - 
· BD RELACIONALES V/S............................................................................................................ - 26 - 
BD MULTIDIMENSIONALES............................................................................................................... - 26 - 
ROLAP VS MOLAP ....................................................................................................................................- 27 - 
¿Cuál es mejor ROLAP O MOLAP?............................................................................................... - 29 - Factores de procesamiento....................................................................................................................- 29 - 
Almacenaje..................................................................................................................................................- 30 - 
Consultas......................................................................................................................................................- 30 - 
¿Por qué recomiende MOLAP?..............................................................................................................- 30 - 
¿Por qué recomiende ROLAP?...............................................................................................................- 30 - 
¿Por qué no recomendar ROLAP?........................................................................................................- 31 - 
TRANSFORMACIÓN DE DB RELACIONALES A MULTIDIMENSIONALES CON DW:.....................................- 33 - 
· DEFINICION DE DATAWAREHOUSE ................................................................................... - 35 - 
· SISTEMAS DE INFORMACIÓN ................................................................................................ - 38 - 
· CARACTERÍSTICAS DE UN DATA WAREHOUSE............................................................ - 40 - 
ORIENTADO A TEMAS...................................................................................................................................- 40 - INTEGRACIÓN................................................................................................................................................- 42 - Fuentes Múltiples.........................................................................................................................................- 42 - 
Codificación.......................................................................................................................................................................- 42 - 
Medida de atributos..................................................................................................................................- 43 - 
Proceso de integración: transformación de Datos................................................................ - 45 - 
DE TIEMPO VARIANTE..................................................................................................................................- 46 - 
NO VOLATIL...................................................................................................................................................- 47 - 
· ESTRUCTURA DEL DATA WAREHOUSE.............................................................................. - 49 - 
DETALLE DE DATOS ACTUALES ....................................................................................................................- 49 - 
DETALLE DE DATOS ANTIGUOS....................................................................................................................- 49 - 
DATOS LIGERAMENTE RESUMIDOS..............................................................................................................- 49 - 
META DATA....................................................................................................................................................- 51 - 
· COMPONENTES DE UN DATA WAREHOUSE .................................................................... - 54 - 
HARDWARE....................................................................................................................................................- 54 - 
SOFTWARE DE ALMACENAMIENTO (SGBD)...............................................................................................- 55 - 
SOFTWARE DE EXTRACCIÓN Y MANIPULACIÓN DE DATOS .........................................................................- 55 - 
HERRAMIENTAS MIDDLEWARE.....................................................................................................................- 56 - 
· OPERACIONES EN UN DATA WAREHOUSE...................................................................... - 58 - 
SISTEMAS OPERACIONALES.........................................................................................................................-58 - 
EXTRACCIÓN, TRANSFORMACIÓN Y CARGA DE LOS DATOS......................................................................- 59 - 
META DATA....................................................................................................................................................- 59 - 
ACCESO DE USUARIO FINAL.........................................................................................................................- 59 - 
PLATAFORMA DEL DATA WAREHOUSE..........................................................................................................- 60 - 
DATOS EXTERNOS........................................................................................................................................- 60 - 
· FLUJO DE DATOS ........................................................................................................................... - 61 - 
· TECNICAS DE EXPLOTACION DE UN DATA WAREHOUSE....................................... - 63 - 
SISTEMAS OLAP ..........................................................................................................................................- 64 - 
CONSULTAS O INFORMES LIBRES (QUERY & REPORTING) ......................................................................- 64 - 
DATA MINIG (MINERÍA DE DATOS)............................................................................................................- 65 - 
· DATA MART V/S DATA WAREHOUSE............................................................................... - 67 - 
· SISTEMA OPERACIONAL V/S DATAWAREHOUSE....................................................... - 70 - 
DESTINOS Y USOS........................................................................................................................................- 70 - 
AMBIENTE OPERACIONAL V/S AMBIENTE DATAWAREHOUSE...................................................................- 71 - 
· USO DEL DATAWAREHOUSE.................................................................................................... - 74 - 
MANERAS DIFERENTES DE USO DE DATOS .................................................................................................- 74 - 
Los usuarios generan un procesamiento no predecible complejo.................................. - 74 - 
Las consultas de los usuarios accedan a cantidades grandes de datos....................... - 74 - 
Las consultas de los usuarios no tienen tiempos de respuesta críticos ....................... - 75 - 
¿QUIÉNES Y PARA QUÉ LO USAN? ...............................................................................................................- 79 - 
Comercio Minorista........................................................................................................................... - 79 - 
Manufactura de Bienes de Consumo Masivo........................................................................... - 80 - Transporte de Cargas y Pasajeros.............................................................................................. - 81 - Telecomunicaciones....................................................................................................................................- 81 - 
· IMPACTOS DW.................................................................................................................................- 82 - 
IMPACTOS HUMANOS...................................................................................................................................- 82 - 
Efectos sobre la gente de la empresa: ..................................................................................... - 82 - 
IMPACTOS EMPRESARIALES..........................................................................................................................- 83 - 
Efectos sobre procesos y decisiones empresariales............................................................ - 83 - 
IMPACTOS TÉCNICOS DE DW.....................................................................................................................- 84 - 
· COSTOS Y VALOR DEL DATAWAREHOUSE ...................................................................... - 85 - 
COSTOS DE UN DW ....................................................................................................................................- 85 - 
Costos de construcciones............................................................................................................... - 85 - 
RRHH:............................................................................................................................................................- 85 - 
Tiempo:.........................................................................................................................................................- 85 - 
Tecnología: ..................................................................................................................................................- 85 - 
Costos de Operación ........................................................................................................................ - 86 - Evolutivos:...................................................................................................................................................- 86 - 
Crecimiento:................................................................................................................................................- 86 - 
Cambios: ......................................................................................................................................................- 86 - 
Cambios en el ambiente empresarial: .........................................................................................- 86 - 
Cambios en la tecnología: ................................................................................................................- 86 - 
VALOR DEL DW............................................................................................................................................- 87 - 
COSTOS V/S VALOR DE DW.......................................................................................................................- 87 - 
• 	ORGANIZACIÓN DE UN PROYECTO..................................................................................... - 89 - 
PLANIFICACIÓN DE UN DATA WAREHOUSE ................................................................................................- 89 - 
Establecer una asociación de usuarios, gestión y grupos.................................................. - 89 - 
Seleccionar una aplicación piloto con una alta probabilidad de éxito........................... - 89 - 
Construir prototipos rápida y frecuentemente....................................................................... - 89 - 
Implementación incremental........................................................................................................ - 90 - 
Reportar activamente y publicar los casos exitosos............................................................ - 90 - 
DESARROLLO DE UN DATA WAREHOUSE....................................................................................................- 90 - 
Primera.................................................................................................................................................. - 91 - 
Segunda................................................................................................................................................ - 91 - 
Tercera .................................................................................................................................................. - 91 - 
En conclusión...................................................................................................................................... - 92 - DISEÑO DE UN DATA WAREHOUSE.............................................................................................................- 92 - 
GESTIÓN DE UN DATA WAREHOUSE...........................................................................................................-93 - 
· TENDENCIAS TECNOLÓGICAS Y DE MERCADO............................................................. - 94 - 
TENDENCIAS HACIA HERRAMIENTAS ESPECIALIZADAS: ............................................................................- 94 - 
WEBHOUSING ...............................................................................................................................................- 94 - 
USO GENERALIZADO DE DATA MARTS........................................................................................................- 94 - 
· CONCLUSION ................................................................................................................................... - 95 - 
· BIBLIOGRAFIA................................................................................................................................ - 96 - 
 
 INTRODUCCION 
 
No cabe duda que los sistemas de información son una herramienta esencial al momento de administrar los datos de cualquier tipo de empresa. Para esto las BD se han convertido en un elemento imprescindible al momento de relacionar toda la información, dejando la idea de los ficheros como un pasado muy antiguo. 
Es así como con el paso de los años este “concepto” ha ido evolucionando a través del tiempo, dejando el modelo relacional de Codd como una “base” para otros tipos de bases de datos como lo son las multidimensionales. 
Pero ¿Qué son las bases de datos multidimensionales? Esta es una respuesta compleja que trataremos de resolver a lo largo de este informe. En un principio podemos imaginarlas como una prolongación del modelo relacional en la cual las consultas son especificas con más un campo. Por ejemplo poder consultar las ventas a través del tiempo en una zona en particular. 
Para trabajar con bases de datos multidimensionales también debemos entender lo que es un data warehouse: un “almacén de datos” que viene a ser el espacio físico donde se contiene la información (servidor). Pero mas que ser un servidor un DW es un concepto que nos sirve implementar las BD multidimensionales, otorgando rapidez a la consulta que en el caso de este tipo de BD son muchas, pero todas parecidas además de tener información de otras BD. 
En el presente informe se pretende hacer un análisis exhaustivo de lo que son las bases de datos multidimensionales, los data warehouse y todo aquello que tenga relación con el tema. Además iremos comparando cada vez que sea necesario este tipo de bases de datos con lo que estamos aprendiendo en clases: modelo relacional , BD operacionales entre otros. 
 
 
 
BASE DE DATOS MULTIDIMENSIONALES 
Un buen trabajo debe dejar claro conceptos que son aplicables a lo largo de todo el informe y que tienen un carácter de primordial antes de entrar en materia directamente con el tema discutido, en este contexto nos enfocamos a la definición de conceptos básicos en el mundo de las bases de datos, en especia en aquellas que reciben el nombre de multidimensionales. 
Lo primero es el concepto de dato e información en esencia la información es un conjunto de datos que están relacionados y ordenados en forma lógica para que así se constituyan en una manera eficiente de consulta de la información que estos están almacenando. De lo anterior resulta claro que se nos esta presentando un nuevo concepto que tiene que ver con el manejo de los datos ya guardados, la forma de guardarlos y el como tener un acceso rápido a ellos, a esto es lo que se le llama un base de datos que es una colección de archivos interrelacionados y creados por un sistema de gestión de bases de datos (SGBD). 
Finalmente, relacionando estos dos componentes con un hardware que sostenga la información se forma lo que se denomina un Sistema de Base de Datos. 
 
 
 
 
 
 	 2 
Base de Datos Multidimensionales y DataWarehouse 
 
 
 	 6 
Base de Datos Multidimensionales y DataWarehouse 
INFORMACIÓN HISTORICA 
Nuestro enfoque ahora es orientado a las bases de datos multidimensionales que son aquellas con grandes cantidades de información, las dimensiones son criterios con los que se clasifica la información y que ofrecen un índice a los datos mediante una lista de valores. 
Como se ha dicho en clases, y se puede ver en algunos textos, lo antecesores de los sistemas de bases de datos son los sistemas de ficheros, que aun siguen en uso en algunas partes. Pero por otros lados se dice que los sistemas de bases de datos tienen sus raíces en el proyecto estadounidense Apolo de mandar al hombre a la luna, en los años sesenta. En aquella época, no había ningún sistema que permitiera gestionar la inmensa cantidad de información que requería el proyecto (cosa que solucionan las BDM). La primera empresa encargada del proyecto, NAA (North American Aviation), desarrolló un software denominado GUAM (General Update Access Method) que estaba basado en el concepto de que varias piezas pequeñas se unen para formar una pieza más grande, y así sucesivamente hasta que el producto final está ensamblado. A mediados de los sesenta, IBM se unió a NAA para desarrollar GUAM en lo que ahora se conoce como IMS (Information Management System). El motivo por el cual IBM restringió IMS al manejo de jerarquías de registros fue el de permitir el uso de dispositivos de almacenamiento, más exactamente las cintas magnéticas. Que estaban de moda por aquella época. 
 En 1970 en los laboratorios de investigación de IBM, escribió un artículo presentando el modelo relacional. En este artículo, presentaba también los inconvenientes de los sistemas previos, el jerárquico y el de red, que no han sido descritos acá pues no van al caso. Entonces, se comenzaron a desarrollar muchos sistemas relacionales, apareciendo los primeros a finales de los setenta y principios de los ochenta. Uno de los primeros es System R, de IBM, que se desarrolló para probar la funcionalidad del modelo relacional, proporcionando una implementación de sus estructuras de datos y sus operaciones. Esto condujo a dos grandes desarrollos: 
El desarrollo de un lenguaje de consultas estructurado denominado SQL, que se ha convertido en el lenguaje estándar de los sistemas relaciónales. 
La producción de varios SGBD relacionales durante los años ochenta, como DB2 y SLQ/DS de IBM, y ORACLE de ORACLE 
Corporación. 
Los SGBD relacionales constituyen la segunda generación de los SGBD. Sin embargo, el modelo relacional también tiene sus fallos, siendo uno de ellos su limitada capacidad al modelar los datos. Se ha hecho mucha investigación desde entonces tratando de resolver este problema. En 1976, Chen presentó el modelo entidad-relación, que es la técnica más utilizada en el diseño de bases de datos. En 1979, Codd intentó subsanar algunas de las deficiencias de su modelo relacional con una versión extendida denominada RM/T (1979) y más recientemente RM/V2 (1990). Los intentos de proporcionar un modelo de datos que represente al mundo real de un modo más fiel han dado lugar a los modelos de datos semánticos. Como respuesta a la creciente complejidad de las aplicaciones que requieren bases de datos, han surgido tres nuevos modelos: el modelo de datos orientado a objetos, el modelo multidimencional y el modelo relacional extendido. Sin embargo, a diferencia de los modelos que los preceden, la composición de estos modelos no está del todo clara. Esta evolución representa la tercera generación de los SGBD. 
 
VENTAJAS DE LAS BASES DE DATOS MULTIDIMENSIONALES 
¿Cuáles fueron las ventas del producto ABC el mes pasado? ¿Cómo se comparan con las obtenidas en el mismo mes, pero del año anterior? ¿Cuáles fueron las ventas del producto en la región norte, y dentro de dicha región en el territorio ZXY? Estas son algunas de las preguntas que muchos profesionales se hacen periódicamente a la hora de gestionar su negocio. El rápido acceso a esta información es vital para reaccionar ante tendencias inesperadas y realizar eficazmente las acciones oportunas. Una de las grandes ventajas de las bases de datos multidimensionales es la rapidezcon la que se puede acceder a información agregada; por ejemplo: 
¿Cuáles fueron las ventas del producto ABC en la región norte? En una base de datos relacional se tendrían que sumar todas las ventas realizadas dentro de dicha región para el producto indicado. 
El tiempo que se tardaría en responder dependería del número de operaciones realizadas. Sin embargo, en una base de datos multidimensional, la respuesta sería inmediata, ya que guarda la información agregada y se accede directamente a ella. Este tipo de bases de datos soportan múltiples vistas de agrupaciones de datos, que permiten a los usuarios analizar las relaciones entre diferentes categorías. El número de vistas se establece en el esquema de la base de datos. Conceptualmente, se suele utilizar la idea de un cubo para representar las dimensiones de datos disponibles para el usuario. En el caso anterior, las ventas, podrían verse desde la dimensión geográfica, de tiempo y tipo de producto. La variable ventas sería del tipo “measure”, mientras que el resto se denominan “feature”. Adicionalmente, se pueden definir jerarquías y niveles dentro de una dimensión (por ejemplo: dentro de la jerarquía geográfica nos encontraríamos con los niveles región y territorio). 
 
 
 
 
 
 
 	 2 
Base de Datos Multidimensionales y DataWarehouse 
 
 
 	 2 
Base de Datos Multidimensionales y DataWarehouse 
 
 
 	 7 
Base de Datos Multidimensionales y DataWarehouse 
LIMITACION CON RESPECTO AL TAMAÑO DE LA BASE DE DATOS 
Hay un concepto erróneo común en el mercado sobre que el tamaño de la base de datos está principalmente limitado por el número máximo de dimensiones soportadas. La limitación real, sin embargo, casi siempre es el número de celdas, no el número de dimensiones. Además, no todas las dimensiones se crean igual. Algunos vendedores soportan las jerarquías simples dentro de las dimensiones. Otros soportan jerarquías complejas múltiples dentro de las dimensiones. Basta decir que una base de datos ocho. dimensional que usa un producto OLAP puede reducirse a sólo tres o cuatro dimensiones con otro. 
En general, como el número de dimensiones aumenta, el número de celdas en la base de datos se incrementa exponencialmente. Por ejemplo, una base de datos bidimensional con 100 Productos y 100 Regiones tendría 10,000 celdas. Si agregamos una tercera dimensión para Tiempo con 52 semanas, tenemos ahora 520,000 celdas. Agregando una cuarta dimensión para Real, Presupuesto, Variación y la Pronostico nos lleva a 2,080,000 celdas. Agregando una quinta dimensión para guardar 10 Tipos de Cliente tenemos el total de 20,800,000. ¡Una base de datos de 16 dimensiones con sólo cinco miembros en cada dimensión tendrían encima de 152 mil millones (152,587,890,625) de celdas! Esto nos podría resultar atroz al momento de querer trabajar con los datos. 
La mayoría de los servidores OLAP comerciales acierta el límite de celdas mucho tiempo antes de que ellos corran fuera de dimensiones. Por ejemplo, un servidor OLAP comercial proclama soportar 32 dimensiones, pero tiene un límite de aproximadamente dos mil millones de celdas. Con sólo dos miembros en cada dimensión, una base de datos de 32 dimensiones tendría 4.3 mil millones de celdas. Así, aun cuando cada dimensión tenga sólo dos miembros, todavía no podría usar todas las 32 dimensiones debido a la limitación de dos mil millones de celdas. En la práctica, la mayoría de las dimensiones tienen muchos más de dos miembros. 
 
FORMA DE ABORDAR EL PROBLEMA 
Disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio. 
Para realizar este tipo de análisis multidimensional debemos utilizar 
lo que se conoce como Bases de Datos Multidimensionales. Este tipo de BD diseñada para optimizar la consulta y almacenamiento de grandes 	volúmenes 	de 	datos 	que 	están íntimamente relacionados y que deben verse y analizarse desde distintas perspectivas. A cada perspectiva se le denomina dimensión. Obtener respuestas a las preguntas típicas de una empresa exige con cierta frecuencia ver los datos bajo diferentes perspectivas. 
Este nuevo enfoque propone una estructura de almacenamiento basada en hiper-cubos en lugar de tablas planas. Para entender mejor el 
concepto de Base de Datos Multidimencional y de dimensiones o perspectivas en este entorno vamos a utilizar un ejemplo de un sistema de gestión de libros. 
Las jerarquías que se podrían manejar para el número de dimensiones serán: zona geográfica, tipo de producto y tiempo de resolución. La visión general de la información de ventas para estas dimensiones definidas, la representaremos, gráficamente como el cubo de la derecha. 
A su vez estas dimensiones tienen una jerarquía, interpretándose en el cubo como que cada cubo elemental es un dato, del que se puede extraer información agregada. En el ejemplo anterior podría ser: 
 
 
ZONAS GEOGRAFICAS ZONA NORTE ARICA 
 IQUIQUE 
 ANTOFAGASTA 
 
LIBRERÍA UNIVERSITARIA 
 
 
 
PRODUCTO LIBROS LITERATURA 
BASES DE DATOS 
 ÉTNICOS 
 CUENTOS 
 
 
 
 
TIEMPO AÑO 2004 1º SEMESTRE 
SEPTIEMBRE DE 2004 2ª SEMESTRE 
 
 
En forma más general la estructura anteriormente descrita podría verse como en la figura del lado derecho, en la cual se indica claramente las sub-divisiones que se tienen en la respuesta a una pregunta. 
Y así por ejemplo se podría querer analizar la evolución de las ventas en Antofagasta de libros de literatura por meses desde Febrero de 2003 hasta Septiembre de 2004. Ello es fácil de obtener si la información de ventas se ha almacenado en una base de datos 	multidimencional, 	definiendo 	estas jerarquías y estas dimensiones de negocio. 
En general tratamos de presentar una forma eficiente de abordar los problemas que 
se pueden solucionar con una base de datos multidimensional, partiendo 
 
 
 
 
 	 9 
Base de Datos Multidimensionales y DataWarehouse 
 
 
 	 2 
Base de Datos Multidimensionales y DataWarehouse 
 
 
 	 11 
Base de Datos Multidimensionales y DataWarehouse 
por el reconocimiento del problema, el cual esta orientado a escribir los requerimiento de los datos en buena forma y coherentemente con lo que en la realidad ocurre, después de eso y una vez elegido el sistema de gestión de la base le sigue el modelo dimensionan y las siguientes etapas conocidas ya en el curso de Base de Datos 2004-2 . 
 
 
 
 
 
 
 
 TECNICAS DE DISEÑO 
Las técnicas de diseño pueden clasificarse en cuatro niveles según el tipo de problemas que abordan. Se parte de técnicas que manipulan objetos de un modelo de datos sin aportar ningún criterio de diseño (técnicas básicas). A medida que se aumenta en el nivel, las técnicas correspondientes introducen elementos orientados a mejorar la productividad y calidad del diseño. Por esto, las técnicas de los niveles superiores se centran en tipos de sistemas de información o en contextos particulares de aplicación de sistemas de información. 
 
	PROCESOS Y METODOLOGIAS 
	ESTRATEGIAS 
	TECNICAS ESPECIALIZADAS 
	TÉCNICAS BÁSICAS 
 
El nivel inferior corresponde a técnicas básicas de diseño para el modeloelegido, por ejemplo técnicas de diseño relacional para creación de estructuras del modelo (tablas, restricciones de integridad, etc.). El siguiente nivel corresponde a técnicas especializadas para un determinado tipo de sistema de información, por ejemplo bases de datos centralizadas, federadas, distribuidas, multidimensionales etc. Cada sistema tiene sus propias técnicas especializadas de diseño, por ejemplo en bases de datos distribuidas existen técnicas para fragmentar tablas, tanto horizontal como verticalmente. 
En un nivel superior se ubican las estrategias de diseño, orientadas a encarar globalmente un problema de diseño. Por ejemplo utilizar estrategias top-down o bottom-up para relevar requerimientos funcionales del sistema, o resolver la integración de esquemas en un ambiente federado con estrategias local-as-view o global-as-view. Las estrategias de diseño abstraen mecanismos para encarar problemas generales de diseño, y decidir qué técnicas conviene aplicar para la resolución de subproblemas concretos. 
 En el nivel superior se ubican los modelos de proceso y metodologías de diseño. Los trabajos en este nivel resuelven la totalidad del problema, brindando metodologías, procesos o algoritmos que descomponen el problema en partes más pequeñas y muestran como atacar cada uno de los sub-problemas. Generalmente en este nivel es muy importante el orden en que se resuelven esos sub-problemas, mientras que las estrategias sólo se encargan de la resolución aislada de cada uno. 
 
 MODELAMIENTO MULTIDIMENCIONAL 
Modelamiento Dimensional es una técnica para modelar bases de datos simples y entendibles al usuario final. La idea fundamental es que el usuario visualice fácilmente la relación que existe entre las distintas componentes del modelo. 
Consideremos un punto en el espacio. El espacio se define a través de sus ejes coordenados (por ejemplo X, Y, Z). Un punto cualquiera de este espacio quedará determinado por la intersección de tres valores particulares de sus ejes. 
Si se le asignan valores particulares a estos ejes. Digamos que el eje X representa Productos, el eje Y representa el Mercado y, el eje Z corresponde al Tiempo. Se podría tener por ejemplo, la siguiente combinación: 
Producto = Maderas, Mercado = Concepción, Tiempo = Septiembre2004. 
La intersección de estos valores nos definirá un solo punto en nuestro espacio. Si el punto que buscamos, lo definimos como la cantidad de madera vendida, entonces se tendrá un valor específico y único para tal combinación. 
En el modelo multidimensional cada eje corresponde a una dimensión particular. Entonces la dimensionalidad de nuestra base estará dada por la cantidad de ejes (o dimensiones) que le asociemos. 
Cuando una base puede ser visualizada como un cubo de tres o más dimensiones, es más fácil para el usuario organizar la información e imaginarse en ella cortando y rebanando el cubo a través de cada una de sus dimensiones, para buscar la información deseada. 
Para entender más el concepto, retomemos el ejemplo anterior. La descripción de una organización típica es: “Nosotros vendemos productos en varios mercados, y medimos nuestro desempeño en el tiempo”: Un diseñador dimensional lo verá como: “Nosotros vendemos productos en varios mercados, y medimos nuestro desempeño en el tiempo. Donde cada palabra subrayada corresponde a una dimensión. 
Esto puede visualizarse como un cubo (Figura 3), donde cada punto dentro del cubo es una intersección de coordenadas definidas por los lados de éste (dimensiones). Ejemplos de medidas son: unidades producidas, unidades vendidas, costo de unidades producidas, ganancias($) de unidades vendidas, etc. 
 
Modelos de Datos 
Un factor importante durante todo el diseño de una base de datos multidimensional, fue expresado por Codd en 1983: “Ustedes pueden pensar que el significado de los datos es simple...pero no es así”.Para construir una base de datos multidimensional se debe primero tener claro que existe una diferencia entre la estructura de la información y la semántica de la información, y que esta última es mucho más difícil de abarcar y que también es precisamente con ella con la que se trabaja en la construcción de una base de datos multidimensional. 
Aquí se encuentra la principal diferencia entre los sistemas operacionales y una base de datos multidimensional: 
 Cada uno de ellos es sostenido por un modelo de datos diferente. Los sistemas operacionales se sustentan en el Modelo Entidad Relación (MER) y las bases de datos multidimensionales trabajan con el Modelo Multidimensional. 
Características del MER 
· Maneja la redundancia fuera de los datos. Por lo tanto realizar un cambio en la base significa tocarla en un solo lugar. 
· Divide los datos en entidades, las que son representadas como tablas en una base de datos. 
· Los MER crecen fácilmente, haciéndose más y más complejos. 
· Se puede apreciar la existencia de muchos caminos para ir de una tabla a otra. Sería natural pensar que al tener diversos caminos para llegar desde una tabla a otra, cualquiera de ellos entregaría el mismo resultado, pero lamentablemente esto no siempre sucede así. 
· El diagrama se visualiza simétrico, donde todas las tablas se parecen, sin distinguir a priori la importancia de unas respecto a otras. No es fácil de entender tanto para usuarios como para los diseñadores. 
 
Características del Modelo Multidimensional 
En general, la estructura básica de una base de datos multidimensional para el Modelo Multidimensional está definida por dos elementos: esquemas y tablas. 
Tablas DW: 
 Como cualquier base de datos relacional, una base de datos multidimensional se compone de tablas. Hay dos tipos básicos de tablas en el Modelo Multidimensional: 
Tablas Fact: 
Contienen los valores de las medidas de negocios, por ejemplo: 
ventas promedio en dólares, número de unidades vendidas, etc. 
Es la tabla central en un esquema dimensional. Es en ella donde se almacenan las mediciones numéricas del negocio. Estas medidas se 
hacen sobre el grano, o unidad básica de la tabla. 
El grano o la granularidad de la tabla queda determinada por el nivel de detalle que se almacenará en la tabla. Por ejemplo, para el caso de producto, mercado y tiempo antes visto, el grano puede ser la cantidad de madera vendida ‘mensualmente’. El grano revierte las unidades atómicas en el esquema dimensional. 
Cada medida es tomada de la intersección de las dimensiones que la definen. Idealmente está compuesta por valores numéricos, continuamente evaluados y aditivos. La razón de estas características es que así se facilita que los miles de registros que involucran una consulta sean comprimidos en unas pocas líneas en un set de respuesta. 
La clave de la tabla fact recibe el nombre de clave compuesta o concatenada debido a que se forma de la composición (o concatenación) de las llaves primarias de las tablas dimensionales a las que está unida. Así entonces, se distinguen dos tipos de columnas en una tabla fact: columnas fact y columnas key. 
Donde la columna fact es la que almacena alguna medida de negocio y una columna key forma parte de la clave compuesta de la tabla. 
 
Tablas Lock_up: 
Contienen el detalle de los valores que se encuentran asociados a la tabla Fact. 
Estas tablas son las que se conectan a la tabla fact, son las que alimentan a la tabla fact. Una tabla lock_up almacena un conjunto de valores que están relacionados a una dimensión particular. Tablas lock_up no contienen hechos, en su lugar los valores en las tablas lock_up son los elementos que determinan la estructura de las dimensiones. Así entonces, en ellas existe el detalle de los valores de la dimensión respectiva. 
Una tabla lock_up está compuesta de una primary key que identifica unívocamente una fila en la tabla junto con un conjunto de atributos, y dependiendo del diseño del modelo multidimensional puede existir una foreign key que determina su relación con otra tabla lock_up. Para decidir si un campo de datos es un atributo o un hecho se analiza la variaciónde la medida a través del tiempo. Si varía continuamente implicaría 
tomarlo como un hecho, caso contrario será un atributo. 
Esquemas DW: 
 la colección de tablas en una base de datos multidimensional se conoce como Esquema. Los esquemas caen dentro de dos categorías básicas: esquemas estrellas y esquemas snowflake. 
 
Esquema Estrella. 
En general, el modelo multidimensional también se conoce con el nombre de esquema estrella, pues su estructura base es similar: una tabla central y un conjunto de tablas que la atienden radialmente. (Ver figura). 
El esquema estrella deriva su nombre del hecho que su diagrama forma una estrella, con puntos radiales desde el centro. El centro de la estrella consiste de una o más tablas fact, y las puntas de la estrella son las tablas lock_up. 
Este modelo entonces, resulta ser asimétrico, pues hay una tabla dominante en el centro con varias conexiones a las otras tablas. Las tablas Lock-up tienen sólo la conexión a la tabla fact y ninguna más. 
 
 
 
 
Esquema Snowflake. 
La diferencia del esquema snowflake comparado con el esquema estrella, está en la estructura de las tablas lock_up: las tablas lock_up en el esquema snowflake están normalizadas. Cada tabla lock_up contiene sólo el nivel que es clave primaria en la tabla y la foreign key de su parentesco del nivel más cercano del diagrama. 
 
 
 
 
 
 
 
Profundizaciones de Diseño 
La Dimensión Tiempo 
Virtualmente se garantiza que cada base de datos multidimensional tendrá una tabla dimensional de tiempo, debido a la perspectiva de almacenamiento histórica de la información. Usualmente es la primera dimensión en definirse, con el objeto de establecer un orden, ya que la inserción de datos en la base de datos multidimensional se hace por intervalos de tiempo, lo cual asegura un orden implícito. 
Dimensiones que varían lentamente en el tiempo 
Son aquellas dimensiones que se mantienen “casi” constantes en el tiempo y que pueden preservar la estructura dimensional independiente del tiempo, con sólo agregados menores relativos para capturar la naturaleza cambiante del tiempo. 
Niveles 
Un nivel representa un nivel particular de agregación dentro de una dimensión; cada nivel sobre el nivel base representa la sumarización total de los datos desde el nivel inferior. Para un mejor entendimiento, veamos el siguiente ejemplo: consideremos una dimensión Tiempo con tres niveles: Mes, Semestre, Año. El nivel Mes representa el nivel base, el nivel Semestre representa la sumarización de los totales por Mes y el nivel A ño representa la sumarización de los totales para los Semestres. 
Sobre Jerarquías 
A nivel de dimensiones es posible definir jerarquías, las cuales son grupos de atributos que siguen un orden preestablecido. Una jerarquía implica una organización de niveles dentro de una dimensión, con cada nivel representando el total agregado de los datos del nivel inferior. Las jerarquías definen cómo los datos son sumarizados desde los niveles más bajos hacia los más altos. Una dimensión típica soporta una o más jerarquías naturales. Una jerarquía puede pero no exige contener todos los valores existentes en la dimensión. 
Se debe evitar caer en la tentación de convertir en tablas dimensionales separadas cada una de las relaciones muchos-a-uno presentes en las jerarquías. Esta descomposición es irrelevante en el planeamiento del espacio ocupado en disco y sólo dificulta el entendimiento de la estructura para el usuario final, además de destruir 
el desempeño del browsing. 
Ejemplo: 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 BD RELACIONALES V/S 
BD MULTIDIMENSIONALES 
El sistema de gestión de bases de datos empleado por un sistema DataWarehouse habitualmente es una base datos relacional (RDBMS) o una base datos multidimensional (MDBMS). Las bases de datos relacionales son empleadas para la construcción de grandes DWs corporativos o pequeños DWs departamentales mientras que las bases de datos multidimensionales se suelen utilizar para DWs departamentales. Por otra parte, la base de datos de los DWs tiene requerimientos por encima de los sistemas operacionales. Los factores claves a considerar son la escalabilidad (tamaño de la base de datos, complejidad de las consultas y numero de usuarios) y el rendimiento (aplicaciones de administración y procesamiento de consultas complejas). A medida que el tamaño de la base de datos y la complejidad de de las consultas se incrementa, es necesario considerar la utilización de arquitecturas de hardware y sistemas de gestión de base de datos paralelas para lograr un rendimiento satisfactorio. 
Las bases de datos relacionales encuentran en su flexibilidad y potencial para las consultas adecuadas, uno de sus puntos fuertes. Las bases de datos relacionales son sabidamente más flexibles cuando se utilizan con una estructura de los datos normalizados. Una consulta típica OLAP, sin embargo, esta atraviesa las relaciones diversas y requieren operaciones diversas de la ensambladura para poder acceder a estos datos. El funcionamiento de los sistemas de la base de datos relacional tradicional es mejor para las consultas basadas en llaves de eso las consultas basadas en contenido. 
Para tomar con cuidado los requisitos de este tipo de transacciones, los SGBDs relacionales han agregado a las funcionalidades sus productos. Estas funcionalidades incluyen extensiones a las estructuras del almacenaje y los operadores relacionales, como también los proyectos especializados de indexación. 
La mayoría de los accesos a los almacenes de información explora la naturaleza multidimensional de los datos. Por lo tanto, estructurando los datos en bases de datos relacionales tradicionales en los proyectos del tipo estrella o el copo de nieve se convirtió en el subir a un nivel suficientemente común. Estos proyectos pueden utilizar las tablas múltiples y técnicas para simular una estructura multidimensional. 
También otro mecanismo no emparentado es posible utilizar alguno para almacenar algo de agregaciones, mientras que otros se consiguen el dinámicamente. Esto que surge, goza de las ventajas de un mecanismo relacional, sacando la ventaja del cálculo anterior con ayuda de algunas agregaciones. 
 Alternadamente, las bases de datos multidimensionales permiten para manipular objetos multidimensionales directamente. Las dimensiones que se crean, identifican la estructura de la base, puesto que la forma para agregar una nueva dimensión puede ser laboriosa Algunas bases de datos multidimensionales requieren una recarga completa de los datos, cuando ocurre una reorganización. Por lo tanto, se recomiendan más para ambientes más constantes donde no están los requisitos en los datos en cambio constante. 
Disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en un análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio. 
Para los desarrolladores de aplicaciones acostumbrados a trabajar con bases de datos relacionales, el diseño de una base de datos multidimensional puede ser complejo o al menos, extraño. Pero en general, el diseño de dimensiones y variables es mucho más sencillo e intuitivo que un diseño relacional. Esto es debido a que las dimensiones y variables son reflejo directo de los informes en papel utilizados por la organización. 
ROLAP VS MOLAP 
Herramientas como "ORACLE, DISCOVERY/2000" han permitido utilizar la Base de Datos Relacional para el análisis de informe. Este análisis utiliza la información operacional de manera detallada sobre las tablas de la BD real. Este acercamiento permite observar la información actual y responder preguntas acerca de que es lo que esta sucediendo,totalizar la información, combinar unos datos con otros, etc. Sin embargo, soluciones OLAP basadas sobre modelos relacionales responden con mucha dificultad a preguntas históricas, que incluyendo la noción del tiempo así como análisis de escenarios, tendencias y proyecciones. 
 
 
 
Una vez que se ha decidido emplear un entorno de consulta OLAP, se ha de elegir entre R-OLAP y M-OLAP. M-OLAP es la arquitectura de base de datos multidimensional en la que los datos se encuentran almacenados en una base de datos relacional, la cual tiene forma de estrella (también llamada copo de nieve o araña). En R-OLAP, en principio la base de datos sólo almacena información relativa a los datos en detalle, evitando acumulados (evitando redundancia). 
En general, las ROLAP (OLAP relacional) son copia de datos de las tablas, o sea, los conjuntos de datos son almacenados en tablas en la base de datos relacionada de la fuente. Este tipo es el mejor cuando en la base de datos es limitado el espacio sobre el Servidor de Análisis y el funcionamiento de pregunta no es muy importante. Las BDs relacionales contienen las dimensiones y definiciones de cubo pero los conjuntos son calculados cuando ellos son necesarios, por lo tanto, requieren menos espacio de almacenaje que lo multidimensionales. 
En cambio en las MOLAP (OLAP Multidimensional) las agregaciones de datos y una copia de los datos son almacenadas en una estructura multidimensional sobre el ordenador de Servidor de Análisis. Es lo mejor cuando el espacio de almacenaje suplementario está disponible sobre el ordenador de Servidor de Análisis y el mejor funcionamiento para las consultas es el deseado. Algunos MOLAP locales contienen todos los datos necesarios para calcular conjuntos y puede ser usado fuera de línea. Estos proporcionan el tiempo de respuesta de pregunta más rápido y el funcionamiento, pero requieren el espacio de almacenaje adicional para la copia suplementaria de datos de la mesa de hecho. 
	ROLAP 
	MOLAP 
	Muchas dimensiones 
	Diez o menos dimensiones. 
	Soportan análisis OLAP contra grandes volúmenes de datos 
	Se comportan razonablemente en volúmenes de datos más reducidos (menos de 5Gb) 
	Herramienta flexible y general 
	Solución particular con volúmenes de información y número de dimensiones más modestos 
 
 
¿Cuál es mejor ROLAP O MOLAP? 
La respuesta corta a esta pregunta es "MOLAP." La mejor práctica para los cubos de los servicios del análisis de las bases de datos es intentar hacer que cada cubo sea MOLAP, porque da el mejor funcionamiento de la pregunta. Hay razones de utilizar particularmente ROLAP, pero son excepciones: Reglas MOLAP 
Factores de procesamiento 
MOLAP ejecuta una pregunta de la población del cubo del RDBMS, trae todos los datos en el motor del proceso de servicios del análisis, computa los agregados, y escribe los agregados y los datos del nivel a los archivos de MOLAP. Por lo tanto, escribir los datos atómicos es rápido 
ROLAP utiliza declaraciones del SQL para computar los agregados, y los almacena en tablas relacionales. Hemos observado que estos procesos parecen ser perceptiblemente más lentos que el proceso de MOLAP. 
 
Almacenaje 
El almacenaje de hechos como MOLAP (índices incluyendo de MOLAP) es generalmente 15-20% del tamaño de los datos emparentados (medidos como indexación de los datos en la tabla del hecho solamente) 
El almacenaje de agregados como MOLAP (índices incluyendo) es generalmente 10-20% del tamaño de los datos emparentados (datos indexados de la tabla del hecho) 
El almacenaje de agregados como ROLAP puede ser 100%-200% del tamaño de los datos relacionales, o más si está agregado pesadamente, o los datos sumarios relacionales se ponen en un índice pesadamente. 
Consultas 
MOLAP da el mejor funcionamiento de la consulta. 
El funcionamiento de la pregunta de ROLAP es siempre peor que funcionamiento de la pregunta de MOLAP. 
¿Por qué recomiende MOLAP? 
El funcionamiento es más rápido de las consultas. 
El coste del almacenaje es comparable el de un índice multi-columna en comparación con la tabla relacional. 
¿Por qué recomiende ROLAP? 
OLAP verdaderamente en tiempo real requiere el almacenaje de ROLAP de la partición actualizada del hecho. En este panorama la mayoría de los clientes utilizan el almacenaje de MOLAP para las particiones inactivas. Pero para conseguir actualizaciones en tiempo real de la dimensión, usted necesita el almacenaje de la dimensión de ROLAP, que significa el almacenaje del hecho de la necesidad ROLAP para cualquier cubo que incluya la dimensión en tiempo real. 
 
¿Por qué no recomendar ROLAP? 
Aplicaciones el almacenaje más total y complicado para las consultas. 
Tiene peor funcionamiento para consultas complicadas que requieren de revisar más tablas y mas datos 
Tiene el funcionamiento de proceso peor, por que requiere de mas recursos. 
Para una visión más general. Podemos hacer un análisis práctico sobre base de datos multidimensionales, en contra posición con las bases de datos relacionales, las cual provee las siguientes capacidades con ejemplos: 
· Análisis comparativo o relativo: ¿Cómo las ventas actuales se comportan con respecto a las ventas esperadas? 
· Reporte de excepciones o tendencias: ¿Cuáles productos se han vendido menos del 5% de lo esperado y representan más del 2% de las ventas totales? 
· Modelado, Proyecciones: ¿Qué pasaría si se agregan 3 vendedores mas a la región central? El análisis ROLAP a pesar de ser más sencillo de construir (puesto que se apoya en la Base de Datos de producción) y mas fácil de mantener (los datos reales siempre están disponibles), presentar algunas desventajas: 
· La mayoría de necesidades de análisis requieren que la información sea procesada en un modelo de series de tiempo, de manera tal que apoyen las decisiones de alto nivel en actividades como en proyecciones de presupuestos. En un sistema relacional, donde el Lenguaje de acceso es SQL, preguntas como: ¿cuanto han variado mis ventas de este mes con respecto al promedio móvil del último año?, son extremadamente difíciles de responder. 
· Debido a que la Base de Datos operacional se encuentra altamente estructurada, un cambio en los requerimientos, o la inclusión de una nueva variable para el análisis, representa un cambio mayor en el modelo de la Base de Datos. La flexibilidad es un punto muy importante. 
· El tiempo para construir un modelo multidimensional basado en una estructura relacional de la información, con el objeto de resolver los dos inconvenientes anteriores, es mucho mayor que el tiempo respectivo para crear un verdadero modelo multidimensional y por lo tanto, el costo es mucho mayor. 
 
Transformación de DB relacionales a multidimensionales con DW: 
Podemos apreciar que en este ejemplo de base de datos relacional hay mas de una correspondencia entre los campos. En esencia esta tabla tiene una sola dimensión, en donde se tienen las ventas de cada producto por región. Una compañía tiene tres productos (arandelas, tornillos, tuercas) que se venden en tres territorios (Este, Oeste, Central). A continuación se muestra la tabla relacional: 
 
	PRODUCTO 
	REGION # 
	VENTAS 
	Arandelas 
	Este 
	50000 
	Arandelas 
	Oeste 
	60000 
	Arandelas 
	Central 
	100000 
	Tornillos 
	Este 
	40000 
	Tornillos 
	Oeste 
	70000 
	Tornillos 
	Central 
	80000 
	Tuercas 
	Este 
	90000 
	Tuercas 
	Oeste 
	120000 
	Tuercas 
	Central 
	30000 
 
 Un camino para representar esta tabla en una forma mas óptima es a través de una matriz de dos dimensiones como lo muestra el próximo diagrama: 
	 
	ESTE 
	OESTE 
	CENTRAL 
	Arandelas 
	50000 
	60000 
	100000 
	Tornillos 
	40000 
	70000 
	80000 
	Tuercas 
	90000 
	120000 
	140000 
De esta forma se pueden realizar preguntas como ¿Cuáles fueron las ventas de arandelas en el Este?, ¿Cuáles fueron las ventas de Tornillos en el Oeste?. 
En casos simples no es necesario colocar la información en bases de datos multidimensionales, pero si nos hacemos preguntas como: ¿Cuál fue el total de ventas en el Esteo en el Oeste? y tenemos un millón de productos la selección a través de un “query” nos tomaría mucho tiempo en una base de datos relacional mientras que usando la tecnología multidimensional OLAP nos tomaría escasos segundos. 
Con las bases de datos relacionales, el tiempo de búsqueda es aproximadamente proporcional al número de archivos recuperados. Así que tomaría cuatro veces como mucho recuperar un total como “las Ventas Totales para el Este” mas que el que habría para recuperar un solo registro como “Lavaderos para el Este”. Para calcular las ventas Totales para el Este, cuatro registros tienen que ser recuperados y sumados. Si preguntáramos “¿Cuales son las ventas totales para todas las regiones?” tendríamos que calcular el total de los 12 números en la base de datos (cuatro productos medidos en tres regiones). Esto tomaría 12 veces de tiempo. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
DATAWAREHOUSE 
 DEFINICION DE DATAWAREHOUSE 
En primer lugar, DW no es un producto que pueda ser comprado en el mercado, sino más bien un concepto que debe ser construido en base a procesos y técnicas. DW es una combinación de conceptos y tecnología que cambian significativamente la manera en que es entregada la información a la gente de negocios. El objetivo principal es satisfacer los requerimientos de información internos de la empresa para una mejor gestión, con eficiencia y facilidad de acceso. 
Existen muchas definiciones para el DW, la más conocida fue propuesta por Inmon (considerado el padre de las Bases de Datos) en 1992: “Un DW es una colección de datos orientados a temas, integrados, no-volátiles y variante en el tiempo, organizados para soportar necesidades empresariales”. En 1993, Susan Osterfeldt publica una definición que sin duda acierta en la clave del DW: “Yo considero al DW como algo que provee dos beneficios empresariales reales: Integración y Acceso de datos. DW elimina una gran cantidad de datos inútiles y no deseados, como también el procesamiento desde el ambiente operacional clásico”. 
Esta última definición refleja claramente el principal beneficio que el datawarehouse aporta a la empresa, eliminar aquellos datos que obstaculizan la labor de análisis de información y entregar la información que se requiere en la forma más apropiada, facilitando así el proceso de gestión. 
El concepto de Data Warehouse surge como solución a las necesidades información reales globales de la empresa que los sistemas operacionales no pueden satisfacer. Este término se traduce literalmente como Almacén de Datos, aunque evidentemente si el Data Warehouse fuese exclusivamente un almacén de datos, los problemas seguirían siendo los mismos que en los Centros de Información. 
La ventaja principal de este tipo de sistemas se basa en su concepto fundamental, la estructura de la información. Este concepto significa el almacenamiento de información homogénea y fiable, en una estructura basada en la consulta y el tratamiento jerarquizado de la misma, y en un entorno diferenciado de los sistemas operacionales 
Disponer de un sistema de bases de datos relacionales, no significa disponer de un soporte directo para la toma de decisiones. Muchas de estas decisiones se basan en una análisis de naturaleza multidimensional, que se intentan resolver con la tecnología no orientada para esta naturaleza. Este análisis multidimensional, parte de una visión de la información como dimensiones de negocio. 
Para realizar este tipo de análisis multidimensional debemos de utilizar lo que se conoce como Bases de Datos Multidimensionales (BDM). Este tipo de BD diseñada para optimizar la consulta y almacenamiento de grandes volúmenes de datos que están íntimamente relacionados y que deben verse y analizarse desde distintas perspectivas. A cada perspectiva se le denomina dimensión. Obtener respuestas a las preguntas típicas de una empresa exige con cierta frecuencia ver los datos bajo diferentes perspectivas. 
Este nuevo enfoque propone una estructura de almacenamiento basada en hiper-cubos en lugar de tablas planas. Para entender mejor el concepto de BDM y de dimensiones o perspectivas en este entorno vamos a utilizar un ejemplo de un sistema de gestión de productos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
	 
Las jerarquías que se podrían manejar para el número de dimensiones serán: zona geográfica, tipo de producto y tiempo de resolución. La visión general de la información de ventas para estas dimensiones definidas, la representaremos, gráficamente como el cubo de la derecha. 
 
	 
 
	 
Un gerente de una zona estaría interesado en visualizar la información para su zona en el tiempo para todos los productos que distribuye, lo podría tener una representación gráfica como el cubo de la derecha: 
 
	 
 
	 
Un director de producto, sin embargo querría examinar la distribución geográfica de un producto, para toda la información histórica almacenada en el Data Warehouse. Esto se podría representar como la siguiente figura: 
 
	 
 
	 
O se podría también examinar los datos en un determinado momento o una visión particularizada. 
 
	 
 
 
 
 SISTEMAS DE INFORMACIÓN 
Los sistemas de información se han dividido de acuerdo al siguiente esquema: 
 
 
· Sistemas Estratégicos, orientados a soportar la toma de decisiones, facilitan la labor de la dirección, proporcionándole un soporte básico, en forma de mejor información, para la toma de decisiones. 
Destacan entre estos sistemas: los Sistemas de Información Gerencial (MIS), Sistemas de Información Ejecutivos (EIS), Sistemas de Información Geo-referencial (GIS), Sistemas de Simulación de Negocios (BIS y que en la práctica son sistemas expertos o de 
Inteligencia Artificial - AI). 
 
· Sistemas Tácticos, diseñados para soportar las actividades de coordinación de actividades y manejo de documentación, definidos para facilitar consultas sobre información almacenada en el sistema, proporcionar informes y, en resumen, facilitar la gestión independiente de la información por parte de los niveles intermedios de la organización. 
Destacan entre ellos: los Sistemas Ofimáticos (OA), Sistemas de Transmisión de Mensajería (Correo electrónico y Servidor de fax), coordinación y control de tareas (Work Flow) y tratamiento de documentos (Imagen, Trámite y Bases de Datos Documentales). 
 
· Sistemas Técnico - Operativos, que cubren operaciones tradicionales de captura masiva de datos (Data Entry) y servicios básicos de tratamiento de datos, con tareas predefinidas (contabilidad, facturación, almacén, presupuesto, personal y otros sistemas administrativos). Estos sistemas están evolucionando con la irrupción de sistemas multimedia, bases de datos relacionales más avanzadas y data warehousing. 
 
· Sistemas Interinstitucionales, nace a partir de la generalización de las redes informáticas de alcance nacional y global (INTERNET), que se convierten en vehículo de comunicación entre la organización y el mercado, no importa dónde esté la organización (INTRANET), el mercado de la institución (EXTRANET) y el mercado (Red Global). 
 
Sin embargo, la tecnología data warehousing basa sus conceptos y diferencias entre dos tipos fundamentales de sistemas de información en todas las organizaciones: los sistemas técnico - operacionales y los sistemas de soporte de decisiones. Este último es la base de un data warehouse. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 CARACTERÍSTICAS DE UN DATA WAREHOUSE 
Entre las principales se tiene: 
· Orientado al tema 
· Integrado 
· De tiempo variante 
· No volátil 
Orientado a Temas 
Una primera característica del data warehouse es que la información se clasifica en base a los aspectos que son de interés para la empresa. Siendo así, los datos tomados están en contraste con los clásicos procesos orientados a las aplicaciones. En la Figura N° 1 se muestra el contraste entre los dos tipos de orientaciones. 
En el ambiente data warehousing se organiza alrededor de sujetos tales como cliente, vendedor, producto y actividad. Por ejemplo, para un fabricante, éstos pueden ser clientes, productos, proveedoresy vendedores. Para una universidad pueden ser estudiantes, clases y profesores. Para un hospital pueden ser pacientes, personal médico, medicamentos, etc. 
Las diferencias entre la orientación de procesos y funciones de las aplicaciones y la orientación a temas, radican en el contenido de la data a escala detallada. En el data warehouse se excluye la información que no será usada por el proceso de sistemas de soporte de decisiones, mientras que la información de las orientadas a las aplicaciones, contiene datos para satisfacer de inmediato los requerimientos funcionales y de proceso, que pueden ser usados o no por el analista de soporte de decisiones. 
Otra diferencia importante está en la interrelación de la información. Los datos operacionales mantienen una relación continua entre dos o más tablas basadas en una regla comercial que está vigente. Las del data warehouse miden un espectro de tiempo y las relaciones encontradas en el data warehouse son muchas. Muchas de las reglas comerciales (y sus correspondientes relaciones de datos) se representan en el data warehouse, entre dos o más tablas 
 
 
Integración 
El aspecto más importante del ambiente data warehousing es que la información encontrada al interior está siempre integrada. 
El contraste de la integración encontrada en el data warehouse con la carencia de integración del ambiente de aplicaciones, se muestran en la Figura N° 2, con diferencias bien marcadas, esto producto típicamente de las “fuentes múltiples” 
Fuentes Múltiples 
Como un mismo elemento puede derivarse desde fuentes múltiples se da el caso que muestra la figura, en que las características físicas de los datos entre una y otra fuente producen inconsistencia en medidas de unidades, formatos de fecha y otros. 
A continuación analizaremos dos problemas de fuentes múltiples bien típicos: el de codificación y el de medida de los atributos 
Codificación 
Los diseñadores de aplicaciones codifican el campo GÉNERO en varias formas. Algunos pueden representar GÉNERO como una "M" y una "F", otros como un "1" y un "0", otros como una "X" y una "Y" e inclusive, como "masculino" y "femenino". 
No importa mucho cómo el GENERO llega al data warehouse. Probablemente "M" y "F" sean tan buenas como cualquier otra representación. Lo importante es que sea de cualquier fuente de donde venga, el GENERO debe llegar al data warehouse en un estado integrado uniforme. 
Por lo tanto, cuando el GENERO se carga en el data warehouse desde una aplicación, donde ha sido representado en formato "M" y "F", los datos deben convertirse al formato del data warehouse. 
 
Medida de atributos 
Los diseñadores de aplicaciones miden las unidades de medida de las tuberías en una variedad de formas. Un diseñador puede almacenar los datos de tuberías en centímetros, otros en pulgadas, otros en millones de pies cúbicos por segundo y otros en yardas. 
Al dar medidas a los atributos, la transformación traduce las diversas unidades de medida usadas en las diferentes bases de datos para transformarlas en una medida estándar común. 
Cualquiera que sea la fuente, cuando la información de la tubería llegue al data warehouse necesitará ser medida de la misma manera. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Proceso de integración: transformación de Datos 
Como se explicaba anteriormente, la inconsistencia en los formatos de datos y la codificación, típicamente existen cuando múltiples bases de datos contribuyen al data warehouse. 
En la Figura N° 9 se ilustra una forma de inconsistencia, en la cual el género se codifica de manera diferente en tres bases de datos diferentes. Los procesos de transformación de datos se desarrollan para direccionar estas inconsistencias. 
 
La transformación de datos también se encarga de las inconsistencias en el contenido de datos. Una vez que se toma la decisión sobre que reglas de transformación serán establecidas, deben crearse e incluirse las definiciones en las rutinas de transformación. 
 
De Tiempo Variante 
Los datos históricos son de poco uso en el procesamiento operacional. La información del depósito por el contraste, debe incluir los datos históricos para usarse en la identificación y evaluación de tendencias. (Ver Figura N° 3). 
 
 
El tiempo variante se muestra de varias maneras: 
1. La más simple es que la información representa los datos sobre un horizonte largo de tiempo - desde cinco a diez años. El horizonte de tiempo representado para el ambiente operacional es mucho más corto - desde valores actuales hasta unos cuantos meses 
 
2. La segunda manera en la que se muestra el tiempo variante en el data warehouse está en la estructura clave. Cada estructura clave en el data warehouse contiene, implícita o explícitamente, un elemento de tiempo como día, semana, mes, etc. 
El elemento de tiempo está casi siempre al pie de la clave concatenada, encontrada en el data warehouse. En ocasiones, el elemento de tiempo existirá implícitamente, como el caso en que un archivo completo se duplica al final del mes, o al cuarto. 
3. La tercera manera en que aparece el tiempo variante es cuando la información del data warehouse, una vez registrada correctamente, no puede ser actualizada. La información del data warehouse es, para todos los propósitos prácticos, una serie larga de "snapshots" (vistas instantáneas). 
No volatil 
La información es útil sólo cuando es estable. Los datos operacionales cambian sobre una base momento a momento. La perspectiva más grande, esencial para el análisis y la toma de decisiones, requiere una base de datos estable. 
En la Figura N° 4 se muestra que la actualización (insertar, borrar y modificar), se hace regularmente en el ambiente operacional sobre una base de registro por registro. Pero la manipulación básica de los datos que ocurre en el data warehouse es mucho más simple. Hay dos únicos tipos de operaciones: la carga inicial de datos y el acceso a los mismos. No hay actualización de datos (en el sentido general de actualización) en el depósito, como una parte normal de procesamiento. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 ESTRUCTURA DEL DATA WAREHOUSE 
Los data warehouse tienen una estructura distinta. Hay niveles diferentes de esquematización y detalle que delimitan el data warehouse. La estructura de un data warehouse se muestra en la Figura N° 5. 
Detalle de datos actuales 
En gran parte, el interés más importante radica en el detalle de los datos actuales, debido a que: 
· Refleja las ocurrencias más recientes, las cuales son de gran interés 
· Es voluminoso, ya que se almacena al más bajo nivel de granularidad. 
· Casi siempre se almacena en disco, el cual es de fácil acceso, aunque su administración sea costosa y compleja. 
Detalle de datos antiguos 
La data antigua es aquella que se almacena sobre alguna forma de almacenamiento masivo. No es frecuentemente su acceso y se almacena a un nivel de detalle, consistente con los datos detallados actuales. 
Datos ligeramente resumidos 
La data ligeramente resumida es aquella que proviene desde un bajo nivel de detalle encontrado al nivel de detalle actual. Los puntos en los que se basa el diseñador para construirlo son: 
· Que la unidad de tiempo se encuentre sobre la esquematización hecha. 
· Qué contenidos (atributos) tendrá la data ligeramente resumida. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
A veces se encuentra en el ambiente de data warehouse y en otros, fuera del límite de la tecnología que ampara al data warehouse. (De todos modos, los datos completamente resumidos son parte del data warehouse sin considerar donde se alojan los datos físicamente.) 
Meta data 
El componente final del data warehouse es el de la meta data. De muchas maneras la meta data se sitúa en una dimensión diferente al de otros datos del data warehouse, debido a que su contenido no es tomadodirectamente desde el ambiente operacional. 
La meta data juega un rol especial y muy importante en el data warehouse y es usada como: 
· Un directorio para ayudar al analista a ubicar los contenidos del data warehouse. 
· Una guía para la trazabilidad de los datos, de cómo se transforma, del ambiente operacional al de data warehouse. 
· Una guía de los algoritmos usados para la esquematización entre el detalle de datos actual, con los datos ligeramente resumidos y éstos, con los datos completamente resumidos, etc. 
La meta data juega un papel mucho más importante en un ambiente data warehousing que en un operacional clásico. 
La meta data contiene (al menos): 
· La estructura de los datos 
· Los algoritmos usados para la esquematización 
· La trazabilidad desde el ambiente operacional al data warehouse 
A fin de recordar los diferentes niveles de los datos encontrados en el data warehouse, considere el ejemplo mostrado en la Figura N° 6. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
El detalle de ventas antiguas son las que se encuentran antes de 
1992. Todos los detalles de ventas desde 1982 (o cuando el diseñador inició la colección de los archivos) son almacenados en el nivel de detalle de datos más antiguo. 
El detalle actual contiene información desde 1992 a 1993 (suponiendo que 1993 es el año actual). En general, el detalle de ventas no se ubica en el nivel de detalle actual hasta que haya pasado, por lo menos, veinticuatro horas desde que la información de ventas llegue a estar disponible en el ambiente operacional. 
En otras palabras, habría un retraso de tiempo de por lo menos veinticuatro horas, entre el tiempo en que en el ambiente operacional se haya hecho un nuevo ingreso de la venta y el momento cuando la información de la venta haya ingresado al data warehouse. 
El detalle de las ventas son resumidas semanalmente por línea de subproducto y por región, para producir un almacenamiento de datos ligeramente resumidos. 
El detalle de ventas semanal es adicionalmente resumido en forma mensual, según una gama de líneas, para producir los datos completamente resumidos. 
 
 
 
 
 
 
 COMPONENTES DE UN DATA WAREHOUSE 
Antes de tener un Data Warehouse en la empresa se tiene que hacer un estudio de cuáles son los requerimientos necesarios para su implantación: 
 Hardware 
 Software de almacenamiento (SGBD) 
 Software de extracción y manipulación de datos 
 Herramientas Middleware 
Hardware 
En este sentido son críticas, a la hora de evaluar uno u otra infraestructura hardware, hay dos características principales: 
 Por un lado, a este tipo de sistemas suelen acceder pocos usuarios con unas necesidades muy grandes de información, a diferencia de los sistemas operacionales, con muchos usuarios y necesidades puntuales de información. Debido a la flexibilidad requerida a la hora de hacer consultas complejas e imprevistas, y al gran tamaño de información manejada, son necesarias unas altas prestaciones de la máquina. 
 Por otro lado, debido a que estos sistemas suelen comenzar con una funcionalidad limitada, que se va expandiendo con el tiempo, es necesario que los sistemas sean escalables para dar soporte a las necesidades crecientes de equipamiento. 
Recomendamos la visita a la dirección Internet: http://www.tpc.org 
En donde la Transaction Processing Council (de la que son miembros AMD, DELL, Bull, Compaq, HP, Intel, Fujitsu, Microsoft, IBM, Oracle, NCR , Sun, entre otros), realiza una comparativa entre las máquinas de sus miembros, proporcionando para diferentes modelos y diferentes configuraciones de Sistemas Operativos y Software de Base de Datos, un análisis de rendimiento (throughput), y un resumen de características (precio, número de procesadores, arquitectura y futuras versiones y fecha de disponibilidad). 
 
Software de almacenamiento (SGBD) 
El sistema que gestione el almacenamiento de la información (Sistema de Gestión de Base de Datos o SGBD), es otro elemento clave en un Data Warehouse. Independientemente de si la información almacenada en el Data Warehouse se puede analizar mediante visualización multidimensional, el SGBD puede estar realizado utilizando tecnología de Bases de Datos Relaciónales o Multidimensionales. 
Las bases de datos relacionales, se han popularizado en los sistemas operacionales, pero se han visto incapaces de enfrentarse a las necesidades de información de los entornos Data Warehouse. Por ello, y puesto que, las necesidades de información suelen atender a consultas multidimensionales, las BD multidimensionales, parten con ventaja. Las bases de datos post-relacionales (multidimensionales), abren un mayor abanico de elección. Estas bases de datos post-relacionales, parten de una tecnología consolidada y dan respuesta al agotamiento de las posibilidades de los sistemas de gestión de bases de datos relacionales, ofreciendo las mismas prestaciones aunque implantadas en una arquitectura diseñada de forma más eficiente. 
 
Software de extracción y manipulación de datos 
Para esta labor, que entra dentro del ámbito de los profesionales de tecnologías de la información, es crítico el poder contar con herramientas que permitan controlar y automatizar las necesidades de actualización del Data Warehouse. 
Estas 	herramientas 	deberán 	proporcionar 	las 	siguientes funcionalidades: 
 Control de la extracción de los datos y su automatización, disminuyendo el tiempo empleado en el descubrimiento de procesos no documentados, minimizando el margen de error y permitiendo mayor flexibilidad. 
 Acceso a diferentes tecnologías, haciendo un uso efectivo del hardware, software, datos y recursos humanos existentes. 
 Proporcionar la gestión integrada del Data Warehouse y los Data 
Marts existentes, integrando la extracción, transformación y carga para la construcción del Data Warehouse corporativo y de los Data Marts. 
 Uso de la arquitectura de meta datos, facilitando la definición de los objetos de negocio y las reglas de consolidación. 
 Acceso a una gran variedad de fuentes de datos diferentes. 
 Manejo de excepciones. 
 Interfaz independiente de hardware. 
 Soporte en la explotación del Data Warehouse. 
A veces, no se suele prestar la suficiente atención a esta fase de la gestión del Data Warehouse, aun cuando supone una gran parte del esfuerzo en la construcción de un Data Warehouse. Existen multitud de herramientas disponibles en el mercado que automatizan parte del trabajo, para lo cual 
Herramientas Middleware 
Como herramientas de soporte a la fase de gestión de un Data Warehouse, se describirá a continuación dos tipos de herramientas: 
 Por un lado herramientas Middleware, que provean conectividad entre entornos diferentes, para ayudar en la gestión del Data Warehouse. 
 Por otro, analizadores y aceleradores de consultas, que permitan optimizar tiempos de respuesta en las necesidades analíticas, o de carga de los diferentes datos desde los sistemas operacionales hasta el Data Warehouse. 
Las herramientas Middleware deben ser escalables siendo capaces de crecer conforme crece el Data Warehouse, sin problemas de volúmenes. También deben ser flexibles y robustas, sin olvidarse de proporcionar un rendimiento adecuado. 
Con el uso de estas herramientas de Middleware lograremos: 
 Maximizar los recursos ejecutando las aplicaciones en la plataforma más adecuada. 
 Integrar los datos y aplicaciones existentes en una plataforma distribuida. 
 Automatizar la distribución de datos y aplicaciones desde un sistema centralizado. 
 Reducir tráfico en la red, balanceando los niveles de cliente servidor. 
 Explotar las capacidades de sistemas remotos sin tener que aprender múltiples entornos operativos. 
 Asegurar la escalabilidad del sistema. 
 Desarrollar aplicaciones en local y explotarlas en el servidor. 
Los analizadores y aceleradores de consultas trabajan volcando sobre un archivo las consultas ejecutadas y datos asociados a las mismas (tiempo de respuesta, tablas accedidas, método de acceso, etc.). Este archivo se analiza automáticamente