Academia latinoamericana de Business Intelligence albi

ACADEMIA LATINOAMERICANA DE BUSINESS
INTELLIGENCE (ALBI)
Contenido del curso

Convenciones
Para ubicar rápidamente los diferentes puntos desarrollados a través de
las unidades, se llevó a cabo un diseño de gráficos que harán referencia a
cada tema. De esta manera el participante podrá ubicar cada contenido sin la
realización de un esfuerzo extra en la búsqueda y aprovechando al máximo el
tiempo dedicado al estudio de cada una de las Unidades presentadas.

En siguiente tabla se podrá apreciar cada gráfico y su significado:

Convención Descripción

Objetivos
Son las metas a las que apunta el curso o el módulo.

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

Riesgos
Cualquier situación que amenaza el éxito del proyecto
en general o afecta la capacidad del equipo de trabajo.
“Un problema que no ha sucedido, pero que podría
causar pérdidas o amenazar el éxito del proyecto, si
sucede.” (Wiegers, 1998)

Ejemplos
Son situaciones conceptuales, reales o hipotéticas de
aplicación de los conceptos tratados y su propósito es
apoyar a la comprensión de los conceptos al asociarlos
con posibles formas de aplicación o de interpretar las
que se proponen.

Página 1 de 94

Convención Descripción

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.

Estadísticas
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 reflexión,
detonan la asociación del contenido conceptual con
entornos de aplicación del aprendizaje.

Preguntas de Reflexión
Son formulaciones que sirven como guía para controlar
el desarrollo del proyecto. Al final de la última unidad,
estas preguntas se reúnen formando un Check List.

Lecciones aprendidas
Son frases o afirmaciones que al final de cada capítulo
sintetizan lo que el participante debió aprender y
permiten parafrasear la información clave.

Diagramas, Son recursos que facilitan la lectura y la comprensión
esquemas, porque destacan, organizan, clasifican, jerarquizan,
fotografías, tablas, ilustran y/o representan el contenido con el propósito
negritas y color en de facilitarte como participante la interacción con el
las fuentes curso.

Página 2 de 94

Objetivos
Quién participe en la presente propuesta educativa, obtendrá
los conceptos teóricos necesarios de Business Intelligence,
formando una base consistente para adquirir posteriormente
los conocimientos y así perfeccionarse en esta tecnología. Al
final del curso tendrá los conocimientos suficientes para
comprender qué es Business Intelligence, su necesidad,
utilidad, desarrollo e implementación.

Contenido
Las siguientes Unidades y temáticas son las que se desarrollarán 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
solución BI, su potencialidad en la toma de decisiones y por qué en la
actualidad las empresas están apostando a ello.

Unidad 2. Definiendo Soluciones OLAP
La Unidad 2 se recordarán los conceptos básicos de un sistema OLTP
con sus ejemplos, pasando posteriormente a la explicación de un
sistema OLAP. Se mencionarán y explicarán las características 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 cómo estos comienzan a transformarse en información
del negocio. Hacia el final de la unidad, se verán algunos de los
posibles procesos de selección y transformación de datos (ETL) que
permiten alimentar las tablas auxiliares que soportarán la estructura
multidimensional.

Unidad 3. Diseñando una solución 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 solución OLAP
En la Unidad 4 se verán consideraciones específicas de la
construcción y procesamiento de un cubo.

Unidad 5. Implementando Cubos OLAP
En la Unidad 5 se verá como un usuario puede acceder a la
información en un sistema de BI, teniendo en cuenta la seguridad y el
tipo de herramienta de consulta utilizada.

Página 3 de 94

Unidad 1 ¿Qué es Business Intelligence?

1.1 Introducción
1.2 ¿A qué empresas les interesa BI?
1.3 ¿Qué es Business Intelligence?
1.4 ¿Qué puede hacer Business Intelligence?
1.5 ¿Quién necesita soluciones Business Intelligence?
1.5.1 Obtención caótica de información
1.5.2 ¿Quién necesita analizar la información?
1.6 ¿Primeros pasos?
1.7 El futuro de Business Intelligence

Unidad 2 Definiendo Soluciones OLAP

2.1 Sistema Transaccional (OLTP)
2.1.1 Características
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. Información de Negocio
2.3.1 Convirtiendo Datos en Información
2.3.2 Transformación y agrupación de datos – ETL

Unidad 3 Diseñando una solución OLAP

3.1 Introducción
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 dimensión
3.3.2.2 Esquema Estrella
3.3.2.3 Esquema Copo de Nieve

Página 4 de 94

3.3.2.4 Padre – Hijo (Parent- Child)
3.3.2.5 Dimensiones Virtuales
3.3.2.6 La dimensión Tiempo
3.4 Medidas
3.4.1 Medidas Naturales
3.4.2 Medidas Calculadas

Unidad 4 Construyendo una solución OLAP

4.1. Introducción
4.2. Tipos de Almacenamiento
4.2.1. MOLAP
4.2.2. ROLAP
4.2.3. HOLAP
4.3. Definición de Agregaciones
4.4. Procesamiento de cubos
4.5. Cubos Virtuales
4.6. Particiones
4.7. La difícil búsqueda del equilibrio

Unidad 5 Implementando Cubos OLAP

1.8 Introducción
1.9 Seguridad
1.10 Consultas
1.11 Herramientas de visualización
5.4.1 La Tabla Pivotal
5.4.2 El Tablero de Control
1.12 Conclusiones
1.13 Check List

Página 5 de 94

Unidad 1. Introducción a Business Intelligence

Objetivos
Dar una visión acerca del por qué se debe contar con un
sistema de apoyo para la toma de decisiones:

