La inteligencia de negocios (BI) es el proceso de transformar datos en información y conocimiento para optimizar la toma de decisiones empresariales. A lo largo de su evolución desde la creación de bases de datos en 1969 hasta la consolidación de plataformas BI en los 2000s, se han desarrollado metodologías y herramientas que permiten el análisis de datos estructurados y no estructurados para identificar oportunidades de negocio. El data warehouse, como componente clave de BI, integra y organiza datos de diversas fuentes, facilitando el análisis multidimensional y la toma de decisiones informadas.

1. Business Intelligence

2. BI – ¿Qué es?
“Es la habilidad para transformar los datos en información, y la información en
conocimiento, de forma que se pueda optimizar el proceso de toma de decisiones
en los negocios.”
”Conjunto de procesos y herramientas orientadas al análisis de información con
el objetivo de hacer uso de datos reales en el proceso de toma de decisiones.”

3. BI – Surgimiento e historia
o 1969: Creación del concepto de base de datos (Codd).
o 1970’s: Desarrollo de las primeras bases de datos y las primeras aplicaciones
empresariales (SAP, JD Edwards, Siebel, PeopleSoft).
o 1980’s: Creación del concepto Datawarehouse (Ralph Kimball, Bill Inmon), y aparición
de los primeros sistemas de reporting.
o 1989: Popularización del término Business Intelligence (Howard Dresner).
o 1990’s: Business Intelligence 1.0. Proliferación de múltiples aplicaciones BI.
o 2000’s: Business Intelligence 2.0. Consolidación de las aplicaciones BI en unas pocas
plataformas Business Intelligence. Además de la información estructurada, se empieza
a considerar otro tipo de información y documentos no estructurados.

4. BI – Conceptos
o BI se considera como una conjunto de metodologías que mediante un procesamiento,
transforma los datos crudos en información valiosa para un objetivo comercial.
o La Inteligencia de Negocios puede supervisar una gran cantidad de datos para ayudar a
identificar y desarrollar nuevas oportunidades.
o El uso de nuevas oportunidades y la implementación de estrategias efectivas que puede
obtener una ventaja de mercado competitivo y la estabilidad a largo plazo.

5. BI – Conocimiento
DATOS: Mínima unidad
semántica, y se corresponden
con elementos primarios de
información que por sí solos son
irrelevantes como apoyo a la
toma de decisiones
INFORMACIÓN: Se puede definir como
un conjunto de datos procesados y que
tienen un significado (relevancia,
propósito y contexto), y que por lo tanto
son de utilidad para quién debe tomar
decisiones
CONOCIMIENTO: Se deriva de la
información. Para que la información se
convierta en conocimiento es necesario
realizar acciones tales como:
* Comparación con otros elementos
* Predicción de eventos / comportamiento
* Búsqueda de conexiones
“Habilidad para
transformar los datos
en información, y la
información en
conocimiento”

6. BI – Conocimiento
Es un valor…
Por ejemplo, “500 unidades”.
DATO
Tiene un contexto…
“Las ventas del mayo fueron de 500
unidades”
INFORMACION
Se obtiene mediante el análisis de la
información…
“Mayo es el mes más alto en ventas”
CONOCIMIENTO

7. BI – ¿Qué se puede hacer?

8. BI – Ejemplos

9. BI – KPI’s

10. BI – KPI’s
Con la ayuda de los KPI somos capaces de extraer aquella información
que realmente aporta un valor respecto a nuestro rendimiento.
El análisis diario, nos informa qué acciones son las que realmente
contribuyen una mejora en el rendimiento del negocio. Así que cada día
lo que hacemos es aprender a mejorar sobre las acciones que realmente
nos favorecen y mejoramos en nuestro rendimiento y conocimiento.

11. BI – ¿Por qué tener Business Intelligence?

