Академический Документы
Профессиональный Документы
Культура Документы
METODOLOGA HEFESTO
Con el fin de que se llegue a una total comprensin de cada paso o etapa,
se acompaar con la implementacin en una empresa real, para demostrar
los resultados que se deben obtener y ejemplificar cada concepto.
1.2. Descripcin
La metodologa HEFESTO puede resumirse a travs del siguiente grfico:
Por ltimo, utilizando tcnicas de limpieza y calidad de datos, procesos ETL, etc,
se definirn polticas y estrategias para la Carga Inicial del DW y su respectiva
actualizacin.
1.3. Caractersticas
Esta metodologa cuenta con las siguientes caractersticas:
Los objetivos y resultados esperados en cada fase se distinguen
fcilmente y son sencillos de comprender.
Se basa en los requerimientos de los usuarios, por lo cual su estructura
es capaz de adaptarse con facilidad y rapidez ante los cambios en el
negocio.
Reduce la resistencia al cambio, ya que involucra a los usuarios finales
en cada etapa para que tome decisiones respecto al comportamiento y
funciones del DW.
Utiliza modelos conceptuales y lgicos, los cuales son sencillos de
interpretar y analizar.
Es independiente del tipo de ciclo de vida que se emplee para contener
la metodologa.
Es independiente de las herramientas que se utilicen para su
implementacin.
Es independiente de las estructuras fsicas que contengan el DW y de su
respectiva distribucin.
Cuando se culmina con una fase, los resultados obtenidos se convierten
en el punto de partida para llevar a cabo el paso siguiente.
Se aplica tanto para Data Warehouse como para Data Mart.
a) Identificar preguntas
Unidades vendidas.
Monto total de ventas.
Y las perspectivas de anlisis son:
Clientes.
Productos.
Tiempo.
c) Modelo Conceptual
sern los resultados que se obtendrn, cules sern las variables que se
utilizarn para analizarlos y cul es la relacin que existe entre ellos.
Caso prctico:
Los indicadores se calcularn de la siguiente manera:
Unidades Vendidas:
o
c) Nivel de granularidad
Una vez que se han establecido las relaciones con los OLTP, se
deben seleccionar los campos que contendr cada perspectiva, ya
que ser a travs de estos por los que se examinarn y filtrarn los
indicadores.
Para ello, basndose en las correspondencias establecidas en el
paso anterior, se debe presentar a las usuarias los datos de anlisis
disponibles para cada perspectiva. Es muy importante conocer en
detalle que significa cada campo y/o valor de los datos encontrados
en los OLTP, por lo cual, es conveniente investigar su sentido, ya sea
a travs de diccionarios de datos, reuniones con las encargadas del
sistema, anlisis de los datos propiamente dichos, etc.
Luego de exponer frente a las usuarias los datos existentes,
explicando su significado, valores posibles y caractersticas, estas
deben decidir cuales son los que consideran relevantes para
consultar los indicadores y cuales no.
Con respecto a la perspectiva Tiempo, es muy importante definir el
mbito mediante el cual se agruparn o sumarizarn los datos. Sus
campos posibles pueden ser: da de la semana, quincena, mes,
trimestres, semestre, ao, etc.
Al momento de seleccionar los campos que integrarn cada
perspectiva, debe prestarse mucha atencin, ya que esta accin
determinar la granularidad de la informacin encontrada en el DW.
Caso prctico:
De acuerdo a las correspondencias establecidas, se analizaron los
campos residentes en cada tabla a la que se hacia referencia, a
travs de dos mtodos diferentes. Primero se examin la base de
datos para intuir los significados de cada campo, y luego se consult
con el encargado del sistema sobre algunos aspectos de los cuales
no se comprenda su sentido.
De todas formas, y como puede apreciarse en el diagrama de
relacional antes expuesto, los nombres de los campos son bastante
explcitos y se deducen con facilidad, pero an as fue necesario
investigarlos para evitar cualquier tipo de inconvenientes.
o
o
o
o
o
o
o
o
o
o
Ao.
Semestre.
Cuatrimestre.
Trimestre.
Nmero de mes.
Quincena.
Semana.
Nmero de da.
Perspectiva Clientes:
Perspectiva Productos:
Perspectiva Tiempo:
Trimestre.
Ao.
d) Modelo Conceptual ampliado
En este paso, y con el fin de graficar los resultados obtenidos en
los pasos anteriores, se ampliar el modelo conceptual, colocando
bajo cada perspectiva los campos seleccionados y bajo cada
indicador su respectiva frmula de clculo. Grficamente:
Caso prctico:
El esquema que se utilizar ser en estrella, debido a sus
caractersticas, ventajas y diferencias con los otros esquemas.
Grficamente:
Para los esquemas copo de nieve, cuando existan jerarquas dentro de una tabla
de dimensin, esta tabla deber ser normalizada. Por ejemplo, se tomar como
referencia la siguiente tabla de dimensin y su respectivas relaciones padre-ho
entre sus campos:
Caso prctico:
A continuacin, se disearan las tablas de dimensiones.
Perspectiva Clientes:
o La nueva tabla de dimensin tendr el nombre CLIENTE.
o Se le agregar una clave principal con el nombre idCliente.
o Se modificar el nombre del campo Razon_Soc por Cliente.
Se puede apreciar el resultado de estas operaciones en la siguiente
grfica:
Perspectiva Productos:
Perspectiva Tiempo:
Grficamente:
o
Entonces se obtendr:
Entonces se obtendr:
Se unificarn en:
Caso prctico:
A continuacin, se confeccionar la tabla de hechos:
5.5.3.4. d) Uniones
Para los tres tipos de esquemas, se realizarn las uniones correspondientes
entre sus tablas de dimensiones y sus tablas de hechos.
Caso prctico:
Se realizarn las uniones pertinentes, de acuerdo corresponda:
Una vez construido el modelo lgico, se deber proceder a poblarlo con datos,
utilizando tcnicas de limpieza y calidad de datos, procesos ETL, etc.; luego se
definirn las reglas y polticas para su respectiva actualizacin, as como
tambin los procesos que la llevarn a cabo.
Caso prctico:
Para simplificar la aplicacin del ejemplo, el caso prctico solo se centrar
en los aspectos ms importantes del proceso ETL, obviando entrar en
detalle de cmo se realizan algunas funciones y/o pasos.
El proceso ETL planteado para la Carga Inicial es el siguiente:
Obtener datos de OLTP: obtiene a travs de una consulta SQL los datos
del OLTP necesarios para cargar la dimensin CLIENTE.
Se tomar como fuente de entrada la tabla Clientes del OLTP
mencionado anteriormente.
Se consult con las usuarias y se averigu que deseaban tener en cuenta
solo aquellos clientes que no estn eliminados y que tengan su cuenta
habilitada.
Es importante destacar que aunque existan numerosos movimientos de
clientes que en la actualidad no poseen su cuenta habilitada o que figuran
Obtener datos de OLTP: obtiene a travs de una consulta SQL los datos
del OLTP necesarios para cargar la dimensin PRODUCTO.
Las fuentes que se utilizarn, son las tablas Productos y Marcas.
En este caso, aunque existan productos eliminados, las usuarias
decidieron que esta condicin no fuese tomada en cuenta, ya que haban
movimientos que hacan referencia a productos con este estado.
Es necesario realizar una unin entre la tabla Productos y Marcas, por
lo cual se debi asegurar que ningn producto hiciera mencin a alguna
marca que no existiese, y se tomaron medidas contra su futura aparicin.
El SQL que contiene este paso es el siguiente:
Para generar esta tabla de dimensin, infaltable en todo DW, existen varias
herramientas y utilidades de software que proporcionan diversas opciones
para su confeccin. Pero, si no se cuenta con ninguna, se puede realizar
manualmente o mediante algn programa, llenando los datos en un
archivo, tabla, hoja de clculo, etc, y luego exportndolos a donde se
requiera.
Lo que se hizo, fue realizar un procedimiento que hace lo siguiente:
Recorre una a una las fechas que se encuentran dentro de este intervalo.
o idFecha =
DAY(fecha).
YEAR(fecha)*10000
MONTH(fecha)*100
o Ao = YEAR(fecha).
o Trimestre = CASE WHEN QUARTER(fecha) = 1 then '1er Tri' ...
END.
o Mes = CASE WHEN MONTH(fecha) = 1 then 'Enero' ... END.
o Inserta los valores obtenidos en la tabla de dimensin FECHA.
Como puede observarse, la clave principal "idFecha" es un campo
numrico representado por el formato "yyyymmdd".
Obtener datos de OLTP: obtiene a travs de una consulta SQL los datos
del OLTP necesarios para cargar la tabla de hechos VENTAS.
5.5.4.2 b) Actualizacin
Cuando se haya cargado en su totalidad el DW, se deben establecer sus
polticas y estrategias de actualizacin o refresco de datos.
Una vez realizado esto, se tendrn que llevar a cabo las siguientes acciones:
Caso prctico:
Las polticas de Actualizacin que se han convenido con las usuarias son
las siguientes:
Los datos de la tabla de hechos que corresponden al ltimo mes (30 das)
a partir de la fecha actual, sern reemplazados cada vez.
Inicio: iniciar la ejecucin de los pasos todos los das a las doce de la
noche.
Unidades Vendidas.
o
Trimestres.
Grficamente:
Grficamente:
Cubo 1:
Cubo 2:
Cubo 3: