METODOLOGIA HEFESTO

1.1. Introduccion a la Metodologia HEFESTO

HEFESTO es una metodologia propia, cuya propuesta esta fundamentada

en una muy amplia investigacion, comparacion de metodologias existentes,
experiencias propias en procesos de confeccion de almacenes de datos.
Cabe destacar que HEFESTO esta en continua evolucion, y se han tenido
en cuenta, como gran valor agregado, todos los feedbacks que han aportado
quienes han utilizado esta metodologia en diversos paises y con diversos
fines.
La idea principal, es comprender cada paso que se realizara, para no caer
en el tedio de tener que seguir un metodo al pie de la letra sin saber
exactamente que se esta haciendo, ni por que.
La construccion e implementacion 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 seran
muy diferentes. Lo que se debe tener muy en cuenta, es no entrar en la
utilizacion de metodologias que requieran fases extensas de reunion de
requerimientos y analisis, fases de desarrollo monolitico que conlleve
demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es
entregar una primera implementacion que satisfaga una parte de las
necesidades, para demostrar las ventajas del DW y motivar a los usuarios.
La metodologia HEFESTO, puede ser embebida en cualquier ciclo de vida
que cumpla con la condicion antes declarada.
Con el fin de que se llegue a una total comprension de cada paso o etapa,
se acompanara con la implementacion en una empresa real, para demostrar
los resultados que se deben obtener y ejemplificar cada concepto.
1.2. Descripcion
La metodologia HEFESTO puede resumirse a traves del siguiente grafico:
Como se puede apreciar, se comienza recolectando las necesidades de
informacion de las usuarias y se obtienen las preguntas claves del negocio.
Luego, se deben identificar los indicadores resultantes de los interrogativos y sus
respectivas perspectivas de analisis, mediante las cuales se construira el modelo
conceptual de datos del DW.
Despues, se analizaran los OLTP para determinar como se construiran los
indicadores, senalar las correspondencias con los datos fuentes y para
seleccionar los campos de estudio de cada perspectiva.
Una vez hecho esto, se pasara a la construccion del modelo logico del deposito,
en donde se definira cual sera el tipo de esquema que se implementara.
Seguidamente, se confeccionaran las tablas de dimensiones y las tablas de
hechos, para luego efectuar sus respectivas uniones.
Por ultimo, utilizando tecnicas de limpieza y calidad de datos, procesos ETL, etc,
se definiran politicas y estrategias para la Carga Inicial del DW y su respectiva
actualizacion.
1.3. Caracteristicas
Esta metodologia cuenta con las siguientes caracteristicas:
Los objetivos y resultados esperados en cada fase se distinguen
facilmente 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 logicos, los cuales son sencillos de
interpretar y analizar.
Es independiente del tipo de ciclo de vida que se emplee para contener
la metodologia.
Es independiente de las herramientas que se utilicen para su
implementacion.
Es independiente de las estructuras fisicas que contengan el DW y de su
respectiva distribucion.
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.
1.4. Empresa analizada
Antes de comenzar con el primer paso en la construccion del Data
Warehouse, es menester describir las caracteristicas principales de la
empresa a la cual se le aplicara la metodologia HEFESTO, asi se podra
tener como base un ambito predefinido y se comprendera mejor cada
decision que se tome con respecto a la implementacion y diseno del DW.
Ademas, este analisis ayudara a conocer el funcionamiento y organizacion
de la empresa, lo que permitira examinar e interpretar de forma optima las
necesidades de informacion de la misma, como asi tambien apoyara a una
mejor construccion y adaptacion del deposito de datos.
1.5. Pasos y aplicacion metodologica
1.5.1. Analisis de Requerimientos
Lo primero que se hara sera identificar los requerimientos de las
usuarias a traves de preguntas que expliciten los objetivos de su
organizacion. Luego, se analizaran estas preguntas a fin de identificar
cuales seran los indicadores y perspectivas que seran tomadas en
cuenta para la construccion del DW. Finalmente se confeccionara un
modelo conceptual en donde se podra visualizar el resultado obtenido en
este primer paso.
Es muy importante tener en cuenta que HEFESTO se puede utilizar para
construir un Data Warehouse o un Data Mart a la vez, es decir, si se
requiere construir por ejemplo dos Data Marts, se debera aplicar la
metodologia dos veces, una por cada Data Mart. Del mismo modo, si se
analizan dos areas de interes de negocio, como el area de ”Ventas” y
”Compras”, se debera aplicar la metodologia dos veces.
a) Identificar preguntas
El primer paso comienza con el acopio de las necesidades de
informacion, el cual puede llevarse a cabo a traves de muy variadas y
diferentes tecnicas, cada una de las cuales poseen caracteristicas
inherentes y especificas, como por ejemplo entrevistas, cuestionarios,
observaciones, etc.
El analisis de los requerimientos de las diferentes usuarias, es el punto
de partida de esta metodologia, ya que ellas son las que deben, en
cierto modo, guiar la investigacion hacia un desarrollo que refleje
claramente lo que se espera del deposito de datos, en relacion a sus
funciones y cualidades.
El objetivo principal de esta fase, es la de obtener e identificar las
necesidades de informacion clave de alto nivel, que es esencial para
llevar a cabo las metas y estrategias de la empresa, y que facilitara una
eficaz y eficiente toma de decisiones.
Debe tenerse en cuenta que dicha informacion, es la que proveera el
soporte para desarrollar los pasos sucesivos, por lo cual, es muy
importante que se preste especial atencion al relevar los datos.
Una forma de asegurarse de que se ha realizado un buen analisis, es
corroborar que el resultado del mismo haga explicitos los objetivos
estrategicos planteados por la empresa que se esta estudiando.
Otra forma de encaminar el relevamiento, es enfocar las necesidades de
informacion en los procesos principales que desarrolle la empresa en
cuestion.
La idea central es, que se formulen preguntas complejas sobre el
negocio, que incluyan variables de analisis que se consideren
relevantes, ya que son estas las que permitiran estudiar la informacion
desde diferentes perspectivas.
Un punto importante que debe tenerse muy en cuenta, es que la
informacion debe estar soportada de alguna manera por algun OLTP, ya
que de otra forma, no se podra elaborar el DW.
Caso practico:
Se indagó a las usuarias en busca de sus necesidades de información,
pero las mismas abarcaban casi todas las actividades de la empresa,
por lo cual se les pidió que escogieran el proceso que considerasen más
importante en las actividades diarias de la misma y que estuviese
soportado de alguna manera por algún OLTP. El proceso elegido fue el
de Ventas.
A continuacion, se procedio a identificar que era lo que les interesaba
conocer acerca de este proceso y cuales eran las variables o
perspectivas que debian tenerse en cuenta para poder tomar decisiones
basadas en ello.
Se les pregunto cuales eran segun ellas, los indicadores que
representan de mejor modo el proceso de Ventas y que seria
exactamente lo que se desea analizar del mismo. La respuesta obtenida,
fue que se deben tener en cuenta y consultar datos sobre la cantidad de
unidades vendidas y el monto total de ventas.
Luego se les pregunto cuales serian las variables o perspectivas desde
las cuales se consultaran dichos indicadores. Para simplificar esta tarea
se les presento una serie de ejemplos concretos de otros casos
similares.
Las preguntas de negocio obtenidas fueron las siguientes:
Se desea conocer cuantas unidades de cada producto fueron vendidas a
sus clientes en un periodo determinado. O en otras palabras: ”Unidades
vendidas de cada producto a cada cliente en un tiempo determinado”.
Se desea conocer cual fue el monto total de ventas de productos a cada
cliente en un periodo determinado. O en otras palabras: ”Monto total de
ventas de cada producto a cada cliente en un tiempo determinado”.
Debido a que la dimension Tiempo es un elemento fundamental en el
DW, se hizo hincapie en el. Ademas, se puso mucho enfasis en dejar en
claro a las usuarias, a traves de ejemplos practicos, que es este
componente el que permitira tener varias versiones de los datos a fin de
realizar un correcto analisis posterior.
Como se puede apreciar, las necesidades de información expuestas
están acorde a los objetivos y estrategias de la empresa, ya que es
precisamente esta información requerida la que proveerá un ámbito para
la toma de decisiones, que en este caso permitirá analizar el
comportamiento de las clientas a las que se pretende satisfacer
ampliamente, para así lograr obtener una ventaja competitiva y
maximizar las ganancias.
b) Identificar indicadores y perspectivas
Una vez que se han establecido las preguntas de negocio, se debe
proceder a su descomposicion para descubrir los indicadores que se
utilizaran y las perspectivas de analisis que intervendran.
Para ello, se debe tener en cuenta que los indicadores, para que sean
realmente efectivos son, en general, valores numericos y representan lo
que se desea analizar concretamente, por ejemplo: saldos, promedios,
cantidades, sumatorias, formulas, etc.
En cambio, las perspectivas se refieren a los objetos mediante los cuales
se quiere examinar los indicadores, con el fin de responder a las
preguntas planteadas, por ejemplo: clientes, proveedores, sucursales,
paises, productos, rubros, etc. Cabe destacar, que el Tiempo es muy
comunmente una perspectiva.
Caso practico:
A continuacion, se analizaran las preguntas obtenidas en el
paso anterior y se detallaran cuales son sus respectivos indicadores y
perspectivas.
Figura 5.3: Caso practico, indicadores y perspectivas.
En síntesis, los indicadores son:
Unidades vendidas.
Monto total de ventas.
Y las perspectivas de análisis son:
Clientes.
Productos.
Tiempo.
c) Modelo Conceptual
En esta etapa, se construira un modelo conceptual a partir de los
indicadores y perspectivas obtenidas en el paso anterior.Modelo
Conceptual: descripción de alto nivel de la estructura de la base de
datos, en la cual la información es representada a través de objetos,
relaciones y atributos.
A traves de este modelo, se podra observar con claridad cuales son los
alcances del proyecto, para luego poder trabajar sobre ellos, ademas al
poseer un alto nivel de definicion de los datos, permite que pueda ser
presentado ante las usuarias y explicado con facilidad.
La representacion grafica del modelo conceptual es la siguiente:
Figura 5.4: Modelo Conceptual.
A la izquierda se colocan las perspectivas seleccionadas, que seran unidas a un
ovalo central que representa y lleva el nombre de la relacion que existe entre
ellas. La relacion, constituye el proceso o area de estudio elegida. De dicha
relacion y entrelazadas con flechas, se desprenden los indicadores, estos se
ubican a la derecha del esquema.
Como puede apreciarse en la figura anterior, el modelo conceptual permite de un
solo vistazo y sin poseer demasiados conocimientos previos, comprender cuales
seran los resultados que se obtendran, cuales seran las variables que se
utilizaran para analizarlos y cual es la relacion que existe entre ellos.
1.5.2. Analisis de los OLPT
Seguidamente, se analizaran las fuentes OLTP para determinar como
seran calculados los indicadores y para establecer las respectivas
correspondencias entre el modelo conceptual creado en el paso anterior
y las fuentes de datos. Luego, se definiran que campos se incluiran en
cada perspectiva. Finalmente, se ampliara el modelo conceptual con la
informacion obtenida en este paso.
a) Conformar Indicadores
En este paso se deberan explicitar como se calcularan los
indicadores, definiendo los siguientes conceptos para cada uno de
ellos:
Hecho/s que lo componen, con su respectiva formula de calculo. Por
ejemplo: Hecho1 + Hecho2.
Funcion de sumarizacion que se utilizara para su agregacion. Por
ejemplo: SUM, AVG, COUNT, etc.
Caso practico:
Los indicadores se calcularan de la siguiente manera:
”Unidades Vendidas”:
o Hechos: Unidades Vendidas.
o Funcion de sumarizacion: SUM.
Aclaracion: el indicador ”Unidades Vendidas” representa la sumatoria
de las unidades que se han vendido de un producto en particular.
”Monto Total de Ventas”:
o Hechos: (Unidades Vendidas) * (Precio de Venta).
o Funcion de sumarizacion: SUM.
Aclaracion: el indicador ”Monto Total de Ventas” representa la
sumatoria del monto total que se ha vendido de cada producto, y se
obtiene al multiplicar las unidades vendidas, por su respectivo
precio.
b) Establecer correspondencias
El objetivo de este paso, es el de examinar los OLTP disponibles que
contengan la informacion requerida, como asi tambien sus
caracteristicas, para poder identificar las correspondencias entre el
modelo conceptual y las fuentes de datos.
La idea es, que todos los elementos del modelo conceptual esten
correspondidos en los OLTP.
Caso practico:
En el OLTP de la empresa analizada, el proceso de venta esta
representado por el diagrama relacional de la siguiente figura.
Diagrama Relacional: representa la informacion a traves de
entidades, relaciones, cardinalidades, claves, atributos y jerarquias
de generalizacion.
Figura 5.6: Caso practico, Diagrama Relacional.
A continuacion, se expondra la correspondencia entre los dos
modelos:
Figura 5.7: Caso practico, correspondencia.
Las relaciones identificadas fueron las siguientes:
La tabla ”Productos” se relaciona con la perspectiva ”Productos”.
La tabla ”Clientes” con la perspectiva ”Clientes”.
El campo ”fecha” de la tabla ”Facturas_Venta” con la perspectiva
”Tiempo” (debido a que es la fecha principal en el proceso de
venta).
El campo ”cantidad” de la tabla ”Detalles_Venta” con el indicador
”Unidades Vendidas”.
El campo ”cantidad” de la tabla ”Detalles_Venta” multiplicado por
el campo ”precio_Fact” de la misma tabla, con el indicador ”Monto
Total de Ventas”.
c) Nivel de granularidad
Una vez que se han establecido las relaciones con los OLTP, se
deben seleccionar los campos que contendra cada perspectiva, ya
que sera a traves de estos por los que se examinaran y filtraran los
indicadores.
Para ello, basandose en las correspondencias establecidas en el
paso anterior, se debe presentar a las usuarias los datos de analisis
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 traves de diccionarios de datos, reuniones con las encargadas del
sistema, analisis de los datos propiamente dichos, etc.
Luego de exponer frente a las usuarias los datos existentes,
explicando su significado, valores posibles y caracteristicas, 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
ambito mediante el cual se agruparan o sumarizaran los datos. Sus
campos posibles pueden ser: dia de la semana, quincena, mes,
trimestres, semestre, ano, etc.
Al momento de seleccionar los campos que integraran cada
perspectiva, debe prestarse mucha atencion, ya que esta accion
determinara la granularidad de la informacion encontrada en el DW.
Caso practico:
De acuerdo a las correspondencias establecidas, se analizaron los
campos residentes en cada tabla a la que se hacia referencia, a
traves de dos metodos diferentes. Primero se examino la base de
datos para intuir los significados de cada campo, y luego se consulto
con el encargado del sistema sobre algunos aspectos de los cuales
no se comprendia su sentido.
De todas formas, y como puede apreciarse en el diagrama de
relacional antes expuesto, los nombres de los campos son bastante
explicitos y se deducen con facilidad, pero aun asi fue necesario
investigarlos para evitar cualquier tipo de inconvenientes.
Con respecto a la perspectiva ”Clientes”, los datos disponibles son
los siguientes:
o id_Cliente: es la clave primaria de la tabla ”Clientes”, y representa
univocamente a un cliente en particular.
o Codigo: representa el codigo del cliente, este campo es calculado
de acuerdo a una combinacion de las iniciales del nombre del
cliente, el grupo al que pertenece y un numero incremental.
o Razon_Soc: nombre o razon social del cliente.
o Telefono1: numero de telefono del cliente.
o Telefono2: segundo numero telefonico del cliente.
o Fax1: numero de fax del cliente.
o Fax2: segundo numero de fax del cliente.
o Mail1: direccion de correo electronico del cliente.
o Mail2: segunda direccion de correo del cliente.
o id_Sit_Fiscal: representa a traves de una clave foranea el tipo de
situacion fiscal que posee el cliente. Por ejemplo: Consumidor Final,
Exento, Responsable No Inscripto, Responsable Inscripto.
o CUIT: numero de C.U.I.T. del cliente.
o ConvenioMultilateral: indica si el cliente posee o no convenio
multilateral.
o DGR: numero de D.G.R. del cliente.
o id_Clasificacion: representa a traves de una clave foranea la
clasificacion del cliente. Por ejemplo: Muy Bueno, Bueno, Regular,
Malo, Muy Malo.
o id_Nota: representa a traves de una clave foranea una observacion
realizada acerca del cliente.
o Cta_Habilitada: indica si el cliente posee su cuenta habilitada.
o id_Rubro: representa a traves de una clave foranea el grupo al que
pertenece el cliente. Por ejemplo: Bancos, Construccion, Educacion
Privada, Educacion Publica, Particulares.
o idCuentaContable: representa la cuenta contable asociada al
cliente, la cual se utilizara para imputar los movimientos contables
que este genere.
o Eliminado: indica si el cliente fue eliminado o no. Si fue eliminado,
no figura en las listas de clientes actuales.
En la perspectiva ”Productos”, los datos que se pueden utilizar son
los siguientes:
o id_prod: es la clave primaria de la tabla ”Productos”, y representa
univocamente a un producto en particular.
o stock: stock actual del producto.
o stock_min: stock minimo del producto, se utiliza para dar alerta si el
stock actual esta cerca del mismo, al ras o si ya lo supero.
o Precio: precio de venta del producto.
o Detalle: nombre o descripcion del producto.
o id_Rubro: representa a traves de una clave foranea el rubro al que
pertenece el producto.
o id_Marca: representa a traves de una clave foranea la marca a la
que pertenece el producto.
o stock_MAX: stock maximo del producto. Al igual que ”stock_min”,
se utiliza para dar alertas del nivel de stock actual.
o tipo: clasificacion del producto. Por ejemplo: Producto, Servicio,
Compuesto.
o Costo: precio de costo del producto.
o codigo: representa el codigo del producto, este campo es calculado
de acuerdo a una combinacion de las iniciales del nombre del
producto, el rubro al que pertenece y un numero incremental.
o Imagen: ruta de acceso a una imagen o dibujo mediante la cual se
quiera representar al producto. Este campo no es utilizado
actualmente.
o Generico: indica si el producto es generico o no.
o Eliminado: indica si el producto fue eliminado o no. Si fue
eliminado, no figura en las listas de productos actuales.
o PrecioR: precio de lista del producto.
Con respecto a la perspectiva ”Tiempo”, que es la que determinara la
granularidad del deposito de datos, los datos mas tipicos que
pueden emplearse son los siguientes:
o Ano.
o Semestre.
o Cuatrimestre.
o Trimestre.
o Numero de mes.
o Nombre del mes.
o Quincena.
o Semana.
o Numero de dia.
o Nombre del dia.
Una vez que se recolecto toda la informacion pertinente y se
consulto con las usuarias cuales eran los datos que consideraban de
interes para analizar los indicadores ya expuestos, los resultados
obtenidos fueron los siguientes:
Perspectiva ”Clientes”:
o ”Razon_Soc” de la tabla ”Clientes”. Ya que este hace referencia al
nombre del cliente.
Perspectiva ”Productos”:
o ”detalle” de la tabla ”Productos”. Ya que este hace referencia al
nombre del producto.
o ”Nombre” de la tabla ”Marcas”. Ya que esta hace referencia a la
marca a la que pertenece el producto. Este campo es obtenido a
traves de la union con la tabla ”Productos”
Perspectiva ”Tiempo”:
o ”Mes”. Referido al nombre del mes.
o ”Trimestre”.
o ”Ano”.
d) Modelo Conceptual ampliado
En este paso, y con el fin de graficar los resultados obtenidos en
los pasos anteriores, se ampliara el modelo conceptual, colocando
bajo cada perspectiva los campos seleccionados y bajo cada
indicador su respectiva formula de calculo. Graficamente:
Figura 5.8: Modelo Conceptual ampliado.
5.5.3 Paso 3) Modelo logico del DW
A continuacion, se confeccionara el modelo logico de la estructura del DW,
teniendo como base el modelo conceptual que ya ha sido creado. Para ello,
primero se definira el tipo de modelo que se utilizara y luego se llevaran a cabo
las acciones propias al caso, para disenar las tablas de dimensiones y de
hechos. Finalmente, se realizaran las uniones pertinentes entre estas
tablas. Modelo Lógico: representación de una estructura de datos, que puede
procesarse y almacenarse en algún SGBD.
5.5.3.1. a) Tipo de Modelo Logico del DW
Se debe seleccionar cual sera el tipo de esquema que se utilizara para contener
la estructura del deposito de datos, que se adapte mejor a los requerimientos y
necesidades de las usuarias. Es muy importante definir objetivamente si se
empleara un esquema en estrella, constelacion o copo de nieve, ya que esta
decision afectara considerablemente la elaboracion del modelo logico.
Caso practico:
El esquema que se utilizara sera en estrella, debido a sus
caracteristicas, ventajas y diferencias con los otros esquemas.
5.5.3.2. b) Tablas de dimensiones
En este paso se deben disenar las tablas de dimensiones que formaran parte del
DW.
Para los tres tipos de esquemas, cada perspectiva definida en en modelo
conceptual constituira una tabla de dimension. Para ello debera tomarse cada
perspectiva con sus campos relacionados y realizarse el siguiente proceso:

