Introduccion Al Soporte de Decisione PDF

Indice general
Resumen 1
1. Introduccion 3
1.1. Que es OLAP? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Diferencia entre el procesamiento OLAP y OLTP . . . . . . . . . . . . . 5
1.3. Cubos: Dimensiones, Medidas y Operaciones aplicables . . . . . . . . . . 7
1.4. ROLAP, MOLAP Y HOLAP . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.1. MOLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4.2. ROLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4.3. HOLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4.4. Cual es la mejor opcion? . . . . . . . . . . . . . . . . . . . . . . . 14
1.5. Pensar en N dimensiones . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2. Consideraciones previas a la implementacion 26

2.1. Requerimientos fsicos y logicos . . . . . . . . . . . . . . . . . . . . . . . 26
2.2. Analisis costo-beneficio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3. Evaluar el entorno actual de la empresa . . . . . . . . . . . . . . . . . . . 30
3. Disenar la fuente de datos y migrarlos 34

3.1. Que es un DataWarehouse (DW)? . . . . . . . . . . . . . . . . . . . . . . 35
3.2. Diferencias entre un DataWarehouse y una base de datos operacional . . 38
3.3. Disenar el DataWarehouse . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.1. Diseno logico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.3.2. Diseno fsico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4. Migrar los datos: ETL (Extract, Transform, Load) . . . . . . . . . . . . . 47
3.4.1. Extraer los datos . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.2. Transformar los datos . . . . . . . . . . . . . . . . . . . . . . . 49
3.4.3. Cargar los datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.4. Evaluar herramientas ETL externas . . . . . . . . . . . . . . . . . 54
4. Implementar una Herramienta OLAP 56

4.1. Microsoft SQL Server Analysis Services . . . . . . . . . . . . . . . . . . . 59
i
ii
4.1.1. Migrar los datos de una base OLTP hacia un esquema estrella
usando paquetes DTS . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.2. Crear un Cubo y sus dimensiones . . . . . . . . . . . . . . . . . . 71
4.1.3. Analizar y manipular el Cubo . . . . . . . . . . . . . . . . . . . . 85
4.1.4. Caractersticas avanzadas en Microsoft Analysis Services . . . . . 89
4.1.5. Acceder a Microsoft Analysis Services desde codigo . . . . . . . . 93
4.1.6. Cambios en Microsoft Analysis Services 2005 . . . . . . . . . . . . 103
5. Conclusion 107
Bibliografa 111
Resumen
El punto de partida de todas las actividades de negocios es el procesamiento de infor-

macion. Esto incluye recolectar, almacenar, transportar, manipular y recuperar
datos con o sin ayuda de las computadoras.
La importancia de contar con buena informacion constituye la diferencia entre tomar
decisiones correctas e incorrectas, porque las decisiones en general estaran basadas en esta
informacion. Por ejemplo, si una empresa dedicada a la reventa de productos tiene poca
informacion 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 que o como se procese la informacion, los atributos que se
buscan son siempre los mismos: la informacion debe ser tangible, precisa, compren-
sible y oportuna.
Se puede decir que en un principio solo las grandes corporaciones tenan acceso al
procesamiento analtico de la informacion, lo que les permitio manipular habilmente el
gran volumen de datos con el que contaban, y as crecer aun mas, dominando todo el
mercado.
La tendencia actual sin embargo, es que este tipo de herramientas esten al alcance
de todas las organizaciones, desde estas grandes multiempresas hasta las empresas mas
pequenas.
Los sistemas de soporte de decisiones tradicionales se enfocaban en procesos opera-

