Introduccion Al Soporte de Decisione

Indice general
Resumen 1. Introducci on 1.1. Qu e es OLAP? . . . . . . . . . . . . . . . . . . . . . . 1.2. Diferencia entre el procesamiento OLAP y OLTP . . . 1.3. Cubos: Dimensiones, Medidas y Operaciones aplicables 1.4. ROLAP, MOLAP Y HOLAP . . . . . . . . . . . . . . 1.4.1. MOLAP . . . . . . . . . . . . . . . . . . . . . . 1.4.2. ROLAP . . . . . . . . . . . . . . . . . . . . . . 1.4.3. HOLAP . . . . . . . . . . . . . . . . . . . . . . 1.4.4. Cual es la mejor opci on? . . . . . . . . . . . . . 1.5. Pensar en N dimensiones . . . . . . . . . . . . . . . . .
1 3 3 5 7 12 12 13 14 14 16
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
2. Consideraciones previas a la implementaci on 26 2.1. Requerimientos f sicos y l ogicos . . . . . . . . . . . . . . . . . . . . . . . 26 2.2. An alisis costo-benecio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.3. Evaluar el entorno actual de la empresa . . . . . . . . . . . . . . . . . . . 30 3. Dise nar la fuente de datos y migrarlos 3.1. Qu e es un DataWarehouse (DW)? . . . . . . . . . . . . . . . . . . . . 3.2. Diferencias entre un DataWarehouse y una base de datos operacional 3.3. Dise nar el DataWarehouse . . . . . . . . . . . . . . . . . . . . . . . . 3.3.1. Dise no l ogico . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3.2. Dise no f sico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4. Migrar los datos: ETL (Extract, Transform, Load) . . . . . . . . . . . 3.4.1. Extraer los datos . . . . . . . . . . . . . . . . . . . . . . . . 3.4.2. Transformar los datos . . . . . . . . . . . . . . . . . . . . . 3.4.3. Cargar los datos . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.4. Evaluar herramientas ETL externas . . . . . . . . . . . . . . . 34 35 38 42 42 44 47 49 49 53 54
. . . . . . . . . .
. . . . . . . . . .
4. Implementar una Herramienta OLAP 56 4.1. Microsoft SQL Server Analysis Services . . . . . . . . . . . . . . . . . . . 59
ii
4.1.1. Migrar los datos de una base OLTP hacia un esquema usando paquetes DTS . . . . . . . . . . . . . . . . . . . 4.1.2. Crear un Cubo y sus dimensiones . . . . . . . . . . . . . 4.1.3. Analizar y manipular el Cubo . . . . . . . . . . . . . . . 4.1.4. Caracter sticas avanzadas en Microsoft Analysis Services 4.1.5. Acceder a Microsoft Analysis Services desde c odigo . . . 4.1.6. Cambios en Microsoft Analysis Services 2005 . . . . . . . 5. Conclusi on Bibliograf a
estrella . . . . . 63 . . . . . 71 . . . . . 85 . . . . . 89 . . . . . 93 . . . . . 103 107 111
Resumen
El punto de partida de todas las actividades de negocios es el procesamiento de informaci on. Esto incluye recolectar, almacenar, transportar, manipular y recuperar datos con o sin ayuda de las computadoras. La importancia de contar con buena informaci on constituye la diferencia entre tomar decisiones correctas e incorrectas, porque las decisiones en general estar an basadas en esta informaci on. Por ejemplo, si una empresa dedicada a la reventa de productos tiene poca informaci on sobre los movimientos de los mismos, puede tomar decisiones incorrectas, como comprar productos que no vende demasiado y quedarse sin stock de productos de alta demanda. Independientemente de qu e o c omo se procese la informaci on, los atributos que se buscan son siempre los mismos: la informaci on debe ser tangible, precisa, comprensible y oportuna. Se puede decir que en un principio solo las grandes corporaciones ten an acceso al procesamiento anal tico de la informaci on, lo que les permiti o manipular h abilmente el gran volumen de datos con el que contaban, y as crecer aun m as, dominando todo el mercado. La tendencia actual sin embargo, es que este tipo de herramientas est en al alcance de todas las organizaciones, desde estas grandes multiempresas hasta las empresas mas peque nas. Los sistemas de soporte de decisiones tradicionales se enfocaban en procesos operacionales relacionados al producto de la organizaci on. Sus capacidades eran limitadas, y los esfuerzos de marketing se dirig an al producto en vez de dirigirse al cliente. Los llamados archivos de informaci on del cliente (Marketing Customer Information File o MCIF) fueron el primer intento de recopilar datos de clientes en un solo archivo central a partir de decenas de sistemas operacionales. Con esta tendencia el foco se fue corriendo desde producto hacia los clientes. Las bases de datos house-holding almacenaban informaci on sobre la forma de vida de los clientes. Se manten an clasicados por categor as para que los gerentes de negocios 1
analizaran interrelaciones entre ellos y sus necesidades. Luego surgi o el DataWarehousing, que fue un paso m as grande en el intento de integrar y cruzar la informaci on de la organizaci on destinada el soporte de decisiones. Este paso origin o tareas y conceptos tales como reportes de ventas, indicadores clave, an alisis de tendencias. Luego del surgimiento del DataWarehousing comenzaron a surgir nuevas herramientas en el mercado, y entre ellas una clase de la que nos ocuparemos en esta tesis, las herramientas OLAP (Online Analytical Processing). En primer lugar nos introduciremos en lo que signica una herramienta OLAP, y como el procesamiento OLAP diere del procesamiento OLTP (Online Transactional Processing), usado en la operatoria diaria. Luego se ver an los pasos fundamentales y las cuestiones a tener en cuenta al momento de congurar el entorno para implementar estas herramientas. El entorno del que se habla se reere a una empresa con distintas aplicaciones operacionales, cada una tomando y guardando datos en distintos tipos de bases de datos y archivos. Se tratar an los principales puntos concernientes al armado de un DataWarehouse o repositorio de datos, que ser a la fuente de datos de la herramienta OLAP que se elija usar e implementar. Entre estos puntos, se analiza como hacer una evaluaci on del entorno actual de la empresa (la plataforma de HW, los DBMS que se est an usando, los datos existentes en toda la organizaci on, las aplicaciones que se est an utilizando), y la carga completa de los datos. Una vez que contamos con la fuente de los datos, se analizan las caracter sticas con las que cuenta una herramienta OLAP. Para conocerlas m as profundamente tomamos como ejemplo la herramienta OLAP de Microsoft, Analysis Services, recorriendo cada aspecto relevante de la misma mediante ejemplos, para obtener as una visi on global y precisa del uso y del potencial que ofrecen estas herramientas.
Cap tulo 1 Introducci on

