Metodologas Empleadas:

Hefesto, Raph Kimball:

Conceptos Generales
Arquitectura, Esquema
Operacional y las aplicaciones.
Ing. Aldo Vela. PMP, MBA

Enero 2015
1 /50

OLTP vs OLAP

2 /50

Origen de Datos

3 /50

Metodologa de Ralph Kimball

La metodologa de Kimball, llamada

Modelo
Dimensional
(Dimensional
Modeling), se basa en lo que se denomina
Ciclo de Vida Dimensional del Negocio
(Business Dimensional Lifecycle). Esta
metodologa es considerada una de las
tcnicas favoritas a la hora de construir un
Data Warehouse.

4 /50

Modelo Dimensional (1)

En el Modelo Dimensional se constituyen modelos de tablas y
relaciones con el propsito de optimizar la toma de decisiones, con
base en las consultas hechas en una base de datos relacional que
estn ligadas con la medicin o un conjunto de mediciones de los
resultados de los procesos de negocio.
El Modelo Dimensional es una tcnica de diseo lgico que tiene
como objetivo presentar los datos dentro de un marco de trabajo
estndar e intuitivo, para permitir su acceso con un alto
rendimiento. Cada Modelo Dimensional esta compuesta por una
tabla con una llave combinada, llamada tabla de hechos, y con un
conjunto de tablas ms pequeas llamadas tablas de dimensiones.
Los elementos de estas tablas se pueden definir de la siguiente
manera:
5 /50

Modelo Dimensional (2)

Hechos: es una coleccin de piezas de datos y datos de contexto.
Cada hecho representa una parte del negocio, una transaccin o
un evento.
Dimensiones: es una coleccin de miembros, unidades o
individuos del mismo tipo.
Medidas: son atributos numricos de un hecho que representan el
comportamiento del negocio relativo a una dimensin
Cada punto de entrada a la tabla de hechos esta conectado esta
conectado a una dimensin, lo que permite determinar el contexto
de los hechos.
6 /50

Fases de la metodologa Kimball (1)

Planificacin del Proyecto:
busca identificar la definicin y el alcance que tiene el
proyecto de DWH. Esta etapa se concentra sobre la
definicin del proyecto, donde, a nivel de planificacin,
se establece la identidad del mismo, el personal,
desarrollo del plan de proyecto, el seguimiento y la
monitorizacin.

7 /50

Fases de la metodologa Kimball (2)

Definicin de los Requerimientos del Negocio:
Es un factor determinante en el xito de un proceso de
DWH. Los diseadores de los Data Warehouse deben
tener en claro cuales son los factores claves que guan
el negocio para determinar efectivamente los
requerimientos y traducirlos en consideraciones de
diseo apropiadas.

8 /50

Fases de la metodologa Kimball (3)

Modelado Dimensional:
Se comienza con una matriz donde se determina la
dimensionalidad de cada indicador para luego
especificar los diferentes grados de detalle dentro de
cada concepto del negocio.

9 /50

Fases de la metodologa Kimball (4)

Diseo Fsico:
se centra en la seleccin de las estructuras necesarias
para soportar el diseo lgico. Un elemento principal de
este proceso es la definicin de estndares del entorno
de la base de datos. La indexacin y las estrategias de
particionamiento se determinan en esta etapa.

10 /50

Fases de la metodologa Kimball (5)

Diseo y Desarrollo de la presentacin de datos:
tiene como principales actividades la extraccin,
transformacin y carga (ETL). Estas actividades son
altamente crticas ya que tienen que ver con la materia
prima del Data Warehouse que son los datos.

11 /50

Fases de la metodologa Kimball (6)

Diseo de la arquitectura tcnica:
En esta fase se deben tener en cuenta tres factores: los
requerimientos de negocio, los actuales entornos
tcnicos, y las directrices tcnicas y estratgicas futuras
planificadas por la compaa, lo que permitir
establecer el diseo de la arquitectura tcnica del
entorno del Data Warehouse.

