Análisis de la Información y

la Decisión
Introducción a la Inteligencia de Negocios
 Inteligencia de Negocios
2

 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
 Propósito de Inteligencia de Negocios
3

 El propósito de BI es convertir el volumen de datos en

valor de negocio a través de herramientas analíticas.
Decisión Valor
Conocimiento
Información
Datos
Volumen

 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
 Componentes de BI
4

Fuentes de Datos Data Warehouse

BI
Herramientas Procesos de
de Explotación Extracción,
de Datos Transformación
y Carga
 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.
 Por qué OLTP no es adecuado para
6
reportes analíticos
OLTP Reportes Analíticos

Información para soportar el servicio Información histórica para analizar.

diario.

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
 BI: un ejemplo
7

 Ticket de venta en supermercado

 ¿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.
 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?
 Fases del proceso de BI
10
 Evolución de los Sistemas de
15
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.
 Evolución de los Sistemas de
16
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.
 Evolución de los Sistemas de
17
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.
 Evolución de los Sistemas de
18
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).
 Proceso de extracción de datos
19

 Los usuarios finales descargan la información desde

los sistemas operacionales.
 Los usuarios son los propietarios de los datos

Sistemas Extracts Usuarios

Operacionales finales
 Problemas de gestión debido a los
20
programas de extracts de datos.

Sistemas Extracts Usuarios

Operacionales Finales

Explosión de Extracts
21 Data Warehouse
 Definición de Data Warehouse
22

 “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
 Propiedades de Data Warehouse
23

Orientado a Integrado
un tema

Data
Warehouse

Variante en
Histórico
el tiempo
 DW: Orientado a un tema
24

 Los datos son categorizados por entidad de

negocio más que por aplicación.
Aplicación OLTP Tema Data Warehouse

Acciones

Fondos

Seguros

Tarjetas

Prestamos Información financiera

del Cliente
 DW: Integrado
25

 Los datos de un sujeto determinado son definidos y

almacenados una única vez.

Cuentas

Tarjetas

Prestamos
Cliente

Aplicaciones OLTP Data Warehouse

 DW: Variante en el tiempo
26

 Los datos son almacenados en una serie de fotos,

cada una representando un período de tiempo.

Data
Warehouse
 DW: Histórico (no volátil)
27

 Los datos en un data warehouse no son modificados

o eliminados.
 Evolución de un DW
28

Bases OLTP Base Data Warehouse

Carga Inicial

Refresh

Refresh

Purga o
Refresh Archivo
 Data Warehouse vs. OLTP
29

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

 Data Warehouse vs. OLTP
30
Consultas
OLTP
Cuál es la dirección del cliente?
Qué saldo tiene el cliente?
Qué productos de una orden no fueron
entregados?
Aceptó un cliente una promoción?
Data Warehouse - OLAP
Cuál es el producto más rentable de una
región?
Cuáles es el tipo de cliente que mayor
ganancia deja a la compañía?
Cuáles serán los productos más vendidos
el próximo trimestre?
Cuáles clientes aceptaran la promoción de
marketing?
 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
 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
 Sistemas OLAP
33

 Sistemas especialmente diseñados para el análisis

de la información en apoyo a la toma de decisiones
 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
 Curva de Uso
35

 En los sistemas operaciones es predecible

 En el Data Warehouse:
 Variable

 Aleatorio
 Expectativas de los usuarios
36

 Controlar las expectativas

 Definir objetivos alcanzables para respuesta a las
consultas
 Definir SLAs
 Entrenar
 El aumento del uso es exponencial
 Data Warehouse Empresarial
37

 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
 Data Warehouse vs. Data Mart
38

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

 Data Marts dependientes
39

Data Marts
Sistemas
Operacionales

Archivos Data
Datos Warehouse Marketing
Planos
Heredados

Datos Ventas
Marketing
Operaciones
Ventas
Finanzas
RRHH

Datos Datos Finanzas

Externos Externos
 Data Marts independientes
40

Sistemas
Operacionales

Archivos
Datos Planos
Heredados
Ventas o
Marketing

Datos
Operaciones