1.1. Qu e es OLAP?
OLAP se dene como el an alisis multidimensional e interactivo de la informaci on de negocios a escala empresarial. El an alisis multidimensional consiste en combinar distintas areas de la organizaci on, y as ubicar ciertos tipos de informaci on que revelen el comportamiento del negocio. Porque se dice que el an alisis es interactivo? Los usuarios de la herramienta OLAP se mueven suavemente desde una perspectiva del negocio a otra, por ejemplo, pueden estar observando las ventas anuales por sucursal y pasar a ver las sucursales con mas ganancias en los u ltimos tres meses, y adem as con la posibilidad de elegir entre diferentes niveles de detalle, como ventas por d a, por semana o por cuatrimestre. Es esta exploraci on interactiva lo que distingue a OLAP de las herramientas simples de consulta y reportes. Porque es u til la multidimensionalidad? Es lo que permite a los analistas de negocios examinar sus indicadores clave o medidas, como ventas, costos, y ganancias, desde distintas perspectivas, como periodos de tiempo, productos, regiones. Estas perspectivas constituyen las dimensiones desde las que se explora la informaci on. Porque a escala empresarial? OLAP es robusto y escalable al punto de permitir satisfacer las necesidades de an alisis de informaci on de la organizaci on completa. Se trabaja con fuentes de datos corporativas, que contienen datos de toda la empresa, y se comparte y cruza la informaci on existente en todas las areas de la misma. Para proveer estas caracter sticas, toda herramienta OLAP tiene tres principales componentes:
CAP ITULO 1. INTRODUCCION
Un modelo multidimensional de la informaci on para el an alisis interactivo. Un motor OLAP que procesa las consultas multidimensionales sobre los datos. Un mecanismo de almacenamiento para guardar los datos que se van a analizar. Este componente puede ser externo a la herramienta, como un RDBMS o un DataWarehouse. Los usuarios de OLAP se enfocan en los conceptos de negocios, trabajando intuitivamente con ellos, sin necesidad de conocer cuestiones t ecnicas tales como el formato f sico de los datos, instrucciones de lenguajes como SQL, nombres de tablas o columnas en la base de datos, o la arquitectura OLAP subyacente. La herramienta no solo permite exibilidad en cuanto a la navegaci on por el modelo multidimensional de la informaci on, sino que tambi en es exible en la denici on de los reportes y aplicaciones que se construyen a partir de ella.
1.2.
Diferencia entre el procesamiento OLAP y OLTP
La compra, venta, producci on, y distribuci on son ejemplos comunes de actividades de negocios de la operaci on diaria. Estas actividades constituyen el llamado procesamiento operacional u OLTP (Online Transactional Processing), y las aplicaciones que soportan este procesamiento se dise nan con orientaci on a la carga de datos. El planeamiento de recursos, planeamiento nanciero, alianzas estrat egicas, e iniciativas de mercado son ejemplos de actividades que generan y usan informaci on basada en an alisis y orientada a la toma de decisiones. Este tipo de actividades son soportadas por las aplicaciones de tipo OLAP. Podemos decir que las caracter sticas que diferencian el procesamiento OLTP del procesamiento de tipo OLAP son las siguientes: Las aplicaciones OLTP son usadas por un gran numero de usuarios concurrentes. Una aplicaci on OLAP, en cambio, no tiene que soportar este nivel de concurrencia, porque en general ser a usada solo a nivel gerencial o por los analistas de negocios. A diferencia del tiempo de respuesta a las consultas en OLAP, el tiempo de respuesta de las operaciones en una aplicaci on OLTP es critico, debe estar en el orden de los microsegundos, ya que un cliente puede estar esperando la respuesta. El procesamiento OLTP tiende a ocurrir en tiempos relativamente constantes, es decir, la frecuencia con la que se realizan las operaciones no varia demasiado. Por ejemplo, una aplicaci on de facturaci on recibe operaciones todo el tiempo. Una aplicaci on OLAP recibe solicitudes de informaci on en tiempos poco predecibles. Se pueden requerir algunos informes en forma mensual, o semanal, o en cualquier momento. En una aplicaci on OLTP los datos se actualizan con la misma frecuencia con la que se leen. No es as en el caso del procesamiento OLAP, donde los datos se actualizan cada ciertos periodos de tiempo, cuando se hace el volcado de datos desde las bases de datos operacionales. Las consultas hechas a las aplicaciones OLTP act uan sobre una cantidad no muy extensa de datos, y la naturaleza de estas consultas no tiene complejidad. Por ejemplo, cuando se consulta sobre un determinado cliente para ver datos como su nombre y su domicilio. Esta consulta implica recuperar y comparar datos no derivados, es decir, no se calculan en el momento. Este tipo de consultas en general se conoce de antemano y pertenecen a un proceso dentro de la organizaci on. En aplicaciones orientadas a la toma de decisiones en cambio, las consultas requieren el examen y recuperaci on de una enorme cantidad de datos, incluso datos hist oricos. Los usuarios de una aplicaci on OLAP generan consultas complejas y ad hoc, y a veces la respuesta a una consulta conduce a la formulaci on de otras m as detalladas. En general los usuarios comienzan buscando en los datos resumidos y al identicar
reas de inter a es, comienzan a acceder al conjunto de datos detallado. Los conjuntos de datos resumidos representan el Qu e de una situaci on y los conjuntos de datos detallados permiten a los usuarios construir un cuadro sobre C omo se ha derivado esa situaci on. Los sistemas operacionales se desarrollan para automatizar circuitos y procesos de negocios y no para la toma de decisiones, por lo tanto, no est an dise nados para integrarse o conciliar datos con otros sistemas a n de ofrecer una vista total de los datos de la organizaci on.
Todas estas diferencias se reejan en las caracter sticas de las bases de datos subyacentes a ambos tipos de aplicaciones.
1.3.
Cubos: Dimensiones, Medidas y Operaciones aplicables
Cubo multidimensional En una base de datos multidimensional, el modelo de datos esta constituido por lo que se denomina un Cubo multidimensional o simplemente Cubo. En un cubo la informaci on se representa por medio de matrices multidimensionales o cuadros de m ultiples entradas, que nos permite realizar distintas combinaciones de sus elementos para visualizar los resultados desde distintas perspectivas y variando los niveles de detalle. Esta estructura es independiente del sistema transaccional de la organizaci on, facilita y agiliza la consulta de informaci on hist orica ofreciendo la posibilidad de navegar y analizar los datos. Aqu vemos como ejemplo un cubo multidimensional que contiene informaci on de ventas discriminadas por periodos de tiempo, productos y zonas geogr acas de las sucursales.
Los ejes del cubo son las Dimensiones, y los valores que se presentan en la matriz, son las Medidas. Una instancia del modelo est a determinada por un conjunto de datos para cada eje del cubo y un conjunto de datos para la matriz. Dimensiones Son objetos del negocio con los cuales se puede analizar la tendencia y el comportamiento del mismo. Las deniciones de las dimensiones se basan en pol ticas de la compa n a o del mercado, e indican la manera en que la organizaci on interpreta o clasica su informaci on para segmentar el an alisis en sectores, facilitando la observaci on de los datos. Para determinar las dimensiones requeridas para analizar los datos podemos preguntarnos: Cu ando? La respuesta a esta pregunta permite establecer la dimensi on del tiempo y visualizar de manera comparativa el desempe no del negocio.
D onde? Esta pregunta nos ubica en un area f sica o imaginaria donde se est an llevando a cabo los movimientos que se desean analizar. Estos lugares se pueden ser zonas geogr acas, divisiones internas de la organizaci on, sucursales, etc. Que? Es el objeto del negocio, o el objeto de inter es para determinada area de la compa n a. Para estos casos se tienen los productos y/o servicios, la materia prima como elemento de inter es para la divisi on de abastecimientos, los veh culos para la secci on de transportes, las maquinarias para el area de producci on, etc. Quien? En esta dimensi on se plantea una estructura de los elementos que inciden directamente sobre el objeto de inter es. En estos casos se hace referencia al area comercial o de ventas, o a los empleados de la organizaci on si se est a llevando a cabo un an alisis a nivel del talento humano, etc. Cu al? Habla de hacia d onde se enfoca el esfuerzo de la organizaci on o una determinada area del negocio, para hacer llegar los productos o servicios. Una dimensi on que surge de esta pregunta es la de clientes.
Medidas o M etricas Son caracter sticas cualitativas o cuantitativas de los objetos que se desean analizar en las empresas. Las medidas cuantitativas est an dadas por valores o cifras porcentuales. Por ejemplo, las ventas en d olares, cantidad de unidades en stock, cantidad de unidades de producto vendidas, horas trabajadas, el promedio de piezas producidas, el porcentaje de aceptaci on de un producto, el consumo de combustible de un veh culo, etc. Jerarqu as de Dimensiones y Niveles Generalmente las dimensiones se estructuran en jerarqu as, y en cada jerarqu a existen uno o mas niveles, los llamados Niveles de Agregaci on o simplemente Niveles. Toda dimensi on tiene por lo menos una jerarqu a con un u nico nivel. En la gura vemos un ejemplo de una dimensi on de vendedores, que consiste de una u nica jerarqu a, y tres niveles de agregaci on para agruparlos por ciudades y por regiones.
Aqu podemos ver una dimensi on que cuenta con dos jerarqu as:
En este caso, los niveles Zonas y Gerencia no est an relacionados entre s , a pesar de que ambos est an relacionados con las Areas. Si existe m as de una jerarqu a, la relaci on que une datos de un nivel con datos de otro nivel superior debe ser conuente. Esto signica que todos los caminos que parten de un elemento e del nivel E, llegan al mismo elemento d del nivel D superior a E, independientemente de la jerarqu a recorrida.
Si no se cumpliera la conuencia, entonces el primer trimestre que gura relacionado con 1998, podr a aparecer relacionado, por ejemplo, con 1999. En este caso, al recorrer la jerarqu a por trimestre, el mes de marzo de 1998 aparecer a en 1999. Operaciones Multidimensionales Las operaciones multidimensionales se pueden agrupar en tres conjuntos b asicos que se describen a continuaci on: Operaciones de Slice & Dice (Selecci on) No existe un consenso general en la denici on de Slice & Dice. Sin embargo, se acepta que hay tres operaciones incluidas en este conjunto: Slice: Seleccionar una tajada de un cubo tomando un determinado valor de dimensi on de un cubo mayor, deniendo un subcubo.
10
Dice: Tomar secciones del cubo en funci on de un rango de valores de las dimensiones. Por ejemplo, dado un cubo que muestra las ventas por meses y por regiones, seleccionar solo las ventas de Febrero (slice), o solo las regiones donde las ventas sean inferiores a $100.000 (dice). La herramienta debe permitir seleccionar tems espec cos de una dimensi on, o seleccionar tems de acuerdo a un rango (por ejemplo, los 5 productos mas vendidos), y combinar estos criterios de selecci on para construir consultas mas complejas. Rotaci on (pivoting): Permite visualizar diferentes planos de un cubo. En general el usuario indica la rotaci on arrastrando una dimensi on a una nueva posici on, y la herramienta rota la perspectiva autom aticamente. Aqu vemos un esquema de la operaci on de Rotaci on. Siguiendo el ejemplo de las ventas, en el primer cubo observamos las ventas discriminadas por productos y zonas para el primer trimestre. Al rotar la dimensi on Tiempo con Zonas Geogr acas, vemos las ventas para la Zona Local. Por ultimo se intercambian las dimensiones Productos y Zonas Geogr acas, exponiendo as las ventas discriminadas por Zonas y por trimestres para un producto en particular.
Operaciones de Agregaci on El grupo de las operaciones de Agregaci on est a constituido por operaciones que realizan desplazamientos por las jerarqu as y niveles de las dimensiones. DrillUp: Implica subir un nivel en la jerarqu a. Como resultado se agrupan todos los valores de los miembros en el nivel original que est an relacionados con el mismo valor del nivel superior. DrillDown: Implica bajar un nivel en la jerarqu a. Se produce la desagregaci on de dichos valores. Por ejemplo, si estamos observando ventas anuales por sucursales podemos aplicar una operaci on de DrillDown para ver dichas ventas discriminadas por trimestre, o aplicar una operaci on de DrillUp para ver las ventas por regiones en lugar de sucursales. En general estas operaciones se invocan haciendo doble clic en el punto relevante en la tabla multidimensional o chart. RollUp (Consolidaci on): Cuando se realiza un DrillUp, se deben calcular nuevos valores en funci on del conjunto de valores de las medidas que se agrupan. La aplicaci on de esta operaci on se traduce, t picamente, en funciones de agregaci on como las presentes en SQL (SUM, AVG, MAX, MIN, etc.).
11
Relacionamiento A partir de un cubo, mediante las operaciones de Relacionamiento, se puede acceder otros datos. DrillAcross: Se accede a datos que est an en otros cubos existentes. DrillThrough: Se accede a datos que est an en un DataWarehouse o en una base operacional. En el siguiente ejemplo podemos ver, dados los datos iniciales de una consulta de ventas, los efectos de aplicar sobre los mismos las operaciones de Pivot, DrillUp sobre la dimensi on de los productos, y DrillDown sobre la dimensi on de sucursales.
12
1.4.
ROLAP, MOLAP Y HOLAP
La estructura que almacena los datos de una aplicaci on de tipo OLAP tiene que proveer consultas ecientes, escalabilidad y acceso multiusuario. Las bases de datos relacionales est an optimizadas para obtener una performance optima en consultas simples y frecuentes, pero no funcionan de manera ideal para las consultas multidimensionales y complejas de estas aplicaciones, ya que existen muchas de ellas que no se pueden expresar en una u nica consulta SQL, y seguramente se requerir an muchas operaciones de JOIN, lo cual reduce dr asticamente el tiempo de respuesta de la consulta. Para cubrir estas deciencias surgieron tres estrategias de almacenamiento: Bases de datos multidimensionales especializadas (MDDBs), que proveen almacenamiento y recupero de datos optimizado para consultas OLAP. DataWarehouses, construidos sobre una tecnolog a relacional, pero la optimizaci on se dirige al soporte de decisiones en lugar de a las operaciones transaccionales. Una tercer estrategia que consiste en la combinaci on de las dos anteriores. Las herramientas OLAP que usan almacenamiento multidimensional son llamadas MOLAP, mientras que a las que almacenan los datos en bases relacionales se les llama herramientas ROLAP. Las herramientas que combinan los dos enfoques se conocen como OLAP H brido u HOLAP.
1.4.1.
MOLAP
Las bases de datos multidimensionales usan estructuras de tipo arreglo para almacenar los datos. Estas estructuras est an indexadas con el n de proveer un tiempo de acceso optimo a cualquier elemento. Se pueden distinguir dos enfoques en la forma de organizar estas estructuras, las MDDBs que usan una arquitectura de hipercubo, y las que usan multicubos. La arquitectura de hipercubo almacena un u nico gran cubo en el cual cada medida est a referenciada y totalizada en todas las dimensiones del mismo. En la arquitectura de multicubos los datos se guardan en m as de un cubo. Por ejemplo, una base de datos puede contener un cubo que almacena las ventas mensuales, por regi on y por producto, y otro que guarda la informaci on correspondiente a costos departamentales y mensuales.
13
La primer organizaci on es mas simple, y tiene una performance mas pareja en cuanto al tiempo de respuesta a las consultas. Con la arquitectura de multicubos se logra una mejor performance si la consulta no requiere el acceso a m as de un cubo, pero en el caso contrario la performance se reduce notoriamente, ya que se requiere un procesamiento complejo para asegurar que los resultados del cruce de cubos sea consistente. Si hablamos del espacio en disco, es la arquitectura de hipercubo la que mas espacio requiere, y adem as necesita un buen manejo de la dispersi on de los datos para evitar que el tama no del cubo se vuelva inmanejable. (ver)Una de las caracter sticas distintivas de MOLAP es la preconsolidaci on de los datos. En una base de datos relacional para responder a una consulta del tipo Cu anta cantidad del producto X se vendi o en el ultimo cuatrimestre? normalmente se tiene que hacer una b usqueda de todos los registros relevantes y totalizar los datos. En una base multidimensional en cambio, estos totales se calculan r apidamente usando operaciones extremadamente ecientes sobre arreglos. Una vez calculados, los totales se pueden almacenar en las estructuras de la base misma. Las MDDBs pueden preconsolidar todos los datos, es decir, hacer los c alculos necesarios para obtener la sumarizaci on y totalizaci on y almacenar estos resultados para su posterior uso. Preconsolidar todos los datos requiere mucho espacio y tiempo de carga de la base. Una alternativa es preconsolidar solo los totales mas usados y calcular el resto en el momento en el que se consultan. La mayor a de las MDDBs tambi en proveen acceso SQL a datos en una base de datos relacional adjunta para recuperar las de informaci on detallada, por ejemplo, todas las las que conformen un determinado total. Esta informaci on detallada solamente se puede visualizar, pero no se puede usar para an alisis. Otra caracter stica de importancia tiene que ver con los datos dispersos. Una MDDB tiene que contar con un manejo de datos dispersos. La dispersi on de datos surge en casos donde no todas las combinaciones de miembros de dimensiones van a tener su valor correspondiente. Por ejemplo, consideremos el caso de una empresa con varias sucursales, que puede vender cientos de productos por d a en cada una, pero no todos los productos necesariamente se van a vender todos los d as en todas las sucursales. Si analizamos estas ventas en periodos diarios y por sucursal creando un cubo con las ventas como medida, y sucursales, productos, y d as como dimensiones, el cubo contendr a celdas vac as. Estas celdas corresponden a los productos que no se vendieron en determinados d a y sucursal. Cada herramienta MOLAP tiene su propio mecanismo para evitar guardar valores nulos o ceros a partir de esta situaci on. En general se comprime la base de datos para descartar valores nulos, con el costo de descomprimirla cuando se accede a los datos.
1.4.2.
ROLAP
Aunque las bases de datos relacionales no est an optimizadas para el an alisis multidimensional, tienen ventajas sobre las MDDBs en otros aspectos. En particular, son escalables a conjuntos mas grandes de datos e incluyen soporte para replicaci on, rollback y recuperaci on. Adem as, en la mayor a de las organizaciones es mas probable que
14
la gente de sistemas est e m as familiarizada con el uso de una base de datos relacional, que con el manejo de las MDDBs. Con los grandes DataWarehouses, que llegan al orden del terabyte, estas ventajas se pueden ver claramente. Las herramientas ROLAP brindan an alisis multidimensional sobre datos almacenados en una base de datos relacional. Lo hacen a trav es de un mapeo entre los datos en el DataWarehouse a un modelo multidimensional, usando consultas SQL. Estas herramientas trabajan de distintas maneras con el RDBMS correspondiente: Algunas lo usan para hacer todo el procesamiento de datos. Generan sentencias SQL y crean tablas temporales si es necesario. Algunas proveen funcionalidad de calculo fuera del RDBMS. Se genera SQL para recuperar datos, pero algunos c alculos (incluyendo algunos JOINs o totalizaciones) los hace la misma herramienta. Las herramientas ROLAP no requieren manejo de los datos dispersos. Para mejorar la performance, se tiende a almacenar algunos valores totalizados en el DataWarehouse, as que los datos dispersos siguen siendo un tema de importancia, que en este caso se relega al dise nador del DataWarehouse.
1.4.3.
HOLAP
Existen dos enfoques para denir a las herramientas HOLAP. Por un lado, se habla de un MDDB que puede recuperar y analizar informaci on detallada. Esta es la denici on mas aceptada de HOLAP. Hablamos de una herramienta que almacena los datos totalizados en la MDDB y los datos detallados en la RDBMS. El usuario trabaja con un u nico modelo de los datos, y este accede en forma transparente a los dos tipos de almacenamiento. Lo interesante de este enfoque es su facilidad de uso. Por otro lado, existen herramientas HOLAP que consisten de un almacenamiento multidimensional, con preconsolidaci on opcional. Se extrae un conjunto de datos de un RDBMS y luego se construye un cubo multidimensional en el cliente. La diferencia con el enfoque anterior es que en este caso no se cuenta con una capa de manejo de base de datos que abstraiga al usuario de la implementaci on t ecnica. Algunos vendedores incluyen la opci on de preconsolidar valores en el almacenamiento, y otros almacenan los datos y hacen las consolidaciones en el momento en que se requieren.
1.4.4.
Cual es la mejor opci on?
Cada alternativa tiene sus ventajas y desventajas. En lugar de discutir cual de las dos es mejor hay que denir un criterio para optar por una u otra, y evaluar el alcance de HOLAP, que en la practica intenta combinar lo mejor de ambos mundos.
15
Lo mas importante es entender los requerimientos del propio negocio y las implicancias para el tipo y tama no de los datos a los que necesitamos acceder en el futuro. Algunas de las ventajas mas importantes de cada enfoque son: MOLAP Buena performance en las consultas, ya que el almacenamiento esta optimizado para el an alisis multidimensional. La escalabilidad est a limitada por la capacidad de la MDDB y por el tiempo de carga de los datos. En general el an alisis est a limitado a los datos totalizados o sumarizados. El modelo multidimensional no es lo sucientemente exible como para acomodarse a las necesidades constantemente cambiantes del negocio. La estructura que guarda los datos est a incluida en la herramienta. Requiere una capa adicional de manejo de datos. No incluye soporte de paralelismo, replicaci on ni recuperaci on de datos. Puede requerir aprendizaje por ser una tecnolog a nueva en la organizaci on. ROLAP La performance de las consultas no es tan optima como en MOLAP. Es capaz de manejar conjuntos de datos muy grandes, por encima de un terabyte.
Adem as del an alisis de informaci on sumarizada, se pueden analizar datos detallados hasta el nivel de las transacciones. Es capaz de analizar los datos desde cualquier perspectiva en cualquier momento. La herramienta ROLAP requiere un DataWarehouse de donde extraer los datos para analizar. Las cuestiones t ecnicas del manejo de los datos est a a cargo del RDBMS. Incluye soporte para replicaci on, rollback y recuperaci on, y para acceso multiusuario.
Ya existen skills para el uso de DBMS.
16
1.5.
Pensar en N dimensiones
Entender lo que es un cubo multidimensional (o cubo de mas de tres dimensiones) es fundamental para entender el software multidimensional, que usa estos cubos de la misma forma que una base de datos usa las tablas. Todo el an alisis, reporte y presentaci on de los datos se hace a trav es de ellos. Vamos a tratar de entender el concepto construyendo un conjunto de datos de N dimensiones a partir de algo bien conocido: una tabla de dos dimensiones con las y columnas. Un ejemplo com un para representar en dos dimensiones podr an ser datos de ventas, costos y ganancias de una empresa, discriminados por mes. Antes que nada observemos la organizaci on de los datos crudos. La base de datos contiene una tabla Ventas y VentasDetalle, una tabla Compras y ComprasDetalle, donde cada una reserva campos para los datos de la factura, el importe, la fecha de la operaci on, y los productos, entre otros.
Luego, agregando y totalizando los importes obtenemos la organizaci on de los datos en dos dimensiones.
17
La grilla tiene una la para cada mes, y una adicional para los totales generales, y tres columnas para las variables de Ventas, Costos y M argenes. Claramente vemos que las dos dimensiones son los Meses por un lado, y las variables por el otro. Sin embargo, si alguien pregunta que es lo que estamos observando, deber amos decir que estamos analizando Ventas, Costos y Ganancias. Estos valores son las variables, en cambio los meses representan la forma en la que se organizan estos datos en la presentaci on. Es decir, no estamos observando meses, estamos observando ventas, costos y ganancias organizados en meses. Si ahora agregamos una dimensi on m as, la dimensi on Productos, obtenemos un cubo de tres dimensiones.
Este cubo no es f acil de visualizar en una pantalla de computadora o en un papel, donde se dispone de dos dimensiones f sicas solamente, lo que se expone en su lugar es una representaci on bidimensional de un cubo de tres dimensiones. Es decir, las dos dimensiones de la pantalla o el papel en el que muestran los datos est an separadas de la met afora que se usa para visualizarlos. Hasta aqu todo funciona, pero que ocurre cuando se agregan m as dimensiones? Como mostrar la informaci on de la manera m as optima para que se pueda analizar y manipular?
18
Veamos otra manera de visualizar los datos del cubo anterior.
Aqu se tiene esencialmente una grilla de dos dimensiones, pero la diferencia es que hay un indicador de p agina para la tercera dimensi on Productos. Las tres dimensiones de la informaci on, que son Variables, Tiempo y Productos, se mapean en las tres dimensiones de la met afora usada para representar los datos, que son las Columnas, Filas y P aginas respectivamente. Las las y columnas se corresponden con las dos dimensiones f sicas de la pantalla, pero las p aginas no se corresponden con ninguna. Esto implica que no se pueden ver todas las p aginas al mismo tiempo, y por ende, no se puede contar con los datos de todos los productos a la vez, sino uno por uno, salvo que se aplique una operaci on de Pivot. La met afora que implica esta selecci on de p aginas es mostrar una rodaja (slice ) del cubo.
19
Volvamos al problema de la representaci on gr aca al agregar una dimensi on m as. Una representaci on u til requiere que las dimensiones sean coexistentes e independientes. Es decir, coexistentes porque cada hecho representa un punto en el espacio de N dimensiones, e independientes porque nos podemos desplazar sobre cualquiera de ellas independientemente de las dem as. Por ejemplo, un punto en el cubo puede representar el hecho de que se vendieron 400 de televisores en el mes de Febrero. Este hecho est a identicado con un valor en cada dimensi on. La independencia entre dimensiones se maniesta cuando nos desplazamos desde las ventas de televisores en Febrero a las de Marzo, y despu es a las ventas de DVDs en Junio. El problema con la representaci on de informaci on en m as de tres dimensiones consiste en encontrar la manera de mapear las dimensiones l ogicas en las dimensiones f sicas de la pantalla o del papel. La soluci on es que varias dimensiones l ogicas compartan la misma dimensi on f sica.
20
En esta gura vemos como seis dimensiones se conectan en forma combinada a las las, columnas y p aginas de la grilla de tres dimensiones. La misma representaci on que funcionaba para tres dimensiones se puede adaptar f acilmente para trabajar con N dimensiones, lo que la convierte en una grilla multidimensional. Las dimensiones Productos y Escenario (cuyos miembros son valor Actual y valor Planeado) se combinan en las columnas, en las las se combinan las variables y la dimensi on del tiempo, y las p aginas se componen de la combinaci on de las dimensiones Sucursal, y Tipo de Cliente. En las siguientes guras vemos otras dos formas de mapear las seis dimensiones en este ejemplo a las, columnas y p aginas.
21
Las distintas posibilidades en la combinaci on de las dimensiones dan lugar a cambios en el formato y longitudes de la grilla, y tambi en en las cercan as de los datos. La longitud de las dimensiones est a directamente relacionada con la facilidad de navegaci on en la grilla. No es lo mismo observar una grilla de 50 las que observar una de 10000, donde tendremos que desplazar la pantalla, perdiendo el foco de an alisis o el punto espec co que est abamos observando. Por estas razones, en el momento de elegir cuales dimensiones combinar, hay que tener en cuenta las longitudes resultantes. La longitud de la combinaci on ser a igual al producto de las longitudes de las dimensiones que se est an combinando, y esto no es despreciable si se est a hablando de miles o hasta millones de las o columnas. Los cambios en la cercan a o en los vecinos de un cierto dato pueden afectar el an alisis gr aco.
22
Aqu vemos en la grilla superior los datos de las ventas por mes y sucursal organizados en dos dimensiones. Cada valor particular tiene cuatro vecinos. El valor de las ventas en la Sucursal Sur en el mes de Febrero por ejemplo, se puede comparar a primera vista con los meses de Enero y de Marzo, que son los valores vecinos de la izquierda y de la derecha respectivamente, y con los valores de las ventas de otras sucursales en el mismo mes, que son los valores vecinos de arriba y de abajo. En la grilla inferior las dimensiones se combinaron en una sola dimensi on f sica, y cada valor tiene ahora s olo dos vecinos. El valor de las ventas en la Sucursal Sur en el mes de Febrero ya no tiene como valores vecinos las ventas en esa misma sucursal en los meses de Enero y Marzo, haciendo que la comparaci on de los valores no sea tan directa a primera vista. No existen representaciones malas ni tampoco optimas, pero s algunas reglas para tener en cuenta cuando se analizan datos multidimensionales. El anidamiento o combinaci on de dimensiones en las las o en las columnas utiliza mas espacio en la pantalla que la combinaci on de dimensiones en p aginas, dejando menos espacio para la visualizaci on de los datos en s . Cuanto menos espacio se dedique a los datos, m as desplazamientos de pantalla se requerir an para visualizarlos. Lo conveniente es mantener la mayor a de las dimensiones mapeadas en p aginas, a menos que se necesite ver mas de un miembro de la dimensi on al mismo tiempo. En el caso de que no se pueda evitar el anidamiento en las o en columnas, es mejor anidar la mayor cantidad de dimensiones en las columnas, ya que generalmente es m as usable el espacio vertical de la pantalla que el horizontal. Una grilla cl asica tiene una
23
dimensi on en las las, de una a tres en las columnas, y el resto en las p aginas, como en la siguiente gura.
Observemos la diferencia de la grilla anterior con la que se presenta a continuaci on. En esta grilla se anidan cuatro dimensiones en las las, una en las columnas y ninguna en las p aginas.
24
Antes de decidir como organizar las dimensiones en la pantalla es u til preguntarse qu e se quiere ver y qu e se quiere comparar. Por ejemplo, si queremos comparar los costos actuales entre sucursales y por mes, para un producto y tipo de cliente en particular, lo ideal es mapear sucursales y meses a las y columnas, y las dimensiones de productos, escenario y tipo de cliente a p aginas, como en la siguiente gura.
25
La habilidad para cambiar f acilmente la forma de visualizar los mismos datos recongurando la organizaci on de las dimensiones es uno de los grandes benecios en cuanto a la navegaci on del usuario que tienen los sistemas multidimensionales.
Cap tulo 2 Consideraciones previas a la implementaci on

