Informe de Practicas Completo

7/24/2019 Informe de Practicas Completo

1/79

UNIVERSIDAD NACIONAL DE SAN CRISTBAL DEHUAMANGA

FACULTAD DE INGENIERA DE MINAS, GEOLOGA Y CIVILESCUELA DE FORMACIN PROFESIONAL DE INGENIERA DE

SISTEMAS

ANLISIS, DISEO E IMPLEMENTACIN DE UN DATA MARTPARA 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


2/79

i

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.


3/79

ii

DEDICATORIA

Este proyecto lo dedico a mi familia por apoyarme

incondicionalmente su tiempo y dedicacin para

continuar con mi aprendizaje.


4/79

iii

CONTENIDO

AGRADECIMIENTOS i

DEDICATORIA ii

CONTENIDO iiiRESUMEN v

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 032.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


5/79

iv

CAPTULO III

RESULTADOS

3.1 PROBLEMTICA 32

3.2 SOLUCIN DESARROLLADA 333.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


6/79

v

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 procesode 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.


7/79

vi

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 ala 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.


8/79

1

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.


9/79

2

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. Estasaplicaciones 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


10/79

3

incluyen clientes, proveedores, productos, servicios y competidores.

(Cmara, 2010).

2.3 DATA WAREHOUSINGEl 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

final 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 varancon el tiempo y que no son transitorios, los cuales soportan el proceso de


11/79

4

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 definirn 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 deinformacin, 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.


12/79

5

Figura 2.5.2: OLTP. (Bernabeu, 2010).

2.5.3 LOAD MANAGERSegn 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).


13/79

6

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 OLTPque 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 disponibil idad 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 Warehouseestn integrados. Los casos ms comunes en los que se deber realizar


14/79

7

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 deuna 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 fin, 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.


15/79

8

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 Datamartde 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 unintervalo de tiempo predefinido para tal operacin). La carga inicial, se


16/79

9

refiere 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. Losmantenimientos 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.


17/79


18/79

11

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 filtrar 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 filas 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 dedimensiones.


19/79

12

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).


20/79

13

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


21/79

14

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 debensoportar, 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).


22/79

15

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 elrendimiento. Es decir, ROLAP cuenta con todos los beneficios 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 especficas (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 unmotor relacional y otros en una base de datos multidimensional. Los datos


23/79

16

agregados y 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).


24/79

17

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 drill-up 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).


25/79

18

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.


26/79

19

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, BusinessModel, 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 finales, 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 fin de seleccionar,

filtrar y personalizar los mismos, para la obtencin de informacin oportuna,

relevante y til, para apoyar el proceso de toma de decisiones. Orientacin

los usuarios finales: 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 CONSULTASSegn Bernabeu (2010) se han desarrollado muchas herramientas


27/79

20

para la produccin de consultas y reportes, que ofrecen a los usuarios, a

travs de pantallas grficas 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 grficos de tortas, barras, etc.

iv. Utilizacin de plantillas de formatos de fondos.

v. Inclusin de imgenes.

vi. Formatos tipogrficos.

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 seencargan de tomar decisiones y de planificar las actividades del negocio,


28/79

21

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.


29/79

22

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


30/79

23

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 fines. (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 identificar los indicadores resultantes de los interrogativos

y sus respectivas perspectivas de anlisis, mediante las cuales se construir


31/79

24

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 ala 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 finales

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 seconvierten en el punto de partida para llevar a cabo el paso


32/79

25

siguiente.

ix. Se aplica tanto para Data Warehouse como para Data Mart.

2.7.3 PASOS DE LA METODOLOGIA2.7.3.1 ANALISIS DE REQUERIMIENTOS

Lo primero que se har ser identificar los requerimientos de los

usuarios a travs de preguntas que especifiquen los objetivos de su

organizacin. Luego, se analizarn estas preguntas a fin de identificar 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 especficas, 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

refleje 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

identificar 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 eficaz y eficiente 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 debetener en cuenta que los indicadores, para que sean realmente efectivos


33/79

26

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 refieren a los objetos mediante

los cuales se quiere examinar los indicadores, con el fin de responder a laspreguntas 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 definicin de los datos, permite que pueda ser presentado ante los

usuarios y explicado con facilidad. (Bernabeu, 2010).

La representacin grfica 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).