Conocer qué sistemas informatizados actúan 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 solución Business Intelligence.

Introducción
Los rápidos cambios que se viven en el mercado actual junto a las
competencias que se generan cada día, hacen que las empresas no puedan
postergar las decisiones relacionadas directamente con el negocio; una
demora en este sentido puede llevar la gestión 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 rápida, con información
precisa para poder aprovechar las oportunidades: “estar en el lugar indicado,
en el momento oportuno, con la información correcta”.
Los sistemas orientados para la toma de decisiones son los englobados por
el término 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 según los objetivos y hasta crecer,
pero en cuanto algo falla, los procesos se descontrolan, la coordinación
desaparece y, en el mediano plazo, la empresa se desploma sobre sí misma.
Esta puede parecer una visión apocalíptica, pero, ¿quién se arriesgaría a
llevar adelante una gestión basándose en la buena suerte?

Página 6 de 94

Contenido de la unidad
1.14 Introducción
1.5.1 Obtención caótica de información
1.5.2 ¿Quién necesita analizar la información?
1.19 ¿Primeros pasos?

1.1 Introducción
Tanto en empresas pequeñas 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 según 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 información que
monitorean las actividades y transacciones elementales de la
organización. Son sistemas que han cobrado un auge importante en la
última década 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 núcleo de
operaciones tradicionales de captura masiva de datos y servicios
básicos de tratamiento de datos, con tareas predefinidas.

Nivel de administración: Se realizan tareas de administradores de
nivel intermedio apoyando las actividades de análisis, de seguimiento,
de control y toma de decisiones, realizando consultas sobre
información almacenada en el sistema, proporcionando informes y
facilitando la gestión de la información por parte de los niveles
intermedios.

Nivel estratégico: Tiene como objetivo realizar las actividades de
planificación a largo plazo, tanto del nivel de administración como de
los objetivos que la empresa posee.

Página 7 de 94

La información que se genera en la organización se consume en diferentes
momentos según el nivel:

Plazo Nivel Uso

Corto plazo Operacional y Obtención y control de datos
Administrativo

Mediano De Conocimientos Decisiones tácticas
plazo

Largo plazo Estratégico Decisiones estratégicas

Las bases de datos transaccionales sirven como herramienta para los dos
niveles básicos de la pirámide, 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 pirámide, el Nivel de Administración y el Nivel
Estratégico, se tiene por tarea la toma de decisiones, tareas que están
estrechamente vinculadas con los objetivos del negocio.

Un sistema es un conjunto de elementos organizados que
interactúan entre sí. Representa el conjunto de reglas de
negocio que la organización define para llevar a cabo los
procesos y procedimientos funcionales y operativos

Página 8 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
sistemáticamente 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 organización 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 características tales
como:
Está orientada a la aplicación.
Tiene estructuras normalizadas.
Contiene los datos de las operaciones.
Los datos se almacenan con el máximo número de detalle.
Se actualiza en línea.
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
Países
Provincias
Ciudades
Etcétera
Cada una de las tablas y la base en sí, estarán normalizadas
para asegurar la integridad de los datos, minimizar el
espacio ocupado y maximizar el rendimiento del
mantenimiento de los datos.

Página 9 de 94


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

Variación del Presupuesto de BI 2006 vs. 2005

Empresas que invertirán Más en BI (2006 vs. 2005)

Página 10 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 inglés de On-Line Transaction
Processing, queriendo significar en su traducción
Procesamiento de Transacciones en Línea.

Bajo el nombre de Business Intelligence (Inteligencia de Negocios) se cobijan
diferentes acrónimos, 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 información calculando previamente todas las
combinaciones de todos los niveles de todas las aperturas de análisis.
Es, por decirlo llanamente, un producto cartesiano que almacena todas
las combinaciones. Se puede decir que este método es exagerado o
salvaje y en parte esta afirmación es real. Lo que no debe perderse de
vista es que esta “salvajada” es el precio que paga la organización
para poder tomar decisiones correctas. Siempre va a ser más barato el

Página 11 de 94

gasto que conlleva la adquisición de SW o HW que el costo que
representa una decisión tomada a destiempo.
Data Mart: El almacén de datos de un hecho en particular se
denomina Data Mart (DM).
Data Mining: Está asociado al escalón más alto de la pirámide (Nivel
Estratégico) 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 Minería
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 definición
de BI tienen tres características comunes:
Primera: Proveen información 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
característica más importante.
Tercera: La capa semántica. 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
extracción, transformación y agregación, lo verdaderamente importante
es que la información le debe “servir” a los usuarios finales en un
lenguaje de negocios comprensible por ellos sin la necesidad de
intérpretes. 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
análisis de la información para la correcta toma de decisiones
que le permita a la organización 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

Información para la
Objetivos Operacionales
toma de decisiones

Orientación A la aplicación Al sujeto

Página 12 de 94

Vigencia de los datos Actual Actual + histórico

Granularidad de los
Detallada Detallada + resumida
datos

Organización
Organización
Organización estructurada en función
normalizada
del análisis a realizar

Cambios en los datos Continuos Estable

A continuación 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.
Orientación: Un sistema OLTP está orientado a la Aplicación, 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
históricos para poder realizar análisis comparativos, de tendencias,
etcétera. La cantidad de períodos almacenados dependerá
exclusivamente de la necesidad de análisis 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 organización como por las normas legales vigentes. En un
OLAP estará dada por el tipo de análisis que se quieran realizar. Si el
análisis del tráfico se realiza analizando el número 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.
Organización: Un sistema OLTP es normalizado, mientras que un
sistema OLAP se basa en estructuras jerárquicas desnormalizadas
modeladas de acuerdo a la forma en que se analizarán 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 presentación de los datos en línea y,
menos aún, pretende modificar los datos originales, solo consultarlos.
La frecuencia de actualización de los datos en un sistema OLAP está
definida por la granularidad.