12. BI – ¿Dónde se toman las decisiones?
Estratégico
Táctico
Operativo
C-Level: CEO, CTO, CFO
Directores
Gerentes de
Negocio
Analistas,
Operadores
Decisiones no estructuradas
con efecto a largo plazo
Efectos a mediano
plazo
Relacionadas a actividades
diarias con resultados
concretos

13. BI – Niveles de realización

14. BI – Reportes y Tableros

15. BI – Análisis Multidimensional

16. BI – Análisis Multidimensional

17. BI – OLTP vs OLAP
OLTP - On-Line Transactional Processing
• Bases de datos orientadas al procesamiento de transacciones.
• Una transacción genera un proceso atómico, puede involucrar operaciones de
inserción, modificación y borrado de datos.
• El proceso transaccional es típico de las bases de datos operacionales.
• El acceso a los datos está optimizado para tareas frecuentes de lectura y escritura.
• Los datos se estructuran según el nivel aplicación (programa de gestión a medida,
ERP o CRM implantado).
• Los formatos de los datos no son necesariamente uniformes en los diferentes
departamentos.

18. BI – OLTP vs OLAP
OLAP - On-Line Analytical Processing
• Bases de datos orientadas al procesamiento analítico. Este análisis suele implicar,
generalmente, la lectura de grandes cantidades de datos para llegar a extraer
algún tipo de información útil: tendencias de ventas, patrones de comportamiento
de los consumidores, elaboración de informes complejos… etc. Este sistema es
típico de los datamarts.
• Acceso a los datos de sólo lectura. La acción más común es la consulta.
• Los datos se estructuran según las áreas de negocio, y los formatos de los datos
están integrados de manera uniforme en toda la organización.
• El historial de datos es a largo plazo, normalmente de dos a cinco años.
• Las bases de datos OLAP se suelen alimentar de información procedente de los
sistemas operacionales existentes, mediante un proceso de extracción,
transformación y carga (ETL).

19. BI – OLTP vs OLAP
OLTP OLAP
Datos actuales - se actualizan Datos históricos
Almacena detalle Almacena detalle y agregados
Normalización Datos estáticos
Desnormalización

20. BI – Desnormalización
En diseño de base de datos, la normalización es un proceso que se implementa para organizar y garantizar la
integridad y estructura de los datos.
Su meta es eliminar datos redundantes o duplicados en la base de datos y asegurar que las dependencias
tengan sentido.
De esta manera, se hace más fácil el mantenimiento y la escalabilidad del sistema.
Sin embargo, hay momentos donde normalizar no es lo más apropiado, como por ejemplo: Datawarehouse.
El propósito es proveer la información al usuario de la manera más rápida posible, ya sea para informes,
estadísticas, métricas, etc.
En este modelo de base de datos, la mejor opción es desnormalizar.
Otro propósito para desnormalizar es tener datos históricos, en donde es necesario tener redundancia de
datos.

21. BI – Analítica
Se refiere a las habilidades, tecnologías, aplicaciones y prácticas para la investigación iterativa persistente de
los resultados de la empresa con el fin de obtener una perspectiva de análisis a nivel management.
La Inteligencia analítica se centra en el desarrollo de nuevos conocimientos y la comprensión del rendimiento
del negocio a partir de datos y métodos estadísticos.

22. BI – Analítica - Evolución

23. BI - Analítica
Qué está ocurriendo en tu negocio
Tipo de pregunta
Por qué está sucediendo, lo que
probablemente sucederá en el futuro (para la
investigación, predicción y de la prescripción)
Métodos
Reportes, métricas KPI (Indicador clave de
performance), monitoreo/Alertas (umbrales) Análisis
interactivo Tableros OLAP (cubos
multidimensionales), etc.
Modelado predictivo, minería de datos,
minería de texto, modelización Estadística
SAP, Cognos, Microstrategy,
SAS, Pentaho, Qlikview Herramientas R Enterprise, Tableau, Weka, Rapidminer
Usuarios
Usuario de Negocio
Científico de datos, analista de negocio,
Usuario de Negocio
Inteligencia de Negocios Inteligencia Analítica
Orientación
Catálogo de hechos del pasado Se ocupa de presente para predecir el futuro

