U N I V E R S I D A D N A C I O N A L J O S É F.

SÁNCHEZ CARRIÓN

FACULTAD DE INGENIERÍA INDUSTRIAL,

SISTEMAS E INFORMÁTICA

ESCUELADEINGENIERÍAINFORMÁTICA

METODOLOGIA HEFESTO

P R O F.: I N G . PIERRE PAUL

LONCAN SALAZAR

Monografía q u e c o m o p a r t e d e
l a a s i g n a t u r a d e INTELIGENCIA DE
NEGOCIOS

presenta el alumno:

Yanac Carrasco, Ansoni Daniel

OCTUBR E , 2019

1
 ÍN D I C E

1. Resumen…………………………………………………………………………………………………………….3

MARCO TEORICO

2. Introducción………………………………………………………………………………………………………...5
3. Descripción………………………………………………………………………………………………………....6
4. Características……………………………………………………………………………………………………..6

CASO APLICADO

5. Empresa analizada………………………………………………………………………………………………..8
6. Paso 1) Análisis de Requerimientos……………………………………………………………………………10
6.1. 1.1) Preguntas de Negocio………………………………………………………………………………...10
6.2. 1.2) Indicadores y Perspectivas…………………………………………………………………………...11
6.3. 1.3) Modelo Conceptual…………………………………………………………………………………….12
7. Paso 2) Análisis de Data Sources………………………………………………………………………………14
7.1. 2.1) Hechos e Indicadores………………………………………………………………………………….14
7.2. 2.2) Mapeo…………………………………………………………………………………………..……….15
7.3. 2.3) Granularidad…………………………………………………………………………………………….16
7.4. 2.4) Modelo Conceptual Ampliado………………………………………………………………….………20
8. Paso 3) Modelo Lógico del DW…………………………………………………………………………………..21
8.1. 3.1) Tipología………………………………………………………………………………………………….21
8.2. 3.2) Tablas de
Dimensiones………………………………………………………………………………………………….23
8.3. 3.3) Tablas de Hechos………………………………………………………………………………………26
8.4. 3.4) Uniones………………………………………………………………………………………………….27
9. Cubo Multidimensional………………………………………………………………………………………...…34

2
1. Resumen

En la segunda parte de esta publicación se presenta la metodología HEFESTO para la construcción

de un Data Warehouse. El principal objetivo de la metodología HEFESTO es facilitar el arduo trabajo
que significa construir un Data Warehouse desde cero, aportando información que permitirá mejorar
su performance. La metodología está orientada a amortiguar el tedio que provoca seguir pasos sin
comprender el por qué de su ejecución. La metodología tiene como punto de partida la recolección
de requerimientos y necesidades de información de l@s usuari@s y concluye con la confección de
un esquema lógico y sus respectivos procesos de extracción, transformación y carga de datos. Se
ejemplificará cada etapa de la metodología a través de su aplicación a una empresa real, que servirá
de guía para la visualización de los resultados esperados en cada paso y para clarificar los
conceptos enunciados. Se describirán los aspectos sobresalientes de la metodología y se detallará
cada paso con su respectiva aplicación. Se expondrán tópicos que deben tenerse en cuenta al
momento de construir e implementar un Data Warehouse. Se sumará a lo anterior, la creación de
Cubos Multidimensionales basados en el DW resultante del caso práctico que se desarrolló
anteriormente.

3
MARCO TEORICO

4
 2. Introducción
En esta sección se presentará la metodología HEFESTO, que permitirá la construcción de Data
Warehouse de forma sencilla, ordenada e intuitiva. Su nombre fue inspirado en el dios griego de la
construcción y el fuego, y su logotipo es el siguiente:

HEFESTO es una metodología, cuya propuesta está fundamentada en una extensa investigación,
comparación de metodologías existentes y el aporte de experiencias propias en procesos de diseño e
implementación de DW. Cabe destacar que HEFESTO está en continua evolución, y se han tenido en
cuenta, como gran valor agregado, todos los feedbacks que han aportado quienes han utilizado esta
metodología en diversos países y con diversos fines. Es fundamento de esta metodología infundir en
l@s lector@s una idea cabal sobre cada paso que se plantea, de tal forma que en tiempo de
aplicación se posea argumentos sólidos para defender y sostener la implementación y además, ser
capaces de plantear nuevos interrogantes que aporten valor extra al trabajo y a la metodología. Es
deseo de quienes escribimos este libro, que esta metodología siga creciendo y evolucionando con
aportes diversos en cuanto a saberes, experiencias y condiciones. La base de dedicar tiempo en
escribir un libro y luego publicarlo de forma libre es la compartir conocimiento, sin embargo, es muy
importante que este conocimiento NO sea estático, y la forma en que este conocimiento se mantenga
en movimiento y constante crecimiento, es sin duda el aporte de la comunidad. La metodología
HEFESTO puede adaptarse muy bien a cualquier ciclo de vida de desarrollo de software. Lo que se
busca, es entregar una primera implementación que satisfaga una parte de las necesidades, para
demostrar las ventajas del DW y motivar a l@s usuari@s. Se acompañará cada desarrollo teórico con
una implementación basada en una empresa real a fin de mostrar los resultados que se deben
obtener y ejemplificar cada concepto de forma concreta y contundente.

3. Descripción
HEFESTO está compuesto por los siguientes pasos:

 1) ANÁLISIS DE REQUERIMIENTOS
o 1.1) Preguntas del Negocio
o 1.2) Indicadores y Perspectivas
o 1.3) Modelo Conceptual
 2) ANÁLISIS DE DATA SOURCES
o 2.1) Hechos e Indicadores
o 2.2) Mapeo
o 2.3) Granularidad
o 2.4) Modelo Conceptual Ampliado
 3) MODELO LÓGICO DEL DW
o 3.1) Tipología
o 3.2) Tablas de Dimensiones
o 3.3) Tablas de Hechos
o 3.4) Uniones
 4) INTEGRACIÓN DE DATOS
o 4.1) Carga Inicial
5
 o 4.2) Actualización