Antes de optar por una soluci on OLAP y ponerla en funcionamiento hay que poner a punto una serie de cuestiones en toda la organizaci on, ya que se van a extraer y mezclar datos provenientes de varios sistemas OLTP, sistemas batch y hasta de fuentes de datos externas. La organizaci on debe estar preparada para considerar la adquisici on de nueva tecnolog a, y sus integrantes deben estar predispuestos a tareas adicionales, al aprendizaje necesario, e incluso a cambiar roles y responsabilidades con otros integrantes de la organizaci on. Para determinar la naturaleza de estas consideraciones ser au til analizar primero los requerimientos de una soluci on OLAP. A partir de esto se puede realizar un an alisis costo benecio, y tambi en una evaluaci on del estado actual de la empresa, en cuanto al hardware, software, y datos existentes, para establecer el marco en el que se instalar a la herramienta.
2.1.
Requerimientos f sicos y l ogicos
Los requerimientos l ogicos esenciales para implementar una soluci on OLAP son: Poder establecer una rica estructura de dimensiones jer arquicas. Vivimos en un mundo que se caracteriza por conjuntos altamente multidimensionales de sistemas que interact uan, cada uno con muchos niveles de datos, detalles, realidades y abstracciones, y la habilidad de OLAP de representar ecientemente esta complejidad es una de sus principales cualidades, por lo tanto debemos aprovecharla al m aximo. Contar con un m etodo eciente y simple para especicar dimensiones, c alculos, y el conjunto de datos que se quiere analizar. El an alisis en una soluci on OLAP simplemente consiste en aplicar operaciones sobre valores num ericos. Lo importante es poder obtener resultados a partir de comparaciones inteligentes de ratios y tendencias en el tiempo o sobre otras dimensiones. Por ejemplo, un director de ventas en 26
CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION
27
la organizaci on puede consultar las diferencias entre las ganancias en el mercado nacional e internacional totalizadas por rubros de productos, y visualizarlas ordenadas de mayor a menor. Para responder a esta consulta la herramienta tiene que realizar varios c alculos: en primer lugar calcular el valor de ganancia por producto, lo cual no es trivial porque la ganancia es un valor derivado, y como tal se puede calcular de varias maneras. Luego estos valores se totalizan por rubros y por los mercados nacional e internacional, se calculan las diferencias entre los dos mercados, y por ultimo se ordenan los totales en forma descendente. El requerimiento es que este tipo de c alculos sea tan f acil de especicar o denir en la aplicaci on como lo es expresarlo. Flexibilidad en todos los aspectos, en particular en la visualizaci on de los datos, en la denici on de las consultas y en la interfase. Si hablamos de exibilidad en cuanto a la visualizaci on de datos, podemos decir que la aplicaci on es exible si permite visualizar los resultados en forma de grafos, matrices y charts, permitiendo al usuario optar seg un sus preferencias. La exibilidad en la denici on de consultas implica libertad y facilidad en la selecci on de las medidas y las dimensiones de los cubos, ltros sobre los resultados, y distintos formatos para los valores num ericos, entre otros. En otros tiempos, el an alisis de datos estaba a cargo de un grupo reducido de personas en la organizaci on, que dedicaban todo su tiempo a esta tarea. Hoy sin embargo, cada vez m as gente en la organizaci on est a capacitada para hacer an alisis de informaci on, pero s olo le dedican una porci on del tiempo de trabajo. Por esto se requiere que el entorno sea lo sucientemente amigable para hacer el trabajo r apido y no perder horas tratando de entender como usar la aplicaci on. La amigabilidad est a ntimamente relacionada con las interfaces gr acas que incluyen elementos para facilitar la denici on de las consultas, aunque siempre hay usuarios, generalmente avanzados, que preeren una interfase simple de l nea de comandos. Separaci on entre la estructura y la representaci on de los datos. Este requerimiento permite que los usuarios nales puedan reorganizar las vistas sin que requieran cambios estructurales en los datos. Esta separaci on no existe en las hojas de c alculo por ejemplo, lo que las hace muy r gidas para un an alisis de tipo OLAP. Entre los principales requerimientos f sicos para una aplicaci on OLAP encontramos los siguientes: Acceso r apido a los datos. OLAP necesita soportar consultas ad hoc, las cuales requieren c alculos en el momento en el que se est a realizando la consulta. Por ejemplo un gerente de ventas podr a consultar las ventas nacionales, profundizar a las ventas por regiones para observar cuales tienen ventas m as bajas, y luego profundizar para ver las ventas por rubros en una regi on determinada. Cada paso en este an alisis es una consulta, y si el tiempo de respuesta se midiera en horas, o incluso en varios minutos, esperar la respuesta de este an alisis seria bastante desalentador. La meta entonces es proveer un tiempo de respuesta razonable, en
28
lo posible en segundos, mientras se trabaja con una base de datos muy grande en un entorno multiusuario y quiz a distribuido en una red. Para cumplir con este requerimiento algunas herramientas precomputan (preconsolidan) todos los totales, aunque esto puede llevar a una explosi on de la base de datos. El incremento del tama no de la base de datos va a opacar el benecio ganado en el tiempo de respuesta. Para un acceso eciente, las herramientas tienen que combinar en forma precisa la cantidad y cuales datos precomputan y cuales se calculan en el momento. Soporte multiusuario. Las corporaciones est an divididas en areas de trabajo que colaboran entre si. Como resultado de esta descentralizaci on, varios empleados de distintas areas van a necesitar acceso a los datos de an alisis. Puede darse el caso que los datos que est a analizando un ejecutivo hayan sido generados por muchos departamentos distintos, y en las grandes corporaciones, estos departamentos ni siquiera est en en el mismo pa s. La manera de proveer soporte multiusuario que se preere en aplicaciones OLAP es un soporte de lectura/escritura multiusuario donde el procesamiento y los datos est an distribuidos entre el cliente y el servidor.
29
2.2.
An alisis costo-benecio
Es com un que la organizaci on tenga poco inter es en este tipo de iniciativas. Una de las razones puede ser que no se valore el impacto real que la carencia de buena informaci on tiene sobre la rentabilidad del negocio. Otra raz on puede ser la ausencia de un equipo de desarrollo dentro de la empresa, o quiz as nos encontramos en una organizaci on cuyos ejecutivos de negocios son gente inaccesible o poco dispuesta. As como puede ocurrir que no vislumbren los grandes benecios detr as de un proyecto de soluci on OLAP, es com un que no se perciba la complejidad del proyecto, y que no se lo reconozca como una iniciativa que abarca todos los aspectos de la organizaci on (crossorganizational), y sabemos que esto no es lo mismo que una aplicaci on independiente. Otra raz on que hace que los integrantes de la compa n a no se interesen por la incorporaci on de la herramienta puede ser el llamado s ndrome de silver bullet : los gerentes y desarrolladores conf an en que una o varias herramientas o metodolog as ya existentes en la organizaci on les resolver an todos sus problemas, entonces cualquier cosa nueva nunca ser a tan buena. Para que el inter es crezca entonces deben denirse claramente los benecios de la implementaci on OLAP, y dejar en claro que permitir a solucionar problemas existentes y tomar ventajas de las oportunidades en el negocio. Un proyecto de soporte de decisiones no solo puede traer benecios tangibles como un incremento en las ventas, sino tambi en intangibles, como mejorar la reputaci on de la empresa. Estos benecios intangibles son los mas dif ciles de cuanticar en t erminos de dinero, y aunque los benecios generales de este tipo de proyectos son bien conocidos, la gerencia no aprobar a el proyecto a menos que asociemos estos benecios generales con metas estrat egicas y problemas espec cos propios de la organizaci on. La idea es preparar una lista detallada con los benecios concretos para medirlos y compararlos con los costos de la implementaci on. La iniciativa del proyecto debe estar dirigida al negocio y no a la tecnolog a. Es decir, la justicaci on de la iniciativa no debe ser solo el hecho de experimentar con nuevas tecnolog as, sino reducir los problemas que afectan la rentabilidad o la eciencia de la organizaci on (business pain ).
30
2.3.
Evaluar el entorno actual de la empresa
Los elementos pertenecientes al entorno que se deben evaluar forman parte de la infraestructura de la organizaci on, tanto t ecnica como no t ecnica. Entre estos elementos se incluyen el hardware y motores de base de datos por un lado, y los datos y aplicaciones por el otro. Evaluaci on de la Infraestructura t ecnica Es conveniente analizar factores tecnol ogicos como la plataforma de hardware, conexiones de red, motores de bases de datos (DBMSs), y gateways DBMS que se usan en la organizaci on, adem as de hacer una revisi on de las herramientas y est andares que emplean los analistas de negocios. El objetivo de esta evaluaci on es el de planear una conguraci on que brinde la mejor performance para el acceso y recupero de los datos de la aplicaci on OLAP a implementar. Evaluar el hardware existente Es com un encontrar una especie de caos controlado en lo que respecta al hardware de una organizaci on, tal como se ve en la gura. Este caos viene acompa nado de una vasta lista de aplicaciones distintas y de un equipo de t ecnicos con los conocimientos sucientes como para hacer el soporte de los sistemas ya existentes.
En este escenario y ante la implementaci on de una aplicaci on de soporte de decisiones hay que tener en cuenta que en el caso de necesitar nuevas plataformas de hardware, estas tienen que encajar con la conguraci on existente. Los principales requerimientos a la plataforma de hardware son la potencia y la escalabilidad.
31
El hardware debe ser lo sucientemente potente, en cuanto a procesamiento y a espacio de almacenamiento, como para manejar accesos complejos y requerimientos de an alisis contra grandes vol umenes de datos. No solo debe soportar consultas simples y predenidas sobre datos resumidos sino tambi en consultas ad hoc complejas sobre datos detallados. La necesidad de que sea escalable surge del r apido crecimiento del volumen de la informaci on, y del r apido cambio en las frecuencias de actualizaci on, en los patrones de acceso a los datos, la cantidad de reportes y consultas, y en la cantidad de usuarios. Estos factores van a afectar directamente la aplicaci on de soporte de decisiones. Se debe planicar ademas la tolerancia a fallas, mediante equipos redundantes, y un plan de backup de los datos, para posibilitar la recuperacion siempre que sea necesario. Otros elementos de hardware importantes son los elementos de red, como routers, cables, switches, hubs, etc, que deben permitir un ancho de banda apropiado para una transferencia r apida de los datos. La red es una de las principales piezas que aseguran el exito de la soluci on OLAP. Con redes robustas, los datos se van a transferir r apidamente desde las bases de datos operacionales hacia el repositorio de datos, y desde el servidor OLAP al usuario nal para su an alisis. Evaluar los Gateways DBMS Los datos operacionales de la organizaci on pueden estar distribuidos en m ultiples plataformas DBMS, interactuando a trav es de una red. Los gateways existen para conectar estos datos con las aplicaciones. Tenemos: Gateways punto a punto: son los que proveen acceso a un solo tipo de DBMS. Son mas f aciles de implementar, y menos costosos que los dem as. Sin embargo, si en la organizaci on se requiere acceso a varios DBMSs, es mas conveniente contar con un solo gateway universal y no con varios gateways punto a punto, por simplicidad. Gateways universales: se pueden usar para acceder a distintos tipos de bases de datos y en distintas plataformas. Requieren un alto esfuerzo de implementaci on y mantenimiento, por lo tanto son bastante costosos. Gateways SQL: son los que usan SQL para acceder a la base de datos. Traducen los requerimientos de la aplicaci on a SQL nativo del DBMS en cuesti on. Solo pueden acceder a bases realmente relacionales (no simuladas). Drivers ODBC: Un driver ODBC (Open DataBase Connectivity ) es una aplicaci on que permite que cualquier sistema acceda a los datos independientemente del DBMS que los maneje, a trav es de APIs. Evaluar los DBMSs Al elegir la infraestructura de la base de datos hay que tener en cuenta el volumen
32
de los datos que se van a manejar. La elecci on puede variar desde un servidor de archivos local, un servidor empresarial o hasta un gran mainframe. Lo que podemos rescatar como conclusi on de lo mencionado es que el hardware, los gateways DBMS y el DBMS deben congurarse para asegurar la escalabilidad y la performance de la soluci on a implementar.
Evaluaci on de la Infraestructura no t ecnica La infraestructura no t ecnica incluye a los datos que se encuentran en la organizaci on y a las aplicaciones que se usan. En primer lugar es necesario construir un modelo l ogico de los datos de la empresa, una arquitectura consolidada y no redundante. Este es el primer paso para migrar los datos operacionales al DataWarehouse. Este modelo de los datos a nivel empresa se construye a partir de modelos de datos manejados en cada aplicaci on. Es interesante que en este proceso participen tanto los analistas de negocios como los analistas de sistemas, desarrolladores, y administradores de bases de datos. Estos u ltimos son los que mantienen las aplicaciones de la organizaci on diariamente, y conocen con bastante profundidad c omo y d onde se almacenan los datos, como se relacionan entre si, la historia de su uso, y c omo el contenido y el signicado de los datos fue cambiando con el transcurso del tiempo. Limpieza de datos (data cleansing) Una vez identicados los datos de inter es para la aplicaci on de procesamiento anal tico, es conveniente examinar los casos en que se incumplen reglas de negocios o de integridad, y discutir el impacto que tendr a el esfuerzo de la limpieza de estos datos, es decir su correcci on. La limpieza es una tarea que debe hacerse tambi en en forma conjunta con la gente de negocios y el grupo de desarrollo. Los primeros conocen la sem antica de los datos, y los desarrolladores conocen su signicado dentro de los programas. Son los que saben que un cierto ag en la base de datos indica si un determinado cliente tiene o no cuenta corriente, por ejemplo. Aun cuando se usen herramientas autom aticas, el costo de asegurar la calidad de los datos para la totalidad de la informaci on es elevado para muchas organizaciones. Por esto lo ideal es siempre concentrarse en la limpieza de datos cr ticos, teniendo en cuenta que no todos los datos son igual de cr ticos para la gente de negocios. No es necesario limpiar todos los datos, y tampoco es necesario hacerlo todo de una sola vez.
33
Entonces, cuando se seleccionan los datos que se van a usar para el soporte de decisiones se debe tener en cuenta si el dato esta lo sucientemente limpio. Si no es as , hay que ver cuales son las posibilidades de aplicar una limpieza, si es que existen, y especicar los procesos de limpieza que se determinen. Los gerentes suelen ver las actividades involucradas en el an alisis y limpieza de los datos como una p erdida de tiempo. Ellos juzgan el exito del proyecto de acuerdo al tiempo en el que se lo termina, y no se jan en la calidad de los resultados. Por esta raz on en la mayor a de las organizaciones los DataWarehouses se llenan con los datos de los sistemas operacionales simplemente por copia, sin eliminar problemas existentes, dando como resultado un DataWarehouse inconsistente y redundante. En cuanto a las aplicaciones, la evaluaci on consiste en examinar componentes como programas, ujo de tareas, bases de datos y archivos, que implementan las funciones, procesos y datos de negocios y las relaciones entre ellos. Una vez evaluados estos factores podemos identicar, catalogar y documentar tanto las aplicaciones como las reglas de negocios que afectan los datos.
Cap tulo 3 Dise nar la fuente de datos y migrarlos