24. DATAWAREHOUSE

25. Datawarehouse
Con el objetivo de poder acceder a la inteligencia de negocios, primero necesitamos abordar el concepto de
Datawarehouse, que es la base para el armado de reportes, indicadores, cubos, etc.
Un Datawarehouse es una base de datos corporativa que se caracteriza por integrar y depurar información
de una o más fuentes distintas, para luego procesarla permitiendo su análisis desde infinidad de
perspectivas y con grandes velocidades de respuesta.
La creación de un Datawarehouse representa en la mayoría de las ocasiones el primer paso, desde el punto
de vista técnico, para implantar una solución completa y fiable de Business Intelligence.

26. Datawarehouse - Características
• No volátil: el almacén de información de un Datawarehouse existe para ser leído, pero no modificado.
La información es por lo tanto permanente.
• Integrado: los datos almacenados en el Datawarehouse deben integrarse en una estructura consistente.
La información suele estructurarse también en distintos niveles de detalle.
• Temático: sólo los datos necesarios para el proceso de generación del conocimiento del negocio se
integran desde el entorno operacional. Los datos se organizan por temas para facilitar su acceso y
entendimiento por parte de los usuarios finales. Por ejemplo, todos los datos sobre clientes pueden ser
consolidados en una única tabla del Datawarehouse. De esta forma, las peticiones de información sobre
clientes serán más fáciles de responder dado que toda la información reside en el mismo lugar.
• Histórico: el tiempo es parte implícita de la información contenida en un Datawarehouse. la
información almacenada en el Datawarehouse sirve, entre otras cosas, para realizar análisis de
tendencias.

27. Datawarehouse - Objetivos
• Proporciona una herramienta para la toma de decisiones en cualquier área funcional, basándose en
información integrada y global del negocio.
• Facilita la aplicación de técnicas estadísticas de análisis y modelización para encontrar relaciones
ocultas entre los datos del almacén; obteniendo un valor añadido para el negocio de dicha información.
• Proporciona la capacidad de aprender de los datos del pasado y de predecir situaciones futuras en
diversos escenarios.

28. Datawarehouse – Ingesta (ETL)
• El Datawahouse se alimenta mediante procesos ETL (extracción, transformación y carga), desde
diferentes fuentes heterogéneas,
• El proceso ETL se comunica con los sistemas Transaccionales, archivos propios de los usuarios, bases de
datos internas/externas, aplicaciones para extraer los datos y cargarlos.
• Extracción: obtención de información de las distintas fuentes tanto internas como externas.
• Transformación: filtrado, limpieza, depuración, homogeneización y agrupación de la información.
• Carga: organización y carga de los datos y los metadatos en la base de datos.
Antes de realizar la carga final, se pueden reformatear, limpiar, filtrar y posteriormente cargarlos en otra
base de datos, en archivos de texto, o en diferentes tecnologías.
Los procesos ETL forma parte de la Inteligencia Empresarial (Business Intelligence).

29. Datawarehouse – ETL - Procedimiento
El procedimiento de extracción consiste en alojar la extracción de datos en un área Staging, con el objetivo
de bajar los datos de forma cruda y sin transformaciones para lograr una óptima performance.
El área Staging es un área volátil, que sólo aloja la extracción en curso (se borra en cada ejecución) y no
almacena historia.
El siguiente paso (puede ser opcional) consiste en realizar las transformaciones y formateos
correspondientes y almacenar la historia de las extracciones en el área ODS (Operational Data Store).
Por último el área DW (también DS, EDW) es el área donde se alimenta a los modelos/cubos/datamarts,
puede contener toda la historia o sólo un rango específico para reportes (dado que se puede regenerar
partiendo del área ODS).