Página 13 de 94

Datos vs. Información
Diariamente manejamos datos sobre los números telefónicos
de las personas con las que tenemos contacto (amigos,
familiares, el plomero, el delivery de pizzas, etcétera). Estos
teléfonos nos llegan de distintas fuentes y podríamos anotarlos
en una “libretita de teléfonos” o en un cuaderno común.
Entonces,
¿Cuál es la ventaja de anotar los números de teléfono que nos
interesan en una libretita en lugar de utilizar un cuaderno? Es
evidente, vamos a encontrar más rápido los números en la
libretita que en el cuaderno ya que los tenemos organizados por
la inicial del nombre.
¿Y si además pudiéramos contar en nuestra libretita con una
división para nuestras amistades, otra para nuestra familia y
otra para servicios, cada una de ellas en diferentes colores de
hojas?
Tendríamos nuestra información telefónica organizada de tal
manera que al necesitar de ella sería rápidamente accesible. Si
queremos llamar a un amigo, tendríamos que identificar el grupo
de pertenencia según el color, luengo por el índice buscamos el
nombre y apellido y obtenemos el número de teléfono.

Este sencillo ejemplo muestra conceptualmente la diferencia
que existe entre datos e información y representa la semilla de
un DW.

Históricamente, para realizar un análisis:
Se debía llamar a una Mesa de Ayuda para solicitarle los datos
necesarios ya que era el personal de Sistemas la que sabía dónde se

Página 14 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 días.
Luego de la larga espera, se recibían los ansiados datos,
procediéndose al análisis.
Era muy posible que el analista se diera cuenta que en realidad
necesitaba contar con más información, lo cual significaba repetir el
ciclo mencionado.

En un DW se pueden reunir los elementos de datos apropiados desde
diversas fuentes de aplicación en un ambiente integral y centralizado,
simplificando el problema de acceso a la información y en consecuencia,
acelerando el proceso de consultas y análisis.
Las aplicaciones para soporte de decisiones basadas en warehousing,
pueden hacer más práctica y fácil la explotación de datos para una mayor
eficacia del negocio tanto desde el punto de vista de la disponibilidad como
de la confiabilidad.

Es posible que aún 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 solución BI.
Vayamos por partes.

Página 15 de 94

1.5.1 Obtención caótica de información: Uno de los problemas más
comunes cuando se necesita consolidar información o realizar tareas de
análisis, es que hay que saber dónde 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
aplicación que los soporte y por consiguiente el usuario lleve parte del
negocio en planillas de cálculo almacenadas en su computadora.
También puede pasar que los datos históricos sólo se mantengan en
informes impresos ubicados en armarios ya sea en el lugar de trabajo o en un
depósito externo.
El recolectar este universo de datos dispersos en todos los sectores y lugares
de la empresa, hace caótica la obtención de la información que se necesita.
El disparador de las soluciones de BI son las Killer Queries (Consultas
asesinas). Si se quiere saber cuánto debo producir en el segundo trimestre
del año, tal vez deba conocer la previsión de ventas y la tendencia de las
ventas en el año actual y las ventas reales de los últimos 5 años. Si se
ejecuta esta consulta directamente contra un sistema OLTP, la respuesta
puede que tarde varias horas y este no sería el mayor problema. El auténtico
peligro es que colapse todo el sistema de información y nadie en la empresa
pueda trabajar mientras tanto, con las pérdidas que esto ocasiona.

Página 16 de 94

1.5.2 ¿Quién necesita analizar la información? El éxito de una
organización y de la gestión de la empresa se centra en el uso que se hace
de la información. No se puede gestionar lo que no se controla. No se puede
controlar lo que no se mide, si no se tiene información para controlar los
procesos ocurrirá el caos.

La información reduce la incertidumbre y facilita la toma de mejores
decisiones.

Entonces, podemos concluir que si existe una organización, si esta
organización 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
también dentro de la empresa un sistema basado en BI.

Tomar decisiones sin la información adecuada, sobre todo
cuando ésta se encuentra disponible en la organización, es un
riesgo que ninguna empresa debería correr.

Finalmente surgen dos interrogantes:
¿Cuándo necesita la empresa hacer uso de esta información?
¿Cuándo puede la empresa hacer uso de esta información?
La respuesta para los dos casos es la misma:
¡Es necesario decidir ahora y se debe tener la información ahora!

Suponer que desarrollar un sistema basado en la tecnología
Business Intelligence es algo lujoso, de costos muy elevados
o que es un elemento de Marketing es una concepción
errónea de la idea.

1.6 Primeros pasos

Página 17 de 94

Aceptando que se reconoce la necesidad de contar con un sistema basado
en BI, se plantean las preguntas: ¿Cómo comienzo? ¿Hasta dónde debo
llegar en una primera etapa?
La creación 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 unificación de los datos que se usan en la toma de
decisiones en un repositorio único. Una experiencia desalentadora
es la de llegar a una reunión y ver que cada expositor porta una
planilla de cálculo propia, con datos propios que no coinciden con
ninguna de las demás e iniciarla con una discusión sobre la validez de
las distintas fuentes de datos.
Implementar una capa semántica útil. Que todos entiendan con
claridad el significado de la información.
Una vez cumplidos estos objetivos básicos, el resto del camino dependerá de
las necesidades propias de cada organización.

Como en casi todas las actividades humanas, en BI se da una mezcla de
necesidad y moda. Por estos tiempos están 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 obtendrán 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 información 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 círculo: se podrán definir las previsiones, los objetivos, la
planificación, la consolidación presupuestaria, etcétera.

Caso de Estudio

Página 18 de 94

Escenario

La Distribuidora Latinoamericana de Alimentos
(DLA), se dedica a la comercialización de
productos comestibles y bebidas a través de sus
Hipermercados y Supermercados.

Si bien cuenta con una amplia e
importante cantidad de locales en la
República Argentina, Brasil y Uruguay, un
claro objetivo a mediano plazo es
inaugurar locales en el resto de los países
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 países 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 información, requiere que sea presentada por zona geográfica 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
categoría 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 análisis, 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 año fiscal (El
premio será distinto si se cumple con los objetivos globalmente para el

Página 19 de 94

año o si, además, se cumplen los objetivos en todos los meses en
particular).

Se tiene distinción 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 solución
Business Intelligence.
Se comprende y se puede decidir cuándo aplicar
una solución Business Intelligence.
Se puede especificar quiénes necesitan una
solución Business Intelligence.

¿Está preparada la organización para trabajar con
BI?
¿Se cuenta con el compromiso de la alta gerencia
para encarar un proyecto de creación de un sistema
de BI?
¿Tiene presente que deberá capacitar a los
usuarios en la disciplina asociada a BI?
¿Están 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 básicos de un sistema OLTP
con sus ejemplos.
Comprenderá las características de un Data
Warehouse junto con los componentes que lo
conforman.
Reconocerá la necesidad de los procesos de
selección y transformación de datos (ETL) que
permiten alimentar las tablas auxiliares que soportarán

Página 20 de 94

la estructura multidimensional.
Conocerá las diferencias entre un sistema
transaccional y un Data Warehouse.
Comprenderá el término OLAP y su relación con la
navegabilidad de la información.
Conocer sobre las transformaciones necesarias para
armar un DW a partir de una Base de Datos
Operacional.

Introducción
Para llevar adelante el desarrollo de un DW, deben tenerse en cuenta una
serie de pautas que deberán 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 también identificar los orígenes 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 características 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.

Página 21 de 94

Los sistemas OLTP son los responsables del mantenimiento de los
datos, ya sea agregando datos, realizando actualizaciones o bien
eliminándolos.
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 diseño. Si se
quisiera obtener determinada información histórica relativa al negocio
consultando un sistema OLTP, se produciría un impacto negativo en el
funcionamiento del sistema.
Normalmente, para el diseño de un sistema OLTP se define un modelo de
Diagrama Entidad Relación (DER). Un DER es una representación de la
realidad a través de un esquema gráfico que contiene los siguientes
elementos:
Entidades: Una Entidad es un tipo de objeto que puede identificarse
de manera única por algún medio. Este objeto es traducido a la
estructura física de una base de datos como una tabla.
Atributos: Las características particulares que distinguen a las
Entidades se denominan Atributos.
Relaciones: vínculos 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
normalización basado en las Formas Normales, lo que además garantiza una
optimización del espacio de disco a utilizar.

2.1.2 Usos Comunes de OLTP
Toda organización 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 definición de OLTP se pueden encuadrar a
todos los sistemas tradicionales dedicados a la captura, validación y

Página 22 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
Automáticos. 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 línea 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 manejándola como una
transacción.
Emitir comprobante.
Saludar al Cliente.
La situación en un Sistema de Ventas por medio de un sitio
Web, sería la siguiente:
Validar al cliente y autenticarlo en el sistema.
Tomar el pedido.
Controlar los topes de créditos.
Informar los valores parciales de la compra y
acumulados.
Requerir confirmación del cliente antes de enviar el
pedido.
Enviar el pedido.
Descontar del stock las cantidades vendidas.
Informar el número 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
créditos.

Página 23 de 94

A su vez, debe mantenerse una integridad en la información, 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 electrónico
Sistemas de facturación
Sistemas de stock

Página 24 de 94

Almacenamiento Transaccional

$

Comercio electrónico Bancos

Pedidos

$
$
$

Sistemas OLTP

Facturación

Stock

2.2 Sistemas OLAP
Los sistemas OLAP (On-Line Analytical Processing) proporcionan una
alternativa a los sistemas transaccionales, ofreciendo una visión de los datos
orientada hacia el análisis y una rápida y flexible navegación por estos.
Las siguientes son características que la tecnología OLAP posee:
Las bases de datos de OLAP tienen un esquema que está optimizado
para que las preguntas realizadas por los usuarios sean respondidas
rápidamente.
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
más allá del análisis de dos dimensiones que puede proporcionar una
simple planilla de cálculo utilizada como tal.
Los usuarios pueden cambiar fácilmente las filas, las columnas, y las
páginas en informes de OLAP, pudiendo leer la información de la
manera que se crea más conveniente para el análisis.

Página 25 de 94

Un Sistema OLAP
Los sistemas OLAP son una solución que devuelve rápidas
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 información ejecutivos. Los usuarios y los
administradores generalmente de mandos altos y medios, reciben la
información sobre los indicadores de funcionamiento dominantes del
negocio y de las excepciones o las variaciones según sea de patrones
y de estándares preestablecidos. Los Sistemas de Información
Ejecutivos (EIS) presentan típicamente datos multidimensionales en
formatos gráficos.

OLAP en EIS
Alertas.
Toma de decisiones.

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
comunicación, análisis del mes-cierre, análisis de lo beneficioso del
producto, los presupuestos y pronóstico. Los analistas financieros
utilizan OLAP extensivamente para el análisis de datos financieros y
operacionales para contestar las preguntas de la gerencia mayor.

OLAP en la Actividad Financiera
Reportes analíticos.
Planeamiento.
Análisis.

Página 26 de 94

Ventas y aplicaciones de Marketing. Existen diferentes formas de
llegar a los clientes para alcanzar los objetivos de venta y de
comercialización propuestos. Por esto, la utilización de sistemas
OLAP, donde es importante contar con información organizada de
manera rápida, es aconsejable. Los ejemplos incluyen análisis de la
facturación, análisis de producto, análisis del cliente, y análisis de
ventas regional.

OLAP en el Marketing
Análisis de productos.
Análisis de Clientes.
Análisis de Facturación.

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

OLAP en Otros Usos
Análisis de la Producción.
Análisis de Servicios al cliente.
Evolución del Costo del producto.


El presente esquema representa las distintas etapas que se deben ejecutar
para la construcción de un Data Mart, desde que se identifican los datos
originales en los sistemas transaccionales hasta que los Usuarios pueden
disponer la información. A modo de guía, se irá indicando qué parte de estos
procesos cubre cada Unidad.

Página 27 de 94

Las etapas que deben cubrirse durante el proceso de construcción de un DW
cumplen con lo siguiente:
1. Identificación 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 selección, transformación e importación 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 información identificada en la etapa de requerimientos.

Para convertir los datos en información, 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 cómo estos datos reflejan metas y objetivos que abarcan
el negocio involucrado.
Un DW, clasifica la información en base a los aspectos que son de interés
para la empresa.
En el ambiente operacional se diseña alrededor de las aplicaciones y
funciones (ventas, facturación, stock, etc.). La base de datos combina los

Página 28 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 análisis del negocio se reconoce como un valor significativo
para una organización, las peticiones de los datos y de la información 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
información. En un sistema OLAP, estos temas se resuelven por única vez,
en la etapa de diseño.

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 homogéneos 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, transformación y carga de datos en un DW se
denominan ETL, sus siglas en inglés significan Extract –
Transform – Load.

Página 29 de 94

Es común 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 codificación 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. Básicamente deben realizarse las siguientes tareas:
Establecer las reglas que serán utilizadas para realizar la
transformación.
Detectar las inconsistencias que pueden originarse al tomar los datos
desde distintas fuentes.
Planificar cuidadosamente y con detalles la transformación de los
datos que den como resultado final conjuntos de datos consistentes.

Convenciones diferentes en el desarrollo de
aplicaciones
Codificación: Un claro ejemplo es la codificación y
descripción 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
transformación, habrá que elegir una convención
única para el DW, que puede ser “M” y “F y
transformar los datos.

Aplicación A: M y F

Aplicación B: 1 y 0 M-F
Aplicación C: Masculino y
Femenino

Unidades de medida de los atributos: Las unidades
pueden tener distintas unidades de medidas, según el
origen del sistema OLTP. Un ejemplo es hablar de
litro, centímetros cúbicos o hectolitros. Habrá que
elegir una única unidad de medida que sea útil para el
DW y transformar los datos.

Página 30 de 94

Aplicación A: Litros

Aplicación B: cm3 Litros

Aplicación 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 transformación correspondiente.

Aplicación A: yyyy/mm/dd

Aplicación B: mm/dd/yyyy dd/mm/yyyy

Aplicación C: dd/mm/yyyy

Varias columnas a una: En un sistema OLTP, los
datos de una persona, como ser Dirección pueden
almacenarse en diferentes campos de la misma tabla
(Calle, Número, 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.

Página 31 de 94

Una columna a varios: los sistemas más antiguos
solían colocar el tipo y número 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 número 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 máxima a
almacenar ene. SW y sumar los datos agrupando según ese
criterio. Al definirse la granularidad se está diciendo, al
mismo tiempo:

Las aperturas que son de interés.

El grado de detalle que se necesita.

Es decir, si tomamos como ejemplo la medición del tráfico
telefónico, puede definirse que se necesitan los totales de
llamados por cliente por día. Vemos que el máximo detalle
que es requerido es el día, no interesaría 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
Día.

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 día por factura o
por boca de expendio, obteniendo el resultado que vemos
en el gráfico.

Página 32 de 94

Una vez que contamos con el plan de trabajo desarrollado según las reglas
de transformación, 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 transformación.

Mala interpretación de los Requerimientos
Durante la etapa de relevamiento previo al diseño de un
sistema OLAP, es importante entender con precisión la
problemática del negocio. Esto incluye definir el hecho y qué
medidas serán necesarias desarrollar en el sistema.
Muchos sistemas no llegan a feliz término a causa de una
etapa de relevamiento en donde los requerimientos
planteados no apuntan a los objetivos del negocio.

Página 33 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 través 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 serán, justamente, las Ventas.
Vamos a comenzar analizando cada necesidad y cuál es la dimensión o
medida que habrá que crear para satisfacer la misma. Luego desarrollaremos
una tabla en donde resumiremos la información obtenida. Esta tabla nos
servirá en la etapa de diseño.

Analizaremos el primer conjunto de necesidades:
La cantidad de unidades vendidas en los países que alcanza el
Mercado actual.
En esta consigna se detecta como posible medida a las unidades vendidas,
la cual necesitamos ver detallada por País. Por otro lado, la cantidad de
unidades vendidas está referida a los productos: detectamos ya una nueva
dimensión, 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 dimensión 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 información, requiere que sea presentada por zona geográfica y
sucursal. Aquí tenemos una nueva dimensión 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

Página 34 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
categoría 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 según su categoría y los
clientes que los adquirieron. De aquí se desprende que necesitamos una
nueva dimensión Clientes y que los Productos deben mostrarse agrupados
por Categoría de Productos, cosa que nos define un nivel en la dimensión
Producto.
Premiar anualmente a aquellos vendedores que superen los objetivos
de venta que les fueran asignados. El análisis, 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 año fiscal (El
premio será distinto si se cumple con los objetivos globalmente para el
año o si, además, se cumplen los objetivos en todos los meses en
particular).
Sobre estos requerimientos, debemos agregar solamente la dimensión
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, podría ser de suma utilidad el
realizar el análisis de cada una de las medidas por Tipo de Sucursal.
Todo sistema DW contiene información histórica que la empresa analizará
para diferentes períodos, agregaremos una dimensión más denominada
Tiempo.
A su vez, es común que sea necesario que se quieran analizar las ventas
obteniendo el promedio de las mismas. Por lo tanto, viendo esta posible
necesidad, sería conveniente que desarrollar la medida Ventas Unidades
Promedio.

Para ver la información obtenida en los relevamientos de una manera más
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 dimensión.
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

Página 35 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 dónde 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 interés?
¿Ha relevado las aperturas por las cuales se analizará la
información?
¿Ha relevado las medidas o indicadores que se usarán
para evaluar los Hechos?
¿Cuál es la granularidad con que es necesaria ver la
información 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 selección, transformación y carga
de datos (ETL)?

Unidad 3. Diseñando una solución OLAP

Objetivos

Página 36 de 94

Comprender la formación 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 Introducción
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

Página 37 de 94

3.1. Introducción

Con lo aprendido en las unidades anteriores, podemos comenzar a definir el
diseño de nuestra base de datos OLAP.
En esta unidad, desarrollaremos el diseño 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 módulo, el lector comprenderá cómo definir la tabla de
hechos, cómo 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 visión desplegada del cubo.

Página 38 de 94

Data Mart: son almacenes de datos con información de
interés particular para un determinado sector de la empresa
Data Warehousing: es el conjunto de almacenes de datos
particulares (Data Mart) con información de interés para la
empresa en general

Cada uno de los siguientes son ejemplos Data Mart (DM)
Ventas
Recursos Humanos
Producción
El Data Warehousing es el conjunto de esos data mart
DM de Ventas + DM de Recursos Humanos + DM
de Producción

3.2. Construyendo el data mart
Hasta ahora hemos analizado los requerimientos del usuario, y depuramos
sus datos para la formación del data warehousing, en esta unidad
comenzaremos a diseñar 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 más pequeñas
que definirán 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 construcción del modelo.

3.3. Esquema Estrella
Para facilitar el análisis, 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 dimensión que
contienen los atributos de las aperturas que interesan al negocio que se
pueden utilizar como criterios de filtro y son relativamente pequeñas. Cada
tabla de dimensión se vincula con la tabla de hechos por un identificador.
Las características de un esquema de estrella son:

El centro de la estrella es la tabla de hecho.

Página 39 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 Admisión de Pacientes
(Hecho) por servicio, pacientes y zona geográfica a lo largo del
tiempo.

Dimensión Dimensión
Servicio Paciente

Tabla de Hechos
Admisión Pacientes

Tiempo Zona
Geográfica

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 numéricas, 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
serán analizados.

Página 40 de 94

Ejemplos de Hechos
En un hospital: admisión de pacientes
En un operador telefónico: Tráfico telefónico

Un hecho es un concepto de interés primario para el proceso
de toma de decisiones, corresponde a eventos que ocurren
dinámicamente en el negocio de la empresa.

3.3.2 Dimensiones
Diseñaremos y construiremos cada dimensión basados en los procesos de
negocio definidos por el cliente.
Las dimensiones organizan los datos en función de un área de interés para
los usuarios.
Cada dimensión describe un aspecto del negocio y proporciona el acceso
intuitivo y simple a datos.
Una dimensión provee al usuario de un gran número de combinaciones e
intersecciones para analizar datos.
Las tablas de dimensiones son las compañeras de las tablas de hechos.
Cada dimensión 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 dimensión en su esquema.
Cada nivel de una dimensión debe corresponderse con una columna en la
tabla de la dimensión. Los niveles se ordenan por grado de detalle y se
organizan en una estructura jerárquica. 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 dimensión existen relaciones,
estas se pueden comprender como las relaciones que existen en un árbol
genealógico donde los términos padre, hijo, hermano, primo, etc. indican una
correspondencia entre elementos del árbol; y los miembros de la dimensión
se comportan como familiares dentro del árbol genealógico.
Padre: Es el miembro del nivel inmediatamente superior que se
relaciona con el miembro seleccionado. Cada elemento tiene un solo
padre.

Página 41 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
dimensión es miembro de ella.

Página 42 de 94

Ejemplos de dimensión
Dimensión zona geográfica

* PAIS ARGENTINA BRASIL URUGUAY
** BUENOS CORDOB SAN MONTEVID
PROVINCIA AIRES A PABLO EO
MAR VILLA
LA
del GRAL.
*** CIUDAD PLAT
PLAT
BELGRA
…. …
A
A NO

Ejemplos de relaciones
En una dimensión zona geográfica tendríamos las
siguientes relaciones entres niveles y entre miembros:
Padre:
Argentina es padre de Buenos Aires y de Córdoba
Hijo:
Buenos Aires y Córdoba son hijos de Argentina
Hermano:
Buenos Aires y Córdoba son hermanos el uno al otro,
también son hermanos Argentina, Brasil y Uruguay.
Primo:
Mar del Plata es primo de Villa General Belgrano.
Descendiente:
Todos los miembros que estén 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

Página 43 de 94

Evitamos duplicar dimensiones locales
Aseguramos que los datos analizados estén 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 dimensión deberá ser modificada en todos
los cubos

Ejemplos de Dimensión Compartida
La dimensión Producto puede utilizarse para el Data
Mart Ventas y para el Data Mart Producción.
Así, la dimensión producto es una dimensión compartida
por los dos Data Mart.

Al definir una dimensión debemos prestar especial
atención en los requerimientos del cliente, ya que una
mala definición de la dimensión, o de sus niveles podría
implicar que no obtengamos los resultados deseados.
Si la definición de las dimensiones no es la correcta, no
serán 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
modificación o cambio en una dimensión compartida sea
válida para todos los cubos que la empleen

3.3.2.2 Dimensiones: Esquema Estrella
En el esquema estrella cada dimensión 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 dimensión están desnormalizadas lograremos en
el modelo del data mart, una menor cantidad de tablas.

Página 44 de 94

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

Servicio Paciente

Tabla de Hechos
Admisión Pacientes

Tiempo Zona
Geográfica

3.3.2.3 Dimensiones: Esquema Copo de Nieve
El esquema copo de nieve es una variación del esquema estrella donde
alguna punta de la estrella se explota en más tablas.
El nombre del esquema se debe a que el diagrama se asemeja a un copo de
nieve.
En este esquema, las tablas de dimensión copo de nieve se encuentran
normalizadas para eliminar redundancia de datos.
A diferencia del esquema estrella, los datos de las dimensiones se reparten
en múltiples 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 características de un copo de nieve:
La dimensión esta normalizada
Los distintos niveles se encuentran almacenados en tablas separadas
Se argumenta ahorro de espacio

Página 45 de 94

Se muestra un esquema donde la dimensión zona geográfica
presenta un esquema copo de nieve.

Copo de nieve
País
Dimensión zona
Geografica

Provincia

Servicio
Ciudad

Admisión
Paciente

Paciente Tiempo

Ejemplo de Tabla Normalizada y Tabla Desnormalizada
En la imagen vemos en la tabla normalizada los datos nombre
de país y nombre de provincia aparecerán una sola vez en las
tablas País y Provincia respectivamente.
Si en cambio, la tabla esta desnormalizada tendremos
redundancia de datos, ya que se repetirán los datos del País y
de la Provincia por cada Ciudad.

Normalizada Desnormalizada

País
ID_País Zona Geográfica
Provincia
País
ID_ Provincia
Provincia Id _ País
ID_País País
ID_Provincia
Provincia
ID_Ciudad
Ciudad Ciudad

ID_ Ciudad
Ciudad
ID_Provincia

Estrella Copo de nieve
Cantidad de tablas Menor Mayor

Página 46 de 94

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

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

Ejemplos de Dimensión Padre - Hijo
La dimensión 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, Créditos
y Caja, y el rubro Caja a su vez contiene Caja y Fondo Fijo.

Las dimensiones virtuales, no requieren un almacenamiento físico en el cubo,
se evalúan en el momento de la consulta.
Funcionan de manera similar a las dimensiones reales y son transparentes
para el usuario.

Página 47 de 94

Ejemplos de Dimensión Virtual
Podemos tener una dimensión Producto organizada de la
siguiente manera:
Producto (Dimensión real)
……
Fabricante
Marca
Calibre
Producto

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

Producto_Marca (Dimensión virtual 1)
……
Marca
Fabricante
Calibre
Producto

Otra necesidad del usuario podría ser obtener los totales o
filtros de calibre sin importar la marca o el fabricante,
entonces construiríamos una dimensión virtual que
contenga solo la columna calibre.

Calibre (Dimensión virtual 2)
Calibre

Mencionaremos esta dimensión ya que ocupa un lugar especial en cada data
mart. Recordemos que el tiempo es parte implícita de la información que
contiene el data mart.
Esta dimensión la podemos definir separándola en distintas jerarquías de
tiempo:
Año
Semestre
Mes

Página 48 de 94

Ejemplos de Dimensión Tiempo

La definición de la jerarquía la haremos teniendo en cuenta las necesidades
que tiene la organización. Debemos contemplar los periodos de tiempo por
los cuales la información necesita ser analizada y la regularidad con la que
se cargaran los datos en el cubo.
Consideraciones para esta dimensión:
Nombres de los miembros: Cuando construyamos la dimensión tiempo es
conveniente que los nombres de los miembros sean únicos. Así, si utilizamos
una nomenclatura para la jerarquía MES que sea “Mes – Año” cuando
busquemos un periodo debemos identificarlo como Julio – 2006. De esta
manera nos ahorramos de utilizar dos niveles de la dimensión logrando una
mayor calidad en los informes.
Si en cambio, el nombre de la jerarquía MES se compone solo del nombre del
mes, para identificar el periodo Julio del 2006 primero debemos seleccionar
sobre el nivel Año y luego sobre el nivel Mes.
Puede existir mas de una: Cabe aclarar que no necesariamente esta
dimensión es única dentro del cubo, podríamos tener que armar más de una
dimensión Tiempo. Si necesitáramos analizar la información de la empresa
en base al año calendario y realizar otro análisis basándonos en el año fiscal,
deberíamos 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, numérica, 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 numéricos porque estos valores son las bases de las cuales el
usuario puede realizar cálculos.
Si la medida fuera un valor no numérico debemos codificarla a un valor
numérico en el proceso de obtención de datos, y luego cuando tengamos que
exponer sus valores decodificarla para mostrarla con el valor original.
Las siguientes son algunas de las características de las medidas:

Página 49 de 94

Deben ser numéricas.
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 Admisión de
Pacientes las medidas pueden ser:
Pacientes Admitidos
Pacientes Atendidos
En un operador telefónico, donde el hecho es Trafico
Telefónico, las medidas pueden ser:
Llamadas Cantidad
Llamadas Duración

Ejemplos de Medidas no numéricas
Supongamos el hecho Recursos Humanos, donde
podemos tener la medida Sexo que toma los valores “F” o
“M”.
Estos valores debemos codificarlos en valores numéricos
durante el proceso de transformación 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 numéricas que queremos analizar que provienen
directamente de los sistemas OLTP.
Cuando definimos una medida debemos tener en cuenta cual será la forma
de agregación (agrupación de la misma) al subir por la estructura
dimensional.
Estas formas de agregación pueden ser:
Suma: es la operación que suma los valores de las columnas
Cuenta: realiza un conteo de los valores
Mínima: devuelve un valor mínimo
Máxima: proporciona el mayor de los valores

Página 50 de 94

Cuenta de Distintos: cuenta los valores diferentes

Las agregaciones son resúmenes 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 expresión medidas calculadas es muy amplio y engloba a
cualquier manipulación de las medidas naturales que nos faciliten el análisis
de los hechos.
En una medida calculada puede haber:
Cálculos Matemáticos
Expresiones condicionales
Alertas
Estos tres tipos (cálculos, condiciones y alertas) usualmente pueden existir
juntos dentro de la misma medida calculada.

Página 51 de 94

Calculo Matemático
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 Dotación.
Expresiones condicionales
Para la medida calculada anterior, Promedio de Horas
Extras, necesitaremos verificar la condición de numerador
diferente de cero para evitar que la división nos arroje un
error.
Si Dotación es distinto de cero entonces Promedio de
Horas Extras será igual a Horas Extras dividido Dotación.
Si Dotación 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á vacía.
Podemos construir una medida Cumplimiento de Ventas
que sea una alerta del tipo semáforo 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 más del 80 % de lo
presupuestado.

Página 52 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 Construcción de las Dimensiones
Etapa 2 Armado de la Tabla de Hechos
Etapa 3 Definición de las Medidas
Construcción de las Dimensiones
Como primer paso definiremos las dimensiones porque estas nos darán 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 según 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, debería haber una exacta coincidencia entre
la definición 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 están correctos o bien
definimos mal las dimensiones.
Comenzaremos por la Dimensión Tiempo ya que, como aprendimos en esta
unidad, es la más importante dentro de cualquier data mart.
Nuestro cliente necesita analizar sus datos diariamente, entonces definiremos
los niveles:
Año
Semestre

Página 53 de 94

Trimestre
Mes
Día

La tabla de dimensión quedara formada:

Dimensión Tiempo

* Año
** Semestre
*** Trimestre
**** Mes
***** Día

Dimensión Sucursal, usaremos un esquema estrella y su estructura jerárquica
será:

Dimensión Sucursal

* Sucursal
** Tipo Sucursal
*** País
**** Provincia
***** Ciudad

Dimensión Vendedor, al igual que sucursal, tendrá un esquema estrella y
quedará definida por los niveles:

Dimensión Vendedor

* Sucursal
** Sección
*** Vendedor

Dimensión Cliente tendrá todos los atributos de un cliente.

Dimensión Cliente

* País
** Provincia
*** Ciudad
**** Razón Social

Dimensión Producto, esta dimensión la construiremos según un esquema
copo de nieve. En estos casos se mantiene la normalización propia de los

Página 54 de 94

sistemas OLTP. Cada tabla contiene los datos iniciales y su relación con el
resto.
La dimensión nos quedará normalizada por lo que usaremos más tablas para
construirla.
Nuestro cliente puede clasificar sus productos según la categoría, 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.
Fact_Ventas

ID_Fecha
ID_Producto
ID_Cliente
ID_Vendedor

Definición de las Medidas
Recordemos que las medidas son los valores numéricos que el usuario desea

Página 55 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:

Fact_Ventas

ID_Fecha
ID_Producto
ID_Cliente
ID_Vendedor
Ventas_Importe
Ventas_Costo
Ventas_Unidades

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á también 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 días, comprobando la condición
del numerador diferente de cero.

Realizadas estas tres etapas, podemos ver el diseño completo de nuestro
data mart.

Página 56 de 94

Lecciones Aprendidas
Un Data Mart adopta un esquema estrella para
maximizar la performance de las consultas.
Las dimensiones son categorías descriptivas
por las cuales las medidas se pueden separar
para el análisis.
La dimensión Tiempo esta implícita en todo
Data Mart
Las medidas son los datos numéricos de
interés primario para el cliente
Con las medidas calculadas se pueden
construir alertas

Página 57 de 94

Preguntas de Reflexión
¿Tenemos claramente definidos los requerimientos?
¿Conocemos los hechos que se quieren analizar, los
indicadores y las aperturas por las cuales se quiere
hacer el análisis?
¿Concuerda esta definición con las tablas auxiliares que
creamos y poblamos con datos de los sistemas OLTP?
¿Sabemos si los usuarios utilizarán las dimensiones para
navegar o para filtrar?
¿Cubren las dimensiones diseñadas 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 agregación, al salir de la
granularidad mínima, para todas las medidas naturales?
¿Están definidas las fórmulas o criterios de todas las
medidas calculadas?
¿Están correctamente documentadas todas las
definiciones?

Unidad 4. Construyendo una solución OLAP

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


Página 58 de 94

Academia latinoamericana de Business Intelligence albi

Academia latinoamericana de Business Intelligence albi

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (9)

Similaire à Academia latinoamericana de Business Intelligence albi

Similaire à Academia latinoamericana de Business Intelligence albi (20)

Dernier

Dernier (20)

Academia latinoamericana de Business Intelligence albi