Se elegira un nombre que identifique la tabla de dimension.

Se anadira un campo que represente su clave principal.

Se redefiniran los nombres de los campos si es que no son lo

suficientemente intuitivos.

Graficamente:

Figura 5.10: Diseno de tablas de dimensiones.

Para los esquemas copo de nieve, cuando existan jerarquias dentro de una tabla
de dimension, esta tabla debera ser normalizada. Por ejemplo, se tomara como
referencia la siguiente tabla de dimension y su respectivas relaciones padre-hijo
entre sus campos:
Figura 5.11: Jerarquia de ”GEOGRAFIA”.
Entonces, al normalizar esta tabla se obtendra:
Figura 5.12: Normalizacion de ”GEOGRAFIA”.
Caso practico:
A continuacion, se disenaran las tablas de dimensiones.
Perspectiva “Clientes”:
o La nueva tabla de dimension tendra el nombre “CLIENTE”.
o Se le agregara una clave principal con el nombre “idCliente”.
o Se modificara el nombre del campo “Razon_Soc” por “Cliente”.
Se puede apreciar el resultado de estas operaciones en la siguiente
grafica:
Figura 5.13: Caso practico, tabla de dimension ”CLIENTE”.

Perspectiva “Productos”:

o
La nueva tabla de dimension tendra el nombre “PRODUCTO”.
o
o
Se le agregara una clave principal con el nombre “idProducto”.
o
o
El nombre del campo “Marca” no sera cambiado.
o
o
Se modificara el nombre del campo “Detalle” por “Producto”.
o
Se puede apreciar el resultado de estas operaciones en la siguiente
grafica:
Figura 5.14: Caso practico, tabla de dimension ”PRODUCTO”.

Perspectiva “Tiempo”:

o
La nueva tabla de dimension tendra el nombre “FECHA”.
o
o
Se le agregara una clave principal con el nombre “idFecha”.
o
o
El nombre los campos no seran modificados.
o
Se puede apreciar el resultado de estas operaciones en la siguiente
grafica:
Figura 5.15: Caso practico, tabla de dimension ”FECHA”.
5.5.3.3. c) Tablas de hechos
En este paso, se definiran las tablas de hechos, que son las que contendran los
hechos a traves de los cuales se construiran los indicadores de estudio.

Para los esquemas en estrella y copo de nieve, se realizara lo siguiente:

o
Se le debera asignar un nombre a la tabla de hechos que
represente la informacion analizada, area de investigacion, negocio
enfocado, etc.
o
o
Se definira su clave primaria, que se compone de la combinacion
de las claves primarias de cada tabla de dimension relacionada.
o
o
Se crearan tantos campos de hechos como indicadores se hayan
definido en el modelo conceptual y se les asignara los mismos
nombres que estos. En caso que se prefiera, podran ser
nombrados de cualquier otro modo.
o
Graficamente:
o
Figura 5.16: Tabla de hechos.

Para los esquemas constelacion se realizara lo siguiente:

o
Las tablas de hechos se deben confeccionar teniendo en cuenta el
analisis de las preguntas realizadas por las usuarias en pasos
anteriores y sus respectivos indicadores y perspectivas.
o
o
Cada tabla de hechos debe poseer un nombre que la identifique,
contener sus hechos correspondientes y su clave debe estar
formada por la combinacion de las claves de las tablas de
dimensiones relacionadas.
o
o
Al disenar las tablas de hechos, se debera tener en cuenta:
o