30. Datawarehouse – Arquitectura

31. Datawarehouse – Ejemplo
Buzón de carga
de los archivos
Sistema
Fuente 1
Institución A
Sistema
Fuente 2
Sistema
Fuente 3
Creación
del archivo .csv
Sistema
Fuente 1
Institución B
Creación
del archivo .csv
Sistema
Fuente 2
Tabla Stage
Institución A
Tabla Stage
Institución B
ETL
Data Warehouse
Reportes
Data Mining
Cubos OLAP
Indicadores
Datos
Estructurados
Institución n
Sistema Fuente n
Procesamiento / Validación
de los archivos
Tabla Stage
Institución n
Datos No
Estructurados

32. Datawarehouse – Enfoques
Bill Inmon
Ralph Kimball
Enfoques
El concepto de Datawarehouse (DW) llegó de la mano de Bill Inmon y Ralph Kimball. Ambos pensaron en un único
repositorio de información para poder integrar y explotar información de diversos sistemas fuentes. Pero, más allá
de esta generalización conceptual, cada uno decidió hacerlo a su manera. Entonces, veamos qué es lo que
propone cada uno de ellos

33. Datawarehouse – Enfoques - Kimball
Ralph Kimball
Kimball sugiere utilizar una metodología Bottom-Up, donde la información se extrae de los sistemas
transaccionales para ser cargada en diferentes DataMarts cada uno de los cuales son independientes, están
modelados en forma dimensional y tienen foco por proceso.

34. Datawarehouse – Enfoques - Inmon
En este caso el Datawarehouse no está modelado dimensionalmente, sino que está en tercera forma normal
(3NF). Así, el creador de este modelo entiende que esta forma es mucho más rica y adaptable que el modelo de
Kimball. Una vez que tenemos el Datawarehouse generado de esta manera, se pueden crear los Datamarts para
las áreas de negocio que necesitemos, y además lo podríamos utilizar para cualquier otro tipo de sistema
decisional como por ejemplo sistemas expertos, o minería de datos.
Bill Inmon

35. Datawarehouse – Enfoques
Bill Inmon Ralph Kimball

36. Datawarehouse vs DataMarts
▪ Datawarehouse: “…repositorio de datos integrado, que facilita el análisis de grandes
volúmenes de datos para la toma de decisiones”
▪ Datamart: es una partición o subconjunto del Datawarehouse:
▪ Acotados a un proceso de negocio.
▪ De interés para un grupo de usurarios o área del negocio.
▪ Suelen tener alcance parecidos a los de un proyecto.

37. Datawarehouse – Modelado Dimensional
Vamos a introducir los conceptos del modelado dimensional:
• Dimensiones
• Hechos
• Atributos
• Elementos
• Métricas

38. Datawarehouse – Dimensiones
• Las dimensiones son los diferentes puntos de vista por los que queremos analizar la información.
• Las dimensiones incluyen los diferentes atributos que queremos analizar, que además se estructuran de
forma jerárquica, conforme a diferentes niveles de detalle.
• Las tablas de dimensiones se construyen incluyendo todos los atributos que la incluyen de una forma
desnormalizada, con una clave que identifica el mínimo nivel de detalle. Podemos distinguir varios tipos
de dimensiones:

39. Datawarehouse – Dimensiones
• Dimensiones Normales: Agrupan diferentes atributos que están relacionados por el ámbito al que se refieren (ej. todas las
características de un cliente, los diferentes componentes de la dimensión tiempo, etc).
• Dimensiones Causuales: Aquella que incluye atributos que pueden causar cambios en los procesos de negocio (por
ejemplo la dimensión promoción en el proceso de negocio de ventas).
• Dimensiones Heterogéneas: Dimensiones que agrupar conjuntos heterogéneos de atributos, que no están relacionados
entre si.
• Dimensiones Roll-Up: Es un subconjunto de otra, necesarias cuando tenemos tablas de hechos con diferente
granularidad.
• Dimensiones Junk: Dimensión que agrupa indicadores de baja cardinalidad como pueden ser flags o indicadores.
• Dimensiones Role-playing: Cuando una misma dimensión interviene en una tabla de hechos varias veces (por ejemplo,
la fecha en una tabla de hechos donde se registran varias fechas referidas a conceptos diferentes), es necesario reutilizar
la misma dimensión, no tiene sentido crear tantas dimensiones como usos se hagan de ella. La misma dimensión juega
un rol diferente según el sitio donde se utiliza.
• Dimensiones Degeneradas: Son dimensiones que no tienen ningún atributo y por tanto, no tienen una tabla especifica de
dimensión. Solo se incluye para ellas un identificador en la tabla de hechos, que identifica completamente a la dimensión
(por ejemplo, un pedido de ventas). Nos interesa tener identificada la transacción (para realizar data mining, por
ejemplo).
• Mini dimensiones: conjunto de atributos de una dimensión que se extraen la tabla de dimensión principal pues se suelen
analizar de forma diferente.

40. Datawarehouse – Dimensión tiempo
Debajo un ejemplo de la dimensión tiempo, totalmente desnormailizada/aplanada, para
poder tener el máximo detalle y poder utilizar jerarquía

41. Datawarehouse – Gestión de Dimensiones
Es necesario gestionar de una forma correcta los cambios que se producen en los atributos de las
dimensiones, que nos permitan realizar de una forma correcta el análisis histórico de los datos.
Para ello se introduce el concepto de Dimensión Lentamente Cambiante (SCD), estableciendo varios
métodos para su procesamiento (que tendrán que ser tenidos en cuenta en los procesos ETL).
SCD Tipo 1 - Sobreescritura: Cuando hay un cambio en los valores de un atributo, sobrescribimos el
valor antiguo con el nuevo sin registrar una historia. Esto significa perder toda la historia del dato, y
cuando hagamos un análisis veremos la información histórica desde el punto de vista actual.
proveedor_id proveedor_codigo proveedor_nombre proveedor_Territorio
12CMA Juan Pablo ARG
proveedor_id proveedor_codigo proveedor_nombre proveedor_Territorio
12CMA Juan Pablo LAT
Antes
Después

42. Datawarehouse – Gestión de Dimensiones
SCD Tipo 2 - Nueva fila: Cuando hay un cambio, creamos un nuevo registro en la tabla. El nuevo registro tiene
una nueva clave subrogada, de forma que una entidad de sistema operacional (por ejemplo, un cliente), puede
tener varios registros en la tabla de la dimensión según se van produciendo los cambios. Estamos gestionando
un versionado, que además puede incluir unas fechas para indicar los periodos de validez, numerador de
registros o un indicador de registro activo o no.
proveedor_id proveedor_codigo proveedor_nombre proveedor_Territorio fecha_desde fecha_hasta Activo
12 CMA Juan Pablo ARG 1/3/2014 2/12/2016
14 CMA Juan Pablo LAT 3/12/2016 x
13 CMI Jose PAR 21/10/2016 x

43. Datawarehouse – Gestión de Dimensiones
SCD Tipo 3 - Nueva columna: Cuando hay un cambio, nos guardamos el valor anterior en una columna
distinta, actualizando el campo con el nuevo valor (para cada campo, tendremos una tupla valor anterior,
valor actual). Solo nos vamos a guardar, por tanto, los dos últimos valores.
Cada una de las dimensiones tiene una clave que identifica cada uno de los registros que la conforman. Para
definir esta clave, podemos utilizar los mismos valores que se utilizan en los sistemas operacionales (con lo que
nos estamos limitando a la forma en que estan definidos alli y seguramente estableciendo limitaciones para el
futuro) o bien utilizar las llamadas Surrogated Keys (Claves Subrogadas).
proveedor_id proveedor_codigo proveedor_nombre proveedor_Territorio_actual proveedor_Territorio_previo
12CMA Juan Pablo LAT
14CMA Juan Pablo ARG LAT