Como ya se planteó en el apartado anterior, la metodología Hefesto, se inicia con la recolección de

las necesidades de información de l@s usuari@s y de esta manera se obtienen las preguntas claves
del negocio. Luego, se deben identificar los Indicadores resultantes de los interrogantes realizados y
sus respectivas Perspectivas de análisis, a través de las cuales se construirá el modelo conceptual de
datos del DW.

Después, se analizarán los Data Sources en pos de determinar cómo se construirán los Indicadores,
señalando el mapeo correspondiente y seleccionando los campos de estudio de cada Perspectiva.

Una vez realizado esto, se pasará a la construcción del Modelo Lógico del DW, en donde se definirá
cuál será el tipo de esquema que se implementará.

Seguidamente, se confeccionarán las tablas de Dimensiones y las tablas de Hechos, para luego
efectuar sus respectivas uniones.

Finalmente, utilizando técnicas de limpieza y calidad de datos, procesos ETL, etc, se definirán
políticas y estrategias para la Carga Inicial del DW y su respectiva Actualización.

4. Características
La metodología HEFESTO posee las siguientes características:

 Los objetivos y resultados esperados en cada fase se distinguen fácilmente y son sencillos de
comprender.
 La piedra fundamental la constituyen los requerimientos de l@s usuari@s, por lo cual, se
adapta con facilidad y rapidez a los cambios del negocio.
 Reduce drásticamente la resistencia al cambio, ya que involucra a l@s usuari@s finales en
cada etapa para que tomen decisiones respecto al comportamiento y funciones del DW, y
además expone resultados inmediatos.
 Utiliza modelos conceptuales y lógicos, los cuales son sencillos de interpretar y analizar.
 Es independiente del tipo de ciclo de vida que se emplee para contener la metodología.
 Es independiente del software/hardware que se utilicen para su implementación.
 Cuando se culmina con una fase, los resultados obtenidos se constituyen en la entrada de la
fase siguiente.
 Se aplica en Data Warehouse y en Data Mart.

6
CASO APLICADO

7
 5. Empresa Analizada
Antes de comenzar con el primer paso, es menester describir las características principales de la
empresa a la cual se le aplicará la metodología HEFESTO, así se podrá tener como base un ámbito
predefinido y se comprenderá cada decisión que se tome con respecto al diseño del DW.

Además, este análisis ayudará a conocer el funcionamiento y accionar de la empresa, lo que

permitirá examinar e interpretar de forma óptima las necesidades de información de la misma.

Identificación de la empresa
La empresa analizada, desarrolla las actividades comerciales de mayorista y minorista de artículos de
limpieza, en un ambiente geográfico de alcance nacional. De acuerdo a su volumen de operaciones,
se la puede considerar de tamaño mediano.

Con respecto a su clasificación, es una sociedad de responsabilidad limitada con fines de lucro.

Su estructura está formalizada y posee características de una organización funcional.

Objetivos
Su objetivo principal es el de maximizar sus ganancias. Pero también, se puede adicionar el objetivo
de expandirse a un nuevo nivel de mercado, con el fin de conseguir una mayor cantidad de client@s
y posicionarse competitivamente por sobre sus rivales.

Otra meta que persigue, pero que aún no está definida como tal, es la de incursionar en otros rubros
para lograr diversificarse.

Políticas
La empresa posee pocos grandes clientes con un gran poder adquisitivo, y son precisamente estos,
los que adquieren el volumen de los productos que se comercializan. Debido a ello, la política que se
utiliza para cubrir los objetivos antes mencionados, es la de satisfacer ampliamente las necesidades
de sus client@s, brindándoles confianza y promoviendo un ambiente familiar entre l@s mism@s.
Esta acción se realiza con el fin de mantener l@s client@s actuales y para que los nuev@s se
interesen en su forma de operar.

Existe otra política que es implícita, por lo cual, no está definida tan estrictamente como la anterior, y
es la de mejorar continuamente, con el objetivo de sosegar las exigencias y cambios en el mercado
en el que actúa y para conseguir una mejor posición respecto a sus competidor@s.

Estrategias
Dentro de las estrategias existentes, se han destacado dos por considerarse más significativas, ellas
son:
Expandir el ámbito geográfico, creando varias sucursales en puntos estratégicos del país.
Añadir nuevos rubros a su actividad de comercialización.

Organigrama
A continuación, se expondrá un organigrama que fue confeccionado a partir de los datos
suministrados en la empresa, ya que no existía ninguno previamente predefinido.

8
 Datos del entorno específico
L@s client@s con que cuenta son bastantes variad@s y cubren un amplio margen. L@s mism@s
son tanto provinciales, como nacionales, con diferentes tipos de poder adquisitivo.

Con respecto a sus proveedor@s, la empresa posee en algunos rubros diversas opciones de las
cuales puede elegir y comparar, pero en otros solo cuenta con pocas alternativas.

Además, tiene como rivales a nivel de mayoreo, vari@s competidor@s importantes y ya

consolidad@s en el mercado, pero, a nivel minorista aventaja por su tamaño y volumen de
actividades a sus principales competidor@s.

Relación de las metas de la organización con

las del DWH
El DWH coincide con la metas de la empresa, ya que ésta necesita mejorar su eficiencia en la toma
de decisiones y contar con información detallada a tal fin. Esto es vital, ya que es muy importante
para procurar una mayor ventaja competitiva conocer cuáles son los factores que inciden
directamente sobre su rentabilidad, como así también, analizar su relación con otros factores y sus
respectivos por qué.

El DWH aportará un gran valor a la empresa; entre las principales ventajas e inconvenientes que
solucionará se pueden mencionar los siguientes:

9
  Permitirá a l@s usuari@s tener una visión general del negocio.
 Transformará datos operativos en información analítica, enfocada a la toma de decisiones.
 Se podrán generar reportes dinámicos, ya que actualmente son estáticos y no ofrecen
ninguna facilidad de análisis.
 Soportará la estrategia de la empresa.
 Aportará a la mejora continua de la estructura de la empresa.

Procesos
Los principales procesos que se llevan a cabo son los siguientes:

 Venta:
o Minorista: es la que se le realiza a l@s client@s particulares que se acercan hasta
la empresa para adquirir los productos que requieren.
o Mayorista: es la que se le efectúa a l@s grandes client@s, ya sea por medio de
comunicaciones telefónicas, o a través de visitas o reuniones.

Al realizarse una venta, el departamento de Depósito se encarga de controlar el stock,

realizar encargos de mercadería en caso de no cubrir lo solicitado, armar el pedido y
enviarlo por medio de transporte propio o de tercer@s al destino correspondiente.

 Compra:

El departamento de Compras, al recibir del departamento de Depósito las necesidades de

mercadería, realiza una comparación de los productos ofrecidos por sus diferentes
proveedor@s en cuestión de precio, calidad y confianza. Posteriormente, se efectúa el
pedido correspondiente.

6. Paso 1. Análisis de Requerimientos

1.1. Preguntas del Negocio
El primer paso comienza con el acopio de las necesidades de información, el cual puede
llevarse a cabo a través de variadas y diferentes técnicas, cada una de las cuales
poseen características inherentes y específicas, como por ejemplo: entrevistas,
cuestionarios, observaciones, etc.

El Análisis de los Requerimientos de l@s diferentes usuari@s, es el punto de partida de

esta metodología, ya que ell@s son l@s que deben, en cierto modo, guiar la
investigación hacia un desarrollo que refleje claramente lo que se espera del DW, en
relación a sus funciones y cualidades.

El objetivo principal de esta fase, es la de obtener e identificar las necesidades de

información clave de alto nivel, que es esencial para lograr las metas y ejecutar las
estrategias de la empresa, además facilitará que la toma de decisiones sea eficaz y
eficiente.

Debe tenerse en cuenta que las necesidades de la información que será recolectada, es la
que proveerá el soporte para desarrollar los pasos sucesivos, por lo cual, es muy
importante que se preste especial atención al relevamiento inicial.

Una forma de asegurarse de que se ha realizado un buen análisis, es corroborar que el

resultado del mismo haga explícitos los objetivos estratégicos planteados por la
empresa que se está estudiando.

Otra forma de encaminar el relevamiento, es enfocar las necesidades de información en

10
 los procesos principales que desarrolle la empresa en cuestión.

La idea central es, que se formulen preguntas complejas sobre el negocio, que incluyan
variables de análisis que se consideren relevantes, ya que son estas las que
permitirán estudiar la información desde diferentes Perspectivas.

Un punto importante que debe tenerse muy en cuenta, es que la información debe estar
soportada de alguna manera por algún Data Source, ya que de otra forma, no se
podrá elaborar el DW.

Caso práctico
En las primeras entrevista se indagó a l@s usuari@s 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 Data Source.

El proceso elegido fue el de Ventas.

Una vez seleccionado el proceso, se comenzó a identificar qué era lo que les interesaba
conocer acerca de este proceso y cuáles eran las variables o Perspectivas que deben
tenerse en cuenta en los análisis en pos de la toma de decisiones.

Se les preguntó cuáles eran, a su criterio, los Indicadores más representativos del proceso
de Ventas y cuál es el análisis que se desea realizar. La respuesta arrojó como
resultado que la cantidad de unidades vendidas y el monto total de ventas son los
números más relevantes en este proceso.

Luego se les preguntó cuáles serían las Perspectivas desde las cuales se consultarán
dichos Indicadores. Para simplificar esta tarea se les presentó una serie de ejemplos
concretos de otros casos similares.

Las Preguntas de Negocio obtenidas fueron las siguientes:

Se desea conocer cuántas 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 cuál 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 Dimensión Tiempo es un elemento fundamental en el DW, se hizo
hincapié en él. Además, se puso mucho énfasis en dejar en claro a l@s usuari@s, a
través de ejemplos prácticos, que es este componente el que permitirá tener varias
versiones de los datos a fin de realizar un correcto análisis posterior.

Como se puede apreciar, las necesidades de información expuestas armonizan con

los objetivos y estrategias de la empresa, ya que es precisamente esta información la
que proveerá un ámbito para la toma de decisiones, que en este caso permitirá
analizar el comportamiento de l@s client@s a quienes que se pretende satisfacer
ampliamente, para así lograr obtener una ventaja competitiva y maximizar las
ganancias.
1.2. Indicadores y perspectiva
Una vez que se han establecido las preguntas de negocio, se debe proceder a su
descomposición para descubrir los Indicadores que se utilizarán y las Perspectivas de
11
 análisis que intervendrán.

Para ello, se debe tener en cuenta que los Indicadores, son valores numéricos y
representan lo que se desea analizar concretamente, por ejemplo: saldos, importes,
promedios, cantidades, sumatorias, fórmulas, etc.

En cambio, las Perspectivas se refieren a las entidades mediante los cuales se

quieren examinar los Indicadores, con el fin de responder a las preguntas planteadas,
por ejemplo: clientes, proveedores, sucursales, países, productos, rubros, etc. Cabe
destacar, que el Tiempo suele considerarse comúnmente como una Perspectiva.

Caso práctico
A continuación, se analizarán las preguntas obtenidas en el paso anterior y se
detallarán cuáles son sus Indicadores y Perspectivas.

Los Indicadores son:

 Unidades vendidas
 Monto total de ventas
Y las Perspectivas de Análisis son:

 Clientes
 Productos
 Tiempo
1.3. Modelo Conceptual
En esta etapa, se construirá un Modelo Conceptual a partir de los Indicadores y Perspectivas
obtenidas en el paso anterior.

Un Modelo Conceptual es una 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 través de este Modelo, se podrá observar con claridad cuáles son los alcances del proyecto, para
luego poder trabajar sobre ellos. Además, al poseer un alto nivel de definición de los datos, permite
que pueda ser presentado ante l@s usuari@s y explicado con facilidad.

La representación gráfica del Modelo Conceptual es la siguiente:

12
  A la izquierda se colocan las Perspectivas seleccionadas, que serán unidas a
 un óvalo central que representa y lleva el nombre de la Relación que existe entre ellas;
 la Relación, constituye el proceso o área de estudio elegida;
 de dicha Relación y entrelazadas con flechas, se desprenden hacia
la derecha los Indicadores.

El Modelo Conceptual permite de un solo vistazo y sin poseer demasiados conocimientos previos,
comprender cuáles serán los resultados que se obtendrán, cuáles serán las variables que se
utilizarán para analizarlos y cuál es la relación que existe entre ellos.

Caso Práctico

El Modelo Conceptual resultante de los datos que se han recolectado, es el siguiente:

13
Como puede observarse, la Relación mediante la cual se unen las diferentes Perspectivas, para
obtener como resultado los Indicadores requeridos por l@s usuari@s, es precisamente Venta.

7. Paso 2. Análisis de Datasources

Se analizarán los Data Sources para determinar cómo serán calculados los Indicadores y para
establecer el mapeo entre el Modelo Conceptual creado en el paso anterior y los datos de la
empresa. Se definirán qué campos se incluirán en cada Perspectiva. Y se ampliará el modelo
conceptual con la información obtenida en este paso.

2.1. Hechos e Indicadores

En este paso se deberán explicitar cómo se calcularán los Indicadores, definiendo los
siguientes conceptos para cada uno de ellos:

 Hecho/s que lo componen, con su respectiva fórmula de cálculo. Por ejemplo: Hecho1 +
Hecho2
 Función de agregación que se utilizará. Por ejemplo: SUM, AVG, COUNT, etc.
Caso práctico
Los Indicadores se calcularán de la siguiente manera:

Indicador: Unidades Vendidas:

Hechos: Unidades Vendidas
Función de agregación: SUM
Aclaración: el Indicador Unidades Vendidas representa la sumatoria de las unidades que se
han vendido de un producto en particular.

Indicador: Monto Total de Ventas:

Hechos: (Unidades Vendidas) * (Precio de Venta)
Función de agregación: SUM
Aclaración: 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.

14
2.2. Mapeo
En este paso debemos examinar los Data Sources e indentificar sus características
propias, y asegurarnos que los Data Sources disponibles contengan los datos requeridos.

Luego, debemos establecer cómo serán obtenidos los elementos que hemos definido
en el Modelo Conceptual, estableciendo de esta manera una correspondencia directa
entre elementos del Modelo Conceptual y Data Sources.

En el Data Source de la empresa analizada, el proceso de venta está representado

por el siguiente Diagrama de Entidad Relación (representa la información a través de
Entidades, Relaciones, Cardinalidades, Claves, Atributos y Jerarquías de generalización):

15
 A continuación, se expondrá el Mapeo entre los dos Modelos:

El Mapeo realizado es el siguiente:

 La Perspectiva Productos se relaciona con tabla Productos.

 La Perspectiva Clientes se relaciona con la tabla Clientes.

 La Perspectiva Tiempo se relaciona con el campo fecha de la tabla

Facturas_Venta, debido a que es la fecha principal en el proceso de venta.

 El Indicador Unidades Vendidas se relaciona con el campo cantidad de la

tabla Detalles_Venta, quedando la fórmula de cálculo como sigue:

SUM( cantidad )

 El Indicador Monto Total de Ventas se relaciona con los campos cantidad y

precio_Fact de la tabla Detalles_Venta. quedando la fórmula de cálculo como
sigue:

SUM( cantidad * precio_Fact )

2.3. Granularidad
Una vez que se han establecido el Mapeo con los Data Sources, se deben seleccionar
los campos que contendrá cada Perspectiva, ya que a través de estos se analizarán
los Indicadores.

Para ello, basándose en el Mapeo establecido en el paso anterior, se debe presentar a

l@s usuari@s los datos de análisis disponibles para cada Perspectiva. Es muy
importante conocer en detalle que significa cada campo y/o valor de los datos
encontrados en los Data Sources, por lo cual, es conveniente investigar su sentido, ya
16
sea a través de diccionarios de datos, reuniones con l@s encargad@s del sistema,
análisis de los datos propiamente dichos, etc.

Luego de exponer frente a l@s usuari@s los datos existentes, explicando su

significado, valores posibles y características, est@s deben decidir cuáles son los que
consideran relevantes para consultar los Indicadores y cuales NO.

Con respecto a la Perspectiva Tiempo, es muy importante definir los períodos mediante
los cuales se agregarán los datos. Sus campos posibles pueden ser: día de la semana,
quincena, mes, trimestres, semestre, año, etc.

Se debe prestar especial atención al momento de seleccionar los campos que

integrarán cada Perspectiva, ya que son estos campos los determinarán la
Granularidad de los datos en el DW.

Caso Práctico

De acuerdo al Mapeo realizado, se analizaron los campos que constituyen cada tabla a
la que se hace referencia a través de dos métodos diferentes. Primero se inspeccionó
la base de datos intentando intuir los significados de cada campo, y luego se consultó
quién es administrador del sistema para indagar acerca de una serie de aspectos que
NO estaban claros. En este caso, los nombres de los campos eran bastante explícitos,
pero aún así fue necesario investigarlos para evitar cualquier tipo de inconvenientes.
Con respecto a la Perspectiva Clientes, los datos disponibles son los siguientes:

id_Cliente: es la clave primaria de la tabla Clientes, y representa unívocamente a un

cliente en particular.

Codigo: representa el código del cliente, este campo es calculado de acuerdo a una
combinación de las iniciales del nombre del cliente, el grupo al que pertenece y un
número incremental.

Razon_Soc: nombre o razón social del cliente.

Telefono1: número de teléfono del cliente.

Telefono2: segundo número telefónico del cliente.

Fax1: número de fax del cliente.

Fax2: segundo número de fax del cliente.

Mail1: dirección de correo electrónico del cliente.

Mail2: segunda dirección de correo del cliente.

