El documento describe los conceptos clave de Business Intelligence (BI) y Data Warehousing. Explica que el software BI permite a los usuarios obtener información corporativa de manera más fácil sin necesidad de conocer las fuentes de datos. También describe los componentes clave de un sistema de BI como los almacenes de datos, herramientas de extracción y consulta, y herramientas de modelización. Finalmente, explica los conceptos de Data Marts y Data Warehouses y cómo forman la base para que las empresas utilicen herramientas de BI.

1. Datawarehousing

2. B.I. : Business Intelligence
 Software que le posibilita a los usuarios la obtención de
informaciones corporativas mas fácilmente.
 El software BI debe permitir que sean derivadas las
transacciones y sumarios que el usuario necesite, sin
que se precise conocer cuales son las fuentes de esos
datos

3. B.I.: Business Intelligence

4. B. I. : Business Intelligence

5. B.I.: Recursos y herramientas
 Fuentes de datos : warehouses, data marts, etc
 Herramientas de administración de datos
 Herramientas de extracción y consulta
 Herramientas de modelización (Data Mining)

6. Datamining (Minería de datos)
 El datamining (minería de datos), es el conjunto de
técnicas y tecnologías que permiten explorar grandes
bases de datos, de manera automática o
semiautomática, con el objetivo de encontrar patrones
repetitivos, tendencias o reglas que expliquen el
comportamiento de los datos en un determinado
contexto.

7. Evolución:
Business Data to Business Information
Etapa Pregunta de Tecnología Proveedores Características
Negocio disponible
Data ¿Cuál fue el total Computadoras, IBM, NCR, Retrospectivo
Collection de ventas en cintas, discos etc Estático
(1960) Capital Federal y
GBA?
Data Access ¿Cuáles fueron RDBMS Oracle, Retrospectivo
(1980) las ventas por SQL Informix, Dinámico
sucursal en Sybase, etc
Capital Federal y
GBA?

8. Evolución:
Business Data to Business Information
Etapa Pregunta de Tecnología Proveedores Características
Negocio disponible
Data ¿Cuál fue el OLAP Pilot, Retrospectivo
Navigation total de DW Discoverer, Dinámico
(1990) ventas en Arbor, etc Niveles
Capital múltiples
Federal?
Drill down a
GBA
Data ¿Cómo Algoritmos Intelligent Prospectivo.
Mining evolucionarán avanzados Miner (IBM) Proactivo
(2000) las ventas en Multiprocesado SGI
el próximo res SAS, etc
año?

9. D.W. : Data Warehouse
 El objetivo de los DWs (almacenamiento de datos) es
almacenar los datos oriundos de los diversos sistemas
de información transaccionales en varios grados de
relaciones y sumarios, con el fin de facilitar y agilizar
los procesos de toma de decisión por diferentes niveles
gerenciales.

10. Orientados al usuario
 Los datos almacenados en el Data Warehouse proveen
información sobre un tema en particular en vez de
atender la operatoria de gestión de la compañía.

11. Integridad
 Esos datos deben ser tratados (identificados,
catalogados, recolectados, a disponibilidad,
transformados en informaciones) e integrados
permitiendo diversas formas de consultas, a través de
mecanismos amistosos de las herramientas de los
usuarios.

12. Variación en el tiempo
 Los DWs son normalmente actualizados en Batch
(actualizados una o algunas veces por día y no
conteniendo los datos de las transacciones de la
empresa de manera on-line) y pueden contener
grandes cantidades de datos.

13. Data Marts
 Los Datamarts(DMs) son DWs de alcance limitados,
dicho de otra manera son pequeños repositorios de
datos específicos para cada área de negocios o
departamentos de las empresas.

14. Data Warehouse
 Tanto los DWs como los DMs forman la base a partir
de la cual las empresas pueden utilizar las
herramientas BI –Business Intelligence -para la
extracción de informaciones gerenciales

15. Datos operacionales y Data
Warehouse
Datos Data Warehouse
operacionales
Contenido Valores elementales Datos sumarizados,
derivados
Organización Por aplicación Por tema
Estabilidad Dinámicos Estáticos hasta su
actualización

16. Datos operacionales y Data
Warehouse
Datos Data Warehouse
operacionales
Estructura Optimizada para Optimizada para
uso transaccional querys complejos
(NORMALIZADA) (DESNORMALIZADA)
Frecuencia de Alta Media y baja
acceso
Tipo de acceso Lectura / escritura Lectura
Actualización Sumarización
campo por campo

17. Datos operacionales y Data
Warehouse
Datos Data
operacionales Warehouse
Uso Predecible Ad hoc
Repetitivo Heurístico
Tiempo de Segundos Segundos a minutos
respuesta