44. Datawarehouse – Códigos Subrogados
Corresponden a los identificadores que creamos en el Datawarehouse, suelen ser secuencias únicas para cada
dimensión, que nos va a permitir optimizar las consultas sql y evitar las posibles limitaciones de la definición de
las claves existentes.
Al existir esta clave, desvinculamos totalmente el identificador con respecto al sistema origen.
Estas claves tienen que ser numéricas, enteras, de tal forma de que el acceso a las tablas sea el más
performante.
proveedor
proveedor_id proveedor_desc
123 SIDERCA
89 METALH
65 FFT-G
localidad
localidad_id localidad_desc
8 Campana
4 Mendoza
medio_pago_id
medio_pago_id medio_pago_desc
1 Efectivo
2 Cta Cte

45. Datawarehouse – Códigos Subrogados
ht_compras
compra_id proveedor_id fecha localidad_id medio_pago_id producto_id cantidad entrega_dias
1129 123 20170421 8 2 889 4 10
1230 89 20170507 4 1 900 2 8
1231 65 20171012 4 2 855 10 6
compra_id proveedor fecha localidad medio_pago producto_id cantidad entrega_dias
1129 SIDERCA 20170421 Campana Cta Cte Planchuela Hierro 4 10
1230 METALH 20170507 Mendoza Efectivo Cemento 2 8
1231 FFT-G 20171012 Mendoza Cta Cte Arena 10 6
Extracción mediante ETL
Transformación – modelo dimensional

46. Datawarehouse – Hechos (fact)
• Las tablas de hechos incluyen los indicadores asociados a un proceso de negocio en concreto,
además de las claves de las dimensiones que intervienen en dicho proceso, en el mínimo nivel de
granuralidad o detalle.
• Evento concreto y especifico del proceso de negocio, y de interés para la organización.
• Los hechos son los indicadores de negocio que dan sentido al análisis de las dimensiones

47. Datawarehouse – Hechos - Tipos
Consolidated Fact Tables: tablas de hechos construidas como la acumulación, en un nivel de granuralidad o
detalle diferente, de las tablas de hechos de transacciones.
Transaction Fact Tables: Representan eventos que suceden en un determinado espacio-tiempo. Se
caracterizan por permitir analizar los datos con el máximo detalle. Reflejan las transacciones relacionadas
con nuestros procesos de negocio (ventas, compras, inventario, contabilidad, etc).
Factless Fact Tables: Son tablas que no tienen medidas y representan la ocurrencia de un evento
determinado. Por ejemplo, la asistencia a un curso puede ser una tabla de hechos sin métricas asociadas.
Periodic Snapshot Fact Tables: Son tablas de hecho usadas para recoger información de forma periódica
a intervalos de tiempo regulares sobre un hecho. Nos permiten tomar una foto de la situación en un
momento determinado (por ejemplo al final del dia, de una semana o de un mes). Un ejemplo puede ser la
foto del stock de materiales al final de cada día.
Accumulating Snapshot Fact Table: representan el ciclo de vida completo de una actividad o proceso,
que tiene un principio y final. Suelen representar valores acumulados.

48. Datawarehouse – Atributo
▪ Generalmente del tipo texto (o pueden tratarse como tal).
▪ Valores cualitativos.
▪ Describe características de una entidad.
▪ Proveen contexto a los hechos.
▪ Proveen nivel de detalle a las métricas.

49. Datawarehouse – Elemento
Instancia o valor que puede tomar un atributo.
Nacionalidad (Atributo)
•Argentina (Elemento)
•Chileno (Elemento)
Estado Civil (Atributo)
•Soltero (Elemento)
•Casado (Elemento)
•Viudo (Elemento)
•Divorciado (Elemento)
Fecha de Nacimiento (Atributo)
•2/3/85 (Elemento)
•3/3/85 (Elemento)
…
Nombre de Producto (Atributo)
•Televisor (Elemento)
•Buzo (Elemento)
•Campera (Elemento)
•Notebook (Elemento)