cionales relacionados al producto de la organizacion. Sus capacidades eran limitadas, y
los esfuerzos de marketing se dirigan al producto en vez de dirigirse al cliente.
Los llamados archivos de informacion del cliente (Marketing Customer Informa-
tion 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 informacion sobre la forma de vida
de los clientes. Se mantenan clasificados por categoras para que los gerentes de negocios
1
2
analizaran interrelaciones entre ellos y sus necesidades. Luego surgio el DataWarehou-

sing, que fue un paso mas grande en el intento de integrar y cruzar la informacion de
la organizacion destinada el soporte de decisiones. Este paso origino tareas y conceptos
tales como reportes de ventas, indicadores clave, analisis de tendencias.
Luego del surgimiento del DataWarehousing comenzaron a surgir nuevas herramien-
tas 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 significa una herramienta OLAP, y

como el procesamiento OLAP difiere del procesamiento OLTP (Online Transactional
Processing), usado en la operatoria diaria.
Luego se veran los pasos fundamentales y las cuestiones a tener en cuenta al momento
de configurar el entorno para implementar estas herramientas. El entorno del que se
habla se refiere a una empresa con distintas aplicaciones operacionales, cada una tomando
y guardando datos en distintos tipos de bases de datos y archivos.
Se trataran los principales puntos concernientes al armado de un DataWarehouse
o repositorio de datos, que sera la fuente de datos de la herramienta OLAP que se elija
usar e implementar. Entre estos puntos, se analiza como hacer una evaluacion del entorno
actual de la empresa (la plataforma de HW, los DBMS que se estan usando, los datos
existentes en toda la organizacion, las aplicaciones que se estan utilizando), y la carga
completa de los datos.
Una vez que contamos con la fuente de los datos, se analizan las caractersticas con
las que cuenta una herramienta OLAP.
Para conocerlas mas profundamente tomamos como ejemplo la herramienta OLAP de
Microsoft, Analysis Services, recorriendo cada aspecto relevante de la misma mediante
ejemplos, para obtener as una vision global y precisa del uso y del potencial que ofrecen
estas herramientas.
Captulo 1
Introduccion
1.1. Que es OLAP?

OLAP se define como el analisis multidimensional e interactivo de la informacion
de negocios a escala empresarial. El analisis multidimensional consiste en combinar dis-
tintas areas de la organizacion, y as ubicar ciertos tipos de informacion que revelen el
comportamiento del negocio.
Porque se dice que el analisis 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 ultimos tres meses, y ademas
con la posibilidad de elegir entre diferentes niveles de detalle, como ventas por da, por
semana o por cuatrimestre. Es esta exploracion interactiva lo que distingue a OLAP de
las herramientas simples de consulta y reportes.
Porque es util la multidimensionalidad?

Es lo que permite a los analistas de negocios examinar sus indicadores clave o me-
didas, 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 informacion.
Porque a escala empresarial?

OLAP es robusto y escalable al punto de permitir satisfacer las necesidades de analisis
de informacion de la organizacion completa. Se trabaja con fuentes de datos corporativas,
que contienen datos de toda la empresa, y se comparte y cruza la informacion existente
en todas las areas de la misma.
Para proveer estas caractersticas, toda herramienta OLAP tiene tres principales
componentes:
3
CAPITULO 1. INTRODUCCION 4
Un modelo multidimensional de la informacion para el analisis 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 intuiti-

vamente con ellos, sin necesidad de conocer cuestiones tecnicas tales como el formato
fsico 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 flexibilidad en cuanto a la navegacion por el modelo
multidimensional de la informacion, sino que tambien es flexible en la definicion de los
reportes y aplicaciones que se construyen a partir de ella.
1.2. Diferencia entre el procesamiento OLAP y OLTP

La compra, venta, produccion, y distribucion son ejemplos comunes de actividades de
negocios de la operacion diaria. Estas actividades constituyen el llamado procesamien-
to operacional u OLTP (Online Transactional Processing), y las aplicaciones que
soportan este procesamiento se disenan con orientacion a la carga de datos.
El planeamiento de recursos, planeamiento financiero, alianzas estrategicas, e inicia-
tivas de mercado son ejemplos de actividades que generan y usan informacion basada
en analisis y orientada a la toma de decisiones. Este tipo de actividades son soportadas
por las aplicaciones de tipo OLAP.
Podemos decir que las caractersticas 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 aplicacion OLAP, en cambio, no tiene que soportar este nivel de concurrencia,
porque en general sera 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 res-

puesta de las operaciones en una aplicacion 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 aplicacion de facturacion recibe operaciones todo el tiempo. Una
aplicacion OLAP recibe solicitudes de informacion en tiempos poco predecibles.
Se pueden requerir algunos informes en forma mensual, o semanal, o en cualquier
momento.
En una aplicacion 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 actuan 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 organizacion. En
aplicaciones orientadas a la toma de decisiones en cambio, las consultas requieren el
examen y recuperacion de una enorme cantidad de datos, incluso datos historicos.
Los usuarios de una aplicacion OLAP generan consultas complejas y ad hoc, y a
veces la respuesta a una consulta conduce a la formulacion de otras mas detalladas.
En general los usuarios comienzan buscando en los datos resumidos y al identificar
areas de interes, comienzan a acceder al conjunto de datos detallado. Los conjuntos

de datos resumidos representan el Que de una situacion y los conjuntos de datos
detallados permiten a los usuarios construir un cuadro sobre Como se ha derivado
esa situacion.
Los sistemas operacionales se desarrollan para automatizar circuitos y procesos de

negocios y no para la toma de decisiones, por lo tanto, no estan disenados para
integrarse o conciliar datos con otros sistemas a fin de ofrecer una vista total de
los datos de la organizacion.
Todas estas diferencias se reflejan en las caractersticas de las bases de datos subya-
centes a ambos tipos de aplicaciones.
1.3. Cubos: Dimensiones, Medidas y Operaciones apli-

cables
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 informacion se
representa por medio de matrices multidimensionales o cuadros de multiples 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 organizacion, facilita y agiliza la consulta
de informacion historica ofreciendo la posibilidad de navegar y analizar los datos.
Aqu vemos como ejemplo un cubo multidimensional que contiene informacion de
ventas discriminadas por periodos de tiempo, productos y zonas geograficas de las su-
cursales.
Los ejes del cubo son las Dimensiones, y los valores que se presentan en la matriz,
son las Medidas.
Una instancia del modelo esta 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 compor-
tamiento del mismo. Las definiciones de las dimensiones se basan en polticas de la
compana o del mercado, e indican la manera en que la organizacion interpreta o clasi-
fica su informacion para segmentar el analisis en sectores, facilitando la observacion de
los datos.
Para determinar las dimensiones requeridas para analizar los datos podemos pregun-
tarnos:
Cuando? La respuesta a esta pregunta permite establecer la dimension del tiempo

y visualizar de manera comparativa el desempeno del negocio.
Donde? Esta pregunta nos ubica en un area fsica o imaginaria donde se estan
llevando a cabo los movimientos que se desean analizar. Estos lugares se pueden
ser zonas geograficas, divisiones internas de la organizacion, sucursales, etc.
Que? Es el objeto del negocio, o el objeto de interes para determinada area de la

compana. Para estos casos se tienen los productos y/o servicios, la materia prima
como elemento de interes para la division de abastecimientos, los vehculos para la
seccion de transportes, las maquinarias para el area de produccion, etc.
Quien? En esta dimension se plantea una estructura de los elementos que inciden
directamente sobre el objeto de interes. En estos casos se hace referencia al area
comercial o de ventas, o a los empleados de la organizacion si se esta llevando a
cabo un analisis a nivel del talento humano, etc.
Cual? Habla de hacia donde se enfoca el esfuerzo de la organizacion o una deter-

minada area del negocio, para hacer llegar los productos o servicios. Una dimension
que surge de esta pregunta es la de clientes.
Medidas o Metricas
Son caractersticas cualitativas o cuantitativas de los objetos que se desean analizar
en las empresas. Las medidas cuantitativas estan dadas por valores o cifras porcentuales.
Por ejemplo, las ventas en dolares, cantidad de unidades en stock, cantidad de unidades
de producto vendidas, horas trabajadas, el promedio de piezas producidas, el porcentaje
de aceptacion de un producto, el consumo de combustible de un vehculo, etc.
Jerarquas de Dimensiones y Niveles

Generalmente las dimensiones se estructuran en jerarquas, y en cada jerarqua exis-
ten uno o mas niveles, los llamados Niveles de Agregacion o simplemente Niveles. Toda
dimension tiene por lo menos una jerarqua con un unico nivel. En la figura vemos un
ejemplo de una dimension de vendedores, que consiste de una unica jerarqua, y tres
niveles de agregacion para agruparlos por ciudades y por regiones.
Aqu podemos ver una dimension que cuenta con dos jerarquas:
En este caso, los niveles Zonas y Gerencia no estan relacionados entre s, a pesar de
que ambos estan relacionados con las Areas.
Si existe mas de una jerarqua, la relacion que une datos de un nivel con datos de
otro nivel superior debe ser confluente. Esto significa 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 jerarqua recorrida.
Si no se cumpliera la confluencia, entonces el primer trimestre que figura relacionado

con 1998, podra aparecer relacionado, por ejemplo, con 1999. En este caso, al recorrer
la jerarqua por trimestre, el mes de marzo de 1998 aparecera en 1999.
Operaciones Multidimensionales
Las operaciones multidimensionales se pueden agrupar en tres conjuntos basicos que
se describen a continuacion:
Operaciones de Slice & Dice (Seleccion)

No existe un consenso general en la definicion 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

dimension de un cubo mayor, definiendo un subcubo.
Dice: Tomar secciones del cubo en funcion 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 especficos de una dimension,
o seleccionar tems de acuerdo a un rango (por ejemplo, los 5 productos mas
vendidos), y combinar estos criterios de seleccion para construir consultas mas
complejas.
Rotacion (pivoting): Permite visualizar diferentes planos de un cubo. En
general el usuario indica la rotacion arrastrando una dimension a una nueva
posicion, y la herramienta rota la perspectiva automaticamente.
Aqu vemos un esquema de la operacion de Rotacion. 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 dimension Tiempo
con Zonas Geograficas, vemos las ventas para la Zona Local. Por ultimo se
intercambian las dimensiones Productos y Zonas Geograficas, exponiendo as
las ventas discriminadas por Zonas y por trimestres para un producto en
particular.
Operaciones de Agregacion
El grupo de las operaciones de Agregacion esta constituido por operaciones que
realizan desplazamientos por las jerarquas y niveles de las dimensiones.
DrillUp: Implica subir un nivel en la jerarqua. Como resultado se agrupan

todos los valores de los miembros en el nivel original que estan relacionados
con el mismo valor del nivel superior.
DrillDown: Implica bajar un nivel en la jerarqua. Se produce la desagregacion
de dichos valores.
Por ejemplo, si estamos observando ventas anuales por sucursales podemos
aplicar una operacion de DrillDown para ver dichas ventas discriminadas por
trimestre, o aplicar una operacion 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 (Consolidacion): Cuando se realiza un DrillUp, se deben calcular
nuevos valores en funcion del conjunto de valores de las medidas que se agru-
pan. La aplicacion de esta operacion se traduce, tpicamente, en funciones de
agregacion como las presentes en SQL (SUM, AVG, MAX, MIN, etc.).
Relacionamiento
A partir de un cubo, mediante las operaciones de Relacionamiento, se puede acceder
otros datos.
DrillAcross: Se accede a datos que estan en otros cubos existentes.

DrillThrough: Se accede a datos que estan 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
dimension de los productos, y DrillDown sobre la dimension de sucursales.
1.4. ROLAP, MOLAP Y HOLAP

La estructura que almacena los datos de una aplicacion de tipo OLAP tiene que
proveer consultas eficientes, escalabilidad y acceso multiusuario.
Las bases de datos relacionales estan 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 unica consulta SQL, y seguramente se requeriran
muchas operaciones de JOIN, lo cual reduce drasticamente el tiempo de respuesta de la
consulta.
Para cubrir estas deficiencias surgieron tres estrategias de almacenamiento:
Bases de datos multidimensionales especializadas (MDDBs), que proveen alma-

cenamiento y recupero de datos optimizado para consultas OLAP.
DataWarehouses, construidos sobre una tecnologa relacional, pero la optimizacion

se dirige al soporte de decisiones en lugar de a las operaciones transaccionales.
Una tercer estrategia que consiste en la combinacion 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 Hbrido u HOLAP.
1.4.1. MOLAP
Las bases de datos multidimensionales usan estructuras de tipo arreglo para alma-
cenar los datos. Estas estructuras estan indexadas con el fin 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 unico gran cubo en el cual cada medida
esta referenciada y totalizada en todas las dimensiones del mismo.
En la arquitectura de multicubos los datos se guardan en mas de un cubo. Por
ejemplo, una base de datos puede contener un cubo que almacena las ventas mensuales,
por region y por producto, y otro que guarda la informacion correspondiente a costos
departamentales y mensuales.
La primer organizacion 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 mas 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 ademas
necesita un buen manejo de la dispersion de los datos para evitar que el tamano del cubo
se vuelva inmanejable.
(ver)Una de las caractersticas distintivas de MOLAP es la preconsolidacion de los
datos. En una base de datos relacional para responder a una consulta del tipo Cuanta
cantidad del producto X se vendio en el ultimo cuatrimestre? normalmente se tiene que
hacer una busqueda de todos los registros relevantes y totalizar los datos. En una base
multidimensional en cambio, estos totales se calculan rapidamente usando operaciones
extremadamente eficientes sobre arreglos. Una vez calculados, los totales se pueden al-
macenar en las estructuras de la base misma. Las MDDBs pueden preconsolidar todos
los datos, es decir, hacer los calculos necesarios para obtener la sumarizacion y totali-
zacion 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 mayora de las MDDBs tambien proveen acceso SQL a datos en una base de datos
relacional adjunta para recuperar filas de informacion detallada, por ejemplo, todas las
filas que conformen un determinado total. Esta informacion detallada solamente se puede
visualizar, pero no se puede usar para analisis.
Otra caracterstica de importancia tiene que ver con los datos dispersos. Una MDDB
tiene que contar con un manejo de datos dispersos. La dispersion 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 da en cada una, pero no todos
los productos necesariamente se van a vender todos los das 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 das como dimensiones, el cubo contendra celdas
vacas. Estas celdas corresponden a los productos que no se vendieron en determinados
da y sucursal.
Cada herramienta MOLAP tiene su propio mecanismo para evitar guardar valores
nulos o ceros a partir de esta situacion. 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 estan optimizadas para el analisis mul-
tidimensional, tienen ventajas sobre las MDDBs en otros aspectos. En particular, son
escalables a conjuntos mas grandes de datos e incluyen soporte para replicacion, roll-
back y recuperacion. Ademas, en la mayora de las organizaciones es mas probable que
la gente de sistemas este mas 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 analisis multidimensional sobre datos almacenados
en una base de datos relacional. Lo hacen a traves 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 calculos (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 disenador del DataWarehouse.
1.4.3. HOLAP
Existen dos enfoques para definir a las herramientas HOLAP.
Por un lado, se habla de un MDDB que puede recuperar y analizar informacion
detallada. Esta es la definicion 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 unico 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 preconsolidacion 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 implementacion tecnica. Algunos vendedores
incluyen la opcion 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 opcion?
Cada alternativa tiene sus ventajas y desventajas. En lugar de discutir cual de las
dos es mejor hay que definir 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.
Lo mas importante es entender los requerimientos del propio negocio y las implican-
cias para el tipo y tamano 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 analisis multidimensional.
La escalabilidad esta limitada por la capacidad de la MDDB y por el tiempo de

carga de los datos.
En general el analisis esta limitado a los datos totalizados o sumarizados.
El modelo multidimensional no es lo suficientemente flexible como para acomodarse

a las necesidades constantemente cambiantes del negocio.
La estructura que guarda los datos esta incluida en la herramienta.
Requiere una capa adicional de manejo de datos.
No incluye soporte de paralelismo, replicacion ni recuperacion de datos.
Puede requerir aprendizaje por ser una tecnologa nueva en la organizacion.
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.
Ademas del analisis de informacion 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 tecnicas del manejo de los datos esta a cargo del RDBMS.
Incluye soporte para replicacion, rollback y recuperacion, y para acceso multiusuario.
Ya existen skills para el uso de DBMS.

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 analisis, reporte y presentacion de
los datos se hace a traves 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 filas y
columnas.
Un ejemplo comun para representar en dos dimensiones podran ser datos de ventas,
costos y ganancias de una empresa, discriminados por mes.
Antes que nada observemos la organizacion de los datos crudos. La base de datos con-
tiene 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
operacion, y los productos, entre otros.
Luego, agregando y totalizando los importes obtenemos la organizacion de los datos

en dos dimensiones.
La grilla tiene una fila para cada mes, y una adicional para los totales generales, y
tres columnas para las variables de Ventas, Costos y Margenes. 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, deberamos 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
presentacion. Es decir, no estamos observando meses, estamos observando ventas, costos
y ganancias organizados en meses.
Si ahora agregamos una dimension mas, la dimension Productos, obtenemos un cubo

de tres dimensiones.
Este cubo no es facil de visualizar en una pantalla de computadora o en un papel,

donde se dispone de dos dimensiones fsicas solamente, lo que se expone en su lugar
es una representacion bidimensional de un cubo de tres dimensiones. Es decir, las dos
dimensiones de la pantalla o el papel en el que muestran los datos estan separadas de la
metafora que se usa para visualizarlos.
Hasta aqu todo funciona, pero que ocurre cuando se agregan mas dimensiones?
Como mostrar la informacion de la manera mas optima para que se pueda analizar y
manipular?
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 pagina para la tercera dimension Productos. Las tres dimensiones
de la informacion, que son Variables, Tiempo y Productos, se mapean en las tres dimen-
siones de la metafora usada para representar los datos, que son las Columnas, Filas y
Paginas respectivamente. Las filas y columnas se corresponden con las dos dimensiones
fsicas de la pantalla, pero las paginas no se corresponden con ninguna. Esto implica que
no se pueden ver todas las paginas 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
operacion de Pivot.
La metafora que implica esta seleccion de paginas es mostrar una rodaja (slice) del
cubo.
Volvamos al problema de la representacion grafica al agregar una dimension mas.

Una representacion util requiere que las dimensiones sean coexistentes e independien-
tes. 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 demas. 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 esta
identificado con un valor en cada dimension. La independencia entre dimensiones se
manifiesta cuando nos desplazamos desde las ventas de televisores en Febrero a las de
Marzo, y despues a las ventas de DVDs en Junio.
El problema con la representacion de informacion en mas de tres dimensiones consiste
en encontrar la manera de mapear las dimensiones logicas en las dimensiones fsicas de la
pantalla o del papel. La solucion es que varias dimensiones logicas compartan la misma
dimension fsica.
En esta figura vemos como seis dimensiones se conectan en forma combinada a las
filas, columnas y paginas de la grilla de tres dimensiones. La misma representacion
que funcionaba para tres dimensiones se puede adaptar facilmente 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 filas se combinan las variables y la di-
mension del tiempo, y las paginas se componen de la combinacion de las dimensiones
Sucursal, y Tipo de Cliente.
En las siguientes figuras vemos otras dos formas de mapear las seis dimensiones en
este ejemplo a filas, columnas y paginas.
Las distintas posibilidades en la combinacion de las dimensiones dan lugar a cambios

en el formato y longitudes de la grilla, y tambien en las cercanas de los datos.
La longitud de las dimensiones esta directamente relacionada con la facilidad de
navegacion en la grilla. No es lo mismo observar una grilla de 50 filas que observar una
de 10000, donde tendremos que desplazar la pantalla, perdiendo el foco de analisis o el
punto especfico que estabamos observando. Por estas razones, en el momento de elegir
cuales dimensiones combinar, hay que tener en cuenta las longitudes resultantes. La
longitud de la combinacion sera igual al producto de las longitudes de las dimensiones
que se estan combinando, y esto no es despreciable si se esta hablando de miles o hasta
millones de filas o columnas.
Los cambios en la cercana o en los vecinos de un cierto dato pueden afectar el analisis
grafico.
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 dimension fsica, y
cada valor tiene ahora solo 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 comparacion 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 combinacion de dimensiones en las filas o en las columnas utiliza
mas espacio en la pantalla que la combinacion de dimensiones en paginas, dejando menos
espacio para la visualizacion de los datos en s. Cuanto menos espacio se dedique a los
datos, mas desplazamientos de pantalla se requeriran para visualizarlos.
Lo conveniente es mantener la mayora de las dimensiones mapeadas en paginas, a
menos que se necesite ver mas de un miembro de la dimension al mismo tiempo.
En el caso de que no se pueda evitar el anidamiento en filas o en columnas, es mejor
anidar la mayor cantidad de dimensiones en las columnas, ya que generalmente es mas
usable el espacio vertical de la pantalla que el horizontal. Una grilla clasica tiene una
dimension en las filas, de una a tres en las columnas, y el resto en las paginas, como en
la siguiente figura.
Observemos la diferencia de la grilla anterior con la que se presenta a continuacion.

En esta grilla se anidan cuatro dimensiones en las filas, una en las columnas y ninguna
en las paginas.
Antes de decidir como organizar las dimensiones en la pantalla es util preguntarse

que se quiere ver y que 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 filas y columnas, y las dimensiones de productos,
escenario y tipo de cliente a paginas, como en la siguiente figura.
La habilidad para cambiar facilmente la forma de visualizar los mismos datos recon-
figurando la organizacion de las dimensiones es uno de los grandes beneficios en cuanto
a la navegacion del usuario que tienen los sistemas multidimensionales.
Captulo 2
Consideraciones previas a la
implementacion
Antes de optar por una solucion OLAP y ponerla en funcionamiento hay que poner a
punto una serie de cuestiones en toda la organizacion, ya que se van a extraer y mezclar
datos provenientes de varios sistemas OLTP, sistemas batch y hasta de fuentes de datos
externas.
La organizacion debe estar preparada para considerar la adquisicion de nueva tec-
nologa, y sus integrantes deben estar predispuestos a tareas adicionales, al aprendizaje
necesario, e incluso a cambiar roles y responsabilidades con otros integrantes de la orga-
nizacion.
Para determinar la naturaleza de estas consideraciones sera util analizar primero los
requerimientos de una solucion OLAP. A partir de esto se puede realizar un analisis
costo beneficio, y tambien una evaluacion del estado actual de la empresa, en cuanto al
hardware, software, y datos existentes, para establecer el marco en el que se instalara la
herramienta.
2.1. Requerimientos fsicos y logicos

Los requerimientos logicos esenciales para implementar una solucion OLAP son:
Poder establecer una rica estructura de dimensiones jerarquicas. Vivimos en un

mundo que se caracteriza por conjuntos altamente multidimensionales de sistemas
que interactuan, cada uno con muchos niveles de datos, detalles, realidades y abs-
tracciones, y la habilidad de OLAP de representar eficientemente esta complejidad
es una de sus principales cualidades, por lo tanto debemos aprovecharla al maximo.
Contar con un metodo eficiente y simple para especificar dimensiones, calculos, y

el conjunto de datos que se quiere analizar. El analisis en una solucion OLAP sim-
plemente consiste en aplicar operaciones sobre valores numericos. Lo importante es
poder obtener resultados a partir de comparaciones inteligentes de ratios y tenden-
cias en el tiempo o sobre otras dimensiones. Por ejemplo, un director de ventas en
26
CAPITULO 2. CONSIDERACIONES PREVIAS A LA IMPLEMENTACION 27
la organizacion puede consultar las diferencias entre las ganancias en el mercado

nacional e internacional totalizadas por rubros de productos, y visualizarlas orde-
nadas de mayor a menor. Para responder a esta consulta la herramienta tiene que
realizar varios calculos: 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 merca-
dos, y por ultimo se ordenan los totales en forma descendente. El requerimiento es
que este tipo de calculos sea tan facil de especificar o definir en la aplicacion como
lo es expresarlo.
Flexibilidad en todos los aspectos, en particular en la visualizacion de los datos,

en la definicion de las consultas y en la interfase.
Si hablamos de flexibilidad en cuanto a la visualizacion de datos, podemos decir
que la aplicacion es flexible si permite visualizar los resultados en forma de grafos,
matrices y charts, permitiendo al usuario optar segun sus preferencias.
La flexibilidad en la definicion de consultas implica libertad y facilidad en la selec-
cion de las medidas y las dimensiones de los cubos, filtros sobre los resultados, y
distintos formatos para los valores numericos, entre otros.
En otros tiempos, el analisis de datos estaba a cargo de un grupo reducido de
personas en la organizacion, que dedicaban todo su tiempo a esta tarea. Hoy sin
embargo, cada vez mas gente en la organizacion esta capacitada para hacer anali-
sis de informacion, pero solo le dedican una porcion del tiempo de trabajo. Por
esto se requiere que el entorno sea lo suficientemente amigable para hacer el tra-
bajo rapido y no perder horas tratando de entender como usar la aplicacion. La
amigabilidad esta ntimamente relacionada con las interfaces graficas que incluyen
elementos para facilitar la definicion de las consultas, aunque siempre hay usuarios,
generalmente avanzados, que prefieren una interfase simple de lnea de comandos.
Separacion entre la estructura y la representacion de los datos. Este requerimiento

permite que los usuarios finales puedan reorganizar las vistas sin que requieran
cambios estructurales en los datos. Esta separacion no existe en las hojas de calculo
por ejemplo, lo que las hace muy rgidas para un analisis de tipo OLAP.
Entre los principales requerimientos fsicos para una aplicacion OLAP encontramos
los siguientes:
Acceso rapido a los datos. OLAP necesita soportar consultas ad hoc, las cuales
requieren calculos en el momento en el que se esta realizando la consulta. Por
ejemplo un gerente de ventas podra consultar las ventas nacionales, profundizar
a las ventas por regiones para observar cuales tienen ventas mas bajas, y luego
profundizar para ver las ventas por rubros en una region determinada. Cada paso
en este analisis es una consulta, y si el tiempo de respuesta se midiera en horas,
o incluso en varios minutos, esperar la respuesta de este analisis seria bastante
desalentador. La meta entonces es proveer un tiempo de respuesta razonable, en
lo posible en segundos, mientras se trabaja con una base de datos muy grande en
un entorno multiusuario y quiza distribuido en una red.
Para cumplir con este requerimiento algunas herramientas precomputan (precon-
solidan) todos los totales, aunque esto puede llevar a una explosion de la base
de datos. El incremento del tamano de la base de datos va a opacar el beneficio
ganado en el tiempo de respuesta. Para un acceso eficiente, 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 estan divididas en areas de trabajo que

colaboran entre si. Como resultado de esta descentralizacion, varios empleados de
distintas areas van a necesitar acceso a los datos de analisis. Puede darse el caso
que los datos que esta analizando un ejecutivo hayan sido generados por muchos
departamentos distintos, y en las grandes corporaciones, estos departamentos ni
siquiera esten en el mismo pas. La manera de proveer soporte multiusuario que
se prefiere en aplicaciones OLAP es un soporte de lectura/escritura multiusuario
donde el procesamiento y los datos estan distribuidos entre el cliente y el servidor.
2.2. Analisis costo-beneficio

Es comun que la organizacion tenga poco interes en este tipo de iniciativas.
Una de las razones puede ser que no se valore el impacto real que la carencia de
buena informacion tiene sobre la rentabilidad del negocio.
Otra razon puede ser la ausencia de un equipo de desarrollo dentro de la empresa,
o quizas nos encontramos en una organizacion cuyos ejecutivos de negocios son gente
inaccesible o poco dispuesta.
As como puede ocurrir que no vislumbren los grandes beneficios detras de un proyecto
de solucion OLAP, es comun que no se perciba la complejidad del proyecto, y que no se
lo reconozca como una iniciativa que abarca todos los aspectos de la organizacion (cross-
organizational), y sabemos que esto no es lo mismo que una aplicacion independiente.
Otra razon que hace que los integrantes de la compana no se interesen por la incor-
poracion de la herramienta puede ser el llamado sndrome de silver bullet: los gerentes y
desarrolladores confan en que una o varias herramientas o metodologas ya existentes en
la organizacion les resolveran todos sus problemas, entonces cualquier cosa nueva nunca
sera tan buena.
Para que el interes crezca entonces deben definirse claramente los beneficios de la
implementacion OLAP, y dejar en claro que permitira solucionar problemas existentes
y tomar ventajas de las oportunidades en el negocio.
Un proyecto de soporte de decisiones no solo puede traer beneficios tangibles como
un incremento en las ventas, sino tambien intangibles, como mejorar la reputacion de la
empresa. Estos beneficios intangibles son los mas difciles de cuantificar en terminos de
dinero, y aunque los beneficios generales de este tipo de proyectos son bien conocidos, la
gerencia no aprobara el proyecto a menos que asociemos estos beneficios generales con
metas estrategicas y problemas especficos propios de la organizacion.
La idea es preparar una lista detallada con los beneficios concretos para medirlos y
compararlos con los costos de la implementacion.
La iniciativa del proyecto debe estar dirigida al negocio y no a la tecnologa. Es
decir, la justificacion de la iniciativa no debe ser solo el hecho de experimentar con
nuevas tecnologas, sino reducir los problemas que afectan la rentabilidad o la eficiencia
de la organizacion (business pain).
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 organizacion, tanto tecnica como no tecnica. Entre estos elementos
se incluyen el hardware y motores de base de datos por un lado, y los datos y aplicaciones
por el otro.
Evaluacion de la Infraestructura tecnica

Es conveniente analizar factores tecnologicos como la plataforma de hardware,
conexiones de red, motores de bases de datos (DBMSs), y gateways DBMS que
se usan en la organizacion, ademas de hacer una revision de las herramientas y
estandares que emplean los analistas de negocios. El objetivo de esta evaluacion es
el de planear una configuracion que brinde la mejor performance para el acceso y
recupero de los datos de la aplicacion OLAP a implementar.
Evaluar el hardware existente

Es comun encontrar una especie de caos controlado en lo que respecta al hardware
de una organizacion, tal como se ve en la figura. Este caos viene acompanado
de una vasta lista de aplicaciones distintas y de un equipo de tecnicos con los
conocimientos suficientes como para hacer el soporte de los sistemas ya existentes.
En este escenario y ante la implementacion de una aplicacion de soporte de deci-

siones hay que tener en cuenta que en el caso de necesitar nuevas plataformas de
hardware, estas tienen que encajar con la configuracion existente.
Los principales requerimientos a la plataforma de hardware son la potencia y la

escalabilidad.
El hardware debe ser lo suficientemente potente, en cuanto a procesamiento y a

espacio de almacenamiento, como para manejar accesos complejos y requerimien-
tos de analisis contra grandes volumenes de datos. No solo debe soportar consultas
simples y predefinidas sobre datos resumidos sino tambien consultas ad hoc com-
plejas sobre datos detallados.
La necesidad de que sea escalable surge del rapido crecimiento del volumen de
la informacion, y del rapido cambio en las frecuencias de actualizacion, 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 aplicacion de soporte de
decisiones.
Se debe planificar 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 rapida de los datos. La red es una de las principales piezas que
aseguran el exito de la solucion OLAP. Con redes robustas, los datos se van a
transferir rapidamente desde las bases de datos operacionales hacia el repositorio
de datos, y desde el servidor OLAP al usuario final para su analisis.
Evaluar los Gateways DBMS

Los datos operacionales de la organizacion pueden estar distribuidos en multiples
plataformas DBMS, interactuando a traves 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 faciles de implementar, y menos costosos que los demas. Sin
embargo, si en la organizacion 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 imple-
mentacion y mantenimiento, por lo tanto son bastante costosos.
Gateways SQL: son los que usan SQL para acceder a la base de datos. Tra-
ducen los requerimientos de la aplicacion a SQL nativo del DBMS en cuestion.
Solo pueden acceder a bases realmente relacionales (no simuladas).
Drivers ODBC: Un driver ODBC (Open DataBase Connectivity) es una apli-
cacion que permite que cualquier sistema acceda a los datos independiente-
mente del DBMS que los maneje, a traves de APIs.
Evaluar los DBMSs

Al elegir la infraestructura de la base de datos hay que tener en cuenta el volumen
de los datos que se van a manejar. La eleccion puede variar desde un servidor de
archivos local, un servidor empresarial o hasta un gran mainframe.
Lo que podemos rescatar como conclusion de lo mencionado es que el hardware,

los gateways DBMS y el DBMS deben configurarse para asegurar la escalabilidad
y la performance de la solucion a implementar.
Evaluacion de la Infraestructura no tecnica

La infraestructura no tecnica incluye a los datos que se encuentran en la organi-
zacion y a las aplicaciones que se usan.
En primer lugar es necesario construir un modelo logico 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 aplicacion. 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 ultimos son los que mantienen las
aplicaciones de la organizacion diariamente, y conocen con bastante profundidad
como y donde se almacenan los datos, como se relacionan entre si, la historia de
su uso, y como el contenido y el significado de los datos fue cambiando con el
transcurso del tiempo.
Limpieza de datos (data cleansing)

Una vez identificados los datos de interes para la aplicacion de procesamiento
analtico, es conveniente examinar los casos en que se incumplen reglas de negocios
o de integridad, y discutir el impacto que tendra el esfuerzo de la limpieza de estos
datos, es decir su correccion.
La limpieza es una tarea que debe hacerse tambien en forma conjunta con la gente
de negocios y el grupo de desarrollo. Los primeros conocen la semantica de los
datos, y los desarrolladores conocen su significado dentro de los programas. Son
los que saben que un cierto flag en la base de datos indica si un determinado cliente
tiene o no cuenta corriente, por ejemplo.
Aun cuando se usen herramientas automaticas, el costo de asegurar la calidad de

los datos para la totalidad de la informacion es elevado para muchas organizaciones.
Por esto lo ideal es siempre concentrarse en la limpieza de datos crticos, teniendo
en cuenta que no todos los datos son igual de crticos para la gente de negocios.
No es necesario limpiar todos los datos, y tampoco es necesario hacerlo todo de
una sola vez.
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 suficientemente limpio. Si no
es as, hay que ver cuales son las posibilidades de aplicar una limpieza, si es que
existen, y especificar los procesos de limpieza que se determinen.
Los gerentes suelen ver las actividades involucradas en el analisis y limpieza de los
datos como una perdida de tiempo. Ellos juzgan el exito del proyecto de acuerdo
al tiempo en el que se lo termina, y no se fijan en la calidad de los resultados. Por
esta razon en la mayora 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 evaluacion consiste en examinar componentes como

programas, flujo de tareas, bases de datos y archivos, que implementan las fun-
ciones, procesos y datos de negocios y las relaciones entre ellos. Una vez evaluados
estos factores podemos identificar, catalogar y documentar tanto las aplicaciones
como las reglas de negocios que afectan los datos.
Captulo 3
Disenar 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 analisis, en conocimiento util 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 opera-
cionales hacia el DataWarehouse, quiza con alguna transformacion previa de los datos.
Esta transformacion 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 informacion cruda, y los sistemas OLAP hacen agre-
gaciones y sumarizaciones de estos datos, y los organizan en cubos o almacenamientos
especiales para permitir un rapido recupero ante una consulta.
La siguiente figura muestra una arquitectura tpica de la interrelacion entre las bases
operacionales, el DataWarehouse y la aplicacion OLAP. OLAP y los DataWarehouses
se complementan entre s. El DataWarehouse almacena y administra los datos, y OLAP
los convierte a informacion util.
34
CAPITULO 3. DISENAR LA FUENTE DE DATOS Y MIGRARLOS 35
3.1. Que es un DataWarehouse (DW)?

Un DataWarehouse es un repositorio central o coleccion de datos en la cual se
encuentra integrada la informacion de la organizacion y que se usa como soporte para el
proceso de toma de decisiones gerenciales.
El concepto de DataWarehouse comenzo a surgir cuando las organizaciones tuvieron
la necesidad de usar los datos que cargaban a traves 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 estan haciendo al mismo
tiempo. Fue entonces que se decidio separar los datos usados para reportes y toma
de decisiones de los sistemas operacionales y disenar y construir DataWarehouses para
almacenar estos datos.
Las principales caractersticas que posee un DataWarehouse se detallan a conti-

nuacion:
Es orientado a la informacion relevante de la organizacion: En un DataWare-

house la informacion se clasifica en base a los aspectos de interes para la empresa,
es decir, se disena para consultar eficientemente informacion relativa a las activi-
dades basicas de la organizacion, como ventas, compras y produccion, y no para
soportar los procesos que se realizan en ella, como gestion de pedidos, facturacion,
etc.
Es integrado: integra datos recogidos de diferentes sistemas operacionales de la

organizacion y/o fuentes externas. Esta integracion se hace estableciendo una con-
sistencia en las convenciones para nombrar los datos, en la definicion de las claves,
y en las medidas uniformes de los datos.
Es variable en el tiempo: los datos son relativos a un periodo de tiempo y

deben ser incrementados periodicamente. La informacion almacenada representa
fotografas correspondientes a ciertos perodos de tiempo.
Es no volatil: la informacion no se modifica despues de que se inserta, solo se

incrementa. El periodo cubierto por un DataWarehouse vara de 2 a 10 anos.
Datamarts
Las corporaciones de hoy se esfuerzan por conducir sus negocios hacia una base inter-
nacional. Vemos companas que surgieron en Estados Unidos y se expandieron a Europa,
Asia y Africa. La expansion del negocio crea la necesidad de acceder a datos corporativos
que estan ubicados en diferentes puntos geograficos. Por ejemplo, un ejecutivo de ventas
de una compana con origen en Brasil que esta situado en Chile puede necesitar acceso
a la base de datos de la empresa para identificar los clientes potenciales que residen en
Chile.
Este problema se soluciona creando versiones mas pequenas del DataWarehouse, los
datamarts. Estas versiones se crean usando algun criterio particular, como por ejemplo
el lugar geografico. En el ejemplo anterior los datos de los clientes que residen en Chile
se deben almacenar en el datamart de la sucursal en ese pas.
La existencia de los datamarts crea nuevas formas de pensar cuando se disenan los
repositorios corporativos de datos. Algunas corporaciones reemplazan completamente el
concepto de tener un DataWarehouse central, por varios datamarts mas pequenos que
se alimenten directamente de los sistemas operacionales.
Otras companas usan datamarts para complementar sus DataWarehouses. Mueven

datos desde el DataWarehouse hacia varios datamarts con el fin de permitir un analisis
mas eficiente. La separacion de los datos se determina segun criterios como departamen-
tos, areas geograficas, periodos de tiempo, etc.
Finalmente, algunas organizaciones usan sus datamarts como el primer paso de alma-
cenamiento de datos operacionales. Luego los datos de todos los datamarts se replican
en un DataWarehouse corporativo central.
3.2. Diferencias entre un DataWarehouse y una base

de datos operacional
La mayora de los sistemas operacionales estan dirigidos a la carga de datos, con
cientos o miles de transacciones diarias y repetitivas, que ademas requieren un tiempo
de respuesta muy corto por parte de los usuarios. Ejemplos de este tipo de operaciones
lo son las reservas de vuelos, depositos bancarios, y reservaciones de hotel.
Las bases de datos operacionales deben estar disenadas con el objetivo de hacer esta
tarea lo mas eficiente posible. Otro objetivo del diseno 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 caracterstica distintiva de las bases de datos operacionales.
Evitar la redundancia, desde el punto de vista tecnico, se refiere a no destinar colum-

nas en varias tablas para almacenar el mismo dato. Esto es lo que se conoce como
normalizacion 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 conse-
cuencia de la normalizacion, tambien 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 actualizacion, sino tambien porque lleva a
inconsistencias, y la inconsistencia es una de las principales razones de la baja calidad
en los datos.
Las aplicaciones destinadas al analisis de datos en cambio, estan orientadas a la salida

de informacion, ya sea en forma de reportes, cubos, o respuestas a consultas.
Estas consultas y reportes no necesariamente se produciran en el mismo da, ni dia-
riamente. No son tan previsibles y frecuentes como las transacciones en un sistema
operacional. Se podra 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 finalizar el pedido de
los datos en microsegundos, es suficiente que la respuesta este disponible en segundos o
incluso en minutos.
Mientras que la normalizacion funciona bien para los sistemas operacionales, los
requerimientos para el analisis de datos son distintos.
La normalizacion implica un gran esfuerzo y tiempo para la recoleccion de los datos.
Para obtener por ejemplo, un cubo de ventas anuales por sucursal, se tienen que acceder
muchas tablas, y leer cada fila de esas tablas. Esto no solo es complejo sino tambien
extremadamente ineficiente si se hace en una base de datos normalizada, porque requiere
un escaneo extensivo de varias tablas y muchas operaciones de JOIN.
Debido a esto, una de las principales caractersticas en los DataWarehouses es la

denormalizacion en el diseno de las tablas.
Ademas, los problemas de actualizacion que surgen cuando existe redundancia en
una base operacional no pueden ocurrir en un DataWarehouse. El DataWarehouse al-
macena informacion preexistente en la organizacion y no existen sobre el operaciones de
actualizacion y modificacion en el sentido de las aplicaciones operacionales.
En la figura se muestran las operaciones tpicas sobre una base operacional, como
inserciones, modificaciones y borrados. En cambio en un DataWarehouse solo hay dos
operaciones, la carga inicial de datos y el acceso a los mismos. No hay actualizacion 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 historicos, y los datos totalizados.
Las bases de datos operacionales almacenan muy pocos datos derivados, en general se
derivan dinamicamente 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 historicos. Todos los registros
historicos se van archivando en otros medios de almacenamiento en forma periodica. En
los DataWarehouses, en cambio, se almacenan grandes cantidades de datos historicos,
algunos con cierto grado de totalizacion, y tambien se guardan datos con algun nivel de
detalle.
Por lo general, en un DataWarehouse la informacion representa los datos sobre un
horizonte largo de tiempo, quiza desde cinco a diez anos. El horizonte de tiempo re-
presentado en el ambiente operacional es mucho mas corto, desde valores actuales hasta
sesenta a noventa das atras.
Veamos con un ejemplo como sera el analisis de datos a partir de una base de datos
operacional:
Supongamos que contamos con una base de datos operacional bancaria, y que un
analista de negocios esta interesado en comparar las ganancias obtenidas de las transac-
ciones en los cajeros automaticos segun el costo de la transaccion.
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 informacion consume mucho
tiempo y recursos, ya que las consultas podran ser mucho mas grandes y complejas,
involucrando muchas operaciones de JOIN, lo cual afectara la velocidad con la que
se recuperan los resultados y tambien afectara la performance de la base de datos
operacional sobre la que se estan realizando importantes transacciones diarias.
Esta es una de las razones por las cuales es conveniente tener los datos que sirven
para analisis en una base de datos aparte, y con un diseno diferente como los que veremos
en las secciones siguientes. Veamos la diferencia entre ambos disenos:
Diseno Operacional
Diseno Estrella
Este ultimo diseno es un diseno Star o Estrella, cuya descripcion veremos en la seccion
siguiente.
Luego de la migracion 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 eficiencia 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 to-
talizar 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). Tambien podemos totalizar las transacciones por estado para to-
dos 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 dimen-
siones para hacer totalizaciones sobre la tabla de hechos.
3.3. Disenar el DataWarehouse

Debido a las diferencias en el proposito y objetivos de las bases de datos operacionales
con las bases orientadas a analisis se originaron tecnicas de diseno diferentes para estas
ultimas.
Habiendo conocido en la seccion anterior las principales caractersticas de este tipo
de base de datos, veremos ahora cuales son los requerimientos en cuanto al diseno fsico
y logico de las mismas.
3.3.1. Diseno logico

Las premisas basicas en el diseno logico son:
Preparar a las bases multidimensionales para soportar el recupero de una gran

cantidad de filas de datos en forma rapida.
La mayora de los analistas de negocios van a querer ver datos totalizados. Estos
datos en lo posible deben precalcularse y almacenarse de antemano para que es-
ta recuperacion sea rapida y eficiente. Es importante ademas discutir el nivel de
granularidad y de detalle esperado por los analistas cuando hacen operaciones de
DrillDown.
El diseno debe estar conducido por el acceso y por el uso, es decir, teniendo en
cuenta que tipo de reportes o resumenes son los mas frecuentes, y cuales los mas
urgentes.
Un diseno normalizado no es bueno, no solo por lo mencionado en la seccion ante-

rior, sino porque no resulta demasiado intuitivo para una persona de negocios, y
podra volverse demasiado complejo.
Todos los datos que se incluyan ya deben existir en las fuentes de datos opera-
cionales, o ser derivables a partir de ellos.
Las dos tecnicas de diseno mas populares son el esquema Star y el esquema Snowflake.
Esquema Star (Estrella)
Este esquema esta formado por un elemento central que consiste en una tabla llamada
la Tabla de Hechos, que esta conectada a varias Tablas de Dimensiones.
En el ejemplo de la seccion 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 va-
lores operacionales atomicos segun las distintas dimensiones, tales como clientes, pro-
ductos o perodos de tiempo.
Representan un evento critico y cuantificable en el negocio, como ventas o costos. Su

clave esta compuesta por las claves primarias de las tablas de dimension relacionadas
(las foreign keys). Pueden existir varias tablas de hechos con informacion redundante,
porque podran contener distintos niveles de agregacion de los mismos datos. Por ejemplo
podra existir una tabla de hechos para las Ventas por Sucursal, Region y Fecha, otra
para Ventas por Productos, Sucursal y Fecha, y otra tabla que almacene las Ventas
por Cliente, Region y Fecha. En general las tablas de hechos tienen muchas filas y
relativamente pocas columnas.
Las tablas de dimension 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 esta formada por un solo atributo, y su caracterstica principal es que estan
denormalizadas. Esto significa que si la dimension incluye una jerarqua, las columnas
que la definen 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 filas. 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 anos, cuatrimestres, periodos fiscales, y periodos contables.
Otras dimensiones comunes son las de clientes, productos, representantes de ventas,
regiones, sucursales.
En la siguiente figura 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 anos de datos historicos, y por su simplicidad en comparacion
con una base de datos normalizada.
Esquema Snowflake
Es una variante al esquema estrella en el cual las tablas de dimension estan norma-
lizadas, es decir, pueden incluir claves que apuntan a otras tablas de dimension.
En la siguiente figura vemos un esquema similar al anterior, donde la tabla de di-
mension 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 normalizacion son la reduccion del tamano y redundancia en las
tablas de dimension, y un aumento de flexibilidad en la definicion de dimensiones.
Sin embargo, el incremento en la cantidad de tablas hace que se necesiten mas opera-
ciones 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. Diseno fsico

Debido a que los DataWarehouses trabajan tanto con datos detallados como con
datos resumidos, y frecuentemente almacenan algunos datos en forma redundante, el
tamano 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). Disenar una base de
datos de este tipo es un gran desafo y la tarea de mantenerlas es demandante.
Entre las decisiones de implementacion que se deben tomar se incluyen el tamano del
espacio libre, el tamano del buffer, el tamano del bloque, y si se usa o no una tecnica de
compactacion de la base de datos. Todas estas cuestiones afectaran la performance del
DataWarehouse.
A continuacion se detallan algunos temas que impactan sobre el diseno fsico 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 logica
se repartan en multiples conjuntos de datos fsicos. Este particionamiento se basa
en una columna de la tabla de hechos, que comunmente 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 restau-