34/79

27

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 ylas fuentes de datos. Luego, se definirn 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, definiendo 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 identificar 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 filtrarn 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 significacada campo y/o valor de los datos encontrados en los OLTP, por lo cual, es


35/79

28

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 significado, valores posibles y caractersticas, estos debendecidir 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 fin de graficar los resultados obtenidos en los

pasos anteriores, se ampliar el modelo conceptual, colocando bajo cada

perspectiva los campos seleccionados y bajo cada indicador su respectiva

frmula de clculo. Grficamente: (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 definir 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


36/79

29

para contener la estructura del depsito de datos, que se adapte mejor a

los requerimientos y necesidades de los usuarios. Es muy importante definir

objetivamente si se emplear un esquema en estrella o copo de nieve, ya

que esta decisin afectar considerablemente la elaboracin del modelolgico. (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 definida 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 identifique la tabla de dimensin.

iv. Se aadir un campo que represente su clave principal.

v. Se redefinirn los nombres de los campos si es que no son lo

suficientemente intuitivos.

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

C. TABLAS DE HECHOS

En este paso, se definirn 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 definir su clave primaria, que se compone de la combinacin


37/79

30

de las claves primarias de cada tabla de dimensin relacionada.

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

definido en el modelo conceptual y se les asignar los mismos

nombres que estos. En caso que se prefiera, podrn ser nombradosde 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 definirn 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.


38/79

31

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 fin, y que nos facilitarn el

trabajo. Se debe evitar que el DATA WAREHOUSE sea cargado con valoresfaltantes 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. Especificar las tareas de limpieza de datos, calidad de datos,

procesos ETL, etc., que debern realizarse para actualizar los datos

del Data Warehouse.

ii. Especificar de forma general y detallada las acciones que deber

realizar cada software.


39/79

32

CAPTULO III

RESULTADOS

3.1 PROBLEMTICAUna 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


40/79

33

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.


41/79


42/79

35

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 predefinidos.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 identificar 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 simplificar 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 enun tiempo determinado.


43/79

36

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 fin de realizar un correcto

anlisis posterior.

3.3.1.2 IDENTIFICAR INDICADORES Y PERSPECTIVAS

A continuacin, se analizarn las preguntas obtenidas en el pasoanterior y se detallarn cules son sus respectivos indicadores y


44/79

37

perspectivas.

Unidades vendidas de cada producto a cada cliente en un tiempo determinado

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

Monto total de ventas de los producto por cada empleado de cada oficina en un tiempo

determinado.

En sntesis, los indicadores son:

i. Unidades vendidas.

ii. Monto total de ventas.

Y las perspectivas de anlisis son:

i. Clientes.

ii. Productos.iii. Empleados.

iv. Oficina.

v. Marca

vi. Modelo

vii. Acuerdo de pago

viii. Tiempo.

3.3.1.3 MODELO CONCEPTUAL

El modelo conceptual resultante de los datos que se han

recolectado, es el siguiente:

INDICADOR

INDICADOR

INDICADORINDICADOR PERSPECTIVAS

PERSPECTIVAS

PERSPECTIVAS


45/79

38

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 figura.

VENTAS

UNIDADES

VENDIDAS

MONTO TOTAL

DE VENTAS

PRODUCTO

EMPLEADO

CLIENTE

OFICINA

MARCA

MODELO FECHA ACUERDO DE

PAGO


46/79

39

Figura 3.3.2: Diagrama entidad relacin del OLTP.

A continuacin, se expondr la correspondencia entre los dos modelos:

Figura 3.3.3: Correspondencia.

ARTICULO (Inventario)

ArticuloId

Organizacion_Id

UnidadMedidaBase_Id

TipoControlInventario_Id

Modelo_Id

Marca_Id

TipoArticulo_Id

CodArticulo

Denominacion

Descripcion

CodFabrica

Imagen

IndExoneraIgv

IndTieneModelo

IndPerecible

IndImportado

IndTieneCodigoBarras

IndTieneMarca

IndVentaRapida

IndPromocion

Estado

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza

CLIENTE (Ventas)

ClienteId

Organizacion_Id

Persona_Id

IndCredito

Estado

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza

DETDOCUMENTOVENTA (

DetOrdenVenta_Id

DetOrdenVentaOrigen_I...

SerieDetOrdenVenta_Id

Articulo_Id

Cantidad

Descripcion

ValorVenta

Descuento

SubtotalSinIGV

SubtotalconIGV

Observacion

Estado

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza

EMPLEADO (RRHH)

EmpleadoId

Persona_Id

Organizacion_Id

EmpleadoSuperior_Id

IndTercero

Cargo_Id

Estado

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza

IndDescuento

Oficina_Id

CategoriaEmpleado_Id

CondicionLaboral_Id

FechaIngreso

ACUERDOPAGO (Ventas)

AcuerdoPagoId

TipoClienteTipoVenta_Id

PlanPago_Id

DETORDENVENTA (Ventas)

ListaPrecioMovil_Id

Articulo_Id

UnidadMedida_Id

DetOrdenVentaOrigen_Id

Cantidad

Descripcion

ValorVenta

Descuento

DOCUM ENTOVENTA (Ventas)

DocumentoVentaId

TipoDocumento_Id

Organizacion_Id

OrdenVenta_Id

DocVentaOrigen_Id

TipoCobro_Id

EstadoCobro_Id

Moneda_Id

Empleado_Id

Oficina_Id

SerieDocumento

NumeroDocumento

SerieDocManual

NroDocManual

SubTotal

TotalDescuento

TotalImpuesto

TotalNeto

OFICINA (Maestro)

OficinaId

Organizacion_Id

Direccion_Id

Empleado_Id

Denominacion

Descripcion

Telefono

IndPrincipal

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza

Estado

MARCA (Inventario )

MarcaId

Organizacion_Id

Fabricante_Id

Denominacion

Descripcion

Estado

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza

IndMigracion

MODELO (Inventario)

ModeloId

Marca_Id

Fabricante_Id

Denominacion

Descripcion

Estado

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza

IndMigracion

LISTAPRECIOMOVIL (

ListaPrecioMovilId

AcuerdoPago_Id

Articulo_Id

Modelo_Id

Moneda_Id

Monto

PctIniDescuento

PctFinDescuento

Estado

UsuarioRegistra_Id

UsuarioActualiza_Id

FechaRegistra

FechaActualiza


47/79

40

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 elnombre de la organizacin en la cual se registra la marca. Por


48/79

41

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.


nombre del usuario que registra los datos del modelo.


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


49/79

42

modelo.

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

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.


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


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. FechaActualiza: fecha en la que se hace la actualizacin de los

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. Organizacion_Id: representa a travs de una clave fornea elnombre de la organizacin en la cual se registra la marca. Por


50/79

43


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 forneael 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. UsuarioRegistra_Id: representa a travs de una clave fornea el

nombre del usuario que registra los datos del producto.

xxi. UsuarioActualiza_Id: representa a travs de una clave fornea el

nombre del usuario que actualiza los datos del producto.

xxii. FechaRegistra: fecha en la que se hace el registro de los datos.xxiii. FechaActualiza: fecha en la que se hace la actualizacin de los


51/79

44

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. Organizacion_Id: representa a travs de una clave fornea el

nombre de la organizacin en la cual se registra la marca. Por


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:


52/79

45

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

inequvocamente a un cliente en particular.

ii. Organizacion_Id: representa a travs de una clave fornea el

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

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. Organizacion_Id: representa a travs de una clave fornea el

nombre de la organizacin en la cual se registra la marca. Por


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 puedenemplearse son los siguientes:


53/79

46

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 lasperspectivas MARCA y MODELO debido a que se consider que esto


54/79

47

provocara un mejor anlisis de la informacin.

iii. Perspectiva OFICINA:

Denominacion de la tabla Oficina. Ya que esta hace referenciaal 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


55/79

48

Ao.

3.3.2.4 MODELO CONCEPTUAL AMPLIADO

Teniendo esto en cuenta, se completar el diseo del diagrama

conceptual:

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 DIMENSIONESA 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 modificar el nombre del campo nombreCompleto por Cliente.

Se puede apreciar el resultado de estas operaciones en la siguiente grfica:

VENTAS

UNIDADES

VENDIDASSUM(unidades vendidas)

MONTO TOTAL

DE VENTASSUM(unidades vendidas *

precio de venta)

PRODUCTODenominacion

Marca

Modelo

EMPLEADOnombreCompleto

Cargo

CLIENTEnombreCompleto

OFICINADenominacion

Ubigeo

FECHADia

Semana

Mes

Trimestre

Semestre

Ao

ACUERDO DE

PAGOPlanPago

PlazoPago


56/79

49

Figura 3.3.5: Tabla de dimensin DIMCLIENTE.

ii. Perspectiva PRODUCTO:

La nueva tabla dimensin tendr el nombre de DIMPRODUCTO.

Se le agregara una clave principal con el nombre de idProducto.

Se modificar el nombre del campo Denominacion por Producto.

El nombre del campo Marca y Modelo no ser modificado.


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.


DIMCLIENTE

column

*PK idCliente

* Cl ie nt e

CLIENTEnombreCompleto

DIMPRODUCTO

column

*PK id Producto

* Pro ducto

* Marca

* Model o

PRODUCTODenominacion

MarcaModelo


57/79

50

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.


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.


Figura 3.3.8: Tabla de dimensin DIMEMPLEADO.

DIMOFICINA

column

*PK idOficina

* Ofi ci na

* Ci udad

OFICINADenominacion

Ubigeo

DIMEMPLEADO

column

*PK idEmpleado

* Empl eado

EMPLEADOnombreCompleto

Cargo

DIMACUERDOPAGO

column

*PK idAcuerdoPago

* Pl anPago

* PlazoPago

ACUERDO DE

PAGOPlanPago

PlazoPago


58/79

51

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 modificados.

Figura 3.3.9: Tabla de dimensin DIMTI.

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 definidas: 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 grfico siguiente se puede apreciar mejor este paso:

FECHADia

Semana

Mes

Trimestre

Semestre

Ao

DIMFECHA

column

*PK idFecha

* Dia

Semana

Mes

Trimestre

Semestre

Ao


59/79

52

Figura 3.3.10: Diseo de la tabla de hechos.

3.3.3.4 UNIONES

Se realizarn las uniones pertinentes, de acuerdo corresponda:

Figura 3.3.11: Uniones.

VENTAS

UNIDADES

VENDIDASSUM(unidades vendidas)

MONTO TOTAL

DE VENTASSUM(unidades vendidas *

precio de venta)

VENTAS

column

*PK idCliente

*PK idProducto

*PK idEmpleado

*PK idAcuerdoPago

*PK idOficina

*PK idFecha

Cantidad

MontoTotal

DIMCLIENTE

column

*PK idCliente

* Cl ie nte

PK

+ PK_DIMCLIENTE()

DIMEMPLEADO

column

*PK idEmpleado

* E mp le ad o

PK

+ PK_DIMEMPLEADO()

DIMOFICINA

column

*PK idOficina

* Ofi ci na

* Ci ud ad

PK+ PK_DIMOFICINA()

DIMACUERDOPAGO

column

*PK idAcuerdoPago

* P la nP ag o

* P lazoPago

PK

+ PK_DIMACUERDOPAGO()

DIMPRODUCTO

column

*PK idProducto

* Producto

* M arca

* M odel o

PK

+ PK_DIMPRODUCTO()

DIMFECHA

column

*PK idFecha

* Dia

Semana

Mes

Trimestre

Semestre

Ao

PK

+ PK_DIMFECHA()

VENTAS

column

*PK idCliente

*PK idProducto

*PK idEmpleado

*PK idAcuerdoPago

*PK idOficina

*PK idFecha

Cantidad

MontoTotal

PK

+ PK_VENTAS(, , , , , )


60/79

53

3.3.4 INTEGRACIN DE DATOS

3.3.4.1 CARGA INICIAL

Para simplificar la aplicacin, solo nos centraremos en los aspectos

ms importantes del proceso ETL, obviando entrar en detalle de cmo serealizan 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 quecargar 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.


61/79

54

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 elmismo.

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.

Figura 3.3.13: Consulta SQL para obtener los datos de entrada de la

dimensin CLIENTE.

SELECT Ventas.CLIENTE.ClienteId, Maestro.PERSONA.NombreCompletoFROM Maestro.PERSONA INNER JOIN Ventas.CLIENTEON Maestro.PERSONA.PersonaId = Ventas.CLIENTE.Persona_Id

where Ventas.CLIENTE.ClienteId is not null


62/79

55

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 especificar 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.

Figura 3.3.15: Consulta SQL para obtener los datos de entrada de ladimensin PRODUCTO.

SELECT Inventario.ARTICULO.ArticuloId,Inventario.ARTICULO.Denominacion AS Producto,Inventario.MARCA.Denominacion AS Marca,Inventario.MODELO.Denominacion AS Modelo

FROM Inventario.MARCA INNER JOIN Inventario.MODELO

ON Inventario.MARCA.MarcaId = Inventario.MODELO.Marca_IdINNER JOIN Inventario.ARTICULO

ON Inventario.MARCA.MarcaId = Inventario.ARTICULO.Marca_IdAND Inventario.MODELO.ModeloId =

Inventario.ARTICULO.Modelo Id


63/79

56

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 dimensinproducto.

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.


OLTP necesarios para cargar la dimensin FECHA.


64/79

57


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. Slowly Changing Dimension: recibe los datos de entrada y verifica

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

incluye las siguientes tareas:

SELECT

Distinct cast(Convert(char(10),FechaRegistra,126)as datetime) as

idFechaFROM Ventas.DOCUMENTOVENTA


65/79

58

Figura 3.3.18: Carga de la dimensin Acuerdo de pago.


OLTP necesarios para cargar la dimensin ACUERDOPAGO.


dimensin ACUERDOPAGO.



registrados, tambin inserta los datos que son nuevos en la dimensin

acuerdo de pago.

3. Insert Destination: inserta los datos nuevos en la tabla

DIMACUERDOPAGO.

SELECT Ventas.ACUERDOPAGO.AcuerdoPagoId,

Ventas.PLANPAGO.Denominacion AS PlanPago,Ventas.PLAZOPAGO.Denominacion AS PlazoPago,Ventas.ACUERDOPAGO.TipoClienteTipoVenta_Id AS TipoCliente

FROM Ventas.ACUERDOPAGO INNER JOIN Ventas.PLANPAGOON Ventas.ACUERDOPAGO.PlanPago_Id = Ventas.PLANPAGO.PlanPagoId

INNER JOIN Ventas.PLAZOPAGOON Ventas.ACUERDOPAGO.PlazoPago_Id =

Ventas.PLAZOPAGO.PlazoPagoId

WHERE (Ventas.ACUERDOPAGO.Estado = 1)


66/79

59



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.


OLTP necesarios para cargar la dimensin OFICINA.


dimensin oficina.

select O.OficinaId,Denominacion, U.Descripcion

from Maestro.UBIGEO U join Maestro.DIRECCION Don U.UbigeoId = D.Ubigeo_Id join Maestro.OFICINA O

on D.DireccionId = O.Direccion_Id


67/79

60



registrados, tambin inserta los datos que son nuevos en la dimensinoficina.

3. Insert Destination: inserta los datos nuevos en la tabla DIMOFICINA.



5. OLE DB Comand 1: hace la actualizacin en la tabla DIMOFICINA de

los datos que han cambiado.

A continuacin, se especificar las tareas llevadas a cabo p

Informe de Practicas Completo

Documents

Transcript of Informe de Practicas Completo