id_Sit_Fiscal: representa a través de una clave foránea el tipo de situación fiscal que
posee el cliente. Por ejemplo: Consumidor Final, Exento, Responsable No Inscripto,
Responsable Inscripto.

CUIT: número de C.U.I.T. (Código Único de Identificación Tributaria) del cliente.

ConvenioMultilateral: indica si el cliente posee o no convenio multilateral.

DGR: número de D.G.R. (Dirección General de Rentas) del cliente.

id_Clasificación: representa a través de una clave foránea la clasificación del cliente.

Por ejemplo: Muy Bueno, Bueno, Regular, Malo, Muy Malo.
17
id_Nota: representa a través de una clave foránea una observación realizada acerca
del cliente.

Cta_Habilitada: indica si el cliente posee su cuenta habilitada.

id_Rubro: representa a través de una clave foránea el grupo al que pertenece el

cliente. Por ejemplo: Bancos, Construcción, Educación Privada, Educación Pública,
Particulares.

idCuentaContable: representa la cuenta contable asociada al cliente, la cual se utilizará

para imputar los movimientos contables que este genere.

Eliminado: indica si el cliente fue eliminado o NO. Si fue eliminado, no figura en las
listas de clientes actuales. Es una baja lógica.

En la Perspectiva Productos, los datos que se pueden utilizar son los siguientes:

id_prod: es la clave primaria de la tabla ”Productos”, y representa unívocamente a un

producto en particular.

stock: stock actual del producto.

stock_min: stock mínimo del producto, se utiliza para emitir un alerta si el stock actual
está cerca de este valor o es menor.

Precio: precio de venta del producto.

Detalle: nombre o descripción del producto.

id_Rubro: representa a través de una clave foránea el rubro al que pertenece el

producto.

id_Marca: representa a través de una clave foránea la marca a la que pertenece el

producto.

stock_MAX: stock máximo del producto. Al igual que ”stock_min”, se utiliza para dar
alertas del nivel de stock actual.

tipo: clasificación del producto. Por ejemplo: Producto, Servicio, Compuesto.

Costo: costo del producto.

codigo: representa el código del producto, este campo es calculado de acuerdo a una
combinación de las iniciales del nombre del producto, el rubro al que pertenece y un
número incremental.

Imagen: ruta a un archivo de tipo imagen que representa al producto. Este campo NO
es utilizado actualmente.

Generico: indica si el producto es genérico o no.

Eliminado: indica si el producto fue eliminado o NO. Si fue eliminado, NO se visualiza

en las listas de productos actuales. Es una baja lógica.

PrecioR: precio de lista del producto.

18
Con respecto a la Perspectiva Tiempo, que es la que determinará la granularidad del
DW, los datos más típicos que pueden emplearse son los siguientes:

Año

Semestre

Cuatrimestre

Trimestre

Número de mes

Nombre del mes

Quincena

Semana

Número de día

Nombre del día

Una vez finalizada la recolección de la información pertinente y consultados l@s

usuari@s sobre los datos que consideraban de interés para analizar los Indicadores,
los resultados obtenidos fueron los siguientes:

Perspectiva Clientes:

Razon_Soc de la tabla Clientes. Ya que este hace referencia al nombre del cliente.

Perspectiva Productos: detalle de la tabla Productos. Ya que este hace referencia al

nombre del producto. Nombre de la tabla Marcas. Ya que esta hace referencia a la
marca a la que pertenece el producto. Este campo es obtenido a través de la unión con
la tabla Productos.

Perspectiva Tiempo:

Mes, referido al nombre del mes.

Trimestre.

Año.

19
2.4. 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 debajo de cada Perspectiva los campos
seleccionados y debajo de cada Indicador su respectiva fórmula de cálculo.

Caso Práctico

Se ampliará el diseño del Diagrama Conceptual:

20
 8. Paso 3. Modelo Lógico del DW
A continuación, se confeccionará el Modelo Lógico de la estructura del DW, teniendo como
base el Modelo Conceptual que ya ha sido creado. Un Modelo Lógico es la representación de
una estructura de datos, que puede procesarse y almacenarse en algún SGBD. Inicialmente,
se definirá el tipo de Modelo Lógico que se utilizará y luego se diseñarán las tablas de
Dimensiones y de Hechos con sus respectivas relaciones.

3.1. Tipología

Debemos seleccionar el tipo de Esquema que mejor se adapte a los requerimientos y

necesidades de l@s usuari@s. El Modelo Lógico seguirá este esquema.

Es muy importante definir objetivamente si se empleará un Esquema en Estrella, Copo de

Nieve o Constelación, ya que esta decisión afectará considerablemente la elaboración del
Modelo Lógico.

Caso práctico

Se ha seleccionado el Esquema en Estrella ya que cumple con los requerimientos planteados

y es simple de implementar y comprender.

3.2. Tablas de Dimensiones

En este paso diseñaremos las tablas de Dimensiones que formarán parte del DW.

Para los tres tipos de Esquemas, cada Perspectiva definida en el Modelo Conceptual se constituirá
en una tabla de Dimensión. Para ello, a partir de cada Perspectiva y sus campos debe realizarse el
siguiente proceso:

 Se elegirá un nombre que identifique la tabla de Dimensión.

 Se añadirá un campo que represente su clave principal.
 Se redefinirán los nombres de los campos si es que no son lo suficientemente intuitivos.

Gráficamente:

Para los Esquemas Copo de nieve, cuando existan Jerarquías dentro de una tabla de Dimensión,
esta tabla deberá ser normalizada. Por ejemplo, se tomará como referencia la siguiente tabla de
Dimensión y su respectivas relaciones padre-hijo entre sus campos:

21
Entonces, al normalizar esta tabla se obtendrá:

Caso práctico

A continuación, se diseñaran las tablas de Dimensiones.

Perspectiva Clientes:

 La nueva tabla de Dimensión tendrá el nombre dimClientes.

 Se le agregará una clave principal con el nombre idCliente.
 Se modificará el nombre del campo Razon_Soc por cliente.