raciones de porciones de una tabla sin impactar en la accesibilidad de otras por-
ciones en la misma tabla que no estan siendo backapeadas ni restauradas en ese
momento.
Otra ventaja del particionamiento es la opcion de almacenar los datos mas fre-
cuentemente accedidos en dispositivos mas rapidos, 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 tecnica muy util para el acceso secuencial de grandes cantidades de datos.
El clustering se obtiene definiendo un ndice clustering para una tabla, el cual
determina el orden secuencial fsico en el que se almacenan las filas en los conjuntos
de datos.
Esta tecnica es importante porque mejora drasticamente la performance del acceso

secuencial, y este tipo de acceso es el mas usado en el procesamiento OLAP. Cuando
las filas de la tabla no permanezcan almacenadas en el orden correspondiente a su
ndice clustering, situacion conocida como fragmentacion, la performance bajara y
habra 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 filas,
y las que tienen una alta distribucion de valores, no una baja como por ejemplo
Codigo Postal.
Una vez que se determinan las columnas a indexar, hay que determinar la estrategia
de ndice. La mayora de las DBMSs proveen varios algoritmos, entre ellos B-tree,
Hash, archivo Invertido, Sparse y Binario. Se debera optar por el mas optimo para
el producto DBMSs que se esta usando.
Reorganizaciones
Las cargas incrementales de las bases de datos iran fragmentando las tablas, y esta
fragmentacion puede resultar en un decaimiento de la performance. La mayora de
las DBMSs proveen rutinas de reorganizacion para reclamar el espacio fragmentado
y mover registros.
Las actividades basicas involucradas en la reorganizacion de una base de datos