Como vimos, las herramientas OLAP se usan para convertir los datos corporativos almacenados en la base de datos orientada al an alisis, en conocimiento u til para la toma de decisiones. En general el DataWarehouse o repositorio de datos es el area de almacenamiento que OLAP usa para hacer este proceso. Los datos se vuelcan desde los sistemas operacionales hacia el DataWarehouse, quiz a con alguna transformaci on previa de los datos. Esta transformaci on ocurre porque los datos en las bases operacionales pueden tener un formato inapropiado, o pueden existir inconsistencias en el caso de tener varias fuentes. Un ejemplo de inconsistencia se da si tenemos representada en una fuente de datos A la provincia de Buenos Aires con la abreviatura BS, y en otra fuente B se la representa con el nombre completo, BUENOS AIRES. El DataWarehouse almacena la informaci on cruda, y los sistemas OLAP hacen agregaciones y sumarizaciones de estos datos, y los organizan en cubos o almacenamientos especiales para permitir un r apido recupero ante una consulta. La siguiente gura muestra una arquitectura t pica de la interrelaci on entre las bases operacionales, el DataWarehouse y la aplicaci on OLAP. OLAP y los DataWarehouses se complementan entre s . El DataWarehouse almacena y administra los datos, y OLAP los convierte a informaci on u til.
34
CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS
35
3.1.
Qu e es un DataWarehouse (DW)?
Un DataWarehouse es un repositorio central o colecci on de datos en la cual se encuentra integrada la informaci on de la organizaci on y que se usa como soporte para el proceso de toma de decisiones gerenciales. El concepto de DataWarehouse comenz o a surgir cuando las organizaciones tuvieron la necesidad de usar los datos que cargaban a trav es de sus sistemas operacionales para planeamiento y toma de decisiones. Para cumplir estos objetivos se necesitan efectuar consultas que sumarizan los datos, y que si se hacen sobre los sistemas operacionales reducen mucho la performance de las transacciones que se est an haciendo al mismo tiempo. Fue entonces que se decidi o separar los datos usados para reportes y toma de decisiones de los sistemas operacionales y dise nar y construir DataWarehouses para almacenar estos datos. Las principales caracter sticas que posee un DataWarehouse se detallan a continuaci on: Es orientado a la informaci on relevante de la organizaci on: En un DataWarehouse la informaci on se clasica en base a los aspectos de inter es para la empresa, es decir, se dise na para consultar ecientemente informaci on relativa a las actividades b asicas de la organizaci on, como ventas, compras y producci on, y no para soportar los procesos que se realizan en ella, como gesti on de pedidos, facturaci on, etc. Es integrado: integra datos recogidos de diferentes sistemas operacionales de la organizaci on y/o fuentes externas. Esta integraci on se hace estableciendo una consistencia en las convenciones para nombrar los datos, en la denici on de las claves, y en las medidas uniformes de los datos.
36
Es variable en el tiempo: los datos son relativos a un periodo de tiempo y deben ser incrementados peri odicamente. La informaci on almacenada representa fotograf as correspondientes a ciertos per odos de tiempo.
Es no vol atil: la informaci on no se modica despu es de que se inserta, solo se incrementa. El periodo cubierto por un DataWarehouse var a de 2 a 10 a nos. Datamarts Las corporaciones de hoy se esfuerzan por conducir sus negocios hacia una base internacional. Vemos compa n as que surgieron en Estados Unidos y se expandieron a Europa, Asia y Africa. La expansi on del negocio crea la necesidad de acceder a datos corporativos que est an ubicados en diferentes puntos geogr acos. Por ejemplo, un ejecutivo de ventas de una compa n a con origen en Brasil que est a situado en Chile puede necesitar acceso a la base de datos de la empresa para identicar los clientes potenciales que residen en Chile. Este problema se soluciona creando versiones m as peque nas del DataWarehouse, los datamarts. Estas versiones se crean usando alg un criterio particular, como por ejemplo el lugar geogr aco. En el ejemplo anterior los datos de los clientes que residen en Chile se deben almacenar en el datamart de la sucursal en ese pa s. La existencia de los datamarts crea nuevas formas de pensar cuando se dise nan los repositorios corporativos de datos. Algunas corporaciones reemplazan completamente el concepto de tener un DataWarehouse central, por varios datamarts m as peque nos que se alimenten directamente de los sistemas operacionales.
37
Otras compa n as usan datamarts para complementar sus DataWarehouses. Mueven datos desde el DataWarehouse hacia varios datamarts con el n de permitir un an alisis m as eciente. La separaci on de los datos se determina seg un criterios como departamentos, areas geogr acas, periodos de tiempo, etc.
Finalmente, algunas organizaciones usan sus datamarts como el primer paso de almacenamiento de datos operacionales. Luego los datos de todos los datamarts se replican en un DataWarehouse corporativo central.
38
3.2.
Diferencias entre un DataWarehouse y una base de datos operacional
La mayor a de los sistemas operacionales est an dirigidos a la carga de datos, con cientos o miles de transacciones diarias y repetitivas, que adem as requieren un tiempo de respuesta muy corto por parte de los usuarios. Ejemplos de este tipo de operaciones lo son las reservas de vuelos, dep ositos bancarios, y reservaciones de hotel. Las bases de datos operacionales deben estar dise nadas con el objetivo de hacer esta tarea lo mas eciente posible. Otro objetivo del dise no es el ahorro en el espacio de almacenamiento. El cumplimiento de estos objetivos se logra evitando la redundancia de datos, por lo tanto, esta es una caracter stica distintiva de las bases de datos operacionales. Evitar la redundancia, desde el punto de vista t ecnico, se reere a no destinar columnas en varias tablas para almacenar el mismo dato. Esto es lo que se conoce como normalizaci on de la base de datos, y junto con la integridad referencial, asegura que los datos se agreguen y se actualicen de manera consistente y no redundante. Como consecuencia de la normalizaci on, tambi en se reduce el espacio requerido por la base de datos, ya que los datos se guardan en un solo lugar. La redundancia no solo es indeseable en las bases de datos operacionales porque reduce la performance de las operaciones de actualizaci on, sino tambi en porque lleva a inconsistencias, y la inconsistencia es una de las principales razones de la baja calidad en los datos. Las aplicaciones destinadas al an alisis de datos en cambio, est an orientadas a la salida de informaci on, ya sea en forma de reportes, cubos, o respuestas a consultas. Estas consultas y reportes no necesariamente se producir an en el mismo d a, ni diariamente. No son tan previsibles y frecuentes como las transacciones en un sistema operacional. Se podr a consultar por un conjunto de datos en periodo mensuales, otros datos se pueden requerir en forma cuatrimestral, etc. El tiempo de respuesta es importante, pero no es necesario nalizar el pedido de los datos en microsegundos, es suciente que la respuesta est e disponible en segundos o incluso en minutos. Mientras que la normalizaci on funciona bien para los sistemas operacionales, los requerimientos para el an alisis de datos son distintos. La normalizaci on implica un gran esfuerzo y tiempo para la recolecci on de los datos. Para obtener por ejemplo, un cubo de ventas anuales por sucursal, se tienen que acceder muchas tablas, y leer cada la de esas tablas. Esto no solo es complejo sino tambi en extremadamente ineciente si se hace en una base de datos normalizada, porque requiere un escaneo extensivo de varias tablas y muchas operaciones de JOIN.
39
Debido a esto, una de las principales caracter sticas en los DataWarehouses es la denormalizaci on en el dise no de las tablas. Adem as, los problemas de actualizaci on que surgen cuando existe redundancia en una base operacional no pueden ocurrir en un DataWarehouse. El DataWarehouse almacena informaci on preexistente en la organizaci on y no existen sobre el operaciones de actualizaci on y modicaci on en el sentido de las aplicaciones operacionales. En la gura se muestran las operaciones t picas sobre una base operacional, como inserciones, modicaciones y borrados. En cambio en un DataWarehouse solo hay dos operaciones, la carga inicial de datos y el acceso a los mismos. No hay actualizaci on en el sentido operacional, como una parte normal de procesamiento.
Otras diferencias entre estos dos tipos de bases de datos tienen que ver con los datos derivados, los datos hist oricos, y los datos totalizados. Las bases de datos operacionales almacenan muy pocos datos derivados, en general se derivan din amicamente cuando se los necesita, a diferencia de los DataWarehouses. En ellos, destinar espacio de almacenamiento a guardar los datos derivados ahorra mucho tiempo al procesamiento de consultas. Las bases de datos operacionales no guardan datos hist oricos. Todos los registros hist oricos se van archivando en otros medios de almacenamiento en forma peri odica. En los DataWarehouses, en cambio, se almacenan grandes cantidades de datos hist oricos, algunos con cierto grado de totalizaci on, y tambi en se guardan datos con alg un nivel de detalle. Por lo general, en un DataWarehouse la informaci on representa los datos sobre un horizonte largo de tiempo, quiz a desde cinco a diez a nos. El horizonte de tiempo representado en el ambiente operacional es mucho m as corto, desde valores actuales hasta sesenta a noventa d as atr as. Veamos con un ejemplo como ser a el an alisis de datos a partir de una base de datos operacional:
40
Supongamos que contamos con una base de datos operacional bancaria, y que un analista de negocios est a interesado en comparar las ganancias obtenidas de las transacciones en los cajeros autom aticos seg un el costo de la transacci on. Para obtener estos resultados podemos escribir una consulta SQL para tomar los datos del sistema OLTP, por ejemplo:
Hacer esto cada vez que el analista requiere alguna informaci on consume mucho tiempo y recursos, ya que las consultas podr an ser mucho mas grandes y complejas, involucrando muchas operaciones de JOIN, lo cual afectar a la velocidad con la que se recuperan los resultados y tambi en afectar a la performance de la base de datos operacional sobre la que se est an realizando importantes transacciones diarias. Esta es una de las razones por las cuales es conveniente tener los datos que sirven para an alisis en una base de datos aparte, y con un dise no diferente como los que veremos en las secciones siguientes. Veamos la diferencia entre ambos dise nos:
Dise no Operacional
41
Dise no Estrella Este u ltimo dise no es un dise no Star o Estrella, cuya descripci on veremos en la secci on siguiente. Luego de la migraci on de datos la tabla Transaction, captura las transacciones a nivel diario para cada sucursal, para todos los clientes, y para todos los servicios. Esta tabla, por lo tanto, va a volverse muy extensa. Para mejorar la eciencia con la que se recuperan los datos, las totalizaciones se precalculan en diferentes niveles y se almacenan en la base de datos o en un formato optimizado, como bases de datos multidimensionales. Las totalizaciones se generan a partir de las otras tablas. Por ejemplo, podemos totalizar las transacciones por mes, para todos los servicios, todos los clientes y todas las sucursales aplicando un GROUP BY por mes a la tabla Transaction (previo JOIN con la tabla Time). Tambi en podemos totalizar las transacciones por estado para todos los dias, todos los clientes y todos los servicios agrupando los datos en la tabla Transaction por el campo state. Podemos combinar de varias maneras las dimensiones para hacer totalizaciones sobre la tabla de hechos.
42
3.3.
Dise nar el DataWarehouse
Debido a las diferencias en el prop osito y objetivos de las bases de datos operacionales con las bases orientadas a an alisis se originaron t ecnicas de dise no diferentes para estas ultimas. Habiendo conocido en la secci on anterior las principales caracter sticas de este tipo de base de datos, veremos ahora cuales son los requerimientos en cuanto al dise no f sico y l ogico de las mismas.
3.3.1.
Dise no l ogico
Las premisas b asicas en el dise no l ogico son: Preparar a las bases multidimensionales para soportar el recupero de una gran cantidad de las de datos en forma r apida. La mayor a de los analistas de negocios van a querer ver datos totalizados. Estos datos en lo posible deben precalcularse y almacenarse de antemano para que esta recuperaci on sea r apida y eciente. Es importante adem as discutir el nivel de granularidad y de detalle esperado por los analistas cuando hacen operaciones de DrillDown. El dise no debe estar conducido por el acceso y por el uso, es decir, teniendo en cuenta que tipo de reportes o res umenes son los m as frecuentes, y cuales los m as urgentes. Un dise no normalizado no es bueno, no solo por lo mencionado en la secci on anterior, sino porque no resulta demasiado intuitivo para una persona de negocios, y podr a volverse demasiado complejo. Todos los datos que se incluyan ya deben existir en las fuentes de datos operacionales, o ser derivables a partir de ellos. Las dos t ecnicas de dise no m as populares son el esquema Star y el esquema Snowake. Esquema Star (Estrella) Este esquema est a formado por un elemento central que consiste en una tabla llamada la Tabla de Hechos, que est a conectada a varias Tablas de Dimensiones. En el ejemplo de la secci on anterior la tabla Transaction es la tabla de hechos del diagrama, y las tablas Time, Branch, Service y Customer son las tablas de dimension. Las tablas de hechos contienen los valores precalculados que surgen de totalizar valores operacionales at omicos seg un las distintas dimensiones, tales como clientes, productos o per odos de tiempo.
43
Representan un evento critico y cuanticable en el negocio, como ventas o costos. Su clave est a compuesta por las claves primarias de las tablas de dimensi on relacionadas (las foreign keys). Pueden existir varias tablas de hechos con informaci on redundante, porque podr an contener distintos niveles de agregaci on de los mismos datos. Por ejemplo podr a existir una tabla de hechos para las Ventas por Sucursal, Regi on y Fecha, otra para Ventas por Productos, Sucursal y Fecha, y otra tabla que almacene las Ventas por Cliente, Regi on y Fecha. En general las tablas de hechos tienen muchas las y relativamente pocas columnas. Las tablas de dimensi on representan las diferentes perspectivas desde donde se ven y analizan los hechos de la tabla de hechos. A diferencia de las anteriores, su clave primaria est a formada por un solo atributo, y su caracter stica principal es que est an denormalizadas. Esto signica que si la dimensi on incluye una jerarqu a, las columnas que la denen se almacenan en la misma tabla dando lugar a valores redundantes, lo cual es aceptable en este esquema. En general suelen tener muchas columnas pero pocas las. Siempre que sea posible, es conveniente compartir las tablas de dimension entre distintas tablas de hechos. Una de las dimensiones mas comunes es la que representa el tiempo, con atributos que describen periodos para a nos, cuatrimestres, periodos scales, y periodos contables. Otras dimensiones comunes son las de clientes, productos, representantes de ventas, regiones, sucursales. En la siguiente gura vemos un ejemplo de esquema Estrella, donde la tabla de hechos es la tabla Ventas, y el resto son las tablas de dimensiones.
El esquema estrella es el mas usado porque maneja bien la performance de consultas y reportes que incluyen a nos de datos hist oricos, y por su simplicidad en comparaci on con una base de datos normalizada. Esquema Snowake
44
Es una variante al esquema estrella en el cual las tablas de dimensi on est an normalizadas, es decir, pueden incluir claves que apuntan a otras tablas de dimension. En la siguiente gura vemos un esquema similar al anterior, donde la tabla de dimensi on Sucursal se expande en las tablas Distrito y Region. Ahora la tabla Sucursal contiene una columna clave DistritoId que apunta a la tabla Distrito, y esta a su vez tiene una columna RegionId que apunta a la tabla de dimension Region.
Las ventajas de esta normalizaci on son la reducci on del tama no y redundancia en las tablas de dimensi on, y un aumento de exibilidad en la denici on de dimensiones. Sin embargo, el incremento en la cantidad de tablas hace que se necesiten mas operaciones de JOINs para responder a las consultas, lo que empeora la performance. Otra desventaja es el mantenimiento adicional que requieren las tablas adicionales.
3.3.2.
Dise no f sico
Debido a que los DataWarehouses trabajan tanto con datos detallados como con datos resumidos, y frecuentemente almacenan algunos datos en forma redundante, el tama no de estas bases de datos puede ser enorme. Las bases de datos que se acercan o exceden el terabyte son llamadas VLDBs (Very Large Databases). Dise nar una base de datos de este tipo es un gran desaf o y la tarea de mantenerlas es demandante. Entre las decisiones de implementaci on que se deben tomar se incluyen el tama no del espacio libre, el tama no del buer, el tama no del bloque, y si se usa o no una t ecnica de compactaci on de la base de datos. Todas estas cuestiones afectar an la performance del DataWarehouse.
45
A continuaci on se detallan algunos temas que impactan sobre el dise no f sico del DataWarehouse. Particionamiento Las tablas deben particionarse y ubicarse en varios discos. Esto es mas que nada importante en las VLDBs, donde las tablas de hechos pueden llegar a ocupar varios cientos de gigabytes. El particionamiento permite que los datos de una tabla l ogica se repartan en multiples conjuntos de datos f sicos. Este particionamiento se basa en una columna de la tabla de hechos, que com unmente es la columna que indica la fecha. Dado que la columna por la cual se particione tiene que ser parte de la clave primaria, no puede ser una columna derivada ni contener valores nulos. El particionamiento es importante porque permite que se hagan backups y restauraciones de porciones de una tabla sin impactar en la accesibilidad de otras porciones en la misma tabla que no est an siendo backapeadas ni restauradas en ese momento. Otra ventaja del particionamiento es la opci on de almacenar los datos m as frecuentemente accedidos en dispositivos m as r apidos, o guardar distintos niveles de agregaciones en diferentes plataformas, por ejemplo, ubicar los datos totalizados en servidores distribuidos y mantener los datos detallados en un mainframe. Clustering Es una t ecnica muy u til para el acceso secuencial de grandes cantidades de datos. El clustering se obtiene deniendo un ndice clustering para una tabla, el cual determina el orden secuencial f sico en el que se almacenan las las en los conjuntos de datos. Esta t ecnica es importante porque mejora dr asticamente la performance del acceso secuencial, y este tipo de acceso es el mas usado en el procesamiento OLAP. Cuando las las de la tabla no permanezcan almacenadas en el orden correspondiente a su ndice clustering, situaci on conocida como fragmentaci on, la performance bajar ay habr a que reorganizar la tabla. Indexado Existen dos estrategias extremas de indexado: una es indexar todo, y la otra es no indexar nada, pero ninguna de las dos es conveniente. Las columnas que se elijan para indexar deben ser las que se usan mas frecuentemente para recuperar las las, y las que tienen una alta distribuci on de valores, no una baja como por ejemplo C odigo Postal. Una vez que se determinan las columnas a indexar, hay que determinar la estrategia de ndice. La mayor a de las DBMSs proveen varios algoritmos, entre ellos B-tree, Hash, archivo Invertido, Sparse y Binario. Se deber a optar por el mas optimo para el producto DBMSs que se est a usando.
46
Reorganizaciones Las cargas incrementales de las bases de datos ir an fragmentando las tablas, y esta fragmentaci on puede resultar en un decaimiento de la performance. La mayor a de las DBMSs proveen rutinas de reorganizaci on para reclamar el espacio fragmentado y mover registros. Las actividades b asicas involucradas en la reorganizaci on de una base de datos implican copiar la base de datos vieja en otro dispositivo, rebloquear las las y recargarlas. Estas tareas no son triviales en un DataWarehouse, pero todos los DBMSs permiten reorganizar particiones, lo cual es otra buena raz on para particionar las tablas. Backup y Recupero Los DBMSs proveen utilidades para hacer backups completos y tambi en incrementales. Muchas organizaciones tienen la err onea impresi on de que los DataWarehouses siempre se pueden recrear a partir de las fuentes de datos originales. Sin embargo, adem as de que esta tarea puede llevar mucho tiempo porque hay que reejecutar los programas de extracci on, transformaci on y carga, es posible que estos programas y los datos mismos ya no est en disponibles. Ejecuci on de las consultas en paralelo Para mejorar la performance de una consulta es mejor dividirla en componentes que ejecuten concurrentemente. Algunos DBMSs ofrecen ejecuci on paralela en forma transparente, es decir, dividen la consulta por si solos. Los DBMSs est an basados en reglas internas intrincadas, que deben entenderse y seguirse. Para esto las organizaciones contratan administradores de bases de datos. Una situaci on com un es que se deje el dise no de la base de datos a los programadores, quienes quiz a no est en del todo familiarizados con el funcionamiento interno del motor, y como consecuencia creen un dise no pobre que no aproveche al m aximo las caracter sticas que brinda el producto.
47
3.4.
Migrar los datos: ETL (Extract, Transform, Load)
La migraci on de los datos desde las fuentes operacionales al DataWarehouse requiere la necesidad de procesos para extraer, transformar y cargar los datos, actividad que se conoce como ETL.
La raz on por la cual se requieren estos procesos se origina en una necesidad de reformatear, conciliar y limpiar los datos de origen. Seria conveniente que las transformaciones a los datos se apliquen solo una vez y que se reejen en los archivos y bases de datos que act uan como fuente de datos. La mayor a de los datos de origen son los datos operacionales actuales, aunque parte de ellos pueden ser datos hist oricos archivados. Si los requerimientos de datos incluyen algunos a nos de historia es necesario desarrollar tres conjuntos de programas ETL: una Carga Inicial, una Carga Hist orica, y una Carga Incremental. Carga Inicial La carga inicial se asemeja mucho al proceso de conversi on entre sistemas que se da en las organizaciones cuando pasan, por ejemplo, de sus viejos sistemas operacionales a un producto ERP (Enterprise Resource Planning), y consiste en la extracci on, transformaci on, y carga de los datos tal cual se explicar a en las secciones siguientes. Carga Hist orica Este proceso debe verse como una extension de la carga inicial, pero la conversi on aqu es un poco diferente porque los datos hist oricos son datos est aticos. A diferencia de los datos operacionales, los datos est aticos ya se archivaron en dispositivos de almacenamiento oine. Es com un que con el transcurso del tiempo se eliminen elementos de datos que ya no sirven, se agreguen nuevos, se modiquen los tipos de ciertos datos o los formatos de los registros, lo que implica que los datos hist oricos no necesariamente se puedan sincronizar con los datos operacionales. Por lo tanto los programas de conversi on escritos para la carga inicial quiz a no sean aplicables a la carga de datos hist oricos sin algunos cambios previos.
48
Carga Incremental Una vez que el DataWarehouse est a cargado con datos iniciales e hist oricos, hay que desarrollar otro proceso para la carga incremental, que se ejecutar a mensual, semanal o diariamente. Existen dos formas de dise nar la carga incremental: Extraer todos los registros: se extraen todos los registros operacionales, independientemente de los valores que hayan cambiado desde la ultima carga realizada. En general esta opci on no es viable debido al volumen de los datos, por eso la mayor a opta por la siguiente opci on. Extraer Deltas solamente: solo se extraen registros nuevos o registros que contengan valores que cambiaron desde la ultima carga realizada. Dise nar programas ETL para extracciones delta es mas f acil cuando las fuentes consisten en bases de datos relacionales y contamos con una columna timestamp para determinar los deltas. Si los datos residen en archivos planos sin timestamp el proceso se vuelve mas complejo y puede requerir la lectura de archivos de auditoria para determinar los registros que cambiaron. Una alternativa consiste en extraer una copia completa de los datos y compararla con una extracci on previa para encontrar dichos registros y crear nuestro propio archivo delta. Otra alternativa es sugerir al equipo de desarrollo de los sistemas operacionales que agregue un timestamp, aunque en la mayor a de los casos los administradores no estar an de acuerdo porque cualquier cambio en la estructura de la base operacional requerir a cambios en los programas. Para ellos no es conveniente cambiar los sistemas cr ticos y perder tiempo en el testing a favor de la aplicaci on de an alisis. Qu e pasa con los registros eliminados? Cuando se borran registros en los archivos o bases de datos fuente, las las correspondientes no se pueden eliminar del DataWarehouse. Tampoco es lo ideal, ya que una de las principales caracter sticas de un DataWarehouse es guardar datos hist oricos! Es necesario denir reglas de negocios para determinar cuando propagar una eliminaci on operacional al DataWarehouse y cuando no. Por ejemplo, si se elimina un registro debido a la anulaci on de una transacci on err onea, es conveniente que la la relacionada a este registro se elimine del DataWarehouse. Si en cambio se elimina un registro porque se archiva, o porque el sistema guarda solo transacciones abiertas y elimina las cerradas, no debe existir propagaci on porque estar amos eliminando un dato hist orico. Existe otra complicaci on, que surge debido a que los programas que extraen deltas se dise nan para tomar s olo los registros existentes que contengan valores cambiados, no pueden extraer registros que no existen. La soluci on es usar archivos de auditoria, o crear un archivo delta comparando una extracci on completa con una extracci on anterior. En cualquier caso, una vez que
49
se identican los registros eliminados, el proceso ETL debe consultar las reglas de negocios para determinar si las eliminaciones se deben propagar al DataWarehouse.
3.4.1.
Extraer los datos
Desde la perspectiva de las bases de datos operacionales, la mejor manera de extraer los datos seria duplicar el contenido completo de los todos los archivos y bases de datos operacionales y pasar este conjunto de datos duplicado al personal que se encarga de crear el DataWarehouse. Sin embargo, los programas ETL tendr an que manejar archivos gigantes cuando en realidad solo se necesita un subconjunto de los datos de origen. Desde la perspectiva del DataWarehouse la manera mas simple de hacer la extracci on de datos seria ordenar, ltrar, limpiar y agregar todos los datos requeridos si es posible en un solo paso y en las mismas fuentes. Sin embargo, en algunas organizaciones este proceso podr a impactar tanto que los sistemas operacionales tendr an que suspenderse las actividades por varias horas. En la mayor a de las organizaciones, se dispone con suerte de 3 o 4 horas para poder procesar las bases de datos operacionales antes de que los sistemas se pongan en funcionamiento para la actividad diaria. Esta es la principal raz on por la que la migraci on de los datos se divide en tres procesos separados de extracci on, transformaci on y carga. La soluci on a este conicto es un compromiso entre la eciencia del proceso ETL y el tiempo de uso de las fuentes de datos. Es decir, los programas de extracci on de datos se tienen que dise nar para maximizar la eciencia del procesamiento ETL, pero adem as deben liberar las fuentes de datos lo antes posible, aunque este es un objetivo bastante dif cil de lograr. Una de las razones que dicultan la tarea de extracci on es la redundancia de datos en los sistemas operacionales, redundancia que los programas de extracci on deben detectar. Por ejemplo, el elemento de datos que almacena el nombre del cliente puede existir en varios archivos y bases de datos de origen. Estas ocurrencias redundantes deben consolidarse, con el procesamiento y b usqueda en las tablas que eso implica. Adem as, es necesario examinar las interdependencias operacionales entre los distintos archivos y bases de datos de donde se va a extraer la informaci on para determinar la secuencia de ejecuci on de los programas de extracci on.
3.4.2.
Transformar los datos
La mayor parte del trabajo ETL ocurre durante la transformaci on de los datos, porque es donde se requieren la integraci on y limpieza de datos. La extracci on y la carga solo representan el 20 % del proceso. Algunos problemas t picos cuando se extraen los datos del entorno operacional se mencionan a continuaci on:
50
Claves primarias inconsistentes: las claves primarias en las bases que act uan como fuentes de datos no siempre coinciden con las que se denen en el DataWarehouse. Por ejemplo, si existen cinco archivos de clientes, cada uno con una clave diferente, estas claves se tienen que consolidar o transformar en una u nica clave en el DataWarehouse. Valores inconsistentes: son datos duplicados que existen en la organizaci on, es decir, elementos que tienen una o mas copias exactas, pero debido a actualizaciones inconsistentes y otras anomal as, dejaron de ser copia exacta del original. Estos valores tambi en deben conciliarse durante el proceso ETL. Datos con diferentes formatos: los elementos tales como fechas o valores monetarios cuentan con una gran variedad de formatos. Esto da lugar a la necesidad de transformar estos datos a un formato u nico en el que se almacenar a en el DataWarehouse. Valores err oneos: la correcci on de valores incorrectos o que violen las reglas de negocios puede ser muy extensa y complicada. Los programas de transformaci on realizan c alculos y b usquedas en las tablas para determinar los valores correctos. Sin onimos y hom onimos: los datos redundantes no siempre son f aciles de reconocer porque el mismo elemento de datos puede tener diferentes nombres en las distintas fuentes. Otra situaci on que puede darse es que se use el mismo nombre en varias fuentes para referirse a elementos diferentes. Los sin onimos y los hom onimos no deben existir en el DataWarehouse, por lo tanto todos estos elementos deben renombrarse con nombres est andares denidos. L ogica embebida: algunos sistemas operacionales son muy viejos. Estos sistemas sol an tener relaciones y convenciones arcaicas y sin documentaci on entre los elementos de datos. Por ejemplo, el valor 00 en un campo Flag puede signicar que el env o se devolvi o, y el valor 11 en el mismo campo signica que el registro est a anulado. En la gura vemos algunos ejemplos t picos de transformaciones de datos.
51
Luego de transformar los datos debido a la existencia de tipos de datos y longitudes incompatibles, o datos inconsistentes o incorrectos, una gran porci on del proceso de transformaci on est a destinado a la integraci on, derivaci on, agregaci on y totalizaci on de los datos: Integraci on: el resultado de la integraci on es que cada elemento de dato u nico sea conocido por un nombre estandar.Muchos de los datos se renombran en forma acorde a ciertos est andares de nombramiento en el DataWarehouse, por ejemplo, renombrar Cliente_Nom como ClienteNombre. Derivaci on: se crean nuevos datos a partir de datos at omicos en las fuentes, mediante c alculos, b usquedas, y l ogica procedural. Por ejemplo, generar un nuevo c odigo para clasicar clientes bas andose en cierta combinaci on de datos existentes, calcular el precio total como resultado de multiplicar el precio unitario por la cantidad vendida, o unir la columna Nombre con la columna Apellido para obtener una u nica columna NombreCliente en el Datawarehouse. Otro ejemplo consiste en dividir elementos de datos y que cada una de las porciones resultantes conformen una columna en el DataWarehouse. Por ejemplo, dividir una columna de tipo fecha o timestamp en sus componentes, como dia, mes, cuatrimestre y a no. Las reglas t ecnicas y de negocios que determinan las transformaciones que se tienen que aplicar se extraen de viejos manuales, viejos memos, emails, programas, y tambi en son propuestas por gente en la organizaci on que recuerda cu ando y porqu e se crearon las distintas reglas.
52
La parte mas importante de la transformaci on de datos consiste en el prec alculo de los mismos para que las consultas al DataWarehouse se respondan mas ecientemente: Totalizaci on (Sumarizaci on): consiste en procesar valores num ericos para obtener valores generales como cantidades, promedios, m aximos, m nimos, totales. Estos valores son los que componen las tablas de hechos, y se pueden calcular y almacenar en distintos niveles, por ejemplo, calcular los totales de ventas por departamentos, los totales por regiones, y los totales por pa s. Agregaci on: se reere a crear datos derivados a partir de la uni on de varios datos at omicos, en forma horizontal. Por ejemplo, agregar los elementos de datos de un cliente a partir de la tabla Clientes y de la tabla Ventas para armar un historial de los movimientos del cliente en la empresa. La mayor a de los datos se agregan y se totalizan bas andose en patrones de los reportes requeridos y en la estructura de la base de datos multidimensional elegida (Star o Snowake). Es importante examinar en que momento realizar cada transformaci on. Hay solo un proceso ETL, as que las transformaciones aplicables a todos los datos de origen, como las conversiones de tipos, se deber an realizar en primer lugar. Las transformaciones especicas del DataWarehouse, como agregaciones y totalizaciones, deber an realizarse m as hacia el nal del proceso. Conciliaci on de datos El prop osito de la conciliaci on de datos es asegurar que toda la informaci on que ingresa al proceso ETL coinciden con la que sale del mismo. Creer que las aplicaciones OLAP son menos criticas en cuanto a la correctitud de los datos que las operacionales es un grave error. Las aplicaciones OLAP son tan criticas como las operacionales porque las decisiones que se toman se basan en los datos que proveen, y estas decisiones afectan la direcci on estrat egica de la organizaci on. Una conocida disciplina cuando se manipulan datos es conciliar toda salida del proceso con la entrada. Cada programa o m odulo que lea datos y los escriba en otro lugar debe producir totales de conciliaci on. Existen tres tipos de totales: Cantidad de registros Uno de los totales fundamentales es una simple contabilizaci on de los registros le dos y los escritos. Tambi en se deben contabilizar los registros rechazados en el caso de registros que no pasaron alg un chequeo del proceso ETL. Luego, el total de registros escritos mas los rechazados debe ser igual al total de registros le dos. Esta conciliaci on se usa cuando se extraen, ordenan y mezclan las de datos. Cantidad de Dominios Se cuenta la cantidad de registros para cada dominio (o valor) u nico en el campo de entrada, y por otro lado se cuenta la cantidad de registros para el mismo dominio
53
en la salida del proceso ETL. La complicaci on surge cuando un elemento de datos sobrecargado se tiene que dividir en varias columnas. El dominio de un elemento sobrecargado describe mas de un objeto de negocios y por eso debe separarse en el DataWarehouse en diferentes columnas en diferentes tablas, en general tablas de dimensi on. En este caso, el total registros para un dominio en la entrada debe ser igual a la suma de los totales de registros para los dominios en los que se divide. Si hubo valores rechazados tambi en deben contabilizarse, y en este caso el total de la suma de los dominios en la salida mas el total de valores rechazados debe ser igual a la cantidad de registros del dominio de entrada. Totales Los totales constituyen el mecanismo principal de conciliaci on. La tarea consiste en sumar y totalizar una determinada columna en la entrada, y hacer lo mismo en el campo correspondiente en la salida. Si hubo registros rechazados, se deber a mantener un tercer total. Luego, la suma del total de salida mas el total rechazado debe ser igual al total de entrada. Si el campo de entrada es un elemento sobrecargado que se tiene que dividir en varias columnas, se deben determinar las formas de calcular y vericar los totales. La conciliaci on de datos, al igual que la limpieza son actividades que tienden a estar ausentes en el proceso ETL. La organizaci on desaprovecha la oportunidad de poner orden en el caos de los datos y contin uan desplazando los datos desde las fuentes al DataWarehouse tal cual est an. Su u nico objetivo es que la estructura receptora de los datos no los rechace por razones t ecnicas como claves duplicadas, o tipos y longitudes que no coincidan. Sin embargo, la gente de negocios espera calidad y consistencia en los datos, y esto se logra aplicando todas las transformaciones necesarias y realizando los chequeos correspondientes. D onde se guardan los datos que se est an migrando? Las actividades de ordenar, mezclar, y transformar los datos requieren un espacio de almacenamiento temporal para guardar los resultados intermedios. Estos archivos y tablas temporales pueden llegar a ser mas grandes que el almacenamiento de origen. La alternativa general es ir guardando estos datos directamente en tablas del DataWarehouse.
3.4.3.
Cargar los datos
El paso nal en el proceso ETL es la carga de los datos en el DataWarehouse. Este proceso se puede aplicar de dos maneras: podemos insertar las nuevas en las tablas mediante c odigo escrito a medida, o hacer una carga masiva usando alguna herramienta de importaci on del DBMS. Este u ltimo enfoque es el m as eciente y el m as usado en la mayor a de las organizaciones. Una vez completados los pasos de extracci on y transformaci on, no deber a ser muy complicado completar el proceso ETL con el paso de carga. Sin embargo, es necesario considerar el tema de la integridad referencial y los ndices:
54
Integridad Referencial: Debido al gran volumen de los datos, en ocasiones se desactiva esta opci on durante la carga para acelerar el proceso, pero el programa ETL tiene que estar capacitado para hacer los chequeos necesarios. Si esto no es as , el DataWarehouse se volver a corrupto en pocos meses o quiz a en semanas. La raz on por la que se tiende a desactivar la Integridad Referencial surge del hecho de que se cargan solo datos con relaciones ya existentes en el ambiente operacional, y no se crean nuevas relaciones. Sin embargo, quiz a las relaciones existentes no est en bien denidas o sean nulas, o quiz a las bases de datos de origen no sean relacionales. De todas maneras se debe activar una vez completado el proceso de carga, para que el DBMS determine cualquier violaci on de integridad entre datos relacionados. Indices: Las bases de datos con performance pobre frecuentemente son la consecuencia de un esquema pobre de indices. Es necesario denir indices en forma eciente, y en gran cantidad, debido al gran volumen de datos en el DataWarehouse. Construir los indices en el momento de la carga retarda mucho el proceso, por lo tanto se recomienda eliminar(DROP) todos los ndices antes del proceso de carga, cargar los datos, y luego crear los ndices nuevamente.
3.4.4.
Evaluar herramientas ETL externas
El proceso ETL es por lejos el m as complicado de dise nar y desarrollar en este tipo de proyectos. La mayor a de las organizaciones preeren usar una herramienta para todo o parte de este proceso, especialmente para la extracci on y transformaci on. Cuando se usa una herramienta ETL, las especicaciones correspondientes a las transformaciones se traducen a instrucciones para la herramienta. Algunos de los pasos a seguir durante la evaluaci on son: 1. Realizar un an alisis costo-benecio para ver si conviene comprar la licencia de un producto ETL o desarrollarlo desde cero. Aunque ambas opciones son costosas, la primer elecci on deber a ser la licencia. Si la herramienta no puede manejar todas las transformaciones requeridas, debemos pensar en el desarrollo propio. 2. Listar los vendedores y productos ETL que satisfagan nuestros requerimientos, y dejar que estos u ltimos -no la palabra del promotor- sean los que conduzcan la evaluaci on. Evaluar cada producto objetivamente, e incluir las reglas de negocios que permiten la limpieza de los datos como parte del criterio de selecci on. Por ejemplo, algunas herramientas no pueden leer archivos planos ni realizar transformaciones muy complejas. Si necesitamos estas capacidades debemos conocer las limitaciones de cada herramienta porque tendremos que adquirir licencias adicionales o incrementar su funcionalidad con c odigo propio. La reputaci on y responsabilidad de los vendedores son tan importantes como las
55
caracter sticas de los productos, as que es conveniente tener en cuenta este factor tambi en. 3. Si es posible contactarse con organizaciones que ya est en usando el producto. 4. Reducir la lista a dos o tres productos candidatos, para no perder tanto tiempo en la comparaci on y la elecci on denitiva. 5. Revisar demos de los productos, y si es posible preparar algunos casos de test para que los vendedores preseleccionados demuestren la performance y efectividad de sus productos. 6. Tratar de obtener un trial de 30 dias para poder testear el producto. El testing es la mejor forma de descubrir suras antes de usar el producto en producci on.
Cap tulo 4 Implementar una Herramienta OLAP