Perspectiva Productos:

 La nueva tabla de Dimensión tendrá el nombre dimProductos.

 Se le agregará una clave principal con el nombre idProducto.
 Se modificará el nombre del campo Marca por marca.
 Se modificará el nombre del campo Detalle por producto.

22
 Perspectiva Tiempo:

 La nueva tabla de Dimensión tendrá el nombre dimFechas.

 Se le agregará una clave principal con el nombre idFecha.
 Se modificará el nombre del campo Año por anio.
 Se modificará el nombre del campo Trimestre por trimestre.
 Se modificará el nombre del campo Mes por mes.

3.3. Tabla de Hechos

En este paso, se definirán las tablas de Hechos.

Esquemas en Estrella y Copo de Nieve

Para los Esquemas en Estrella y Copo de Nieve, se realizará lo siguiente:

 Se le deberá asignar un nombre a la tabla de Hechos que represente la información que

contiene, área de investigación, negocio enfocado, etc.
 Se definirá su clave primaria, que se compone de la combinación de las claves primarias de
cada tabla de Dimensión relacionada.
 Se crearán tantos campos de Hechos como Indicadores se hayan definido en el modelo
conceptual y se les asignará un nombre.

23
 Esquemas Constelación

Para los Esquemas Constelación se realizará lo siguiente:

 Las tablas de Hechos se deben confeccionar teniendo en cuenta el análisis de las preguntas
realizadas por l@s usuari@s en pasos anteriores y sus respectivos Indicadores y
Perspectivas.
 Cada tabla de Hechos debe poseer un nombre que la identifique y su clave debe estar
formada por la combinación de las claves de las tablas de Dimensiones relacionadas.

Al diseñar las tablas de Hechos, se deberá tener en cuenta:

Caso 1:

Si en dos o más preguntas de negocio figuran los mismos Indicadores pero con diferentes
Perspectivas de análisis, existirán tantas tablas de Hechos como preguntas cumplan esta condición.
Por ejemplo:

Entonces se obtendrá:

24
 Caso 2:

Si en dos o más preguntas de negocio figuran diferentes Indicadores con diferentes Perspectivas de
análisis, existirán tantas tablas de Hechos como preguntas cumplan esta condición. Por ejemplo:

Entonces se obtendrá:

Caso 3:

Si el conjunto de preguntas de negocio cumplen con las condiciones de los dos puntos anteriores se
deberán unificar aquellos interrogantes que posean diferentes Indicadores pero iguales Perspectivas
de análisis, para luego reanudar el estudio de las preguntas. Por ejemplo:

Se unificarán en:

Caso práctico

A continuación, se confeccionará la tabla de Hechos:

 La tabla de Hechos tendrá el nombre factVentas.

 Su clave principal será la combinación de las claves principales de las tablas de Dimensiones
antes definidas: idCliente, idProducto e idFecha.
 Se crearán dos Hechos, que se corresponden con los dos Indicadores:

 Unidades Vendidas será renombrado como cantidad y

25
  Monto Total de Ventas será renombrado como montoTotal.

3.4. Tabla de Uniones

Para los tres tipos de Esquemas, se realizarán las uniones correspondientes entre sus
tablas de Dimensiones y sus tablas de Hechos.

Caso práctico

Se realizarán las uniones necesarias según corresponda:

26
 9. Paso 4. Integración de Datos
Una vez construido el Modelo Lógico, se deberá proceder a poblarlo con datos, utilizando
técnicas de limpieza y calidad de datos, procesos ETL, etc.

Luego se definirán las reglas y políticas de actualización, así como también los procesos que
la llevarán a cabo.

4.1. Carga Inicial

Debemos en este paso realizar la Carga Inicial del DW, poblando el modelo construido en pasos
anteriores. Para lo cual debemos llevar adelante una serie de tareas básicas, tales como asegurar la
limpieza y calidad de los datos, procesos ETL, etc.

En muchos casos, las tareas antes mencionadas tienen una lógica compleja. Afortunadamente, en la
actualidad existen muchas herramientas de software que se pueden emplear y que nos facilitan en
gran parte el trabajo.

Se debe evitar que el DW sea cargado con Missing Values (valores faltantes), Outliers (datos
anómalos) o faltos de integridad; se deben establecer condiciones y restricciones para asegurar que
solo se utilicen los datos de interés.

Cuando se trabaja con un Esquema Constelación, hay que tener presente que varias tablas de
Dimensiones serán compartidas con diferentes tablas de Hechos. Puede darse el caso que algunas
restricciones aplicadas sobre una tabla de Dimensión para analizar una tabla de Hechos, se
contrapongan con otras restricciones o condiciones de análisis de otras tablas de Hechos.

Primero se cargarán los datos de las Dimensiones y luego los de las tablas de Hechos. En el caso en
que se esté utilizando un Esquema Copo de Nieve, cada vez que existan Jerarquías de Dimensiones,
se comenzarán cargando las tablas de Dimensiones del nivel más general al más detallado. Esto se
debe a la existencia de claves foráneas y se realiza para evitar problemas de rechazo de datos por
parte del SGBD.

Concretamente, en este paso se deberán registrar en detalle las acciones llevadas a cabo con los
diferentes Software de Integración de datos. Por ejemplo, es común que sistemas ETL trabajen
con Pasos y Relaciones, en donde cada Paso realiza una tarea en particular del Proceso ETL y
cada Relación indica hacia donde debe dirigirse el flujo de datos.

Se debe especificar:

 qué hace el proceso en general y luego

 qué hace cada Paso y Relación.

Es decir, se partirá de lo más general y se irá a lo más específico, para obtener de esta manera una
visión general y detallada de todo el proceso.

Es importante tener presente, que al cargar los datos en las tablas de Hechos pueden utilizarse
preagregaciones con el mismo nivel de granularidad o con niveles menores.

Caso práctico

Para simplificar la aplicación del ejemplo, el caso práctico solo se centrará en los aspectos
más importantes del Proceso ETL, obviando entrar en detalle de cómo se realizan algunas
funciones y/o pasos.