implican copiar la base de datos vieja en otro dispositivo, rebloquear las filas y
recargarlas. Estas tareas no son triviales en un DataWarehouse, pero todos los
DBMSs permiten reorganizar particiones, lo cual es otra buena razon para parti-
cionar las tablas.
Backup y Recupero
Los DBMSs proveen utilidades para hacer backups completos y tambien incremen-
tales. Muchas organizaciones tienen la erronea impresion de que los DataWare-
houses siempre se pueden recrear a partir de las fuentes de datos originales. Sin
embargo, ademas de que esta tarea puede llevar mucho tiempo porque hay que
reejecutar los programas de extraccion, transformacion y carga, es posible que
estos programas y los datos mismos ya no esten disponibles.
Ejecucion de las consultas en paralelo

Para mejorar la performance de una consulta es mejor dividirla en componentes que
ejecuten concurrentemente. Algunos DBMSs ofrecen ejecucion paralela en forma
transparente, es decir, dividen la consulta por si solos.
Los DBMSs estan basados en reglas internas intrincadas, que deben entenderse y
seguirse. Para esto las organizaciones contratan administradores de bases de datos. Una
situacion comun es que se deje el diseno de la base de datos a los programadores, quienes
quiza no esten del todo familiarizados con el funcionamiento interno del motor, y como
consecuencia creen un diseno pobre que no aproveche al maximo las caractersticas que
brinda el producto.
3.4. Migrar los datos: ETL (Extract, Transform, Load)

La migracion 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 razon por la cual se requieren estos procesos se origina en una necesidad de refor-
matear, conciliar y limpiar los datos de origen. Seria conveniente que las transformaciones
a los datos se apliquen solo una vez y que se reflejen en los archivos y bases de datos que
actuan como fuente de datos.
La mayora de los datos de origen son los datos operacionales actuales, aunque parte
de ellos pueden ser datos historicos archivados.
Si los requerimientos de datos incluyen algunos anos de historia es necesario desa-
rrollar tres conjuntos de programas ETL: una Carga Inicial, una Carga Historica, y una
Carga Incremental.
Carga Inicial
La carga inicial se asemeja mucho al proceso de conversion 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 extraccion, transformacion, y carga de los datos tal cual se explicara en las
secciones siguientes.
Carga Historica
Este proceso debe verse como una extension de la carga inicial, pero la conversion
aqu es un poco diferente porque los datos historicos son datos estaticos.
A diferencia de los datos operacionales, los datos estaticos ya se archivaron en
dispositivos de almacenamiento offline. Es comun que con el transcurso del tiempo
se eliminen elementos de datos que ya no sirven, se agreguen nuevos, se modifiquen
los tipos de ciertos datos o los formatos de los registros, lo que implica que los datos
historicos no necesariamente se puedan sincronizar con los datos operacionales. Por
lo tanto los programas de conversion escritos para la carga inicial quiza no sean
aplicables a la carga de datos historicos sin algunos cambios previos.
Carga Incremental
Una vez que el DataWarehouse esta cargado con datos iniciales e historicos, hay
que desarrollar otro proceso para la carga incremental, que se ejecutara mensual,
semanal o diariamente. Existen dos formas de disenar 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 opcion no es viable debido al volumen de los datos, por eso
la mayora opta por la siguiente opcion.
Extraer Deltas solamente: solo se extraen registros nuevos o registros que
contengan valores que cambiaron desde la ultima carga realizada.
Disenar programas ETL para extracciones delta es mas facil 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 extraccion previa para encon-
trar 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 mayora de los casos los administradores no estaran
de acuerdo porque cualquier cambio en la estructura de la base operacional
requerira cambios en los programas. Para ellos no es conveniente cambiar los
sistemas crticos y perder tiempo en el testing a favor de la aplicacion de
analisis.
Que pasa con los registros eliminados?
Cuando se borran registros en los archivos o bases de datos fuente, las filas
correspondientes no se pueden eliminar del DataWarehouse. Tampoco es lo
ideal, ya que una de las principales caractersticas de un DataWarehouse es
guardar datos historicos!
Es necesario definir reglas de negocios para determinar cuando propagar una
eliminacion operacional al DataWarehouse y cuando no. Por ejemplo, si se
elimina un registro debido a la anulacion de una transaccion erronea, es con-
veniente que la fila 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
propagacion porque estaramos eliminando un dato historico.
Existe otra complicacion, que surge debido a que los programas que extraen
deltas se disenan para tomar solo los registros existentes que contengan va-
lores cambiados, no pueden extraer registros que no existen. La solucion es
usar archivos de auditoria, o crear un archivo delta comparando una extrac-
cion completa con una extraccion anterior. En cualquier caso, una vez que
se identifican los registros eliminados, el proceso ETL debe consultar las re-
glas 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 tendran 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 extraccion
de datos seria ordenar, filtrar, 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 podra impactar tanto que los sistemas operacionales tendran que suspenderse
las actividades por varias horas.
En la mayora 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 razon por la que la migracion
de los datos se divide en tres procesos separados de extraccion, transformacion y carga.
La solucion a este conflicto es un compromiso entre la eficiencia del proceso ETL y
el tiempo de uso de las fuentes de datos. Es decir, los programas de extraccion de datos
se tienen que disenar para maximizar la eficiencia del procesamiento ETL, pero ademas
deben liberar las fuentes de datos lo antes posible, aunque este es un objetivo bastante
difcil de lograr.
Una de las razones que dificultan la tarea de extraccion es la redundancia de datos en
los sistemas operacionales, redundancia que los programas de extraccion 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 busqueda en las tablas que eso implica.
Ademas, es necesario examinar las interdependencias operacionales entre los distintos
archivos y bases de datos de donde se va a extraer la informacion para determinar la
secuencia de ejecucion de los programas de extraccion.
3.4.2. Transformar los datos

La mayor parte del trabajo ETL ocurre durante la transformacion de los datos,
porque es donde se requieren la integracion y limpieza de datos. La extraccion y la carga
solo representan el 20 % del proceso.
Algunos problemas tpicos cuando se extraen los datos del entorno operacional se
mencionan a continuacion:
Claves primarias inconsistentes: las claves primarias en las bases que actuan
como fuentes de datos no siempre coinciden con las que se definen en el DataWare-
house. Por ejemplo, si existen cinco archivos de clientes, cada uno con una clave
diferente, estas claves se tienen que consolidar o transformar en una unica clave en
el DataWarehouse.
Valores inconsistentes: son datos duplicados que existen en la organizacion, es

decir, elementos que tienen una o mas copias exactas, pero debido a actualizaciones
inconsistentes y otras anomalas, dejaron de ser copia exacta del original. Estos
valores tambien deben conciliarse durante el proceso ETL.
Datos con diferentes formatos: los elementos tales como fechas o valores mone-
tarios cuentan con una gran variedad de formatos. Esto da lugar a la necesidad
de transformar estos datos a un formato unico en el que se almacenara en el
DataWarehouse.
Valores erroneos: la correccion de valores incorrectos o que violen las reglas de

negocios puede ser muy extensa y complicada. Los programas de transformacion
realizan calculos y busquedas en las tablas para determinar los valores correctos.
Sinonimos y homonimos: los datos redundantes no siempre son faciles de re-

conocer porque el mismo elemento de datos puede tener diferentes nombres en las
distintas fuentes. Otra situacion que puede darse es que se use el mismo nombre en
varias fuentes para referirse a elementos diferentes. Los sinonimos y los homonimos
no deben existir en el DataWarehouse, por lo tanto todos estos elementos deben
renombrarse con nombres estandares definidos.
Logica embebida: algunos sistemas operacionales son muy viejos. Estos sistemas
solan tener relaciones y convenciones arcaicas y sin documentacion entre los ele-
mentos de datos. Por ejemplo, el valor 00 en un campo Flag puede significar que
el envo se devolvio, y el valor 11 en el mismo campo significa que el registro esta
anulado.
En la figura vemos algunos ejemplos tpicos de transformaciones de datos.

Luego de transformar los datos debido a la existencia de tipos de datos y longitudes

incompatibles, o datos inconsistentes o incorrectos, una gran porcion del proceso de
transformacion esta destinado a la integracion, derivacion, agregacion y totalizacion de
los datos:
Integracion: el resultado de la integracion es que cada elemento de dato unico

sea conocido por un nombre estandar.Muchos de los datos se renombran en forma
acorde a ciertos estandares de nombramiento en el DataWarehouse, por ejemplo,
renombrar Cliente_Nom como ClienteNombre.
Derivacion: se crean nuevos datos a partir de datos atomicos en las fuentes, me-
diante calculos, busquedas, y logica procedural.
Por ejemplo, generar un nuevo codigo para clasificar clientes basandose en cierta
combinacion de datos existentes, calcular el precio total como resultado de multi-
plicar el precio unitario por la cantidad vendida, o unir la columna Nombre con
la columna Apellido para obtener una unica columna NombreCliente en el
Datawarehouse.
Otro ejemplo consiste en dividir elementos de datos y que cada una de las por-
ciones resultantes conformen una columna en el DataWarehouse. Por ejemplo, di-
vidir una columna de tipo fecha o timestamp en sus componentes, como dia, mes,
cuatrimestre y ano.
Las reglas tecnicas y de negocios que determinan las transformaciones que se tienen
que aplicar se extraen de viejos manuales, viejos memos, emails, programas, y tambien
son propuestas por gente en la organizacion que recuerda cuando y porque se crearon
las distintas reglas.
La parte mas importante de la transformacion de datos consiste en el precalculo de

los mismos para que las consultas al DataWarehouse se respondan mas eficientemente:
Totalizacion (Sumarizacion): consiste en procesar valores numericos para obte-

ner valores generales como cantidades, promedios, maximos, mnimos, totales. Es-
tos 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 de-
partamentos, los totales por regiones, y los totales por pas.
Agregacion: se refiere a crear datos derivados a partir de la union de varios datos

atomicos, 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 mayora de los datos se agregan y se totalizan basandose en patrones de los

reportes requeridos y en la estructura de la base de datos multidimensional elegida (Star
o Snowflake).
Es importante examinar en que momento realizar cada transformacion. Hay solo un
proceso ETL, as que las transformaciones aplicables a todos los datos de origen, como
las conversiones de tipos, se deberan realizar en primer lugar. Las transformaciones
especificas del DataWarehouse, como agregaciones y totalizaciones, deberan realizarse
mas hacia el final del proceso.
Conciliacion de datos
El proposito de la conciliacion de datos es asegurar que toda la informacion 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 direccion estrategica de la organizacion.
Una conocida disciplina cuando se manipulan datos es conciliar toda salida del proceso
con la entrada. Cada programa o modulo que lea datos y los escriba en otro lugar debe
producir totales de conciliacion.
Existen tres tipos de totales:
Cantidad de registros
Uno de los totales fundamentales es una simple contabilizacion de los registros
ledos y los escritos. Tambien se deben contabilizar los registros rechazados en el
caso de registros que no pasaron algun chequeo del proceso ETL. Luego, el total
de registros escritos mas los rechazados debe ser igual al total de registros ledos.
Esta conciliacion se usa cuando se extraen, ordenan y mezclan filas de datos.
Cantidad de Dominios
Se cuenta la cantidad de registros para cada dominio (o valor) unico en el campo de
entrada, y por otro lado se cuenta la cantidad de registros para el mismo dominio
en la salida del proceso ETL. La complicacion 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
dimension. 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 tambien 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 conciliacion. 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 debera
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 verificar los totales.
La conciliacion de datos, al igual que la limpieza son actividades que tienden a estar
ausentes en el proceso ETL. La organizacion desaprovecha la oportunidad de poner
orden en el caos de los datos y continuan desplazando los datos desde las fuentes al
DataWarehouse tal cual estan. Su unico objetivo es que la estructura receptora de los
datos no los rechace por razones tecnicas como claves duplicadas, o tipos y longitudes
que no coincidan.
Sin embargo, la gente de negocios espera calidad y consistencia en los datos, y es-
to se logra aplicando todas las transformaciones necesarias y realizando los chequeos
correspondientes.
Donde se guardan los datos que se estan migrando?

