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

7. BI: un ejemplo
7
 Ticket de venta en supermercado

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?

10. Fases del proceso de BI
10

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

17. Data Warehouse21

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

43. Arquitectura de un Data Warehouse
47

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.

47. Arquitectura: Load
51
 Transformación:
 Codificación
 Medidas de atributos

48. Arquitectura: Load
52
 Transformación:
 Convenciones de nombramiento
 Fuentes múltiples

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.

52. Inmon vs. Kimball56

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

61. Data Warehouse: Inmon
65

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

63. Data Warehouse: Kimball
67

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.