Informe de Practicas Completo

UNIVERSIDAD NACIONAL DE SAN CRISTBAL DE
HUAMANGA
FACULTAD DE INGENIERA DE MINAS, GEOLOGA Y CIVIL
ESCUELA DE FORMACIN PROFESIONAL DE INGENIERA DE
SISTEMAS
ANLISIS, DISEO E IMPLEMENTACIN DE UN DATA MART

PARA EL REA DE VENTAS DE INTERCEL DISTRIBUIDOR
AUTORIZADO DE CLARO DE LA REGION AYACUCHO
INFORME DE PRCTICAS PRE-PROFESIONALES PRESENTADO POR:
BENDEZ VILLENA, Richard
PARA OPTAR EL GRADO ACADMICO DE:

BACHILLER EN INGENIERA DE SISTEMAS
ASESORA: ING. ELVIRA FERNANDEZ JERI
AYACUCHO, 05 DE SETIEMBRE DEL 2014
AGRADECIMIENTOS
Agradezco a Dios por haberme dado a los padres y
hermanos que tengo por qu ellos han dejado de
hacer varias cosas por darme a m lo necesario para
que yo pueda estudiar.
DEDICATORIA
Este proyecto lo dedico a mi familia por apoyarme
incondicionalmente su tiempo y dedicacin para
continuar con mi aprendizaje.
ii
CONTENIDO
AGRADECIMIENTOS
DEDICATORIA
ii
CONTENIDO
iii
RESUMEN
INTRODUCCIN
vi
CAPTULO I
OBJETIVOS
1.1
OBJETIVO GENERAL
01
1.2
OBJETIVOS ESPECFICOS
01
CAPTULO II
MARCO TERICO
2.1
INTERCEL
02
2.2
INTELIGENCIA DE NEGOCIOS
02
2.3
DATA WAREHOUSING
03
2.4
DATA WAREHOUSE
03
2.5
ARQUITECTURA DEL DATA WAREHOUSING
04
2.5.1 INTRODUCCIN.
04
2.5.2 OLTP
04
2.5.3 LOAD MANAGER
05
2.5.4 DATA WAREHOUSE MANAGER
10
2.5.5 QUERY MANAGER
17
2.5.6 HERRAMIENTAS DE CONSULTA Y ANLISIS
17
2.5.7 USUARIOS
20
2.6
DATA MART
21
2.7
METODOLOGIA HEFESTO
22
2.7.1 DEFINICION
22
2.7.2 CARACTERISTICAS
24
2.7.3 PASOS DE LA METODOLOGIA
25
iii
CAPTULO III
RESULTADOS
3.1
PROBLEMTICA
32
3.2
SOLUCIN DESARROLLADA
33
3.3
PASOS DE LA METODOLOGIA EFESTO
35
3.3.1 ANALISIS DE REQUERIMIENTOS
35
3.3.2 ANLISIS DE LOS OLTP
38
3.3.3 MODELO LGICO DEL DW
48
3.3.4 INTEGRACIN DE DATOS
53
3.4
CREACIN DE CUBOS MULTIDIMENSIONALES
63
3.5
REPORTES CON LOS CUBOS
64
CAPTULO IV
CONCLUSIONES Y RECOMENDACIONES
4.1
CONCLUSIONES
69
4.2
RECOMENDACIONES
69
BIBLIOGRAFA
71
iv
RESUMEN
Las distribuidoras autorizadas de Claro crecen en el mercado peruano
generando ingresos y empleo. El rpido avance de la tecnologa permite a
ms personas acceder a productos que faciliten su comunicacin diaria en
la sociedad. Esto obliga a dichas empresas a volverse ms competitivas en
cuanto a precios, promociones, publicidad y tecnologa.
Para volverse ms competitivas muchas empresas de este rubro toman
decisiones a base de la experiencia y resultados anteriores. Debido a que
estas decisiones generalmente no se toman de manera estructurada, se
plantea como solucin el uso de una herramienta de inteligencia de
negocios que permita en tiempo real a los gerentes y jefes de producto
generar escenarios, pronsticos y reportes que apoyen a la toma de
decisiones en la venta de equipos de telecomunicacin.
Como solucin de Inteligencia de Negocios se disea un Data Mart de
Ventas, luego se realizan los procesos de extraccin, transformacin y carga
de datos, para finalmente explotar los datos mediante reportes que
permitan hacer el anlisis de la informacin.
El proceso de extraccin, transformacin y carga (ETL) permite mover datos
de diferentes fuentes, transformarlos y cargarlos a los Data Marts. El proceso
de Explotacin permite generar los reportes que el usuario final usa para el
anlisis de la informacin y para la toma de decisiones.
El Data Mart fue diseado siguiendo los pasos indicados por la metodologa
para la construccin de un Data WareHouse HEFESTO, el mismo que es
descrito en el presente informe; intentando de esta manera garantizar la
documentacin y la calidad de la herramienta de BI.
v
INTRODUCCIN
Las empresas actualmente caracterizan a la informacin como uno de
los activos de la empresa, debido a ello empiezan a tratarla ms
metdicamente, especialmente la informacin que da soporte al
proceso de toma de decisiones.
La empresa Intercel comunicaciones cuenta con una aplicacin de
procesamiento transaccional que mecaniza las operaciones de su da a
da. En esta aplicacin se procesan grandes cantidades de datos
referentes a las actividades rutinarias y se almacenan en bases de datos.
De ellas se puede extraer informacin que bsicamente sirve de soporte
para apoyar en decisiones operativas que conducen actividades
bsicas, mas no sirve para realizar un anlisis ms profundo o estratgico,
ya que no estn diseadas para este tipo de tareas.
As muchas empresas si bien cuentan con una gran cantidad de
informacin que podra generarle una ventaja competitiva, no cuentan
con las herramientas necesarias para poder administrar los datos y se
enfrentan al problema de procesar dichos datos y transformarlos en
informacin til.
Como solucin a los problemas con la informacin de Intercel
comunicaciones, es posible extraer un grupo de datos, a partir de una o
varias bases de datos operacionales, que aporten un valor agregado a
la gestin de la empresa, lo que constituir un Data Warehouse o Data
Mart.
El presente informe tiene como objetivo principal implementar un Data
Mart para el rea de ventas de Intercel comunicaciones para brindarle
una herramienta que facilitar la toma de decisiones a dicha rea.
vi
CAPTULO I
OBJETIVOS
1.1 OBJETIVO GENERAL
Realizar el anlisis, diseo e implementacin de un Data Mart para el
rea de ventas de INTERCEL distribuidor autorizado de claro, con el
propsito de agilizar el proceso de anlisis de datos, toma de decisiones,
formulacin de estrategias de prevencin y planificacin de actividades
de una forma ms rpida y eficaz, y la finalidad de poner a disposicin del
gerente, la Informacin consolidada.
1.2 OBJETIVOS ESPECFICOS
a.
Identificar los requerimientos del usuario que especifiquen los

objetivos de la organizacin.
b.
Elegir un esquema de Data Mart y especificar las consultas de

anlisis que mejor se adapte a los requerimientos y necesidades de
los usuarios.
c.
Disear el proceso de ETL (Extraccin, Transformacin y Carga) de

datos teniendo en cuenta la confiabilidad e integridad de estos.
d.
Crear un cubo multidimensional que permita hacer el anlisis de los

datos cargados en el Data Mart.
e.
Crear reportes para la toma de decisiones, solicitados en el rea

de ventas de INTERCEL distribuidor autorizado de claro.
CAPTULO II
MARCO TERICO
2.1
ITERCEL
Distribuidor autorizado de Claro desde 2009. Hoy en da es uno de los
distribuidores ms grande e importante de la Regin Ayacucho. Ofrece

servicios y equipos de la ms alta calidad acordes con los avances
tecnolgicos y las tendencias de las telecomunicaciones situacin que les
permite brindar las mejores alternativas de comunicacin a sus clientes
razn por la cual se constituyen como la mejor opcin de comunicacin
mvil.
2.2
INTELIGENCIA DE NEGOCIOS
Las aplicaciones de Business Intelligence (BI) son herramientas de
soporte de decisiones que permiten en tiempo real, acceso interactivo,

anlisis y manipulacin de informacin crtica para la empresa. Estas
aplicaciones proporcionan a los usuarios un mayor entendimiento que les
permite identificar las oportunidades y los problemas de los negocios. Los
usuarios son capaces de acceder y apalancar una vasta cantidad de
informacin y analizar sus relaciones y entender las tendencias que
ltimamente estn apoyando las decisiones de los negocios. Estas
herramientas previenen una potencial prdida de conocimiento dentro de
la empresa que resulta de una acumulacin masiva informacin que no es
fcil de leer o de usar. (CherryTree & Co., 2000).
BI es un proceso interactivo para explorar y analizar informacin
estructurada sobre un rea (normalmente almacenada en un Data
Warehouse), para descubrir tendencias o patrones, a partir de los cuales
derivar ideas y extraer conclusiones. El proceso de BI incluye la
comunicacin de los descubrimientos y efectuar los cambios. Las reas
2
incluyen clientes, proveedores, productos, servicios y competidores.

(Cmara, 2010).
2.3
DATA WAREHOUSING
El Data Warehousing (DWH), es el encargado de extraer,
transformar, consolidar, integrar y centralizar los datos que una organizacin

genera en todos los mbitos de su actividad diaria (compras, ventas,
produccin, etc) y/o informacin externa relacionada. Permitiendo de esta
manera el acceso y exploracin de la informacin requerida, a travs de
una amplia gama de posibilidades de anlisis multivariables, con el objetivo
nal de dar soporte al proceso de toma de decisiones estratgico y
tctico. (Bernabeu, 2010).
Data Warehousing es el centro de la arquitectura para los sistemas de
informacin en la dcada de los '90. Soporta el procesamiento informtico
al proveer una plataforma slida, a partir de los datos histricos para hacer
el anlisis. Facilita la integracin de sistemas de aplicacin no integrados.
Organiza y almacena los datos que se necesitan para el procesamiento
analtico, informtico sobre una amplia perspectiva de tiempo. (ONGEI,
1997).
2.4
DATA WAREHOUSE
Es un almacn o repositorio de datos que integra informacin de
diferentes fuentes (base de datos, archivos de texto, hojas de clculo, etc.)

y permite un anlisis para la toma de decisiones. Muchos expertos definen
el Data Warehouse como un almacn de datos centralizados que introduce
datos en un almacn de datos especfico llamado Data Mart. Otros
aceptan una amplia definicin de Data Warehouse, como un conjunto
integrado de Data Marts. (Vitt, Luckevich y Misner, 2002).
"Es un conjunto de datos integrados orientados a una materia, que varan
con el tiempo y que no son transitorios, los cuales soportan el proceso de
3
toma de decisiones de una administracin" (Harjinder y Prakash, 1996).

2.5
ARQUITECTURA DEL DATA WAREHOUSING
2.5.1
INTRODUCCIN.
Segn Bernabeu (2010) en este punto y teniendo en cuenta que ya
se han detallado claramente las caractersticas generales del Data

Warehousing, se denirn y describirn todos los componentes que
intervienen en su arquitectura o ambiente. A travs del siguiente grafico se
explicitar la estructura del Data Warehousing:
Figura 2.5.1: Data Warehousing, arquitectura. (Bernabeu, 2010).

2.5.2
OLTP
Segn Bernabeu (2010) OLTP (On Line Transaction Processing),
representa toda aquella informacin transaccional que genera la empresa

en su accionar diario, adems, de las fuentes externas con las que puede
llegar a disponer. Como ya se ha mencionado, estas fuentes de
informacin, son de caractersticas muy dismiles entre s, en formato,
procedencia, funcin, etc.
Entre los OLTP ms habituales que pueden existir en cualquier organizacin
se encuentran: Archivos de textos, hipertextos, hojas de clculos, Bases de
datos transaccionales e Informes semanales, mensuales, anuales, etc.
Figura 2.5.2: OLTP. (Bernabeu, 2010).

2.5.3
LOAD MANAGER
Segn Bernabeu (2010) para poder extraer los datos desde los OLTP,
para luego manipularlos, integrarlos y transformarlos, para posteriormente