Las actividades de ordenar, mezclar, y transformar los datos requieren un espacio de al-
macenamiento temporal para guardar los resultados intermedios. Estos archivos y tablas
temporales pueden llegar a ser mas grandes que el almacenamiento de origen. La alter-
nativa general es ir guardando estos datos directamente en tablas del DataWarehouse.
3.4.3. Cargar los datos

El paso final en el proceso ETL es la carga de los datos en el DataWarehouse. Este
proceso se puede aplicar de dos maneras: podemos insertar filas nuevas en las tablas
mediante codigo escrito a medida, o hacer una carga masiva usando alguna herramienta
de importacion del DBMS. Este ultimo enfoque es el mas eficiente y el mas usado en la
mayora de las organizaciones.
Una vez completados los pasos de extraccion y transformacion, no debera 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:
Integridad Referencial: Debido al gran volumen de los datos, en ocasiones se

desactiva esta opcion 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 volvera corrupto en pocos meses o quiza en semanas.
La razon 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, quiza las relaciones existentes no
esten bien definidas o sean nulas, o quiza 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 violacion de integridad entre datos relacionados.
Indices: Las bases de datos con performance pobre frecuentemente son la con-
secuencia de un esquema pobre de indices. Es necesario definir indices en forma
eficiente, y en gran cantidad, debido al gran volumen de datos en el DataWare-
house.
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 mas complicado de disenar y desarrollar en este tipo
de proyectos. La mayora de las organizaciones prefieren usar una herramienta para todo
o parte de este proceso, especialmente para la extraccion y transformacion.
Cuando se usa una herramienta ETL, las especificaciones correspondientes a las trans-
formaciones se traducen a instrucciones para la herramienta.
Algunos de los pasos a seguir durante la evaluacion son:
1. Realizar un analisis costo-beneficio para ver si conviene comprar la licencia de un

producto ETL o desarrollarlo desde cero. Aunque ambas opciones son costosas, la
primer eleccion debera 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 ultimos -no la palabra del promotor- sean los que conduzcan la
evaluacion.
Evaluar cada producto objetivamente, e incluir las reglas de negocios que permiten
la limpieza de los datos como parte del criterio de seleccion. Por ejemplo, algunas
herramientas no pueden leer archivos planos ni realizar transformaciones muy com-
plejas. Si necesitamos estas capacidades debemos conocer las limitaciones de cada
herramienta porque tendremos que adquirir licencias adicionales o incrementar su
funcionalidad con codigo propio.
La reputacion y responsabilidad de los vendedores son tan importantes como las
caractersticas de los productos, as que es conveniente tener en cuenta este factor

tambien.
3. Si es posible contactarse con organizaciones que ya esten usando el producto.
4. Reducir la lista a dos o tres productos candidatos, para no perder tanto tiempo en
la comparacion y la eleccion definitiva.
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 fisuras antes de usar el producto en produccion.
Captulo 4
Implementar una Herramienta

OLAP
Una vez que contamos con la fuente de datos completamente organizada, el siguiente
paso es poner atencion sobre las opciones disponibles para la implementacion de una
herramienta concreta.
Conceptualmente, la arquitectura de una herramienta OLAP consiste de tres com-
ponentes funcionales: Servicios de Presentacion, Servicios OLAP, y Servicios de Bases
de datos.
Servicios de Presentacion
La gente que va a usar la informacion multidimensional son analistas de negocios,
gerentes, ejecutivos, no tecnicos. Por lo tanto, los datos tienen que aparecer en un formato
que les permita a sus usuarios desarrollar propuestas, definir niveles de inversion, y
establecer metas.
Los servicios de presentacion tienen que ser faciles de usar, y la facilidad de uso
tiene que estar determinada por sus usuarios, y no por el equipo tecnico. Por ejemplo,
los analistas de negocios prefieren una interface grafica sumamente intuitiva y poder
trabajar con terminos 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 debera
poder expresar en terminos cuantificables, como por ejemplo cuanto tiempo se necesita
para aprender a usarla, cuan rapido se puede hacer un analisis, cuan comodos estan los
usuarios con la herramienta, si cumple con toda la funcionalidad requerida, y en que
medida es integrable a otras herramientas, como MS Excel por ejemplo.
Los servicios de presentacion tienen que ser flexibles y adaptables al cambio porque
los distintos usuarios tienen preferencias y skills diferentes. Por ejemplo, algunos pre-
fieren los reportes tabulares, y otros los graficos y charts. Los menus, iconos y funciones
tienen que estar configurados segun el perfil del usuario, y poder reconfigurarse segun sea
necesario. Los usuarios expertos esperan una mayor performance y respuestas rapidas,
56
CAPITULO 4. IMPLEMENTAR UNA HERRAMIENTA OLAP 57
as que la presentacion debera consistir en una pantalla menos cargada. Una herramien-
ta ideal debe poder ajustarse a las distintas preferencias y brindar diferentes niveles de
presentacion.
Servicios OLAP
Las consultas, los reportes y el analisis de datos son actividades muy relacionadas,
interactivas e iterativas. Por ejemplo, podemos ver los resultados de una consulta en
forma de grilla, chart o grafico, 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 analisis.
No es practico 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 transicion realizada por la misma herramienta, no por el usuario.
Servicios de Base de datos

Como se menciono anteriormente, la arquitectura OLAP soporta dos tipos de base
de datos, las relacionales y las bases de datos multidimensionales propias de cada he-
rramienta en particular.
Las herramientas ROLAP pueden acceder a cualquiera de las conocidas bases rela-
cionales, como DB2, Oracle y MS SQL Server, mientras que el diseno subyacente sea
multidimensional, como un esquema estrella o snowflake.
Las herramientas MOLAP estan disenadas 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 mas reciente de una serie de concursos realizados por Nigel Pendse, consultor
y conferencista de OLAP, y www.survey.com, una compana que ha realizado cientos
de examenes y encuestas concernientes a la tecnologa de la informacion, entre otras
areas. Este concurso tiene como objetivo evaluar las herramientas OLAP mas contun-
dentes en el mercado. De los 42 productos presentados, solo 11 tuvieron suficiente uso
como para ser incluidos en el reporte de resultados. Estas herramientas son Applix
TM1, BusinessObjects, Cognos PowerPlay, Hyperion Essbase, MIS Alea, Mi-
croStrategy, 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 mas informacion sobre las distintas herramientas son:
http://www.applix.com/solutions/
http://www.businessobjects.com/products/default.asp
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 interes sobre el OLAP Survey y OLAP en general son:
www.survey.com/olap
www.olapreport.com
Para comprender mas profundamente el manejo y uso de los datos multidimensionales

es conveniente indagar en el uso de una herramienta en particular. En la siguiente seccion
profundizaremos en la herramienta Microsoft Analysis Services.
4.1. Microsoft SQL Server Analysis Services

Microsoft reconocio la importancia de proveer un mejor sistema de base de datos
para hacer DataWarehousing, y tambien proveer las herramientas necesarias para que el
analisis de datos sea un proceso mas facil y placentero. En principio lanzo al mercado
Microsoft SQL Server 7 OLAP Services, luego mejoro esta solucion con la nueva version
SQL Server 2000 Analysis Services. En esta seccion veremos el uso de esta he-
rramienta y sus principales caractersticas, y conoceremos las mejoras incorporadas en
la ultima version, 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 Analisis Services, aunque cualquier otra base de datos
que provea conectividad a traves 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 snowflake 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 recoleccion y transfe-
rencia 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 ademas tareas de validacion, limpieza, consolidacion, y transformacion
de los datos cuando es necesario.
Un objeto basico, llamado paquete, almacena la informacion 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 definen un flujo de trabajo del proceso. Los com-
ponentes del paquete DTS se pueden definir 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 creacion de un paquete podemos construir las trasformaciones a partir
de tareas predefinidas 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 codigo
externo escrito en cualquier lenguaje que soporte OLE, como Visual Basic,
Visual C++, y Delphi entre otros.
Un Asistente de Importacion/Exportacion con la misma funcionalidad del DTS
Designer, que gua al usuario en la creacion y ejecucion de paquetes DTS
para exportar e importar datos entre dos datasources que cumplan OLE DB.
El asistente tambien permite realizar transformaciones a los datos durante el
proceso.
Un DTS Query Designer, cuya funcion es construir consultas DTS.
Una interface de programacion COM y un conjunto de interfaces OLE que
permiten la creacion de aplicaciones propias para importar/exportar y trans-
formar. Los programas que usan estas interfaces van desde simples scripts en
Visual Basic o JScript hasta complejas aplicaciones C++.
Esta caracterstica es especialmente importante en la construccion de un
Datawarehouse, donde las transformaciones de datos se vuelven bastante com-
plejas debido a que los datos tienen que coincidir con un esquema diferente
del operacional, y ser sometidos a agregaciones y validacion. Con la flexibi-
lidad que brindan las interfaces COM, todos estos requerimientos se pueden
satisfacer sin problemas.
Entonces, podemos definir las actividades de transformacion de datos usando el

asistente de importacion/exportacion de datos para modificar 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 metodo mas facil, pero si el
mas flexible dado que se dispone del poder del lenguaje de programacion usado.
Almacenamiento
Las posibilidades de almacenamiento incluyen al DataWarehouse (o datamarts en
el caso de que existan) y las bases de datos OLAP. Tambien se incluyen bases rela-
cionales usadas para almacenar tablas con datos totalizados por Analysis Services
durante la construccion de cubos OLAP.
Los modos de almacenamiento posibles en Analysis Services incluyen archivos mul-

tidimensionales (MOLAP), bases de datos relacionales (ROLAP), o un almace-
namiento hbrido (HOLAP).
Dado que MOLAP requiere copiar todos los datos y convertirlos a su propio for-
mato 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 ultimas tablas son llamadas vistas materializadas, y se
crean de acuerdo a las dimensiones cuando se procesa el cubo.
Con esta opcion, las tablas de agregacion tienen columnas para cada dimension
y cada medida. Cada columna de dimension esta indexada, y tambien se crea
un ndice compuesto con todas las columnas de dimension. 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 multidimensio-
nal. 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 multidi-
mensional. Una desventaja de esta opcion es que la cantidad de procesamiento
entre los sistemas ROLAP y MOLAP puede afectar su eficiencia.
Analysis Server
El Analysis Server es el corazon de Microsoft Analysis Services, y sirve para extraer
datos de fuentes heterogeneas, analizar datos multidimensionales, crear cubos de
datos, construir las agregaciones, y conectar el cliente a los datasources. Tambien
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 Office, en especial MS Excel y MS Access, permitiendo
que estas herramientas accedan a los cubos a traves del PivotTable Service. Esto
constituye una gran ventaja para usuarios que esten 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 analisis
online y offline de los datos OLAP, y tambien la construccion de cubos. El analisis
offline es posible gracias al manejo de cache de este servicio, que permite que los
usuarios descarguen datos de fuentes multidimensionales o relacionales y las usen
en modo offline en cubos locales. Tambien brinda una interface COM para que
otras aplicaciones cliente accedan al Analysis Server, los datos OLAP y la cache
del cliente.
Veamos la utilidad de la cache con un ejemplo. Supongamos que el usuario so-

licita los datos sobre ventas de Enero, Febrero y Marzo de 2004. Estos datos son
obtenidos por el PivotTable Service mediante el Analysis Server. Supongamos aho-
ra que el usuario hace una segunda consulta solicitando las ventas del primer
trimestre del ano 2004. En este caso, no es necesaria una nueva consulta al Ana-
lysis Server por parte del PivotTable, ya que este tiene la capacidad de realizar
los calculos necesarios, y ademas tiene los datos base para realizar los mismos en
cache, previamente almacenados en la consulta anterior.
Microsoft Analysis Services es una herramienta que cuenta con varios asistentes, edi-
tores y material de ayuda en cada paso. Las herramientas principales de administracion
con las que cuenta son el Analysis Manager y el Enterprise Manager (Administrador
Corporativo) de SQL Server.
Analysis Manager
Es una interface grafica (GUI) que permite que el usuario construya una solucion
OLAP basandose en datasources existentes. Esta interface permite una comoda ad-
ministracion 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.
Tambien permite administrar la seguridad de los cubos tal que podamos garantizar
el acceso autorizado a los datos correspondientes.
Cuenta ademas con Asistentes de analisis de uso y de optimizacion basada en el
uso.
Administrador Corporativo
El DataWarehouse es una base de datos SQL Server y el Administrador Corpo-
rativo es la herramienta que nos permite mantenerlo. Ademas 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 ayudara a aclarar algunas cuestiones
involucradas con la creacion del repositorio de datos o Datawarehouse, y luego un ejemplo
de la construccion y analisis de un cubo de datos.
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 figura vemos un diagrama
de la estructura de esta base de datos que llamaremos OLTP.
El esquema Estrella disenado 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
dimension llamadas Customers, Products, Time y Geography.
Ya tenemos establecidas las bases de datos fuente y destino para la migracion de los
datos. Lo que necesitamos ahora es disenar un paquete DTS que realize la transformacion
y migracion. Para esto debemos iniciar el editor de paquetes de Microsoft Analysis Ser-
vices seleccionando el nodo Data Transformation Services y eligiendo la opcion
New Package en el menu contextual.
Primero vamos a considerar la migracion de los datos que van a conformar las di-
mensiones. Debemos insertar en el paquete cuatro tareas de trasformacion, o Transform
Data Task, cada una con sus respectivas fuentes y destinos, los cuales estan constituidos
por objetos llamados Connection. En principio tendramos lo siguiente:
Los objetos connection llamados OLTP representan la misma conexion a la base con
el mismo nombre. Cuando arrastramos el primero de ellos al area de diseno creamos la
conexion 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 conexion existente.

De la misma manera que establecimos la conexion con la base OLTP, establecemos
una usando el objeto DATAWAREHOUSE con la base de datos Datawarehouse, selec-
cionandola en la propiedad Database del objeto.
El siguiente paso consiste en configurar la carga de los datos que van a conformar la
dimension de clientes. Para esto debemos seleccionar una de las Transform Data Task que
enlazan alguna de las conexiones OLTP a la conexion 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 construccion o carga de la dimension de tiempo es similar al proceso seguido en

la carga de la dimension de clientes. Tomamos una segunda Transform Data Task, y
establecemos la siguiente consulta SQL como origen de la tarea:
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 proximo paso consiste en tomar la tercer Transform Data Task libre y estable-
cer sus propiedades para efectuar la carga de la dimension de zonas geograficas. Como
destino definimos la Tabla Geography del DataWarehouse, y la consulta que usaremos
como origen de la transformacion en este caso sera:
Ahora debemos crear la dimension que nos falta, la dimension de Productos. La

creacion de esta dimension 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 definir el origen
de los datos:
Luego, en la solapa Transformations del cuadro de dialogo de Propiedades,

creamos una nueva trasformacion usando el boton New , en particular un ActiveX
Script. Un cuadro de dialogo nos permite configurar, entre otras cosas, el lenguaje del
script, las columnas que incluye, y las funciones que se les aplican. En este caso selec-
cionamos todas las columnas en ambas tablas, fuente y destino, y como lenguaje optamos
por VB Script. El codigo del script transforma los ProductNames y BrandDescrip-

tions a nombres en mayuscula:
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 conexion a OLTP
y una conexion a la base de datos Datawarehouse para configurar la carga de la tabla
de hechos. El esquema del paquete DTS se vera ahora como en la figura:
El enlace que conecta los dos grupos de tareas es un objeto On Success Workflow,
y esta 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 configurar la carga. Como
destino establecemos la tabla Ventas del Datawarehouse, y como origen definimos
la siguiente consulta SQL:
Ahora el paquete esta listo para ejecutarse, y su ejecucion llenara el DataWarehouse

