Introducción al Business Intelligence, sistemas OLAP, Data Warehouse, Data Marts, comparación metodologías Inmon y Kimball.
Curso de Análisis de la Información y la Decisión, Facultad de Ingeniería, Universidad de Palermo.
1. Análisis de la Información y
la Decisión
Introducción a la Inteligencia de Negocios
2. Inteligencia de Negocios
El proceso, tecnologías y herramientas necesarias para
convertir datos en información, información en conocimiento
y conocimiento en planes que dirijan acciones de negocio
rentables. BI abarca Data Warehouse, herramientas
analíticas y gestión de conocimiento.
The Data Warehousing Institute
Business Intelligence suele definirse como la transformación
de datos de la compañía en conocimiento para obtener una
ventaja competitiva.
Gartner Group
2
3. Propósito de Inteligencia de Negocios
El propósito de BI es convertir el volumen de datos en
valor de negocio a través de herramientas analíticas.
El desafío principal de BI es reunir y presentar de
manera organizada la información referente a todos
los factores relevantes que conducen el negocio y
habilitar el acceso al conocimiento a los usuarios finales
de manera fácil y eficiente, con el efecto de maximizar
el éxito de una organización
Decisión
Conocimiento
Información
Datos
Volumen
Valor
3
4. Componentes de BI
4
Data Warehouse
Procesos de
Extracción,
Transformación
y Carga
Herramientas
de Explotación
de Datos
Fuentes de Datos
BI
5. OLTP
5
On Line Transaction Processing, se refiere a la clase
de sistemas que facilitan y gestionan aplicaciones
orientadas a transacciones.
Un cajero automático es un claro ejemplo de aplicación
de procesamiento de transacciones.
6. Por qué OLTP no es adecuado para
reportes analíticos
OLTP Reportes Analíticos
Información para soportar el servicio
diario.
Información histórica para analizar.
Datos almacenados a nivel de transacción. Es necesario integrar los datos.
Diseño de base de datos: Normalizado. Diseño de Base de Datos:
Desnormalizado, esquema de tipo estrella
6
8. ¿Quiénes necesitan BI?
8
Responsables de compras, para ver qué artículos se están vendiendo
más y cuáles son sus tendencias de venta.
Responsables de ventas, para ver qué productos tienen mayor rotación
para situarlos en las zonas preferenciales.
Responsables de la negociación con las entidades financieras, que
conocen cuáles son los flujos de efectivo, tarjetas de crédito o débito.
Responsables de marketing, para ver la efectividad de las promociones.
Responsables de RR. HH., para asignar los turnos correctamente en
función de la afluencia de clientes y el calendario.
En resumen, todas aquellas personas de una organización que
tengan que tomar decisiones. Dependiendo de qué preguntas
necesiten responder se establecerá el modelo de BI necesario.
9. Preguntas que resuelve BI
9
Quiénes son los mejores clientes?
Cómo minimizar costos y mejorar las prestaciones?
Cuál será el pronóstico de ventas del próximo mes?
En qué zonas conviene realizar campañas de
marketing?
Cuál es el día de la semana con mayor cantidad de
ventas?
11. Evolución de los Sistemas de
Soporte a las Decisiones
Master Files: Programas COBOL y
reportes simples, redundancia y
desincronización.
Direct Access Storage Device y
aparición de las bases de datos
como fuente principal de los
programas.
15
12. Evolución de los Sistemas de
Soporte a las Decisiones
Sistemas OLTP de alta
performance sin escalabilidad ni
GUI.
Aparición de las PCs y redes de
PC (files server y print server) ,
lenguajes de 4G y primeros
MIS/DSS (Management
Information Systems y Decision
Support Systems).
Programas extracts que a partir
de parámetros buscan y extraen
solo la información necesaria.
16
13. Evolución de los Sistemas de
Soporte a las Decisiones
Comienzan a realizarse muchos
extracts de archivos maestros y
extracts de extracts, con esto la
arquitectura comienza a evolucionar
de manera compleja y existe
diferencia de información entre los
distintos departamentos que utilizan
los sistemas. Problemas frecuentes:
• No existe una base de datos en
el tiempo.
• Distintos algoritmos por datos.
• Niveles de extracción.
• Problemas de datos externos.
• Falta de fuente común de datos
desde el inicio.
17
14. Evolución de los Sistemas de
Soporte a las Decisiones
A partir de los 90s, aparecen los
sistemas Cliente – Servidor
(aplicaciones centralizadas y acceso
a bases de datos heterogéneas con
ODBC).
18
15. Proceso de extracción de datos
Los usuarios finales descargan la información desde
los sistemas operacionales.
Los usuarios son los propietarios de los datos
Usuarios
finales
Sistemas
Operacionales
Extracts
19
16. Problemas de gestión debido a los
programas de extracts de datos.
ExtractsSistemas
Operacionales
Usuarios
Finales
Explosión de Extracts
20
18. Definición de Data Warehouse
“Data Warehouse es un conjunto de datos
integrados, históricos, variantes en el tiempo y
unidos alrededor de un tema específico, que es
usado por la gerencia para la toma de decisiones”
— W. H. Inmon
22
19. Propiedades de Data Warehouse
Integrado
Histórico
Variante en
el tiempo
Orientado a
un tema
Data
Warehouse
23
20. DW: Orientado a un tema
Los datos son categorizados por entidad de
negocio más que por aplicación.
Aplicación OLTP
Acciones
Fondos
Seguros
Tarjetas
Prestamos
Tema Data Warehouse
Información financiera
del Cliente
24
21. DW: Integrado
Los datos de un sujeto determinado son definidos y
almacenados una única vez.
Data WarehouseAplicaciones OLTP
Cliente
Cuentas
Tarjetas
Prestamos
25
22. DW: Variante en el tiempo
Los datos son almacenados en una serie de fotos,
cada una representando un período de tiempo.
Data
Warehouse
26
23. DW: Histórico (no volátil)
Los datos en un data warehouse no son modificados
o eliminados.
27
24. Evolución de un DW
Bases OLTP Base Data Warehouse
Carga Inicial
Refresh
Refresh
Refresh
Purga o
Archivo
28
25. Data Warehouse vs. OLTP
Propiedad OLTP Data Warehouse
Tiempo de respuesta Mili segundos a segundos Segundos a Horas
Operaciones DML Solo lectura
Naturaleza de datos 30 – 60 días Fotos en el tiempo
Organización de datos Aplicación Tema, Tiempo
Tamaño Pequeño a grande Grande a muy grande
Fuentes de datos Operacional, internas Operacional, internas,
externas
Actividades Procesamiento Análisis
Usuarios Miles Cientos
29
26. Data Warehouse vs. OLTP
Consultas30
OLTP Data Warehouse - OLAP
Cuál es la dirección del cliente? Cuál es el producto más rentable de una
región?
Qué saldo tiene el cliente? Cuáles es el tipo de cliente que mayor
ganancia deja a la compañía?
Qué productos de una orden no fueron
entregados?
Cuáles serán los productos más vendidos
el próximo trimestre?
Aceptó un cliente una promoción? Cuáles clientes aceptaran la promoción de
marketing?
27. Características del DW
31
Plataforma de hardware aislada
Integra datos desde distintos sistemas fuentes
Sus datos se utilizan para la toma de decisiones
La información se encuentra desnormalizada
Es una combinación de hardware, software
especializado y datos
28. Necesidad de un DW
32
Aliviar la carga de servidores
Eliminar datos sucios
Mejora en el acceso a datos corporativos
Democratización en el acceso a los datos
Única verdad
Mejor relación con el cliente
29. Sistemas OLAP
33
Sistemas especialmente diseñados para el análisis
de la información en apoyo a la toma de decisiones
30. OLAP vs. Data Warehouse
34
Surgieron de forma independiente
OLAP hace énfasis en el proceso de satisfacción al
usuario final y de explotación de información
Data Warehouse hace hincapié en la obtención y
almacenamiento de los datos; procesos para
obtención de datos seguros, consistentes, integrados
y disponibles
Una solución robusta es la utilización de sistemas
OLAP explotando un Data Warehouse
31. Curva de Uso
En los sistemas operaciones es predecible
En el Data Warehouse:
Variable
Aleatorio
35
32. Expectativas de los usuarios
Controlar las expectativas
Definir objetivos alcanzables para respuesta a las
consultas
Definir SLAs
Entrenar
El aumento del uso es exponencial
36
33. Data Warehouse Empresarial
Implementaciones a gran escala
Alcanza la organización
Datos desde todas las áreas temáticas
Desarrollado incrementalmente
Fuente única de datos organizacional
Datos sincronizados a nivel organización
Punto único de distribución a data marts
independientes
37
34. Data Warehouse vs. Data Mart
Propiedad Data Warehouse Data Mart
Alcance Organización Departmento
Temas Múltiples Tema único, área funcional
Fuentes de datos Muchas Pocas
Tiempo de Implementación Meses a años Meses
38
35. Data Marts dependientes
Data
Warehouse
Data Marts
Archivos
Planos Marketing
Ventas
Finanzas
Marketing
Ventas
Finanzas
RRHH
Sistemas
Operacionales
Datos
Externos
Datos
Operaciones
Datos
Heredados
Datos
Externos
39
36. Data Marts independientes
Ventas o
Marketing
Archivos
Planos
Sistemas
Operacionales
Datos
Externos
Datos
Operaciones
Datos
Heredados
Datos
Externos
40
37. Enfoques de desarrollo de un DW
Enfoque “bing bang”
Enfoque incremental
Top – Down
Bottom - Up
41
38. Enfoque bing bang
Analizar los requerimientos
de la organización
Construir el DW
organizacional
Reportes en subconjuntos
o almacenados en un DM
42
39. Enfoque Top - Down
Analizar los requerimientos a nivel organización
Desarrollar un modelo de información conceptual
Identificar y priorizar las áreas de interés
Completar un modelo para el área seleccionada
Mapa a datos disponibles
Ejecutar un análisis de fuentes de información
Implementar la arquitectura de base y establecer la
metadata y procesos de extracción y carga para
el área de interés inicial
Crear y poblar el área de interés inicial dentro del
Data Warehouse
43
40. Enfoque Bottom - Up
Definir el alcance y cobertura del DW y analizar
los sistemas fuentes dentro del alcance
Definir el incremento inicial basado en presiones
políticas, asumiendo beneficios de negocio
y volumen de datos
Implementar la arquitectura de base y establecer la
metadata y procesos de extracción
y carga para el área de interés inicial
Crear y poblar el área de interés inicial dentro del
Data Warehouse
44
41. Enfoque incremental para desarrollo
Múltiples iteraciones
Implementaciones breves
Validación en cada fase Estrategia
Definición
Análisis
Diseño
Construcción
Producción
Incremento 1
Iterativo
45
42. Esquema de una solución BI
46
Sistemas
Fuentes
Area
Staging
Area
Presentación
Herramientas
Acceso
ODS
Operacional
Externos
Heredados
Metadata
Data Marts
Data
Warehouse
44. Arquitectura: OLTP
48
OLTP representa toda la información transaccional
que genera la organización en su accionar diario,
además de las fuentes externas de las que puede
disponer:
Archivos de textos
Hipertextos
Hojas de cálculos
Informes
Bases de datos transacciones
45. Arquitectura: Load
49
Todas las tareas que se realizarán desde que se
toman los datos del OLTP hasta que se carguen al
DW.
46. Arquitectura: Load
50
Extracción:
Manipular los datos sin interrumpir ni paralizar el OLTP
ni el DW.
No depender de la disponibilidad del OLTP.
Almacenar y gestionar los metadatos que se generarán
en el proceso de ETL.
Facilitar la integración de las diversas fuentes.
49. Arquitectura: Load
53
Limpieza de datos: Eliminar datos erróneos o
inconsistentes.
Resolución de outliers: ignorarlos, eliminar la columna,
filtrar la columna, filtrar la fila erronea, reemplazar el
valor, discretizar.
Datos faltantes: ignorarlos, eliminar la columna, filtrar
la columna, filtrar la fila erronea, reemplazar el valor,
completar en el origen.
50. DW Manager
54
Tipicamente un DBMS con software y aplicaciones
dedicadas.
Almacena los datos de forma multidimensional, a
través de tablas de hechos y dimensiones.
Gestiona las diferentes estructuras que se constuyen
en el DW (cubos multidimensionales, business
models, etc).
Gestiona y mantiene la metadata.
51. DW Manager
55
Es responsable por:
Transformar e integrar los datos fuentes y de
almacenamiento intermedio en un modelo adecuado
para la toma de decisiones.
Realizar todas las funciones de definición y
manipulación del DW, para poder soportar todos los
procesos de gestión del mismo.
Ejecutar y definir las políticas de particionamiento.
Realizar copias de resguardo.
53. Historia
57
1990
Inmon publica “Building the Data Warehouse”
1996
Kimball publica “The Data Warehouse Toolkit”
2002
Inmon actualiza su libro y define la arquitectura para la
recolección de fuentes diversas de datos y establece el
envio desde una fuente centralizada a cada uno de los
data marts.
Top Down
Kimball define múltiples bases de datos llamadas Data
Marts que son organizadas por procesos de negocio, pero
que utilizan el bus de datos empresarial (dimensiones
conformadas).
Bottom Up
54. Definición
58
Inmon
Orientado al negocio, variante en el tiempo, no volátil
e integrado.
Kimball
Una copia de datos de las transacciones estructuradas,
especificamente para la consulta y análisis.
55. Qué están diciendo con esto?
59
Kimball en 1997 escribía:
El almacén de datos no es nada más que la unión de
todos los data marts.
Kimball indica una metodología bottom-up de
almacenamiento de datos, en la que los data marts
individuales, ofrecen vistas específicas de los datos de
la organización, que pueden ser creados y combinados
más adelante en un modelo más grande denominado
Data Warehouse.
56. Qué están diciendo con esto?
60
En 1998 Inmon respondía:
Puedes ver todos los pececitos en el océano, pero
todavía no hacen una ballena.
Esto indica el punto de vista opuesto, en donde el Data
Warehouse puede ser diseñado desde arriba hacía
abajo (top-down) para incluir todos los datos
corporativos. En esta metodología, los datas marts son
creados después que el Data Warehouse se ha creado.
57. Data Mart
61
Una representación específica, orientada al proceso o
departamento que me permite tener una vista de una
porción de la organización.
Se construyen para responder a usuarios de un área
específica.
Múltiples data marts para una organización
Un data mart es construido utilizando el modelo dimensional
Centrado en el foco del negocio
Generalmente pequeño, conformado por hechos y
dimensiones
58. Data Warehouse vs. Data Mart
62
Data Warehouse Data Mart
Alcance • Independiente de la aplicación
• Centralizado o corporativo
• Planificado
• Específicos de la aplicación
• Descentralizados
• Organizados pero no
planificados
Datos • Históricos, detallados,
sumarizados
• Algunas tablas desnormalizadas
• Alguna historia, detallados,
sumarizados.
• Alta densrmalización
Sujeto • Múltiples • Uno o pocos
Origen • Múltiples fuentes de datos • Pocas fuentes de datos
• Flexible
• Orientado al dato
• Larga vida
• Estructura individual compleja
• Restrictivo
• Orientado al proyecto
• Corta vida
• Muchas estructuras simples
59. Modelo de Inmon
63
Consiste en todas las bases de datos y sistemas de
una organización.
CIF – Corporate Information Factory –
El Data Warehouse es parte del CIF
Define distintos entornos de datos
Operacional Operaciones diarias Transacciones Rating de clientes
Atómico Datos manipulados y
movidos
Transacciones Historial del cliente
Departamental Enfocado Su fuente es el
atómico
Clientes por región
Individual Ad hoc Su fuente es el
atómico
Clientes con transacciones
fraudulentas
60. Modelado de Inmon
64
Tres niveles
DER
Definir entidades, atributos y relaciones.
Modelado de nivel intermedio (DIS)
Conjunto de datos por items
Conjunto de datos por departamento
Cuatro construcciones:
Datos primarios agrupados
Datos secundarios agrupados
Conectores
Tipos de datos
Modelo físico
Desnormalizado para mejorar la performance
62. Modelo de Kimball
66
Arquitectura de modelo dimensional
Tablas
Hechos
Dimensiones
No adhiere a la teoría de normalización
Accesible y entendible para el usuario
64. Bus de datos de Kimball
68
Los datos son movidos al área de Staging
A partir del área de Staging se crean los Data
Mart
Los data mart son basados en un único modelo.
La suma de todos los Data Mart constituyen un
Enterprise Data Warehouse
Las dimensiones conformadas son las que
relacionan a los data marts
65. Filosofía de Kimball
69
Hacer que los datos sean fácilmente accesibles
La información debe estar consistente
Facilmente adaptable a los cambios
Proteger la información
El fundamento del servicio que se presta es brindar
el mejor modelo para la toma de decisiones
66. Seleccionando la metodología
70
Kimball
Comenzar con data marts
Enfoque en entregas rápidas al usuario
Inmon
Enfoque hacía una visión macro empresarial
Foco en la organización
67. Comparación
71
Inmon Kimball
Aproximación Top-Down Bottom-Up
Arquitectura Modelo empresarial, con
bases por departamento
Modela los procesos de negocios en data
marts, se alcanza la organización con las
dimensiones conformadas.
Complejidad Complejo Simple
Orientación Al sujeto o dato Al proceso
Herramientas DER y DIS Modelo dimensional
Acceso a
usuarios
Bajo Alto
Plazo Continuo y discreto SCD
Método Timestamps Claves en dimensiones
68. Comparación
72
Inmon Kimball
Audiencia IT Usuarios finales
Plazos Parte integral del CIF Transformar y retener los datos
operacionales
Objetivo Basado en modelos
técnicos y tecnologías
altamente probadas
Basado en métodos simples de
adquisición de datos al usuario final, con
alta predisposición en la mejora de
performance.
69. Cómo elegir?
73
Inmon Kimball
Naturaleza de los
requerimientos para la
toma de decisiones
Estratégico Tácticos
Requerimientos de
integración de datos
Integración empresarial Áreas de negocios individuales
Estructura de los datos Los tipos de datos que
no son métricas pueden
ser aplicados para
múltiples necesidades
Métricas de negocios, medidas de
rendimiento y scorecard
Escalabilidad El crecimiento y la
evolución de las
necesidades son críticas
Se pueden adaptar a los cambios
rapidamente, siempre dentro de
un marco acotado
Persistencia de datos Cambio continuo en los
origenes de datos
Los origenes de datos son estables
Recursos Gran cantidad de
especialistas
Equipos pequeños
70. Cómo elegir?
74
Inmon Kimball
Tiempo de entrega Se requieren gran
cantidad de tiempo
para la entrega
Cuando existen necesidades
urgentes de información
Costo Alto costo inicial, con
pequeños agregados en
ciclos futuros
Costo bajo inicial, y por cada ciclo
siguiente puede haber
optimización en los costos
71. Resumen
75
Podemos resumir que el enfoque Inmon es mas
apropiado para sistemas complejos, donde además
queremos asegurar su perdurabilidad y consistencia
aunque cambien los procesos de negocio en la
organización.
Pero para pequeños proyectos, donde además
queremos asegurar la usabilidad de los usuarios con un
sistema fácil de entender y el rápido desarrollo de la
solución, el enfoque Kimball es más apropiado.