27
 Proceso ETL Principal

El Proceso ETL principal planteado para la Carga Inicial es el siguiente:

Las tareas que lleva a cabo este proceso son:

 Inicio: inicia la ejecución de los pasos en el momento en que se le indique.

 Establecer variables Fecha_Desde y Fecha_Hasta: establece dos variables globales que
serán utilizadas posteriormente por algunos Pasos.
 Para la variable Fecha_Desde se obtiene el valor de la fecha en que se realizó la primera
venta.
 Para la variable Fecha_Hasta se obtiene el valor de la fecha actual.
 Carga de Dimensión dimClientes: ejecuta el contenedor de Pasos que cargará la tabla de
Dimensión dimClientes (más adelante se detallará).
 Carga de Dimensión dimProductos: ejecuta el contenedor de Pasos que cargará la tabla de
Dimensión dimProductos (más adelante se detallará).
 Carga de Dimensión dimFechas: ejecuta el contenedor de Pasos que cargará la tabla de
Dimensión dimFechas (más adelante se detallará).
 Carga de Tabla de Hechos factVentas: ejecuta el contenedor de Pasos que cargará la tabla
de Hechos factVentas (más adelante se detallará).

Carga de Dimensión dimClientes

A continuación, se especificarán las tareas llevadas a cabo por Carga de Dimensión

dimClientes. Este Paso es un Contenedor de Pasos, así que incluye las siguientes tareas:

 Obtener datos de Datasource: obtiene a través de una consulta SQL los datos del
Datasource necesarios para cargar la tabla de Dimensión dimClientes.

Se tomará como fuente de entrada la tabla Clientes del Data Source mencionado anteriormente.

28
Se consultó con l@s usuari@s y se averiguó que deseaban tener en cuenta solo aquellos clientes
que NO estén eliminados y que tengan su cuenta habilitada.

Es importante destacar que aunque existían numerosos movimientos de clientes que en la

actualidad NO poseen su cuenta habilitada o que figuran como eliminados, se decidió NO
incluirlos debido a que el énfasis está puesto en analizar los datos a través de aquellos
clientes que NO se encuentren en estas condiciones.

Los clientes eliminados son referenciados mediante el campo Eliminado; el valor 1 indica que
éste fue eliminado y el valor 0 que aún permanece vigente. Cuando se examinaron los
registros de la tabla, para muchos clientes NO había ningún valor asignado para este campo,
lo cual, según comunicó el encargado del sistema, se debía a que este campo se agregó
poco después de haberse creado la base de datos inicial, razón por la cual existían Missing
Values (valores faltantes). Además, comentó que en el sistema, si un cliente posee en el
campo Eliminado el valor 0 o un Missing Value (valor faltante), es considerado como vigente.

Con respecto a la cuenta habilitada, el campo del Data Source que le corresponde es
Cta_Habilitada; el valor 0 indica que su cuenta NO está habilitada y el valor 1 que su cuenta
sí está habilitada.

A continuación se expondrá la sentencia SQL configurada en este Paso:

 Cargar dimClientes: almacena en la tabla de Dimensión dimClientes los datos obtenidos en el

Paso anterior.

Carga de Dimensión dimProductos

Se especificarán las tareas llevadas a cabo por Carga de Dimensión dimProductos. Este
Paso es un Contenedor de Pasos, así que incluye las siguientes tareas

29
  Obtener datos de Datasource: obtiene a través de una consulta SQL los datos del Data
Source necesarios para cargar la Dimensión dimProductos.

Las fuentes que se utilizarán, son las tablas Productos y Marcas.

En este caso, aunque existían productos eliminados, l@s usuari@s decidieron que esta
condición NO fuese tomada en cuenta, ya que había movimientos que hacían referencia
a productos con este estado.

Es necesario realizar una unión entre la tabla Productos y Marcas, por lo cual se debió
asegurar que ningún producto hiciera mención a alguna marca que NO existiese.

La sentencia SQL configurada en este paso es la siguiente:

 Cargar dimProductos: almacena en la tabla de Dimensión dimProductos los datos obtenidos

en el Paso anterior.

Carga de Dimensión dimFechas

A continuación, se especificarán las tareas llevadas a cabo por Carga de Dimensión

dimFechas. Este Paso es un Contenedor de Pasos, así que incluye las siguientes tareas:

Para generar la tabla de Dimensión dimFechas (la cual debe estar presente en todo DW) existen
herramientas y utilidades de Software que proporcionan diversas opciones para su
confección.

Lo que se hizo, fue confeccionar un Procedure (procedimiento) que trabaja de la siguiente

manera:

1) Recibe como parámetros los valores de Fecha_Desde y Fecha_Hasta.

30
2) Recorre una a una las fechas que se encuentran dentro de este intervalo.

3) Analiza cada fecha y realiza una serie de operaciones para crear los valores de los campos de
la tabla de la Dimensión dimFechas:

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

anio = YEAR(fecha)

trimestre = CASE WHEN QUARTER(fecha) = 1 then '1er Tri' ... END

mes = CASE WHEN MONTH(fecha) = 1 then 'Enero' ... END

4) Inserta los valores obtenidos en la tabla de Dimensión dimFechas.

La clave principal idFecha es un campo numérico representado por el formato yyyymmdd.

Carga de Tabla de Hechos factVentas

A continuación, se especificarán las tareas llevadas a cabo por Carga de Tabla de Hechos
factVentas. Este Paso es un Contenedor de Pasos, así que incluye las siguientes tareas:

 Obtener datos de Datasource: obtiene a través de una consulta SQL los datos del Data
Source necesarios para cargar la tabla de Hechos factVentas.

31
 Para la confección 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 analizaron las condiciones
que deben cumplir los datos para considerarse de interés. En este caso, se trabajará
solamente con aquellas facturas que NO hayan sido anuladas.

Se investigó al respecto, y se llegó a la conclusión de que el campo que brinda dicha

información es Anulada de la tabla Facturas_Ventas y si el mismo posee el valor 1 significa
que efectivamente fue anulada.