con la informacion del sistema OLTP.
Captura o extraccion de datos de las bases operacionales
Vimos en captulos anteriores que la actualizacion del Datawarehouse una vez que
fue cargado por primera vez se puede realizar de varias maneras.
La extraccion simple de datos de las fuentes nos brinda una fotografa estatica de
la informacion en un punto especfico en el tiempo. Esta tecnica 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 ano actual y archivar los datos
del ano anterior en otro medio fsico. Otras tecnicas mas sofisticadas para extraer datos
incluyen la captura de logs de DBMS, captura basada en triggers, captura asistida por
aplicaciones, captura por timestamp, y la comparacion de archivos.
Con la tecnica de Captura de logs DBMS los datos a extraer se determinan a partir
del sistema de logs del DBMS. La ventaja de esta tecnica es el mnimo impacto que la
extraccion tiene sobre la base de datos operacional y los sistemas que acceden a ella,
pero requiere que el DBMS soporte logging, y tambien un claro entendimiento sobre
el formato de los registros de log. Este metodo no es posible en SQL Server porque el
formato de los archivos de log generados por el SQL Profiler son internos a SQL Server,
y no es facil leerlos fuera de esta herramienta.
La mayora de los sistemas de administracion de bases de datos soportan stored
procedures y triggers. La Captura basada en triggers utiliza el hecho de que estos
ultimos pueden ejecutar consultas SQL o aplicaciones complejas cuando ocurren ciertos
eventos en la base de datos, en particular, cuando se insertan nuevos registros, o se

actualizan o eliminan registros existentes.
Tambien podemos usar programas escritos a medida para la extraccion de datos,
que incluyan la logica para capturarlos. Las tecnologas de abstraccion de datos provistas
por Microsoft, como OLE DB y ADO permiten acceder a una amplia variedad de fuentes
de datos.
Las tecnicas 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
tecnicas en general requieren alguna otra facilidad para la carga inicial de los datos.
La Captura basada en timestamp es una tecnica simple que consiste en chequear
un valor timestamp para determinar si el registro cambio desde la ultima captura.
La Comparacion de archivos no es una tecnica muy eficiente, pero si facil de entender
y de implementar. La idea es guardar en un archivo una fotografa de los datos de origen
en el momento de la extraccion de los datos, y compararlo con un archivo previo generado
en la extraccion anterior. Cualquier cambio y/o adicion que se detecte se guarda en un
archivo separado para cargarlo al DataWarehouse.
Estas dos ultimas tecnicas tambien nos permiten mantener una continuidad de los
datos, sin embargo, quiza 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 sera 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 ultimo de los producidos
en el intervalo.
Es necesario tener en cuenta todas estas tecnicas durante la planificacion de la captura
de los datos. En general, el mejor escenario de uso para la extraccion simple es la carga
inicial del DataWarehouse, y el resto de las tecnicas se utilizan en la carga incremental
del mismo. Si queremos mantener una historia de cambios continua en el tiempo es
conveniente usar las tecnicas de Captura de logs, Captura basada en triggers y la Captura
asistida por aplicaciones. Las tecnicas de Captura por timestamp y comparacion de
archivos, como dijimos, nos brindan una historia de cambios por periodos.
El proceso de transformacion puede requerir procesar varias veces los datos extrados,
ya que los mismos valores que se usan como medidas en una tabla de hechos, quiza
tambien se requieran en el calculo de agregaciones.
Mantenimiento del Datawarehouse
Algunas de las cuestiones que deben tenerse en cuenta en una planificacion de man-
tenimiento del DataWarehouse se detallan a continuacion:
Plan de seguridad
La seguridad en SQL Server se expande al DataWarehouse y a los cubos OLAP.
Analysis Services provee seguridad a traves de los roles que se definen a nivel cubo.
Estos roles estan altamente integrados con los usuarios y los grupos de usuarios
del sistema operativo. El proposito de un plan de seguridad es establecer cuales
usuarios pueden ver los datos, cuales datos, y que actividades pueden realizar.
SQL Server provee un modelo sofisticado de seguridad que si es bien usado pre-
viene de accesos no deseados a los datos y objetos de las bases de datos. Este
modelo de seguridad permite dos modos de autenticacion, autenticacion Windows
o autenticacion mixta (SQL Server y Windows).
Backup y Recupero del DataWarehouse

Estas actividades permiten la restauracion completa de los datos luego de una
falla en un medio fsico, danos causados por usuarios u aplicaciones, o cadas del
servidor. Ademas de ser util en estas situaciones, hacer backups y restauraciones
de una base de datos es util tambien si queremos moverla o copiarla de un servidor
a otro de manera facil y rapida.
Auditora
La auditora permite reconocer todas las actividades que ocurrieron en la base de
datos y quien realizo estas acciones. La auditora en SQL Server se implementa
como parte de la seguridad.
Recoleccion de datos estadsticos

Es importante monitorear la forma en que los usuarios usan el DataWarehouse y
las herramientas OLAP. Conocer cuales consultas se realizan en un cubo particular
y en que frecuencia, nos permite modificarlo para que estas consultas se ejecuten
mas eficientemente. Algunos valores interesantes para monitorear son la cantidad
promedio y maxima de consultas contra cierta tabla de hechos, la cantidad prome-
dio y maxima de filas retornadas por consulta, la cantidad promedio y maxima de
tiempo de ejecucion de las consultas.
Archivar datos
Como el DataWarehouse recibe mas y mas datos de las fuentes operacionales, su
tamano 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 ano 2003 y 2004 respectivamente. Ademas, las tablas de hechos
que ya tienen varios anos y no se usan casi nunca deberan archivarse fuera de la
base de datos para poder reusar ese espacio.
4.1.2. Crear un Cubo y sus dimensiones

En esta seccion veremos como crear y analizar un cubo multidimensional con Mi-
crosoft Analysis Services. Disenaremos las dimensiones, las medidas, estableceremos la
fuente de datos y disenaremos su almacenamiento. Una vez creado el cubo podremos
procesarlo, y por ultimo veremos la funcionalidad basica de la herramienta para analizar
y manipular los datos en el cubo.
La creacion 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 jerarquica, 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 automaticamente de la instalacion de MS SQL Server
2000, por defecto el nombre de la maquina.
Crear una base de datos OLAP

Antes de disenar un cubo, es necesario establecer una base de datos, mas especfi-
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 comun
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 menu contextual. Le
damos el nombre EjemploOLAP, y opcionalmente podemos darle una descripcion. Una
vez agregada, EjemploOLAP aparece en la estructura de arbol, e incluye una serie de
subcarpetas predefinidas, por ahora vacas, para almacenar los objetos como cubos y
dimensiones que se generen.
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 asociacion expandimos el nodo EjemploOLAP, seleccionamos la
carpeta Orgenes de datos y elegimos Nuevo Origen de datos en el menu contextual.
Ahora estamos en condiciones de establecer una serie de parametros 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 snowflake que se instala
como ejemplo junto con Analysis Services. Como es una base de datos Access selec-
cionamos Microsoft Jet 4.0 OLE DB Provider en el tab Provider.
Para establecer una conexion, seteamos los parametros correspondientes en el tab
Connection del cuadro de dialogo. En este caso seleccionamos la base de datos
FoodMart2000.mdb.
El boton Test Connection permite testear la conexion 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 valido.
Disenar un cubo
El diseno de un cubo primero exige determinar que 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 analisis de la per-
formance de la organizacion. Otro elemento que se debe determinar son las dimensiones,
es decir, las perspectivas o vistas en las que las medidas tienen relevancia y significado.
Una dimension que siempre es util es la que representa el tiempo.
Para crear un cubo Analysis Services provee un asistente que nos gua en la seleccion
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 menu contextual.
El primer paso consiste en seleccionar una tabla de hechos del data source Food-
Mart2000. Un cubo puede tener mas de una tabla de hechos, aunque para simplificar
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.
En el panel derecho se detallan las columnas de la tabla seleccionada. El boton

Examinar datos... permite una vista previa de los datos de la tabla.
El paso siguiente consiste en seleccionar las columnas numericas que actuaran como
medidas, es decir, las columnas sobre las que se realizaran las agregaciones. De la lista de
columnas numericas pertenecientes a la tabla sales_fact_1998 elegimos las colum-
nas store_sales, store_cost, y unit_sales. Mediante el Editor de Cubos, a
cada una de estas columnas se les puede aplicar una funcion de agregacion 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 analogas a una clausula GROUP BY de SQL, ya que los datos de
un cubo OLAP estan organizados, o agrupados, en dimensiones. Analysis Services maneja
varios tipos de dimensiones con distintas caractersticas. Para crear una dimension ini-
ciamos el Asistente para Dimensiones mediante el boton 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 multiples cubos. En lugar de
construir varias dimensiones para el mismo tipo de informacion, usamos solo una,
ahorrando tiempo de desarrollo y de procesamiento. En la carpeta Dimensiones
Compartidas podemos encontrar todas las dimensiones definidas 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 automaticamente cuando se procesa el cubo,lo que
implica reprocesarlo si se modifican la estructura o los datos de alguna de estas
dimensiones.
Dimensiones Virtuales
Las dimensiones virtuales dependen de las propiedades de los miembros de una
dimension existente. Por ejemplo, dada una dimension Sucursal, una de las
posibles propiedades de los miembros podra ser TipoSucursal, con los valores
mayorista y minorista. Al construir una dimension virtual sobre esta propiedad,
los usuarios finales pueden agrupar la informacion no solo por las dimensiones, sino
tambien por los atributos de las dimensiones. En este caso, pueden organizar los
datos segun las sucursales y tambien segun sucursales mayoristas y minoristas.
Dimensiones Parent-Child o Primario-Secundario

Este tipo de dimensiones nos permiten reflejar ciertas estructuras jerarquicas del
mundo real en las que un miembro juega mas de un rol. Veamos como ejemplo la
tabla de dimension 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.
Reflejar esta situacion mediante una dimension comun requerira conversiones, ya

que la estructura es desbalanceada y esta caracterstica no esta soportada por
una dimension comun. Para crear una dimension de tipo parent-child se definen
la columna clave que identifica cada miembro y una columna parent. La relacion
entre ambas columnas define la jerarqua de la dimension.
Dimensiones con varias jerarquas

En Microsoft Analysis Services se pueden definir jerarquas multiples en terminos
del nombre de la dimension de la que son parte introduciendo un punto que separe
el nombre de la dimension del nombre de la jerarqua.
Por ejemplo, para crear dos jerarquas para la dimension Tiempo, una para el
periodo fiscal y otra para el perodo calendario, creamos dos dimensiones con los
nombres Tiempo.Fiscal y Tiempo.Calendario respectivamente.
Las jerarquas multiples se tratan como dimensiones separadas en Analysis Ser-
vices. Un efecto colateral indeseable es que se van a crear agregaciones entre las
dos dimensiones que representan las jerarquas, las cuales usualmente resultan in-
significativas y solo consumen espacio de disco y tiempo de procesamiento.
En este ejemplo vamos a crear dimensiones compartidas. En primer lugar crearemos

una dimension a partir de un esquema estrella, donde como sabemos existe una sola tabla
para cada dimension. Luego crearemos una dimension a partir de un esquema snowflake,
donde una dimension esta representada en varias tablas.
El primer paso en la creacion de una dimension consiste en seleccionar como queremos
crearla. Para crear una dimension a partir de un esquema estrella seleccionamos la primer
opcion.
El siguiente paso consiste en seleccionar la tabla de dimension correspondiente. De

la lista de tablas pertenecientes al datasource elegido seleccionamos la tabla Region.
El paso siguiente consiste en seleccionar los niveles posibles para la dimension, si

es que existen. A partir de las columnas disponibles de la tabla de dimensiones selec-
cionamos sales_country, sales_region, sales_state_province, sales_
district y sales_city como niveles de la dimension, en ese orden. El ordenamiento
es acorde al grado de detalle en cada nivel.
El asistente nos previene si intentamos establecer un ordenamiento que podra no

resultar logico, como por ejemplo poner el nivel de distritos(Sales District) por
encima del de las provincias(Sales State Province).
El siguiente paso es especificar los miembros de la dimension. Debemos definir 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.
En el Editor de Cubos se pueden definir las member name columns o columnas de nom-
bre de los miembros, que contienen los nombres para los miembros de un nivel, aunque
en general esta informacion esta dada por la misma columna clave.
Una vez que definimos toda la informacion necesaria para crear la dimension, el
asistente presenta una vista previa en la que podemos ver la estructura de arbol con los
miembros en los respectivos niveles de la jerarqua.
Cuando creamos una dimension se crea un nivel adicional ademas de los que especifi-
camos. 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 dimension. Podemos deshabilitarlo usando el Editor de Dimensiones.
Ahora retornemos a la creacion del cubo en el Asistente para Cubos, donde podemos
observar que Region ya aparece en la lista de dimensiones del cubo.
Ahora vamos a crear una dimension llamada Products, a partir de un esquema

Snowflake. Los pasos basicamente son los mismos que en la creacion de la dimension
Region, pero en el dialogo donde antes seleccionamos la opcion esquema Estrella,
ahora seleccionamos esquema Snowflake(o copo de nieve).
En la seleccion de tablas de dimension elegimos las tablas product y product_class.
Recordemos que en el esquema snowflake una dimension involucra a mas de una tabla.
El paso siguiente consiste en crear y editar las relaciones entre las tablas seleccionadas
para componer la dimension 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 estan relacionadas
mediante la columna product_class_id.
Luego, de la misma manera que con la dimension 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 dimension de tiempo. Ini-
cialmente debemos crear la dimension con el esquema estrella, y seleccionar la tabla
time_by_day como la tabla de dimension.
En este ejemplo el datasource ya contiene una tabla de dimension de tiempo, aunque
en general la dimension de tiempo se deriva de una columna en la tabla de hechos. En
el ejemplo, la tabla time_by_day esta 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 opcion de crear una dimension estandar o una dimension de tiempo.
Optamos por la segunda opcion, y establecemos que la columna que se usa para definir
la dimension es the_date, en este caso, la unica columna de tipo datetime en la
tabla Time_by_day.
Ahora debemos considerar los niveles de la dimension. El asistente presenta por
defecto las niveles mas comunes, como ano-cuatrimestre-mes-da, ano-cuatrimestre-mes-
da-hora-minuto, ano-trimestre-mes, etc. Ademas permite establecer una fecha de inicio
del ano distinta al 1 de enero. Esto es particularmente util para reflejar periodos contables
o fiscales. La configuracion para nuestra dimension de tiempo es la siguiente:
En este punto tenemos el modelo definido: establecimos un conjunto de dimensiones

con sus niveles, y tambien las medidas y las tablas de hechos en las que residen.
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 dimension.
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 detecto la relacion entre la tabla de hechos sales_

fact_1998 y la tabla de dimension Region. Agregar una relacion es muy simple bajo
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 definir y usar un puente o tabla intermedia que complete esta asociacion
logica. Agregamos la tabla store, y relacionamos las tablas region y store me-
diante la columna region_id, y las tablas store y sales_fact_1998 mediante la
columna store_id.
El siguiente paso consiste en disenar el almacenamiento para el cubo. Por definicion,

los cubos OLAP constituyen un mecanismo de almacenamiento para agregaciones pre-
calculadas, las cuales conducen a una performance mas rapida en las consultas. El diseno
del almacenamiento consiste en establecer las caractersticas de estas agregaciones, las
cuales se construyen durante el procesamiento del cubo.
Para realizar esta tarea de diseno, Analysis Services provee un Asistente de Almace-
namiento.
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 agregacion para el cubo. Podemos

establecer la restriccion 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 opcion implica un tradeoff 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 boton Iniciar podemos
observar un grafico que previsualiza los posibles resultados de la opcion seleccionada.
En este ejemplo establecimos que la performance tiene que permanecer por encima
del 80 %. Al observar el grafico 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
opcion Proceso Completo.
Durante el procesamiento se cargan los datos desde el datasource designado y se

generan las totalizaciones definidas en las opciones de agregacion. La ventana de Proceso
nos permite monitorear esta actividad.
Ademas de la opcion de procesamiento completo del cubo, Analysis Services brinda