Una vez que contamos con la fuente de datos completamente organizada, el siguiente paso es poner atenci on sobre las opciones disponibles para la implementaci on de una herramienta concreta. Conceptualmente, la arquitectura de una herramienta OLAP consiste de tres componentes funcionales: Servicios de Presentaci on, Servicios OLAP, y Servicios de Bases de datos. Servicios de Presentaci on La gente que va a usar la informaci on multidimensional son analistas de negocios, gerentes, ejecutivos, no t ecnicos. Por lo tanto, los datos tienen que aparecer en un formato que les permita a sus usuarios desarrollar propuestas, denir niveles de inversi on, y establecer metas. Los servicios de presentaci on tienen que ser f aciles de usar, y la facilidad de uso tiene que estar determinada por sus usuarios, y no por el equipo t ecnico. Por ejemplo, los analistas de negocios preeren una interface gr aca sumamente intuitiva y poder trabajar con t erminos familiares. Por lo tanto, una herramienta OLAP debe ocultar la estructura subyacente de los datos y los procesos que se ejecutan para formar las vistas multidimensionales de los mismos. La facilidad de uso de la herramienta se deber a poder expresar en t erminos cuanticables, como por ejemplo cuanto tiempo se necesita para aprender a usarla, cu an r apido se puede hacer un an alisis, cu an c omodos est an los usuarios con la herramienta, si cumple con toda la funcionalidad requerida, y en qu e medida es integrable a otras herramientas, como MS Excel por ejemplo. Los servicios de presentaci on tienen que ser exibles y adaptables al cambio porque los distintos usuarios tienen preferencias y skills diferentes. Por ejemplo, algunos preeren los reportes tabulares, y otros los gr acos y charts. Los men us, iconos y funciones tienen que estar congurados seg un el perl del usuario, y poder recongurarse seg un sea necesario. Los usuarios expertos esperan una mayor performance y respuestas r apidas,
56
CAP ITULO 4. IMPLEMENTAR UNA HERRAMIENTA OLAP
57
as que la presentaci on deber a consistir en una pantalla menos cargada. Una herramienta ideal debe poder ajustarse a las distintas preferencias y brindar diferentes niveles de presentaci on. Servicios OLAP Las consultas, los reportes y el an alisis de datos son actividades muy relacionadas, interactivas e iterativas. Por ejemplo, podemos ver los resultados de una consulta en forma de grilla, chart o gr aco, y mientras estamos estudiando estos resultados, podemos requerir una nueva consulta, e imprimir los resultados en un reporte. Las herramientas OLAP deben integrar los servicios de consultas, reporte y an alisis. No es pr actico que un usuario tenga que salir de una herramienta de consulta para poder usar otra herramienta de reportes. Estas tres actividades deben intercalarse mediante una suave transici on realizada por la misma herramienta, no por el usuario. Servicios de Base de datos Como se mencion o anteriormente, la arquitectura OLAP soporta dos tipos de base de datos, las relacionales y las bases de datos multidimensionales propias de cada herramienta en particular. Las herramientas ROLAP pueden acceder a cualquiera de las conocidas bases relacionales, como DB2, Oracle y MS SQL Server, mientras que el dise no subyacente sea multidimensional, como un esquema estrella o snowake. Las herramientas MOLAP est an dise nadas para acceder a bases de datos propias, con estructuras de datos especiales, y realizar sus operaciones sobre estas estructuras, como Hyperion Essbase, una herramienta OLAP que guarda los cubos en estructuras propias. El mercado actual ofrece una amplia gama de herramientas OLAP. OLAP Survey 4 es el m as reciente de una serie de concursos realizados por Nigel Pendse, consultor y conferencista de OLAP, y www.survey.com, una compa n a que ha realizado cientos de ex amenes y encuestas concernientes a la tecnolog a de la informaci on, entre otras areas. Este concurso tiene como objetivo evaluar las herramientas OLAP m as contundentes en el mercado. De los 42 productos presentados, solo 11 tuvieron suciente uso como para ser incluidos en el reporte de resultados. Estas herramientas son Applix TM1, BusinessObjects, Cognos PowerPlay, Hyperion Essbase, MIS Alea, MicroStrategy, Microsoft Analysis Services, los tres productos de Oracle, Express, Discoverer, y OLAP Option) y SAP BW (Business Information Warehouse). Las principales diferencias entre ellas tienen que ver con el tipo de almacenamiento que permiten. Algunos links donde obtener m as informaci on sobre las distintas herramientas son: http://www.applix.com/solutions/ http://www.businessobjects.com/products/default.asp
58
http://www.cognos.com/products/business_intelligence/analysis/ index.html http://www.hyperion.com/products/business_intelligence/analysis/ essbase_analytics.cfm http://www.microstrategy.com/Software/Products/Service_Modules/ OLAP_Services/ http://www.microstrategy.com/Solutions/5Styles/olap_analysis.asp http://www.oracle.com/technology/products/discoverer/index.html http://www.oracle.com/technology/pub/articles/rittman_olap.html Otros links de inter es sobre el OLAP Survey y OLAP en general son: www.survey.com/olap www.olapreport.com
Para comprender m as profundamente el manejo y uso de los datos multidimensionales es conveniente indagar en el uso de una herramienta en particular. En la siguiente secci on profundizaremos en la herramienta Microsoft Analysis Services.
59
4.1.
Microsoft SQL Server Analysis Services
Microsoft reconoci o la importancia de proveer un mejor sistema de base de datos para hacer DataWarehousing, y tambi en proveer las herramientas necesarias para que el an alisis de datos sea un proceso mas f acil y placentero. En principio lanz o al mercado Microsoft SQL Server 7 OLAP Services, luego mejor o esta soluci on con la nueva versi on SQL Server 2000 Analysis Services. En esta secci on veremos el uso de esta herramienta y sus principales caracter sticas, y conoceremos las mejoras incorporadas en la u ltima versi on, SQL Server 2005 Analysis Services. Comencemos conociendo la arquitectura de Microsoft Analysis Services. En el nivel mas alto, esta arquitectura se divide en tres grandes componentes: las fuentes de datos operacionales, Analysis Services y sus herramientas, y las aplicaciones cliente.
En cuanto a las fuentes de datos, las bases de datos relacionales SQL Server sirven como el principal datasource para An alisis Services, aunque cualquier otra base de datos que provea conectividad a trav es de ODBC, u OLE DB Provider, como Oracle por ejemplo, puede actuar como tal. Usualmente la estructura de estas bases de datos se transforma a un esquema estrella o snowake usado en los Datawarehouses OLAP. Si profundizamos un poco dentro de la arquitectura propia de Analysis Services, encontramos que se compone de: transformaciones de datos, un almacenamiento, un componente Analysis Server, y un componente llamado PivotTable Service. Transformaciones de datos: DTS - Data Transformation Services Microsoft introdujo los DTS en SQL Server 7 para facilitar la recolecci on y transferencia de datos desde sus fuentes OLTP al sistema OLAP. Esta herramienta brinda una manera de mover los datos desde las fuentes al destino en el Datawarehouse, realizando adem as tareas de validaci on, limpieza, consolidaci on, y transformaci on de los datos cuando es necesario.
60
Un objeto b asico, llamado paquete, almacena la informaci on correspondiente a estas tareas y el orden en el cual se deben realizar. Un paquete puede incluir una o mas conexiones a diferentes datasources, y las distintas tareas y transformaciones que se ejecutan como pasos que denen un ujo de trabajo del proceso. Los componentes del paquete DTS se pueden denir usando varias herramientas, todas instaladas con SQL Server, entre ellas: Un DTS Designer que ayuda al usuario a crear paquetes DTS y mantenerlos. En la creaci on de un paquete podemos construir las trasformaciones a partir de tareas predenidas o a partir de un script escrito por nosotros conocido como Microsoft ActiveX Script. Los lenguajes que se pueden usar son VB Script, JScript o PerlScript. Sin embargo, se pueden hacer llamadas a c odigo externo escrito en cualquier lenguaje que soporte OLE, como Visual Basic, Visual C++, y Delphi entre otros. Un Asistente de Importaci on/Exportaci on con la misma funcionalidad del DTS Designer, que gu a al usuario en la creaci on y ejecuci on de paquetes DTS para exportar e importar datos entre dos datasources que cumplan OLE DB. El asistente tambi en permite realizar transformaciones a los datos durante el proceso. Un DTS Query Designer, cuya funci on es construir consultas DTS. Una interface de programaci on COM y un conjunto de interfaces OLE que permiten la creaci on de aplicaciones propias para importar/exportar y transformar. Los programas que usan estas interfaces van desde simples scripts en Visual Basic o JScript hasta complejas aplicaciones C++. Esta caracter stica es especialmente importante en la construcci on de un Datawarehouse, donde las transformaciones de datos se vuelven bastante complejas debido a que los datos tienen que coincidir con un esquema diferente del operacional, y ser sometidos a agregaciones y validaci on. Con la exibilidad que brindan las interfaces COM, todos estos requerimientos se pueden satisfacer sin problemas. Entonces, podemos denir las actividades de transformaci on de datos usando el asistente de importaci on/exportaci on de datos para modicar los datos a medida que se copian desde la fuente al almacenamiento destino, o mediante un programa o Microsoft ActiveX script. Esta clase de script usa la API de DTS para conectarse al datasource y transformar los datos. Este no es el m etodo mas f acil, pero si el mas exible dado que se dispone del poder del lenguaje de programaci on usado. Almacenamiento Las posibilidades de almacenamiento incluyen al DataWarehouse (o datamarts en el caso de que existan) y las bases de datos OLAP. Tambi en se incluyen bases relacionales usadas para almacenar tablas con datos totalizados por Analysis Services durante la construcci on de cubos OLAP.
61
Los modos de almacenamiento posibles en Analysis Services incluyen archivos multidimensionales (MOLAP), bases de datos relacionales (ROLAP), o un almacenamiento h brido (HOLAP). Dado que MOLAP requiere copiar todos los datos y convertirlos a su propio formato para llenar el almacenamiento multidimensional, MOLAP es apropiado para conjuntos de datos no muy extensos. El almacenamiento ROLAP mantiene los datos que llenan los cubos en sus tablas relacionales originales y se usa un conjunto de tablas relacionales para almacenar los datos agregados. Estas u ltimas tablas son llamadas vistas materializadas, y se crean de acuerdo a las dimensiones cuando se procesa el cubo. Con esta opci on, las tablas de agregaci on tienen columnas para cada dimensi on y cada medida. Cada columna de dimensi on esta indexada, y tambi en se crea un ndice compuesto con todas las columnas de dimensi on. ROLAP es ideal para grandes bases de datos o para datos que no son tan consultados. Con HOLAP, los datos originales se mantienen en sus tablas relacionales como en ROLAP, y las agregaciones de datos se almacenan en un formato multidimensional. Una ventaja de este sistema es que HOLAP provee conectividad a extensos conjuntos de datos en las tablas relacionales pero con la ventaja de una mayor performance cuando se consultan datos agregados en el almacenamiento multidimensional. Una desventaja de esta opci on es que la cantidad de procesamiento entre los sistemas ROLAP y MOLAP puede afectar su eciencia.
Analysis Server El Analysis Server es el coraz on de Microsoft Analysis Services, y sirve para extraer datos de fuentes heterog eneas, analizar datos multidimensionales, crear cubos de datos, construir las agregaciones, y conectar el cliente a los datasources. Tambi en puede utilizar las tablas con datos sumarizados que residen en bases de datos OLTP. Analysis Server puede trabajar con varias herramientas del lado del cliente, como English Query, y Microsoft Oce, en especial MS Excel y MS Access, permitiendo que estas herramientas accedan a los cubos a trav es del PivotTable Service. Esto constituye una gran ventaja para usuarios que est en muy familiarizados con estas herramientas. PivotTable Service Es una herramienta de procesamiento del lado del cliente, es decir, funciona como un cliente del Analysis Server. Este servicio se encarga de permitir el an alisis online y oine de los datos OLAP, y tambi en la construcci on de cubos. El an alisis
62
oine es posible gracias al manejo de cach e de este servicio, que permite que los usuarios descarguen datos de fuentes multidimensionales o relacionales y las usen en modo oine en cubos locales. Tambi en brinda una interface COM para que otras aplicaciones cliente accedan al Analysis Server, los datos OLAP y la cach e del cliente. Veamos la utilidad de la cach e con un ejemplo. Supongamos que el usuario solicita los datos sobre ventas de Enero, Febrero y Marzo de 2004. Estos datos son obtenidos por el PivotTable Service mediante el Analysis Server. Supongamos ahora que el usuario hace una segunda consulta solicitando las ventas del primer trimestre del a no 2004. En este caso, no es necesaria una nueva consulta al Analysis Server por parte del PivotTable, ya que este tiene la capacidad de realizar los c alculos necesarios, y adem as tiene los datos base para realizar los mismos en cach e, previamente almacenados en la consulta anterior. Microsoft Analysis Services es una herramienta que cuenta con varios asistentes, editores y material de ayuda en cada paso. Las herramientas principales de administraci on con las que cuenta son el Analysis Manager y el Enterprise Manager (Administrador Corporativo) de SQL Server. Analysis Manager Es una interface gr aca (GUI) que permite que el usuario construya una soluci on OLAP bas andose en datasources existentes. Esta interface permite una c omoda administraci on de las bases de datos OLAP, mediante asistentes para agregar nuevos cubos de datos, cambiar la estructura de cubos existentes agregando o cambiando dimensiones y sus niveles de complejidad. Tambi en permite administrar la seguridad de los cubos tal que podamos garantizar el acceso autorizado a los datos correspondientes. Cuenta adem as con Asistentes de an alisis de uso y de optimizaci on basada en el uso. Administrador Corporativo El DataWarehouse es una base de datos SQL Server y el Administrador Corporativo es la herramienta que nos permite mantenerlo. Adem as esta herramienta es la que se usa para mantener todas las bases de datos operacionales, las cuales constituyen la fuente de datos que se usa para cargar el DataWarehouse.
Ahora que conocemos la arquitectura y los componentes principales de Microsoft Analysis Services veremos un ejemplo que nos ayudar a a aclarar algunas cuestiones involucradas con la creaci on del repositorio de datos o Datawarehouse, y luego un ejemplo de la construcci on y an alisis de un cubo de datos.
63
4.1.1.
Migrar los datos de una base OLTP hacia un esquema estrella usando paquetes DTS
En este ejemplo contamos con una base de datos OLTP altamente normalizada para optimizar el ingreso de datos. Consiste de varias tablas de las cuales las mas importantes son la tabla Orders y Orders_Details. En la siguiente gura vemos un diagrama de la estructura de esta base de datos que llamaremos OLTP.
El esquema Estrella dise nado para el Datawarehouse al cual se van a migrar los datos consiste de cinco tablas, una tabla de hechos llamada Sales y cuatro tablas de dimensi on llamadas Customers, Products, Time y Geography.
Ya tenemos establecidas las bases de datos fuente y destino para la migraci on de los datos. Lo que necesitamos ahora es dise nar un paquete DTS que realize la transformaci on
64
y migraci on. Para esto debemos iniciar el editor de paquetes de Microsoft Analysis Services seleccionando el nodo Data Transformation Services y eligiendo la opci on New Package en el men u contextual. Primero vamos a considerar la migraci on de los datos que van a conformar las dimensiones. Debemos insertar en el paquete cuatro tareas de trasformaci on, o Transform Data Task, cada una con sus respectivas fuentes y destinos, los cuales est an constituidos por objetos llamados Connection. En principio tendr amos lo siguiente:
Los objetos connection llamados OLTP representan la misma conexi on a la base con el mismo nombre. Cuando arrastramos el primero de ellos al area de dise no creamos la conexi on estableciendo la propiedad DataSource a Microsoft OLE DB Provider for SQL Server, y la propiedad Database a OLTP, entre otras.
Para los objetos OLTP restantes establecemos la conexi on existente. De la misma manera que establecimos la conexi on con la base OLTP, establecemos una usando el objeto DATAWAREHOUSE con la base de datos Datawarehouse, seleccion andola en la propiedad Database del objeto. El siguiente paso consiste en congurar la carga de los datos que van a conformar la dimensi on de clientes. Para esto debemos seleccionar una de las Transform Data Task que
65
enlazan alguna de las conexiones OLTP a la conexi on DATAWAREHOUSE y establecemos en sus propiedades la base de datos Datawarehouse y la tabla Customer como destino y como origen la siguiente consulta SQL:
Podemos chequear en la solapa Transformations del cuadro de dialogo de Propiedades las correspondencias entre las columnas origen y destino.
La construcci on o carga de la dimensi on de tiempo es similar al proceso seguido en la carga de la dimensi on de clientes. Tomamos una segunda Transform Data Task, y establecemos la siguiente consulta SQL como origen de la tarea:
66
En esta consulta se usan varias funciones de fecha para crear los valores necesarios para las columnas del DataWarehouse que no existen originalmente en la tabla Orders de la base de datos OLTP. Como destino establecemos la tabla Time de la base de datos Datawarehouse. El pr oximo paso consiste en tomar la tercer Transform Data Task libre y establecer sus propiedades para efectuar la carga de la dimensi on de zonas geogr acas. Como destino denimos la Tabla Geography del DataWarehouse, y la consulta que usaremos como origen de la transformaci on en este caso ser a:
Ahora debemos crear la dimensi on que nos falta, la dimensi on de Productos. La creaci on de esta dimensi on es muy similar a las anteriores, aunque existe una diferencia. Debemos tomar la ultima Transform Data Task libre, establecer como destino la tabla Products del DataWarehouse, y usar la siguiente consulta SQL para denir el origen de los datos:
Luego, en la solapa Transformations del cuadro de di alogo de Propiedades, creamos una nueva trasformaci on usando el bot on New , en particular un ActiveX Script. Un cuadro de di alogo nos permite congurar, entre otras cosas, el lenguaje del script, las columnas que incluye, y las funciones que se les aplican. En este caso seleccionamos todas las columnas en ambas tablas, fuente y destino, y como lenguaje optamos
67
por VB Script. El c odigo del script transforma los ProductNames y BrandDescriptions a nombres en may uscula:
En el tab Transformations podemos notar las relaciones muchos a muchos indicadas por el diagrama de mapeo de columnas.
Ahora debemos agregar una Transform Data Task que enlace una conexi on a OLTP y una conexi on a la base de datos Datawarehouse para congurar la carga de la tabla de hechos. El esquema del paquete DTS se ver a ahora como en la gura:
68
El enlace que conecta los dos grupos de tareas es un objeto On Success Workow, y est a ah para asegurar que la ultima tarea no comience hasta que las cuatro tareas precedentes no se completen exitosamente. Para construir la tabla de hechos Ventas en el DataWarehouse usamos la Transform Data Task de la derecha y establecemos sus propiedades para congurar la carga. Como destino establecemos la tabla Ventas del Datawarehouse, y como origen denimos la siguiente consulta SQL:
Ahora el paquete est a listo para ejecutarse, y su ejecuci on llenar a el DataWarehouse con la informaci on del sistema OLTP. Captura o extracci on de datos de las bases operacionales Vimos en cap tulos anteriores que la actualizaci on del Datawarehouse una vez que fue cargado por primera vez se puede realizar de varias maneras. La extracci on simple de datos de las fuentes nos brinda una fotograf a est atica de la informaci on en un punto espec co en el tiempo. Esta t ecnica funciona bien cuando se cargan bloques de datos en el DataWarehouse, que van a reemplazar otro bloque de datos relacionados a la misma fuente pero en un punto distinto en el tiempo. Por ejemplo, actualizar un DataWarehouse con los datos del a no actual y archivar los datos del a no anterior en otro medio f sico. Otras t ecnicas mas sosticadas para extraer datos incluyen la captura de logs de DBMS, captura basada en triggers, captura asistida por aplicaciones, captura por timestamp, y la comparaci on de archivos. Con la t ecnica de Captura de logs DBMS los datos a extraer se determinan a partir del sistema de logs del DBMS. La ventaja de esta t ecnica es el m nimo impacto que la extracci on tiene sobre la base de datos operacional y los sistemas que acceden a ella, pero requiere que el DBMS soporte logging, y tambi en un claro entendimiento sobre el formato de los registros de log. Este m etodo no es posible en SQL Server porque el formato de los archivos de log generados por el SQL Proler son internos a SQL Server, y no es f acil leerlos fuera de esta herramienta. La mayor a de los sistemas de administraci on de bases de datos soportan stored procedures y triggers. La Captura basada en triggers utiliza el hecho de que estos u ltimos pueden ejecutar consultas SQL o aplicaciones complejas cuando ocurren ciertos
69
eventos en la base de datos, en particular, cuando se insertan nuevos registros, o se actualizan o eliminan registros existentes. Tambi en podemos usar programas escritos a medida para la extracci on de datos, que incluyan la l ogica para capturarlos. Las tecnolog as de abstracci on de datos provistas por Microsoft, como OLE DB y ADO permiten acceder a una amplia variedad de fuentes de datos. Las t ecnicas de Captura de logs, Captura basada en triggers y Captura asistida por aplicaciones son capaces de producir un registro incremental de los cambios en las fuentes, lo que nos permite mantener una continuidad de los datos en la historia. Estas t ecnicas en general requieren alguna otra facilidad para la carga inicial de los datos. La Captura basada en timestamp es una t ecnica simple que consiste en chequear un valor timestamp para determinar si el registro cambi o desde la u ltima captura. La Comparaci on de archivos no es una t ecnica muy eciente, pero si f acil de entender y de implementar. La idea es guardar en un archivo una fotograf a de los datos de origen en el momento de la extracci on de los datos, y compararlo con un archivo previo generado en la extracci on anterior. Cualquier cambio y/o adici on que se detecte se guarda en un archivo separado para cargarlo al DataWarehouse. Estas dos ultimas t ecnicas tambi en nos permiten mantener una continuidad de los datos, sin embargo, quiz a no sea tan precisa. Supongamos que un registro en particular se ve afectado por varios cambios entre dos capturas. La historia capturada sobre este registro ser a mas bien una historia basada en puntos en el tiempo, y no un registro del continuo cambio del mismo, porque el cambio que se extrae es el u ltimo de los producidos en el intervalo. Es necesario tener en cuenta todas estas t ecnicas durante la planicaci on de la captura de los datos. En general, el mejor escenario de uso para la extracci on simple es la carga inicial del DataWarehouse, y el resto de las t ecnicas se utilizan en la carga incremental del mismo. Si queremos mantener una historia de cambios continua en el tiempo es conveniente usar las t ecnicas de Captura de logs, Captura basada en triggers y la Captura asistida por aplicaciones. Las t ecnicas de Captura por timestamp y comparaci on de archivos, como dijimos, nos brindan una historia de cambios por periodos. El proceso de transformaci on puede requerir procesar varias veces los datos extra dos, ya que los mismos valores que se usan como medidas en una tabla de hechos, quiz a tambi en se requieran en el calculo de agregaciones. Mantenimiento del Datawarehouse Algunas de las cuestiones que deben tenerse en cuenta en una planicaci on de mantenimiento del DataWarehouse se detallan a continuaci on: Plan de seguridad La seguridad en SQL Server se expande al DataWarehouse y a los cubos OLAP. Analysis Services provee seguridad a trav es de los roles que se denen a nivel cubo.
70
Estos roles est an altamente integrados con los usuarios y los grupos de usuarios del sistema operativo. El prop osito de un plan de seguridad es establecer cuales usuarios pueden ver los datos, cu ales datos, y qu e actividades pueden realizar. SQL Server provee un modelo sosticado de seguridad que si es bien usado previene de accesos no deseados a los datos y objetos de las bases de datos. Este modelo de seguridad permite dos modos de autenticaci on, autenticaci on Windows o autenticaci on mixta (SQL Server y Windows). Backup y Recupero del DataWarehouse Estas actividades permiten la restauraci on completa de los datos luego de una falla en un medio f sico, da nos causados por usuarios u aplicaciones, o ca das del servidor. Adem as de ser u til en estas situaciones, hacer backups y restauraciones de una base de datos es u til tambi en si queremos moverla o copiarla de un servidor a otro de manera f acil y r apida. Auditor a La auditor a permite reconocer todas las actividades que ocurrieron en la base de datos y qui en realiz o estas acciones. La auditor a en SQL Server se implementa como parte de la seguridad. Recolecci on de datos estad sticos Es importante monitorear la forma en que los usuarios usan el DataWarehouse y las herramientas OLAP. Conocer cu ales consultas se realizan en un cubo particular y en qu e frecuencia, nos permite modicarlo para que estas consultas se ejecuten mas ecientemente. Algunos valores interesantes para monitorear son la cantidad promedio y maxima de consultas contra cierta tabla de hechos, la cantidad promedio y maxima de las retornadas por consulta, la cantidad promedio y maxima de tiempo de ejecuci on de las consultas. Archivar datos Como el DataWarehouse recibe mas y mas datos de las fuentes operacionales, su tama no crece y las consultas se vuelven cada vez mas lentas. Para mantener la performance de las consultas es necesario separar los datos de las tablas de hechos en varias, de acuerdo a una determinada columna. Por ejemplo separar la tabla de hechos Ventas en las tablas Ventas2003 y Ventas2004, con los datos pertenecientes al a no 2003 y 2004 respectivamente. Adem as, las tablas de hechos que ya tienen varios a nos y no se usan casi nunca deber an archivarse fuera de la base de datos para poder reusar ese espacio.
71
4.1.2.
Crear un Cubo y sus dimensiones
En esta secci on veremos c omo crear y analizar un cubo multidimensional con Microsoft Analysis Services. Dise naremos las dimensiones, las medidas, estableceremos la fuente de datos y dise naremos su almacenamiento. Una vez creado el cubo podremos procesarlo, y por ultimo veremos la funcionalidad b asica de la herramienta para analizar y manipular los datos en el cubo. La creaci on de un cubo multidimensional se realiza usando el Analysis Manager. Esta herramienta tiene una apariencia y funcionalidad similar al Enterprise Manager. En el panel izquierdo presenta una estructura jer arquica, de arbol, en la que podemos ver todos los Analysis Servers establecidos en el entorno. El ejemplo muestra solo un servidor, cuyo nombre se deriva autom aticamente de la instalaci on de MS SQL Server 2000, por defecto el nombre de la maquina.
Crear una base de datos OLAP Antes de dise nar un cubo, es necesario establecer una base de datos, mas espec camente una base de datos OLAP. Una base de datos OLAP es similar a una base de datos SQL Server en que esta compuesta por varios objetos. Una base de datos com un contiene tablas relacionales y vistas, mientras que una base de datos OLAP contiene cubos multidimensionales, dimensiones, datasources y otros objetos. Para crear la base hay que seleccionar un servidor, y elegir Nueva base de datos en el men u contextual. Le damos el nombre EjemploOLAP, y opcionalmente podemos darle una descripci on. Una vez agregada, EjemploOLAP aparece en la estructura de arbol, e incluye una serie de subcarpetas predenidas, por ahora vac as, para almacenar los objetos como cubos y dimensiones que se generen.
72
Establecer un origen de datos Luego de crear la base de datos OLAP debemos enlazarle un data source (o varios) antes de comenzar a construir el cubo. Estas fuentes de datos deben estar accesibles via OLE DB Providers, como SQL Server, Access u Oracle. Para establecer la asociaci on expandimos el nodo EjemploOLAP, seleccionamos la carpeta Orgenes de datos y elegimos Nuevo Origen de datos en el men u contextual. Ahora estamos en condiciones de establecer una serie de par ametros relacionados con el datasource.
En este ejemplo vamos a establecer como datasource la base de datos FoodMart2000.mdb, una base de datos multidimensional organizada con un esquema snowake que se instala como ejemplo junto con Analysis Services. Como es una base de datos Access seleccionamos Microsoft Jet 4.0 OLE DB Provider en el tab Provider. Para establecer una conexi on, seteamos los par ametros correspondientes en el tab Connection del cuadro de dialogo. En este caso seleccionamos la base de datos FoodMart2000.mdb.
73
El bot on Test Connection permite testear la conexi on establecida con la fuente de datos. Ahora el Data Source se agrega al arbol en el panel izquierdo del Analysis Manager. Ya tenemos una base de datos OLAP enlazada a un datasource v alido. Dise nar un cubo El dise no de un cubo primero exige determinar qu e se quiere capturar como medidas, es decir, los valores cuantitativos que se quieren analizar y monitorear como indicadores de la actividad del negocio. Las medidas como ventas y costos son interesantes, sobre todo si se analizan valores actuales y planeados, para alcanzar un buen an alisis de la performance de la organizaci on. Otro elemento que se debe determinar son las dimensiones, es decir, las perspectivas o vistas en las que las medidas tienen relevancia y signicado. Una dimensi on que siempre es u til es la que representa el tiempo. Para crear un cubo Analysis Services provee un asistente que nos gu a en la selecci on de medidas y dimensiones de una manera directa. Para iniciar el asistente debemos expandir EjemploOLAP, seleccionar la carpeta Cubos, y elegir Nuevo Cubo/Asistente en el men u contextual. El primer paso consiste en seleccionar una tabla de hechos del data source FoodMart2000. Un cubo puede tener mas de una tabla de hechos, aunque para simplicar supondremos que cuenta con solo una. De la lista de tablas pertenecientes a esta base de datos seleccionamos la tabla de hechos sales_fact_1998.
74
En el panel derecho se detallan las columnas de la tabla seleccionada. El bot on Examinar datos... permite una vista previa de los datos de la tabla. El paso siguiente consiste en seleccionar las columnas num ericas que actuar an como medidas, es decir, las columnas sobre las que se realizar an las agregaciones. De la lista de columnas num ericas pertenecientes a la tabla sales_fact_1998 elegimos las columnas store_sales, store_cost, y unit_sales. Mediante el Editor de Cubos, a cada una de estas columnas se les puede aplicar una funci on de agregaci on como Sum (por defecto), Count, Max, Min y Distinct Count.
El paso siguiente consiste en seleccionar las dimensiones, pero como aun no existen dimensiones creadas, debemos generarlas. Las dimensiones son an alogas a una cl ausula GROUP BY de SQL, ya que los datos de un cubo OLAP est an organizados, o agrupados, en dimensiones. Analysis Services maneja
75
varios tipos de dimensiones con distintas caracter sticas. Para crear una dimensi on iniciamos el Asistente para Dimensiones mediante el bot on Nueva Dimension..., pero antes veamos un poco cuales son las dimensiones soportadas en la herramienta de Microsoft. Dimensiones compartidas Las dimensiones compartidas pueden ser usadas por m ultiples cubos. En lugar de construir varias dimensiones para el mismo tipo de informaci on, usamos solo una, ahorrando tiempo de desarrollo y de procesamiento. En la carpeta Dimensiones Compartidas podemos encontrar todas las dimensiones denidas para el cubo actual, y pueden editarse y agregarse nuevas. Dimensiones privadas Las dimensiones privadas son particulares al cubo que las contiene. Se construyen junto con el cubo y se procesan autom aticamente cuando se procesa el cubo,lo que implica reprocesarlo si se modican la estructura o los datos de alguna de estas dimensiones. Dimensiones Virtuales Las dimensiones virtuales dependen de las propiedades de los miembros de una dimensi on existente. Por ejemplo, dada una dimensi on Sucursal, una de las posibles propiedades de los miembros podr a ser TipoSucursal, con los valores mayorista y minorista. Al construir una dimensi on virtual sobre esta propiedad, los usuarios nales pueden agrupar la informaci on no solo por las dimensiones, sino tambi en por los atributos de las dimensiones. En este caso, pueden organizar los datos seg un las sucursales y tambi en seg un sucursales mayoristas y minoristas. Dimensiones Parent-Child o Primario-Secundario Este tipo de dimensiones nos permiten reejar ciertas estructuras jer arquicas del mundo real en las que un miembro juega mas de un rol. Veamos como ejemplo la tabla de dimensi on Employee de la base de datos Foodmart2000, donde existen empleados que tienen a otros a cargo, los que a su vez pueden ser supervisores de otros empleados.
Reejar esta situaci on mediante una dimensi on com un requerir a conversiones, ya que la estructura es desbalanceada y esta caracter stica no est a soportada por una dimensi on com un. Para crear una dimensi on de tipo parent-child se denen la columna clave que identica cada miembro y una columna parent. La relaci on entre ambas columnas dene la jerarqu a de la dimensi on.
76
Dimensiones con varias jerarqu as En Microsoft Analysis Services se pueden denir jerarqu as multiples en t erminos del nombre de la dimensi on de la que son parte introduciendo un punto que separe el nombre de la dimensi on del nombre de la jerarqu a. Por ejemplo, para crear dos jerarqu as para la dimensi on Tiempo, una para el periodo scal y otra para el per odo calendario, creamos dos dimensiones con los nombres Tiempo.Fiscal y Tiempo.Calendario respectivamente. Las jerarqu as m ultiples se tratan como dimensiones separadas en Analysis Services. Un efecto colateral indeseable es que se van a crear agregaciones entre las dos dimensiones que representan las jerarqu as, las cuales usualmente resultan insignicativas y solo consumen espacio de disco y tiempo de procesamiento. En este ejemplo vamos a crear dimensiones compartidas. En primer lugar crearemos una dimensi on a partir de un esquema estrella, donde como sabemos existe una sola tabla para cada dimension. Luego crearemos una dimensi on a partir de un esquema snowake, donde una dimensi on esta representada en varias tablas. El primer paso en la creaci on de una dimensi on consiste en seleccionar c omo queremos crearla. Para crear una dimensi on a partir de un esquema estrella seleccionamos la primer opci on.
El siguiente paso consiste en seleccionar la tabla de dimension correspondiente. De la lista de tablas pertenecientes al datasource elegido seleccionamos la tabla Region.
77
El paso siguiente consiste en seleccionar los niveles posibles para la dimensi on, si es que existen. A partir de las columnas disponibles de la tabla de dimensiones seleccionamos sales_country, sales_region, sales_state_province, sales_ district y sales_city como niveles de la dimensi on, en ese orden. El ordenamiento es acorde al grado de detalle en cada nivel.
El asistente nos previene si intentamos establecer un ordenamiento que podr a no resultar l ogico, como por ejemplo poner el nivel de distritos(Sales District) por encima del de las provincias(Sales State Province). El siguiente paso es especicar los miembros de la dimensi on. Debemos denir las member key columns o columnas clave, que son las que distinguen los miembros en cada nivel. En este caso, seleccionamos sales_country, sales_region, sales_state_ province, sales_district y sales_city, para los cinco niveles respectivamente.
78
En el Editor de Cubos se pueden denir las member name columns o columnas de nombre de los miembros, que contienen los nombres para los miembros de un nivel, aunque en general esta informaci on est a dada por la misma columna clave.
Una vez que denimos toda la informaci on necesaria para crear la dimensi on, el asistente presenta una vista previa en la que podemos ver la estructura de arbol con los miembros en los respectivos niveles de la jerarqu a.
Cuando creamos una dimensi on se crea un nivel adicional adem as de los que especicamos. Se trata de un nivel llamado Todos [NombreDimension], Todos Region en este caso, que se incluye por defecto y resume todos los datos en el nivel mas alto de la dimensi on. Podemos deshabilitarlo usando el Editor de Dimensiones. Ahora retornemos a la creaci on del cubo en el Asistente para Cubos, donde podemos observar que Region ya aparece en la lista de dimensiones del cubo.
79
Ahora vamos a crear una dimensi on llamada Products, a partir de un esquema Snowake. Los pasos b asicamente son los mismos que en la creaci on de la dimensi on Region, pero en el dialogo donde antes seleccionamos la opci on esquema Estrella, ahora seleccionamos esquema Snowflake(o copo de nieve). En la selecci on de tablas de dimensi on elegimos las tablas product y product_class. Recordemos que en el esquema snowake una dimensi on involucra a m as de una tabla. El paso siguiente consiste en crear y editar las relaciones entre las tablas seleccionadas para componer la dimensi on Products. El asistente detecta y muestra las relaciones obvias entre estas tablas, es decir, relaciones formadas por pares de columnas con el mismo nombre. En este caso las tablas product y product_class est an relacionadas mediante la columna product_class_id.
80
Luego, de la misma manera que con la dimensi on Region, seleccionamos los niveles correspondientes y los ordenamos desde el mas resumido al mas detallado. En este caso, establecemos los niveles product_category, product_subcategory, y brand_ name, en ese orden. Ahora veremos cuales son los pasos para agregar una dimensi on de tiempo. Inicialmente debemos crear la dimensi on con el esquema estrella, y seleccionar la tabla time_by_day como la tabla de dimensi on. En este ejemplo el datasource ya contiene una tabla de dimensi on de tiempo, aunque en general la dimensi on de tiempo se deriva de una columna en la tabla de hechos. En el ejemplo, la tabla time_by_day est a relacionada a la tabla de hechos mediante la columna clave time_id. Cuando el asistente detecta que existe una columna de tipo datetime en la tabla seleccionada ofrece la opci on de crear una dimensi on est andar o una dimensi on de tiempo. Optamos por la segunda opci on, y establecemos que la columna que se usa para denir la dimensi on es the_date, en este caso, la u nica columna de tipo datetime en la tabla Time_by_day. Ahora debemos considerar los niveles de la dimensi on. El asistente presenta por defecto las niveles mas comunes, como a no-cuatrimestre-mes-d a, a no-cuatrimestre-mesd a-hora-minuto, a no-trimestre-mes, etc. Adem as permite establecer una fecha de inicio del a no distinta al 1 de enero. Esto es particularmente u til para reejar periodos contables o scales. La conguraci on para nuestra dimensi on de tiempo es la siguiente:
En este punto tenemos el modelo denido: establecimos un conjunto de dimensiones con sus niveles, y tambi en las medidas y las tablas de hechos en las que residen.
81
El siguiente paso consiste el guardar el modelo de cubo.
Es probable que surjan mensajes de error porque no se pueden encontrar relaciones entre algunas tablas, las cuales deben establecerse manualmente. Las complicaciones surgen cuando el asistente intenta procesar el cubo y no puede determinar relaciones obvias entre las tablas de hechos y las de dimensi on. Estas relaciones se deben establecer en forma manual para que el procesamiento del cubo pueda continuar, y para esto usamos el Editor de Cubos, donde podemos observar las tablas de hechos y de dimensiones y sus interrelaciones.
Observemos que el Asistente no detect o la relaci on entre la tabla de hechos sales_ fact_1998 y la tabla de dimensi on Region. Agregar una relaci on es muy simple bajo
82
circunstancias normales, solo debemos parear ambas claves en las tablas a relacionar. Sin embargo, parecen no existir claves comunes entre las tablas sales_fact_1998 y Region. Necesitamos denir y usar un puente o tabla intermedia que complete esta asociaci on l ogica. Agregamos la tabla store, y relacionamos las tablas region y store mediante la columna region_id, y las tablas store y sales_fact_1998 mediante la columna store_id. El siguiente paso consiste en dise nar el almacenamiento para el cubo. Por denici on, los cubos OLAP constituyen un mecanismo de almacenamiento para agregaciones precalculadas, las cuales conducen a una performance mas r apida en las consultas. El dise no del almacenamiento consiste en establecer las caracter sticas de estas agregaciones, las cuales se construyen durante el procesamiento del cubo. Para realizar esta tarea de dise no, Analysis Services provee un Asistente de Almacenamiento. El primer paso consiste en seleccionar el tipo de almacenamiento. Analysis Services brinda los tres modos de almacenamiento para los datos y las agregaciones: MOLAP, ROLAP y HOLAP. En este caso vamos a optar por un almacenamiento MOLAP.
El paso siguiente es establecer las opciones de agregaci on para el cubo. Podemos establecer la restricci on de que el espacio de disco ocupado por el cubo no supere una cierta cantidad de almacenamiento, o bien establecer que la performance se mantenga siempre por encima de un porcentaje determinado, sin considerar el espacio de disco que se requiera para lograrlo. Cualquier opci on implica un tradeo entre el espacio en disco y la performance de las consultas en el cubo, ya que cada incremento en la performance requiere un mayor uso del espacio de almacenamiento. Si usamos el bot on Iniciar podemos observar un gr aco que previsualiza los posibles resultados de la opci on seleccionada.
83
En este ejemplo establecimos que la performance tiene que permanecer por encima del 80 %. Al observar el gr aco vemos que este objetivo se logra designando casi 0.2 MB para el almacenamiento de 11 agregaciones en el cubo. Ahora podemos procesar el cubo. Para hacerlo seleccionamos el cubo en el panel izquierdo de Analysis Services, elegimos Procesar... en el menu contextual, y luego la opci on Proceso Completo.
Durante el procesamiento se cargan los datos desde el datasource designado y se generan las totalizaciones denidas en las opciones de agregaci on. La ventana de Proceso nos permite monitorear esta actividad.
84
Adem as de la opci on de procesamiento completo del cubo, Analysis Services brinda las opciones de Actualizaci on Incremental y Actualizaci on de datos. La Actualizaci on Incremental permite procesar los datos que se agregaron u ltimamente en la tabla de hechos, determinando cuales son mediante alg un criterio en una cl ausula WHERE. Si la actualizaci on no especica ning un criterio o ltro, se actualizar a con la tabla de hechos completa y se agregar an datos ya existentes, originando informaci on duplicada. La Actualizaci on de Datos se usa cuando no se hizo ning un cambio a la estructura del cubo, y simplemente se quiere refrescar la informaci on existente. Esta opci on es la mas c omoda cuando reprocesamos un cubo no muy grande y no estamos seguros de que se hayan agregado nuevos datos. La opci on que usamos, Proceso Completo, es la que se requiere cuando se cambia la estructura del cubo, ya que lo reconstruye completamente. Existe adem as una opci on Actualizar de forma incremental las dimensiones compartidas utilizadas en este cubo. Esto reeja la importancia de procesar las dimensiones antes de procesar el cubo, para que este ultimo proceso pueda considerar a los posibles nuevos miembros de las dimensiones.
85
4.1.3.
Analizar y manipular el Cubo
Luego del procesamiento del cubo, los datos ya est an listos para analizar. Para esto vamos a utilizar el Cube Browser incluido en Analysis Services. Esta herramienta permite ltrar los datos seg un las dimensiones, aplicar operaciones DrillUp para ver datos mas resumidos, o DrillDown para ver datos mas detallados, es decir, los datos subyacentes a un valor total previamente seleccionado. Para iniciar el Cube Browser expandimos el nodo EjemploOLAP en el Analysis Manager, luego expandimos la carpeta Cubos, seleccionamos el cubo CostoyVentas y elegimos Examinar Datos en el men u contextual.
Inicialmente el Browser nos muestra los datos correspondientes a las tres medidas, store_sales, store_cost y unit_sales, organizados en una sola dimensi on, Products. En el panel superior est an las otras dos dimensiones, Region y Time. Podemos cambiar las posiciones de las dimensiones. Podemos analizar las medidas organizadas por region reemplazando la dimensi on Products por la dimensi on Region. Este reemplazo se realiza simplemente arrastrando la dimensi on Region y solt andola encima de la columna que ocupa la dimensi on Products.
86
Si observamos la dimensi on Time vemos que est a establecida en el miembro Todos Time, es decir, las medidas que estamos observando valen para todas las fechas sin ltro alguno. Por defecto las dimensiones se establecen inicialmente en el m aximo nivel, es decir, el mas resumido. El nivel establecido para las dimensiones en el panel superior esta siempre visible para mantener la orientaci on constante sobre los datos que se est an presentando. Si luego queremos analizar las medidas desde una perspectiva del producto pero manteniendo la clasicaci on por la dimensi on Region, debemos arrastrar la dimensi on Products y soltarla en cualquier lugar de la grilla. Esta acci on provoca que la dimensi on se agregue a la grilla, no que reemplace otras dimensiones como en el paso anterior. El resultado es una grilla donde los totales para las regiones se subdividen seg un los miembros de la dimensi on Products. Se mantiene la columna Todos Products, que act ua como una columna de totales.
Veamos algunos ejemplos de operaciones t picas en el an alisis OLAP. Una operaci on de tipo Slice & Dice permite establecer un ltro en los datos, seleccionando un miembro de alguna dimensi on en particular. Para seleccionar un miembro de la dimensi on Time por ejemplo expandimos el combo para visualizar la jerarqu a de la dimensi on y seleccionamos, por ejemplo, el miembro Trimestre 3 perteneciente al miembro 1998 para ver la informaci on del tercer trimestre del a no 1998.
87
Autom aticamente las medidas en la grilla se reajustan para reejar solo los valores que pertenezcan al periodo de tiempo ltrado.
Una operaci on DrillDown, como sabemos, permite ver datos mas detallados. Para detallar las medidas un nivel mas en la dimensi on Products basta con hacer doble clic en la celda Product_Category para expandirla. Como resultado de esta operaci on, adem as de los datos detallados se crea una nueva celda Product_Subcategory que sirve para indicar el nivel actual de la dimensi on.
Una operaci on DrillUp nos muestra datos mas resumidos. Si queremos volver atr as la operaci on DrillDown anterior sobre la dimensi on Products debemos hacer doble click en la celda Product_Subcategory recientemente expandida.
88
Estas operaciones se pueden aplicar en forma combinada y en los niveles que sean convenientes. Por ejemplo, podr amos hacer DrillDown en la dimensi on Region para analizar las ventas y costos por pa ses, provincias, distritos, o ciudades, hasta alcanzar el nivel de detalle que resulte mas signicativo al an alisis.
89
4.1.4.
Caracter sticas avanzadas en Microsoft Analysis Services
Ahora que hemos visto como crear un conjunto b asico de cubos y dimensiones, veremos algunos conceptos mas avanzados, como: Miembros de dimensiones calculados en base a f ormulas Medidas calculadas Cubos Virtuales y Cubos Enlazados Particiones Miembros calculados Los miembros calculados son miembros cuyos valores se denen a trav es de una formula y en general est an basados en otros miembros de la dimensi on. Un ejemplo de miembro calculado es uno que calcule el presupuesto del a no actual seg un los gastos, tal que el presupuesto sea un 20 por ciento mayor que los gastos actuales. Si contamos con una dimensi on cuyos miembros representan los distintos tipos de presupuestos, entre ellos, el miembro Current Years Actuals representa el monto realmente destinado para el a no corriente, podemos incluir el miembro calculado Current Years Budget, que representa el monto planeado, y cuyo valor es igual al valor del miembro Current Years Actuals multiplicado por 1.2.
Esta dimensi on debe tener la propiedad Writeback activa para poder crear un miembro calculado en ella. Esta propiedad permite que cualquier modicaci on en un miembro vuelva directamente a la tabla de dimensi on de origen. La formula que dene el valor del miembro agregado es la siguiente: [Scenario].[Current Years Actuals]*1.2 Esta formula est a escrita en MDX, o Multidimensional Expressions. MDX es un lenguaje usado para consultar una base de datos OLAP, de la misma forma en que se usa T-SQL para consultar una base de datos SQL Server. Comparte con T-SQL la misma estructura b asica y formato, pero tiene algunas caracter sticas adicionales creadas para manipular este tipo de bases de datos.
90
Medidas calculadas Las medidas calculadas se originan a partir de formulas MDX y no a partir de columnas de la tabla de hechos. El cubo solo almacena las expresiones MDX para estas medidas, y los valores se calculan en el momento de la consulta. Esta caracter stica se asemeja a las Vistas en las bases de datos SQL Server, que se almacenan como simples consultas SQL. Continuando con el ejemplo del cubo CostoyVentas, que contiene medidas para las ventas y para los costos, podemos agregar una medida calculada Profit cuyo valor sea la diferencia entre las medidas anteriores. La formula MDX que dene a esta medida es: [Measures].[Store_Sales]-[Measures].[Store_Cost] Celdas calculadas Las celdas calculadas son similares a las medidas calculadas en que est an determinadas por expresiones MDX que se calculan en el momento de la consulta. La diferencia es que es posible especicar un subconjunto de celdas, o solo una, para las cuales esta expresi on es valida. La forma de determinar el subconjunto de celdas tambi en se expresa mediante MDX, en t erminos de las dimensiones y medidas existentes. DrillThrough Recordemos que la operaci on de DrillThrough sobre un cubo multidimensional implica el acceso a datos que se encuentran en una base de datos relacional. Esta operaci on es u til cuando los usuarios quieren conocer los datos detallados que componen las agregaciones que est an observando. Hay que tener en cuenta que los cubos OLAP construidos sobre un almacenamiento MOLAP pueden operar sin los datos SQL subyacentes una vez que se proces o el cubo, y adem as en muchos DataWarehouses se quitan los datos detallados una vez que los cubos han sido procesados. Por todo esto, para que la operaci on DrillThrough funcione, es necesario asegurarse de que los datos detallados que se usaron para procesar el cubo permanezcan accesibles. Si los detalles est an disponibles es posible habilitar la opci on DrillThrough u Opciones de obtenci on de detalles en el Editor de Cubos, y seleccionar las columnas correspondientes. Luego, para aplicar la operaci on, solo basta con seleccionar una celda en el Cube Browser y elegir DrillThrough en el menu contextual.
91
Cubos Virtuales Los cubos virtuales funcionan de manera similar a las Vistas en una base de datos relacional. Estos cubos se crean uniendo otros para crear un super cubo y as poder disponer de una gran vista de los datos sin consumir espacio en disco. Cuando se crean cubos virtuales, es importante seleccionar las medidas y dimensiones de cubos que compartan el mismo conjunto de dimensiones (cubos enlazados ). Las agregaciones entre distintos cubos est an relacionadas por la dimensi on compartida, y si juntamos datos de cubos que no tengan dimensiones en com un van a continuar separados sin cohesionarse. Por ejemplo, podemos crear un cubo virtual a partir de un cubo que contenga informaci on sobre los empleados y un cubo de ventas, y a partir de este cubo virtual los analistas pueden establecer una relaci on entre la cantidad de empleados en una sucursal y el total de ganancias de la misma para un periodo de tiempo particular, ayud andolos a denir una cantidad promedio optima de empleados por sucursal. Particiones Las particiones representan divisiones l ogicas de un cubo de datos. Estas divisiones se originan seg un los valores de una dimensi on particular. Por ejemplo, podemos particionar un cubo de ventas seg un los valores de la columna de regiones, y tener particiones distintas para datos de la regiones Sur y Norte. Otra alternativa es crear particiones que almacenen los datos de las ventas por un periodo de n a nos. Las particiones se pueden denir seg un cualquier dimensi on que exista en el cubo, pero com unmente se crean de acuerdo a periodos de tiempo, usando la dimensi on de tiempo. La partici on se puede almacenar en un disco distinto del cubo original. Esto permite ubicar los datos que no se consultan frecuentemente en un medio de almacenamiento mas lento,y dejar las particiones que contienen los datos mas requeridos en los medios mas r apidos. Tambi en pueden distribuirse y almacenarse bajo distintos Analysis Servers distribuyendo as la carga de trabajo. Algunos problemas que se deben evitar cuando se usa esta opci on son la aparici on de particiones solapadas y particiones incompletas. Las particiones solapadas llevan a la duplicaci on de datos y a agregaciones incorrectas. Por ejemplo, si dada una base de datos de ventas e inventario dise namos las particiones tal que cada una incluye los datos para un cuatrimestre, pero seguimos manteniendo una partici on para el a no completo. Si ambas tablas usan la misma tabla de hechos sus valores se contabilizar an dos veces. La soluci on a este problema
92
consiste en descartar la partici on para el a no completo, y mezclar las particiones de cuatrimestres cuando se requieran los datos del a no completo. El cubrimiento incompleto de un cubo particionado conduce a la aparici on de celdas vac as donde no deber an estarlo. Las particiones incompletas, como las solapadas, producen agregaciones err oneas.
93
4.1.5.
Acceder a Microsoft Analysis Services desde c odigo
Aunque existe una gran variedad de recursos que permiten f acilmente consultar y presentar datos OLAP usando simples herramientas de usuario, es posible y a veces conveniente construir soluciones desarrolladas a medida que incluyan caracter sticas OLAP simples y tambi en avanzadas. En esta secci on veremos los recursos disponibles para acceder y manipular datos OLAP desde el c odigo de un programa. Entre estos recursos vamos a mencionar a ADO MD, MDX, Oce Web Components y DSO. Oce Web Components Esta librer a se introdujo con Oce 2000 y se mejor o con Oce XP. Est a disponible desde Visual Basic, Access, Excel, Power Point, y Word, y contiene cinco controles ActiveX: Chart: este control muestra los datos resumidos en un gr aco tipo chart. Los datos se pueden obtener desde cualquiera de los controles Spreadsheet, PivotTable, o DataSource, o puede llenarse desde el c odigo. Spreadsheet: este control brinda una funcionalidad simple tipo Excel en una interface liviana para p aginas web. Data Source: provee una conexi on ADO para los controles consumidores de datos como el Chart y el PivotTable. No es necesario si vamos a establecer el origen de datos desde el c odigo. Record Navigation: sirve para soportar el enlace de datos. PivotTable: es un control similar al PivotTable de Excel. Muestra totales por las y columnas, y permite operaciones de pivoting arrastrando campos a los encabezados de las, de columnas o a otras areas. Ahora veremos un ejemplo sobre el uso de controles Chart y PivotTable para mostrar los datos de un cubo con informaci on sobre cursos dictados, y para esto creamos un nuevo proyecto EXE en Visual Basic 6.0, y habilitamos Office XP Web Components en el cuadro de di alogo Componentes del men u Proyecto. Programando el control PivotTable: El PivotTable es una interface de usuario apropiada para un cubo porque permite que el usuario lleve a un plano los datos multidimensionales seleccionando una dimensi on en particular, o tambi en puede usar otras dimensiones como ltro de los datos. El PivotTable obtiene los datos del cubo usando una consulta MDX. Como ejemplo agregamos un PivotTable al formulario de la aplicaci on Visual Basic, e incluimos el siguiente c odigo en el evento load del formulario:
94
Si observamos la expresi on MDX vemos que en la cl ausula FROM indica que los datos se extraen del cubo TrainingSales, y en la cl ausula SELECT se establece la dimensi on Customers para las columnas, y la dimensi on Course para las las, ambas con todos los niveles incluidos.
Podemos usar la lista de campos para agregar campos adicionales al header de ltros, o intercambiar campos en los headers de columnas y las. Las operaciones de DrillDown y DrillUp se aplican expandiendo y colapsando niveles, usando los nodos (+) y (-) correspondientes a cada miembro de dimensi on. Por ejemplo, aqu se muestra el resultado de aplicar un ltro por fecha, en particular el Trimestre 2, y se expandieron algunos nodos para profundizar el nivel de detalle.
95
Programando el control Chart: La programaci on de este control es muy similar a la del PivotTable, porque tienen varias propiedades en com un. Por lo tanto, el ejemplo anterior se aplica al control chart con un c odigo con muy pocas modicaciones:
Como el control puede contener varios charts, hacemos referencia a la colecci on Charts del objeto, en particular a Charts(0), para establecer las propiedades
96
de nuestro chart. La colecci on Axes contiene objetos Axis, y en el c odigo anterior, Axes(1) se reere al eje vertical que muestra las ventas. Aqu vemos el resultado luego de ejecutar el c odigo anterior
ADO MD (ActiveX Data Objects Multidimensional) La librer a ADO MD es la extensi on de ADO para soportar fuentes de datos multidimensionales tales como Microsoft SQL Server Analysis Services. ADO MD provee acceso a trav es de c odigo al PivotTable Service de Analysis Services. Tiene una interface COM y se puede usar desde varias herramientas, como Visual C++, C#, Visual Basic, VBA y Visual Basic Scripting Edition, entre otras. El objeto Cellset El objeto Cellset en ADO MD es el equivalente OLAP del objeto Recordset de ADO, y as como la propiedad Source de un Recordset acepta una expresi on SQL, a un objeto Cellset se le puede asignar una expresi on MDX como origen de datos. Alguna de sus propiedades mas relevantes son: FilterAxis: retorna informaci on sobre las dimensiones que se usan para ltrar datos en el cubo. Cells: cada objeto Cell representa un dato en la intersecci on de coordenadas de los ejes. Axes: cada objeto Axis representa un punto de datos, puede estar asociado con un nivel o miembro especicado en una expresi on MDX.
97
Veamos entonces el c odigo para instanciar un objeto Cellset, e iterar sobre sus celdas para mostrar sus datos en un control FlexGrid no enlazado. Para usarlo debemos agregar una referencia a Microsoft ActiveX Data Objects (Multi-dimensional) en el proyecto Visual Basic.
Aqu vemos el resultado de ejecutar el c odigo anterior
Observemos la denici on del eje de las las: strSource = "SELECT Course.Course.Members ON ROWS, "...
98
Aqu Course.Course.Members se reere al nivel Course de la dimensi on Course. Esto es as porque solo queremos ver los nombres de Cursos en la primer columna. Supongamos ahora que la denici on para las las est a determinada por la siguiente expresi on. strSource = "SELECT Course.Members ON ROWS, "... Como resultado la primer columna contiene todos los niveles de la dimensi on Course, es decir, All Course, Product, Course, y Class Date.
El objeto CubeDef Este objeto expone informaci on de esquema, y se usa para recuperar informaci on sobre las dimensiones a trav es de las colecciones Dimensions, Hierarchies y Levels. El siguiente ejemplo muestra c omo obtener los elementos de un cubo a trav es de este objeto. Primero establecemos una conexi on, y luego iteramos sobre las propiedades del cubo para armar su esquema en un formulario Visual Basic.
99
En conclusi on, ADO MD es un modelo de objetos que permite obtener mediante c odigo, datos y metadatos de una estructura de cubo y sus miembros. DSO (Decision Support Objects) DSO es el modelo de objetos que se usa para manipular objetos OLAP mediante c odigo como una alternativa al Analysis Manager. Con los objetos DSO es posible crear, consultar y modicar todos los objetos expuestos en el Analysis Manager, y m as. Al igual que ADO MD, DSO expone objetos a trav es de COM y se puede programar en cualquier lenguaje o herramienta que admita este tipo de objetos. Veamos una representaci on del modelo de objetos. El modelo comienza con el objeto Server que contiene una colecci on Databases. El objeto Database a su vez contiene objetos Datasources, Cubes y Shared Dimensions.
100
Para usar el modelo DSO desde un proyecto es necesario establecer una referencia a la librer a DSO, Microsoft Decision Support Objects. Como ejemplo vemos el c odigo para crear una base de datos OLAP llamada Ejemplo, usando la base de datos FoodMart2000. Dentro de la base Ejemplo se crea un cubo, una dimensi on Employees con tres niveles, y una medida Salary.
101
Una vez ejecutado este c odigo podemos abrir el Analysis Manager y comprobar que la base de datos Ejemplo existe, junto con los componentes que denimos. Como sabemos, crear la base de datos OLAP no es suciente para llenar la estructura con datos. Para esto es necesario procesar el cubo, pero antes debemos establecer las opciones de agregaci on y de almacenamiento. Estas tareas tambi en se pueden hacer usando DSO, aunque pueden resultar bastante tediosas.
102
En lugar de construir todo el c odigo para crear una base de datos OLAP podemos usar una utilidad llamada Meta Data Scripter incluida en SQL Server 2000 Resource Kit, que toma una base de datos OLAP y genera el c odigo DSO en VBScript para crear todos los objetos correspondientes a dicha base de datos.
103
4.1.6.
Cambios en Microsoft Analysis Services 2005
En esta secci on veremos algunas de las diferencias b asicas entre las versiones 2000 y 2005 de Analysis Services, en cuanto a la interface de usuario, la arquitectura, y el acceso desde c odigo. Cambios en la interface de usuario Analysis Services 2005 incorpora la funcionalidad de las tres principales herramientas de la versi on 2000 en dos nuevas herramientas que vienen incorporadas en el Visual Studio 2005 IDE. Estas nuevas herramientas son BI Workbench y SQL Workbench. BI Workbench se usa para crear y administrar cubos, como el Analysis Manager en la versi on 2000, y tambi en incluye capacidades de dise no de DTS, que en la versi on anterior se inclu an junto con el Enterprise Manager. SQL Workbench fusiona las funciones del Enterprise Manager y del Query Analyzer, y algunas funciones administrativas del Analysis Manager.
Algunas de las diferencias b asicas en la creaci on y manipulaci on de cubos son: Ya no existe una representaci on expl cita de los Analysis Servers, y no est a claro si la interface permite administrar instancias de los mismos. En SQL Workbench s se pueden administrar las instancias de Analysis Servers. Mientras que en Analysis Services 2000 el objeto principal es una base de datos multidimensional, en la versi on 2005 encontramos la soluci on, que es una colecci on de uno o mas proyectos. Estos t erminos se derivan del entorno de Visual Studio, debido a su familiaridad entre los desarrolladores de C# o VB.NET. Cuando se
104
crea un nuevo proyecto, entre los tipos de proyectos para elegir existe un tipo Analysis Services, que es similar a la base de datos en Analysis Manager. Tambi en existen otros tipos de proyectos para representar las funciones DTS. En la versi on 2005 los cubos pueden estar basados en varias tablas de hechos de distinta granularidad. Esta caracter stica se asemeja a los cubos virtuales de la versi on 2000. BI Workbench introduce la tecnolog a IntelliCube que automatiza la creaci on del cubo a trav es de an alisis heur sticos sobre el esquema relacional. En algunos casos se puede construir un cubo con un simple click. Las dimensiones se pueden cargar en forma incremental, y esto es u til en casos en los que no se actualizan las existentes, sino que solo se agregan nuevas.
Cambios en la arquitectura Analysis Services 2000 soporta una sosticada mezcla de c alculo y cach e en ambos lados, servidor y cliente. Para favorecer la integraci on y simplicaci on, Analysis Services 2005 soporta c alculo y cach eu nicamente en el lado del servidor. Recordemos que en Analysis Services 2000 se requiere como fuente de datos de un cubo un esquema estrella relacional o una variante muy cercana, como lo es el esquema snowake. En Analysis Services 2005, sin embargo, es posible mapear cubos a esquemas arbitrarios mediante los llamados Data Source Views. En casos extremos, un cubo se podr a mapear directamente a la base operacional. Un Data Source View es una capa que se ubica por encima del Datasource, impidiendo que todos los objetos del mismo (tablas y vistas en el caso de un datasource operacional) queden directamente expuestas. Esto permite capacidades adicionales, como seleccionar solo un subconjunto de objetos del Data Source, renombrar columnas, agregar columnas virtuales calculadas, agregar consultas con nombre, y usar sentencias SQL que retornan un conjunto de resultados que luego se trata como una tabla. Adem as, los Data Source Views permiten trabajar sobre las estructuras del cubo sin estar conectado al datasource, a diferencia de Analysis Services 2000. Otra caracter stica que se incluye en la nueva versi on es el Unied Dimensional Model (UDM), una funcionalidad que une almacenamientos de datos relacionales y multidimensionales permitiendo la creaci on de un u nico modelo dimensional que se aplica a ambos. Microsoft caracteriza a UDM como la combinaci on de lo mejor de lo relacional y lo multidimensional. Con UDM, los almacenamientos MOLAP se vuelven transparentes, ya que son ubicados en cach e y administrados autom aticamente, y las aplicaciones OLAP entregan datos con menor latencia y muestran atributos detallados. Algunas de las nuevas caracter sticas que surgen a trav es de UDM incluyen:
105
Dimensiones basadas en atributos: en Analysis Services 2000 una dimensi on tiene una u nica jerarqu a, y salvo por las member propertys, los u nicos atributos permitidos son los que indican la jerarqu a o el nivel. En Analysis Services 2005 las dimensiones consisten simplemente de atributos que no necesariamente est an relacionados a la jerarqu a. Por ejemplo, una dimensi on Clientes puede tener varios atributos demogr acos que se organizan en dos jerarqu as, una natural como Pa sRegi on-Provincia-Ciudad, y una anal tica, como Ciudad-Edad-G enero. Grupos de medidas: como mencionamos, varias tablas de hechos de distinta granularidad se pueden combinar en un u nico cubo. Los grupos de medidas agrupan medidas de igual nivel de granularidad y se usan en conjunci on con las Perspectivas. Perspectivas: debido a todas estas caracter sticas reci en nombradas, un cubo puede volverse muy grande y dif cil de navegar. Las perspectivas son conjuntos con nombre de dimensiones y grupos de medidas, que ayudan a manejar el volumen del cubo.
Cambios en la programaci on de Analysis Services Algunas de los cambios que se perlan en la nueva versi on son: MDX: se anuncia una simplicaci on de MDX, que consiste en escribir expresiones como scripts procedurales en lugar de las t picas consultas. La ventaja mas importante es la posibilidad de hacer un debugging paso a paso por la expresi on. Business Intelligence Wizard y Calculated Measure Templates: Estos templates ayudan en problemas comunes, como conversions de monedas por ejemplo. Analysis Management Objects (AMO): AMO reemplaza al modelo de objetos DSO, aunque este permanence vigente por cuestiones de compatibilidad. Server Trace Events: con Analysis Services 2000 es casi imposible obtener informaci on de bajo nivel sobre lo que est a ocurriendo en el Analysis Server. En la versi on 2005 se generan eventos Trace, los cuales pueden ser monitoreados y analizados con el SQL Server Proler, igual que en SQL Server. Traducciones: la nueva versi on incluye una capacidad de traducci on que permite que el mismo cubo se presente en m ultiples lenguajes.
Otros cambios en Analysis Services incluyen la introducci on del Caching Proactivo, y los Servicios de Noticaci on. El Caching Proactivo permite especicar caracter sticas como la pol tica a seguir cuando los datos subyacentes cambian y la cach e se vuelve desactualizada, cu an frecuentemente refrescar la cach e, etc. Las distintas pol ticas de caching dan lugar a una
106
amplia gama de funcionamientos diferentes. Adem as, estos par ametros se pueden establecer para cada objeto en particular, lo que provee una gran exibilidad en casos donde el tradeo entre performance y latencia var a seg un las distintas partes del cubo. Los Servicios de Noticaci on son nuevos en SQL Server. Este servicio provee una infraestructura escalable por la cual los clientes pueden registrarse como interesados en un evento, como el cambio del resultado de una consulta, y denen la forma en la que ser an noticados del evento, por ejemplo, por email o mensajer a instant anea. En SQL Server 2005, los servicios de noticaci on incluyen un adaptador especial para Analysis Services, y us andolo, un cliente se puede suscribir a un evento especicando una consulta MDX que dene el dato de inter es, la frecuencia de interrogaci on, el esquema de noticaci on, etc. Como ejemplo de la utilidad de estos servicios, supongamos que un gerente de sucursal requiera una noticaci on cuando las ventas por hora de un producto particular decrece por debajo de un cierto nivel especicado. Esto es solo un pantallazo de los cambios introducidos en la versi on 2005 de Analysis Services, sobre los aspectos que tocamos en las secciones anteriores con la versi on 2000.
Cap tulo 5 Conclusi on