cargar los resultados obtenidos en el Data Warehouse, es necesario contar
con algn sistema que se encargue de ello. Precisamente, la integracin de
datos es quien cumplir con tal fin.
La integracin de datos agrupa una serie de tcnicas y subprocesos que se
encargan de llevar a cabo todas las tareas relacionadas con la extraccin,
manipulacin, control, integracin, depuracin de datos, carga y
actualizacin del Data Warehouse, etc. Es decir, todas las tareas que se
realizarn desde que se toman los datos de los diferentes OLTP hasta que se
cargan en el Data Warehouse.
Figura 2.5.3: Load manager. (Bernabeu, 2010).

5
2.5.3.1 EXTRACCIN
Segn Bernabeu (2010) es aqu, en donde, basndose en las
necesidades y requisitos de los usuarios, se exploran las diversas fuentes OLTP
que se tengan a disposicin, y se extraer la informacin que se considere
relevante al caso.
Una vez que los datos son seleccionados y extrados, se guardan en un
almacenamiento intermedio, lo cual permite, entre otras ventajas:
i.
Manipular los datos sin interrumpir ni paralizar los OLTP, ni tampoco

el DATA WAREHOUSE.
ii.
No depender de la disponibilidad de los OLTP.
iii.
Almacenar y gestionar los metadatos que se generarn en los

procesos ETL.
iv.
Facilitar la integracin de las diversas fuentes, internas y externas.
Segn Palomar (2001), las fuentes de datos que normalmente suministran los
insumos para esta operacin son: Base de datos operacionales de la
organizacin o bases de datos externas, archivos de texto plano, Datos
provenientes de documentos de texto, hojas de clculos, Data Warehouse
empresarial, en caso que el destino del proceso ETL sea un Datamart y el
Datamart de la organizacin.
2.5.3.2 TRANSFORMACIN
Segn Bernabeu (2010) esta funcin es la encargada de convertir
aquellos datos inconsistentes en un conjunto de datos compatibles y
congruentes, para que puedan ser cargados en el Data Warehouse. Estas
acciones se llevan a cabo, debido a que pueden existir diferentes fuentes
de informacin, y es vital conciliar un formato y forma nica, definiendo
estndares, para que todos los datos que ingresarn al Data Warehouse
estn integrados. Los casos ms comunes en los que se deber realizar
6
integracin, son los siguientes:

a)
Codificacin: Una inconsistencia muy tpica que se encuentra al

intentar integrar varias fuentes de datos, es la de contar con ms de
una forma de codificar un atributo en comn. Por ejemplo, en el
campo estado, algunos diseadores completan su valor con 0 y
1, otros con Apagado y Encendido.
b)
Medida de atributos: Los tipos de unidades de medidas utilizados

para
representar
los
atributos
de
una
entidad,
varan
considerablemente entre s, a travs de los diferentes OLTP. Por

ejemplo, al registrar la longitud de un producto determinado, de
acuerdo a la aplicacin que se emplee para tal n, las unidades de
medidas pueden ser explicitadas en centmetros, metros, pulgadas,
etc.
c)
Convenciones de nombramiento: Usualmente, un mismo atributo es

nombrado de diversas maneras en los diferentes OLTP. Por ejemplo,
al referirse al nombre del proveedor, puede hacerse como
nombre, razn_social, proveedor, etc.
d)
Fuentes mltiples: Un mismo elemento puede derivarse desde varias

fuentes. En este caso, se debe elegir aquella fuente que se considere
ms fiable y apropiada.
Adems de lo antes mencionado, esta funcin se encarga de
realizar, entre otros, los procesos de Limpieza de Datos (Data
Cleansing) y Calidad de Datos.
e)
limpieza de datos: Su objetivo principal es el de realizar distintos tipos

de acciones contra el mayor nmero de datos errneos,
inconsistentes e irrelevantes.
7
Segn Lane (1999) se plantea que la transformacin de los datos para el

Datamart se puede definir como una serie de pasos, que consiste en llevar
a cabo las transformaciones de cada atributo a considerar en el Datamart
de forma separada mediante operaciones de SQL y/o procedimientos en
lenguajes estructurados; por lo que se crean tablas temporales donde se
almacenan los resultados parciales de estas operaciones. Para llevar a
cabo esta estrategia se debe proveer de checkpoints o puntos seguros
dentro del flujo de transformaciones con miras a llevar el monitoreo del
proceso y poder reiniciar el mismo en caso de alguna falla.
Esta estrategia provee al proceso un mejor desempeo por cuanto se lleva
a cabo en etapas, pero dificulta la modificacin, insercin y eliminacin de
las transformaciones y por ello se utilizan los checkpoints.
Figura 2.5.4: Ejemplo de un flujo de transformaciones (Lane, 1999).
2.5.3.3 CARGA
Segn Bernabeu (2010) .Esta funcin se encarga, por un lado de
realizar las tareas relacionadas con: Carga Inicial (Initial Load) y
actualizacin o mantenimiento peridico (siempre teniendo en cuenta un
intervalo de tiempo predenido para tal operacin). La carga inicial, se
8
reere precisamente a la primera carga de datos que se le realizar al Data

Warehouse. Por lo general, esta tarea consume un tiempo bastante
considerable, ya que se deben insertar registros que han sido generados
aproximadamente, y en casos ideales, durante ms de cinco aos. Los
mantenimientos peridicos mueven pequeos volmenes de datos, y su
frecuencia est dada en funcin del grnulo del Data Warehouse y los
requerimientos de los usuarios. El objetivo de esta tarea es aadir al depsito
aquellos datos nuevos que se fueron generando desde el ltimo refresco.
Por otra parte, el proceso de carga tiene la tarea de mantener la estructura
del Data Warehouse, y trata temas relacionados con: Relaciones muchos a
muchos, claves Subrogadas, dimensiones lentamente cambiantes y
dimensiones degeneradas.
Segn lane(1999) Consiste en depositar los datos en el sistema
destino y puede llevarse de la siguiente forma:
a)
Cargas secuenciales: Se realiza una serie de cargas organizadas

una tras otra y generalmente de grandes volmenes de datos.
b)
Procesos por lotes (batchs): Se realiza una serie de cargas

generalmente largas que son supervisadas por el administrador de
la base de datos y son generalmente realizadas por programas de
forma peridica con la finalidad de mantener actualizado el Data
Mart.
c)
Procesamiento paralelo y tcnicas incrementales: Esta tcnica se

caracteriza por cargar slo los datos nuevos y modificar aquellos
que han sido alterados desde su origen. Esta tcnica permite la
consulta del Datamart aun cuando se est llevando a cabo la
actualizacin y realiza comprobaciones peridicas (auditorias) con
la finalidad de revisar la consistencia en los estados del proceso.
2.5.4
DATA WAREHOUSE MANAGER

Segn Bernabeu (2010) el Data Warehouse Manager presenta las
siguientes caractersticas y funciones principales:

i.
Se constituye tpicamente al combinar un SGBD con software y

aplicaciones dedicadas.
ii.
Almacena los datos de forma multidimensional, es decir, a travs de

tablas de hechos y tablas de dimensiones.
iii.
Gestiona las diferentes estructuras de datos que se construyan o

describan
sobre
el
Data
Warehouse,
como
Cubos
Multidimensionales, modelos de negocio, etc.

iv.
Gestiona y mantiene metadatos.
v.
Adems, el Data Warehouse Manager se encarga de: Transformar e

integrar los datos fuentes y del almacenamiento intermedio en un
modelo adecuado para la toma de decisiones.
vi.
Realizar todas las funciones de definicin y manipulacin del

depsito de datos, para poder soportar todos los procesos de
gestin del mismo. Ejecutar y denir las polticas de particionamiento
El objetivo de realizar esto, es conseguir una mayor eciencia y
performance en las consultas al no tener que manejar todo el grueso
de los datos. Esta poltica debe aplicarse sobre la tabla de hechos
que, como se explicar ms adelante, es en la que se almacena
toda la informacin que ser analizada.
vii.
Realizar copias de resguardo incrementales o totales de los datos del

Data Warehouse.
2.5.4.1 BASE DE DATOS MULTIDIMENSIONAL

Una base de datos multidimensional es una base de datos en
donde su informacin se almacena en forma multidimensional, es decir, a
travs de tablas de hechos y tablas de dimensiones (Bernabeu, 2010).
2.5.4.2 TABLAS DE DIMENSIONES
Las tablas de dimensiones denen como estn los datos
10
organizados lgicamente y proveen el medio para analizar el contexto del

negocio. Contienen datos cualitativos. Representan los aspectos de inters,
mediante los cuales los usuarios podrn ltrar y manipular la informacin
almacenada en la tabla de hechos. (Bernabeu, 2010).
Las tablas de dimensiones representan cada uno de los ejes en un espacio
multidimensional. Sus atributos son del tipo cualitativo que proporcionan el
contexto en el que se obtienen las medidas en un esquema de hecho. Las
dimensiones poseen jerarquas, que son varios atributos unidos mediante
una relacin del tipo jerrquico. (Ullman y Widom, 1999).
2.5.4.3 TABLAS DE HECHOS
Las tablas de hechos contienen, precisamente, los hechos que
sern utilizados por los analistas de negocio para apoyar el proceso de
toma de decisiones. Contienen datos cuantitativos. (Ullman y Widom,
1999).
Las tablas de hechos constituyen el objeto a analizar, poseen atributos de
hechos que son del tipo cuantitativo cuyos valores se obtienen por
aplicacin de alguna funcin estadstica que resumen un conjunto de
valores en un nico valor. (Ullman y Widom, 1999).
2.5.4.4 CUBO MULTIDIMENSIONAL: INTRODUCCIN
Segn Bernabeu (2010) un cubo multidimensional o hipercubo,
representa o convierte los datos planos que se encuentran en las y
columnas, en una matriz de N dimensiones. Los objetos ms importantes que
se pueden incluir en un cubo multidimensional, son los siguientes:
a)
Indicadores: clculos que se efectan sobre algn hecho o

expresiones basadas en clculos, pertenecientes a una tabla de
hechos.
b)
Atributos: campos o criterios de anlisis, pertenecientes a tablas de

dimensiones.
11
c)
Jerarquas: representa una relacin lgica entre dos o ms atributos.
d)
Relacin: Relacin Una relacin representa la forma en que dos

atributos interactan dentro de una jerarqua. Existen bsicamente
dos tipos de relaciones:
i.
Explcitas: son las ms comunes y se pueden modelar a partir

de atributos directos y estn en lnea continua de una
jerarqua, por ejemplo, un pas posee una o ms provincias y
una provincia pertenece solo a un pas.
ii.
Implcitas: son las que ocurren en la vida real, pero su relacin

no es de vista directa, por ejemplo, una provincia tiene uno o
ms ros, pero un ro pertenece a una o ms provincias. Como
se puede observar, este caso se trata de una relacin muchos
a muchos.
e)
Granularidad: La granularidad representa el nivel de detalle al que

se desea almacenar la informacin sobre el negocio que se est
analizando. Por ejemplo, los datos referentes a ventas o compras
realizadas por una empresa, pueden registrarse da a da, en
cambio, los datos pertinentes a pagos de sueldos o cuotas de socios,
podrn almacenarse a nivel de mes.
2.5.4.5 TIPOS DE MODELAMIENTO DE UN DATA WAREHOUSE

A.
ESQUEMA EN ESTRELLA
El esquema estrella forma un diagrama en forma de estrella
teniendo en el centro de la estrella una o ms tablas de hechos y las puntas

de las estrellas a las tablas de dimensiones. (Ullman y Widom, 1999).
El esquema en estrella, consta de una tabla de hechos central y de varias
tablas de dimensiones relacionadas a esta, a travs de sus respectivas
claves. (Bernabeu, 2010).
12
Figura 2.5.5: Esquema en estrella (Bernabeu, 2010).

B.
ESQUEMA COPO DE NIEVE

En el caso del esquema de copo de nieve, las tablas de
dimensiones se encuentran normalizadas, es decir, cada tabla dimensional