http://www.kimballgroup.com/
12 /50

Metodologa Hefesto
HEFESTO es una metodologa cuya propuesta est
fundamentada en una muy amplia investigacin,
comparacin de metodologas existentes y experiencias
propias en procesos de confeccin de almacenes de
datos..

13 /50

Metodologa Hefesto
La construccin e implementacin de un DW puede
adaptarse muy bien a cualquier ciclo de vida de
desarrollo de software, con la salvedad de que para
algunas fases en particular, las acciones que se han de
realizar sern muy diferentes. Lo que se debe tener muy
en cuenta, es no entrar en la utilizacin de metodologas
que requieran fases extensas de reunin de
requerimientos y anlisis, fases de desarrollo monoltico
que conlleve demasiado tiempo y fases de despliegue
muy largas. Lo que se busca, es entregar una primera
implementacin que satisfaga una parte de las
necesidades, para demostrar las ventajas del DW y
motivar a los usuarios.
14 /50

Pasos de la Metodologa Hefesto

15 /50

Pasos de la Metodologa Hefesto

16 /50

Pasos de la Metodologa Hefesto

17 /50

Pasos de la Metodologa Hefesto

18 /50

Arquitectura BI

19 /50

Datos Externos

Unificar las dimensiones

Unificar las dimensiones
Mximo nivel de detalle
Rendimiento
DWH organizado por temas
Tablas agregadas
Uso de Claves nicas
Tablas de Hechos
Dimensiones

20 /50

Extraccin / Transformacin y Carga

21 /50

Extraccin / Transformacin y Carga

22 /50

Extraccin / Transformacin y Carga

23 /50

Extraccin / Transformacin y Carga

24 /50

Extraccin / Transformacin y Carga

25 /50

Extraccin / Transformacin y Carga

26 /50

Extraccin / Transformacin y Carga

27 /50

Extraccin / Transformacin y Carga

28 /50

Extraccin / Transformacin y Carga

29 /50

Extraccin / Transformacin y Carga

30 /50

Extraccin / Transformacin y Carga

31 /50

Extraccin / Transformacin y Carga

32 /50

Extraccin / Transformacin y Carga

33 /50

Extraccin / Transformacin y Carga

34 /50

Cmo construir un Datawarehouse?

Unificar las dimensiones

Unificar las dimensiones
Mximo nivel de detalle
Rendimiento
DWH organizado por temas
Tablas agregadas
Uso de Claves nicas
Tablas de Hechos
Dimensiones

35 /50

Unificar las dimensiones

Un DWH es un repositorio donde la informacin corporativa
se encuentra "integrada
Efectivamente, cualquier empresa tiene mltiples sistemas
operacionales, cada uno de ellos con sus propios maestros
y su propia informacin. Uno de los objetivos del DWH es
unificar toda esa informacin dispersa en un nico
repositorio. Sin embargo, no se trata slo de juntar todos
estos datos, el objetivo es unificarlos, integrarlos y
conformarlos, es decir, dar la misma forma y el mismo
significado a dimensiones y hechos aparentemente
distintos (en ingls dicen "conform information").
36 /50

Unificar las dimensiones. (ejemplo)

37 /50

Unificar las dimensiones

Sabemos que es normal que dentro de
una compaa convivan muchas
aplicaciones informticas, cada una de
ellas con sus propios maestros. Una
funcin importante del DWH es la
unificacin de estas aplicaciones en
unos maestros nicos.

38 /50

Unificar las dimensiones. (ejemplo)

Por ejemplo, la aplicacin de recursos
humanos puede utilizar los cdigos "M" y
"F" para indicar el sexo de los empleados,
mientras que la aplicacin de CRM puede
estar utilizando los cdigos "H" y "M". Es
slo un ejemplo tonto, pero es la realidad
de todas las empresas. Incluso puede
haber diferencias entre los cdigos de las
tiendas y productos que utilizan las
distintas aplicaciones o mdulos del ERP