las opciones de Actualizacion Incremental y Actualizacion de datos.
La Actualizacion Incremental permite procesar los datos que se agregaron ultimamente
en la tabla de hechos, determinando cuales son mediante algun criterio en una clausula
WHERE. Si la actualizacion no especifica ningun criterio o filtro, se actualizara con la
tabla de hechos completa y se agregaran datos ya existentes, originando informacion
duplicada.
La Actualizacion de Datos se usa cuando no se hizo ningun cambio a la estructura del
cubo, y simplemente se quiere refrescar la informacion existente. Esta opcion es la mas
comoda cuando reprocesamos un cubo no muy grande y no estamos seguros de que se
hayan agregado nuevos datos.
La opcion que usamos, Proceso Completo, es la que se requiere cuando se cambia la
estructura del cubo, ya que lo reconstruye completamente.
Existe ademas una opcion Actualizar de forma incremental las dimen-
siones compartidas utilizadas en este cubo. Esto refleja 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.
4.1.3. Analizar y manipular el Cubo

Luego del procesamiento del cubo, los datos ya estan listos para analizar. Para esto
vamos a utilizar el Cube Browser incluido en Analysis Services. Esta herramienta permite
filtrar los datos segun 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 menu contextual.
Inicialmente el Browser nos muestra los datos correspondientes a las tres medidas,
store_sales, store_cost y unit_sales, organizados en una sola dimension,
Products. En el panel superior estan las otras dos dimensiones, Region y Time.
Podemos cambiar las posiciones de las dimensiones. Podemos analizar las medidas
organizadas por region reemplazando la dimension Products por la dimension Region.
Este reemplazo se realiza simplemente arrastrando la dimension Region y soltandola
encima de la columna que ocupa la dimension Products.
Si observamos la dimension Time vemos que esta establecida en el miembro Todos

Time, es decir, las medidas que estamos observando valen para todas las fechas sin filtro
alguno. Por defecto las dimensiones se establecen inicialmente en el maximo nivel, es
decir, el mas resumido.
El nivel establecido para las dimensiones en el panel superior esta siempre visible
para mantener la orientacion constante sobre los datos que se estan presentando.
Si luego queremos analizar las medidas desde una perspectiva del producto pero
manteniendo la clasificacion por la dimension Region, debemos arrastrar la dimension
Products y soltarla en cualquier lugar de la grilla. Esta accion provoca que la dimension
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 segun los
miembros de la dimension Products. Se mantiene la columna Todos Products, que
actua como una columna de totales.
Veamos algunos ejemplos de operaciones tpicas en el analisis OLAP.

Una operacion de tipo Slice & Dice permite establecer un filtro en los datos, selec-
cionando un miembro de alguna dimension en particular. Para seleccionar un miembro
de la dimension Time por ejemplo expandimos el combo para visualizar la jerarqua de
la dimension y seleccionamos, por ejemplo, el miembro Trimestre 3 perteneciente al
miembro 1998 para ver la informacion del tercer trimestre del ano 1998.
Automaticamente las medidas en la grilla se reajustan para reflejar solo los valores
que pertenezcan al periodo de tiempo filtrado.
Una operacion DrillDown, como sabemos, permite ver datos mas detallados. Para
detallar las medidas un nivel mas en la dimension Products basta con hacer doble clic
en la celda Product_Category para expandirla. Como resultado de esta operacion,
ademas de los datos detallados se crea una nueva celda Product_Subcategory que
sirve para indicar el nivel actual de la dimension.
Una operacion DrillUp nos muestra datos mas resumidos. Si queremos volver atras la
operacion DrillDown anterior sobre la dimension Products debemos hacer doble click
en la celda Product_Subcategory recientemente expandida.
Estas operaciones se pueden aplicar en forma combinada y en los niveles que sean
convenientes. Por ejemplo, podramos hacer DrillDown en la dimension Region para
analizar las ventas y costos por pases, provincias, distritos, o ciudades, hasta alcanzar
el nivel de detalle que resulte mas significativo al analisis.
4.1.4. Caractersticas avanzadas en Microsoft Analysis Services

Ahora que hemos visto como crear un conjunto basico de cubos y dimensiones, ve-
remos algunos conceptos mas avanzados, como:
Miembros de dimensiones calculados en base a formulas
Medidas calculadas
Cubos Virtuales y Cubos Enlazados
Particiones
Miembros calculados
Los miembros calculados son miembros cuyos valores se definen a traves de una
formula y en general estan basados en otros miembros de la dimension. Un ejemplo
de miembro calculado es uno que calcule el presupuesto del ano actual segun los
gastos, tal que el presupuesto sea un 20 por ciento mayor que los gastos actuales.
Si contamos con una dimension cuyos miembros representan los distintos tipos
de presupuestos, entre ellos, el miembro Current Years Actuals representa
el monto realmente destinado para el ano 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 dimension debe tener la propiedad Writeback activa para poder crear un
miembro calculado en ella. Esta propiedad permite que cualquier modificacion en
un miembro vuelva directamente a la tabla de dimension de origen.
La formula que define el valor del miembro agregado es la siguiente:
[Scenario].[Current Years Actuals]*1.2
Esta formula esta 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 basica y formato, pero tiene algunas caractersticas
adicionales creadas para manipular este tipo de bases de datos.
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 carac-
terstica 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 define a
esta medida es:
[Measures].[Store_Sales]-[Measures].[Store_Cost]
Celdas calculadas
Las celdas calculadas son similares a las medidas calculadas en que estan deter-
minadas por expresiones MDX que se calculan en el momento de la consulta. La
diferencia es que es posible especificar un subconjunto de celdas, o solo una, para
las cuales esta expresion es valida. La forma de determinar el subconjunto de cel-
das tambien se expresa mediante MDX, en terminos de las dimensiones y medidas
existentes.
DrillThrough
Recordemos que la operacion de DrillThrough sobre un cubo multidimensional

implica el acceso a datos que se encuentran en una base de datos relacional. Esta
operacion es util cuando los usuarios quieren conocer los datos detallados que
componen las agregaciones que estan observando.
Hay que tener en cuenta que los cubos OLAP construidos sobre un almacenamien-
to MOLAP pueden operar sin los datos SQL subyacentes una vez que se pro-
ceso el cubo, y ademas en muchos DataWarehouses se quitan los datos detallados
una vez que los cubos han sido procesados. Por todo esto, para que la operacion
DrillThrough funcione, es necesario asegurarse de que los datos detallados que se
usaron para procesar el cubo permanezcan accesibles.
Si los detalles estan disponibles es posible habilitar la opcion DrillThrough u Op-

ciones de obtencion de detalles en el Editor de Cubos, y seleccionar las columnas
correspondientes. Luego, para aplicar la operacion, solo basta con seleccionar una
celda en el Cube Browser y elegir DrillThrough en el menu contextual.
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 dimen-

siones de cubos que compartan el mismo conjunto de dimensiones (cubos enlaza-
dos). Las agregaciones entre distintos cubos estan relacionadas por la dimension
compartida, y si juntamos datos de cubos que no tengan dimensiones en comun
van a continuar separados sin cohesionarse.
Por ejemplo, podemos crear un cubo virtual a partir de un cubo que contenga
informacion sobre los empleados y un cubo de ventas, y a partir de este cubo
virtual los analistas pueden establecer una relacion entre la cantidad de empleados
en una sucursal y el total de ganancias de la misma para un periodo de tiempo
particular, ayudandolos a definir una cantidad promedio optima de empleados por
sucursal.
Particiones
Las particiones representan divisiones logicas de un cubo de datos. Estas divisiones

se originan segun los valores de una dimension particular. Por ejemplo, podemos
particionar un cubo de ventas segun 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 anos.
Las particiones se pueden definir segun cualquier dimension que exista en el cubo,
pero comunmente se crean de acuerdo a periodos de tiempo, usando la dimension
de tiempo.
La particion se puede almacenar en un disco distinto del cubo original. Esto permite
ubicar los datos que no se consultan frecuentemente en un medio de almacenamien-
to mas lento,y dejar las particiones que contienen los datos mas requeridos en los
medios mas rapidos.
Tambien pueden distribuirse y almacenarse bajo distintos Analysis Servers dis-

tribuyendo as la carga de trabajo.
Algunos problemas que se deben evitar cuando se usa esta opcion son la aparicion
de particiones solapadas y particiones incompletas.
Las particiones solapadas llevan a la duplicacion de datos y a agregaciones inco-

rrectas. Por ejemplo, si dada una base de datos de ventas e inventario disenamos las
particiones tal que cada una incluye los datos para un cuatrimestre, pero seguimos
manteniendo una particion para el ano completo. Si ambas tablas usan la misma
tabla de hechos sus valores se contabilizaran dos veces. La solucion a este problema
consiste en descartar la particion para el ano completo, y mezclar las particiones

de cuatrimestres cuando se requieran los datos del ano completo.
El cubrimiento incompleto de un cubo particionado conduce a la aparicion de celdas

vacas donde no deberan estarlo. Las particiones incompletas, como las solapadas,
producen agregaciones erroneas.
4.1.5. Acceder a Microsoft Analysis Services desde codigo

Aunque existe una gran variedad de recursos que permiten facilmente consultar y
presentar datos OLAP usando simples herramientas de usuario, es posible y a veces con-
veniente construir soluciones desarrolladas a medida que incluyan caractersticas OLAP
simples y tambien avanzadas.
En esta seccion veremos los recursos disponibles para acceder y manipular datos
OLAP desde el codigo de un programa. Entre estos recursos vamos a mencionar a ADO
MD, MDX, Office Web Components y DSO.
Office Web Components

Esta librera se introdujo con Office 2000 y se mejoro con Office XP. Esta disponible
desde Visual Basic, Access, Excel, Power Point, y Word, y contiene cinco controles
ActiveX:
Chart: este control muestra los datos resumidos en un grafico tipo chart. Los datos
se pueden obtener desde cualquiera de los controles Spreadsheet, PivotTable,
o DataSource, o puede llenarse desde el codigo.
Spreadsheet: este control brinda una funcionalidad simple tipo Excel en una in-
terface liviana para paginas web.
Data Source: provee una conexion 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 codigo.
Record Navigation: sirve para soportar el enlace de datos.
PivotTable: es un control similar al PivotTable de Excel. Muestra totales por
filas y columnas, y permite operaciones de pivoting arrastrando campos a los
encabezados de filas, 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 informacion 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 dialogo Componentes del menu 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
dimension en particular, o tambien puede usar otras dimensiones como filtro de
los datos. El PivotTable obtiene los datos del cubo usando una consulta MDX.
Como ejemplo agregamos un PivotTable al formulario de la aplicacion Visual Basic,

e incluimos el siguiente codigo en el evento load del formulario:
Si observamos la expresion MDX vemos que en la clausula FROM indica que los
datos se extraen del cubo TrainingSales, y en la clausula SELECT se establece
la dimension Customers para las columnas, y la dimension Course para las filas,
ambas con todos los niveles incluidos.
Podemos usar la lista de campos para agregar campos adicionales al header de

filtros, o intercambiar campos en los headers de columnas y filas. Las operaciones
de DrillDown y DrillUp se aplican expandiendo y colapsando niveles, usando los
nodos (+) y (-) correspondientes a cada miembro de dimension.
Por ejemplo, aqu se muestra el resultado de aplicar un filtro por fecha, en particular
el Trimestre 2, y se expandieron algunos nodos para profundizar el nivel de detalle.
Programando el control Chart:

La programacion de este control es muy similar a la del PivotTable, porque tienen
varias propiedades en comun. Por lo tanto, el ejemplo anterior se aplica al control
chart con un codigo con muy pocas modificaciones:
Como el control puede contener varios charts, hacemos referencia a la coleccion

Charts del objeto, en particular a Charts(0), para establecer las propiedades
de nuestro chart. La coleccion Axes contiene objetos Axis, y en el codigo anterior,

Axes(1) se refiere al eje vertical que muestra las ventas.
Aqu vemos el resultado luego de ejecutar el codigo anterior
ADO MD (ActiveX Data Objects Multidimensional)

La librera ADO MD es la extension de ADO para soportar fuentes de datos
multidimensionales tales como Microsoft SQL Server Analysis Services.
ADO MD provee acceso a traves de codigo 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 expresion SQL,
a un objeto Cellset se le puede asignar una expresion MDX como origen de datos.
Alguna de sus propiedades mas relevantes son:
FilterAxis: retorna informacion sobre las dimensiones que se usan para

filtrar datos en el cubo.
Cells: cada objeto Cell representa un dato en la interseccion de coordenadas
de los ejes.
Axes: cada objeto Axis representa un punto de datos, puede estar asociado
con un nivel o miembro especificado en una expresion MDX.
Veamos entonces el codigo para instanciar un objeto Cellset, e iterar sobre sus
celdas para mostrar sus datos en un control FlexGrid no enlazado. Para usar-
lo debemos agregar una referencia a Microsoft ActiveX Data Objects
(Multi-dimensional) en el proyecto Visual Basic.
Aqu vemos el resultado de ejecutar el codigo anterior
Observemos la definicion del eje de las filas:
strSource = "SELECT Course.Course.Members ON ROWS, "...

Aqu Course.Course.Members se refiere al nivel Course de la dimension

Course. Esto es as porque solo queremos ver los nombres de Cursos en la primer
columna. Supongamos ahora que la definicion para las filas esta determinada por
la siguiente expresion.
strSource = "SELECT Course.Members ON ROWS, "...
Como resultado la primer columna contiene todos los niveles de la dimension

Course, es decir, All Course, Product, Course, y Class Date.
El objeto CubeDef
Este objeto expone informacion de esquema, y se usa para recuperar informacion

sobre las dimensiones a traves de las colecciones Dimensions, Hierarchies y
Levels.
El siguiente ejemplo muestra como obtener los elementos de un cubo a traves

de este objeto. Primero establecemos una conexion, y luego iteramos sobre las
propiedades del cubo para armar su esquema en un formulario Visual Basic.
En conclusion, ADO MD es un modelo de objetos que permite obtener mediante

codigo, 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
codigo como una alternativa al Analysis Manager. Con los objetos DSO es posible
crear, consultar y modificar todos los objetos expuestos en el Analysis Manager, y
mas.
Al igual que ADO MD, DSO expone objetos a traves de COM y se puede programar
en cualquier lenguaje o herramienta que admita este tipo de objetos.
Veamos una representacion del modelo de objetos. El modelo comienza con el

objeto Server que contiene una coleccion Databases. El objeto Database a su vez
contiene objetos Datasources, Cubes y Shared Dimensions.
Para usar el modelo DSO desde un proyecto es necesario establecer una referencia
a la librera DSO, Microsoft Decision Support Objects. Como ejemplo
vemos el codigo 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
dimension Employees con tres niveles, y una medida Salary.
Una vez ejecutado este codigo podemos abrir el Analysis Manager y comprobar
que la base de datos Ejemplo existe, junto con los componentes que definimos.
Como sabemos, crear la base de datos OLAP no es suficiente para llenar la es-
tructura con datos. Para esto es necesario procesar el cubo, pero antes debemos
establecer las opciones de agregacion y de almacenamiento. Estas tareas tambien
se pueden hacer usando DSO, aunque pueden resultar bastante tediosas.
En lugar de construir todo el codigo para crear una base de datos OLAP podemos
usar una utilidad llamada Meta Data Scripter incluida en SQL Server 2000 Re-
source Kit, que toma una base de datos OLAP y genera el codigo DSO en VBScript
para crear todos los objetos correspondientes a dicha base de datos.
4.1.6. Cambios en Microsoft Analysis Services 2005

En esta seccion veremos algunas de las diferencias basicas entre las versiones 2000
y 2005 de Analysis Services, en cuanto a la interface de usuario, la arquitectura, y el
acceso desde codigo.
Cambios en la interface de usuario
Analysis Services 2005 incorpora la funcionalidad de las tres principales herramien-

tas de la version 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
version 2000, y tambien incluye capacidades de diseno de DTS, que en la version ante-
rior se incluan 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 basicas en la creacion y manipulacion de cubos son:
Ya no existe una representacion explcita de los Analysis Servers, y no esta 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 version 2005 encontramos la solucion, que es una coleccion
de uno o mas proyectos. Estos terminos se derivan del entorno de Visual Studio,
debido a su familiaridad entre los desarrolladores de C# o VB.NET. Cuando se
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. Tambien
existen otros tipos de proyectos para representar las funciones DTS.
En la version 2005 los cubos pueden estar basados en varias tablas de hechos de
distinta granularidad. Esta caracterstica se asemeja a los cubos virtuales de la
version 2000.
BI Workbench introduce la tecnologa IntelliCube que automatiza la creacion del

cubo a traves de analisis heursticos 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 util en casos en

los que no se actualizan filas existentes, sino que solo se agregan nuevas.
Cambios en la arquitectura
Analysis Services 2000 soporta una sofisticada mezcla de calculo y cache en ambos
lados, servidor y cliente. Para favorecer la integracion y simplificacion, Analysis Services
2005 soporta calculo y cache unicamente 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
snowflake. 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
podra 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. Ademas, los Data Source
Views permiten trabajar sobre las estructuras del cubo sin estar conectado al datasource,
a diferencia de Analysis Services 2000.
Otra caracterstica que se incluye en la nueva version es el Unified Dimensional
Model (UDM), una funcionalidad que une almacenamientos de datos relacionales y
multidimensionales permitiendo la creacion de un unico modelo dimensional que se aplica
a ambos. Microsoft caracteriza a UDM como la combinacion de lo mejor de lo relacional y
lo multidimensional. Con UDM, los almacenamientos MOLAP se vuelven transparentes,
ya que son ubicados en cache y administrados automaticamente, y las aplicaciones OLAP
entregan datos con menor latencia y muestran atributos detallados.
Algunas de las nuevas caractersticas que surgen a traves de UDM incluyen:
Dimensiones basadas en atributos: en Analysis Services 2000 una dimension tiene

una unica jerarqua, y salvo por las member propertys, los unicos atributos per-
mitidos son los que indican la jerarqua o el nivel. En Analysis Services 2005 las
dimensiones consisten simplemente de atributos que no necesariamente estan rela-
cionados a la jerarqua. Por ejemplo, una dimension Clientes puede tener varios
atributos demograficos que se organizan en dos jerarquas, una natural como Pas-
Region-Provincia-Ciudad, y una analtica, como Ciudad-Edad-Genero.
Grupos de medidas: como mencionamos, varias tablas de hechos de distinta gran-

ularidad se pueden combinar en un unico cubo. Los grupos de medidas agrupan
medidas de igual nivel de granularidad y se usan en conjuncion con las Perspectivas.
Perspectivas: debido a todas estas caractersticas recien nombradas, un cubo puede

volverse muy grande y difcil de navegar. Las perspectivas son conjuntos con nom-
bre de dimensiones y grupos de medidas, que ayudan a manejar el volumen del
cubo.
Cambios en la programacion de Analysis Services
Algunas de los cambios que se perfilan en la nueva version son:
MDX: se anuncia una simplificacion de MDX, que consiste en escribir expresiones

como scripts procedurales en lugar de las tpicas consultas. La ventaja mas impor-
tante es la posibilidad de hacer un debugging paso a paso por la expresion.
Business Intelligence Wizard y Calculated Measure Templates: Estos templates ayu-

dan 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 informa-
cion de bajo nivel sobre lo que esta ocurriendo en el Analysis Server. En la version
2005 se generan eventos Trace, los cuales pueden ser monitoreados y analizados
con el SQL Server Profiler, igual que en SQL Server.
Traducciones: la nueva version incluye una capacidad de traduccion que permite

que el mismo cubo se presente en multiples lenguajes.
Otros cambios en Analysis Services incluyen la introduccion del Caching Proactivo,

y los Servicios de Notificacion.
El Caching Proactivo permite especificar caractersticas como la poltica a seguir
cuando los datos subyacentes cambian y la cache se vuelve desactualizada, cuan fre-
cuentemente refrescar la cache, etc. Las distintas polticas de caching dan lugar a una
amplia gama de funcionamientos diferentes. Ademas, estos parametros se pueden es-

tablecer para cada objeto en particular, lo que provee una gran flexibilidad en casos
donde el tradeoff entre performance y latencia vara segun las distintas partes del cubo.
Los Servicios de Notificacion 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 definen la forma en
la que seran notificados del evento, por ejemplo, por email o mensajera instantanea.
En SQL Server 2005, los servicios de notificacion incluyen un adaptador especial para
Analysis Services, y usandolo, un cliente se puede suscribir a un evento especificando una
consulta MDX que define el dato de interes, la frecuencia de interrogacion, el esquema
de notificacion, etc. Como ejemplo de la utilidad de estos servicios, supongamos que un
gerente de sucursal requiera una notificacion cuando las ventas por hora de un producto
particular decrece por debajo de un cierto nivel especificado.
Esto es solo un pantallazo de los cambios introducidos en la version 2005 de Analysis

Services, sobre los aspectos que tocamos en las secciones anteriores con la version 2000.
Captulo 5
Conclusion
OLAP juega un rol importante dentro de las organizaciones, ya que ayuda a estable-
cer, monitorear y comunicar las medidas de performance que permiten a los gerentes
entender como se va desarrollando el negocio en el complejo entorno competitivo.
Ademas permite establecer nuevas medidas de performance. Tradicionalmente, las
finanzas provean las unicas medidas de performance corporativa, las cuales continuan
siendo criticas para cualquier negocio. No obstante, surge una tendencia hacia otros fac-
tores, tales como medidas de calidad (en sistemas de produccion), proyectos de inversion
de capitales, eficiencia operacional y del negocio, y medidas sobre el cliente y sobre los
recursos humanos.
Las medidas financieras solo proveen una perspectiva particular, y la mayora de
las organizaciones estan 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 rapido.
Las herramientas OLAP dan pie o facilitan el desarrollo de un conjunto comun de

valores para medir la performance de la compana, mediante un metodo llamado Ba-
lanced Scorecard o Tablero de Comandos. El metodo del Balanced Scorecard agrega
tres perspectivas ademas de la financiera, 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 estrategico, enlazando
metas estrategicas con los resultados de acciones a corto plazo, como mejora de calidad
o nuevas iniciativas de entrenamiento. Se hace hincapie sobre el rol de los sistemas de
informacion como una ayuda para los gerentes en la investigacion de medidas y causas
subyacentes a cualquier senal inesperada.
El rol de OLAP va mas alla del monitoreo de medidas de performance. La definicion

de tales medidas debera ser un proceso de articulacion 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 definan metas.
OLAP y otras herramientas financieras
107
CAPITULO 5. CONCLUSION 108
Existe una clara superposicion en el area de reporte financiero, planeamiento y anali-

sis entre OLAP y planillas de calculo y paquetes contables corporativos. La mayora 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 conjuncion 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
financieros que incorporan funcionalidad OLAP en sus productos.
OLAP en relacion 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 satisfaccion,
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 companas de tele-
comunicaciones, aerolneas, servicios financieros, supermercados, y hasta productoras de
cine, etc, implementan soluciones OLAP, lo que les permite hacer pronosticos de ven-
tas, analisis de promociones, segmentacion de mercado y clientes, y analisis de mercado
compartido.
OLAP y el proceso de fabricacion
El departamento de compras puede negociar mejores descuentos si tiene mejor acceso

a la informacion sobre la performance del proveedor, los costos del material y los gastos.
Conocer mejor los factores que influyen sobre los volumenes y movimientos de stock
permite administrar mejor el mismo. El equipo de control de calidad puede testear
hipotesis y explorar relaciones para entender las causas. Los gerentes pueden ver como
interactuan factores como materias primas, stock, logstica, distribucion, pagos.
Porque 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 facil identificar patrones y tendencias.
El usuario se convierte en un explorador de la informacion, en lugar de un obser-

vador 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.
OLAP y su relacion con herramientas de Reporting y Datamining
Existe una relacion superpuesta entre las herramientas de Reporting, OLAP y Datami-
ning.
Las herramientas de reporting apuntan a un publico general, y los resultados se ex-
tienden a toda la organizacion. Las herramientas OLAP se especializan en la exploracion
interactiva de informacion multidimensional, y se usan en todos los niveles de la orga-
nizacion. La division entre los dos tipos de herramientas no es totalmente clara, porque
algunas herramientas de Reporting tienen facilidades limitadas que permiten a los usua-
rios explorar datos, y las herramientas OLAP, a su vez, se benefician de algunas de las
caractersticas de las de Reporting.
Las herramientas de Datamining estan orientadas a la busqueda de patrones y a
la exploracion de los datos usando hipotesis sobre los mismos. Algunas herramientas
OLAP ofrecen caractersticas limitadas de Datamining, aunque la tendencia actual es
la integracion con estas herramientas como una expansion 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 coleccion
de aplicaciones, tanto operacionales como de toma de decisiones, y de bases de datos,
que juntas proveen a la gente de negocios un facil acceso a los datos de interes.
Las aplicaciones BI no solo facilitan las actividades relacionadas al analisis multi-
dimensional, sino tambien actividades como el Datamining, forecasting(pronosticos), y
preparacion de Balanced Scorecards, entre otras.
Historicamente, una solucion Business Intelligence consista en un conjunto de he-
rramientas individuales, donde cada una soportaba una funcion diferente. Hoy la realidad
es que las soluciones BI a nivel empresarial no solo brindan herramientas que investigan
los datos, sino tambien herramientas de desarrollo y administracion para crear, desa-
rrollar y mantener aplicaciones de tipo BI. Hoy una nueva generacion 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 numero creciente de usuarios y un
diverso rango de necesidades, proveer acceso web, brindar un metodo optimo de inte-
gracion y administracion de fuentes de datos corporativas de gran volumen, funcionalidad
BI embebida en el proceso de negocios, administracion end-to-end de la plataforma, en-
trega de informacion dirigida y planificada, y proveer una plataforma para construir y
desarrollar aplicaciones analticas.
El contenido de esta tesis esta dirigido a quienes se encuentran por primera vez frente
a esta tecnologa.
La idea es brindar las premisas basicas para saber cuales datos tomar de los sistemas
operacionales, conocer las transformaciones mas comunes que se aplican a estos datos,
y para disenar la estructura de las tablas del DataWarehouse que va a recibir los datos
operacionales.
Como ejemplo practico para clarificar estas ideas, se migraron datos desde una base
OLTP a un DataWarehouse disenado con un esquema Snowflake usando los Servicios de
Transformacion de SQL Server (DTS).
La creacion de un cubo con la herramienta SQL Server Analysis Services intento fijar
los conceptos de Cubos, Dimensiones y Niveles, vistos en la introduccion. El analisis y
manipulacion del mismo fue una forma de hacer lo mismo con las operaciones aplicables
a los cubos.
Los ejemplos usados con este fin son bastante basicos, pero utiles para comenzar a
conocer OLAP y sus beneficios.
Las ultimas secciones nos brindan algunas puntas para comenzar a experimentar con
caractersticas mas avanzadas, como cubos virtuales, o la construccion de una herramien-
ta OLAP propia que acceda a Analysis Services por codigo.
Es importante no quedarse afuera de esta tecnologa, y no solo por los beneficios
que brinda. El hecho de que OLAP este acaparando el mercado implica que nuestros
competidores iran avanzando en la medida que la herramienta se los permita, y nuestra
organizacion se ira posicionando en un lugar bastante poco privilegiado con respecto a
la competencia.
Poniendonos a la par, contamos con la misma informacion que los competidores, y
aun mas, a medida que adquiramos conocimiento mas profundo sobre la herramienta
OLAP que usemos y la aprovechemos al maximo.
Bibliografa
[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 caractersticas BI
en SQL Server 2005 prometen cambiar la manera en la que desa-
rrollamos aplicaciones de este tipo. La comparacion realizada en este
artculo esta dirigida a descubrir estos cambios. El link del artculo 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 Sys-

tems. Wiley Computer Publishing, 2002.
[Tie05] Gail Tieh. An Introduction to OLAP in SQL Server 2005. www.devx.com,

2005. Este artculo brinda un pantallazo acerca de las nuevas caractersticas
de Business Intelligence que se incluyen en SQL Server 2005, y sobre los prin-
cipales 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
BIBLIOGRAFIA 112
Turley; Sakhr Youness. Professional SQL Server 2000 DataWarehousing with

Analysis Services. Wrox Press Ltd., 2001.

Introduccion Al Soporte de Decisione PDF

Transféré par

Informations du document

Titre original

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 PDF

Transféré par

Droits d'auteur :

Formats disponibles

Indice general

2. Consideraciones previas a la implementacion 26

3. Disenar la fuente de datos y migrarlos 34

4. Implementar una Herramienta OLAP 56

El punto de partida de todas las actividades de negocios es el procesamiento de infor-

Los sistemas de soporte de decisiones tradicionales se enfocaban en procesos opera-

analizaran interrelaciones entre ellos y sus necesidades. Luego surgio el DataWarehou-

En primer lugar nos introduciremos en lo que significa una herramienta OLAP, y

1.1. Que es OLAP?

Porque se dice que el analisis es interactivo?

Porque es util la multidimensionalidad?

Porque a escala empresarial?

Un modelo multidimensional de la informacion para el analisis interactivo.

Un mecanismo de almacenamiento para guardar los datos que se van a analizar.

Los usuarios de OLAP se enfocan en los conceptos de negocios, trabajando intuiti-

1.2. Diferencia entre el procesamiento OLAP y OLTP

A diferencia del tiempo de respuesta a las consultas en OLAP, el tiempo de res-

El procesamiento OLTP tiende a ocurrir en tiempos relativamente constantes, es

areas de interes, comienzan a acceder al conjunto de datos detallado. Los conjuntos

Los sistemas operacionales se desarrollan para automatizar circuitos y procesos de

1.3. Cubos: Dimensiones, Medidas y Operaciones apli-

Cuando? La respuesta a esta pregunta permite establecer la dimension del tiempo

Que? Es el objeto del negocio, o el objeto de interes para determinada area de la

Cual? Habla de hacia donde se enfoca el esfuerzo de la organizacion o una deter-

Jerarquas de Dimensiones y Niveles

Si no se cumpliera la confluencia, entonces el primer trimestre que figura relacionado

Operaciones de Slice & Dice (Seleccion)

Slice: Seleccionar una tajada de un cubo tomando un determinado valor de

Dice: Tomar secciones del cubo en funcion de un rango de valores de las

DrillUp: Implica subir un nivel en la jerarqua. Como resultado se agrupan

DrillAcross: Se accede a datos que estan en otros cubos existentes.

1.4. ROLAP, MOLAP Y HOLAP

Bases de datos multidimensionales especializadas (MDDBs), que proveen alma-

DataWarehouses, construidos sobre una tecnologa relacional, pero la optimizacion

Una tercer estrategia que consiste en la combinacion de las dos anteriores.

Las herramientas OLAP que usan almacenamiento multidimensional son llamadas

Algunas lo usan para hacer todo el procesamiento de datos. Generan sentencias

1.4.4. Cual es la mejor opcion?

Buena performance en las consultas, ya que el almacenamiento esta optimizado

La escalabilidad esta limitada por la capacidad de la MDDB y por el tiempo de

En general el analisis esta limitado a los datos totalizados o sumarizados.

El modelo multidimensional no es lo suficientemente flexible como para acomodarse

La estructura que guarda los datos esta incluida en la herramienta.

Requiere una capa adicional de manejo de datos.

No incluye soporte de paralelismo, replicacion ni recuperacion de datos.

Puede requerir aprendizaje por ser una tecnologa nueva en la organizacion.

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.

Ademas del analisis de informacion sumarizada, se pueden analizar datos detallados

Es capaz de analizar los datos desde cualquier perspectiva en cualquier momento.

La herramienta ROLAP requiere un DataWarehouse de donde extraer los datos

Incluye soporte para replicacion, rollback y recuperacion, y para acceso multiusuario.

Ya existen skills para el uso de DBMS.

1.5. Pensar en N dimensiones

Luego, agregando y totalizando los importes obtenemos la organizacion de los datos

Si ahora agregamos una dimension mas, la dimension Productos, obtenemos un cubo

Este cubo no es facil de visualizar en una pantalla de computadora o en un papel,

Veamos otra manera de visualizar los datos del cubo anterior.

Volvamos al problema de la representacion grafica al agregar una dimension mas.

Las distintas posibilidades en la combinacion de las dimensiones dan lugar a cambios

No existen representaciones malas ni tampoco optimas, pero s algunas reglas para

Observemos la diferencia de la grilla anterior con la que se presenta a continuacion.

Antes de decidir como organizar las dimensiones en la pantalla es util preguntarse