slo contiene el nivel que es la clave primaria en la tabla y la llave fornea
de su parentesco del nivel ms cercano. (Daz, 2002).
Este esquema representa una extensin del modelo en estrella cuando
las tablas de dimensiones se organizan en jerarquas de dimensiones.
(Bernabeu, 2010).
Figura 2.5.6: Esquema en copo de nieve (Bernabeu, 2010).

2.5.4.6 OLTP VS DATA WAREHOUSE
Los OLTP son diseados para soportar el procesamiento de
informacin diaria de las empresas, y el nfasis recae en maximizar la
13
capacidad transaccional de sus datos. Su estructura es altamente

normalizada, para brindar mayor eficiencia a sistemas con muchas
transacciones que acceden a un pequeo nmero de registros y estn
fuertemente condicionadas por los procesos operacionales que deben
soportar, para la ptima actualizacin de sus datos. Esta estructura es ideal
para llevar a cabo el proceso transaccional diario, brindar consultas sobre
los datos cargados y tomar decisiones diarias, en cambio los esquemas de
Data Warehouse estn diseados para poder llevar a cabo procesos de
consulta y anlisis para luego tomar decisiones estratgicas y tcticas de
alto nivel. (Bernabeu, 2010).
A continuacin se presentar una tabla comparativa entre los dos
ambientes, que resume sus principales diferencias:
Cuadro 5.5.1: OLTP Vs Data Warehouse. (Bernabeu, 2010).
14
2.5.4.7 TIPOS DE IMPLEMENTACIN DE UN DATA WAREHOUSE

A.
ROLAP (RELATIONAL ON LINE ANALYTIC PROCESSING)

Este tipo de organizacin fsica se implementa sobre tecnologa
relacional, pero disponen de algunas facilidades para mejorar el

rendimiento. Es decir, ROLAP cuenta con todos los benecios de una SGBD
Relacional a los cuales se les provee extensiones y herramientas para poder
utilizarlo como un Sistema Gestor de DATA WAREHOUSE. (Bernabeu, 2010).
La
arquitectura
ROLAP
cree
que
las
capacidades
OLAP
estn
perfectamente implantadas sobre bases de datos relacionales. La

arquitectura ROLAP es capaz de usar datos pre calculados si estos estn
disponibles, o de generar dinmicamente los resultados desde los datos
elementales si es preciso. Esta arquitectura accede directamente a los
datos del Data Warehouse, y soporta tcnicas de optimizacin de accesos
para acelerar las consultas. (Sinexus, s.f.).
B.
MOLAP (MULTIDIMENTIONAL ON LINE ANALYTIC PROCESSING)

El objetivo de los sistemas MOLnAP es almacenar fsicamente los
datos en estructuras multidimensionales de manera que la representacin

externa y la interna coincidan. Para ello, se dispone de estructuras de
almacenamiento especcas (Arrays) y tcnicas de compactacin de
datos que favorecen el rendimiento del DATA WAREHOUSE. (Bernabeu,
2010).
La arquitectura MOLAP usa unas bases de datos multidimensionales para
proporcionar el anlisis, su principal premisa es que el OLAP est mejor
implantado almacenando los datos multidimensionalmente. (Sinnexus, s.f.).
C.
HOLAP (HYBRID ON LINE ANALYTIC PROCESSING)

HOLAP constituye un sistema hbrido entre MOLAP y ROLAP, que
combina estas dos implementaciones para almacenar algunos datos en un

motor relacional y otros en una base de datos multidimensional. Los datos
15
agregados
pre
calculados
se
almacenan
en
estructuras
multidimensionales y los de menor nivel de detalle en estructuras

relacionales. Es decir, se utilizar ROLAP para navegar y explorar los datos, y
se emplear MOLAP para la realizacin de tableros. (Bernabeu, 2010).
La tecnologa HOLAP permite manejar lo mejor de ambos mundos. Para
informacin sumarizada, HOLAP utiliza tecnologa multidimensional para un
mejor desempeo. Cuando se necesita llegar a la informacin detallada,
HOLAP utiliza tcnicas de datos relacionales para llegar a sta. (Sinnexus,
s.f.).
D.
ROLAP VS MOLAP
En la siguiente tabla comparativa se pueden apreciar las principales
diferencias entre estos dos tipos de implementacin:
Cuadro 5.5.2: ROLAP Vs MOLAP. (Bernabeu, 2010).
16
2.5.5
QUERY MANAGER
Este componente realiza las operaciones necesarias para soportar
los procesos de gestin y ejecucin de consultas relacionales, tales como

Join y agregaciones, y de consultas propias del anlisis de datos, como drillup y drill-down. Query Manager recibe las consultas de los usuarios, las
aplica a la estructura de datos correspondiente (cubo multidimensional,
Business Models, etc.) y devuelve los resultados obtenidos. Cabe aclarar que
una consulta a un Data Warehouse, generalmente consiste en la obtencin
de indicadores a partir de los datos (hechos) de una tabla de hechos,
restringidas por las propiedades o condiciones de los atributos que hayan
sido creados. (Bernabeu, 2010).
Figura 2.5.7: Query Manager. (Bernabeu, 2010).

2.5.6
HERRAMIENTAS DE CONSULTA Y ANLISIS

Las herramientas de consulta y anlisis son sistemas que permiten a
los usuarios realizar la exploracin de datos del DATA WAREHOUSE.

Bsicamente constituyen el nexo entre el depsito de datos y los usuarios.
Utilizan la metadata de las estructuras de datos que han sido creadas
previamente (cubos multidimensionales, Business Models, etc.) para
trasladar a travs de consultas SQL los requerimientos de los usuarios, para
luego, devolver el resultado obtenido. Estas herramientas tambin pueden
emplear simples conexiones a bases de datos (JNDI, JDBC, ODBC), para
obtener la informacin deseada. (Bernabeu, 2010).
17
Figura 2.5.8: Herramientas de consulta y anlisis. (Bernabeu, 2010).

Segn Bernabeu (2010) a travs de una interfaz grfica y una serie de pasos,
los usuarios generan consultas que son enviadas desde la herramienta de
consulta y anlisis al Query Manager, este a su vez realiza la extraccin de
informacin al Data Warehouse Manager y devuelve los resultados
obtenidos a la herramienta que se los solicit. Luego, estos resultados son
expuestos ante los usuarios en formatos que le son familiares. Este proceso
se puede comprender mejor al observar la siguiente figura:
Figura 2.5.9: Procesos de consulta y Anlisis. (Bernabeu, 2010).

El mismo, se lleva a cabo a travs de seis pasos sucesivos:
1.
Los usuarios seleccionan o establecen que datos desean obtener

del Data Warehouse, mediante las interfaces de la herramienta que
utilice.
18
2.
La herramienta recibe el pedido de los usuarios, construye la

consulta (utilizando la metadata) y la enva al Query Manager.
3.
El Query Manager ejecuta la consulta sobre la estructura de datos

con la que se est trabajando (cubo multidimensional, Business
Model, etc.).
4.
El Query Manager obtiene los resultados de la consulta.
5.
El Query Manager enva los datos a la herramienta de consulta y

anlisis.
6.
La herramienta presenta a los usuarios la informacin requerida.
Las herramientas de consulta y anlisis, en general, comparten las

siguientes caractersticas: Accesibilidad a la informacin: permiten el
acceso a la informacin a travs de las diferentes estructuras de datos de
forma transparente a los usuarios nales, para que estos solo se enfoquen
en el anlisis y no en el origen y procedencia de los datos. Apoyo en la toma
de decisiones: permiten la exploracin de los datos, a n de seleccionar,
ltrar y personalizar los mismos, para la obtencin de informacin oportuna,
relevante y til, para apoyar el proceso de toma de decisiones. Orientacin
los usuarios nales: permiten a travs de entornos amigables e intuitivos, que
los usuarios puedan realizar anlisis y consultas, sin poseer conocimientos
tcnicos. Si bien lo realmente importante son los datos mismos, que estos
puedan ser interpretados y analizados por los usuarios depender en gran
medida de cmo se presenten y dispongan. (Bernabeu, 2010).
Segn Bernabeu (2010) existen diferentes tipos de herramientas de consulta
y anlisis, y de acuerdo a la necesidad, tipos de usuarios y requerimientos
de informacin, se debern seleccionar las ms propicias al caso. Entre ellas
se destacan las siguientes: Reportes y Consultas, OLAP, Dashboards, Data
Mining y EIS.
2.5.6.1 REPORTES Y CONSULTAS
Segn Bernabeu (2010) se han desarrollado muchas herramientas
19
para la produccin de consultas y reportes, que ofrecen a los usuarios, a

travs de pantallas grcas intuitivas, la posibilidad de generar informes
avanzados y detallados del tema de inters que se est analizando.
Actualmente las herramientas de generacin de reportes y consultas
cuentan con muchas prestaciones, las cuales permiten dar variadas formas
y formatos a la presentacin de la informacin. Entre las opciones ms
comunes se encuentran las siguientes:
i.
Parametrizacin de los datos devueltos.
ii.
Seleccin de formatos de salida (planilla de clculo, HTML, PDF, etc.).
iii.
Inclusin de grcos de tortas, barras, etc.
iv.
Utilizacin de plantillas de formatos de fondos.
v.
Inclusin de imgenes.
vi.
Formatos tipogrcos.
vii.
Links a otros reportes.
2.5.6.2 OLAP (ON LINE ANALYTIC PROCESSING)

El procesamiento analtico en lnea OLAP, es la componente ms
poderosa del Data Warehousing, ya que es el motor de consultas
especializado del depsito de datos. Las herramientas OLAP, son una
tecnologa de software para anlisis en lnea, administracin y ejecucin de
consultas, que permiten inferir informacin del comportamiento del
negocio. Su principal objetivo es el de brindar rpidas respuestas a
complejas preguntas, para interpretar la situacin del negocio y tomar
decisiones. Cabe destacar que lo que es realmente interesante en OLAP,
no es la ejecucin de simples consultas tradicionales, sino la posibilidad de
utilizar operadores tales como drill-up, drill-down, etc, para explotar
profundamente la informacin. (Bernabeu, 2010).
2.5.7
USUARIOS
Los usuarios que posee el Data Warehouse son aquellos que se
encargan de tomar decisiones y de planicar las actividades del negocio,

20
es por ello que se hace tanto nfasis en la integracin, limpieza de datos,

etc, para poder conseguir que la informacin posea toda la calidad
posible. (Bernabeu, 2010).
2.6
DATA MART
Segn Lane (1999) es una forma ms sencilla de un Data Warehouse
que est enfocado a una sola rea funcional tales como ventas, finanzas o
mercadeo. Debido a que se centra nicamente en una sola rea, los
Datamart se constituyen de menor cantidad de fuentes de datos que los
Data Warehouse, las cuales pueden ser sistemas operacionales internos o
un Data Warehouse interno o externo.
Es un subconjunto de los datos del Data Warehouse cuyo objetivo es
responder a un determinado anlisis, funcin o necesidad, con una
poblacin de usuarios especifica. Al igual que un Data Warehouse, los datos
estn estructurados en modelos de estrella o copo de nieve, y un Data Mart
puede ser dependiente o independiente de un Data Warehouse. (Curto,
2010).
TIPOS DE DATA MART
Existen dos tipos de Data Mart, los dependientes e independientes:
1.
DEPENDIENTES
Son los que se construyen a partir de un Data Warehouse central, es
decir reciben sus datos de un repositorio empresarial central.
21
Figura 2.6.1: Datamart dependiente.

2.
INDEPENDIENTES
Son aquellos Data Mart que no dependen de un Data Warehouse
central, ya que pueden recibir los datos directamente del ambiente

operacional, ya sea mediante procesos internos de las fuentes de datos o
de almacenes de datos operacionales (ODS).
Figura 2.6.2: Datamart independiente.

2.7
METODOLOGIA HEFESTO
2.7.1
DEFINICIN
HEFESTO es una metodologa propia, cuya propuesta est
fundamentada en una muy amplia investigacin, comparacin de

metodologas existentes, experiencias propias en procesos de confeccin
de almacenes de datos. Cabe destacar que HEFESTO est en continua
22
evolucin, y se han tenido en cuenta, como gran valor agregado, todos los
feedbacks que han aportado quienes han utilizado esta metodologa en
diversos pases y con diversos nes. (Bernabeu, 2010).
Figura 2.7.1: Metodologa HEFESTO, pasos. (Bernabeu, 2010).

Como se puede apreciar, se comienza recolectando las necesidades de
informacin de los usuarios y se obtienen las preguntas claves del negocio.
Luego, se deben identicar los indicadores resultantes de los interrogativos
y sus respectivas perspectivas de anlisis, mediante las cuales se construir
23
el modelo conceptual de datos del Data Warehouse. Despus, se

analizarn los OLTP para determinar cmo se construirn los indicadores,
sealar las correspondencias con los datos fuentes y para seleccionar los
campos de estudio de cada perspectiva. Una vez hecho esto, se pasar a
la construccin del modelo lgico del depsito, en donde se definir cul
ser el tipo de esquema que se implementar. Seguidamente, se
confeccionarn las tablas de dimensiones y las tablas de hechos, para
luego efectuar sus respectivas uniones. Por ltimo, utilizando tcnicas de
limpieza y calidad de datos, procesos ETL, etc, se definirn polticas y
estrategias para la Carga Inicial del Data Warehouse y su respectiva
actualizacin. (Bernabeu, 2010).
2.7.2
CARACTERISTICAS
Esta metodologa cuenta con las siguientes caractersticas:
i.
Los objetivos y resultados esperados en cada fase se distinguen

fcilmente y son sencillos de comprender.
ii.
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.
iii.
Reduce la resistencia al cambio, ya que involucra a los usuarios nales

en
cada
etapa
para
que
tome
decisiones
respecto
al
comportamiento y funciones del Data Warehouse.

iv.
Utiliza modelos conceptuales y lgicos, los cuales son sencillos de

interpretar y analizar.
v.
Es independiente del tipo de ciclo de vida que se emplee para

contener la metodologa.
vi.
Es independiente de las herramientas que se utilicen para su

implementacin.
vii.
Es independiente de las estructuras fsicas que contengan el Data

Warehouse y de su respectiva distribucin.
viii.
Cuando se culmina con una fase, los resultados obtenidos se

convierten en el punto de partida para llevar a cabo el paso
24
siguiente.
ix.
2.7.3
Se aplica tanto para Data Warehouse como para Data Mart.

PASOS DE LA METODOLOGIA
2.7.3.1 ANALISIS DE REQUERIMIENTOS

Lo primero que se har ser identicar los requerimientos de los
usuarios a travs de preguntas que especifiquen los objetivos de su
organizacin. Luego, se analizarn estas preguntas a n de identicar cules
sern los indicadores y perspectivas que sern tomadas en cuenta para la
construccin del DATA WAREHOUSE. Finalmente se confeccionar un
modelo conceptual en donde se podr visualizar el resultado obtenido en
este primer paso. (Bernabeu, 2010).
A.
IDENTIFICAR PREGUNTAS
El primer paso comienza con el acopio de las necesidades de
informacin, el cual puede llevarse a cabo a travs de muy variadas y

diferentes tcnicas, cada una de las cuales poseen caractersticas
inherentes y especcas, como por ejemplo entrevistas, cuestionarios,
observaciones, etc. El anlisis de los requerimientos de los diferentes
usuarios, es el punto de partida de esta metodologa, ya que ellos son los
que deben, en cierto modo, guiar la investigacin hacia un desarrollo que
reeje claramente lo que se espera del depsito de datos, en relacin a sus
funciones y cualidades. El objetivo principal de esta fase, es la de obtener e
identicar las necesidades de informacin clave de alto nivel, que es
esencial para llevar a cabo las metas y estrategias de la empresa, y que
facilitar una ecaz y eciente toma de decisiones. (Bernabeu, 2010).
B.
IDENTIFICAR INDICADORES Y PERSPECTIVAS

Una vez que se han establecido las preguntas de negocio, se debe
proceder a su descomposicin para descubrir los indicadores que se

utilizarn y las perspectivas de anlisis que intervendrn. Para ello, se debe
tener en cuenta que los indicadores, para que sean realmente efectivos
25
son, en general, valores numricos y representan lo que se desea analizar

concretamente, por ejemplo: saldos, promedios, cantidades, sumatorias,
frmulas, etc. En cambio, las perspectivas se reeren a los objetos mediante
los cuales se quiere examinar los indicadores, con el n de responder a las
preguntas planteadas, por ejemplo: clientes, proveedores, sucursales,
pases, productos, rubros, etc. Cabe destacar, que el Tiempo es muy
comnmente una perspectiva. (Bernabeu, 2010).
C.
MODELO CONCEPTUAL
En esta etapa, se construir un modelo conceptual a partir de los
indicadores y perspectivas obtenidas en el paso anterior. A travs de este

modelo, se podr observar con claridad cules son los alcances del
proyecto, para luego poder trabajar sobre ellos, adems al poseer un alto
nivel de denicin de los datos, permite que pueda ser presentado ante los
usuarios y explicado con facilidad. (Bernabeu, 2010).
La representacin grca del modelo conceptual es la siguiente:
Figura 2.7.2: Modelo conceptual. (Bernabeu, 2010).

A la izquierda se colocan las perspectivas seleccionadas, que sern unidas
a un valo central que representa y lleva el nombre de la relacin que existe
entre ellas. La relacin, constituye el proceso o rea de estudio elegida. De
dicha relacin y entrelazadas con flechas, se desprenden los indicadores,
estos se ubican a la derecha del esquema. (Bernabeu, 2010).
26
2.7.3.2 ANLISIS DE LOS OLTP

Seguidamente, se analizarn las fuentes OLTP para determinar
cmo sern 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 denirn qu campos se incluirn en cada
perspectiva. Finalmente, se ampliar el modelo conceptual con la
informacin obtenida en este paso. (Bernabeu, 2010).
A.
CONFORMAR INDICADORES
En este paso se debern explicitar cmo se calcularn los
indicadores, deniendo los siguientes conceptos para cada uno de ellos:

(Bernabeu, 2010).
i.
Hecho/s que lo componen, con su respectiva frmula de clculo.

Por ejemplo: Hecho1 + Hecho2.
ii.
Funcin de sumarizacin que se utilizar para su agregacin. Por

ejemplo: SUM, AVG, COUNT, etc.
B.
ESTABLECER CORRESPONDENCIAS
El objetivo de este paso, es el de examinar los OLTP disponibles que
contengan la informacin requerida, como as tambin sus caractersticas,

para poder identicar las correspondencias entre el modelo conceptual y
las fuentes de datos. La idea es, que todos los elementos del modelo
conceptual estn correspondidos en los OLTP. (Bernabeu, 2010).
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 ltrarn los indicadores.
Para ello, basndose en las correspondencias establecidas en el paso
anterior, se debe presentar a los usuarios los datos de anlisis disponibles
para cada perspectiva. Es muy importante conocer en detalle que signica
cada campo y/o valor de los datos encontrados en los OLTP, por lo cual, es
27
conveniente investigar su sentido, ya sea a travs de diccionarios de datos,

reuniones con los encargados del sistema, anlisis de los datos propiamente
dichos, etc. Luego de exponer frente a los usuarios los datos existentes,
explicando su signicado, valores posibles y caractersticas, estos deben
decidir cules son los que consideran relevantes para consultar los
indicadores y cules no. (Bernabeu, 2010).
D.
MODELO CONCEPTUAL AMPLIADO

En este paso, y con el n de gracar 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. Grcamente: (Bernabeu, 2010).
Figura 5.7.3: Modelo Conceptual ampliado. (Bernabeu, 2010).

2.7.3.3 MODELO LGICO DEL DATA WAREHOUSE
A continuacin, se confeccionar el modelo lgico de la estructura
del Data Warehouse, teniendo como base el modelo conceptual que ya
ha sido creado. Para ello, primero se denir el tipo de modelo que se
utilizar y luego se llevarn a cabo las acciones propias al caso, para
disear las tablas de dimensiones y de hechos. Finalmente, se realizarn las
uniones pertinentes entre estas tablas. (Bernabeu, 2010).
A.
TIPO DE MODELO LGICO DEL DATA WAREHOUSE

Se debe seleccionar cul ser el tipo de esquema que se utilizar
28
para contener la estructura del depsito de datos, que se adapte mejor a

los requerimientos y necesidades de los usuarios. Es muy importante denir
objetivamente si se emplear un esquema en estrella o copo de nieve, ya
que esta decisin afectar considerablemente la elaboracin del modelo
lgico. (Bernabeu, 2010).
B.
TABLAS DE DIMENSIONES
En este paso se deben disear las tablas de dimensiones que
formaran parte del DATA WAREHOUSE. Para los tres tipos de esquemas,
cada perspectiva denida en el modelo conceptual constituir una tabla
de dimensin. Para ello deber tomarse cada perspectiva con sus campos
relacionados y realizarse el siguiente proceso: (Bernabeu, 2010).
iii.
Se elegir un nombre que identique la tabla de dimensin.
iv.
Se aadir un campo que represente su clave principal.
v.
Se redenirn los nombres de los campos si es que no son lo

sucientemente intuitivos.
Figura 2.7.4: Diseo de tablas de dimensiones. (Bernabeu, 2010).

C.
TABLAS DE HECHOS
En este paso, se denirn las tablas de hechos, que son las que contendrn
los hechos a travs de los cuales se construirn los indicadores de estudio.
Para los esquemas en estrella y copo de nieve, se realizar lo siguiente:
vi.
Se le deber asignar un nombre a la tabla de hechos que represente

la informacin analizada, rea de investigacin, negocio enfocado,
etc.
vii.
Se denir su clave primaria, que se compone de la combinacin

29
de las claves primarias de cada tabla de dimensin relacionada.

viii.
Se crearn tantos campos de hechos como indicadores se hayan

denido en el modelo conceptual y se les asignar los mismos
nombres que estos. En caso que se preera, podrn ser nombrados
de cualquier otro modo.
Figura 2.7.5: diseo de tabla de hechos. (Bernabeu, 2010).

D.
UNIONES
Para los tipos de esquemas, se realizarn las uniones
correspondientes entre sus tablas de dimensiones y sus tablas de hechos.

(Bernabeu, 2010).
2.7.3.4 INTEGRACIN DE DATOS
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 denirn las reglas y polticas para su respectiva
actualizacin, as como tambin los procesos que la llevarn a cabo.
(Bernabeu, 2010).
A.
CARGA INICIAL
Debemos en este paso realizar la Carga Inicial al DATA
WAREHOUSE, poblando el modelo de datos que hemos construido

anteriormente. Para lo cual debemos llevar adelante una serie de tareas
bsicas, tales como limpieza de datos, calidad de datos, procesos ETL, etc.
30
La realizacin de estas tareas puede contener una lgica realmente

compleja en algunos casos. Afortunadamente, en la actualidad existen
muchos softwares que se pueden emplear a tal n, y que nos facilitarn el
trabajo. Se debe evitar que el DATA WAREHOUSE sea cargado con valores
faltantes o anmalos, as como tambin se deben establecer condiciones
y restricciones para asegurar que solo se utilicen los datos de inters.
(Bernabeu, 2010).
B.
ACTUALIZACIN
Segn Bernabeu (2010) cuando se haya cargado en su totalidad el
Data Warehouse, 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:
i.
Especicar las tareas de limpieza de datos, calidad de datos,

procesos ETL, etc., que debern realizarse para actualizar los datos
del Data Warehouse.
ii.
Especicar de forma general y detallada las acciones que deber

realizar cada software.
31
CAPTULO III
RESULTADOS
3.1
PROBLEMTICA
Una empresa distribuidora de servicios en telecomunicaciones
mviles tiene como funciones principales la compra mayorista y venta

minorista de productos, siendo principalmente su margen de ganancia la
diferencia entre el costo del producto y el precio de venta al pblico. Los
productos que ofrece una empresa de este tipo varan constantemente en
el tiempo, ya que se basa en tecnologa y tendencias.
El rea de ventas es importante ya que se encarga de finalizar el proceso
que hace efectivo el negocio. Las decisiones que se toman actualmente
en esta rea generalmente son en base a la experiencia y a los datos de
las compras y ventas realizadas diariamente.
Los principales problemas identificados para el rea de ventas son:
i.
Inadecuado Contraste de la informacin.
ii.
Identificar la comisin que le corresponde a cada empleado por las