Otro punto a tener en cuenta, es que la fecha se debe convertir al formato numérico
yyyymmdd.

Se decidió aplicar una preagregación a los Hechos que formarán parte de la tabla de Hechos;
es por esta razón que se utilizará la cláusula GROUP BY para agrupar todos los registros a
través de las claves primarias de esta tabla.

La sentencia SQL configurada en este Paso es la siguiente:

 Cargar factVentas: almacena en la tabla de Hechos factVentas los datos obtenidos en el

Paso anterior.

4.2. Actualización

Cuando se haya ejecutado la carga inicial del DW, se deben establecer las políticas y estrategias de
actualización periódica.

Entonces, se deben llevar a cabo las siguientes acciones:

 Determinar el proceso de limpieza de datos y calidad de datos, definir los procesos ETL, etc.,
que deberán realizarse para actualizar los datos del DW.
 Especificar de forma general y detallada las acciones que deberá realizar cada Software.

Caso práctico

La información se refrescará: todos los días a las 00:00hs.

32
  Los datos de las tablas de Dimensiones dimProductos y dimClientes serán cargados siempre
en su totalidad.
 Los datos de la tabla de Dimensión dimFechas se cargarán de forma incremental teniendo en
cuenta la fecha de la última actualización.
 Los datos de la tabla de Hechos factVentas que corresponden al último mes (30 días) a partir
de la fecha actual, serán reemplazados cada vez.
 Estas acciones se realizarán durante un período de prueba, para analizar cuál es la manera
más eficiente de generar las actualizaciones, basadas en el estudio de los cambios que se
producen en los Data Sources y que afectan al contenido del DW.
 Para evitar que se extienda demasiado la aplicación del ejemplo, el caso práctico solo incluirá
lo que debería realizar el proceso ETL para actualizar el DW.

El proceso ETL para la actualización del DW es similar al de Carga Inicial, con las siguientes
diferencias:

 Inicio: iniciará la ejecución de los pasos todos los días a las doce de la noche.
 Establecer variables Fecha_Desde y Fecha_Hasta:
 La variable Fecha_Desde obtendrá el valor resultante de restarle a la fecha actual treinta
días.
 La variable Fecha_Hasta obtendrá el valor de la fecha actual.
 Carga de Dimensión dimClientes: a la serie de pasos que realiza esta tarea, se le
antepondrá un nuevo paso que borrará los datos que contenga la Dimensión dimClientes.
 Carga de Dimensión dimProductos: a la serie de pasos que realiza esta tarea, se le
antepondrá un nuevo paso que borrará los datos que contenga la Dimensión
dimProductos.
 Carga de Dimensión dimFechas: en este paso, se establecerá la variable Fecha_Desde,
tomando la fecha del último registro cargado en la Dimensión dimFechas.

Carga de Tabla de Hechos factVentas:

a la serie de pasos que realiza esta tarea, se le antepondrá un nuevo paso que borrará los datos
que contenga la tabla de Hechos factVentas en el intérvalo entre Fecha_Desde y
Fecha_Hasta.

en el paso Obtener datos de Datasource se modificará la sentencia SQL agregando la siguiente

condición:

WHERE Facturas_Venta.Fecha >= {Fecha_Desde} AND Facturas_Venta.Fecha <=

{Fecha_Hasta}

33
 10. Cubo Multidimensional
Continuando con el ejemplo, se creará un Cubo Multidimensional que estará basado en el modelo
lógico diseñado en el caso práctico de la metodología HEFESTO:

La creación de este Cubo tiene las siguientes finalidades:

 Ejemplificar la creación de Cubos Multidimensionales.

 Propiciar la correcta distinción entre Hechos de una tabla de Hechos e Indicadores de un
Cubo.
 Propiciar la correcta distinción entre campos de una tabla de Dimensión y Atributos de un
Cubo.

Pasos básicos
1) Se creará un Cubo Multidimensional llamado Cubo Hefesto:

2) Se indicará que la tabla de Hechos utilizar es factVentas:

3) Se creará un Dimensión para analizar l@s clientes. Su nombre será Dimensión Clientes.

 Se añadirá una Jerarquía. Su nombre será Jerarquía Clientes.

 Se indicará que Jerarquía Clientes estará basada en los campos de la tabla de
Dimensión dimClientes.
 Se añadirá a la Jerarquía Clientes el Atributo Cliente, que estará basado en el
campo cliente.

34
4) Se creará un Dimensión para analizar los productos. Su nombre será Dimensión Productos.

 Se añadirá una Jerarquía. Su nombre será Jerarquía Productos.

 Se indicará que Jerarquía Productos estará basada en los campos de la tabla de
Dimensión dimProductos.
 Se añadirá a la Jerarquía Productos el Atributo Marca, que estará basado en el
campo marca.
 Se añadirá a la Jerarquía Productos el Atributo Producto, que estará basado en el
campo producto. En donde existe una relación padre-hijo
entre marca y producto respectivamente.

5) Se creará un Dimensión para analizar el tiempo. Su nombre será Dimensión Fechas.

 Se añadirá una Jerarquía. Su nombre será Jerarquía Fechas.

 Se indicará que Jerarquía Fechas estará basada en los campos de la tabla de
Dimensión dimFechas.
 Se añadirá a la Jerarquía Fechas el Atributo Año, que estará basado en el campo anio.
 Se añadirá a la Jerarquía Fechas el Atributo Trimestre, que estará basado en el
campo trimestre. En donde existe una relación padre-hijo
entre anio y trimestre respectivamente.
 Se añadirá a la Jerarquía Fechas el Atributo Mes, que estará basado en el campo mes. En
donde existe una relación padre-hijo entre trimestre y mes respectivamente.

35
6) Se creará un Indicador, llamado Unidades Vendidas que se calculará de la siguiente manera:

 SUM(cantidad)

7) Se creará un Indicador, llamado Monto Total de Ventas que se calculará de la siguiente manera:

 SUM(montoTotal)

36