Professional Documents
Culture Documents
Inteligencia de
Negocios
1. Introducción a los
SSD y a DW
(Gartner, http://www.gartner.com/it-glossary/business-
intelligence-bi, s.f.)
Introducción
1
mejores prácticas que permiten el acceso y análisis de información para
mejorar y optimizar las decisiones y el desempeño”.
(http://goo.gl/oIeCU, 2008)
2
La comunidad de negocios debe aceptar al sistema de BI para que
sea exitoso.
Por otro lado, Ralph Kimball (2013) sostiene que estos dos últimos
requerimientos son los más críticos y frecuentemente los más
desatendidos por las organizaciones a la hora de implementar un sistema
de BI.
Historia
Los software MIS, que generalmente contaban con una interfaz de usuario
poco amigable, tampoco tenían grandes capacidades de modelado y
estaban más bien orientados a la integración de información para la toma
de decisiones.
3
Los Sistemas de Gestión de Bases de Datos (DBMS, Database Management
Systems en inglés) que surgieron en la década de 1970, verdaderamente
iniciaron una nueva era informática con el advenimiento del denominado
procesamiento transaccional en línea (OLTP, Online Transaction
Processing).
William Inmon (2005) alega que los primeros Almacenes de Datos (más
conocidos como Data Warehouses en inglés) nacen en 1983.
4
(OLAP), Exploration Warehouses, ODS, entre otros (conceptos que veremos
más adelante en esta misma unidad).
5
1.3 Necesidades
Ralph Kimball (2013) considera que uno de los activos más importantes de
cualquier organización es su información. Este activo es casi siempre usado
para dos propósitos: la preservación de los registros
operativos/transaccionales y la toma de decisiones analítica.
Ahora, ¿quién necesita de BI? En este sentido, Josep Lluís Cano (2007, p.
30) sostiene que “la información que podemos generar a partir de Business
6
Intelligence es útil para todos los departamentos de nuestra organización”.
Esto incluye a los responsables o gerentes de departamentos tales como:
Compras
Ventas / Comercial
Finanzas
Marketing
Recursos Humanos
Operaciones
entre otros.
1.4 Problemática
Ralph Kimball (2013) sostiene que los problemas típicos de los usuarios
pueden sintetizarse en algunas de las demandas que mencionamos a
continuación:
7
Por otro lado, William Inmon (2005) expresa que la inexistencia de una
solución BI lleva a los siguientes problemas:
Algoritmos diferentes
Del mismo modo que en el caso anterior, si no existe una base de datos
única e integrada para el análisis de la información se produce una fuerte
pérdida de productividad al tener que, por cada análisis requerido, revisar
distintos archivos, bases de datos, etc., compilando información muchas
veces contradictoria y sin una regla explícita de integración que puede
depender de lo que hace cada analista en un momento dado. Hay una
evidente sobrecarga de trabajo al tener que producir un reporte o informe
manualmente.
8
La Incapacidad de Convertir Datos en Información
1.5 Beneficios
De acuerdo con Josep Lluís Cano (2007, p. 32), “uno de los objetivos
básicos de los sistemas de información es que nos ayuden a la toma de
decisiones. Cuando un responsable tiene que tomar una decisión pide o
busca información, que le servirá para reducir la incertidumbre”.
Los beneficios que se pueden obtener a través del uso de BI pueden ser de
distintos tipos:
9
Beneficios intangibles: el hecho de que tengamos disponible la
información para la toma de decisiones hará que más usuarios
utilicen dicha información para tomar decisiones y mejorar la
nuestra posición competitiva.
Este mismo autor también sostiene que (2007, p. 37) “la principal razón de
un proyecto de Business Intelligence es el análisis de un problema o
problemas interrelacionados”.
10
inversión (ROI). El ROI pone en relación el valor aportado al
negocio con las inversiones necesarias para obtenerlo. Una forma
simplificada del cálculo del ROI es:
11
En donde NPV es el Valor Neto Actual, es decir, la suma
actualizada de los beneficios esperados del proyecto.
Además, de acuerdo con Josep Lluís Cano (2007, p. 52), “los proyectos de
Business Intelligence tienen un ROI elevado, su comportamiento es mucho
mejor que en el resto de proyectos de Sistemas de Información”.
Inteligencia
Diseño
Selección
Implementación.
12
A continuación veremos cada una de estas fases:
Fase de Inteligencia
Fase de Diseño
Fase de Selección
La etapa de Selección:
Consiste en elegir entre alternativas de solución. Aquí el
encargado de la toma de decisiones podría necesitar un sistema
DSS más grande para obtener datos más extensos a partir de
varias alternativas y modelos complejos, o bien, herramientas de
análisis de datos para recabar todos los costos, consecuencias y
oportunidades.
13
Fase de Implementación
1.7 CIF
Niveles de Datos
Nivel Operacional
14
Nivel Individual.
Estos niveles son la base del concepto del Corporate Information Factory
(CIF). A continuación, describiremos las principales características de cada
uno de estos niveles de datos:
Nivel Operacional
Nivel Departamental
Nivel Individual
15
Imagen 1: Niveles de Datos
Resulta evidente que los tipos de consultas que se pueden efectuar en cada
nivel de datos son distintos. Así, los diferentes niveles de datos requieren
un conjunto de entidades arquitectónicas diferenciadas. Estas entidades
constituyen el Corporate Information Factory (CIF).
Como señalan Josep Lluís Cano (2007), William Inmon (2005) y Ralph
Kimball (2013), los distintos componentes del CIF y, por ende, de una
solución de BI, son (aunque no siempre encontraremos todos ellos):
Fuentes de Información
Data Warehouse
Data Mart
16
Repositorio de Metadatos
Exploration Warehouse
17
Fuentes de Información
Según Josep Lluís Cano (2007), las fuentes de información hacen referencia
a los lugares (bases de datos, etc.) de donde se extraerán los datos para
alimentar el Data Warehouse.
18
Pero también existen otras fuentes de información de las cuales se pueden
llegar a tomar datos según las necesidades, tales como:
Otros.
Factores a Considerar
Según Josep Lluís Cano (2007), hay distintos factores que contribuyen a la
complejidad de la carga de información; entre ellos el autor destaca la
cantidad de fuentes diferentes de información, teniendo en cuenta que en
las grandes corporaciones es natural hablar de una media de 8 bases de
datos hasta llegar incluso a 50.
19
información no estructurada tenemos: correos electrónicos,
cartas, informes, videos, etc.
Calidad de Datos
De acuerdo con Josep Lluís Cano (2007), una vez que ya se han establecido
cuáles serán las fuentes de información debe procederse a verificar la
calidad de los datos del Data Warehouse, lo cual es un aspecto esencial.
Consecuentemente, es necesario asegurar que la calidad de los
datos es máxima. Si en el Data Warehouse hay errores, éstos se
propagarán a lo largo de toda la organización y son muy difíciles
de localizar. Además, pueden ocasionar que se tomen decisiones
erróneas que afecten a los resultados de la organización. Los
costes derivados de que la calidad de los datos no sea la correcta
pueden llegar a ser muy elevados.
20
de mejora en los mismos. Muchos de estos casos se deben a que
los usuarios pueden introducir datos sin ningún tipo de control.
Siempre que se pueda, es recomendable que los usuarios elijan
entre distintos valores, en lugar de introducirlos libremente ellos.
No es una buena opción corregirlos en el proceso ETL y no
modificar las aplicaciones origen. Esta alternativa es mucho más
rápida inicialmente, pero mucho más costosa a largo plazo.
(2007, p. 100)
21
5) Validez: ¿Son los valores aceptables en los rangos definidos por
el negocio?
Concepto de ETL
22
Proceso ETL en el Proyecto de BI
El diseño de los procesos ETL insume gran parte del tiempo de un proyecto
BI. Se trata de una tarea compleja, pero para poder aprovechar los
beneficios del Data Warehouse es fundamental que se logre la integración
de datos desde los distintos orígenes.
Josep Lluís Cano señala que “el proceso de ETL consume entre el 60% y el
80% del tiempo de un proyecto de Business Intelligence, por lo que es un
proceso clave en la vida de todo proyecto” (2007, p. 103).
23
Problema de Integración de Datos
Ocurre que cuando fueron diseñados esos sistemas nadie pensó en futuras
integraciones. Cada una tuvo sus propios requerimientos. Por lo tanto,
extraer datos de distintos lugares e integrarlos en una base de datos única
es un problema complejo.
Formatos diferentes.
24
Eficiencia en el Acceso a los Sistemas
Transaccionales
Extraer los datos que tienen marca temporal en las bases de datos
operacionales. Sólo se traen los datos desde la última fecha y hora
de actualización.
25
Desafíos en los Procesos ETL
De acuerdo con William Inmon (2005), los procesos ETL encaran varios
desafíos complejos:
Sumarización de datos.
Renombre de datos.
Otros.
26
Enterprise Data Warehouse
27
seguros de autos, vida, casa, salud, etc. Las principales áreas de
interés podrían ser: cliente, póliza, etc. Cada tipo de empresa tiene
sus propias áreas de interés. A su vez, cada área de interés está
físicamente implementada como una serie de tablas relacionadas
en el Data Warehouse. Por ejemplo, para el área “Clientes” podría
haber una tabla con todos los clientes de la empresa y varias tablas
con la actividad de estos clientes, algunas con los eventos
detallados y otras con sumarizaciones o agregaciones (como
cantidad de transacciones realizadas por mes, promedio de
accidentes por año, etc.); todas las tablas estarán relacionadas por
el ID del Cliente.
28
año, mes o día, pero el Data Warehouse siempre contiene algún
elemento de tiempo.
Data Mart
Normalmente, los Data Mart son más pequeños que los Data
Warehouses. Tienen menos cantidad de información, menos
modelos de negocio y son utilizados por un número inferior de
usuarios.
29
Repositorio de Metadatos
Modelo de datos
30
utilizando la misma terminología y con el mismo significado, lo
cual no siempre es sencillo. Cuando alguien hable de “margen
bruto” o “margen de contribución” deberá estar absolutamente
definido para la organización. Evidentemente, organizaciones
distintas tendrán normalmente definiciones distintas.
Imagen 4: Metadatos
31
Operational Data Store (ODS)
De acuerdo con William Inmon (2005), con los ODS fue posible hacer
procesamiento en tiempo real contra datos integrados.
Existe un componente tecnológico, los Operational Data Store
(ODS) que a veces se confunden con los Data Warehouses. Los
ODS son una extensión de la tecnología de los Data Warehouses.
Clases de ODS
32
económicamente. Mayormente se opta simplemente por pasar
datos del entorno operacional al ODS sin integrarlos.
33
El diseño del ODS sigue un modelo híbrido, puede hacerse siguiendo
modelo relacional en una parte y multidimensional en otra parte;
dependerá de los requerimientos en cuanto a flexibilidad y performance.
Exploration Warehouse
34
Data Mining Warehouse
Sin embargo, dado que las diferencias son sutiles -salvo en grandes
corporaciones-, pueden estar bajo la misma estructura.
35
Herramientas de Dashboard y Scorecard: Permiten a los
usuarios finales ver información crítica para el rendimiento con
un simple vistazo, utilizando iconos gráficos y con la posibilidad
de ver más detalle para analizar información detallada e
informes si así lo desean.
Herramientas OLAP
Josep Lluís Cano expresa que “existen distintas tecnologías que nos
permiten analizar la información que reside en un Data Warehouse, pero la
más extendida es el OLAP” (2007, p. 125).
36
tendencias que otras herramientas menos flexibles no pueden
aportar.
37
En el ejemplo anterior, la cantidad de unidades vendidas de cada uno de
los libros por cliente y por año es lo que se denomina un Hecho. A su vez,
las dimensiones son:
Clientes
Libros
Años (Tiempo).
Incluso, una dimensión dada puede tener una jerarquía específica. Por
ejemplo, generalmente la dimensión Tiempo tiene una jerarquía del tipo:
Año
Mes
Día.
Slice
Dice
Roll-Up
Drill-Down
Roll-Across
Drill-Across
Pivot.
38
Herramientas de Visualización por Lógica Asociativa
De acuerdo con Josep Lluís Cano, “una alternativa al OLAP son las
herramientas que utilizan consultas de lógica asociativa” (2007, p. 131). En
este tipo de herramientas, cuando se realiza una consulta se accede
directamente a los datos (ya sea de la base de datos transaccional o al Data
Warehouse preferentemente) pero sin diseñar un cubo, sin dimensiones ni
jerarquías predefinidas y sin restricciones en cuanto al volumen de
información.
El modelo de almacenamiento interno proporciona una visión
“vertical” (basada en columnas) de los datos así como una visión
“horizontal ampliada” (basado en fi las) que va más allá de la
tecnología de bases de datos relacionales. Cada columna
almacena cada valor diferente de forma separada con la
frecuencia y usos de cada valor. Las consultas son altamente
eficientes por el nuevo modelo de almacenamiento y el conjunto
de operaciones utilizados para resolver las consultas.
39
Bibliografía Lectura 1
www.uesiglo21.edu.ar
40
Módulo 2
Arquitectura de
Soluciones de BI
2. Arquitectura de
Soluciones
“Un Data Warehouse es una colección de información creada
para soportar las aplicaciones de toma de decisiones”
Granularidad
Particionamiento
Granularidad
Mientras más detalle tenga el Data Warehouse, más bajo será el nivel de
granularidad. A menor detalle, mayor nivel de granularidad. Por ejemplo,
1
una única transacción estaría en el nivel más bajo de granularidad,
mientras que un resumen de todas las transacciones realizadas durante el
mes en curso estaría en un nivel más alto de granularidad.
Imagen 1: Granularidad
Granularidad
El nivel de Detalle
Ejemplo: Ejemplo:
El detalle de cada llamada El resumen de llamadas
telefónica realizada por un telefónicas realizadas por un
cliente para un mes cliente para un mes
2
Según William Inmon (2005), los beneficios de un bajo nivel de
granularidad son los siguientes:
3
Niveles Duales de Granularidad y Tablas Sumarizadas
Sin embargo, William Inmon (2005) destaca que cuando una organización
tiene gran necesidad de eficiencia en el almacenamiento y acceso a los
datos, y a la vez la necesidad de contar con la capacidad de analizar datos
en detalle sobre un Data Warehouse de gran volumen de datos, debería
considerarse la posibilidad de contar con dos o más niveles de granularidad
en simultáneo.
De esta manera, puede tenerse una tabla detallada y una o más tablas
sumarizadas que favorecen determinadas consultas al estar ya pre-
calculadas; es decir, además de contar con una estructura de tablas con
todos los registros históricos detallados, contar también con tablas que
sumaricen esos registros para facilitar las consultas y mejorar la
performance de las aplicaciones DSS que usen el Data Warehouse como
fuente.
4
Particionamiento
Reestructuradas
Indexadas
Secuencialmente escaneadas
Reorganizadas
Recuperadas
Monitoreadas.
Por Fecha
5
Aunque definitivamente la fecha es un criterio mandatorio, casi siempre es
empleado. Incluso, en ocasiones puede ser necesario hacerlo ya que la
definición o estructura de los datos puede variar de un año a otro. Por
ejemplo, en lugar de tener una tabla con gran cantidad de registros,
podríamos tener varias tablas con las actividades de los años 2009, 2010,
2011, 2012 y 2013, por separado.
Imagen 2: Particionamiento
2009
------- 2010
------- -------
------- -------
-------
2011
-------
-------
-------
2013
-------
-------
2012
-------
-------
-------
-------
6
2.2 Datawarehouse: Comparación con
OLTP
7
Datos Primitivos / Operacionales Datos Derivados / Decisionales (DSS)
(OLTP)
8
En definitiva, según William Inmon (2005) las principales diferencias entre
ambos esquemas son:
Los datos primitivos son datos detallados, usados para ejecutar las
operaciones diarias de la organización. Los datos derivados han sido
sumarizados o pre-calculados para satisfacer las necesidades de la
gerencia.
Los datos primitivos son datos de valor actual. Los datos derivados
son datos históricos.
9
normalizados bajo la tercera forma normal. Así, el modelo
Relacional produce un diseño muy flexible. Flexibilidad en términos
de que el diseño puede adaptarse a distintas vistas. Esta es la mayor
fortaleza junto con la versatilidad, dado que los datos detallados
pueden combinarse: pueden soportarse muchas vistas distintas.
10
modelo Multidimensional ofrece una performance similar con un
acceso directo a los datos.
2.4 Arquitectura
11
La ventaja del modelo Relacional apunta a su flexibilidad al cambio, hacia
nuevos requerimientos o nuevos grupos de usuarios que tienen
necesidades distintas.
William Inmon (2005) alega que los Data Warehouses se diseñan a partir
de los requerimientos de información corporativos de toda la organización,
y no desde los requerimientos departamentales (como un Data Mart). Por
lo tanto, crear un Data Warehouse con un modelo Multidimensional sería
un error ya que el resultado será un Data Warehouse optimizado para una
comunidad de usuarios a expensas de otros usuarios.
12
presentación implican doble proceso de ETL, lo cual requiere más tiempo e
inversión para el desarrollo, mayor tiempo de actualización de los datos y
más capacidad para almacenar las múltiples copias de datos. Aunque la
consistencia de datos a nivel empresarial es un objetivo fundamental de un
Data Warehouse, puede ser más efectivo y menos costoso no incluir en el
ETL estas estructuras normalizadas.
13
Al igual que el enfoque de Kimball, el Corporate Information Factory
subraya la coordinación e integración de datos empresariales. El Corporate
Information Factory dice que el Enterprise Data Warehouse normalizado
satisface este rol, mientras que la arquitectura de Kimball recalca la
importancia de un Enterprise Data Warehouse Bus Architecture con
dimensiones compartidas.
Este enfoque trae lo mejor de los dos mundos, pero este esquema híbrido
sólo puede ser apropiado si la empresa ya invirtió en un Enterprise Data
Warehouse normalizad, porque iniciar desde cero implica más costos y más
tiempo, tanto en desarrollo como operación continua, dados los múltiples
movimientos de datos y almacenamiento redundante de datos detallados.
14
2.5 Datamart
Arquitecturas Disponibles
15
necesariamente dio el mismo resultado al usar distintas fórmulas o reglas
de negocio.
16
Data Marts Dependientes
18
información” y posponer la toma de decisiones que conciernen a
la definición de criterios y modelos de negocio. Si seguimos esta
estrategia debemos tener claro el plan de acción, es decir, qué
áreas cubriremos y la integración de los distintos modelos. Esta
estrategia se utiliza a veces como un paso previo al desarrollo de
un Data Warehouse corporativo.
Definición
19
La minería de datos es parte de un proceso iterativo mayor llamado
descubrimiento de conocimiento en base de datos (KDD, Knowledge
Discovery in Databases en Inglés).
20
técnicas de minería nos ayudan a identificar los aspectos
característicos de nuestros servicios que han hecho leales a algunos
de nuestros clientes para tratar de replicarlos con los demás
clientes. Además, nos puede informar sobre las características
particulares de nuestros clientes leales para obtener un perfil de los
mismos y luego focalizar las campañas de incorporación de nuevos
clientes en personas con el mismo perfil, es decir, con una alta
probabilidad de tener una relación a largo término con la empresa.
21
más eficiente que las tecnologías anteriores. Los algoritmos de
minería permiten echar luz sobre tendencias y relaciones que no
son evidentes en los grandes cúmulos de datos, y las nuevas
técnicas gráficas permiten visualizar complejos modelos de
información que facilitan el análisis y la comparación. Las técnicas
de minería ayudan a los aseguradores a segmentar sus clientes para
poder tratarlos de forma diferenciada y dividirlos en subconjuntos
con un riesgo asociado a cada grupo.
Modelado Predictivo
Análisis de Relaciones
Detección de Desviaciones
Los datos pueden, desde ya, ser continuos, caso en el cual pueden asumir
cualquier valor numérico (por ejemplo, la cantidad vendida); o discretos,
incluidos dentro de clases discretas (como azul, verde, rojo, etc.). Los datos
discretos pueden ser, además, definidos o categorizados en ordinales, los
22
cuales tienen un orden significativo (por ejemplo: alto, medio, bajo); o
nominales, los que están desordenados (por ejemplo, los códigos postales).
23
anteriormente), usa resultados conocidos para guiar sus
predicciones.
24
2.7 Balanced Scorecard
25
agregado en la empresa (ejemplo: reduciendo el presupuesto de
investigación y desarrollo).
Como sostiene Paul Niven (2002, p. 33), “se necesita un sistema que
equilibre la exactitud histórica de las cifras financieras con los impulsores
de los resultados futuros, al mismo tiempo que ayude a las empresas a
poner en marcha sus estrategias diferenciadoras”.
Perspectivas
Clientes
Procesos Internos
Aprendizaje y Crecimiento
Financiera
Perspectiva Clientes
Según Paul Niven (2002, p. 38), “al elegir las medidas (indicadores) que
formarán parte de la perspectiva del cliente dentro del cuadro de mando,
las empresas deben responder a dos preguntas fundamentales: ¿Quiénes
26
son nuestros clientes? y ¿cuál es nuestra proposición de valor al
servirlos?”.
- Cuota de mercado
- Tasa de rentabilidad
- Precio directo
- Clientes perdidos
- Retención de clientes
- Número de clientes
27
- Número de propuestas hechas
- Reconocimiento de marca
- Tasa de respuesta
- Volumen de ventas
- Entrega a tiempo
28
- Tiempo de espera medio
- Rotación de inventario
- Emisiones medioambientales
- Participación de la comunidad
- Patentes pendientes
- Falta de existencias
- Porcentaje de defectos
- Momento de equilibrio
- Mejoras continuas
- Reclamaciones de garantías
- Reducción desperdicios
- Tiempo muerto
- Exactitud de la planificación
29
- Tiempo necesario para salir al mercado de nuevos productos /
servicios
En esta perspectiva, de acuerdo con Paul Niven (2002, pp. 39-40), “si se
quieren alcanzar resultados ambiciosos con respecto a los procesos
internos, los clientes y también los accionistas, ¿qué se puede hacer? Las
medidas concernientes a la perspectiva de aprendizaje y crecimiento son
verdaderos facilitantes de las otras tres perspectivas”.
- Ausentismo
- Tasa de rotación
30
- Valor añadido por empleado
- Índice de motivación
- Tasas de diversidad
- Promoción de la salud
- Horas de formación
- Desarrollo de liderazgo
- Planificación de la comunicación
- Tareas interfuncionales
- Violaciones de la ética
31
Perspectiva Financiera
De acuerdo con Paul Niven (2002, p. 40), “las medidas de esta perspectiva
nos dicen si la ejecución de nuestra estrategia, detallada a través de
medidas elegidas en las otras perspectivas, nos está llevando a resultados
finales mejores”.
- Margen bruto
- Beneficio neto
- Ingresos
32
- Valor económico añadido (EVA)
- Dividendos
- Valor de mercado
- Mix de accionistas
- Flujo de caja
- Costos totales
- Calificación crediticia
- Deuda
- Intereses ganados
- Días en inventario
33
Imagen 6: Perspectivas del Balanced Scorecard
Perspectiva
Financiera
Indicadores
Iniciativas
Objetivos
¿Qué objetivos
Metas
financieros debemos
alcanzar para ser
exitosos?
Indicadores
¿Qué necesidades de
Iniciativas
Iniciativas
Objetivos
Objetivos
los clientes debemos ¿En qué procesos
Metas
Metas
satisfacer para tener debemos ser
éxito? Visión y Estrategia excelentes para
satisfacer a nuestros
accionistas y clientes?
Perspectiva
Aprendizaje y
Indicadores
Iniciativas
Crecimiento
Objetivos
Metas
¿Cómo debemos
aprender a cambiar,
innovar y mejorar
para alcanzar
nuestros objetivos?
Como destaca Paul Niven (2002, pp. 47-48), el equilibrio en el sistema del
Balanced Scorecard se refiere a tres aspectos:
34
Desarrollo del Cuadro de Mando Integral
Desde luego, de los pasos anteriores debe quedar claro que la Misión,
Visión, Valores y la Estrategia de la empresa seguramente ya existen.
35
Modelización del Negocio
36
Si el modelo de negocio está bien definido nos permitirá
responder preguntas clave de la gestión de nuestra organización.
37
resultados en la organización, es decir, aquellos que son
esenciales para conseguir los objetivos.
Scorecards
38
Bibliografía Lectura 2
www.uesiglo21.edu.ar
39
Módulo 3
Modelado
Multidimensional
3. Análisis
Multidimensional
El análisis multidimensional nos facilita el análisis de un hecho
desde distintas perspectivas o dimensiones. Esta es la forma
natural que se aplica para analizar la información por parte de
los tomadores de decisiones, ya que los modelos de negocio
normalmente son multidimensionales.
¿Qué es un Modelo?
1
Modelado Relacional
De acuerdo con Josep Lluís Cano (2007, p. 71), “una vez definido el modelo
de negocio debemos determinar qué información tenemos para
analizarlo”.
2
El orden de los registros no es significativo.
Modelado Multidimensional
Como sostiene Josep Lluís Cano (2007), a partir del esquema entidad-
relación, original de los sistemas transaccionales, se deberá construir el
esquema multidimensional (usualmente tipo estrella, como veremos más
adelante en esta misma Lectura) que nos permitirá analizar la información
en la base de datos analítica.
3
Responder consultas con rápida performance.
4
3.2 RDM vs. MDM
Ralph Kimball (2013) establece que existen cinco mitos sobre el modelado
Multidimensional:
Dado que no se pueden predecir todas las consultas que harán los
usuarios, es necesario que se acceda a los datos detallados.
5
Mito 2: Los modelos multidimensionales son
departamentales, no empresariales
6
generalmente son estables, excepto por los análisis que están
continuamente evolucionando.
Hechos
Dimensiones
Elementos
Atributos
Miembros
Tablas de Hechos
Tablas de Dimensión
Esquemas.
7
Hechos
Ejemplo: Ventas en $.
Dimensiones
Ejemplos: Tiempo (año, mes, día, entre otros), Zona Geográfica (país,
provincia/estado, localidad, entre otros), etc., lo cual permite analizar, por
ejemplo, las Ventas Totales por Provincia y por Mes.
Elementos de Dimensión
Atributos de Dimensión
8
Miembro de Dimensión
Los hechos más útiles son numéricos y aditivos, como por ejemplo, las
ventas en pesos. La aditividad es crucial, porque las aplicaciones de BI rara
vez consultan una sola fila de la tabla de hechos; por lo general, consultan
miles de filas para traer un valor sumarizado. Sin embargo, hay hechos no
aditivos, como el precio unitario, que nunca pueden ser sumados; en
cambio, se podrá hacer cuentas o promedios.
Por otro lado, si no hubo ventas para un producto, no debe incluirse una
fila con ceros en la tabla de hechos. No obstante, las tablas de hechos
consumen el 90% de espacio de una base de datos multidimensional.
Dichas tablas tienden a ser profundas en cantidad de filas, pero
generalmente de pocas columnas.
9
Todas las tablas de hechos tienen 2 o más claves foráneas (FK) que las
conectan con las tablas de dimensión. La tabla de hechos generalmente
tiene su propia clave primaria, compuesta por un subconjunto de las FK de
las dimensiones. Toda tabla que tenga clave compuesta es una tabla de
hechos, dado que expresan relaciones muchos a muchos; las restantes son
tablas de dimensión.
Por ejemplo, podemos tener una tabla de Hechos con los siguientes
campos:
10
Tablas de Dimensión para Contexto Descriptivo
11
Imagen 2: Tabla de Dimensión Tiempo
12
Hechos y Dimensiones relacionados en un Esquema
Estrella
13
A continuación, podemos ver cómo nos quedó el ejemplo con el esquema
Estrella:
Para poder obtener las Ventas Totales es necesario multiplicar los campos
CANTIDAD y PRECIO_UNITARIO.
14
3.4 Esquema de Implementación
Esquemas Estrella
Según Josep Lluís Cano (2007, p. 75), “para la construcción del esquema
estrella debemos distinguir entre las tablas de hechos (aquello que
queremos medir o analizar) y las tablas de dimensiones (cómo lo
queremos medir)”.
Las características del esquema estrella son:
15
Esquemas Copos de Nieve
16
Fuente: Elaboración propia
Esquemas Constelación
Multidimensionalidad
Según Josep Lluís Cano (2007, p. 84), “al poder utilizar las distintas
dimensiones a la vez estamos utilizando la funcionalidad de la
multidimensionalidad. La multidimensionalidad nos permite analizar la
información por distintas dimensiones a la vez”.
Así, para el ejemplo anterior, podemos analizar las Ventas Totales por
varias dimensiones en simultáneo, es decir, ver la evolución de las ventas
por cada una de las Provincias de Argentina, para el 3º Trimestre de 2012 y
la categoría de Productos de Alta Gama.
17
3.5 Conceptos relacionados
Los cubos OLAP también proveen funciones analíticas más robustas que las
disponibles en el lenguaje SQL. La desventaja es que se paga un precio en
performance de carga, especialmente en grandes volúmenes de datos.
Aunque las capacidades de la tecnología OLAP están continuamente
mejorando, generalmente se recomienda que la información atómica y
detallada se cargue en un esquema estrella sobre un RDBMS. Los cubos
OLAP, de desarrollo opcional, luego se cargan a partir del esquema estrella
inicial.
18
Consideraciones sobre el Despliegue en Cubos OLAP
19
3.6 Mejoras de Performance
Indexación
Tablas Sumarizadas
Particionamiento
20
Business Intelligence In-Memory y Visualización por
Lógica Asociativa
Según uno de los productos líderes en este mercado, las claves para la
mejor performance de las aplicaciones de BI in-memory con lógica
asociativa están dados por los siguientes aspectos:
Tiene un motor de inferencia que mantiene las
asociaciones entre los datos automáticamente.
21
Comprime los datos hasta un 10% de su tamaño original
para optimizar la potencia de los procesadores.
Memoria flash.
22
Necesidad de analizar la información en tiempo real, dado que de
manera frecuente las aplicaciones de BI se usan para tomar
decisiones inmediatas a base de los perfiles históricos.
Otros aspectos.
Imagen 7: AQL
23
4. Administración del
Modelo
“Las herramientas OLAP permiten a los usuarios finales tratar la
información de forma multidimensional para explorarla desde
distintas perspectivas y períodos de tiempo.”
24
es que el usuario sólo recibe los hechos y las dimensiones en los
que está interesado y los analiza en forma local.
4.2 FASMI
De acuerdo con Josep Lluís Cano (2007, p. 126), “el OLAP Council sumarizó
las 12 reglas de Codd en lo que ellos llamaban el concepto FASMI y que los
productos OLAP deben cumplir”.
Fast
Analysis
Shared
Multidimensional
Information
25
4.3 Almacenamiento OLAP
ROLAP
MOLAP
HOLAP
26
4.4 Conceptos Avanzados
De acuerdo con Ralph Kimball (2013), las cuatro decisiones clave que se
toman durante el diseño de un modelo multidimensional incluyen los
siguientes pasos:
Declarar la granularidad
1. Procesos de Negocio
Los procesos de negocio son las actividades operativas realizadas por una
organización, como por ejemplo: tomar una orden o solicitud, procesar una
queja o reclamo, registrar estudiantes en un curso, y otros.
27
2. Granularidad
La granularidad atómica se refiere al nivel más bajo, en el cual los datos son
capturados por un proceso de negocio dado. Ralph Kimball (2013)
recomienda iniciar enfocándose en datos de granularidad atómica porque
permite resistir el surgimiento de consultas de usuario impredecibles.
Las tablas de dimensión contienen los atributos descriptivos usados por las
aplicaciones BI para filtrar y agrupar los hechos.
Las tablas de dimensión son algunas veces llamadas el ‘alma’ del Data
Warehouse porque contienen los puntos de entrada y etiquetas
descriptivas que le permiten a un sistema BI habilitar el análisis del
negocio.
28
4. Hechos para Medición
29
Hechos Aditivos, Semi-Aditivos y No Aditivos
Sin embargo, los NULL deben evitarse en las claves foráneas de las tablas
de hechos porque los mismos causarían automáticamente una violación de
la integridad referencial.
Hechos Ajustados
30
Si las definiciones de hechos separadas son consistentes, los hechos
ajustados deberían ser nombrados idénticamente; pero si son
incompatibles, deberían ser nombrados de manera diferente para alertar a
los usuarios y aplicaciones BI.
Estas tablas pueden ser o no densas porque las filas solo existen si las
mediciones toman lugar. Además, siempre contienen una clave foránea
por cada dimensión asociada, y opcionalmente contienen timestamps
precisos y claves de dimensiones degeneradas.
31
Tablas de Hechos de Snapshots de Acumulación
Además de las claves foráneas de fechas asociadas con cada paso crítico
del proceso, las Tablas de Hechos de Snapshots de Acumulación contienen
claves foráneas para otras dimensiones, y opcionalmente contienen
dimensiones degeneradas.
Las tablas de hechos sin hechos pueden también ser usadas para analizar
qué no sucedió. Estas consultas siempre tienen dos partes: una tabla sin
hechos que contiene todas las posibilidades de eventos que podrían
suceder y una tabla de actividades que contiene los eventos que
sucedieron. Cuando la actividad se extrae de la primera, el resultado es el
conjunto de eventos que no sucedió.
32
Tablas de Hechos Sumarizadas o Cubos OLAP
33
Técnicas Básicas para Tablas de Dimensión
Cada tabla de dimensión tiene una única columna PK. Esta clave primaria
está embebida como una FK en cualquier tabla de hechos asociada, donde
el contexto descriptivo de la fila de la dimensión es exactamente correcto
para esa fila de la Tabla de Hechos.
Una tabla de dimensión se diseña con una columna que sirve como única
PK; esta no puede ser la clave natural del sistema operacional porque
habrá múltiples filas de dimensión para esa clave natural cuando los
cambios se sigan en el tiempo. Además, las claves naturales para una
dimensión pueden ser creadas por más de un sistema fuente y pueden ser
incompatibles o pobremente administradas.
34
Claves Naturales, Durables y Sobrenaturales
Las claves naturales creadas por los sistemas operacionales están sujetas a
reglas de negocio fuera del control del sistema BI.
Cuando el Data Warehouse desea tener una única clave, debe crearse una
nueva clave durable, persistente y que no cambie. En ocasiones, se hace
referencia a la misma como ‘clave sobrenatural durable’. Generalmente
son secuencias numéricas iniciando en 1.
Drill Down
Dimensiones Degeneradas
35
Múltiples Jerarquías en Dimensiones
Los códigos operacionales con significado embebido dentro del valor del
código deberían ser fragmentados en cada parte del código,
expandiéndose en distintos atributos descriptivos de dimensión separados.
Los atributos de dimensiones con valor NULL resultan cuando una fila de
dimensión dada no ha sido totalmente llenada o cuando hay atributos que
no son aplicables a todas las filas de la dimensión. En ambos casos, Ralph
Kimball (2013) recomienda sustituir un string descriptivo, tal como por
ejemplo: Desconocido o No Aplica, en lugar del valor NULL.
36
Para facilitar el particionamiento, la PK de una dimensión Fecha o Tiempo
puede ser más significativa, como un entero que representa AAAAMMDD,
en lugar de dimensión Tiempo necesita una fila especial para representar
fechas desconocidas o a ser determinadas. Cuando se necesita mayor
precisión, un timestamp separado puede agregarse a la tabla de hechos. El
timestamp no es una FK relacionada con una tabla de dimensión, sino que
es una columna aislada.
Por otra parte, si los usuarios del negocio restringen o agrupan los datos en
base a atributos de la hora del día, debería agregarse una FK separada con
los rangos horarios a la tabla de hechos.
Dimensiones ‘Role-Playing’
Una única dimensión física puede ser referenciada múltiples veces en una
tabla de hechos, con cada referencia enlazada a un rol lógicamente distinto
para la dimensión.
Por ejemplo, una tabla de hechos puede tener distintas fechas, cada una de
las cuales estará representada por una FK a la dimensión Tiempo.
Dimensiones Inútiles
37
Dimensiones Copos de Nieve
Dimensiones de Refuerzo
38
Bibliografía Lectura 3
www.uesiglo21.edu.ar
39
Módulo 4
Soluciones de BI
5. Herramientas y
Soluciones de BI
“Existen cuatro tipos de usuarios de una solución de Business
Intelligence (BI): Granjeros, Exploradores, Mineros y Turistas”.
Granjeros
Exploradores
Mineros
Turistas.
1
Granjeros
Las consultas tienden a ser cortas; dado que sabe lo que quiere, va
directamente a donde están los datos.
Exploradores
2
En el Corporate Information Factory, generalmente acceden al Data
Warehouse y al Exploration Warehouse.
Mineros
Opera en proyectos.
Turistas
3
5.2 Tipos de Soluciones
Por otra parte, de acuerdo con Josep Lluís Cano (2007), en base a la
clasificación de Wayne Eckerson y Cindi Howson (2005), podemos
identificar dos grandes tipos de usuarios:
Para cada uno de los cuales podemos también identificar qué tipo de
soluciones son las más apropiadas:
Los productores de información: Normalmente se trata del 20%
de los usuarios y utilizan herramientas desktop para crear
informes o modelos. […] se trata de estadísticos que utilizan
herramientas Data Mining o autores de informes que utilizan
herramientas de diseño o de programación para crear informes
específicos. Habitualmente los autores de informes son: técnicos
de sistemas de información no usuarios de negocio avanzados que
son capaces de entender la información y la informática. Los
usuarios avanzados pueden crear o utilizar informes, por lo que en
el gráfico están a medio camino entre los productores y los
consumidores de información. Usualmente utilizan hojas de
cálculo, herramientas de consulta y de informes para acceder y
analizar la información.
4
el acceso desde cualquier lugar y facilitar el uso y minimizarlos
costes de administración y mantenimiento.
5
6. Ciclo de Vida del
Business Intelligence
“El ciclo de vida de un proyecto de Business Intelligence abarca
desde la planificación del proyecto hasta el despliegue,
crecimiento y mantenimiento de la solución.”
6
A continuación, se presenta un diagrama del ciclo de vida en donde se aprecia cómo se interrelacionan las distintas etapas / tareas:
Definición del Alcance del proyecto (por ejemplo, iniciar con un sólo
proceso de negocio) y la justificación del mismo, lo cual está
relacionado con realizar una estimación de los beneficios y costos
asociados al proyecto.
- Usuarios Finales
- Arquitecto / Diseñador de BI
- Desarrollador de Aplicaciones de BI
- Project Manager
- Arquitecto Técnico
- Arquitecto de Datos
- Modelador de Datos
- Coordinador de Metadatos
Incluye:
9
Etapa de Diseño de la Arquitectura Técnica
Incluye:
10
Etapa de Modelado Multidimensional
11
Etapa de Especificación / Diseño de la Aplicación de
BI
Etapa de Despliegue
12
Etapas de Crecimiento y Mantenimiento
Soporte técnico
Soporte funcional
Capacitación
Nuevas funcionalidades.
13
Negocio debe contar con fuertes habilidades comunicacionales. Por otro
lado, ser respetado por los clientes/usuarios resulta un plus adicional,
teniendo en cuenta que dicho Analista estará representando al resto del
equipo del proyecto en cuanto a la definición de requerimientos.
14
Arquitecto de Datos/Modelador de
Datos/Administrador de Bases de Datos (DBA)
15
Coordinador de Metadatos
16
El Desarrollador de Aplicaciones de BI crea y mantiene las aplicaciones de
BI, generalmente usando software de Query & Reporting; además es
responsable de configurar la capa semántica de la herramienta de BI. Este
rol requiere de conocimientos en bases de datos y también habilidades en
programación, junto con una profunda comprensión del negocio y sus
requerimientos.
Desde luego, los roles que aquí mencionamos también pueden ser llevados
a cabo por las personas que conforman el Core Team.
17
Programador de Data Staging
Consultores Externos
18
7. Taller
“Escoger aquella herramienta de Business Intelligence que mejor
satisfaga las necesidades de los usuarios en cuanto a las
funcionalidades, con la mejor arquitectura y al mejor coste, no
es una tarea fácil”
Múltiples Alternativas
19
Es posible, por lo tanto, que una organización haya adquirido
inapropiadamente un software porque no ha destinado los
suficientes recursos en tiempo y dinero para seleccionar la
solución.
Según Josep Lluís Cano (2007, p. 165), “Con un proceso formal de selección
de software la probabilidad deseleccionar la mejor herramienta para la
organización se incrementa sustancialmente”.
Metodología de Jonathan Wu
1. Inicio del proyecto:
1.2. Equipo.
20
2.2. Identificar las mejores prácticas que apoyan a los
objetivos de negocio.
3.1. De negocio:
3.2. Funcionales:
3.3. Técnicos:
5.1. Demostraciones.
5.4. Negociación
21
Metodología de Wayne Eckerson y Cindi Howson
1. Deberíamos constituir el Comité de Selección de la herramienta
de Business Intelligence. Debería estar formado por todos los
stakeholders de los distintos departamentos, incluido el de
Sistemas de Información. En el Comité debería participar algún
directivo que actúe como sponsor del proyecto. Si tenemos
usuarios con experiencia deben participar en él. Para quesean
efectivos, los comités deben estar compuestos por pocos
miembros.
22
requerimientos a las capacidades de la herramienta de Business
Intelligence. Por ejemplo, es difícil que los usuarios digan:
“Queremos una herramienta de BI con una capa de metadata”. Lo
que probable mentedirán es que quieren crear sus propios
informes sin necesidad de conocer su lenguaje. Los criterios más
utilizados son viabilidad del vendedor, estrategia del vendedor,
funcionalidades (en consultas, en informes, en entrega de
información, integración con hojas de cálculo, cuadros de mando,
administración, arquitectura, coste, formación y soporte).
Deberemos priorizar cada criterio con un peso. Si se quieren
consultar ejemplos de listas de criterios, se pueden consultar en
www.BIScorecard.com.
23
pena si tenemos pocas alternativas, ya que si el número de
productos es muy elevado no es demasiado práctica.
24
Criterios de Selección de la Herramienta / Producto
de BI
- Resultado económico.
- Estrategia de ventas.
25
- Procesamiento en el servidor (o en cliente).
- Escalabilidad y rendimiento.
- Alta disponibilidad.
- Consultas ad hoc.
- Seleccionar de listas.
- Formatos de tablas.
- Tipos de gráficos.
- Control de impresión.
- Formato contextual.
26
- Capacidades de navegación.
- Formato WYSIWYG.
- Entrega de información:
o Integración en portales.
- Uso de particiones.
- Cálculos.
- Jerarquías alternativas.
- Análisis de atributos.
- Navegar a detalle.
- Tiempo de respuesta.
- Ranking.
27
- Alertas y semáforos.
- Formatos de impresión.
- Entornos de desarrollo.
- Control de cambios.
Los precios:
28
Criterios de Selección del Implementador de BI
Josep Lluís Cano (2007) propone también una serie de criterios que deben
tenerse en cuenta a la hora de seleccionar la empresa proveedora que
realizará la implementación de la solución de BI. Puntualmente, menciona
los siguientes aspectos:
Historia.
Cobertura geográfica.
Servicios ofertados.
Grado de confianza.
Especialización vertical.
29
Productos de BI
En la Nota Técnica 3 del Capítulo VI (2007, pp. 175-185), Josep Lluís Cano
hace una recopilación de distintos proveedores de productos de BI.
Es evidente que para el caso de las PyMEs muchas veces los costos pueden
resultar definitivamente prohibitivos; en tal caso no queda otra alternativa
por la cual optar que por una herramienta Free Open Source, o bien por
alguna opción comercial de relativo bajo costo, como por ejemplo, para la
visualización de los datos puede ser la planilla de cálculo Microsoft Excel.
En este sentido, Josep Lluís Cano (2007) muestra un ejemplo de acceso a
bases de datos OLAP con Excel (también en el mencionado capítulo VI, pp.
186-192).
“SAP: 22,1 %
Oracle: 14,9%
IBM: 12,4 %
SAS: 12,2%
Microsoft: 9,1%”
1
Sitio Web donde se pueden consultar los datos de mercado actualizados:
http://www.gartner.com/newsroom/id/2507915
30
7.2 Relevamiento del Negocio
Una vez decidida la plataforma tecnológica de soluciones de BI, el
relevamiento del negocio es fundamental para poder comprender los
requerimientos.
Entre los aspectos que debemos tener en cuenta podemos mencionar los
siguientes:
Otros aspectos.
Josep Lluís Cano (2007) hace, en el capítulo VII, una recorrida de distintos
casos de estudio con diferentes experiencias de implementación de
soluciones de BI.
31
7.4 Construcción procesos ETL
Precio unitario
Sucursal
Cliente.
32
Imagen 3: Modelo Multidimensional de Ejemplo de Concesionaria
33
7.6 Presentación
Así, por ejemplo, como puede verse en la imagen 4, ubicamos los valores
de la dimensión Tiempo en la parte superior de la pantalla y el resto de las
dimensiones en el margen izquierdo de la misma.
34
A continuación, se muestra un gráfico en el que se visualiza el indicador de
Cantidad de Unidades Vendidas, que lo definimos como un SUM del campo
FACT_VENTAS.CANTIDAD. Este gráfico de ejemplo se elaboró incluyendo la
dimensión Producto, de modo tal que podremos ver los autos vendidos por
cada una de las marcas (productos).
35
Imagen 6: Autos Vendidos por Marca por Sucursal
36
A continuación, queremos ver la evolución de las ventas usando el mismo
indicador, pero por tiempo. Para ello, agregamos otro gráfico, en este caso
de barras, para ver los autos vendidos por año, mes y día (es decir,
agregamos la dimensión Tiempo).
37
Ahora seleccionamos un año: 2012, con lo cual vemos las ventas para dicho
año. El gráfico nos muestra la evolución mes por mes (hicimos un drill-
down en la jerarquía de la dimensión Tiempo):
Imagen 10: Autos Vendidos por Día del Mes del Año
39
Bibliografía Lectura 4
www.uesiglo21.edu.ar
40