ventas realizadas
iii.
Identificar los productos que menos se venden.
iv.
Ortodoxo seguimiento de las ventas diarias.
v.
Desatinada proyeccin de las ventas.
3.2
SOLUCIN DESARROLLADA
La inteligencia de negocios es una herramienta de informacin
estratgica que ayuda a las empresas a la toma de decisiones en las reas

de marketing, finanzas, operaciones, logstica, administracin, recursos
humanos, entre otras reas, por medio del anlisis de los datos, brindando
informacin disponible y rpida, permitiendo detectar fallas en los procesos,
descubriendo oportunidades de negocio y cuantificando relaciones con
32
proveedores y clientes. Este tipo de solucin se basa en la extraccin de

datos de diversas fuentes, transformndolas y almacenndolas en un
repositorio, desde el cual se genera informacin mediante reportes para los
usuarios finales.
Luego de identificado el problema de falta de informacin slida para
toma de decisiones en el rea de ventas de INTERCEL, se plantea como
solucin la implementacin de un Data Mart de ventas el cual es una
herramientas de inteligencia de negocios que se desarrollara para el
presente proyecto.
33
Figura 3.2.1: Antes y despus de la implementacin de una solucin de

inteligencia de negocios (Saima Solutions, 2013).
Entre
los
benecios
ms
importantes
que
BI
proporciona
las
organizaciones, vale la pena destacar los siguientes:

i.
Reduce el tiempo mnimo que se requiere para recoger toda la

informacin relevante de un tema en particular, ya que la misma se
34
encontrar integrada en una fuente nica de fcil acceso.

ii.
Automatiza la asimilacin de la informacin, debido a que la

extraccin y carga de los datos necesarios se realizar a travs de
procesos predenidos.
iii.
Proporciona
herramientas
de
anlisis
para
establecer
comparaciones y tomar decisiones.

iv.
Cierra el crculo que hace pasar de la decisin a la accin.
v.
Permite a los usuarios no depender de reportes o informes

programados, porque los mismos sern generados de manera
dinmica.
vi.
Posibilita la formulacin y respuesta de preguntas que son claves

para el desempeo de la organizacin.
vii.
Permite acceder y analizar directamente los indicadores de xito.
viii.
Se pueden identicar cules son los factores que inciden en el buen

o mal funcionamiento de la organizacin.
ix.
Se podrn detectar situaciones fuera de lo normal.
x.
Permitir predecir el comportamiento futuro con un alto porcentaje

de certeza, basado en el entendimiento del pasado.
xi.
Los usuarios podrn consultar y analizar los datos de manera sencilla

e intuitiva.
3.3
PASOS DE LA METODLOGIA HEFESTO
3.3.1
ANALISIS DE REQUERIMIENTOS
3.3.1.1 IDENTIFICAR PREGUNTAS

Para simplicar esta tarea se les present a los usuarios una serie de
ejemplos concretos de otros casos similares. Las preguntas de negocio
obtenidas fueron las siguientes:
i.
Se desea conocer cuntas 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.
35
ii.
Se desea conocer cul fue el monto total de ventas de productos a

cada cliente en un periodo determinado. O en otras palabras:
Monto total de ventas de los productos a cada cliente en un
tiempo determinado.
iii.
Se desea conocer cul fu el monto total de ventas de un empleado

en un periodo determinado. O en otras palabras: Monto total de
ventas de los producto por cada empleado de cada oficina en un
tiempo determinado.
iv.
Se desea saber cuntas unidades de producto se han vendido en

cada oficina: Unidades vendidas de cada producto por cada
oficina en un tiempo determinado.
v.
Se desea saber cuntas unidades de producto se han vendido con

un tipo de acuerdo de pago determinado en un tiempo
determinado: Unidades vendidas de cada producto por tipo de
acuerdo de pago en un tiempo determinado.
vi.
Se desea saber cuntas unidades de producto se han vendido de

cada marca y modelo: Unidades vendidas de cada producto de
cada marca y modelo en un tiempo determinado.
Debido a que la dimensin Tiempo es un elemento fundamental en el DW,

se hizo hincapi en l. Adems, se puso mucho nfasis en dejar en claro a
los usuarios, a travs de ejemplos prcticos, que es este componente el que
permitir tener varias versiones de los datos a n de realizar un correcto
anlisis posterior.
3.3.1.2 IDENTIFICAR INDICADORES Y PERSPECTIVAS
A continuacin, se analizarn las preguntas obtenidas en el paso
anterior y se detallarn cules son sus respectivos indicadores y
36
perspectivas.
Unidades vendidas de cada producto a cada cliente en un tiempo determinado

INDICADOR
PERSPECTIVAS
Monto total de ventas de los productos a cada cliente en un tiempo determinado.

INDICADOR
PERSPECTIVAS
Monto total de ventas de los producto por cada empleado de cada oficina en un tiempo
INDICADOR
PERSPECTIVAS
determinado.
En sntesis, los indicadores son:

i.
ii.
Unidades vendidas.
Monto total de ventas.
Y las perspectivas de anlisis son:

i.
ii.
iii.
iv.
v.
vi.
vii.
viii.
Clientes.
Productos.
Empleados.
Oficina.
Marca
Modelo
Acuerdo de pago
Tiempo.
3.3.1.3 MODELO CONCEPTUAL

El modelo conceptual resultante de los datos que se han
recolectado, es el siguiente:
37
PRODUCTO
MARCA
UNIDADES
VENDIDAS
EMPLEADO
MONTO TOTAL
DE VENTAS
CLIENTE
VENTAS
OFICINA
MODELO
FECHA
ACUERDO DE
PAGO
Figura 3.3.1: Modelo conceptual inicial.

3.3.2
ANLISIS DE LOS OLTP
3.3.2.1 CONFORMAR INDICADORES

Los indicadores se calcularn de la siguiente manera:
Unidades Vendidas:
Hechos: Unidades Vendidas.
Funcin de sumarizacin: SUM.
Aclaracin: el indicador Unidades Vendidas representa la sumatoria de
las unidades que se han vendido de un producto en particular.
Monto Total de Ventas:
Hechos: (Unidades Vendidas) * (Precio de Venta).
Funcin de sumarizacin: SUM.
Aclaracin: 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.
3.3.2.2 ESTABLECER CORRESPONDENCIAS
En el OLTP de la empresa analizada, el proceso de venta est
representado por el diagrama de entidad relacin de la siguiente gura.
38
MARCA (Inventario)
OFICINA (Maestro)
OficinaId
EMPLEADO (RRHH)
Organizacion_Id
EmpleadoId
Direccion_Id
Persona_Id
Empleado_Id
Denominacion
ARTICULO (Inventario)
CLIENTE (Ventas)
ClienteId
Descripcion
Organizacion_Id
Telefono
Persona_Id
IndPrincipal
IndCredito
UsuarioRegistra_Id
Estado
UsuarioActualiza_Id
UsuarioRegistra_Id
FechaRegistra
UsuarioActualiza_Id
FechaActualiza
FechaRegistra
Estado
FechaActualiza
CodigoCliente
Organizacion_Id
EmpleadoSuperior_Id
IndTercero
Cargo_Id
Estado
UsuarioRegistra_Id
UsuarioActualiza_Id
FechaRegistra
FechaActualiza
Organizacion_Id
OrdenVenta_Id
DocVentaOrigen_Id
TipoCobro_Id
EstadoCobro_Id
Moneda_Id
Empleado_Id
Oficina_Id
SerieDocumento
NumeroDocumento
SerieDocManual
NroDocManual
SubTotal
TotalDescuento
TotalImpuesto
TotalNeto
SerieDetOrdenVenta_Id
Articulo_Id
Cantidad
Descripcion
Estado
Marca_Id
UsuarioRegistra_Id
TipoArticulo_Id
UsuarioActualiza_Id
CodArticulo
FechaRegistra
Denominacion
FechaActualiza
Descripcion
IndMigracion
IndPerecible
IndImportado
IndTieneCodigoBarras
IndTieneMarca
DETDOCUMENTOVENTA (Ventas)
DetOrdenVentaOrigen_I...
Descripcion
Modelo_Id
IndTieneModelo
Ruc
DetOrdenVenta_Id
Denominacion
TipoControlInventario_Id
IndExoneraIgv
Oficina_Id
FechaIngreso
TipoDocumento_Id
Fabricante_Id
UnidadMedidaBase_Id
Imagen
IndDescuento
CondicionLaboral_Id
DocumentoVentaId
Organizacion_Id
Organizacion_Id
CodFabrica
CategoriaEmpleado_Id
DOCUMENTOVENTA (Ventas)
IndVentaRapida
IndPromocion
Estado
UsuarioRegistra_Id
UsuarioActualiza_Id
FechaRegistra
FechaActualiza
ValorVenta
Descuento
SubtotalSinIGV
MarcaId
ArticuloId
MODELO (Inventario)
AcuerdoPago_Id
Articulo_Id
Fabricante_Id
Modelo_Id
Denominacion
Moneda_Id
Descripcion
Monto
Estado
PctIniDescuento
UsuarioRegistra_Id
PctFinDescuento
UsuarioActualiza_Id
Estado
FechaRegistra
UsuarioRegistra_Id
FechaActualiza
UsuarioActualiza_Id
IndMigracion
FechaRegistra
FechaActualiza
ListaPrecioMovil_Id
Articulo_Id
Observacion
UnidadMedida_Id
Estado
DetOrdenVentaOrigen_Id
UsuarioRegistra_Id
Cantidad
UsuarioActualiza_Id
Descripcion
FechaRegistra
ValorVenta
FechaActualiza
Descuento
SubtotalSinIGV
ListaPrecioMovilId
Marca_Id
DETORDENVENTA (Ventas)
SubtotalconIGV
LISTAPRECIOMOVIL (Ventas)
ModeloId
ACUERDOPAGO (Ventas)
AcuerdoPagoId
TipoClienteTipoVenta_Id
PlanPago_Id
PlazoPago_Id
Figura 3.3.2: Diagrama entidad relacin del OLTP.

A continuacin, se expondr la correspondencia entre los dos modelos:
Figura 3.3.3: Correspondencia.

39
Las relaciones identificadas fueron las siguientes:

i.
La tabla ARTICULO se relaciona con la perspectiva PRODUCTO.
ii.
La tabla CLIENTE con la perspectiva CLIENTE.
iii.
La tabla EMPLEADO con la perspectiva EMPLEADO.
iv.
La tabla OFICINA con la perspectiva OFICINA.
v.
La tabla MARCA con la perspectiva MARCA.
vi.
La tabla ACUERDOPAGO con la perspectiva ACUERDO DE

PAGO.
vii.
La tabla MODELO con la perspectiva MODELO.
viii.
El campo FechaRegistra de la tabla DETDOCUMENTOVENTA con

la perspectiva Tiempo (debido a que es la fecha principal en el
proceso de venta).
ix.
El campo cantidad de la tabla DETDOCUMENTOVENTA con el

indicador Unidades Vendidas.
x.
El
campo cantidad de la tabla
DETDOCUMENTOVENTA
multiplicado por el campo ValorVenta de la misma tabla, con el

indicador Monto Total de Ventas.
3.3.2.3 NIVEL DE GRANULARIDAD
De acuerdo a las correspondencias establecidas, se analizaron los
campos residentes en cada tabla a la que se haca referencia, a travs de
la examinacin de la base de datos para intuir los significados de cada
campo.
Con respecto a la perspectiva MARCA los datos disponibles son los
siguientes:
i.
MarcaId: es la clave primaria de la tabla Marca y representa

inequvocamente a una marca en particular.
ii.
Organizacion_Id: representa a travs de una clave fornea el

nombre de la organizacin en la cual se registra la marca. Por
40
ejemplo: SMART BUSINESS E.I.R.L.

iii.
Fabricante_Id: representa a travs de una clave fornea el nombre

del fabricante de la marca. Por ejemplo: Sansung, LG, etc.
iv.
Denominacion: nombre de la marca.
v.
Descripcion: contiene una descripcin breve de la marca.
vi.
Estado: seala si la marca se encuentra activa o no.
vii.
UsuarioRegistra_Id: representa a travs de una clave fornea el

nombre del usuario que registra los datos de la marca.
viii.
UsuarioActualiza_Id: representa a travs de una clave fornea el

nombre del usuario que actualiza los datos de la marca.
ix.
FechaRegistra: fecha en la que se hace el registro de los datos de la

marca.
x.
FechaActualiza: fecha en la que se hace la actualizacin de los

datos de la marca.
Con respecto a la perspectiva MARCA los datos disponibles son los

siguientes:
i.
ModeloId: es la clave primaria de la tabla Modelo y representa

inequvocamente a un modelo en particular.
ii.
Marca_Id: representa a travs de una clave fornea el nombre de

la marca.
iii.
Fabricante_Id: representa a travs de una clave fornea el nombre

del fabricante de la marca.
iv.
Denominacion: nombre del modelo.
v.
Descripcion: descripcin breve del modelo.
vi.
Estado: seala si el modelo se encuentra activa o no.
vii.

nombre del usuario que registra los datos del modelo.
viii.

nombre del usuario que actualiza los datos del modelo.
ix.
FechaRegistra: fecha en la que se hace el registro de los datos del

41
modelo.
xi.

datos del modelo.
Con respecto a la perspectiva ACUERDO DE PAGO los datos disponibles

son los siguientes:
i.
AcuerdoPagoId: E s la clave primaria de la tabla AcuerdoPago y

representa inequvocamente a un acuerdo de pago en particular.
ii.
TipoClienteTipoVenta_Id: representa a travs de una clave fornea

el tipo de cliente por ejemplo customer, distribuidor, etc.
iii.
PlanPago_Id: representa a travs de una clave fornea el tipo de

plan de pago. Por ejemplo: RPC 45, Smart Total, etc.
iv.
PlazoPago_Id: representa a travs de una clave fornea el tipo de

plazo de pago. Por ejemplo: 6 meses, 12 meses, etc.
v.
Denominacion: nombre del acuerdo de pago.
vi.
Estado: seala si el acuerdo de pago se encuentra activa o no.
vii.

nombre del usuario que registra los datos del acuerdo de pago.
viii.

nombre del usuario que actualiza los datos del acuerdo de pago.
ix.
FechaRegistra: fecha en la que se hace el registro de los datos del

acuerdo de pago.
x.

datos del acuerdo de pago.
Con respecto a la perspectiva Producto los datos disponibles son los

siguientes:
i.
ArticuloId: Es la clave primaria de la tabla Articulo y representa

inequvocamente a un artculo en particular.
ii.

42

iii.
UnidadMedidaBase_Id: representa a travs de una clave fornea el

tipo de unidad de medida. Por ejemplo UNIDAD.
iv.
TipoControlInventario_Id: representa a travs de una clave fornea

el tipo de control de inventario. Por ejemplo Primero en entrar
primeros en salir.
v.
Modelo_Id: representa a travs de una clave fornea el nombre del

modelo.
vi.
Marca_Id: representa a travs de una clave fornea el nombre de

la marca.
vii.
TipoArticulo_Id: representa a travs de una clave fornea el tipo de

artculo. Por ejemplo equipo, tarjeta fsica, chip, etc.
viii.
CodArticulo: es una denominacin del artculo, resumiendo a sus

letras iniciales de la marca y numero del modelo.
ix.
Denominacion: nombre del artculo.
x.
Descripcion: descripcion breve sobre el artculo.
xi.
IndExoneraIgv: indica si el articulo esta exonerada del IGV.
xii.
IndTieneModelo: indica si el artculo tiene un modelo o no.
xiii.
IndPerecible: indica si el artculo es perecible o no.
xiv.
IndImportado: indica si el articulo ha sido importado o no.
xv.
IndTieneCodigoBarras: indica si el artculo tiene cdigo de barras.
xvi.
IndTieneMarca: indica si el artculo tiene una marca o no.
xvii.
IndVentaRapida: indica si el producto puede venderse sin pasar por

caja.
xviii.
IndPromocion: indica si el producto est en promocin o no.
xix.
Estado: indica si el producto se encuentra disponible o no.
xx.

nombre del usuario que registra los datos del producto.
xxi.

nombre del usuario que actualiza los datos del producto.
xxii.
FechaRegistra: fecha en la que se hace el registro de los datos.
xxiii.

43
datos.
Con respecto a la perspectiva EMPLEADO los datos disponibles son los
siguientes:
i.
EmpleadoId: es la clave primaria de la tabla empleado y representa

inequvocamente a un empleado.
ii.
Persona_Id: representa a travs de una clave fornea los datos

personales del empleado.
iii.

iv.
EmpleadoSuperior_Id: representa a travs de una clave fornea que

empleado es su superior.
v.
IndTercero: indica si el empleado es de terceros o no.
vi.
Cargo_Id: representa a travs de una clave fornea el tipo de

cargo.
vii.
Estado: indica si el empleado est activo o no.
viii.
IndDescuento: indica si se le ha hecho un descuento al empleado.
ix.
Oficina_Id: representa a travs de una clave fornea a que oficina

pertenece el empleado.
x.
CondicionLaboral_Id: representa a travs de una clave fornea la

condicin bajo la cual labora el empleado.
xi.
FechaIngreso: fecha en la que el empeado ingresa a trabajr a la

empresa.
xii.
Ruc: nmero de ruc del empleado.
xiii.
Observacion: descripcin de alguna observacin que se le pudiera

hacer al empleado.
Con respecto a la perspectiva CLIENTE los datos disponibles son los

siguientes:
44
i.
ClienteId: es la clave primaria de la tabla Cliente y representa

inequvocamente a un cliente en particular.
ii.

iii.
Persona_Id: representa a travs de una clave fornea los datos

personales del cliente.
iv.
IndCredito: indica si el cliente tiene crdito para comprar en la

tienda.
v.
Estado: indica si el cliente est activo o no.
Con respecto a la perspectiva OFICINA los datos disponibles son los

siguientes:
i.
OficinaId: es la clave primaria de la tabla oficina y representa

inequvocamente a una oficina.
ii.

iii.
Direccion_Id: representa a travs de una clave fornea el nombre

de la direccin donde est ubicada la oficina.
iv.
Empleado_Id: representa a travs de una clave fornea el nombre

del empleado a cargo de la oficina.
v.
Denominacion: nombre de la oficina.
vi.
Descripcion: descripcin breve de la oficina.
vii.
Telefono: telfono de la oficina.
viii.
IndPrincipal: indica si es la oficina principal o no.
ix.
Estado: indica si la oficina est funcionando o no.
Con respecto a la perspectiva Fecha, que es la que determinar la

granularidad del depsito de datos, los datos ms tpicos que pueden
emplearse son los siguientes:
45
i.
Ao.
ii.
Semestre.
iii.
Cuatrimestre.
iv.
Trimestre.
v.
Nmero de mes.
vi.
Nombre del mes.
vii.
Quincena.
viii.
Semana.
ix.
Nmero de da.
x.
Nombre del da.
Una vez que se recolect toda la informacin pertinente y se consult con

los usuarios cuales eran los datos que consideraban de inters para analizar
los indicadores ya expuestos, los resultados obtenidos fueron los siguientes:
i.
Perspectiva CLIENTE:
NombreCompleto de la tabla Persona. Ya que este hace
referencia al nombre del cliente. Este campo es obtenido a travs
de la unin con la tabla Cliente.
ii.
Perspectiva PRODUCTO:
Denominacion de la tabla Articulo. Ya que este hace referencia
al nombre del producto.
Marca de la tabla Marca. Ya que esta hace referencia a la
marca a la que pertenece el producto. Este campo es obtenido a
travs de la unin con la tabla Articulo
Modelo de la tabla Modelo. Ya que esta hace referencia al
modelo del producto. Este campo es obtenido a travs de la unin
con la tabla Articulo
Como se nota la perspectiva PRODUCTO agrego como indicadores a las

perspectivas MARCA y MODELO debido a que se consider que esto
46
provocara un mejor anlisis de la informacin.

iii.
Perspectiva OFICINA:
Denominacion de la tabla Oficina. Ya que esta hace referencia
al nombre de la oficina.
Ubigeo de la tabla Ubigeo. Ya que esta hace referencia al
nombre de la ciudad donde est ubicada la oficina. Este campo es
obtenido a travs de la unin de tres tablas las cuales son: Oficina,
Direccion y Ubigeo.
iv.
Perspectiva EMPLEADO
NombreCompleto de la tabla Persona. Ya que este hace
referencia al nombre del empleado. Este campo es obtenido a
travs de la unin con la tabla Cliente.
Cargo de la tabla Cargo. Ya que este hace referencia al
nombre del cargo que ocupa el empleado. Este campo es obtenido
a travs de la unin con la tabla Empleado.
v.
Perspectiva ACUERDO DE PAGO

PlanPago de la tabla PlanPago. Ya que esta hace referencia al
nombre del plan de pago. Este campo es obtenido a travs de la
unin con la tabla AcuerdoPago.
PlazoPago de la tabla PlazoPago. Ya que esta hace referencia
al nombre del plazo de pago. Este campo es obtenido a travs de
la unin con la tabla AcuerdoPago.
vi.
Perspectiva FECHA:
Dia .Referido al nombre del da.
Semana.
Mes. Referido al nombre del mes.
Trimestre.
Semestre
47
Ao.
3.3.2.4 MODELO CONCEPTUAL AMPLIADO
Teniendo esto en cuenta, se completar el diseo del diagrama
conceptual:
PRODUCTO
ACUERDO DE
PAGO
Denominacion
Marca
Modelo
UNIDADES
VENDIDAS
PlanPago
PlazoPago
EMPLEADO
SUM(unidades vendidas)
VENTAS
nombreCompleto
Cargo
CLIENTE
nombreCompleto
OFICINA
FECHA
Dia
Semana
Mes
Trimestre
Semestre
Ao
MONTO TOTAL
DE VENTAS
SUM(unidades vendidas *
precio de venta)
Denominacion
Ubigeo
Figura 3.3.4: modelo conceptual ampliado.

3.3.3
MODELO LGICO DEL DW
3.3.3.1 TIPO DE MODELO LGICO DEL DW

El esquema que se utilizar ser en estrella, debido a sus
caractersticas, ventajas y diferencias con los otros esquemas.
3.3.3.2 TABLAS DE DIMENSIONES
A continuacin, se disearan las tablas de dimensiones.
i.
Perspectiva CLIENTE:
La nueva tabla de dimensin tendr el nombre DIMCLIENTE.

Se le agregar una clave principal con el nombre idCliente.
Se modicar el nombre del campo nombreCompleto por Cliente.
Se puede apreciar el resultado de estas operaciones en la siguiente grca:
48
dm zdf
DIMCLIENTE
CLIENTE
column
*PK idCliente
* Cliente
nombreCompleto
Figura 3.3.5: Tabla de dimensin DIMCLIENTE.

ii.
PK
+ PK_DIMCLIENTE()
Perspectiva PRODUCTO:
La nueva tabla dimensin tendr el nombre de DIMPRODUCTO.

Se le agregara una clave principal con el nombre de idProducto.
Se modicar el nombre del campo Denominacion por Producto.
El nombre del campo Marca y Modelo no ser modificado.
dm zdf
DIMPRODUCTO
PRODUCTO
Denominacion
Marca
Modelo
column
*PK idProducto
*
Producto
*
Marca
*
Modelo
PK
+
PK_DIMPRODUCT O()
Figura 3.3.5: Tabla de dimensin DIMPRODUCTO.

iii.
Perspectiva OFICINA:
La nueva tabla dimensin tendr el nombre de DIMOFICINA.

Se le agregara una clave principal con el nombre de idOficina.
Se modificar el nombre del campo Denominacion por Oficina.
Se modificar el nombre del campo Ubigeo por Ciudad.
49
dm zdf
DIMOFICINA
OFICINA
column
*PK idOficina
*
Oficina
*
Ciudad
Denominacion
Ubigeo
PK
+
PK_DIMOFICINA()
Figura 3.3.6: Tabla Dimensin DIMOFICINA.