18. Problemas con los datos
 Demasiados datos
 datos corruptos o con ruido
 datos redundantes (requieren factorización)
 datos irrelevantes
 excesiva cantidad de datos

19. Problemas con los datos
 Pocos datos
 atributos perdidos (missings)
 valores perdidos
 poca cantidad de datos
 Datos fracturados
 datos incompatibles
 múltiples fuentes de datos

20. ¿Cuántos datos son necesarios?
 ¿Cuántas filas?.
 ¿Cuántas columnas?.
 ¿Cuánta historia?
 Regla general : cuanto más datos, mejor
 En la práctica : condicionado a los recursos de
obtención y procesamiento.

21. Explotación del Datawarehouse
Report
Query,
Metadata EIS
Extracción,
clean up y carga
de datos
OLAP
DW
Data
Datos Mining
operacionales y
externos

22. Componentes del DW
 Fuentes de datos
 Procedimientos de Extracción
ETL
 Procedimientos de Transformación
 Procedimientos de carga (Loading)
 Soporte físico de los datos (DBMS)
 Herramientas de explotación : OLAP, reporting, Data
Mining, etc.

23. ETL
 Procedimientos (herramientas) destinados a obtener
los datos de las fuentes operacionales, limpiarlos,
convertirlos a los formatos de utilización y cargarlos en
el repositorio final.

24. Integridad de datos
 Los datos cumplen condiciones de integridad cuando
se ajustan a todos los stándares de valor y completitud.
 Todos los datos del DW son correctos
 El DW está completo (no existen más datos fuera de
él).

25. Integridad de datos
 La credibilidad del DW depende de la integridad de
sus datos
 El uso del DW depende de la percepción de los
usuarios y de la confianza que tengan en su contenido.
 De la integridad de datos depende el éxito del
proyecto.

26. Controles de Integridad
 Controles de Prevención : controlan la integridad
antes de cargar los datos en el DW.
 Controles de Detección : aseguran la exactitud y
completitud de la información una vez cargada en el
DW.

27. Data Process Flow
Data Process Flow Stages:
1.Data Migration
2.Cleansing
3.Transformation
4.Loading
5.Reconciliation

28. Etapas del proceso ETL
 Migración de datos
 Limpieza
 Transformación
(cálculos,agregados,sumarizaciones,desnormalización).
 Carga
 Conciliación - Validación

29. Migración
 Staging area : área de trabajo fuera del DW.
 El propósito de la migración es mover los datos de los
sistemas operacionales a las áreas de trabajo (staging
areas).
 NO se debe mover datos innecesarios (control
preventivo).

30. Limpieza (Data cleaning)
 Corregir, estandarizar y completar los datos
 Identificar datos redundantes
 Identificar valores atípicos (outliers)
 Identificar valores perdidos (missings)

31. Limpieza (actividades)
 Se debe uniformar las tablas de códigos de los sistemas
operacionales y simplificar esquemas de codificación
 Datos complejos, que representan varios atributos a la
vez, deben ser particionados.

32. Transformación
 Son procesos destinados a adaptar los datos al modelo lógico
del DW
 Se generan “reglas de transformación”.
 Las reglas deben validarse con los usuarios del DW

33. Transformación
 Generalmente el DW no contiene información de las
entidades que - en los sistemas operacionales - son
muy dinámicas y sufren frecuentes cambios.
 Si es necesario se utilizan Snapshots (fotos
instantáneas)

34. Transformación
 La des-normalización de los datos tiene como
propósito mejorar la performance.
 Otro propósito es el de reflejar relaciones estáticas,es
decir, que no cambian en una perspectiva histórica.
Por ejemplo: producto - precio vigente al momento de
facturación.

35. Transformación (sumarizaciones)
 Los datos sumarizados aceleran los tiempos de
análisis.
 Las sumarizaciones también ocultan complejidad
de los datos.
 Las sumarizaciones pueden incluir joins de
múltiples tablas
 Las sumarizaciones proveen múltiples vistas del
mismo conjunto de datos detallados
(dimensiones).

36. Estructura dimensional

37. Sumarizaciones (mantenimiento)
 El mantenimiento de las sumarizaciones es una
tarea crítica.
 El DW debe actualizarlas a medida que se cargan
nuevos datos.
 Debe existir alguna forma de navegar los datos
hasta el nivel de detalle (drill down).
 La definición de la granularidad es un problema
serio de diseño.

38. El nivel de granularidad:
problema de diseño del DW
 Cúal es la unidad de tratamiento (fila)
 ¿Qué es un cliente? Una cuenta, un individuo, una
familia
 ¿Cómo se sumariza la dimensión tiempo? Días,
semanas, meses …?

39. Carga (Loading)
 Dos aproximaciones:
 Full Refresh
 Incremental
 Aunque el Full Refresh parece más sólido desde el