Caso 1: Si en dos o mas preguntas de negocio figuran los

mismos indicadores pero con diferentes perspectivas de
analisis, existiran tantas tablas de hechos como preguntas
cumplan esta condicion. Por ejemplo:

Figura 5.17: Caso 1, preguntas.

Entonces se obtendra:

Figura 5.18: Caso 1, diseno de tablas de hechos.

Caso 2: Si en dos o mas preguntas de negocio figuran diferentes

indicadores con diferentes perspectivas de analisis, existiran tantas
tablas de hechos como preguntas cumplan esta condicion. Por
ejemplo:
Figura 5.19: Caso 2, preguntas.
Entonces se obtendra:
Figura 5.20: Caso 2, diseno de tablas de hechos.
Caso 3: Si el conjunto de preguntas de negocio cumplen con las
condiciones de los dos puntos anteriores se deberan unificar
aquellos interrogantes que posean diferentes indicadores pero
iguales perspectivas de analisis, para luego reanudar el estudio de
las preguntas. Por ejemplo:
Figura 5.21: Caso 3, preguntas.
Se unificaran en:
Figura 5.22: Caso 3, unificacion.
Caso practico:
A continuacion, se confeccionara la tabla de hechos:
La tabla de hechos tendra el nombre “VENTAS”.
Su clave principal sera la combinacion de las claves principales de las
tablas de dimensiones antes definidas: “idCliente”, “idProducto” e
“idFecha”.
Se crearan dos hechos, que se corresponden con los dos indicadores y
seran renombrados, “Unidades Vendidas” por “Cantidad” y “Monto Total
de Ventas” por “MontoTotal”.
En el grafico siguiente se puede apreciar mejor este paso:
Figura 5.23: Caso practico, diseno de la tabla de hechos.
5.5.3.4. d) Uniones
Para los tres tipos de esquemas, se realizaran las uniones correspondientes
entre sus tablas de dimensiones y sus tablas de hechos.
Caso practico:
Se realizaran las uniones pertinentes, de acuerdo corresponda:
Figura 5.24: Caso practico, uniones.
5.5.5 Paso 4) Integracion de Datos
Una vez construido el modelo logico, se debera proceder a poblarlo con datos,
utilizando tecnicas de limpieza y calidad de datos, procesos ETL, etc.; luego se
definiran las reglas y politicas para su respectiva actualizacion, asi como
tambien los procesos que la llevaran a cabo.
5.5.4.1 a) Carga Inicial
Debemos en este paso realizar la Carga Inicial al DW, poblando el modelo de
datos que hemos construido anteriormente. Para lo cual debemos llevar
adelante una serie de tareas basicas, tales como limpieza de datos, calidad de
datos, procesos ETL, etc.
La realizacion de estas tareas pueden contener una logica realmente compleja
en algunos casos. Afortunadamente, en la actualidad existen muchos softwares
que se pueden emplear a tal fin, y que nos facilitaran el trabajo.
Se debe evitar que el DW sea cargado con valores faltantes o anomalos, asi
como tambien se deben establecer condiciones y restricciones para asegurar
que solo se utilicen los datos de interes.
Cuando se trabaja con un esquema constelacion, hay que tener presente que
varias tablas de dimensiones seran compartidas con diferentes tablas de
hechos, ya que puede darse el caso de que algunas restricciones aplicadas
sobre una tabla de dimension en particular para analizar una tabla de hechos, se
puedan contraponer con otras restricciones o condiciones de analisis de otras
tablas de hechos.
Primero se cargaran los datos de las dimensiones y luego los de las tablas de
hechos, teniendo en cuenta siempre, la correcta correspondencia entre cada
elemento. En el caso en que se este utilizando un esquema copo de nieve, cada
vez que existan jerarquias de dimensiones, se comenzaran cargando las tablas
de dimensiones del nivel mas general al mas detallado.
Concretamente, en este paso se debera registrar en detalle las acciones
llevadas a cabo con los diferentes softwares. Por ejemplo, es muy comun que
sistemas ETL trabajen con "pasos" y "relaciones", en donde cada "paso" realiza
una tarea en particular del proceso ETL y cada "relacion" indica hacia donde
debe dirigirse el flujo de datos. En este caso lo que se debe hacer es explicar
que hace el proceso en general y luego que hace cada "paso" y/o "relacion". Es
decir, se partira de lo mas general y se ira a lo mas especifico, para obtener de
esta manera una vision general y detallada de todo el proceso.
Es importante tener presente, que al cargar los datos en las tablas de hechos
pueden utilizarse preagregaciones, ya sea al nivel de granularidad de la misma o
a otros niveles diferentes.
Caso practico:
Para simplificar la aplicacion del ejemplo, el caso practico solo se centrara
en los aspectos mas importantes del proceso ETL, obviando entrar en
detalle de como se realizan algunas funciones y/o pasos.
El proceso ETL planteado para la Carga Inicial es el siguiente:
Figura 5.26: Caso practico, Carga Inicial.
Las tareas que lleva a cabo este proceso son:
Inicio: inicia la ejecucion de los pasos en el momento en que se le
indique.
Establecer variables Fecha_Desde y Fecha_Hasta: establece dos
variables globales que seran utilizadas posteriormente por algunos pasos.
o Para la variable "Fecha_Desde" se obtiene el valor de la fecha en
que se realizo la primera venta.
o Para la variable "Fecha_Hasta" se obtiene el valor de la fecha
actual.
Carga de Dimension CLIENTE: ejecuta el contenedor de pasos que
cargara la dimension CLIENTE, mas adelante se detallara el mismo.
Carga de Dimension PRODUCTO: ejecuta el contenedor de pasos que
cargara la dimension PRODUCTO, mas adelante se detallara el mismo.
Carga de Dimension FECHA: ejecuta el contenedor de pasos que cargara
la dimension FECHA, mas adelante se detallara el mismo.
Carga de Tabla de Hechos VENTAS: ejecuta el contenedor de pasos que
cargara la tabla de hechos VENTAS, mas adelante se detallara el mismo.
A continuacion, se especificaran las tareas llevadas a cabo por "Carga de
Dimension CLIENTE". Este paso es un contenedor de pasos, asi que
incluye las siguientes tareas:
Figura 5.27: Caso practico, Carga de Dimension CLIENTE.
Obtener datos de OLTP: obtiene a traves de una consulta SQL los datos
del OLTP necesarios para cargar la dimension CLIENTE.
Se tomara como fuente de entrada la tabla “Clientes” del OLTP
mencionado anteriormente.
Se consulto con las usuarias y se averiguo que deseaban tener en cuenta
solo aquellos clientes que no esten eliminados y que tengan su cuenta
habilitada.
Es importante destacar que aunque existian numerosos movimientos de
clientes que en la actualidad no poseen su cuenta habilitada o que figuran
como eliminados, se decidio no incluirlos debido a que el enfasis esta
puesto en analizar los datos a traves de aquellos clientes que no cuentan
con estas condiciones.
Los clientes eliminados son referenciados mediante el campo “Eliminado”,
en el cual un valor “1” indica que este fue eliminado, y un valor “0” que aun
permanece vigente. Cuando se examinaron los registros de la tabla, para
muchos clientes no habia ningun valor asignado para este campo, lo cual,
segun comunico el encargado del sistema, se debia a que este se agrego
poco despues de haberse creado la base de datos inicial, razon por la cual
existian valores faltantes. Ademas, comento que en el sistema, si un cliente
posee en el campo “Eliminado” un valor “0” o un valor faltante, es
considerado como vigente.
Con respecto a la cuenta habilitada, el campo del OLTP que le hace
mencion es “Cta_Habilitada”, y un valor “0” indica que no esta habilitada y
un valor “1” que si.
Seguidamente, se expondra la sentencia SQL que contiene este paso:
Figura 5.28: Caso practico, CLIENTE - Obtener datos de OLTP.
Cargar CLIENTE: almacena en la tabla de dimension CLIENTE los datos
obtenidos en el paso anterior.
A continuacion, se especificara las tareas llevadas a cabo por "Carga de
Dimension PRODUCTO". Este paso es un contenedor de pasos, asi que
incluye las siguientes tareas:
Figura 5.29: Caso practico, Carga de Dimension PRODUCTO.
Obtener datos de OLTP: obtiene a traves de una consulta SQL los datos
del OLTP necesarios para cargar la dimension PRODUCTO.
Las fuentes que se utilizaran, son las tablas “Productos” y “Marcas”.
En este caso, aunque existian productos eliminados, las usuarias
decidieron que esta condicion no fuese tomada en cuenta, ya que habian
movimientos que hacian referencia a productos con este estado.
Es necesario realizar una union entre la tabla “Productos” y “Marcas”, por
lo cual se debio asegurar que ningun producto hiciera mencion a alguna
marca que no existiese, y se tomaron medidas contra su futura aparicion.
El SQL que contiene este paso es el siguiente:
Figura 5.30 : Caso practico, PRODUCTO - Obtener datos de OLTP.
Cargar PRODUCTO: almacena en la tabla de dimensión PRODUCTO los
datos obtenidos en el paso anterior.
A continuación, se especificarán las tareas llevadas a cabo por "Carga de
Dimensión FECHA". Este paso es un contenedor de pasos, así que incluye
las siguientes tareas:
Figura 5.31 : Caso practico, Carga de Dimension FECHA.
Para generar esta tabla de dimension, infaltable en todo DW, existen varias
herramientas y utilidades de software que proporcionan diversas opciones
para su confeccion. Pero, si no se cuenta con ninguna, se puede realizar
manualmente o mediante algun programa, llenando los datos en un
archivo, tabla, hoja de calculo, etc, y luego exportandolos a donde se
requiera.
Lo que se hizo, fue realizar un procedimiento que hace lo siguiente:
Recibe como parametros los valores de "Fecha_Desde" y "Fecha_Hasta".
Recorre una a una las fechas que se encuentran dentro de este intervalo.
Analiza cada fecha y realiza una serie de operaciones
para crear los valores de los campos de la tabla de la
dimension FECHA:

Figura 5.32: Caso practico, datos de FECHA.

o idFecha = YEAR(fecha)*10000 + MONTH(fecha)*100 +

DAY(fecha).
o Ano = 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 dimension FECHA.
Como puede observarse, la clave principal "idFecha" es un campo
numerico representado por el formato "yyyymmdd".
A continuacion, se especificara las tareas llevadas a cabo por "Carga de
Tabla de Hechos VENTAS". Este paso es un contenedor de pasos, asi que
incluye las siguientes tareas:
Figura 5.33: Caso practico, Carga de Tabla de Hechos VENTAS.
Obtener datos de OLTP: obtiene a traves de una consulta SQL los datos
del OLTP necesarios para cargar la tabla de hechos VENTAS.
Para la confeccion de la tabla de hechos, se tomaron como fuente las
tablas “Facturas_Ventas” y “Detalles_Venta”. Al igual que en las tablas de
dimensiones, se recolectaron las condiciones que deben cumplir los datos
para considerarse de interes, y en este caso, se trabajara solamente con
aquellas facturas que no hayan sido anuladas.
Se investigo al respecto, y se llego a la conclusion de que el campo que da
dicha informacion en “Anulada” de la tabla “Facturas_Ventas” y si el mismo
posee el valor “1” significa que efectivamente fue anulada.
Otro punto importante a tener en cuenta es que la fecha se debe convertir
al formato numerico “yyyymmdd”.
Se decidio aplicar una preagregacion a los hechos que formaran parte de
la tabla de hechos, es por esta razon que se utilizara la clausula GROUP
BY para agrupar todos los registros a traves de las claves primarias de
esta tabla.
La sentencia SQL que contiene este paso fue la siguiente:
Figura 5.34: Caso practico, VENTAS - Obtener datos de OLTP..
Cargar VENTAS: almacena en la tabla de hechos VENTAS los datos
obtenidos en el paso anterior.
5.5.4.2 b) Actualizacion
Cuando se haya cargado en su totalidad el DW, se deben establecer sus
politicas y estrategias de actualizacion o refresco de datos.
Una vez realizado esto, se tendran que llevar a cabo las siguientes acciones:
Especificar las tareas de limpieza de datos, calidad de datos, procesos
ETL, etc., que deberan realizarse para actualizar los datos del DW.
Especificar de forma general y detallada las acciones que debera realizar
cada software.
Caso practico:
Las politicas de Actualizacion que se han convenido con las usuarias son
las siguientes:
La informacion se refrescara todos los dias a las doce de la noche.
Los datos de las tablas de dimensiones “PRODUCTO” y “CLIENTE” seran
cargados totalmente cada vez.
Los datos de la tabla de dimension “FECHA” se cargaran de manera
incremental teniendo en cuenta la fecha de la ultima actualizacion.
Los datos de la tabla de hechos que corresponden al ultimo mes (30 dias)
a partir de la fecha actual, seran reemplazados cada vez.
Estas acciones se realizaran durante un periodo de prueba, para analizar
cual es la manera mas eficiente de generar las actualizaciones, basadas
en el estudio de los cambios que se producen en los OLTP y que afectan
al contenido del DW.
Para evitar que se extienda demasiado la aplicacion del ejemplo, el caso
practico solo incluira lo que deberia realizar el proceso ETL para actualizar
el DW.
El proceso ETL para la actualizacion del DW es muy similar al de Carga
Inicial, pero cuenta con las siguientes diferencias:
Inicio: iniciara la ejecucion de los pasos todos los dias a las doce de la
noche.
Establecer variables Fecha_Desde y Fecha_Hasta:
o La variable "Fecha_Desde" obtendra el valor resultante de restarle
a la fecha actual treinta dias.
o La variable "Fecha_Hasta" obtendra el valor de la fecha actual.
Carga de Dimension CLIENTE: a la serie de tareas que realiza este paso,
se le antecedera un nuevo paso que borrara los datos de la dimension
CLIENTE.
Carga de Dimension PRODUCTO: a la serie de tareas que realiza este
paso, se le antecedera un nuevo paso que borrara los datos de la
dimension PRODUCTO.
Carga de Dimension FECHA: en este paso, en vez de recibir el valor de la
variable "Fecha_Desde", se tomara la fecha del ultimo registro cargado en
la dimension FECHA.
Carga de Tabla de Hechos VENTAS:
o a la serie de tareas que realiza este paso, se le antecedera un
nuevo paso que borrara los datos de la tabla de HECHOS
correspondientes al intervalo entre "Fecha_Desde" y
"Fecha_Hasta".
o en el paso "Obtener datos de OLTP" se le agregara a la sentencia
SQL la siguiente condicion:
WHERE Facturas_Venta.Fecha >= {Fecha_Desde} AND
Facturas_Venta.Fecha <= {Fecha_Hasta}
1.6. Creacion de Cubos Multidimensionales
A continuacion se creara un cubo multidimensional de ejemplo, que sera llamado
”Cubo de Ventas” y que estara basado en el modelo logico disenado en el caso
practico de la metodologia Hefesto:
Figura 5.30: Caso practico, modelo logico.
La creacion de este cubo tiene las siguientes finalidades:

Ejemplificar la creacion de cubos multidimensionales.

Propiciar la correcta distincion entre hechos de una tabla de hechos e
indicadores de un cubo.

Propiciar la correcta distincion entre campos de una tabla de dimension y

atributos de un cubo.

5.6.1. Creacion de Indicadores

En este momento se crearan dos indicadores que seran incluidos en el cubo
”Cubo de Ventas”:

De la tabla de hechos “VENTAS”, se sumarizara el hecho “Cantidad” para

crear el indicador denominado:

o
“Unidades Vendidas”.
o
La formula utilizada para crear este indicador es la siguiente:
o
“Unidades Vendidas” = SUM(VENTAS.Cantidad).
o

De la tabla de hechos “VENTAS”,se sumarizara el hecho “MontoTotal”

para crear el indicador denominado:

o
“Monto Total de Ventas”.
o
La formula utilizada para crear este indicador es la siguiente:
o
“Monto Total de Ventas” = SUM(VENTAS.MontoTotal).
o
Entonces, el cubo quedaria conformado de la siguiente manera:
Figura 5.31: Cubo ejemplo, paso 1.
5.6.2. Creacion de Atributos
Ahora se crearan y agregaran al cubo seis atributos:

De la tabla de dimension “CLIENTE”, se tomara el campo “Cliente” para la

creacion del atributo denominado:
“Clientes”.
De la tabla de dimension “PRODUCTO”, se tomara el campo “Marca” para
la creacion del atributo denominado:
“Marcas”.
De la tabla de dimension “PRODUCTO”, se tomara el campo “Producto”
para la creacion del atributo denominado:
“Productos”.
De la tabla de dimension “FECHA”, se tomara el campo “Ano” para la
creacion del atributo denominado:
“Anos”.
De la tabla de dimension “FECHA”, se tomara el campo “Trimestre” para
la creacion del atributo denominado:
“Trimestres”.
De la tabla de dimension “FECHA”, se tomara el campo “Mes” para la
creacion del atributo denominado:
“Meses”.
Entonces, el cubo quedaria conformado de la siguiente manera:
Figura 5.32: Cubo ejemplo, paso 2.
5.6.3. Creacion de Jerarquias
Finalmente se crearan y agregaran al cubo dos jerarquias:

Se definio la jerarquia “Jerarquia Productos”, que se aplicara sobre los

atributos recientemente creados, “Marcas” y “Productos”, en donde:

o
Un producto en especial pertenece solo a una marca. Una marca
puede tener uno o mas productos.
o
Graficamente:
Figura 5.33: “PRODUCTO”, relacion padre-hijo.
Se definio la jerarquia “Jerarquia Fechas”, que se aplicara sobre los
atributos recientemente creados, “Anos”, “Trimestres” y “Meses”, en
donde:
o
Un mes del ano pertenece solo a un trimestre del ano. Un trimestre
del ano tiene uno o mas meses del ano.
o
o
Un trimestre del ano pertenece solo a un ano. Un ano tiene uno o
mas trimestres del ano.
o
Graficamente:
Figura 5.34: “FECHA”, relacion padre-hijo.
Entonces, el cubo quedaria conformado de la siguiente manera:
Figura 5.35: Cubo ejemplo, paso 3.
5.6.4. Otros ejemplos de cubos multidimensionales
A partir del modelo logico planteado, podrian haberse creado una gran cantidad
de cubos, cada uno de los cuales estaria orientado a un tipo de analisis en
particular. Tal y como se explico antes, estos cubos pueden coexistir sin ningun
inconveniente.
A continuacion se expondran una serie de cubos de ejemplo:

Cubo 1:

Figura 5.36: Cubo 1, ejemplo

Cubo 2:

Figura 5.37: Cubo 2, ejemplo.

Cubo 3:

Figura 5.38: Cubo 3, ejemplo