OLAP juega un rol importante dentro de las organizaciones, ya que ayuda a establecer, monitorear y comunicar las medidas de performance que permiten a los gerentes entender como se va desarrollando el negocio en el complejo entorno competitivo. Adem as permite establecer nuevas medidas de performance. Tradicionalmente, las nanzas prove an las u nicas medidas de performance corporativa, las cuales contin uan siendo criticas para cualquier negocio. No obstante, surge una tendencia hacia otros factores, tales como medidas de calidad (en sistemas de producci on), proyectos de inversi on de capitales, eciencia operacional y del negocio, y medidas sobre el cliente y sobre los recursos humanos. Las medidas nancieras solo proveen una perspectiva particular, y la mayor a de las organizaciones est an comenzando a ver la necesidad de un rango mas amplio de indicadores para entender su performance en un mercado altamente competitivo que se mueve muy r apido. Las herramientas OLAP dan pie o facilitan el desarrollo de un conjunto com un de valores para medir la performance de la compa n a, mediante un m etodo llamado Balanced Scorecard o Tablero de Comandos. El m etodo del Balanced Scorecard agrega tres perspectivas adem as de la nanciera, la perspectiva de los clientes, los procesos internos, y el crecimiento y aprendizaje. Los visionarios de este enfoque han sugerido que se puede extender para monitorear sistemas de gerenciamiento estrat egico, enlazando metas estrat egicas con los resultados de acciones a corto plazo, como mejora de calidad o nuevas iniciativas de entrenamiento. Se hace hincapi e sobre el rol de los sistemas de informaci on como una ayuda para los gerentes en la investigaci on de medidas y causas subyacentes a cualquier se nal inesperada. El rol de OLAP va mas all a del monitoreo de medidas de performance. La denici on de tales medidas deber a ser un proceso de articulaci on de valores y metas. En muchos casos, este proceso es tan importante como los resultados. Las herramientas OLAP pueden proveer un entorno colaborativo en el cual se denan metas. OLAP y otras herramientas nancieras
107
CAP ITULO 5. CONCLUSION
108
Existe una clara superposici on en el area de reporte nanciero, planeamiento y an alisis entre OLAP y planillas de c alculo y paquetes contables corporativos. La mayor a de las herramientas OLAP proveen links a Excel u otras planillas, las cuales permiten un acceso a datos robusto, soporte multiusuario y la arquitectura servidor de OLAP para usar en conjunci on con estas herramientas front-end familiares. Muchos usuarios quieren tener links directos entre sus aplicaciones transaccionales y las poderosas facilidades de OLAP. Esta oportunidad de mercado esta siendo aprovechada por los vendedores de OLAP que producen aplicaciones especializadas y por los vendedores de paquetes nancieros que incorporan funcionalidad OLAP en sus productos. OLAP en relaci on al cliente En lo que respecta al cliente, las organizaciones entienden que deben hacer un seguimiento sobre los tipos y necesidades de los mismos, monitorear su satisfacci on, y conocer cuales son los clientes mas importantes, ya que el 20-25 % de ellos son los que generan el 80 % de las ganancias. Las grandes organizaciones, como compa n as de telecomunicaciones, aerol neas, servicios nancieros, supermercados, y hasta productoras de cine, etc, implementan soluciones OLAP, lo que les permite hacer pron osticos de ventas, an alisis de promociones, segmentaci on de mercado y clientes, y an alisis de mercado compartido. OLAP y el proceso de fabricaci on El departamento de compras puede negociar mejores descuentos si tiene mejor acceso a la informaci on sobre la performance del proveedor, los costos del material y los gastos. Conocer mejor los factores que inuyen sobre los vol umenes y movimientos de stock permite administrar mejor el mismo. El equipo de control de calidad puede testear hip otesis y explorar relaciones para entender las causas. Los gerentes pueden ver como interact uan factores como materias primas, stock, log stica, distribuci on, pagos. Porqu e es tan importante la multidimensionalidad? Permite ver las medidas del negocio desde varias perspectivas. Es una forma intuitiva de trabajar con datos agregados o totalizados. Es mas f acil identicar patrones y tendencias. El usuario se convierte en un explorador de la informaci on, en lugar de un observador pasivo de largos listados. No solo abstrae al usuario de usar SQL o ser consciente de cosas como los nombres de las tablas y columnas de la base de datos, sino que le permite ejecutar consultas complejas que involucran muchas facetas de su negocio sin necesidad de asistencia por parte del personal de sistemas.
109
OLAP y su relaci on con herramientas de Reporting y Datamining Existe una relaci on superpuesta entre las herramientas de Reporting, OLAP y Datamining. Las herramientas de reporting apuntan a un p ublico general, y los resultados se extienden a toda la organizaci on. Las herramientas OLAP se especializan en la exploraci on interactiva de informaci on multidimensional, y se usan en todos los niveles de la organizaci on. La divisi on entre los dos tipos de herramientas no es totalmente clara, porque algunas herramientas de Reporting tienen facilidades limitadas que permiten a los usuarios explorar datos, y las herramientas OLAP, a su vez, se benecian de algunas de las caracter sticas de las de Reporting. Las herramientas de Datamining est an orientadas a la b usqueda de patrones y a la exploraci on de los datos usando hip otesis sobre los mismos. Algunas herramientas OLAP ofrecen caracter sticas limitadas de Datamining, aunque la tendencia actual es la integraci on con estas herramientas como una expansi on de la funcionalidad de las herramientas OLAP. OLAP y Bussiness Intelligence La tendencia actual dirige a las aplicaciones OLAP a formar parte de algo mas grande y abarcativo, que se conoce como plataforma Bussiness Intelligence. Bussiness Intelligence (BI) no es ni un producto ni un sistema. Es una arquitectura y una colecci on de aplicaciones, tanto operacionales como de toma de decisiones, y de bases de datos, que juntas proveen a la gente de negocios un f acil acceso a los datos de inter es. Las aplicaciones BI no solo facilitan las actividades relacionadas al an alisis multidimensional, sino tambi en actividades como el Datamining, forecasting(pron osticos), y preparaci on de Balanced Scorecards, entre otras. Hist oricamente, una soluci on Business Intelligence consist a en un conjunto de herramientas individuales, donde cada una soportaba una funci on diferente. Hoy la realidad es que las soluciones BI a nivel empresarial no solo brindan herramientas que investigan los datos, sino tambi en herramientas de desarrollo y administraci on para crear, desarrollar y mantener aplicaciones de tipo BI. Hoy una nueva generaci on de herramientas provee este tipo de soporte end-to-end y a medida que estas herramientas maduran en las plataformas BI, la complejidad de las soluciones que se pueden construir aumenta. Una plataforma BI se caracteriza por soportar un n umero creciente de usuarios y un diverso rango de necesidades, proveer acceso web, brindar un m etodo optimo de integraci on y administraci on de fuentes de datos corporativas de gran volumen, funcionalidad BI embebida en el proceso de negocios, administraci on end-to-end de la plataforma, entrega de informaci on dirigida y planicada, y proveer una plataforma para construir y desarrollar aplicaciones anal ticas. El contenido de esta tesis est a dirigido a quienes se encuentran por primera vez frente a esta tecnolog a.
110
La idea es brindar las premisas b asicas para saber cu ales datos tomar de los sistemas operacionales, conocer las transformaciones m as comunes que se aplican a estos datos, y para dise nar la estructura de las tablas del DataWarehouse que va a recibir los datos operacionales. Como ejemplo pr actico para claricar estas ideas, se migraron datos desde una base OLTP a un DataWarehouse dise nado con un esquema Snowake usando los Servicios de Transformaci on de SQL Server (DTS). La creaci on de un cubo con la herramienta SQL Server Analysis Services intent o jar los conceptos de Cubos, Dimensiones y Niveles, vistos en la introducci on. El an alisis y manipulaci on del mismo fue una forma de hacer lo mismo con las operaciones aplicables a los cubos. Los ejemplos usados con este n son bastante b asicos, pero u tiles para comenzar a conocer OLAP y sus benecios. Las u ltimas secciones nos brindan algunas puntas para comenzar a experimentar con caracter sticas mas avanzadas, como cubos virtuales, o la construcci on de una herramienta OLAP propia que acceda a Analysis Services por c odigo. Es importante no quedarse afuera de esta tecnolog a, y no solo por los benecios que brinda. El hecho de que OLAP est e acaparando el mercado implica que nuestros competidores ir an avanzando en la medida que la herramienta se los permita, y nuestra organizaci on se ir a posicionando en un lugar bastante poco privilegiado con respecto a la competencia. Poni endonos a la par, contamos con la misma informaci on que los competidores, y aun mas, a medida que adquiramos conocimiento mas profundo sobre la herramienta OLAP que usemos y la aprovechemos al m aximo.
Bibliograf a
[Atr03] Larissa T. Moss; Shaku Atre. Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications. Addison Wesley, 2003. [Bal02] Seth Paul; Nitin Guatam; Raymond Balint. Preparing and Mining Data with Microsoft SQL Server 2000 and Analysis Services. MSPress, 2002. [Fra05] Mark Frawley. Analysis Services Comparison: SQL 2000 vs. SQL 2005. www.devx.com, 2005. Los principales cambios a las caracter sticas BI en SQL Server 2005 prometen cambiar la manera en la que desarrollamos aplicaciones de este tipo. La comparaci on realizada en este art culo est a dirigida a descubrir estos cambios. El link del art culo es http://www.devx.com/dbzone/Article/21539. [Raf03] Maurizio Rafanelli. Multidimensional Databases: Problems and Solutions. Idea Group Publishing, 2003. [Ros] Ralph Kimball; Margy Ross. The DataWarehouse Toolkit. Second Edition. The Complete Guide to Dimensional Modeling. Wiley Computer Publishing.
[San05] Paul Sanders. Paper: SQL Server 2005. Real-time Business Intelligence Using Analysis Services. Microsoft TechNet, 2005. [Tho02] Erik Thomsen. OLAP Solutions. Building Multidimensional Information Systems. Wiley Computer Publishing, 2002. [Tie05] Gail Tieh. An Introduction to OLAP in SQL Server 2005. www.devx.com, 2005. Este art culo brinda un pantallazo acerca de las nuevas caracter sticas de Business Intelligence que se incluyen en SQL Server 2005, y sobre los principales componentes OLAP de Analysis Services. El link correspondiente es http://www.devx.com/dbzone/Article/21410.
[Woo00] Mary Hope; Madan Sheina; David Wells; Eric Woods. Ovum Evaluates: OLAP. Ovum Ltd., 2000. [You01] Tony Bain; Mike Benkovich; Robin Dewson; Sam Ferguson; Christopher Graves; Terrence J. Joubert; Denny Lee; Mark Scott; Robert Skoglund; Paul 111
BIBLIOGRAF IA
112
Turley; Sakhr Youness. Professional SQL Server 2000 DataWarehousing with Analysis Services. Wrox Press Ltd., 2001.

Introduccion Al Soporte de Decisione

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Introduccion Al Soporte de Decisione

Transféré par

Droits d'auteur :

Formats disponibles

Indice general

estrella . . . . . 63 . . . . . 71 . . . . . 85 . . . . . 89 . . . . . 93 . . . . . 103 107 111

Cap tulo 1 Introducci on

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Diferencia entre el procesamiento OLAP y OLTP

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Cubos: Dimensiones, Medidas y Operaciones aplicables

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

ROLAP, MOLAP Y HOLAP

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Cual es la mejor opci on?

CAP ITULO 1. INTRODUCCION

Ya existen skills para el uso de DBMS.

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Veamos otra manera de visualizar los datos del cubo anterior.

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

CAP ITULO 1. INTRODUCCION

Cap tulo 2 Consideraciones previas a la implementaci on

Requerimientos f sicos y l ogicos

CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION

CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION

CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION

CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION

Evaluar el entorno actual de la empresa

CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION

CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION

CAP ITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION

Cap tulo 3 Dise nar la fuente de datos y migrarlos

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

Diferencias entre un DataWarehouse y una base de datos operacional

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

Dise nar el DataWarehouse

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

Migrar los datos: ETL (Extract, Transform, Load)

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS

Extraer los datos

Transformar los datos

CAP ITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS