Business Intelligence Fundamentos

Pgina 1 de 94
ACADEMIA LATINOAMERICANA DE BUSINESS

INTELLIGENCE (ALBI)
Contenido del curso

Convenciones
Para ubicar rpidamente los diferentes puntos desarrollados a travs de
las unidades, se llev a cabo un diseo de grficos que harn referencia a
cada tema. De esta manera el participante podr ubicar cada contenido sin la
realizacin de un esfuerzo extra en la bsqueda y aprovechando al mximo el
tiempo dedicado al estudio de cada una de las Unidades presentadas.

En siguiente tabla se podr apreciar cada grfico y su significado:

Convencin Descripcin

Objetivos
Son las metas a las que apunta el curso o el mdulo.

Conceptos clave
Es el contenido que, por su relevancia de significado,
propone definiciones, descripciones o informacin a la
que como participante se le debe prestar especial
atencin.

Riesgos
Cualquier situacin que amenaza el xito del proyecto
en general o afecta la capacidad del equipo de trabajo.
Un problema que no ha sucedido, pero que podra
causar prdidas o amenazar el xito del proyecto, si
sucede. (Wiegers, 1998)

Ejemplos
Son situaciones conceptuales, reales o hipotticas de
aplicacin de los conceptos tratados y su propsito es
apoyar a la comprensin de los conceptos al asociarlos
con posibles formas de aplicacin o de interpretar las
que se proponen.
Pgina 2 de 94
Convencin Descripcin

Caso de Estudio
Ejemplo que se desarrollar en detalle a lo largo del
curso. Al finalizar el curso, el participante podr reunir
estas secciones y tener un ejemplo de desarrollo
completo.

Estadsticas
Son datos cuantitativos provenientes de estudios
realizados por fuentes confiables que permiten
dimensionar la importancia de los sistemas de BI. Al
igual que los Ejemplos y las Preguntas de reflexin,
detonan la asociacin del contenido conceptual con
entornos de aplicacin del aprendizaje.

Preguntas de Reflexin
Son formulaciones que sirven como gua para controlar
el desarrollo del proyecto. Al final de la ltima unidad,
estas preguntas se renen formando un Check List.

Lecciones aprendidas
Son frases o afirmaciones que al final de cada captulo
sintetizan lo que el participante debi aprender y
permiten parafrasear la informacin clave.
Diagramas,
esquemas,
fotografas, tablas,
negritas y color en
las fuentes
Son recursos que facilitan la lectura y la comprensin
porque destacan, organizan, clasifican, jerarquizan,
ilustran y/o representan el contenido con el propsito
de facilitarte como participante la interaccin con el
curso.

Pgina 3 de 94
Objetivos

Quin participe en la presente propuesta educativa, obtendr
los conceptos tericos necesarios de Business Intelligence,
formando una base consistente para adquirir posteriormente
los conocimientos y as perfeccionarse en esta tecnologa. Al
final del curso tendr los conocimientos suficientes para
comprender qu es Business Intelligence, su necesidad,
utilidad, desarrollo e implementacin.

Contenido
Las siguientes Unidades y temticas son las que se desarrollarn a lo largo
del curso, cubriendo las expectativas planteadas en los objetivos que se
pretenden que el alumno alcance a lo largo de esta propuesta educativa.
Unidad 1. Qu es Business Intelligence?
La Unidad 1 contar a modo introductorio el concepto de Business
Intelligence, haciendo un repaso de lo que significa contar con una
solucin BI, su potencialidad en la toma de decisiones y por qu en la
actualidad las empresas estn apostando a ello.
Unidad 2. Definiendo Soluciones OLAP
La Unidad 2 se recordarn los conceptos bsicos de un sistema OLTP
con sus ejemplos, pasando posteriormente a la explicacin de un
sistema OLAP. Se mencionarn y explicarn las caractersticas de un
Data Warehouse junto con los componentes que lo conforman. A su
vez, se tratar sobre los datos de origen que alimentan al Data
Warehouse y cmo estos comienzan a transformarse en informacin
del negocio. Hacia el final de la unidad, se vern algunos de los
posibles procesos de seleccin y transformacin de datos (ETL) que
permiten alimentar las tablas auxiliares que soportarn la estructura
multidimensional.
Unidad 3. Diseando una solucin OLAP
En la Unidad 3 se describir el esquema de la base que conformar el
plano sobre el que se edificar la estructura multidimensional (cubo) y
sus componentes (Tablas de Hechos, Dimensiones y Medidas).
Unidad 4. Construyendo una solucin OLAP
En la Unidad 4 se vern consideraciones especficas de la
construccin y procesamiento de un cubo.
Unidad 5. Implementando Cubos OLAP
En la Unidad 5 se ver como un usuario puede acceder a la
informacin en un sistema de BI, teniendo en cuenta la seguridad y el
tipo de herramienta de consulta utilizada.
Pgina 4 de 94
Unidad 1 Qu es Business Intelligence?

1.1 Introduccin
1.2 A qu empresas les interesa BI?
1.3 Qu es Business Intelligence?
1.4 Qu puede hacer Business Intelligence?
1.5 Quin necesita soluciones Business Intelligence?
1.5.1 Obtencin catica de informacin
1.5.2 Quin necesita analizar la informacin?
1.6 Primeros pasos?
1.7 El futuro de Business Intelligence

Unidad 2 Definiendo Soluciones OLAP

2.1 Sistema Transaccional (OLTP)
2.1.1 Caractersticas
2.1.2 Usos comunes de OLTP
2.2 Sistemas OLAP
2.2.1 Bases de Datos (Estructuras)
2.2.2 Usos Comunes de OLAP
2.3 Datos de Origen vs. Informacin de Negocio
2.3.1 Convirtiendo Datos en Informacin
2.3.2 Transformacin y agrupacin de datos ETL

Unidad 3 Diseando una solucin OLAP

3.1 Introduccin
3.2 Construyendo el data mart
3.3 Esquema Estrella
3.3.1 Tabla de Hechos
3.3.2 Dimensiones
3.3.2.1 Relaciones y Estructura de una dimensin
3.3.2.2 Esquema Estrella
3.3.2.3 Esquema Copo de Nieve
Pgina 5 de 94
3.3.2.4 Padre Hijo (Parent- Child)
3.3.2.5 Dimensiones Virtuales
3.3.2.6 La dimensin Tiempo
3.4 Medidas
3.4.1 Medidas Naturales
3.4.2 Medidas Calculadas

Unidad 4 Construyendo una solucin OLAP

4.1. Introduccin
4.2. Tipos de Almacenamiento
4.2.1. MOLAP
4.2.2. ROLAP
4.2.3. HOLAP
4.3. Definicin de Agregaciones
4.4. Procesamiento de cubos
4.5. Cubos Virtuales
4.6. Particiones
4.7. La difcil bsqueda del equilibrio

Unidad 5 Implementando Cubos OLAP

1.8 Introduccin
1.9 Seguridad
1.10 Consultas
1.11 Herramientas de visualizacin
5.4.1 La Tabla Pivotal
5.4.2 El Tablero de Control
1.12 Conclusiones
1.13 Check List

Pgina 6 de 94
Unidad 1. Introduccin a Business Intelligence

Objetivos

Dar una visin acerca del por qu se debe contar con un
sistema de apoyo para la toma de decisiones:

Conocer qu sistemas informatizados actan en cada
componente organizacional.
Distinguir entre un sistema operacional y un sistema
de toma de decisiones.
Comprender el concepto de Business Intelligence.
Conocer acerca de los beneficios que trae aparejado
el uso de Business Intelligence.
Comprender los criterios que llevan a una empresa a
utilizar una solucin Business Intelligence.

Introduccin
Los rpidos cambios que se viven en el mercado actual junto a las
competencias que se generan cada da, hacen que las empresas no puedan
postergar las decisiones relacionadas directamente con el negocio; una
demora en este sentido puede llevar la gestin de la empresa al fracaso.
Es necesario entonces contar con un sistema que juegue el papel de soporte
para la toma de decisiones, de respuesta gil y rpida, con informacin
precisa para poder aprovechar las oportunidades: estar en el lugar indicado,
en el momento oportuno, con la informacin correcta.
Los sistemas orientados para la toma de decisiones son los englobados por
el trmino Business Intelligence. Administrar una empresa sin contar con un
sistema de Business Intelligence adecuado se parece mucho a caminar con
los ojos vendados: se puede avanzar, ejecutar los procesos operacionales
correctamente, progresar aparentemente segn los objetivos y hasta crecer,
pero en cuanto algo falla, los procesos se descontrolan, la coordinacin
desaparece y, en el mediano plazo, la empresa se desploma sobre s misma.
Esta puede parecer una visin apocalptica, pero, quin se arriesgara a
llevar adelante una gestin basndose en la buena suerte?

Pgina 7 de 94

Contenido de la unidad
1.14 Introduccin
1.5.1 Obtencin catica de informacin
1.5.2 Quin necesita analizar la informacin?
1.19 Primeros pasos?

1.1 Introduccin
Tanto en empresas pequeas como en grandes organizaciones existen
variados sistemas informatizados que tienen como objetivo principal
garantizar la persistencia de las operaciones diarias realizadas. Estas
operaciones se realizan segn reglas de negocios predefinidas y se
almacenan en grandes bases de datos.
Dentro de las organizaciones se pueden reconocer distintos niveles de uso de
los datos:
Nivel operacional: Se utilizan sistemas de informacin que
monitorean las actividades y transacciones elementales de la
organizacin. Son sistemas que han cobrado un auge importante en la
ltima dcada a consecuencia de un desarrollo organizacional
orientado al mercado global.

Nivel de conocimientos: En este nivel encontramos a los
trabajadores de conocimiento y de datos, cubriendo el ncleo de
operaciones tradicionales de captura masiva de datos y servicios
bsicos de tratamiento de datos, con tareas predefinidas.

Nivel de administracin: Se realizan tareas de administradores de
nivel intermedio apoyando las actividades de anlisis, de seguimiento,
de control y toma de decisiones, realizando consultas sobre
informacin almacenada en el sistema, proporcionando informes y
facilitando la gestin de la informacin por parte de los niveles
intermedios.

Nivel estratgico: Tiene como objetivo realizar las actividades de
planificacin a largo plazo, tanto del nivel de administracin como de
los objetivos que la empresa posee.
Pgina 8 de 94

La informacin que se genera en la organizacin se consume en diferentes
momentos segn el nivel:
Plazo Nivel Uso
Corto plazo Operacional y
Administrativo
Obtencin y control de datos
Mediano
plazo
De Conocimientos Decisiones tcticas
Largo plazo Estratgico Decisiones estratgicas
Las bases de datos transaccionales sirven como herramienta para los dos
niveles bsicos de la pirmide, el Nivel Operativo y el Nivel de
Conocimientos. En los sistemas OLTP se ingresan, controlan y almacenan
los datos.
En los niveles superiores de la pirmide, el Nivel de Administracin y el Nivel
Estratgico, se tiene por tarea la toma de decisiones, tareas que estn
estrechamente vinculadas con los objetivos del negocio.

Un sistema es un conjunto de elementos organizados que
interactan entre s. Representa el conjunto de reglas de
negocio que la organizacin define para llevar a cabo los
procesos y procedimientos funcionales y operativos
Pgina 9 de 94
necesarios para alcanzar los objetivos propuestos.
Una Base de Datos es un conjunto de datos que pertenecen
al mismo contexto y se encuentran almacenados
sistemticamente dentro de alguna estructura que los
contiene.
El Ambiente Operacional es el espacio en el que conviven el
conjunto de reglas de negocio que la organizacin define para
llevar a cabo los procesos y procedimientos funcionales y
operativos necesarios para alcanzar los objetivos propuestos y
los datos generados por las transacciones realizadas
diariamente.

Una Base de Datos operacional posee un conjunto de caractersticas tales
como:
Est orientada a la aplicacin.
Tiene estructuras normalizadas.
Contiene los datos de las operaciones.
Los datos se almacenan con el mximo nmero de detalle.
Se actualiza en lnea.
Est en constante cambio.

Ejemplo de Base de Datos Operacional
La base de datos de una Entidad Financiera puede tener
datos de:
Clientes
Tipos de Clientes
Productos
Tipos de Productos
Operaciones
Tipos de operaciones
Regiones
Pases
Provincias
Ciudades
Etctera
Cada una de las tablas y la base en s, estarn normalizadas
para asegurar la integridad de los datos, minimizar el
espacio ocupado y maximizar el rendimiento del
mantenimiento de los datos.
Pgina 10 de 94


Gasto total, para Argentina, en soluciones de BI, por
Mercado

Variacin del Presupuesto de BI 2006 vs. 2005

Empresas que invertirn Ms en BI (2006 vs. 2005)
Pgina 11 de 94

Hasta este momento hemos estado hablando sobre Base de Datos
transaccionales, las cuales dan soporte a las operaciones de la empresa.
Estas Bases de Datos componen los sistemas OLTP.
.

OLTP son las iniciales en ingls de On-Line Transaction
Processing, queriendo significar en su traduccin
Procesamiento de Transacciones en Lnea.

Bajo el nombre de Business Intelligence (Inteligencia de Negocios) se cobijan
diferentes acrnimos, herramientas y disciplinas que apuntan a dar soporte a
la tarea de toma de decisiones.
Fundamentalmente podemos nombrar a:
Data Warehousing: Los Data Warehouses o Almacenes de Datos se
basan en estructuras multidimensionales (cubos) en las que se
almacena la informacin calculando previamente todas las
combinaciones de todos los niveles de todas las aperturas de anlisis.
Es, por decirlo llanamente, un producto cartesiano que almacena todas
las combinaciones. Se puede decir que este mtodo es exagerado o
salvaje y en parte esta afirmacin es real. Lo que no debe perderse de
vista es que esta salvajada es el precio que paga la organizacin
para poder tomar decisiones correctas. Siempre va a ser ms barato el
Pgina 12 de 94
gasto que conlleva la adquisicin de SW o HW que el costo que
representa una decisin tomada a destiempo.
Data Mart: El almacn de datos de un hecho en particular se
denomina Data Mart (DM).
Data Mining: Est asociado al escaln ms alto de la pirmide (Nivel
Estratgico) y tiene por objeto eliminar los errores cometidos por las
personas al analizar los datos debido a prejuicios y dejar que sean los
datos los que muestren los modelos subyacentes en ellos. La Minera
de Datos ayuda a crear nuevos modelos no percibidos por el analista
hasta ese momento pero que realmente existen en los datos.
Todas las herramientas o disciplinas que pueden contenerse en la definicin
de BI tienen tres caractersticas comunes:
Primera: Proveen informacin para el control del proceso de negocio,
independientemente de la fuente en la que los datos se encuentran
almacenados.
Segunda: Dan soporte a la toma de decisiones, siendo esta la
caracterstica ms importante.
Tercera: La capa semntica. No se pueden tomar decisiones de
negocio si no se habla el lenguaje propio del negocio.
Independientemente del origen de los datos o de la forma de
extraccin, transformacin y agregacin, lo verdaderamente importante
es que la informacin le debe servir a los usuarios finales en un
lenguaje de negocios comprensible por ellos sin la necesidad de
intrpretes. La idea es que el analista se concentre en la toma de
decisiones, las tome con rapidez y seguridad, lo que le ofrece una
ventaja competitiva a la empresa y la acerca al cumplimiento de los
objetivos.

Business Intelligence (BI) es una disciplina que, junto con
sus correspondientes herramientas, hacen centro en el
anlisis de la informacin para la correcta toma de decisiones
que le permita a la organizacin cumplir con los objetivos de
negocio.

En la siguiente tabla se muestran las diferencias que son clave entre un
sistema OLPT y un DW.
OLPT DW
Objetivos Operacionales
Informacin para la
toma de decisiones
Orientacin A la aplicacin Al sujeto
Pgina 13 de 94
Vigencia de los datos Actual Actual + histrico
Granularidad de los
datos
Detallada Detallada + resumida
Organizacin
Organizacin
normalizada
Organizacin
estructurada en funcin
del anlisis a realizar
Cambios en los datos Continuos Estable

A continuacin se comentan cada una de las diferencias mencionadas para
comprender con mayor detalle el concepto de DW.
Objetivos: Un sistema OLTP debe garantizar la consistencia de los
datos, mientras que un OLAP consolida datos ya validados y los
adecua a las necesidades propias de la toma de decisiones.
Orientacin: Un sistema OLTP est orientado a la Aplicacin, debe
hacer cumplir las Reglas de Negocio. En cambio un sistema OLAP
est orientado al Sujeto, se define en base a lo que el analista necesita
ver.
Vigencia de los Datos: En un sistema OLTP los datos se usan en la
medida que se van produciendo y dejan de ser importantes en el corto
plazo (un diario de ventas se lista para el mes que finaliza y, en el
mismo momento comienzan a ser importantes los datos del mes
actual). En un sistema OLAP se guardan los datos actuales y los
histricos para poder realizar anlisis comparativos, de tendencias,
etctera. La cantidad de perodos almacenados depender
exclusivamente de la necesidad de anlisis de la empresa y de la
capacidad de almacenamiento.
Granularidad de los Datos: En un sistema OLTP la granularidad est
dada por los controles que deban realizarse, ya sea controles definidos
por la organizacin como por las normas legales vigentes. En un
OLAP estar dada por el tipo de anlisis que se quieran realizar. Si el
anlisis del trfico se realiza analizando el nmero de llamadas en el
mes, no tiene sentido guardar el detalle diario en el OLAP, mientras
que en el OLTP tal vez no tenga la libertad de decidir el nivel de
granularidad.
Organizacin: Un sistema OLTP es normalizado, mientras que un
sistema OLAP se basa en estructuras jerrquicas desnormalizadas
modeladas de acuerdo a la forma en que se analizarn los datos.
Cambios en los datos: Un sistema OLTP modifica sus datos en forma
constante porque maneja las transacciones de la empresa. Un sistema
OLAP no tiene como objetivo la presentacin de los datos en lnea y,
menos an, pretende modificar los datos originales, solo consultarlos.
La frecuencia de actualizacin de los datos en un sistema OLAP est
definida por la granularidad.
Pgina 14 de 94

Datos vs. Informacin
Diariamente manejamos datos sobre los nmeros telefnicos
de las personas con las que tenemos contacto (amigos,
familiares, el plomero, el delivery de pizzas, etctera). Estos
telfonos nos llegan de distintas fuentes y podramos anotarlos
en una libretita de telfonos o en un cuaderno comn.
Entonces,
Cul es la ventaja de anotar los nmeros de telfono que nos
interesan en una libretita en lugar de utilizar un cuaderno? Es
evidente, vamos a encontrar ms rpido los nmeros en la
libretita que en el cuaderno ya que los tenemos organizados por
la inicial del nombre.
Y si adems pudiramos contar en nuestra libretita con una
divisin para nuestras amistades, otra para nuestra familia y
otra para servicios, cada una de ellas en diferentes colores de
hojas?
Tendramos nuestra informacin telefnica organizada de tal
manera que al necesitar de ella sera rpidamente accesible. Si
queremos llamar a un amigo, tendramos que identificar el grupo
de pertenencia segn el color, luengo por el ndice buscamos el
nombre y apellido y obtenemos el nmero de telfono.
Este sencillo ejemplo muestra conceptualmente la diferencia
que existe entre datos e informacin y representa la semilla de
un DW.

Histricamente, para realizar un anlisis:
Se deba llamar a una Mesa de Ayuda para solicitarle los datos
necesarios ya que era el personal de Sistemas la que saba dnde se
Pgina 15 de 94
almacenaban y de qu forma. El pedido pasaba a formar parte de la
cola de incidentes.
Obtener los datos demandaba un tiempo importante, pudiendo ser
medido en das.
Luego de la larga espera, se reciban los ansiados datos,
procedindose al anlisis.
Era muy posible que el analista se diera cuenta que en realidad
necesitaba contar con ms informacin, lo cual significaba repetir el
ciclo mencionado.

En un DW se pueden reunir los elementos de datos apropiados desde
diversas fuentes de aplicacin en un ambiente integral y centralizado,
simplificando el problema de acceso a la informacin y en consecuencia,
acelerando el proceso de consultas y anlisis.
Las aplicaciones para soporte de decisiones basadas en warehousing,
pueden hacer ms prctica y fcil la explotacin de datos para una mayor
eficacia del negocio tanto desde el punto de vista de la disponibilidad como
de la confiabilidad.
Es posible que an para un grupo importante de personas esta pregunta no
tenga una respuesta fundamentada o, lo que consideramos peor, que existan
empresas que piensen que no necesitan contar con una solucin BI.
Vayamos por partes.

Pgina 16 de 94
1.5.1 Obtencin catica de informacin: Uno de los problemas ms
comunes cuando se necesita consolidar informacin o realizar tareas de
anlisis, es que hay que saber dnde est almacenado cada dato, con qu
formato y qu nivel de consistencia tiene. Todo esto sin mencionar siquiera
las complicaciones que trae el tema del acceso a los datos por cuestiones de
seguridad.

Un sistema operacional puede estar compuesto por varias aplicaciones, estas
aplicaciones pueden haber sido desarrolladas por diferentes proveedores y
con diferentes herramientas.
Puede darse el caso de que haya determinados procesos que no tengan una
aplicacin que los soporte y por consiguiente el usuario lleve parte del
negocio en planillas de clculo almacenadas en su computadora.
Tambin puede pasar que los datos histricos slo se mantengan en
informes impresos ubicados en armarios ya sea en el lugar de trabajo o en un
depsito externo.
El recolectar este universo de datos dispersos en todos los sectores y lugares
de la empresa, hace catica la obtencin de la informacin que se necesita.
El disparador de las soluciones de BI son las Killer Queries (Consultas
asesinas). Si se quiere saber cunto debo producir en el segundo trimestre
del ao, tal vez deba conocer la previsin de ventas y la tendencia de las
ventas en el ao actual y las ventas reales de los ltimos 5 aos. Si se
ejecuta esta consulta directamente contra un sistema OLTP, la respuesta
puede que tarde varias horas y este no sera el mayor problema. El autntico
peligro es que colapse todo el sistema de informacin y nadie en la empresa
pueda trabajar mientras tanto, con las prdidas que esto ocasiona.

Pgina 17 de 94
1.5.2 Quin necesita analizar la informacin? El xito de una
organizacin y de la gestin de la empresa se centra en el uso que se hace
de la informacin. No se puede gestionar lo que no se controla. No se puede
controlar lo que no se mide, si no se tiene informacin para controlar los
procesos ocurrir el caos.

La informacin reduce la incertidumbre y facilita la toma de mejores
decisiones.

Entonces, podemos concluir que si existe una organizacin, si esta
organizacin tiene un servicio o producto que est comercializando, si existen
objetivos a corto y largo plazo que deben ser alcanzados y si existe, por
sobre todas las cosas, ideales de competencia y crecimiento, debe existir
tambin dentro de la empresa un sistema basado en BI.

Tomar decisiones sin la informacin adecuada, sobre todo
cuando sta se encuentra disponible en la organizacin, es un
riesgo que ninguna empresa debera correr.

Finalmente surgen dos interrogantes:
Cundo necesita la empresa hacer uso de esta informacin?
Cundo puede la empresa hacer uso de esta informacin?
La respuesta para los dos casos es la misma:
Es necesario decidir ahora y se debe tener la informacin ahora!

Suponer que desarrollar un sistema basado en la tecnologa
Business Intelligence es algo lujoso, de costos muy elevados
o que es un elemento de Marketing es una concepcin
errnea de la idea.

1.6 Primeros pasos
Pgina 18 de 94
Aceptando que se reconoce la necesidad de contar con un sistema basado
en BI, se plantean las preguntas: Cmo comienzo? Hasta dnde debo
llegar en una primera etapa?
La creacin de un sistema de BI puede verse como una obra de muy largo
aliento y provocar temores. Lo importante, al principio es crear la base sobre
la que podamos obtener los primeros resultados para, con el tiempo, seguir
creciendo. Lo esencial es
Lograr la unificacin de los datos que se usan en la toma de
decisiones en un repositorio nico. Una experiencia desalentadora
es la de llegar a una reunin y ver que cada expositor porta una
planilla de clculo propia, con datos propios que no coinciden con
ninguna de las dems e iniciarla con una discusin sobre la validez de
las distintas fuentes de datos.
Implementar una capa semntica til. Que todos entiendan con
claridad el significado de la informacin.
Una vez cumplidos estos objetivos bsicos, el resto del camino depender de
las necesidades propias de cada organizacin.

Como en casi todas las actividades humanas, en BI se da una mezcla de
necesidad y moda. Por estos tiempos estn tomando cuerpo los proyectos
BAM y CPM:
BAM: Los Business Activity Monitoring plantean el uso de
indicadores de cuadro de mando, pero a muy corto plazo. Son
indicadores estrictamente operacionales que se obtendrn de los
sistemas transaccionales. En algunos casos se los menciona como BI
Operacional, porque responden a la necesidad de tomar decisiones a
nivel operacional, en el aqu y ahora.
CPM: Los Corporate Performance Management completan el
enfoque global del proceso de flujo de informacin que da soporte a
las decisiones en la empresa. Con las herramientas actuales se puede
monitorear el negocio, analizar los problemas o aciertos. Se controlan
los KPI (Key Performance Indicador Indicador Clave de Rendimiento)
pero no se tienen herramientas para crear y gestionar los KGI (Key
Goal Indicador Indicador Clave de Objetivo). Con CPM se pretende
cerrar el crculo: se podrn definir las previsiones, los objetivos, la
planificacin, la consolidacin presupuestaria, etctera.

Caso de Estudio

Pgina 19 de 94
Escenario

La Distribuidora Latinoamericana de Alimentos
(DLA), se dedica a la comercializacin de
productos comestibles y bebidas a travs de sus
Hipermercados y Supermercados.

Si bien cuenta con una amplia e
importante cantidad de locales en la
Repblica Argentina, Brasil y Uruguay, un
claro objetivo a mediano plazo es
inaugurar locales en el resto de los pases
que conforman el MERCOSUR.

Necesidad: Los analistas de DLA, por pedido de sus directivos, necesitan
realizar informes en donde se pueda analizar:
La cantidad de unidades vendidas en los pases que alcanza el
Mercado actual.
El coste inducido en cada unidad vendida
El valor de venta de cada producto.
La ganancia obtenida en la venta de cada producto.
Esta informacin, requiere que sea presentada por zona geogrfica y
sucursal.
A su vez, la empresa quiere:
Armar canastas de productos de acuerdo al perfil de compra de los
clientes de cada ciudad en la que tienen una boca de expendio. Para
esto requieren un estudio de las ventas realizadas abiertas por
categora de producto (con la posibilidad de obtener el detalle por
producto), por ciudad, por mes, para los ltimos 13 meses (para
detectar estacionalidades)
Premiar anualmente a aquellos vendedores que superen los objetivos
de venta que les fueran asignados. El anlisis, en este caso deber
incluir a los vendedores, las ventas realizadas, los objetivos de venta y
el indicador de cumplimiento detallados por mes para el ao fiscal (El
premio ser distinto si se cumple con los objetivos globalmente para el
Pgina 20 de 94
ao o si, adems, se cumplen los objetivos en todos los meses en
particular).

Se tiene distincin entre un sistema basado en lo
operacional y un sistema que apoya la toma de
decisiones.
Comprendemos ahora qu es Business
Intelligence.
Se comprenden las ventajas de una solucin
Business Intelligence.
Se comprende y se puede decidir cundo aplicar
una solucin Business Intelligence.
Se puede especificar quines necesitan una
solucin Business Intelligence.

Est preparada la organizacin para trabajar con
BI?
Se cuenta con el compromiso de la alta gerencia
para encarar un proyecto de creacin de un sistema
de BI?
Tiene presente que deber capacitar a los
usuarios en la disciplina asociada a BI?
Estn claramente definidos los objetivos de
negocio que se asocian al sistema de BI?

Unidad 2. Definiendo Soluciones OLAP

Objetivos

Al cabo de esta Unidad, el participante:
Recordar los conceptos bsicos de un sistema OLTP
con sus ejemplos.
Comprender las caractersticas de un Data
Warehouse junto con los componentes que lo
conforman.
Reconocer la necesidad de los procesos de
seleccin y transformacin de datos (ETL) que
permiten alimentar las tablas auxiliares que soportarn
Pgina 21 de 94
la estructura multidimensional.
Conocer las diferencias entre un sistema
transaccional y un Data Warehouse.
Comprender el trmino OLAP y su relacin con la
navegabilidad de la informacin.
Conocer sobre las transformaciones necesarias para
armar un DW a partir de una Base de Datos
Operacional.

Introduccin
Para llevar adelante el desarrollo de un DW, deben tenerse en cuenta una
serie de pautas que debern estar alineadas con los objetivos del negocio y
los hechos que necesitan analizarse, incluyendo el alcance que tendr el
sistema, la granularidad de los datos y la navegabilidad que se desea.
Debemos tambin identificar los orgenes de datos para luego seleccionarlos,
depurarlos, transformarlos e importarlos.
2.1.2 Usos comunes de OLTP
2.2 Sistemas OLAP

Los sistemas de OLTP (On-Line Transaction Processing) son los sistemas
operacionales que capturan las transacciones de un negocio y las persisten
en estructuras relacionales llamadas Base de Datos.
Las caractersticas principales de los sistemas OLTP son:
Realizan transacciones en tiempo real del proceso de un negocio, con
lo cual los datos almacenados cambian continuamente. Los sistemas
OLTP en sus transacciones conducen procesos esenciales del
negocio.
Pgina 22 de 94
Los sistemas OLTP son los responsables del mantenimiento de los
datos, ya sea agregando datos, realizando actualizaciones o bien
eliminndolos.
Las estructuras de datos deben estar optimizadas para validar la
entrada de los mismos, y rechazarlos si no cumplen con determinadas
reglas de negocio.
Para la toma de decisiones, proporciona capacidades limitadas ya
que no es su objetivo, por lo tanto no es prioridad en su diseo. Si se
quisiera obtener determinada informacin histrica relativa al negocio
consultando un sistema OLTP, se producira un impacto negativo en el
funcionamiento del sistema.
Normalmente, para el diseo de un sistema OLTP se define un modelo de
Diagrama Entidad Relacin (DER). Un DER es una representacin de la
realidad a travs de un esquema grfico que contiene los siguientes
elementos:
Entidades: Una Entidad es un tipo de objeto que puede identificarse
de manera nica por algn medio. Este objeto es traducido a la
estructura fsica de una base de datos como una tabla.
Atributos: Las caractersticas particulares que distinguen a las
Entidades se denominan Atributos.
Relaciones: vnculos existentes entre las tablas que sirven para
asegurar la integridad referencial.

Un ejemplo de Entidades y Atributos es:
Persona (IdPersona, Nombre, Apellido,
IdLocalidad)
Grupo (IdPersona, Telefono)

Para llegar a esquematizar un DER, se debe realizar un proceso de
normalizacin basado en las Formas Normales, lo que adems garantiza una
optimizacin del espacio de disco a utilizar.
2.1.2 Usos Comunes de OLTP
Toda organizacin o empresa, lleva adelante sus objetivos diarios realizando
un conjunto de tareas que se encuentran cuidadosamente agrupadas dentro
de procesos, estos ltimos estrechamente relacionados entre s. Los
procesos pueden pertenecer al rea Industrial, al departamento de Marketing,
al departamento de Ventas o al sector Administrativo, mencionando solo
algunos.
Decimos entonces, que en la definicin de OLTP se pueden encuadrar a
todos los sistemas tradicionales dedicados a la captura, validacin y
Pgina 23 de 94
almacenamiento de datos de manera estructurada y que corresponden a los
procedimientos.

Sistema OLTP
Imaginemos que estamos frente a un Sistema de Cajeros
Automticos. El sistema, al ser operado por un cliente
pasar por las siguientes situaciones:
Tomar la tarjeta del Cliente.
Validar el Cliente. Consultar a la Base de Datos si el
Cliente existe y, de existir, confirmar que se encuentra
en una lnea de cajeros habilitada.
Autenticar el cliente en el sistema.
De querer realizar una transferencia:
Verificar que est autorizado para realizarla.
Verificar que tiene saldo.
Inicializar la transferencia manejndola como una
transaccin.
Emitir comprobante.
Saludar al Cliente.
La situacin en un Sistema de Ventas por medio de un sitio
Web, sera la siguiente:
Validar al cliente y autenticarlo en el sistema.
Tomar el pedido.
Controlar los topes de crditos.
Informar los valores parciales de la compra y
acumulados.
Requerir confirmacin del cliente antes de enviar el
pedido.
Enviar el pedido.
Descontar del stock las cantidades vendidas.
Informar el nmero de venta y la fecha de entrega.
Saludar al cliente.

Vemos que el sistema transaccional asegura un conjunto de reglas de
negocio, como ser en el ejemplo del sistema de Ventas Web, antes de
realizar la venta se controla que el cliente no haya superado el tope de los
crditos.
Pgina 24 de 94
A su vez, debe mantenerse una integridad en la informacin, es decir, si en
una tabla manejo el stock de los productos y en otra llevo los movimientos
que realizo de estos productos, las cantidades que muevo en la tabla de
movimientos tienen que ser descontadas en igual medida que las que tengo
en la tabla de productos.

Las organizaciones se ven entonces en la necesidad de registrar las
transacciones que ocurren durante sus procesos operacionales, para su
control y posterior consulta.
Un sistema OLTP es utilizado en:
Sistemas bancarios
Procesamiento de pedidos
Comercio electrnico
Sistemas de facturacin
Sistemas de stock

Pgina 25 de 94
$
Bancos Comercio electrnico
Pedidos
Stock
$ $
$
Facturacin
Sistemas OLTP
Almacenamiento Transaccional

2.2 Sistemas OLAP
Los sistemas OLAP (On-Line Analytical Processing) proporcionan una
alternativa a los sistemas transaccionales, ofreciendo una visin de los datos
orientada hacia el anlisis y una rpida y flexible navegacin por estos.
Las siguientes son caractersticas que la tecnologa OLAP posee:
Las bases de datos de OLAP tienen un esquema que est optimizado
para que las preguntas realizadas por los usuarios sean respondidas
rpidamente.
Las preguntas que se le hacen a un OLAP, deben permitir un uso
interactivo con los usuarios.
Los cubos de OLAP almacenan varios niveles de datos conformados
por estructuras altamente optimizadas que responden a las
expectativas de negocio de la empresa.
Un sistema OLAP est preparado para realizar informes complejos de
una manera simple.
OLAP proporciona una vista de datos multidimensional. Los cubos
proporcionan una vista de los datos multidimensional que se extiende
ms all del anlisis de dos dimensiones que puede proporcionar una
simple planilla de clculo utilizada como tal.
Los usuarios pueden cambiar fcilmente las filas, las columnas, y las
pginas en informes de OLAP, pudiendo leer la informacin de la
manera que se crea ms conveniente para el anlisis.

Pgina 26 de 94

Un Sistema OLAP
Los sistemas OLAP son una solucin que devuelve rpidas
respuestas a las consultas que le son realizadas.
En base a los sistemas OLAP, se pueden obtener informes de
negocios sobre Ventas Marketing, entre otros.

Los sistemas OLAP, son utilizados por las empresas para conocer la historia
del negocio y poder realizar la toma de decisiones.
Podemos enunciar entonces las siguientes reas en donde el uso de un
sistema OLAP est difundido:
Sistemas de informacin ejecutivos. Los usuarios y los
administradores generalmente de mandos altos y medios, reciben la
informacin sobre los indicadores de funcionamiento dominantes del
negocio y de las excepciones o las variaciones segn sea de patrones
y de estndares preestablecidos. Los Sistemas de Informacin
Ejecutivos (EIS) presentan tpicamente datos multidimensionales en
formatos grficos.

Aplicaciones financieras. Para diversos usos de tipo financiero se
utilizan las bases de datos de OLAP como ser para comunicar,
planear, y analizar. Los ejemplos de usos financieros incluyen la
comunicacin, anlisis del mes-cierre, anlisis de lo beneficioso del
producto, los presupuestos y pronstico. Los analistas financieros
utilizan OLAP extensivamente para el anlisis de datos financieros y
operacionales para contestar las preguntas de la gerencia mayor.

OLAP en EIS
Alertas.
Toma de decisiones.

OLAP en la Actividad Financiera
Reportes analticos.
Planeamiento.
Anlisis.
Pgina 27 de 94

Ventas y aplicaciones de Marketing. Existen diferentes formas de
llegar a los clientes para alcanzar los objetivos de venta y de
comercializacin propuestos. Por esto, la utilizacin de sistemas
OLAP, donde es importante contar con informacin organizada de
manera rpida, es aconsejable. Los ejemplos incluyen anlisis de la
facturacin, anlisis de producto, anlisis del cliente, y anlisis de
ventas regional.

Otros Usos. Las bases de datos de OLAP se adaptan a una amplia
gama de anlisis, incluyendo rendimiento de procesamiento y eficacia
de la fabricacin, eficacia del servicio de cliente, y anlisis de coste del
producto. En definitiva, un sistema OLAP es til para todo proceso en
el que sea necesario tomar decisiones.


El presente esquema representa las distintas etapas que se deben ejecutar
para la construccin de un Data Mart, desde que se identifican los datos
originales en los sistemas transaccionales hasta que los Usuarios pueden
disponer la informacin. A modo de gua, se ir indicando qu parte de estos
procesos cubre cada Unidad.

OLAP en el Marketing
Anlisis de productos.
Anlisis de Clientes.
Anlisis de Facturacin.

OLAP en Otros Usos
Anlisis de la Produccin.
Anlisis de Servicios al cliente.
Evolucin del Costo del producto.
Pgina 28 de 94

Las etapas que deben cubrirse durante el proceso de construccin de un DW
cumplen con lo siguiente:
1. Identificacin de las necesidades y requerimientos.
2. Reconocimiento de las fuentes de datos originales y sus estructuras.
3. En base a los requerimientos, definir las tablas auxiliares y los
procesos de seleccin, transformacin e importacin de datos.
4. Construir el esquema multidimensional. Debe controlarse que este
esquema concuerde con los requerimientos y las tablas auxiliares,
como primera forma de testeo.
5. Acceso al sistema desde las estaciones de trabajo de los analistas
obteniendo la informacin identificada en la etapa de requerimientos.

Para convertir los datos en informacin, se debe entender de qu manera
pueden interpretarse los datos almacenados en sistemas operacionales,
determinando:
Como los hechos que deseamos medir se relacionan con los datos
que podemos obtener.
Entendiendo cmo estos datos reflejan metas y objetivos que abarcan
el negocio involucrado.
Un DW, clasifica la informacin en base a los aspectos que son de inters
para la empresa.
En el ambiente operacional se disea alrededor de las aplicaciones y
funciones (ventas, facturacin, stock, etc.). La base de datos combina los
Pgina 29 de 94
procesos en una estructura que responde a las necesidades de las reglas del
negocio.
En cambio en un DW, estos elementos se organizan alrededor de sujetos
clientes (vendedores, productos, sucursales, etc.).
Una vez que el anlisis del negocio se reconoce como un valor significativo
para una organizacin, las peticiones de los datos y de la informacin llegan a
ser numerosas y frecuentes.
Satisfacer estas peticiones puede ser una tarea muy compleja en un sistema
OLTP, se debe bucear por grandes cantidades de datos obtenidos de
distintas fuentes, procurando seleccionar, adecuar y consolidar la
informacin. En un sistema OLAP, estos temas se resuelven por nica vez,
en la etapa de diseo.

Los datos que alimentan a un sistema DW provienen de diferentes fuentes,
estas fuentes son los distintos sistemas operacionales que la empresa posee,
generalmente ni son homogneos entre s ni concuerdan exactamente con lo
que se necesita, por lo que ser necesario realizar todas las adaptaciones
pertinentes.

ETL
Los diferentes procesos que se concentran en el concepto de
toma, transformacin y carga de datos en un DW se
denominan ETL, sus siglas en ingls significan Extract
Transform Load.

Pgina 30 de 94
Es comn que los sistemas operacionales que se encuentran en las
organizaciones hayan sido desarrollados por diferentes equipos de
programadores o empresas de software, y en su desarrollo, hayan adoptado
diferentes convenciones en la codificacin de variables, nombres de los
atributos de las tablas, diferentes tipos de datos o formatos de fechas.
Al reunir datos de los diferentes sistemas, se debe definir una norma nica
para el DW y realizar las transformaciones que sean necesarias en cada
caso. Bsicamente deben realizarse las siguientes tareas:
Establecer las reglas que sern utilizadas para realizar la
transformacin.
Detectar las inconsistencias que pueden originarse al tomar los datos
desde distintas fuentes.
Planificar cuidadosamente y con detalles la transformacin de los
datos que den como resultado final conjuntos de datos consistentes.

Convenciones diferentes en el desarrollo de
aplicaciones
Codificacin: Un claro ejemplo es la codificacin y
descripcin del sexo del individuo. Este pudo haber
sido almacenado de diferentes maneras. Por ejemplo,
puede encontrarse como M y F, 1 y 0, Hombre
y Mujer Masculino y Femenino. En la
transformacin, habr que elegir una convencin
nica para el DW, que puede ser M y F y
transformar los datos.

Aplicacin A: M y F
M - F
Aplicacin B: 1 y 0
Aplicacin C: Masculino y
Femenino

Unidades de medida de los atributos: Las unidades
pueden tener distintas unidades de medidas, segn el
origen del sistema OLTP. Un ejemplo es hablar de
litro, centmetros cbicos o hectolitros. Habr que
elegir una nica unidad de medida que sea til para el
DW y transformar los datos.
Pgina 31 de 94

Aplicacin A: Litros
Litros Aplicacin B: cm3
Aplicacin C: Hectolitros

Formatos: Otro claro ejemplo son los formatos de
fecha que encontramos en los diferentes sistemas
operacionales. Las fechas pueden estar almacenadas
como yyyy/mm/dd, mm/dd/yyyy dd/mm/yyyy. En el
desarrollo del sistema DW, debemos elegir alguna de
ellas y realizar la transformacin correspondiente.

Aplicacin A: yyyy/mm/dd
dd/mm/yyyy Aplicacin B: mm/dd/yyyy
Aplicacin C: dd/mm/yyyy

Varias columnas a una: En un sistema OLTP, los
datos de una persona, como ser Direccin pueden
almacenarse en diferentes campos de la misma tabla
(Calle, Nmero, Piso y Departamento). Al transformar
estos datos para que puedan ser utilizados en un
sistema DW, es posible que los almacenemos en una
nica columna. Lo mismo puede suceder con el
Nombre y Apellido. En el sistema OLTP puede estar
almacenado en dos columnas y en OLAP ser
requerido en una sola.

Pgina 32 de 94

Una columna a varios: los sistemas ms antiguos
solan colocar el tipo y nmero de documento en el
mismo campo de la tabla. En un DW, es muy posible
que necesitemos colocar el tipo de documento en un
campo y el nmero de documento en otro.

Granularidad
En el momento de importar los datos desde la fuente de
origen se deben realizar las sumarizaciones que sean
requeridas. Se debe definir la granularidad mxima a
almacenar ene. SW y sumar los datos agrupando segn ese
criterio. Al definirse la granularidad se est diciendo, al
mismo tiempo:

Las aperturas que son de inters.

El grado de detalle que se necesita.

Es decir, si tomamos como ejemplo la medicin del trfico
telefnico, puede definirse que se necesitan los totales de
llamados por cliente por da. Vemos que el mximo detalle
que es requerido es el da, no interesara la hora de la
llamada ni el tiempo de cada una de las llamadas. Por ende
habr que agrupar y sumar utilizando el criterio por Cliente y
Da.

Si se desea tener la cantidad e importe de ventas por mes,
cliente y producto, se debe agrupar por estas tres aperturas,
dejando en el sistema OLTP el detalle por da por factura o
por boca de expendio, obteniendo el resultado que vemos
en el grfico.

Pgina 33 de 94

Una vez que contamos con el plan de trabajo desarrollado segn las reglas
de transformacin, tomamos los datos desde el sistema operacional y los
importamos dentro de nuestra rea de datos. Usaremos para almacenar los
datos de origen tablas auxiliares que nos ayudaran durante la transformacin.

Mala interpretacin de los Requerimientos
Durante la etapa de relevamiento previo al diseo de un
sistema OLAP, es importante entender con precisin la
problemtica del negocio. Esto incluye definir el hecho y qu
medidas sern necesarias desarrollar en el sistema.
Muchos sistemas no llegan a feliz trmino a causa de una
etapa de relevamiento en donde los requerimientos
planteados no apuntan a los objetivos del negocio.

Pgina 34 de 94

Caso de estudio
Relevando los Requerimientos
En la Unidad 1, hemos anotado las necesidades de la Distribuidora
Latinoamericana de Alimentos (DLA) y qu factores se quieren analizar para
la toma de decisiones.
Ahora debemos identificar de qu manera, a travs de las aperturas y las
medidas, vamos a medir los hechos que la empresa necesita analizar.
Teniendo en cuenta que cada punto mencionado en los requerimientos est
referido a las Ventas de la Empresa, podemos decir que el hecho de nuestro
DW sern, justamente, las Ventas.
Vamos a comenzar analizando cada necesidad y cul es la dimensin o
medida que habr que crear para satisfacer la misma. Luego desarrollaremos
una tabla en donde resumiremos la informacin obtenida. Esta tabla nos
servir en la etapa de diseo.
Analizaremos el primer conjunto de necesidades:
La cantidad de unidades vendidas en los pases que alcanza el
Mercado actual.
En esta consigna se detecta como posible medida a las unidades vendidas,
la cual necesitamos ver detallada por Pas. Por otro lado, la cantidad de
unidades vendidas est referida a los productos: detectamos ya una nueva
dimensin, el Producto.
El coste inducido en cada unidad vendida.
De este requerimiento se desprende la medida costo de ventas.
Aqu necesitaremos contar con la medida Importe de ventas, sabiendo que
utilizaremos la dimensin Producto para obtener el Valor de la Venta de cada
Producto.
La medida Ganancia obtenida, se obtendr de la diferencia entre el Importe
de la venta y el costo del producto.
Esta informacin, requiere que sea presentada por zona geogrfica y
sucursal. Aqu tenemos una nueva dimensin que llamaremos Sucursal.
Ahora analizaremos el segundo conjunto de requerimientos:
A su vez, la empresa quiere:
Armar canastas de productos de acuerdo al perfil de compra de los
Pgina 35 de 94
clientes de cada ciudad en la que tienen una boca de expendio. Para
esto requieren un estudio de las ventas realizadas abiertas por
categora de producto (con la posibilidad de obtener el detalle por
producto), por ciudad, por mes, para los ltimos 13 meses (para
detectar estacionalidades).
Vemos que se nos pide analizar los productos segn su categora y los
clientes que los adquirieron. De aqu se desprende que necesitamos una
nueva dimensin Clientes y que los Productos deben mostrarse agrupados
por Categora de Productos, cosa que nos define un nivel en la dimensin
Producto.
Premiar anualmente a aquellos vendedores que superen los objetivos
de venta que les fueran asignados. El anlisis, en este caso deber
incluir a los vendedores, las ventas realizadas, los objetivos de venta y
el indicador de cumplimiento detallados por mes para el ao fiscal (El
premio ser distinto si se cumple con los objetivos globalmente para el
ao o si, adems, se cumplen los objetivos en todos los meses en
particular).
Sobre estos requerimientos, debemos agregar solamente la dimensin
Vendedor, ya que las medidas que utilizaremos son las mismas que hemos
relevado anteriormente.
Teniendo en cuenta que la empresa llega a los clientes tanto por
Supermercados como por Hipermercados, podra ser de suma utilidad el
realizar el anlisis de cada una de las medidas por Tipo de Sucursal.
Todo sistema DW contiene informacin histrica que la empresa analizar
para diferentes perodos, agregaremos una dimensin ms denominada
Tiempo.
A su vez, es comn que sea necesario que se quieran analizar las ventas
obteniendo el promedio de las mismas. Por lo tanto, viendo esta posible
necesidad, sera conveniente que desarrollar la medida Ventas Unidades
Promedio.
Para ver la informacin obtenida en los relevamientos de una manera ms
clara y comprensible, es conveniente armar una tabla de doble entrada en
donde colocaremos en las filas las medidas y en las columnas las
dimensiones. Luego, en las intersecciones de medidas y columnas,
colocaremos una cruz si es necesario ver la medida por esa dimensin.
Hecho a medir: Venta de Productos

Dimensiones
Medidas Tiempo Sucursal Vendedor Cliente Producto
Ventas_Importe X X X X X
Ventas_Costo X X X X X
Ventas_Unidades X X X X X
Ventas_ImporteTotal X X X X X
Ventas_Ganancia X X X X X
Ventas_Promedio X X X X X
Esta tabla resumen es de suma utilidad para ver con claridad los
Pgina 36 de 94
requerimientos, agrupar por apertura y comenzar a definir los cubos a crear.

Se conoce con mayor profundidad la estructura de
un sistema OLTP.
Se comprende dnde se utiliza un sistema OLTP.
Se conoce de qu manera se estructura un sistema
OLAP.
Se conoce con detalles en qu reas se utiliza un
sistema OLAP.
Se conocen las inconsistencias que puede haber
cuando se alimenta un sistema OLAP desde un
sistema operacional.
Se comprende la manera en que los datos son
transformados antes de llegar al sistema OLAP.

Ha relevado los Hechos que son de inters?
Ha relevado las aperturas por las cuales se analizar la
informacin?
Ha relevado las medidas o indicadores que se usarn
para evaluar los Hechos?
Cul es la granularidad con que es necesaria ver la
informacin en el sistema OLAP?
Tiene definidas las fuentes de donde va a extraer los
datos?
Tiene definidos los formatos de los archivos de
transferencia y de los datos que stos incluyen?
Dise los procesos de seleccin, transformacin y carga
de datos (ETL)?

Unidad 3. Diseando una solucin OLAP

Objetivos

Pgina 37 de 94

Comprender la formacin de la tabla de hechos
Entender que son las medidas
Conocer que son las dimensiones y como se
organizan
Distinguir la diferencia entre los esquemas estrella y
copo de nieve.
Diferenciar las medidas naturales de las calculadas


3.5 Introduccin
3.6 Construyendo el data mart
3.7 Esquema Estrella
3.7.2 Dimensiones
3.7.2.2 Esquema Estrella
3.7.2.3 Esquema Copo de Nieve
3.7.2.4 Padre Hijo (Parent- Child)
3.8 Medidas

Pgina 38 de 94
3.1. Introduccin

Con lo aprendido en las unidades anteriores, podemos comenzar a definir el
diseo de nuestra base de datos OLAP.
En esta unidad, desarrollaremos el diseo de las tablas que conforman el
plano de un data mart (DM) que nos servir de estructura para el posterior
armado del cubo.
Al final de este mdulo, el lector comprender cmo definir la tabla de
hechos, cmo se pueden organizar las dimensiones, y qu son las medidas.

La estructura que forman la Tabla de Hechos y las Dimensiones
puede verse como el plano o la visin desplegada del cubo.

Pgina 39 de 94

Data Mart: son almacenes de datos con informacin de
inters particular para un determinado sector de la empresa
Data Warehousing: es el conjunto de almacenes de datos
particulares (Data Mart) con informacin de inters para la
empresa en general

Cada uno de los siguientes son ejemplos Data Mart (DM)
Ventas
Recursos Humanos
Produccin
El Data Warehousing es el conjunto de esos data mart
DM de Ventas + DM de Recursos Humanos + DM
de Produccin
3.2. Construyendo el data mart
Hasta ahora hemos analizado los requerimientos del usuario, y depuramos
sus datos para la formacin del data warehousing, en esta unidad
comenzaremos a disear el modelo del data mart. Este modelo, ser el paso
previo al armado de nuestra base de datos OLAP.
En esta etapa vamos a modelar las tablas relacionales en una gran estructura
desnormalizada, compuesta por tabla de hechos, y tablas ms pequeas
que definirn las n-dimensiones o aperturas de nuestro cubo, llamadas tablas
de dimensiones.
Para ello, primero debemos conocer algunos conceptos que tendremos en
cuenta en la construccin del modelo.

3.3. Esquema Estrella
Para facilitar el anlisis, el data mart organiza los datos en una estructura
llamada esquema de estrella.
Esta estructura esta compuesta por una tabla central - tabla de hechos - y
un conjunto de tablas organizadas alrededor de sta - tablas de
dimensiones.
En las puntas de la estrella se encuentran las tablas de dimensin que
contienen los atributos de las aperturas que interesan al negocio que se
pueden utilizar como criterios de filtro y son relativamente pequeas. Cada
tabla de dimensin se vincula con la tabla de hechos por un identificador.
Las caractersticas de un esquema de estrella son:
El centro de la estrella es la tabla de hecho.
Pgina 40 de 94
Los puntos de la estrella son las tablas de dimensiones.
Cada esquema esta compuesto por una sola tabla de hechos
Generalmente es un esquema totalmente desnormalizado, pudiendo
estar parcialmente normalizado en las tablas de dimensiones.

En el ejemplo construimos un esquema estrella considerando que
se necesita analizar como evoluciona la Admisin de Pacientes
(Hecho) por servicio, pacientes y zona geogrfica a lo largo del
tiempo.

El modelo dimensional divide el mundo de los datos en dos grandes tipos: las
medidas y las dimensiones de estas medidas.
Las medidas, siempre son numricas, se almacenan en las tablas de hechos
y las dimensiones que son textuales se almacenan en las tablas de
dimensiones.
La tabla de hechos es la tabla primaria del modelo dimensional, y contiene
los valores del negocio que se desea analizar.
Cada tabla de hechos contiene las claves externas, que se relacionan con
sus respectivas tablas de dimensiones, y las columnas con los valores que
sern analizados.
Dimensin
Servicio
Dimensin
Paciente
Dimensin
Tiempo
Tabla de Hechos
Admisin Pacientes

Dimensin
Zona
Geogrfica
Pgina 41 de 94

Un hecho es un concepto de inters primario para el proceso
de toma de decisiones, corresponde a eventos que ocurren
dinmicamente en el negocio de la empresa.

3.3.2 Dimensiones
Disearemos y construiremos cada dimensin basados en los procesos de
negocio definidos por el cliente.
Las dimensiones organizan los datos en funcin de un rea de inters para
los usuarios.
Cada dimensin describe un aspecto del negocio y proporciona el acceso
intuitivo y simple a datos.
Una dimensin provee al usuario de un gran nmero de combinaciones e
intersecciones para analizar datos.
Las tablas de dimensiones son las compaeras de las tablas de hechos.
Cada dimensin se define por su clave primaria que sirve para mantener la
integridad referencial en la tabla de hechos a la que se relaciona.
Un cubo requiere que se defina al menos una dimensin en su esquema.
Cada nivel de una dimensin debe corresponderse con una columna en la
tabla de la dimensin. Los niveles se ordenan por grado de detalle y se
organizan en una estructura jerrquica. Cada nivel contiene miembros, los
miembros son los valores de la columna que define el nivel.
Entre los miembros y entre los niveles de una dimensin existen relaciones,
estas se pueden comprender como las relaciones que existen en un rbol
genealgico donde los trminos padre, hijo, hermano, primo, etc. indican una
correspondencia entre elementos del rbol; y los miembros de la dimensin
se comportan como familiares dentro del rbol genealgico.
Padre: Es el miembro del nivel inmediatamente superior que se
relaciona con el miembro seleccionado. Cada elemento tiene un solo
padre.

Ejemplos de Hechos
En un hospital: admisin de pacientes
En un operador telefnico: Trfico telefnico
Pgina 42 de 94
Hijo: Son los elementos del siguiente nivel inferior que se relacionan
con el miembro seleccionado. Pueden existir varios hijos para un mismo
miembro.

Hermano: Son los miembros que se encuentran en el mismo nivel que
el miembro seleccionado y poseen el mismo padre.

Primo: Son los miembros que se encuentran en el mismo nivel que el
miembro seleccionado, pero que tienen diferentes padres. Los primos
tiene padres que son hermanos.

Descendientes: Son todos los miembros que se encuentran debajo
del nivel del miembro seleccionado. independientemente de la cantidad de
niveles que los separen.

Ancestros: Son todos los miembros que se encuentran por encima del
nivel del miembro seleccionado.
Un miembro es independiente de las relaciones. Cada integrante de la
dimensin es miembro de ella.
Pgina 43 de 94
Ejemplos de dimensin
Dimensin zona geogrfica

* PAIS ARGENTINA BRASIL URUGUAY
**
PROVINCIA
BUENOS
AIRES
CORDOB
A
SAN
PABLO
MONTEVID
EO
*** CIUDAD
MAR
del
PLAT
A
LA
PLAT
A
VILLA
GRAL.
BELGRA
NO
.
Ejemplos de relaciones
En una dimensin zona geogrfica tendramos las
siguientes relaciones entres niveles y entre miembros:
Padre:
Argentina es padre de Buenos Aires y de Crdoba
Hijo:
Buenos Aires y Crdoba son hijos de Argentina
Hermano:
Buenos Aires y Crdoba son hermanos el uno al otro,
tambin son hermanos Argentina, Brasil y Uruguay.
Primo:
Mar del Plata es primo de Villa General Belgrano.
Descendiente:
Todos los miembros que estn por debajo de Argentina
son sus descendientes, por ejemplo Buenos Aires, Mar del
Plata y Villa General Belgrano son alguno de sus
descendientes.
Ancestro:
Mar del Plata tiene dos antepasados Buenos Aires y
Argentina.

Las dimensiones pueden ser:
Locales
Compartidas
Las dimensiones locales son las que se definen y se utilizan dentro de un
mismo cubo.
Las dimensiones compartidas son aquellas dimensiones que se definen
independientes de los cubos y pueden ser utilizadas por varios de ellos.
Ventajas de las dimensiones compartidas
Pgina 44 de 94
Evitamos duplicar dimensiones locales
Aseguramos que los datos analizados estn organizados de la misma
forma en todos los cubos, lo que implica un menor costo de
mantenimiento.
Desventajas de las dimensiones compartidas
Deben emplearse del mismo modo en los cubos que las usen.
Un cambio implica que la dimensin deber ser modificada en todos
los cubos

Ejemplos de Dimensin Compartida
La dimensin Producto puede utilizarse para el Data
Mart Ventas y para el Data Mart Produccin.
As, la dimensin producto es una dimensin compartida
por los dos Data Mart.

Al definir una dimensin debemos prestar especial
atencin en los requerimientos del cliente, ya que una
mala definicin de la dimensin, o de sus niveles podra
implicar que no obtengamos los resultados deseados.
Si la definicin de las dimensiones no es la correcta, no
sern correctos ni tiles las agrupaciones, las
sumarizaciones o los filtros. Probablemente se termine
copiando datos a una planilla de calculo como sino
existiera el DM.
Riesgos de Dimensiones Compartidas
Es importante que nos aseguremos que cualquier
modificacin o cambio en una dimensin compartida sea
vlida para todos los cubos que la empleen

3.3.2.2 Dimensiones: Esquema Estrella
En el esquema estrella cada dimensin esta compuesta por una sola tabla,
esta tabla esta desnormalizada.
El esquema se denomina as debido a que el diagrama se parece a una
estrella.
Debido a que las tablas de dimensin estn desnormalizadas lograremos en
el modelo del data mart, una menor cantidad de tablas.
Pgina 45 de 94

Este es un esquema donde las dimensiones tienen un esquema
estrella.

3.3.2.3 Dimensiones: Esquema Copo de Nieve
El esquema copo de nieve es una variacin del esquema estrella donde
alguna punta de la estrella se explota en ms tablas.
El nombre del esquema se debe a que el diagrama se asemeja a un copo de
nieve.
En este esquema, las tablas de dimensin copo de nieve se encuentran
normalizadas para eliminar redundancia de datos.
A diferencia del esquema estrella, los datos de las dimensiones se reparten
en mltiples tablas.
Como ventaja del esquema destacamos el ahorro de espacio de
almacenamiento en disco, pero en perjuicio de un aumento en la cantidad de
tablas.
Los siguientes son las caractersticas de un copo de nieve:
La dimensin esta normalizada
Los distintos niveles se encuentran almacenados en tablas separadas
Se argumenta ahorro de espacio

Dimensin
Servicio
Dimensin
Paciente
Dimensin
Tiempo
Tabla de Hechos
Admisin Pacientes

Dimensin
Zona
Geogrfica
Pgina 46 de 94

Se muestra un esquema donde la dimensin zona geogrfica
presenta un esquema copo de nieve.

Ejemplo de Tabla Normalizada y Tabla Desnormalizada
En la imagen vemos en la tabla normalizada los datos nombre
de pas y nombre de provincia aparecern una sola vez en las
tablas Pas y Provincia respectivamente.
Si en cambio, la tabla esta desnormalizada tendremos
redundancia de datos, ya que se repetirn los datos del Pas y
de la Provincia por cada Ciudad.

Estrella Copo de nieve
Cantidad de tablas Menor Mayor
Normalizada

Zona Geogrfica

Id _ Pas
Pas
ID_Provincia
Provincia
ID_Ciudad
Ciudad

Provincia

ID_ Provincia
Provincia
ID_Pas

Desnormalizada

Pas

ID_Pas
Pas

Ciudad

ID_ Ciudad
Ciudad
ID_Provincia

Ciudad

Paciente
Provincia
Pas
Copo de nieve
Dimensin zona
Geografica

Servicio

Tiempo

Admisin
Paciente

Pgina 47 de 94

Consultas
Mejora la performance Aumenta la cantidad de
uniones entre tablas
provocando baja en la
perfomance
Almacenamiento

Aumenta el espacio Ahorra espacio

3.3.2.4 Dimensiones: Padre Hijo (Parent Child)
Una dimensin padre-hijo es una dimensin donde el dato del Padre se
relaciona con el Hijo y ambos se encuentran en la misma tabla de dimensin,
es decir, la dimensin se relacionan consigo misma.

Ejemplos de Dimensin Padre - Hijo
La dimensin Cuenta Contable donde una cuenta
imputable forma parte de un Sub Rubro y el Sub Rubro a
su vez forma parte de un Rubro. Estos datos se encuentran
en un solo Plan de Cuentas.
La cuenta Activo, contiene los rubros Inversiones, Crditos
y Caja, y el rubro Caja a su vez contiene Caja y Fondo Fijo.

Las dimensiones virtuales, no requieren un almacenamiento fsico en el cubo,
se evalan en el momento de la consulta.
Funcionan de manera similar a las dimensiones reales y son transparentes
para el usuario.
Pgina 48 de 94

Ejemplos de Dimensin Virtual
Podemos tener una dimensin Producto organizada de la
siguiente manera:
Producto (Dimensin real)

Fabricante
Marca
Calibre
Producto

Si el usuario requiere que sus anlisis de informacin se
realicen por Marca, utilizando la dimensin Producto
requerir seleccionar a cada fabricante para obtener la
informacin de la marca.
Para evitar esto, podemos crear una dimensin virtual
donde el orden de los niveles Fabricante - Marca estn
invertidos, que le permita ver sus datos por Marca sin
necesidad de seleccionar a todos los fabricantes. Esta
dimensin la construiremos de la siguiente manera:

Producto_Marca (Dimensin virtual 1)

Marca
Fabricante
Calibre
Producto

Otra necesidad del usuario podra ser obtener los totales o
filtros de calibre sin importar la marca o el fabricante,
entonces construiramos una dimensin virtual que
contenga solo la columna calibre.

Calibre (Dimensin virtual 2)
Calibre

Mencionaremos esta dimensin ya que ocupa un lugar especial en cada data
mart. Recordemos que el tiempo es parte implcita de la informacin que
contiene el data mart.
Esta dimensin la podemos definir separndola en distintas jerarquas de
tiempo:
Ao
Semestre
Mes
Pgina 49 de 94

Ejemplos de Dimensin Tiempo

La definicin de la jerarqua la haremos teniendo en cuenta las necesidades
que tiene la organizacin. Debemos contemplar los periodos de tiempo por
los cuales la informacin necesita ser analizada y la regularidad con la que
se cargaran los datos en el cubo.
Consideraciones para esta dimensin:
Nombres de los miembros: Cuando construyamos la dimensin tiempo es
conveniente que los nombres de los miembros sean nicos. As, si utilizamos
una nomenclatura para la jerarqua MES que sea Mes Ao cuando
busquemos un periodo debemos identificarlo como Julio 2006. De esta
manera nos ahorramos de utilizar dos niveles de la dimensin logrando una
mayor calidad en los informes.
Si en cambio, el nombre de la jerarqua MES se compone solo del nombre del
mes, para identificar el periodo Julio del 2006 primero debemos seleccionar
sobre el nivel Ao y luego sobre el nivel Mes.
Puede existir mas de una: Cabe aclarar que no necesariamente esta
dimensin es nica dentro del cubo, podramos tener que armar ms de una
dimensin Tiempo. Si necesitramos analizar la informacin de la empresa
en base al ao calendario y realizar otro anlisis basndonos en el ao fiscal,
deberamos construir dos dimensiones de tiempo para el mismo data mart.
3.4. Medidas
Las medidas son los valores de datos que se analizan.
Una medida es una columna cuantitativa, numrica, en la tabla de hechos.
Las medidas representan los valores que son analizados, como cantidad de
pacientes admitidos o llamadas efectuadas.
Las medidas son:
Valores que permiten analizar los hechos
Valores numricos porque estos valores son las bases de las cuales el
usuario puede realizar clculos.
Si la medida fuera un valor no numrico debemos codificarla a un valor
numrico en el proceso de obtencin de datos, y luego cuando tengamos que
exponer sus valores decodificarla para mostrarla con el valor original.
Las siguientes son algunas de las caractersticas de las medidas:
Pgina 50 de 94
Deben ser numricas.
Cruzan todas las dimensiones en todos los niveles.
Las medidas pueden clasificarse en:
Naturales
Calculadas

Ejemplos de Medidas
En un hospital, donde el hecho es Admisin de
Pacientes las medidas pueden ser:
Pacientes Admitidos
Pacientes Atendidos
En un operador telefnico, donde el hecho es Trafico
Telefnico, las medidas pueden ser:
Llamadas Cantidad
Llamadas Duracin
Ejemplos de Medidas no numricas
Supongamos el hecho Recursos Humanos, donde
podemos tener la medida Sexo que toma los valores F o
M.
Estos valores debemos codificarlos en valores numricos
durante el proceso de transformacin de datos (ETL). As,
por ejemplo tendremos 0=F y 1=M.
Cuando el usuario visualice esta medida, debemos volver
los datos a sus valores originales (decodificarlos) para
mostrar F o M.

Son las columnas numricas que queremos analizar que provienen
directamente de los sistemas OLTP.
Cuando definimos una medida debemos tener en cuenta cual ser la forma
de agregacin (agrupacin de la misma) al subir por la estructura
dimensional.
Estas formas de agregacin pueden ser:
Suma: es la operacin que suma los valores de las columnas
Cuenta: realiza un conteo de los valores
Mnima: devuelve un valor mnimo
Mxima: proporciona el mayor de los valores
Pgina 51 de 94
Cuenta de Distintos: cuenta los valores diferentes

Las agregaciones son resmenes de datos
precalculados que mejoran el tiempo de respuesta
por el simple hecho de tener preparadas las
respuestas antes de que se planteen las preguntas.

Son las medidas que se calculan en el cubo en base a los valores de las
medidas naturales.
El sentido de la expresin medidas calculadas es muy amplio y engloba a
cualquier manipulacin de las medidas naturales que nos faciliten el anlisis
de los hechos.
En una medida calculada puede haber:
Clculos Matemticos
Expresiones condicionales
Alertas
Estos tres tipos (clculos, condiciones y alertas) usualmente pueden existir
juntos dentro de la misma medida calculada.

Pgina 52 de 94

Calculo Matemtico
En un sistema de RRHH, podemos querer medir el
promedio de horas extras por mes. Definimos la medida
calculada Promedio de Horas Extras que ser el resultado
de hacer Horas Extras dividido Dotacin.
Expresiones condicionales
Para la medida calculada anterior, Promedio de Horas
Extras, necesitaremos verificar la condicin de numerador
diferente de cero para evitar que la divisin nos arroje un
error.
Si Dotacin es distinto de cero entonces Promedio de
Horas Extras ser igual a Horas Extras dividido Dotacin.
Si Dotacin es igual a cero entonces Promedio de Horas
Extras se mostrara vaci.
Alertas
En un hospital, podemos definir la medida calculada
Sobrecarga de Pacientes que tomara el valor 1 si los
Pacientes Admitidos (medida natural) es mayor a 100, de lo
contrario permanecer vaca.
Podemos construir una medida Cumplimiento de Ventas
que sea una alerta del tipo semforo y nos indique
Rojo: Si las unidades vendidas son menores a las
unidades presupuestadas dividido 5, es decir, vendimos
menos que el 20 % de lo presupuestado.
Amarillo: Si el valor de las unidades vendidas est entre
unidades presupuestadas dividido 3 y unidades
presupuestadas dividido 5 (el valor vendido esta entre el
20 % y el 80 % de lo presupuestado).
Verde: Si no se cumple ninguna de las condiciones
anteriores, es decir, vendimos ms del 80 % de lo
presupuestado.

Pgina 53 de 94

Caso de Estudio

Ilustraremos los conceptos que aprendimos en esta unidad con nuestro
ejemplo de La Distribuidora Latinoamericana de Alimentos (DLA).
Construiremos el modelo del data mart de ventas en tres etapas:
Etapa 1 Construccin de las Dimensiones
Etapa 2 Armado de la Tabla de Hechos
Etapa 3 Definicin de las Medidas
Construccin de las Dimensiones
Como primer paso definiremos las dimensiones porque estas nos darn las
aperturas del cubo.
En base a definiciones surgidas de los reuniones de trabajo con los
representantes de DLA, vimos que necesitan analizar sus datos segn el
siguiente cuadro:

Hecho a medir: Venta de Productos

Dimensiones
Medidas Tiempo Sucursal Vendedor Cliente Producto
Ventas_Importe X X X X X
Ventas_Costo X X X X X
Ventas_Unidades X X X X X
Ventas_ImporteTotal X X X X X
Ventas_Ganancia X X X X X
Ventas_Promedio X X X X X

Si trabajamos en forma correcta, debera haber una exacta coincidencia entre
la definicin de las dimensiones y los datos que estamos extrayendo de las
fuentes transaccionales. Si esa coincidencia no ocurre, en alguna de las dos
etapas tenemos un error, o bien los datos de origen no estn correctos o bien
definimos mal las dimensiones.
Comenzaremos por la Dimensin Tiempo ya que, como aprendimos en esta
unidad, es la ms importante dentro de cualquier data mart.
Nuestro cliente necesita analizar sus datos diariamente, entonces definiremos
los niveles:
Ao
Semestre
Pgina 54 de 94
Trimestre
Mes
Da

La tabla de dimensin quedara formada:

Dimensin Sucursal, usaremos un esquema estrella y su estructura jerrquica
ser:

Dimensin Vendedor, al igual que sucursal, tendr un esquema estrella y
quedar definida por los niveles:

Dimensin Cliente tendr todos los atributos de un cliente.

Dimensin Producto, esta dimensin la construiremos segn un esquema
copo de nieve. En estos casos se mantiene la normalizacin propia de los
Dimensin Cliente
* Pas
** Provincia
*** Ciudad
**** Razn Social
Dimensin Vendedor
* Sucursal
** Seccin
*** Vendedor
Dimensin Tiempo
* Ao
** Semestre
*** Trimestre
**** Mes
***** Da
Dimensin Sucursal
* Sucursal
** Tipo Sucursal
*** Pas
**** Provincia
***** Ciudad
Pgina 55 de 94
sistemas OLTP. Cada tabla contiene los datos iniciales y su relacin con el
resto.
La dimensin nos quedar normalizada por lo que usaremos ms tablas para
construirla.
Nuestro cliente puede clasificar sus productos segn la categora, el
departamento y la familia de producto a la que pertenece.

Armado de la Tabla de Hechos
Ahora que tenemos definidas las dimensiones y sus niveles, conformaremos
la tabla de Hechos.
La tabla de hechos debe tener las columnas claves de las tablas de las
dimensiones y las columnas de las medidas.
Primero colocaremos las columnas claves de la tabla cada una de las tablas
de dimensiones.

Definicin de las Medidas
Recordemos que las medidas son los valores numricos que el usuario desea
Fact_Ventas
ID_Fecha
ID_Producto
ID_Cliente
ID_Vendedor
Pgina 56 de 94
analizar.
Vimos que nuestro cliente necesita medir:
El coste inducido en cada unidad vendida

Agregaremos a nuestra tabla de hechos ventas estas medidas:

La medida ganancia obtenida en la venta de cada producto no la
agregamos a la tabla porque esta medida puede ser calculada a partir de las
medidas naturales ventas importe y ventas costo.
Nuestro modelo contar tambin con las medidas calculadas:
Ventas_Ganacia que tendr la formula Ventas_Importe menos
Ventas_Costo
Ventas_Promedio que ser el resultado de la suma de
Ventas_Unidades dividido cantidad de das, comprobando la condicin
del numerador diferente de cero.
Realizadas estas tres etapas, podemos ver el diseo completo de nuestro
data mart.
Fact_Ventas
ID_Fecha
ID_Producto
ID_Cliente
ID_Vendedor
Ventas_Importe
Ventas_Costo
Ventas_Unidades
Pgina 57 de 94

Lecciones Aprendidas

Un Data Mart adopta un esquema estrella para
maximizar la performance de las consultas.
Las dimensiones son categoras descriptivas
por las cuales las medidas se pueden separar
para el anlisis.
La dimensin Tiempo esta implcita en todo
Data Mart
Las medidas son los datos numricos de
inters primario para el cliente
Con las medidas calculadas se pueden
construir alertas

Pgina 58 de 94

Preguntas de Reflexin
Tenemos claramente definidos los requerimientos?
Conocemos los hechos que se quieren analizar, los
indicadores y las aperturas por las cuales se quiere
hacer el anlisis?
Concuerda esta definicin con las tablas auxiliares que
creamos y poblamos con datos de los sistemas OLTP?
Sabemos si los usuarios utilizarn las dimensiones para
navegar o para filtrar?
Cubren las dimensiones diseadas las necesidades de
los usuarios intuitivamente y con facilidad de manejo?
Se tienen todas las medidas naturales con las aperturas
requeridas?
Est definida la forma de agregacin, al salir de la
granularidad mnima, para todas las medidas naturales?
Estn definidas las frmulas o criterios de todas las
medidas calculadas?
Estn correctamente documentadas todas las
definiciones?

Unidad 4. Construyendo una solucin OLAP

Objetivos

Diferenciar los distintos modos de almacenamiento
Comprender qu es y como definir el porcentaje de
agregacin
Conocer la posibilidad del uso particiones
Entender el manejo de los Cubos Virtuales
Mejorar los tiempos de procesamiento
Optimizar el espacio de almacenamiento


Pgina 59 de 94
4.8. Introduccin
4.2.1. MOLAP
4.2.2. ROLAP
4.2.3. HOLAP
4.13. Particiones

4.1. Introduccin

En esta unidad abordaremos los conceptos a tener en cuenta para la
implementacin del data mart. Describiremos los distintos tipos de
almacenamiento y las consideraciones que debemos analizar para mejorar la
performance del sistema.
Adems, veremos con que frecuencia es conveniente procesar nuestros
cubos y explicaremos el uso de los cubos virtuales y particiones.
Al final de este modulo, el lector conocer qu modo de almacenamiento ser
el ms adecuado para los requerimientos de la organizacin, como balancear
los distintos factores que intervienen al implementar un cubo.
Pgina 60 de 94
Haciendo un pequeo balance de las unidades anteriores, vemos que ya
tenemos: un diseo de requerimientos, sabemos de dnde y cmo obtener
los datos y ya contamos con la definicin de la estructura multidimensional.
Ahora que vamos a armar fsicamente el cubo debemos elegir entre los
distintos modos de almacenamiento que podemos utilizar. Para facilitar esta
eleccin, desarrollaremos los conceptos de MOLAP, ROLAP y HOLAP y
luego haremos una comparacin de los mismos.
4.2.1. MOLAP
En el modo de almacenamiento MOLAP (OLAP Multidimensional) una
copia de los datos de origen del cubo, junto con sus agregaciones, es
almacenada en una estructura multidimensional.
Debemos tener en cuenta que mientras los datos de origen cambian
directamente con las operaciones, los objetos con almacenamiento MOLAP
deben ser procesados para incorporar estos cambios.
El tiempo comprendido entre un procesamiento y el siguiente, crea un periodo
de latencia durante el que puede que la informacin OLAP no coincida con
los datos de origen actuales.
Como caracterstica del almacenamiento MOLAP podemos desatacar:
Provee excelente rendimiento y compresin de datos.
Tiene mejor tiempo de respuesta, dependiendo solo del porcentaje de
las agregaciones del cubo.
La estructura est muy optimizada para maximizar el rendimiento de
las consultas.
En general este mtodo, es muy apropiado para cubos con uso
frecuente por su rpida respuesta.

4.2.2. ROLAP

Base de Datos
Relacional
Vista de
Usuario
Base de Datos
Multidimensional
AGREGACIONES
Y DATOS
Pgina 61 de 94
En un modelo ROLAP (OLAP Relacional) toda la informacin del cubo, sus
datos, su agregacin, sumas, etc., son almacenados en una base de datos
relacional.
A diferencia del modo de almacenamiento MOLAP, ROLAP no almacena
copia de la base de datos, accede a las tablas originales cuando necesita
responder a las consultas, generalmente es mucho ms lenta que las otras
estrategias de almacenamiento (MOLAP o HOLAP).
ROLAP se utiliza para ahorrar espacio de almacenamiento cuando se trabaja
con grandes conjuntos de datos que se consultan con poca frecuencia; por
ejemplo, datos exclusivamente histricos.
Los usos comunes de este esquema son:
Cuando los clientes desean ver los cambios inmediatamente.
Cuando contamos con grandes conjuntos de datos que no son
frecuentemente buscados

4.2.3. HOLAP
HOLAP (OLAP hbrido) combina atributos de MOLAP y ROLAP.
Al igual que MOLAP, HOLAP hace que las agregaciones se almacenen en
una estructura multidimensional, y los datos a nivel de detalle, en una base
de datos relacional como lo hace el almacenamiento ROLAP.
Para procedimientos de bsqueda que accedan datos sumarizados, HOLAP
es equivalente a MOLAP. Por el contrario, si los procesos de consultas
accedieran a los mximos niveles de detalle, deberan recuperar los datos de
la base de datos relacional y esto no seria tan rpido comparado con una
estructura MOLAP.
Los cubos almacenados como HOLAP, son ms pequeos que los MOLAP y
responden ms rpidos que los ROLAP.
Usos comunes de HOLAP
Cubos que requieren rpida respuesta
Cuando existen sumarizaciones basadas en una gran cantidad de
datos de origen.
Base de Datos
Relacional
Vista de
Usuario
Base de Datos
Multidimensional
AGREGACIONES
Y DATOS
Pgina 62 de 94
Solucin de compromiso para bajar el espacio ocupado sin perjudicar
totalmente el rendimiento de las consultas.

Debemos tener en cuenta que si los usuarios generan
consultas que deben utilizar los datos del nivel mas bajo
HOLAP no suele ser la mejor opcin

Ejemplo del operador telefnico. Supongamos que:
Se miden las llamadas realizadas x Da y x Cliente.
El tiempo se estructura en Da Mes Ao.
Los Clientes se estructuran en Cliente Ciudad Pas.
Definicin MOLAP ROLAP HOLAP
Datos
detallados
Llamadas para un Da y
Cliente
EM BR BR
Datos
sumarizados
Suma de llamadas para
algn cruce de Cliente
Tiempo donde al menos
uno de las dos dimensiones
no est en el mnimo nivel.
(Cliente y Mes Ao, Da y
Ciudad o Pas, etctera)
EM BR EM
EM = Estructura Multidimensional
BR = Base de Datos Relacional

Base de Datos
Relacional
Vista de
Usuario
Base de Datos
Multidimensional
DATOS AGREGACIONES
Pgina 63 de 94

MOLAP ROLAP HOLAP
Almacenamiento
de las
Agregaciones
Modelo
Multidimensional
Base de datos
relacional
Modelo
Multidimensional
Almacenamiento
de los datos
Modelo
Multidimensional
Base de datos
relacional
Base de datos
relacional
Facilidad de
Creacin
Sencillo Muy Sencillo Sencillo
Velocidad de
respuesta
Buena Regular o Baja Buena para
consultas que
posean
agregaciones,
Regular para datos
de bajo nivel
Escalabilidad Problemas de
escalabilidad
Son ms
escalables

Recomendados
para
Cubos con uso
frecuente
Datos que no
son
frecuentemente
usados
Si el cubo requiere
una rpida
respuesta

Ventajas Desventajas
MOLAP
Mejor performance en los tiempos
de respuesta
Duplica el
almacenamiento de datos
(ocupa ms espacio)
Tiempo de Latencia
ROLAP
Ahorra espacio de
almacenamiento. til cuando se
trabaja con muy grandes conjuntos
de datos.
El tiempo de respuesta
a consultas es mayor.
HOLAP
Buen tiempo de respuesta slo
para informacin sumarizada
Volmenes de datos
ms grandes en la base de
datos relacional

Pgina 64 de 94

MOLAP es un OLAP basado en el acceso a una base
de datos multidimensional
ROLAP es un OLAP basado en el acceso a una base
de datos relacional
HOLAP es un OLAP situado entre ROLAP y MOLAP,
accede a la Multidimensional y a la Relacional.

Otro factor para considerar en la implementacin del modelo OLAP, adems
del modo de almacenamiento, es la definicin del porcentaje de
agregaciones.
Se denomina agregacin al proceso de precalcular el clculo de los datos a
travs de los niveles, para disminuir los tiempos de respuestas en los
procesos de bsquedas de informacin. El porcentaje de agregacin da idea
de la proporcin o profundidad hasta la que se realizarn los preclculos.
Las agregaciones se almacenan en la estructura multidimensional (segn el
modo de almacenamiento que escogimos).

Cuando definamos agregaciones debemos tener en cuenta de especificar las
restricciones de almacenamiento y de porcentaje de agregacin, a fin de
lograr una buena solucin de compromiso entre el tiempo de respuesta a las
consultas y los requisitos de almacenamiento.
Si calculramos todas las agregaciones posibles necesitaremos gran
cantidad de tiempo de procesamiento y espacio de almacenamiento. Si por el
contrario, no se precalculan agregaciones (0%), la cantidad de espacio de
almacenamiento que se necesita se reduce al mnimo, pero el tiempo de
respuesta aumenta.
Por lo tanto, suele existir un equilibrio entre el espacio de almacenamiento, el
porcentaje de posibles agregaciones que se precalculan y la performance
requerida.
En la figura mostramos la grafica de esta relacin:

Las agregaciones son resmenes de datos precalculados
que mejoran el tiempo de respuesta por el simple hecho de
tener preparadas las respuestas antes de que se planteen
las consultas.
Pgina 65 de 94

En el grfico podemos observar que llega un punto en el cual ya no se
consigue un aumento significativo en las agregaciones (debemos recordar
que, en este contexto, aumentar las agregaciones el sinnimo de mejorar la
performance en las consultas), a pesar de aumentar la cantidad de espacio
de almacenamiento. Debemos escoger un porcentaje situado en la zona del
punto A, donde logramos el mximo porcentaje de agregacin con la menor
cantidad de espacio posible.
Caractersticas de las agregaciones:
Las agregaciones permiten mejorar los tiempos de respuesta
Requieren de almacenamiento adicional
Si no son controladas pueden provocar una explosin en los requisitos
de almacenamiento

A mayor nmero de agregaciones ms tiempo de
procesamiento y ms requerimiento de espacio
A menor nmero de pre agregaciones peor tiempo de
respuesta de las consultas

En esta etapa debemos definir cuando y con que frecuencia procesar los
cubos.

Esta definicin debe considerar los siguientes factores

Cuando se procesan Dimensiones o cubos se estn
actualizando los datos, las estructuras multidimensionales o
ambas cosas.
Pgina 66 de 94
Modo de almacenamiento que escogimos (MOLAP-ROLAP-HOLAP),
Tamao de la tabla de hechos (cantidad de registros)
Numero de dimensiones del modelo
Porcentaje de agregaciones
Para determinar la frecuencia con que procesaremos el cubo debemos tener
en cuenta lo analizado con el cliente respecto de la granularidad de los datos
para el tiempo. EL nivel de detalle (da, mes, etctera) nos fijar la
periodicidad de actualizacin de los datos.
A diferencia de los sistemas OLTP en los que la actualizacin de los datos se
realiza en lnea con las transacciones y la agregacin de los datos se realiza
en el momento en que el usuario realiza una consulta, en OLAP el
procesamiento de los cubos se realiza a contra turno, en los horarios en que
no se afecta la tarea de los usuarios.

En el sistema de trfico telefnico, si se reciben los datos de
las llamadas una vez por semana, entonces deberamos
procesar el cubo un da del fin de semana y de esa manera no
afectaramos la tarea del usuario.
Si en cambio, la informacin de las llamadas se recibe en
forma diaria, el procesamiento se podra realizar una vez al da
a ltima hora de la noche, o bien a primera hora de la maana.

Los cubos virtuales son vistas de cubos reales. Los cubos virtuales pueden
ser utilizados:
Cuando el usuario desee ver informacin conjunta de dos cubos
diferentes.
Cuando se quiere tener una visin parcial de un cubo. Es una forma de
simplificar el manejo de la seguridad.

En el sistema de trfico telefnico, se pueden querer relacionar
las llamadas telefnicas con la cantidad de horas trabajadas.
Una forma simple de cumplir con este requisito es crear un
cubo virtual que tome datos de los cubos de Trfico y de
RRHH.

4.6. Particiones
Los cubos estn compuestos por particiones. Como su nombre lo sugiere,
una particin es una divisin o fraccionamiento de la informacin que
conforma a un cubo. Cada cubo contiene al menos una particin, pero puede
estar compuesto por mltiples particiones,
Pgina 67 de 94
Las particiones de un cubo son invisibles para el usuario, pero su uso
aumenta la carga de trabajo del administrador del modelo multidimensional.
Para cada particin podemos definir la fuente de datos, el modo de
almacenamiento y el porcentaje de agregacin de manera independiente de
las dems particiones.
Adems, una particin de datos puede ser actualizada independientemente
de las otras. Esta propiedad es muy importante ya que nos brinda la ventaja
de mejorar los tiempos de procesamiento si dividimos correctamente las
particiones y las procesamos adecuadamente.
As, si dividimos nuestro cubo en particiones definiremos cada unos de estos
parmetros de la manera mas indicada.
Particin ms utilizada (Tiempo Actual):
Modo de Almacenamiento MOLAP,
% de Agregacin: alto
Frecuencia de procesamiento: alta
Particin medianamente consultada (Tiempos intermedios):
Modo de Almacenamiento: HOLAP
% de Agregacin: bajo
Frecuencia de procesamiento: ocasional
Particin poco accedida (Perodos viejos):
Modo de Almacenamiento ROLAP,
% de Agregacin: nulo
Frecuencia de procesamiento: muy baja (normalmente slo al
crear la particin)

Desde el punto de vista de la administracin, se puede manejar
cada particin como si fuera un cubo independiente. Puede
tener fuente de datos, modo de almacenamiento, porcentaje de
agregacin y frecuencia de procesamiento propios.

Podemos crear una particin por cada ao que contenga el
cubo, (por ejemplo 2004, 2005 y 2006), y almacenar las
particiones de la siguiente manera:
Ao 2006: En una estructura MOLAP, con un alto porcentaje
de agregaciones, para obtener una respuesta rpida a las
consultas.
Ao 2005: En una estructura HOLAP, con un bajo porcentaje
Pgina 68 de 94
de agregaciones, lo que permitir buenos tiempos de respuesta
para consultas de resumen, con un espacio de almacenamiento
mnimo.
Aos anteriores: En una estructura ROLAP, con porcentaje de
agregaciones cero, lo que nos ahorrar espacio de
almacenamiento. Este ahorro se paga con el aumento del
tiempo de respuesta, pero no es caro, porque las consultas son
ocasionales.

Disear mal una particin, sin considerar los filtros que
habitualmente utiliza el usuario, aumenta la carga de
administracin y no mejora la performance de las
consultas.
Si la lgica que define las particiones no est
correctamente diseada, se pueden perder o duplicar
datos.
En el momento de implementar el cubo, debemos analizar en conjunto los
siguientes factores, tratando de llegar a un punto de equilibrio.
% de Preagregacin.
Tiempo de Procesamiento.
Requerimientos de tiempos de respuesta
Tipo de almacenamiento
Tipificacin de las consultas (Base para decidir si se manejan
particiones)
Uso de Particiones

Respuesta

Accin

T
i
e
m
p
o

d
e

P
r
o
c
e
s
a
-
m
i
e
n
t
o

Tiempo de Respuesta
E
s
p
a
c
i
o

O
c
u
p
a
d
o

M
a
n
t
e
n
i
-
m
i
e
n
t
o

Consultas Cambios
% Preagregaciones
Pgina 69 de 94
A
l
m
a
c
e
n
a
m
i
e
n
t
o

MOLAP
X Alto Alto x Agenda Alto
ROLAP X Bajo Bajo Directo Bajo
HOLAP X Medio Medio x Agenda Medio
Particiones S

Caso de Estudio
Veremos como implementamos el diseo del modelo de OLAP
que desarrollamos en la unidad anterior.

Como vimos nuestro modelo era:

A este modelo lo implementaremos sobre un cubo denominado Ventas.

Cubo Ventas

Dimensin Cliente
* Pas
** Provincia
*** Ciudad
**** Razn
Social
Fact_Ventas
ID_Fecha
ID_Producto
ID_Cliente
ID_Vendedor
Ventas_Importe
Ventas_Costo
Ventas_Unidades
Dimensin Vendedor
* Sucursal
** Seccin
*** Vendedor
Dimensin Sucursal
* Sucursal
** Tipo
Sucursal
*** Pas
**** Provincia
***** Ciudad
Dimensin Tiempo
* Ao
** Semestre
*** Trimestre
**** Mes
***** Da
Dimensin Producto
* Familia
**
Departament
o
*** Categora
**** Subcategora
***** Producto
Subcategora
Subcategora
Categora
Categora
Departamento
Departamento
Familia
Familia
Pgina 70 de 94
Teniendo en cuenta que nuestro cliente analiza su informacin con respecto a
los periodos de tiempo, filtrando por ao, construiremos dos particiones
dividiendo el cubo en forma anual. As, obtenemos una particin para el ao
2005 y otra para el ao 2006.

Esta particin tiene como objeto dar soporte a consultas que se
realizan con poca frecuencia, por lo que optamos por definir
parmetros que permitan el ahorro de espacio ocupado,
aceptando una performance ms baja.

La particin para el ao 2005 tendr:
Modo de almacenamiento: HOLAP
Porcentaje de agregacin: 10%
Frecuencia de procesamiento: La procesaremos en el momento de la
creacin y despus solo cuando el cliente lo solicite.

Esta particin tiene como objeto dar soporte a las consultas que
se realizan habitualmente, uno de los requerimientos bsicos es
el tiempo de respuesta de las consultas, por lo que optamos por
definir parmetros que apunten a obtener la mejor performance,
aceptando el costo en espacio ocupado y tiempo de procesamiento.
La particin del ao 2006 tendr:
Modo de almacenamiento: MOLAP
Porcentaje de agregacin: 40%
Frecuencia de procesamiento: El procesamiento se realizar
diariamente a partir de las 22:00 hs. ya que sabemos que los usuarios
no realizan consultas en ese horario.

No es necesaria la creacin de un cubo virtual para poder visualizar las dos
particiones. Desde el punto de vista del acceso para las consultas, las
particiones son transparentes para el usuario, quien define al cubo como
su fuente de datos sin tener en cuenta la forma en que est construido.

Existen distintos modos de almacenamiento de los
datos y agregaciones de un cubo, deberemos
seleccionar uno de ellos segn las necesidades y
posibilidades de nuestra organizacin.
Es conveniente emplear particiones cuando existen
grandes volmenes de datos con fin de lograr mejoras
en los tiempos de procesamiento y la resolucin de las
2005
2006
Pgina 71 de 94
consultas.
Utilizaremos cubos virtuales cuando el data mart
necesite relacionar informacin de distintos cubos.

Los tiempos de respuesta de las consultas son un factor
clave? Se tienen definidos valores mnimos o mximos a
cumplir?
Est estimado el volumen de datos a manejar, tanto en
la actualidad como en el futuro?
La frecuencia y el tiempo de procesamiento, son factores
crticos?
Se cuenta con el equipamiento adecuado para la
situacin actual y la estimacin futura? Se consider
este factor relacionndolo con el almacenamiento y la
velocidad de procesamiento?
Existen criterios predefinidos para la definicin del % de
pre agregacin?
Ser necesaria la creacin de cubos virtuales?
Se tiene una clara idea de la cantidad y calidad de las
consultas habituales? Existe algn patrn de filtrado que
se repita, como el mes o la ciudad?

Unidad 5. Implementando Cubos OLAP
Objetivos

Comprender la importancia del correcto manejo de la
seguridad en los datos.
Conocer las operaciones que se pueden realizar en la
consulta de un cubo.
Entender el uso de la tabla pivotal como herramienta de
exploracin.
Pgina 72 de 94
1.21 Introduccin
1.22 Seguridad
1.23 Consultas
1.25 Conclusiones
1.26 Check List

5.1 Introduccin

Como terminacin del curso veremos como los usuarios pueden acceder a la
informacin del cubo, para ello primero describiremos algunos aspectos de
seguridad para mostrar los datos y luego expondremos los diferentes modos
que existen para navegar un cubo.
Al final del modulo daremos una conclusin sobre lo aprendido a lo largo del
curso y habremos completado un Check List que nos servir de gua en el
proceso de creacin de una solucin de BI.
5.2 Seguridad
A la hora de disear el modelo multidimensional, es fundamental definir la
seguridad adecuada sobre los diferentes componentes y niveles de la
Pgina 73 de 94
solucin, debido a lo sensible que puede ser para la organizacin la
informacin que suelen manejar este tipo de aplicaciones.
Al igual que ocurre con las bases de datos de los sistemas transaccionales,
en OLAP pueden manejarse distintos niveles de seguridad.
La seguridad en OLAP tiene una arquitectura jerrquica, partiendo del cubo y
llegando al nivel de celda dentro del cubo.
De este modo, podemos definir los permisos a nivel de:
Cubo
Dimensin
Celda (Medida)
Cubo: esta restriccin de seguridad se realiza sobre todo el cubo, se puede
permitir o denegar el acceso al cubo.

Dimensin: Podemos permitir que el usuario vea la dimensin, que acceda
solo a una parte de ella, o que no tenga permiso de visualizarla.

Celda: En una celda o medida podemos permitir el acceso, o bien personalizarlo utilizando
expresiones que verifiquen alguna condicin para acceder a los datos.
Otra opcin para limitar los accesos puede ser el uso de cubos virtuales.
Podramos crear un cubo virtual solo con las medidas que deseamos que
tenga acceso el usuario y luego otorgar los permisos sobre el cubo virtual, y
denegar o no otorgar permiso sobre el cubo original.

Por ejemplo, si solo un grupo de usuarios puede visualizar el
importe de los sueldos de los empleados, entonces podramos
definir una restriccin de acceso a nivel celda, sobre la medida
Sueldo o crear un cubo virtual que no muestre esta medida.

Denegado Permitido
Permitido Solo una parte Denegado
Pgina 74 de 94
5.3 Consultas
Una vez que tenemos armado el cubo, los usuarios pueden realizar diferentes
operaciones para poder visualizar y analizar sus datos.
Las operaciones que se pueden realizar son:
Drill - Down
Drill - Up
Slice y Dice. (Filtrado)
Rotacin
Consolidacin

Drill Down Drill Up: Es una tcnica por la que el usuario puede navegar
entre las jerarquas de una dimensin agrupando (Drill-up) o desagrupando
(Drill-down) los datos.
El drill down y el dril up sirven para navegar el cubo sobre sus dimensiones,
con el drill up se pasa desde el detalle a la generalizacin, y con el drill down
se pasa desde un nivel general al detalle.

Slice: Al seleccionar un miembro en particular de una dimensin se forma
una especie de rebanada (slice) del cubo original.
D
r
i
l
l

-

U
p

D
r
i
l
l

-

D
o
w
n

Pgina 75 de 94

Dice: Al seleccionar varios miembros de varias dimensiones se forma sub-
cubo, cubo ms pequeo o dado (dice). Tanto Slice como Dice son formas
particulares de Filtrado.

Rotacin: Selecciona el orden de visualizacin de las dimensiones, rota o
gira el cubo segn sus dimensiones.

Consolidacin (Roll-Up): Calcula las medidas en funcin de agrupamientos,
realiza el re-clculo de la medida de acuerdo a los ajustes de escala.

Pgina 76 de 94

La navegacin es un trmino que usamos para describir la posibilidad que
tienen los usuarios de recorrer las distintas dimensiones y sus cruces,
visualizando para cada caso los valores resultantes de las medidas.
Estas son algunos tipos de herramientas que se pueden utilizar para navegar
el cubo:
Planillas de Clculo: Las planillas de clculo pueden conectarse a la
estructura dimensional y alimentar una tabla pivotal con la
informacin que extraen de los cubos.
Tablero de Control: Los tableros de control se conectan a la
estructura dimensional y generan indicadores que permiten una
rpida visin del estado actual de las variables bsicas y su relacin
con los objetivos de la empresa.
Desarrollos propios: Soluciones o aplicaciones desarrolladas a
medida, especialmente para la organizacin. Estas soluciones puede
desarrollarlas el rea de Sistemas de la empresa o un Proveedor
externo, pero siempre en base a los requerimientos propios de la
organizacin.
Software especializado: Soluciones o aplicaciones creadas por
empresas dedicadas principalmente al desarrollo de visualizadores de
informacin orientada al anlisis. Existe una gran variedad de
herramientas con diversidad de prestaciones y costos, pudiendo ser
tanto genricas como orientadas a algn mercado en particular.
Reporteadores: Herramientas especializadas en la construccin de
informes que pueden conectarse a la estructura dimensional y generar
reportes con la informacin que extraen de los cubos.

Existe una gran variedad de Herramientas de visualizacin
de la informacin almacenada en una estructura
multidimensional. Se debe estudiar cada conjunto necesidad
recurso para decidir cual de ellas usar.
En general, los factores que influyen el la eleccin de una
Pgina 77 de 94
herramienta son:
Tipo de consultas o anlisis.
Presupuesto.
Valor del desarrollo o de las licencias.
Usuario al que va destinada la herramienta.
Otras herramientas existentes en la empresa.
Capacidad de desarrollo de aplicaciones propias.

Si no se incluye el anlisis de la herramienta de visualizacin
a utilizar entre las tareas de diseo, se corre el riesgo de
tener la informacin correcta y a tiempo, pero a los usuarios
desconformes.
La tabla pivotal es una herramienta grfica que permite a los usuarios
explorar fcilmente las dimensiones y medidas del cubo. De esta manera el
usuario puede construir sus propios informes.
La tabla pivotal se utiliza a travs de una planilla de clculo que se conecta al
modelo multidimensional. Con ella se pueden realizar todas las operaciones
que vimos en el punto 5.3 Consultas.
Una Tabla Pivotal consta de las siguientes reas:
rea de Filtros: En la parte superior de la tabla. Se puede incluir una o
ms dimensiones. Se puede filtrar la informacin seleccionando niveles en
general o miembros en particular. Cuando se realizan selecciones
mltiples dentro de una dimensin, stas se relacionan mediante el
operador OR. Si las selecciones se realizaron en varias dimensiones, se
vinculan con el operador AND. En esta rea se implementa
exclusivamente la operacin Filtrado; en base a las selecciones realizadas
se forma un conjunto reducido de datos que cumplen con los valores
elegidos.
rea de Filas: A la izquierda, define qu dimensiones cruzan la tabla
como filas. En esta zona se pueden arrastrar las dimensiones, se puede
navegar por ellas y decidir qu niveles mostrar y el grado de apertura de
la informacin. Tambin se puede seleccionar qu informacin se
muestra. En esta rea se implementan las operaciones Drill-Up, Drill-
Down y Filtrado.

Pgina 78 de 94

rea de Columnas: En la parte superior de la tabla debajo del rea de
filtros. Se define qu dimensiones cruzan la tabla como columnas. En esta
zona se pueden arrastrar las dimensiones, se puede navegar por ellas y
decidir qu niveles mostrar y el grado de apertura de la informacin.
Tambin se puede seleccionar qu informacin se muestra. En esta rea
se implementan las operaciones Drill-Up, Drill-Down y Filtrado.
rea de Datos: En el centro de la tabla, se pueden incluir slo medidas.
Cuando arrastramos una medida tendremos el resultado de la interseccin
con las dimensiones que escogimos como filas y columnas, para el
subconjunto que define el Filtrado.
Lista de de Campos: Contiene la lista de las dimensiones y las medidas
del cubo.
Notas:
o Una dimensin puede estar en Filtros, Filas o Columnas, pero
slo en un rea a la vez.
o En general, en el rea de Filtros no se muestra la seleccin
realizada. Si se desea filtrar por un nivel o miembro y, a la vez
mostrarlo, se lo debe incluir en Filas o Columnas.

En este ejemplo se quieren ver las unidades vendidas
(Ventas Unidades), para el mes de Mayo de 2006, de
Cuadernos cuadriculados, detalladas por Sucursal.
Pgina 79 de 94

Caso de estudio

Restricciones de seguridad
Cada Sucursal puede ver nicamente sus datos, no pueden acceder a los
que corresponden al resto de las sucursales.

Los Vendedores pueden ver las ventas por Seccin o Sucursal, pero no
deben poder acceder al detalle por Vendedor.
Pgina 80 de 94

Los Vendedores no pueden tener acceso al costo de las unidades vendidas.

Operaciones sobre el cubo
Veremos algunas de las operaciones que se pueden hacer sobre el cubo,
ejemplificndolas con nuestro cubo de Ventas de la empresa DLA. Para la
visualizacin usaremos una tabla pivotal, por tratarse de una herramienta de fcil
manejo y disponibilidad.
Drill Down: Si el usuario est analizando los datos de las ventas de Argentina y
desea ver cmo estn compuestos, podr hacer drill-down en la dimensin de la
Sucursal, la que exhibira Buenos Aires, Capital Federal, Entre Ros, La Pampa y
Santa Fe.

Si desea explotar Buenos Aires, con otro drill-down la tabla mostrar La Plata, Mar
del Plata y Necochea.

Pgina 81 de 94

Drill Up: Si el usuario esta viendo en detalle el nivel Ciudad (La Plata, Mar del
Plata y Necochea) y quiere ver un nivel ms general, podr hacer drill up. Esta
operacin agrupar la informacin por Pas y mostrar el total de Argentina.

La ventaja de tener estructuras definidas previamente, reside en que no es
necesario que el analista sepa a qu pas corresponde cada provincia o a qu
provincia corresponde una ciudad para agregar o detallar. La estructura le dice el
camino.
Dice: con esta operacin armamos un SubCubo de tres dimensiones, tomando las
dimensiones Producto, Sucursal y Tiempo, dejamos fuera de nuestra seleccin a
las dimensiones Cliente y Vendedor.

Slice: Seleccionando la dimensin tiempo definimos una tajada del cubo.

Pgina 82 de 94

Filtrado: Un ejemplo de filtrado podra ser seleccionar para la dimensin Producto
el valor Temperley Cristal Para x 1 Lt.

Rotacin: en este ejemplo tomamos las dimensiones productos y sucursal y las
rotamos.

Reportes: A continuacin se vern algunos informes simples orientados al anlisis
de la informacin.
a- Se desea ver la evolucin de la ganancia en las ventas de los Hipermercados,
para los totales de los aos 2005 y 2006, detalladas por Pas.
Filtro: Tipo de Sucursal Hipermercado.
Filas: Dimensin Sucursal
Columnas: Dimensin Tiempo
Datos: Medida Ventas Ganancia
Obtenemos el siguiente resultado:
Pgina 83 de 94

b- Ahora se desea comparar el Importe de las Ventas del Mes de Septiembre de
2006, por Pas y Familia de Productos, explotando cada familia por Departamento
y Categora.
Filtro: Septiembre 2006
Filas: Dimensin Producto, y sus niveles Familia, Departamento y Categora
Columnas: Sucursal
Datos: Medida Ventas Importe
El resultado que obtuvimos fue:

c- Si queremos conocer como se distribuye la ganancia de las ventas en cada pas
podemos construir un grafico que nos permite visualizar claramente esta
distribucin:
Filtro: -
Filas: Dimensin Sucursal
Columnas: -
Datos: Medida Ventas Ganancia

Ventas Ganancia
Pgina 84 de 94

d- Ahora queremos comparar las unidades vendidas de cada producto durante los
aos 2005 y 2006 en un grfico de barras.
Filtro: -
Filas: Dimensin Producto
Columnas: Dimensin Tiempo
Datos: Medida Ventas Unidades

El Tablero de Control es una herramienta grfica que le permite a los
directivos concentrarse en indicadores fundamentales que tienen relacin
directa con los objetivos de negocio de la empresa. El Tablero de Control no
es un repositorio de datos, bsicamente es una herramienta que muestra
indicadores relacionando los resultados esperados con los reales, es una
manera de analizar la evolucin del negocio.
Pgina 85 de 94
Un Tablero de Control muestra, en pocos indicadores, datos trascendentes
que extractan la naturaleza de la empresa y su porvenir. Estos indicadores
deben mostrar la informacin en forma oportuna, sencilla e integrada, y ser
claros y confiables.
Un Tablero de Control no garantiza el xito de una empresa, debe
comprometerse el esfuerzo necesario para su efectiva utilizacin y generar
una transformacin en la cultura de trabajo empresarial.
Finalmente, se debe tener perfectamente en claro que un Tablero de Control
no gerencia ni gestiona; los indicadores le muestran los problemas a los
directivos, pero el anlisis de las causas y la forma de solucionarlos depende
de las decisiones que ellos tomen. El Tablero de Control le indica a los
directivos si la organizacin est cumpliendo con los objetivos o no, pero en
ningn momento genera una solucin automtica. Para qu sirve, entonces,
el Tablero de Control? Bsicamente, el Tablero de Control permite una rpida
lectura del estado actual de las variables bsicas y su relacin con los
objetivos de la empresa, alerta sobre la existencia de problemas actuales y
facilita la visin de la evolucin esperada, con lo cual ayuda a detectar los
desvos en los objetivos y tomar decisiones oportunas para corregirlos a
tiempo.

El Tablero de Control es una muy buena herramienta, pero
slo el cambio de la cultura empresarial puede hacer exitoso
el camino.

En este ejemplo se muestran dos modelos de Semforo,
siendo stos indicadores grficos caractersticos de los
Tableros de Control.
Para definir los semforos se manejan, bsicamente, las
siguientes variables:
Modelo del Semforo: Existen varios estilos con
diferentes cantidades de niveles. El nmero de
niveles que posea un semforo est directamente
relacionado con la sensibilidad o capacidad de
detalle que tiene el mismo.
Valor Real: Es la variable que se desea
monitorear.
Valor Destino: Es el elemento de contraste contra
el cual se van a monitorear los valores reales, y a
partir del cual se calculan las diferencias o desvos.
Umbrales: Valores porcentuales que definen el
Pgina 86 de 94
paso de un estado del semforo al otro (Del verde
al amarillo, por ejemplo). Segn sea la cantidad de
niveles del modelo de semforo, ser la cantidad
de umbrales a definir.
Semforo tradicional de 3 colores: Es un semforo con
la forma, los colores y la lgica tradicional. El
color Verde indica la situacin ideal,
mientras que el Rojo seala el peor extremo.
Semforo de cinco niveles: Es un semforo que
combina una barra, en el estilo de las barras de progreso,
con un ndice. La barra completa, con el ndice en el
cuadro de la derecha, representa la situacin ideal,
mientras que la barra con slo el cuadro de la izquierda y
el ndice sobre ste ltimo, seala el peor extremo.

Pgina 87 de 94

Caso de estudio

Tablero de Control
A continuacin se vern dos ejemplos de Tablero de Control aplicados a nuestro
Caso de Estudio.
a- Se desea ver la evolucin del Importe de las Ventas, para los meses de Enero,
Febrero y Marzo del 2006, detallada por Producto. Se desean ver los datos
agrupados por Familia y Departamento.
Lo primero que se ve en el Tablero de Control son los semforos. Con el primer
golpe de vista, sobre todo si la persona cuenta con la experiencia suficiente en el
uso de estas herramientas, se puede saber el grado de cumplimiento de las Ventas
respecto de los Objetivos para cada mes y la evolucin que se est dando en el
trimestre. En forma complementaria se tienen los valores numricos como
elemento de soporte.

b- Se desea ver la evolucin de las Ventas (Importe y Unidades), para los meses
de Enero, Febrero y Marzo del 2006, detallada por Provincia.
Lo primero que se ve en el tablero de Control es que se pueden analizar, en forma
simultnea, varios aspectos del negocio. Se pueden combinar distintas variables a
analizar y semforos de distinta sensibilidad.
En este caso se puede ver la evolucin de las ventas comparando cmo varan las
unidades y los importes, a lo largo del tiempo, con un solo golpe de vista.
Pgina 88 de 94

Debemos considerar las restricciones de seguridad
para proteger la informacin de los cubos.
Los permisos de acceso los podemos otorgar sobre
diferentes elementos del modelo (cubos, dimensiones,
celdas).
Las consultas de un cubo involucran diferentes
operaciones (rotacin, drill-down, slice, etctera).
La tabla pivotal es una planilla de clculo que permite
navegar los cubos.

Pgina 89 de 94

Existe una poltica de seguridad institucional?
Se pueden definir grupos de usuarios con roles similares para
facilitar la administracin de la seguridad?
Todos los requerimientos de control de acceso a los datos se
van a manejar administrando la seguridad o se va a tener en
cuenta estos puntos en el diseo de los objetos de la
estructura multidimensional?
Existen herramientas corporativas para la visualizacin de los
cubos?
Existe capacidad (habilidades y tiempo disponible) de
desarrollar herramientas propias?
Las herramientas del Mercado, cubren las necesidades de la
empresa? Son accesibles?

5.5 Conclusiones
Las principales conclusiones obtenidas a lo largo del curso son:
Un sistema de BI constituye una necesidad para el correcto manejo del
negocio.
Los sistemas de BI son una muy buena herramienta para sustentar la
evolucin y el crecimiento del negocio y deben estar diseados de
forma tal que puedan seguir esa evolucin y crecimiento.
Los sistemas de BI influyen en toda la empresa, no son una facilidad
de un sector.
Cualquier empresa que se proponga cumplir con sus objetivos debe
tener un sistema de BI. Los sistemas de BI no son slo para las
grandes empresas.
Los sistemas de BI no son mquinas de fabricar informes.
El tener un sistema de BI no es un lujo para la empresa, es responder
a una necesidad.
Los sistemas de BI son vlidos para cualquier proceso en el que deban
tomarse decisiones, no son propiedad de las reas comerciales o
financieras.
Los sistemas de BI no son mquinas de fabricar resmenes, brindan la
informacin con el grado de detalle necesario para cada anlisis.
Los sistemas de BI no son una herramienta del rea de Sistemas para
mantener cautivos a los usuarios. Por el contrario, con un sistema de
BI los usuarios consiguen ms independencia al poder realizar las
consultas en forma intuitiva y flexible.
Construir un sistema de BI tiene como valor agregado el tener que
revisar dnde y cmo se estn almacenando los datos de los sistemas
transaccionales (OLTP). Es una muy buena oportunidad de incluir en
Pgina 90 de 94
los procesos manejos de datos que se estn haciendo manualmente y
sin soporte alguno.
El desarrollo de un sistema de BI no se comienza por la eleccin de la
herramienta de visualizacin. Como en todo desarrollo hay que relevar
las necesidades de la empresa, consultar a los usuarios, fijar el
alcance y las restricciones y, finalmente, disear, desarrollar y probar
cada etapa.
El desarrollo de un sistema de BI no termina con la creacin de un
cubo multidimensional. Se deben definir e implementar los trabajos de
procesamiento de los cubos (periodicidad, horario, manejo de errores,
etctera).
Existe una gran variedad de herramientas de visualizacin de datos.
Debe brindarse a cada usuario la que ms le convenga, sin descuidar
el presupuesto. La herramienta de visualizacin no debe ser una
barrera entre el usuario y el sistema de BI.
Pgina 91 de 94
5.6 Check List

Est preparada la organizacin para trabajar con BI?
Se cuenta con el compromiso de la alta gerencia para
encarar un proyecto de creacin de un sistema de BI?
Tiene presente que deber capacitar a los usuarios en
la disciplina asociada a BI?
Estn claramente definidos los objetivos de negocio
que se asocian al sistema de BI?
Ha relevado los Hechos que son de inters?
Ha relevado las aperturas por las cuales se analizar la
informacin?
Ha relevado las medidas o indicadores que se usarn
para evaluar los Hechos?
Cul es la granularidad con que es necesaria ver la
informacin en el sistema OLAP?
Tiene definidas las fuentes de donde va a extraer los
datos?
Tiene definidos los formatos de los archivos de
transferencia y de los datos que stos incluyen?
Dise los procesos de seleccin, transformacin y
carga de datos (ETL)?
Tenemos claramente definidos los requerimientos?
Conocemos los hechos que se quieren analizar, los
indicadores y las aperturas por las cuales se quiere
hacer el anlisis?
Concuerda esta definicin con las tablas auxiliares que
creamos y poblamos con datos de los sistemas OLTP?
Sabemos si los usuarios utilizarn las dimensiones para
navegar o para filtrar?
Cubren las dimensiones diseadas las necesidades de
los usuarios intuitivamente y con facilidad de manejo?
Se tienen todas las medidas naturales con las aperturas
requeridas?
Pgina 92 de 94
Est definida la forma de agregacin, al salir de la
granularidad mnima, para todas las medidas naturales?
Estn definidas las frmulas o criterios de todas las
medidas calculadas?
Estn correctamente documentadas todas las
definiciones?
Los tiempos de respuesta de las consultas son un factor
clave? Se tienen definidos valores mnimos o mximos a
cumplir?
Est estimado el volumen de datos a manejar, tanto en
la actualidad como en el futuro?
La frecuencia y el tiempo de procesamiento, son factores
crticos?
Se cuenta con el equipamiento adecuado para la
situacin actual y la estimacin futura? Se consider
este factor relacionndolo con el almacenamiento y la
velocidad de procesamiento?
Existen criterios predefinidos para la definicin del % de
pre agregacin?
Ser necesaria la creacin de cubos virtuales?
Se tiene una clara idea de la cantidad y calidad de las
consultas habituales? Existe algn patrn de filtrado que
se repita, como el mes o la ciudad?
Existe una poltica de seguridad institucional?
Se pueden definir grupos de usuarios con roles similares
para facilitar la administracin de la seguridad?
Todos los requerimientos de control de acceso a los
datos se van a manejar administrando la seguridad o se
va a tener en cuenta estos puntos en el diseo de los
objetos de la estructura multidimensional?
Existen herramientas corporativas para la visualizacin
de los cubos?
Existe capacidad (habilidades y tiempo disponible) de
desarrollar herramientas propias?
Pgina 93 de 94
Las herramientas del Mercado, cubren las necesidades
de la empresa? Son accesibles?

Pgina 94 de 94

Documentacin Consultada:

Kimball Ralph, "The Data Warehouse Toolkit " - John Wiley & Son, Inc.

Thomsen E., Spofford G., Chase D., Microsoft OLAP Solutions - John
Wiley & Son, Inc.

Laudon Kenneth C.; Laudon Jane Price. Sistemas de informacin
gerencial : administracin de la empresa digital - Pearson Educacin

Curso 2074A: Designing and Implementing OLAP Solutions with
Microsoft SQL Server 2000.

Facultad de Ciencias Exactas UNICEN
http://www.exa.unicen.edu.ar/catedras/dwhouse/

Facultad de Ingeniera Universidad de la Repblica de Uruguay
http://www.fing.edu.uy/inco/grupos/csi/esp/Cursos/cursos_act/2003/DA
P_SistDW

Facultad Tecnologa Informtica - Universidad Abierta Interamericana
Ctedra: Base de Datos Aplicada I

Articulo Bajo el paraguas Business Intelligence, Jorge Fernndez
Gonzlez, Abril 2006.

Business Intelligence Fundamentos

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Business Intelligence Fundamentos

Cargado por

Copyright:

Formatos disponibles

Pgina 1 de 94

ACADEMIA LATINOAMERICANA DE BUSINESS

También podría gustarte