Datos Datos
Externos Externos
 Enfoques de desarrollo de un DW
41

 Enfoque “bing bang”

 Enfoque incremental
 Top – Down
 Bottom - Up
 Enfoque bing bang
42

Analizar los requerimientos

de la organización

Construir el DW
organizacional

Reportes en subconjuntos
o almacenados en un DM
 Enfoque Top - Down
43

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
 Enfoque Bottom - Up
44

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
 Enfoque incremental para desarrollo
45

 Múltiples iteraciones
Incremento 1
 Implementaciones breves
 Validación en cada fase Estrategia

Definición

Análisis

Diseño

Iterativo Construcción

Producción
 Esquema de una solución BI
46

Sistemas Area Area Herramientas

Fuentes Staging Presentación Acceso

Heredados

Data
Warehouse
Externos
ODS

Operacional Data Marts

Metadata
 Arquitectura de un Data Warehouse
47
 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

 Arquitectura: Load
49

 Todas las tareas que se realizarán desde que se

toman los datos del OLTP hasta que se carguen al
DW.
 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.
 Arquitectura: Load
51

 Transformación:
 Codificación

 Medidas de atributos
 Arquitectura: Load
52

 Transformación:
 Convenciones de nombramiento

 Fuentes múltiples
 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.
 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.
 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.

56 Inmon vs. Kimball
 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
 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.
 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.
 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.
 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
 Data Warehouse vs. Data Mart
62

Data Warehouse Data Mart

Alcance • Independiente de la aplicación • Específicos de la aplicación
• Centralizado o corporativo • Descentralizados
• Planificado • Organizados pero no
planificados
Datos • Históricos, detallados, • Alguna historia, detallados,
sumarizados sumarizados.
• Algunas tablas desnormalizadas • Alta densrmalización
Sujeto • Múltiples • Uno o pocos
Origen • Múltiples fuentes de datos • Pocas fuentes de datos
• Flexible • Restrictivo
• Orientado al dato • Orientado al proyecto
• Larga vida • Corta vida
• Estructura individual compleja • Muchas estructuras simples
 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 Transacciones Historial del cliente
movidos
Departamental Enfocado Su fuente es el Clientes por región
atómico
Individual Ad hoc Su fuente es el Clientes con transacciones
atómico fraudulentas
 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
 Data Warehouse: Inmon
65
 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
 Data Warehouse: Kimball
67
 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
 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
 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
 Comparación
71

Inmon Kimball
Aproximación Top-Down Bottom-Up
Arquitectura Modelo empresarial, con Modela los procesos de negocios en data
bases por departamento 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 Bajo Alto
usuarios
Plazo Continuo y discreto SCD
Método Timestamps Claves en dimensiones
 Comparación
72

Inmon Kimball
Audiencia IT Usuarios finales
Plazos Parte integral del CIF Transformar y retener los datos
operacionales
Objetivo Basado en modelos Basado en métodos simples de
técnicos y tecnologías adquisición de datos al usuario final, con
altamente probadas alta predisposición en la mejora de
performance.
 Cómo elegir?
73

Inmon Kimball
Naturaleza de los Estratégico Tácticos
requerimientos para la
toma de decisiones
Requerimientos de Integración empresarial Áreas de negocios individuales
integración de datos
Estructura de los datos Los tipos de datos que Métricas de negocios, medidas de
no son métricas pueden rendimiento y scorecard
ser aplicados para
múltiples necesidades
Escalabilidad El crecimiento y la Se pueden adaptar a los cambios
evolución de las rapidamente, siempre dentro de
necesidades son críticas un marco acotado
Persistencia de datos Cambio continuo en los Los origenes de datos son estables
origenes de datos
Recursos Gran cantidad de Equipos pequeños
especialistas
 Cómo elegir?
74

Inmon Kimball
Tiempo de entrega Se requieren gran Cuando existen necesidades
cantidad de tiempo urgentes de información
para la entrega
Costo Alto costo inicial, con Costo bajo inicial, y por cada ciclo
pequeños agregados en siguiente puede haber
ciclos futuros optimización en los costos
 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.