iv.
Perspectiva EMPLEADO
La nueva tabla de dimensin tendr el nombre DIMEMPLEADO.

Se le agregar una clave principal con el nombre idEmpleado.
Se modificara el nombre del campo nombreCompleto por Empleado.
El nombre del campo Cargo no se modificara.
dm zdf
DIMEMPLEADO
EMPLEADO
nombreCompleto
Cargo
column
*PK idEmpleado
*
Empleado
PK
+
PK_DIMEMPLEADO()
Figura 3.3.7: Tabla de dimensin DIMEMPLEADO.

v.
Perspectiva ACUERDO DE PAGO
La nueva tabla de dimensin tendr el nombre DIMACUERDOPAGO.

Se le agregar una clave principal con el nombre idAcuerdoPago.
El nombre de los campos PlanPago y PlazoPago no se modificara.
dm zdf
ACUERDO DE
PAGO
PlanPago
PlazoPago
Figura 3.3.8: Tabla de dimensin DIMEMPLEADO.
DIMACUERDOPAGO
column
*PK idAcuerdoPago
*
PlanPago
*
PlazoPago
PK
+
PK_DIMACUERDOPAGO()
50
vi.
Perspectiva FECHA:
La nueva tabla de dimensin tendr el nombre DIMFECHA.

Se le agregar una clave principal con el nombre idFecha.
El nombre los campos no sern modicados.
dm zdf
DIMFECHA
FECHA
Dia
Semana
Mes
Trimestre
Semestre
Ao
Figura 3.3.9: Tabla de dimensin DIMTI.
column
*PK idFecha
*
Dia
Semana
Mes
Trimestre
Semestre
Ao
PK
+
PK_DIMFECHA()
3.3.3.3 TABLAS DE HECHOS

A continuacin, se confeccionar la tabla de hechos:
La tabla de hechos tendr el nombre VENTAS.
Su clave principal ser la combinacin de las claves principales de las tablas
de dimensiones antes denidas: idCliente, idProducto,idEmpleado,
idAcuerdoPago, idOficina e idFecha.
Se crearn dos hechos, que se corresponden con los dos indicadores y
sern renombrados, Unidades Vendidas por Cantidad y Monto Total
de Ventas por MontoTotal.
En el grco siguiente se puede apreciar mejor este paso:
51
dm zdf
UNIDADES
VENDIDAS
VENTAS
SUM(unidades vendidas)
VENTAS
column
*PK idCliente
*PK idProducto
*PK idEmpleado
*PK idAcuerdoPago
*PK idOficina
*PK idFecha
Cantidad
MontoTotal
MONTO TOTAL
DE VENTAS
SUM(unidades vendidas *
precio de venta)
PK
+
PK_VENTAS(, , , , , )
Figura 3.3.10: Diseo de la tabla de hechos.

3.3.3.4 UNIONES
Se realizarn las uniones pertinentes, de acuerdo corresponda:
dm zdf
DIMOFICINA
column
*PK idOficina
*
Oficina
*
Ciudad
DIMPRODUCTO
column
*PK idProducto
*
Producto
*
Marca
*
Modelo
PK
+
PK_DIMPRODUCTO()
DIMFECHA
column
*PK idFecha
*
Dia
Semana
Mes
Trimestre
Semestre
Ao
PK
+
PK_DIMFECHA()
PK
+
PK_DIMOFICINA()
VENTAS
column
*PK idCliente
*PK idProducto
*PK idEmpleado
*PK idAcuerdoPago
*PK idOficina
*PK idFecha
Cantidad
MontoTotal
DIMCLIENTE
column
*PK idCliente
*
Cliente
PK
+
PK_DIMCLIENTE()
PK
+
PK_VENTAS(, , , , , )
DIMACUERDOPAGO
DIMEMPLEADO
column
*PK idEmpleado
*
Empleado
column
*PK idAcuerdoPago
*
PlanPago
*
PlazoPago
PK
+
PK_DIMACUERDOPAGO()
PK
+
PK_DIMEMPLEADO()
Figura 3.3.11: Uniones.
52
3.3.4
INTEGRACIN DE DATOS
3.3.4.1 CARGA INICIAL

Para simplicar la aplicacin, solo nos centraremos 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:
Figura 3.3.12: Carga Inicial

Las tareas que lleva a cabo este proceso son:
i.
Inicia la ejecucin de los pasos en el momento en que se le indique.
ii.
DIMCLIENTE: ejecuta el contenedor del flujo de datos que cargar

la dimensin CLIENTE, ms adelante se detallar el mismo.
iii.
DIMPRODUCTO: ejecuta el contenedor de flujo de datos que

cargar la dimensin PRODUCTO, ms adelante se detallar el
mismo.
iv.
DIMFECHA: ejecuta el contenedor de flujo de datos que cargar la

dimensin FECHA, ms adelante se detallar el mismo.
v.
DIMACUERDOPAGO: ejecuta el contenedor de flujo de datos que

cargar la dimensin ACUERDOPAGO, ms adelante se detallar el
mismo.
53
vi.
DIMOFICINA: ejecuta el contenedor de flujo de datos que cargar

la dimensin OFICINA, ms adelante se detallar el mismo.
vii.
DIMEMPLEADO: ejecuta el contenedor de flujo de datos que

cargar la dimensin EMPLEADO, ms adelante se detallar el
mismo.
viii.
VENTAS: ejecuta el contenedor de flujo de datos que cargar la

tabla de hechos VENTAS, ms adelante se detallar el mismo.
A continuacin, se especificaran las tareas llevadas a cabo por

"DIMCLIENTE". Este paso es un contenedor de flujo de datos, as que incluye
las siguientes tareas:
Figura 3.3.13: Carga de Dimensin CLIENTE.

1.
OLE DB Source: obtiene a travs de una consulta SQL los datos del
OLTP necesarios para cargar la dimensin CLIENTE.
SELECT Ventas.CLIENTE.ClienteId, Maestro.PERSONA.NombreCompleto

FROM
Maestro.PERSONA INNER JOIN Ventas.CLIENTE
ON Maestro.PERSONA.PersonaId = Ventas.CLIENTE.Persona_Id
where Ventas.CLIENTE.ClienteId is not null
Figura 3.3.13: Consulta SQL para obtener los datos de entrada de la

dimensin CLIENTE.
54
2.
Slowly Changing Dimension: recibe los datos de entrada y verifica

que los datos sean nuevos para insertarlos en la dimensin cliente.
3.
Insert Destination: almacena en la tabla DIMCLIENTE los datos

obtenidos en el paso anterior.
A continuacin, se especicar las tareas llevadas a cabo por

"DIMPRODUCTO". Este paso es un contenedor de flujo de datos, as que
incluye las siguientes tareas:
Figura 3.3.14: Carga de la dimensin Producto.

1.
OLE DB Source: Obtiene a travs de una consulta SQL los datos del
OLTP necesarios para cargar la dimensin PRODUCTO.
SELECT
FROM
ON
ON
Inventario.ARTICULO.ArticuloId,
Inventario.ARTICULO.Denominacion AS Producto,
Inventario.MARCA.Denominacion AS Marca,
Inventario.MODELO.Denominacion AS Modelo
Inventario.MARCA INNER JOIN Inventario.MODELO
Inventario.MARCA.MarcaId = Inventario.MODELO.Marca_Id
INNER JOIN Inventario.ARTICULO
Inventario.MARCA.MarcaId = Inventario.ARTICULO.Marca_Id
AND Inventario.MODELO.ModeloId =
Inventario.ARTICULO.Modelo_Id

dimensin PRODUCTO.
55
2.
Slowly Changing Dimension: recibe los datos de entrada y verifica si

los datos han sufrido algn cambio para actualizar los datos ya
registrados, tambin inserta los datos que son nuevos en la dimensin
producto.
3.
Insert
Destination:
inserta
los
datos
nuevos
en
la
tabla
DIMPRODUCTO.
4.
OLE DB Comand: hace una inferencia para ver qu datos son los
que han sufrido cambios.
5.
OLE DB Comand 1: hace la actualizacin en la tabla DIMPRODUCTO

de los datos que han cambiado.
A continuacin, se especificaran las tareas llevadas a cabo por

"DIMFECHA". Este paso es un contenedor de flujo de datos, as que incluye
Figura 3.3.16: Carga de la dimensin Fecha.

1.
OLTP necesarios para cargar la dimensin FECHA.
56
SELECT
Distinct cast(Convert(char(10),FechaRegistra,126)as datetime) as
idFecha
FROM
Ventas.DOCUMENTOVENTA

dimensin FECHA.
2.
Derived Column: mediante funciones que reciben la fecha como

parmetro se obtienen el ao, trimestre, mes, semana y da.
3.
Data Conversion: convierte el parmetro fecha en un tipo de dato

string.
4.
Derived Column1: se le quita los guiones y espacios al dato de fecha

convertido a String.
5.

que los datos sean nuevos para insertarlos en la dimensin fecha.
6.
Insert Destination: almacena en la tabla DIMFECHA los datos

obtenidos en el paso anterior.

"DIMACUERDOPAGO". Este paso es un contenedor de flujo de datos, as que
57
Figura 3.3.18: Carga de la dimensin Acuerdo de pago.

1.
OLTP necesarios para cargar la dimensin ACUERDOPAGO.
SELECT
FROM
ON
ON
WHERE
Ventas.ACUERDOPAGO.AcuerdoPagoId,
Ventas.PLANPAGO.Denominacion AS PlanPago,
Ventas.PLAZOPAGO.Denominacion AS PlazoPago,
Ventas.ACUERDOPAGO.TipoClienteTipoVenta_Id AS TipoCliente
Ventas.ACUERDOPAGO INNER JOIN Ventas.PLANPAGO
Ventas.ACUERDOPAGO.PlanPago_Id = Ventas.PLANPAGO.PlanPagoId
INNER JOIN Ventas.PLAZOPAGO
Ventas.ACUERDOPAGO.PlazoPago_Id =
Ventas.PLAZOPAGO.PlazoPagoId
(Ventas.ACUERDOPAGO.Estado = 1)

dimensin ACUERDOPAGO.
2.

acuerdo de pago.
3.
Insert
Destination:
inserta
los
datos
nuevos
en
la
tabla
DIMACUERDOPAGO.
58
4.
5.
OLE
DB
Comand
1:
hace
la
actualizacin
en
la
tabla
DIMACUERDOPAGO de los datos que han cambiado.

"DIMOFICINA". Este paso es un contenedor de flujo de datos, as que incluye
Figura 3.3.20: Carga de la dimensin Oficina.

1.
OLTP necesarios para cargar la dimensin OFICINA.
select
O.OficinaId,Denominacion, U.Descripcion
from Maestro.UBIGEO U join Maestro.DIRECCION D
on
U.UbigeoId = D.Ubigeo_Id join Maestro.OFICINA O
on
D.DireccionId = O.Direccion_Id

dimensin oficina.
59
2.

oficina.
3.
Insert Destination: inserta los datos nuevos en la tabla DIMOFICINA.
4.
5.
OLE DB Comand 1: hace la actualizacin en la tabla DIMOFICINA de

los datos que han cambiado.

"DIMEMPLEADO". Este paso es un contenedor de flujo de datos, as que
Figura 3.3.22: Carga de la dimensin empleado.

1.
OLTP necesarios para cargar la dimensin EMPLEADO.
60
SELECT
FROM
ON
ON
E.EmpleadoId, P.NombreCompleto,
C.Denominacion
RRHH.EMPLEADO AS E INNER JOIN Maestro.PERSONA AS P
E.Persona_Id = P.PersonaId INNER JOIN RRHH.CARGO AS C
E.Cargo_Id = C.CargoId

dimensin empleado.
2.

empleado.
3.
Insert Destination: inserta los datos nuevos en la tabla DIMEMPLEADO.
4.
5.
OLE DB Comand 1: hace la actualizacin en la tabla DIMEMPLEADO

de los datos que han cambiado.
A continuacin, se especicar las tareas llevadas a cabo por "VENTAS".

Este paso es un contenedor de flujo de datos, as que incluye las siguientes
tareas:
61
Figura 3.3.24: Carga de la tabla de hechos VENTAS.

1.
OLTP necesarios para cargar la tabla de hechos VENTAS.
SELECT
Ventas.DETORDENVENTA.Cantidad,
Ventas.DOCUMENTOVENTA.Cliente_Id AS idCliente,
Ventas.DETORDENVENTA.SubtotalconIGV AS MontoTotal,
Ventas.LISTAPRECIOMOVIL.AcuerdoPago_Id AS idAcuerdoPago,
Ventas.DOCUMENTOVENTA.Empleado_Id AS idEmpleado,
Ventas.DOCUMENTOVENTA.Oficina_Id AS idOficina,
Ventas.DETORDENVENTA.Articulo_Id AS idProducto,
CAST(CONVERT(char(10),Ventas.DOCUMENTOVENTA.FechaRegistra, 126) AS datetime)
AS idFecha
FROM
Ventas.DETORDENVENTA cross JOIN Ventas.DOCUMENTOVENTA
JOIN Ventas.LISTAPRECIOMOVIL
ON Ventas.DETORDENVENTA.ListaPrecioMovil_Id =
Ventas.LISTAPRECIOMOVIL.ListaPrecioMovilId
Where Ventas.DOCUMENTOVENTA.Cliente_Id is not null

dimensin FECHA.
2.
Data Conversion: Convierte el parmetro fecha en un tipo de dato

string.
3.
Derived Column: Se le quita los guiones y espacios al dato de fecha

convertido a String.
62
4.

que los datos sean nuevos para insertarlos en la tabla de hechos
Ventas.
5.
Insert Destination: almacena en la tabla VENTAS los datos obtenidos

en el paso anterior.
3.4
CREACIN DE CUBOS MULTIDIMENSIONALES

A continuacin se crear un cubo multidimensional, que ser
llamado Cubo de Ventas y que estar basado en el modelo lgico

diseado con metodologa Hefesto:
Figura 3.4.1: Modelo Lgico.
63
Figura 3.4.2: Cubo de ventas.

3.5
REPORTES CON LOS CUBOS
3.5.1
Se desea conocer cuntas 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.
Figura 3.5.1: Reporte de las unidades vendidas de cada producto a cada

cliente en un tiempo determinado.
64
3.5.2
Se desea conocer cul fue el monto total de ventas de productos a

cada cliente en un periodo determinado. O en otras palabras:
Monto total de ventas de los productos a cada cliente en un
tiempo determinado.
Figura 3.5.2: Reporte del monto total de ventas de los productos a cada
cliente en un tiempo determinado
3.5.3
Se desea conocer cul fu el monto total de ventas de un empleado

en un periodo determinado. O en otras palabras: Monto total de
ventas de los producto por cada empleado de cada oficina en un
tiempo determinado.
65
Figura 3.5.3: Reporte del monto total de ventas de los productos por cada
empleado de cada oficina en un tiempo determinado.
3.5.4
Se desea saber cuntas unidades de producto se han vendido en

cada oficina: Unidades vendidas de cada producto por cada
Figura 3.5.4: Reporte de las unidades vendidas de cada producto por cada
66

3.5.5
Se desea saber cuntas unidades de producto se han vendido con

un tipo de acuerdo de pago determinado en un tiempo
determinado: Unidades vendidas de cada producto por tipo de
acuerdo de pago en un tiempo determinado.
Figura 3.5.5: Reporte de las unidades vendidas de cada producto por tipo
67
de acuerdo de pago en un tiempo determinado.

3.5.6
Se desea saber cuntas unidades de producto se han vendido de

cada marca y modelo: Unidades vendidas de cada producto de
Figura 3.5.6: Reporte de las unidades vendidas de cada producto de

68
CAPTULO IV
CONCLUSIONES Y RECOMENDACIONES
4.1
CONCLUSIONES
a.
Se desarroll satisfactoriamente el Data Mart, para el rea de

ventas
de
Intercel
comunicaciones,
haciendo
uso
de
la
metodologa HEFESTO, lenguaje de consulta estructurada SQL y

gestor de base de datos SQLServer 2012.
b.
Se identificaron los requerimientos que especifican los objetivos de

la organizacin, haciendo uso de instrumentos de recoleccin de
datos. Estos requerimientos fueron revisados y aprobados por el
cliente.
c.
El esquema que se eligi fue el de estrella, debido a sus

caractersticas, ventajas y diferencias con los otros esquemas y se
especificaron las consultas de anlisis para la construccin del
modelo lgico del Data Mart de ventas.
d.
Se dise el proceso de ETL con el uso de la herramienta

Integration Services de Microsoft sin afectar la confiabilidad e
integridad de los datos.
e.
Se cre el cubo multidimensional que permiti el anlisis de los

datos del Data Mart, haciendo uso de la herramienta Analysis
Services de Microsoft.
f.
Se crearon reportes para la toma de decisiones que responden a

los requerimientos del rea de ventas de INTERCEL, con el uso de la
herramienta Excel.
4.2
RECOMENDACIONES
a.
Se recomienda Implementar un componente de Inteligencia de

Negocios basado en Balanced Scorecard esto ser relativamente
sencillo debido que se cuenta con un Data Mart que cuenta con
69
informacin actualizndose peridicamente y con dimensiones y

medidas que pueden ser reutilizadas como indicadores.
b.
Se
recomienda
la ampliacin
de reas
departamentos,
desarrollando Data Marts para las otras reas de la empresa e ir

construyendo un Data Warehouse corporativo. De esta manera, el
alcance no slo estar limitado por las necesidades de informacin
del rea de ventas sino que podra abarcarse reas como
Compras, Contabilidad y tener una visin ms completa de la
organizacin.
c.
Se recomienda implementar herramientas de explotacin de datos

como minera de datos, mantenimiento de metadatos, etc. Puesto
que el objetivo principal de estas herramientas es brindar medios
ms efectivos y fciles de utilizar para la generacin de
informacin til de manera rpida, integrada y con la seguridad de
contar con informacin consistente
70
BIBLIOGRAFA
BIBLIOGRAFA PRINCIPAL
1.
Carmen Cmara Nez. (2010). Anlisis de los sistemas Business

Intelligence y su aplicacin prctica en los proyectos software,
Madrid, Espaa: Universidad Carlos III de Madrid.
2.
CherryTree & Co. (2000). Business Intelligence-The Missing Link.

Minesota, Estados Unidos: Customized investment banking for IT
services firms.
3.
Dario Bernabeu Ricardo. (2010). HEFESTO: Metodologa para la

Construccin de un Data Warehouse. Crdoba, Argentina.
4.
Elizabeth Vitt, Michael Luckevich y Stacia Misner. (2002). Business

Intelligence Tcnicas de anlisis para la toma de decisiones
estratgicas, Espaa.
5.
Gill Harjinder S., Rao Prakash C. (1996). Data Warehousing, la

integracin de informacin para la mejor toma de decisiones.
Mxico: Prentice Hall.
6.
Josep Curto Daz. (2010). Introduccin al Business Intelligence.
7.
Manuel Palomar Sanz. (2001). Uso y diseo de Base de Datos

Multidimensionales y almacenes de datos.
8.
Microsoft (s.f.). Informacin general sobre el procesamiento

analtico en lnea (OLAP). Recuperado el 4 de Abril del 2014, de
http://office.microsoft.com/es-es/excel-help/informacion-generalsobre-el-procesamiento-analitico-en-linea-olapHP010177437.aspx#BMwhat_is_on-line_analytical_processing.
9.
ONGEI. (1997). Manual de Construccin de un Data Warehouse.
10.
Paul Lane. (1999). Oracle 8i Data Warehousing guide.
11.
Sinnexus. (s.f). business intelligence. Recuperado el 5 de Abril del

2014,
de
http://www.sinnexus.com/business_intelligence
/olap_avanzado.aspx.
71
12.
Ullman, J.D.; Widom, J. (1999). Introduccin a los Sistemas de Bases

de Datos. Prentice Hall.
13.
Wladimiro Daz. (2002). Recuperado el 4 de Abril del 2014, de

http://www.uv.es/~diaz.
72

Informe de Practicas Completo

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Informe de Practicas Completo

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD NACIONAL DE SAN CRISTBAL DE

ANLISIS, DISEO E IMPLEMENTACIN DE UN DATA MART

BENDEZ VILLENA, Richard

PARA OPTAR EL GRADO ACADMICO DE:

AYACUCHO, 05 DE SETIEMBRE DEL 2014

ARQUITECTURA DEL DATA WAREHOUSING

2.5.3 LOAD MANAGER

2.5.4 DATA WAREHOUSE MANAGER

2.5.5 QUERY MANAGER

2.5.6 HERRAMIENTAS DE CONSULTA Y ANLISIS

2.7.3 PASOS DE LA METODOLOGIA

PASOS DE LA METODOLOGIA EFESTO

3.3.1 ANALISIS DE REQUERIMIENTOS

3.3.2 ANLISIS DE LOS OLTP

3.3.3 MODELO LGICO DEL DW

3.3.4 INTEGRACIN DE DATOS

CREACIN DE CUBOS MULTIDIMENSIONALES

REPORTES CON LOS CUBOS

Identificar los requerimientos del usuario que especifiquen los

Elegir un esquema de Data Mart y especificar las consultas de

Disear el proceso de ETL (Extraccin, Transformacin y Carga) de

Crear un cubo multidimensional que permita hacer el anlisis de los

Crear reportes para la toma de decisiones, solicitados en el rea

distribuidores ms grande e importante de la Regin Ayacucho. Ofrece

soporte de decisiones que permiten en tiempo real, acceso interactivo,

incluyen clientes, proveedores, productos, servicios y competidores.

transformar, consolidar, integrar y centralizar los datos que una organizacin

diferentes fuentes (base de datos, archivos de texto, hojas de clculo, etc.)

toma de decisiones de una administracin" (Harjinder y Prakash, 1996).

ARQUITECTURA DEL DATA WAREHOUSING

se han detallado claramente las caractersticas generales del Data

Figura 2.5.1: Data Warehousing, arquitectura. (Bernabeu, 2010).

representa toda aquella informacin transaccional que genera la empresa

Figura 2.5.2: OLTP. (Bernabeu, 2010).

para luego manipularlos, integrarlos y transformarlos, para posteriormente

Figura 2.5.3: Load manager. (Bernabeu, 2010).

Manipular los datos sin interrumpir ni paralizar los OLTP, ni tampoco

No depender de la disponibilidad de los OLTP.

Almacenar y gestionar los metadatos que se generarn en los

Facilitar la integracin de las diversas fuentes, internas y externas.

integracin, son los siguientes:

Codificacin: Una inconsistencia muy tpica que se encuentra al

Medida de atributos: Los tipos de unidades de medidas utilizados

considerablemente entre s, a travs de los diferentes OLTP. Por

Convenciones de nombramiento: Usualmente, un mismo atributo es

Fuentes mltiples: Un mismo elemento puede derivarse desde varias

limpieza de datos: Su objetivo principal es el de realizar distintos tipos

Segn Lane (1999) se plantea que la transformacin de los datos para el

Figura 2.5.4: Ejemplo de un flujo de transformaciones (Lane, 1999).

reere precisamente a la primera carga de datos que se le realizar al Data

Cargas secuenciales: Se realiza una serie de cargas organizadas

Procesos por lotes (batchs): Se realiza una serie de cargas

Procesamiento paralelo y tcnicas incrementales: Esta tcnica se

DATA WAREHOUSE MANAGER

siguientes caractersticas y funciones principales:

Se constituye tpicamente al combinar un SGBD con software y

Almacena los datos de forma multidimensional, es decir, a travs de

Gestiona las diferentes estructuras de datos que se construyan o

Multidimensionales, modelos de negocio, etc.

Gestiona y mantiene metadatos.

Adems, el Data Warehouse Manager se encarga de: Transformar e

Realizar todas las funciones de definicin y manipulacin del

Realizar copias de resguardo incrementales o totales de los datos del

2.5.4.1 BASE DE DATOS MULTIDIMENSIONAL