39 /50

Mximo nivel de detalle

Si se dispone la informacin detallada,
cualquier consulta posterior podr
resolverse en cualquier de las
agrupaciones disponibles. Tal vez, de
entrada, puede parecer suficiente ver
las ventas diarias de cada familia, s,
Pero y si luego quiero verlo por
grupo social? O por hora de venta?
O si lo quiero segmentar por precio
de venta? O por tipo de subfamilia?

40 /50

Rendimiento
En primer lugar, reconozcamos que
tenemos un problema de rendimiento.
Todos los datawarehouse tienen un
problema de rendimiento. Ninguno va
excesivamente rpido. Siempre se
puede mejorar. Es ms, la falta de
problemas de rendimiento suele
esconder un problema mucho mayor y
de ms difcil solucin la falta de
uso del sistema.

41 /50

Rendimiento. Problemas Comunes

Dificultad de uso de la herramienta Business
Intelligence, lo que provoca consultas incorrectas o sin
sentido por parte de los usuarios
Modelizacin deficiente (falta de agregados, falta de
ndices, etc.)
Hardware insuficiente (el sistema debe dimensionarse en
funcin del volumen a informacin a gestionar y el nmero
de usuarios activos)

42 /50

DWH organizado por temas

Otra de las caractersticas importantes que debe tener un
DWH es estar "organizado por temas" (subject-oriented).
Bill Inmon es considerado uno de los padres del
concepto DWH
Modelizar adecuadamente la estructura del sistema
Business Intelligence es fundamental para que
posteriormente el usuario puede generarse cualquier
informe que necesite

43 /50

Tablas agregadas (1)

El datawarehouse tiene, y debe tener, todo el detalle de
informacin en su nivel atmico. As, las ventas estarn
detalladas por fecha, cliente, producto y punto de venta.
Rpidamente nos daremos cuenta que estaremos
trabajando con un volumen muy importante de
informacin. Por poner algn ejemplo, en los sectores de
distribucin retail, telecomunicaciones o banca es
habitual encontrarse con datawarehouses con miles de
millones de registros.

44 /50

Tablas agregadas (2)

Sin embargo, la mayora de consultas no necesitan acceder
a tanto detalle. Un "product manager" puede estar
interesado en los totales de venta de sus productos mes a
mes, mientras que el "rea manager" consulta
habitualmente la evolucin de ventas de sus zonas.
Incluso con el uso de ndices, la compresin de las tablas, o
con una inversin millonaria en hardware, estas consultas
habituales deberan leer, agrupar y sumar decenas de
millones de registros, lo que repercutira directamente en el
tiempo de respuesta y en el descontento de los usuarios. La
solucion el uso de tablas agregadas (sumarizadas)
45 /50

Uso de Claves nicas

Una clave subrogada es un identificador nico
que se asigna a cada registro de una tabla de
dimensin. Esta clave, generalmente, no tiene
ningn sentido especfico de negocio. Son
siempre de tipo numrico. Preferiblemente, un
entero autoincremental.
Habitualmente, el sistema operacional ya utiliza
sus propias claves, aunque suelen ser de tipo
carcter y tienen un sentido especfico para los
empleados de la compaa.
46 /50

Tablas de Hechos
Denominamos hechos a los indicadores de negocio. Por
ejemplo, son hechos las ventas, los pedidos, los envos, las
reclamaciones, las compras, etc. Es decir, son todas aquellas
medidas numricas que incluiremos en nuestro sistema
Business Intelligence.
Tcnicamente, una tabla de hecho es la tabla central de un
modelo en estrella. En el siguiente diagrama, la tabla de
ventas es la tabla de hechos:

47 /50

Tablas de Hechos
Una caracterstica importante
de las tablas de hecho es el
nivel de detalle de la
informacin que se almacena.
En el anterior ejemplo, las
ventas estn guardadas a nivel
de cliente, producto, almacn,
promocin y fecha.

48 /50

Dimensiones
Denominamos dimensiones a aquellos datos que nos
permiten filtrar, agrupar o seccionar la informacin. El
trmino "dimensin" sigue teniendo un cierta
connotacin tcnica, por lo que muchas personas lo
siguen
denominando
"atributo",
"caracterstica",
"propiedad", "campo", o incluso "cuadradito azul" (en el
caso de una instalacin de BO).
Dimensiones = Jerarquia

49 /50

Modelo Estrella
El modelo estrella es el ms sencillo en
estructura. Consta de una tabla central de
"Hechos" y varias "dimensiones", incluida una
dimensin de "Tiempo". Lo caracterstico de la
arquitectura de estrella es que slo existe
una tabla de dimensiones para cada
dimensin.
Esto quiere decir que la nica tabla que tiene
relacin con otra es la de hechos, lo que
significa que toda la informacin relacionada con
una dimensin debe estar en una sola tabla
50 /50

Modelo Estrella. Ejemplo

51 /50

Modelo Copo de Nieve

El modelo copo de nieve es una variacin o
derivacin del modelo estrella. En este modelo la
tabla de hechos deja de ser la nica relacionada
con otras tablas ya que existen otras tablas que
se relacionan con las dimensiones y que no
tienen relacin directa con la tabla de hechos. El
modelo fue concebido para facilitar el
mantenimiento de las dimensiones, sin embargo
esto hace que se vinculen ms tablas a las
secuencias SQL, haciendo la extraccin de datos
ms difcil as como vuelve compleja la tarea de
mantener el modelo.
52 /50

Modelo Copo de Nieve

53 /50

Modelo Estrella vs Copo de Nieve

Para la creacin de un Datawarehouse podemos usar
dos modelos: estrella o copo de nieve. El estrella es el
ms sencillo adems de ser quizs el ms utilizado ya
que su estructura es simple y hace que la extraccin de
datos sea ms rpida, sin embargo para su uso mucha
informacin debe estar contenida en cada una de las
tablas de dimensin.

54 /50

Modelo Estrella vs Copo de Nieve

Si se desea ms orden en ese aspecto se puede utilizar
el modelo copo de nieve sin embargo al existir ms
relaciones en el modelo este se volvera poco eficiente
para buscar la informacin adems de volverse complejo
de mantener.
Por eso es muy recomendable definir bien que se espera
del Datawarehouse para utilizar uno de los dos modelos,
factores como tamao, uso y velocidad de proceso
pueden hacer tomar un modelo u otro.
.

55 /50

Modelo Estrella vs Copo de Nieve

56 /50

Cmo no construir un datawarehouse

Error 1: No compartir dimensiones entre diferentes

tablas de hechos.
Error 2: No unificar los hechos entre distintas tablas
de hechos.
Error 3: Omitir las tablas agregadas y comprimir las
tablas de dimension para afrontar los problemas de
rendimiento.
Error 4: Olvidarse del mximo nivel de detalle en el
modelo entidad-relacin.
57 /50

Cmo no construir un datawarehouse

Error 5: Mezclar hechos de diferente granularidad en

una misma tabla de hechos.
Error 6: Crear un modelo dimensional para resolver
un informe en particular.
Error 7: Aadir dimensiones en una tabla de hechos
antes de definir su granularidad.
Error 8: Crear smart keys para relacionar una tabla
de dimension con una tabla de hechos.

58 /50

Cmo no construir un datawarehouse

Error 09: No afrontar el tratamiento de las

dimensiones lentamente cambiantes.
Error 10: Dividir las jerarquas y los niveles de las
jerarquas en mltiples dimensiones.
Error 11: Abreviar las descripciones en las tablas de
dimensin con la intencin de reducir el espacio
requerido.
Error 12: Incluir atributos de texto en una tabla de
hechos, si se hace con la intencin de filtrar o
agrupar.
59 /50

Gracias!!
60 /50