punto de vista de la integridad de los datos, a medida
que crece el DW se vuelve cada vez más difícil de
realizar.

40. Controles de detección
 La validación de la carga del DW identifica problemas
en los datos no detectados en las etapas anteriores.
 Existen dos maneras de hacer la validación:
 completa (al final del proceso)
 por etapas a medida que se cargan los datos

41. Controles de detección
 Los controles incluyen reportes que comparan los
datos del DW con las fuentes operacionales a través de:
 totales de control
 número de registros cargados
 valores originales vs valores limpios (transformados),
etc.

42. Herramientas ETL
 Pueden ser procesos manuales diseñados a medida (querys
SQL, programas en Visual Basic, etc).
 Existen herramientas que proporcionan interfaces visuales
para definir joins, transformaciones, agregados, etc. sobre las
plataformas mas comunes.

43. Data Modelling Techniques for Data Warehousing

44. La pregunta central
¿De qué modo deben diseñarse las bases de datos que
conforman un Data Warehouse para soportar
eficientemente los requerimientos de los usuarios?

45. ¿Por qué es importante?
 Visualización del universo del negocio
 Modelo de abstracción de las “preguntas” que los
usuarios necesitan responder
 Diseño del plan de implantación del Data Warehouse

46. Dos técnicas
Modelo E-R Modelo dimensional
 Entidades  Hechos
 Atributos  Dimensiones
 Relaciones  Medidas

47. Modelo E-R

48. Modelo dimensional: HECHOS
 Hechos : colección de items de datos y datos de
contexto. Cada hecho representa un item de negocio,
una transacción o un evento
 Los hechos se registran en las tablas CENTRALES del
DW

49. Modelo dimensional: DIMENSION
 Una dimensión es una colección de miembros o
unidades o individuos del mismo tipo
 Cada punto de entrada de la tabla de HECHOS está
conectado a una DIMENSION
 Determinan el contexto de los HECHOS

50. Modelo dimensional:
DIMENSIONES
 Se utilizan como parámetros para los análisis OLAP
 Dimensiones habituales son:
 Tiempo
 Geografía
 Cliente
 Vendedor

51. Modelo dimensional:
DIMENSIONES - Miembros
Dimensión Miembro
Tiempo Meses, Trimestre, Años
Geografía País, Región, Ciudad
Cliente Id Cliente
Vendedor Id Vendedor

52. Modelo dimensional
DIMENSIONES - Jerarquía

53. Modelo dimensional
DIMENSIONES : Medidas
 Medida : es un atributo numérico de un hecho que
representa la performance o comportamiento del
negocio relativo a la dimensión
 Ejemplos:
 Ventas en $$
 Cantidad de productos
 Total de transacciones, etc.

54. Visualización de un modelo
dimensional

55. DW - OLAP
El modelo dimensional es ideal para soportar las 4
operaciones básicas de la tecnología OLAP:
 Relacionadas con la granularidad: ROLL UP - DRILL
DOWN
 Navegación por las dimensiones : SLICE - DICE

56. Drill Down - Roll Up

57. Slice and Dice

58. Modelos básicos dimensionales
STAR SNOWFLAKE

59. Star

60. SnowFlake

61. Datawarehousing process

62. Manage the Project
 Es un proceso cíclico e iterativo
 Refiere al manejo del PROYECTO, no al manejo del
Warehouse (ONGOING)

63. Define the project
 ¿Qué se necesita analizar y por qué?¿Cuál es el alcance
del proyecto?
 El contexto de definición y los alcances del proyecto
DEBEN permitir FLEXIBILIDAD. NO deben ser
demasiado específicos.

64. Requirements gathering
 Quién (personas, grupos, usuarios, etc)
 Qué (se quiere analizar)
 Por qué
 Cuándo (factores de oportunidad en el tiempo)
 Dónde (factores geográficos)
 Cómo definir las medidas

65. Source driven
 Los requerimientos se definen utilizando las fuentes
de datos operacionales.
 La mayor ventaja es que de antemano se conoce que
todos los datos podrán ser provistos ya que se sabe qué
está disponible

66. Source driven
 Se minimiza el tiempo de interacción con los usuarios
en las primeras etapas (se gana velocidad).
 El riesgo es producir un conjunto incorrecto de
requerimientos por la poca participación del usuario
 El usuario recibe “lo que tenemos”

67. User driven
 Los requerimientos se definen a partir de las
necesidades del usuario.
 Conduce a proyectos más acotados pero
probablemente más útiles
 Tiene como desventaja que al no limitarse el
pedido del usuario pueden solicitarse
objetivos imposibles

68. Relevamiento:
Source driven vs User driven

69. Source driven - User driven
 Data Mart : User driven
 Global Data Warehouse : Source driven para partir el
proyecto en áreas temáticas. Luego para cada área se
utiliza un enfoque User driven