50. Datawarehouse – Métricas
Métricas: Son los valores que recogen el proceso de una actividad o los resultados de la misma. Esto
medidas proceden del resultado de la actividad de negocio.
• Métricas de realización de actividad: Miden la realización de un actividad. Por ejemplo, la participación
de una persona en un evento.
• Métricas de resultado de una actividad: Recogen los resultados de una actividad. Por ejemplo, la
cantidad de unidades vendidas.

51. Datawarehouse – Métricas - Indicadores
Indicadores clave: Entendemos por este concepto, valores correspondientes que hay que alcanzar, y que
suponen el grado de asunción de los objetivos. Estas medidas proporcionar información sobre el
rendimiento de una actividad o sobre la consecución de una meta.
• Key Performance Indicator (KPI): Indicadores clave de rendimiento. Más allá de la eficacia, se definen
unos valores que nos explican en qué rango óptimo de rendimiento nos deberíamos situar al alcanzar los
objetivos. Son métricas del proceso.
• Key Goal Indicator (KGI): Indicadores de metas. Aquí podríamos incluir por ejemplo, el objetivo de
rentabilidad del proceso de negocio de ventas.
Las medidas se pueden clasificar igualmente como aditivas, semiaditivas y no aditivas según si se pueden
sumarizar a lo largo de todas las dimensiones, solo para algunas o para ninguna.

52. Datawarehouse – Modelado
El proceso de modelado dimensional consiste en elegir cual es el mejor modelo a
elegir al momento de plantear las estructuras de las dimensiones.
Existen 2 tipos de modelados para el armado de cubos:
• Estrella (star schema)
• Copo de nieve (snowflaked)

53. Datawarehouse – Modelado

54. Datawarehouse – Proceso de modelado
El proceso consiste en cuatro pasos:
1. Elegir el proceso de negocio: Consiste en elegir el área a modelar. Es una decisión de la dirección, y
depende fundamentalmente del análisis de requerimientos y de los temas analíticos que se desean
explorar.
2. Establecer el nivel de granularidad: La granularidad significa especificar el nivel de detalle. La elección de
la granularidad depende de los requerimientos del negocio y lo que es posible a partir de los datos
actuales. La sugerencia general es comenzar a diseñar el Datawarehouse al mayor nivel de detalle
posible, ya que se podrían realizar agrupamientos posteriores, al nivel deseado.
3. Elegir las dimensiones: Las dimensiones surgen naturalmente de las discusiones del equipo, y facilitadas
por la elección del nivel de granularidad. Las tablas de dimensiones tienen un conjunto de atributos
(generalmente textuales) que brindan una perspectiva o forma de análisis sobre una medida en una tabla
hechos. Una forma de identificar las tablas de dimensiones es que sus atributos son posibles candidatos
para ser encabezado en los informes, tablas pivot, cubos, o cualquier forma de visualización,
unidimensional o multidimensional.

55. Datawarehouse – Proceso de modelado
4. Identificar medidas y las tablas de hechos: Este paso consiste en identificar las medidas que surgen de
los procesos de negocios. Una medida es un atributo (campo) de una tabla que se desea analizar, sumando o
agrupando sus datos y usando los criterios de corte conocidos como dimensiones.
Las medidas habitualmente se vinculan con el nivel de granularidad. Un registro contiene una medida
expresada en números, como ser cantidad, tiempo, dinero, etc., sobre la cual se desea realizar una operación
de agregación (promedio, conteo, suma, etc.) en función de una o más dimensiones. La granularidad, en este
punto, es el nivel de detalle que posee cada registro de una tabla de hechos.

56. Gracias!!!