Tesis Sis83 Men

UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA
FACULTAD DE INGENIERÍA DE MINAS, GEOLOGÍA Y CIVIL
ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS
“DATAMART PARA INFORMACIÓN TÁCTICA DE VENTAS Y

ALMACEN DE LA EMPRESA TOPI TOP, 2017”
Tesis Presentada por : Bach. Katy Lizbeth Meneses Mendoza

Para optar el título profesional de : Ingeniera de Sistemas
Tipo de Investigación : Observacional, Retrospectivo, Longitudinal,
descriptiva
Área de Investigación : Inteligencia de negocios
Asesor : MSc. Ing. Efraín Elías Porras Flores
Ayacucho – Perú
2019
DEDICATORIA
Este trabajo de investigación en primer lugar
dedico a mi padre quien me apoyo
incondicionalmente durante toda mi formación,
por ser el pilar fundamental para culminar mis
estudios, con su perseverancia y entusiasmo en el
transcurso de mi vida.
A mi madre quien me apoyo para poder llegar a

esta instancia de mis estudios, por su amor,
paciencia, comprensión, por la motivación
constante.
A mi hermana Tania quien me apoyo

incondicionalmente siempre que lo necesitaba.
i
AGRADECIMIENTO
A Dios
A mi familia por su apoyo incondicional.
A la Universidad Nacional de San Cristóbal de Huamanga, por medio de ella a la
Escuela de Formación Profesional de Ingeniería de Sistemas y por ende a sus dignos
maestros.
Al Ing. MSc. Efraín Porras Flores quien estuvo ayudándome como asesor en el
transcurso del desarrollo del proyecto.
A todos quienes estuvieron durante mi carrera de una u otra forma apoyándome
incondicionalmente.
ii
CONTENIDO
DEDICATORIA ................................................................................................................ I
AGRADECIMIENTO......................................................................................................II
CONTENIDO..................................................................................................................III
RESUMEN......................................................................................................................IV
INTRODUCCION............................................................................................................V
CAPÍTULO I
PLANTEAMIENTO DE LA INVESTIGACIÓN
1.1 DIAGNÓSTICO Y ENUNCIADO DEL PROBLEMA...................................1
1.2 FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN....................... 2
1.3 OBJETIVOS DE LA INVESTIGACIÓN ........................................................ 2
1.4 JUSTIFICACIÓN Y DELIMITACIÓN DE LA INVESTIGACIÓN .............. 3
1.4.1 JUSTIFICACIÓN............................................................................................. 4
1.4.2 DELIMITACIÓN ............................................................................................. 4
CAPÍTULO II
REVISIÓN DE LA LITERATURA
2.1 ANTECEDENTES DE LA INVESTIGACIÓN .............................................. 5
2.2 MARCO TEÓRICO ......................................................................................... 6
2.2.1 INFORMACIÓN TÁCTICA ........................................................................... 6
2.2.2 VENTAS .......................................................................................................... 8
2.2.3 ALMACEN .................................................................................................... 11
2.2.4 DATAMART ................................................................................................. 13
2.2.5 METODOLOGIA HEFESTO.........................................................................14
2.2.6 PROCESAMIENTO ANALÍTICO EN LÍNEA OLAP (ON-LINE
ANALYTICAL PROCESSING) ................................................................... 24
2.2.7 SISTEMA GESTOR DE BASE DE DATOS(SGBD) ................................... 27
2.2.8 BASE DE DATOS RELACIONAL .............................................................. 28
CAPITULO III
METODOLOGÍA DE LA INVESTIGACION
3.1 TIPO Y NIVEL DE INVESTIGACIÒN ........................................................ 30
3.2 DISEÑO DE LA INVESTIGACIÒN ............................................................ 30
3.3 POBLACIÒN Y MUESTRA ......................................................................... 30
iii
3.4 VARIABLE DESCRIPTIVAS Y VARIABLES DE INTERES ................... 31
3.5 TECNICAS E INSTRUMENTOS PARA RECOLECTAR
INFORMACION............................................................................................32
3.5.1 TECNICAS.....................................................................................................33
3.5.2 INSTRUMENTOS..........................................................................................33
3.6 HERRAMIENTA PARA EL TRATAMIENTO DE DATOS .......................34
3.7 TECNICAS PARA APLICAR LA METODOLOGIA HEFESTO.................35
CAPITULO IV
RESULTADOS DE LA INVESTIGACIÒN
4.1 RESULTADOS APLICANDO LA METODOLOGÍA HEFESTO .............. 36
4.1.1 ANALISIS DE REQUISITOS ....................................................................... 36
4.1.2 FASE DEL ANALISIS PROCESAMIENTO DE TRANSACCIONES EN
LINEA (OLTP)...............................................................................................44
4.1.3 FASE DE MODELO LOGICO DEL DATAMART ..................................... 54
4.1.4 FASES DEL PROCESO ETL ....................................................................... 62
4.1.5 IMPLEMENTACION DE CUBOS MULTIDIMENSIONALES...................75
CAPITULO V
CONCLUSIONES Y RECOMENDACIONES
5.1 CONCLUSIONES.............................................................................................115
5.2 RECOMENDACIONES....................................................................................115
BIBLIOGRAFIA...........................................................................................................117
iv
RESUMEN
Topi Top S.A, es una empresa que trabaja en el rubro de tejidos de punto con algodón
manufactura, estampadora, tejido plano y exportan el 70% de producción, siendo los
principales destinos: EEUU y Alemania. Hoy en día para la empresa, donde el tiempo es
un factor muy importante y existe desventaja frente a sus competidores debido a la
demora en la toma de decisiones y retardo de procesamiento de datos; es decir, muchas
veces los reportes sobre las ventas y almacén de productos, no son realizados a tiempo,
causando que las decisiones administrativas se realicen de manera tardía.
La presente investigación desarrolla un Datamart para calcular los indicadores de ventas

y almacén mediante el uso de la metodología Hefesto; con la base de datos Topi Top se
construyó la tablas de hechos y dimensiones dispuestas en esquema estrella, se
implementó sobre SQL Server 2014; y el desarrollo y automatización de los procesos
ETL mediante Integración Services y la construcción e implementación de los cubos
OLAP se realizó mediante Analysis Services de SQL Server. Finalmente el acceso a los
indicadores por parte de los usuarios finales se realiza mediante una hoja de cálculo.
La implementación del DataMart cumplió con los objetivos específicos planteados en la

presente investigación, mejorando el proceso de toma de decisiones del área de ventas y
almacén de la empresa Topi Top, ya que contiene toda la información relevante para el
análisis.
PALABRAS CLAVES
Datamart, Información táctica, metodología Hefesto, ventas, almacén.
v
INTRODUCCIÓN
De acuerdo a Francois (2004), la información táctica es aquella que muestra un aspecto

panorámico y central de la realidad y su evolución, sirviendo para proyectar y prever
futuras realidades, como las estadísticas, los análisis históricos, los informes y
documentos de situación política, social, económica y cultural. Con esta información y la
base ideológica se construyen los modelos para las diversas temáticas (Chiavenato, 2007,
p 286).
Mediante el apoyo en la toma de decisiones “Se busca ir más allá en la presentación de la

información, de manera que los usuarios tengan acceso a herramientas de análisis que les
permita seleccionar y manipular solo aquellos datos que les interesen” (Rayner, 2007).
Mi motivación para la implementación del DataMart, se debe a que en la actualidad la

empresa TopiTop de Lima, cuenta con información de una base de datos que falta ser
procesada, y proporcionarle una herramienta para procesar la información y apoyar en la
toma de decisiones.
La razón para realizar la investigación es dar soluciones a los problemas que tienen las
oficinas de ventas y almacén. El problema principal de la empresa es que no tienen un
control exacto de las ventas y almacén que realizan las áreas de la empresa, no pudiendo
tomar decisiones sobre las mismas.
El objetivo es calcular indicadores de información táctica para el área de ventas con la

finalidad de tener los indicadores; ventas por vendedor, metas por vendedor, metas por
tienda, líneas más vendidas por estilo, ventas por forma de pago, venta mensual. Calcular
indicadores de información táctica para el área de almacén con la finalidad de tener los
indicadores; stock disponible, transferencia a tienda por estilo, stock total de compañía,
ajuste de inventario.
vi
CAPÍTULO I
PLANTEAMIENTO DE LA INVESTIGACIÓN
1.1 DIAGNÓSTICO Y ENUNCIADO DEL PROBLEMA

Topi Top S.A, es una empresa que trabaja en el rubro de tejidos de punto con
algodón (Sur Color Star), manufactura, estampadora (Star Print), tejido plano (Expresess
jeans) y exportan el 70% de producción, siendo los principales destinos: EEUU y
Alemania. Hoy en día para la empresa en donde el tiempo es un factor muy importante
tiene desventaja frente a sus competidores debido a la demora en la toma de decisiones
por el retardo de procesamiento de datos; es decir, muchas veces los reportes sobre las
ventas y compras de productos no son realizados a tiempo, causando que las decisiones
administrativas se realicen de manera tardía. Es por ello que las diversas áreas de Topitop
S.A están sujetas a mejoras y depende de los directores o gerentes, priorizarlos para hacer
mejoras de acuerdo a las necesidades del negocio.
El área de ventas es la encargada de realizar las operaciones de ventas de los productos a

los clientes, con los que actualmente se cuenta y con ello generar rentabilidad para el
negocio. Pese a que las ganancias de los últimos años han sido buenas, el sobre stock de
productos ha aumentado debido a la producción masiva de los mismos lo que ha
ocasionado que en épocas del año sean rematados e incluso eliminados de la
comercialización.
La empresa se encuentra entonces en la necesidad de equilibrar su producción, para lo

cual debe considerar una tendencia de las ventas a realizar, así como en las diversas zonas
del Perú donde los productos serán comercializados según las épocas del año de las zonas
del país, donde los clientes de las mismas a quienes van dirigidos los productos
elaborados.
Asimismo, la empresa no lleva un control de las metas mensuales, a las que deben llegar
los vendedores de las diferentes zonas de país donde se comercializa, tampoco un control
mensual de las devoluciones que en muchas épocas del año han sido más de lo normal.
1
Por otro lado no cuenta con un control de las compras realizadas que en muchas ocasiones
no cumple con el pedido al proveedor, perjudicando así la productividad de la empresa.
Para este caso la empresa se encuentra ante la necesidad de evaluar el abastecimiento de
tiendas.
Tabla 1.1. Inventario y Venta

AÑO MES INVENTARIO(Soles) VENTA(Soles)
2017 ENERO 22,648,941.00 15,368,445.00
2017 FEBRERO 31,654,645.00 20,654,793.00
2017 MARZO 29,274,173.00 19,496,001.61
2017 ABRIL 44,530,120.60 21,197,048.41
2017 MAYO 16,755,412.08 25,944,467.74
2017 JUNIO 17,557,714.60 24,039,127.81
2017 JULIO 29,566,407.00 23,144,104.11
2017 AGOSTO 32,464,644.00 12,291,542.80
2017 SETIEMBRE 41,124,848.00 10,672,794.23
2017 OCTUBRE 59,719,907.30 12,964,026.91
2017 NOVIEMBRE 43,283,735.53 13,101,446.41
2017 DICIEMBRE 788,070.00 429,875.00
TOTAL 3,096,487,108.10 15,027,386.27
Fuente: Topitop (2017).
1.2 FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN
PROBLEMA PRINCIPAL
¿Qué indicadores se requiere para ventas y almacén de la empresa Topi Top S.A., Lima
2017?
PROBLEMAS SECUNDARIOS
a) ¿Qué información táctica se requiere del área de ventas?
b) ¿Qué información táctica se requiere del área de almacén?
2
1.3 OBJETIVOS DE LA INVESTIGACIÓN
OBJETIVO GENERAL
Desarrollar un Datamart mediante técnicas e instrumentos, la tecnología OLAP y con la
metodología Hefesto, un administrador de base de datos relacional, con el fin de tener
información táctica para las áreas de ventas y almacén de la empresa Topi Top Lima,
2017.
OBJETIVOS ESPECÍFICOS
a) Calcular indicadores de información táctica para el área de ventas con la
finalidad de tener los indicadores; ventas por vendedor, metas por vendedor,
metas por tienda, líneas más vendidas por estilo, ventas por forma de pago, venta
mensual.
b) Calcular indicadores de información táctica para el área de almacén con la
finalidad de tener los indicadores; stock disponible, transferencia a tienda por
estilo, stock total de compañía, ajuste de inventario.
1.4 JUSTIFICACIÓN Y DELIMITACIÓN DE LA INVESTIGACIÓN

1.4.1 JUSTIFICACIÓN
El Datamart permitirá disponer de una estructura optima de datos para analizar
a detalle todas las perspectivas que afecten a los departamentos de la empresa Topi top
S.A, la cual le permitirá al usuario acceder a la información actualizada en la base de
datos, el cual dará la facilidad para tomar las mejores decisiones en cuanto a la calidad de
servicio, información actualizada de cobranza que deben ser utilizados en la medición de
ingresos para la Empresa y abastecer necesidades a caja en tienda.
Con el Datamart se podrá contar con información táctica oportuna la cual facilitará a la
dirección la toma de decisiones, la necesidad de información y los procesos críticos
identificados que pueden ser usados por otras Universidades del Perú, que aún no hayan
identificado una estructura optima de datos que le permita analizar al detalle qué factores
afectan a los procesos.
En la importancia social, se apoyará al servicio de la empresa Topitop S.A y como

resultado final los beneficiados directos serán los departamentos de Venta y Almacen, ya
que al manejarse la información de una manera más oportuna, se podrá prever situaciones
3
como la falta de atención adecuada, también podrá tener una mejor elección de
información táctica de cobranza, cierre de caja.
En el aspecto económico al contar con Datamart se podrá acceder a una información

oportuna que permita saber con exactitud la cantidad de ingresos de cobranza que se tiene
la tienda y hacer un mejor uso de ello.
1.4.2 DELIMITACIÓN
La investigación se realizó en la tienda principal de la empresa Topi Top de la
ciudad de Lima, en sus áreas de ventas y almacén, usando datos del año 2017.
4
CAPÍTULO II
REVISIÓN DE LA LITERATURA
2.1 ANTECEDENTES DE LA INVESTIGACIÓN

Según Silva (2017), en su tesis “Análisis, Diseño e Implementación de un
Datamart que garantice una adecuada toma de decisiones en el área de ventas en la
empresa PROMED E.I.R.L. Lima-2017” concluye que, al desarrollar el análisis, diseño
e implementación de un Datamart permitió garantizar una adecuada toma de decisiones
en el área de ventas en la empresa PROMED E.I.R.L, evaluando la actualización de la
información, compatibilidad y dinámica entre el personal de la empresa.
Según Moreno (2013), en su tesis “análisis, diseño e implementación de datamarts para

las áreas de ventas y recursos humanos de una empresa dedicada a la exportación e
importación de productos alimenticios” menciona que, al hacer un Datamart permitirá
tomar las mejores decisiones frente a los problemas presentados en las áreas de ventas y
de recursos humanos; aprovechando, de este modo, todas las ventajas que una solución
de BI brinda; como la granularidad de la información, uso de técnicas de explotación
como dice, slice, drill down, consultas rápidas y cuyo objetivo es generar una mayor
rentabilidad en la organización.
Según la investigación de Mauricio Mendoza Paitán en su tesis “Análisis, Diseño e

Implementación de un sistema gerencial basado en una suite integrada de DataMarts para
las áreas de finanzas, contabilidad, recursos humanos y comercial” menciona que los
modelos multidimensionales de cada uno del DataMarts deben ser lo más completa
posible y permitir escalabilidad, debido a que los usuarios siempre podrán tener nuevos
requerimientos en cuanto a dimensiones o variables a analizar y la solución debe permitir
estos cambios sin tener que realizar demasiado mantenimiento. (Mendoza, 2011).
Según Fernández (2009), en su tesis “Análisis, diseño e implementación de un Datamart

de clientes para el área de marketing de una entidad aseguradora”, argumenta que al hacer
uso de un Datamart de Clientes en el área de marketing permitirá a los usuarios contar
con la herramienta para monitorear la gestión del negocio y contar con una visión acerca
del cumplimiento de sus objetivos; para cumplir con el objetivo de este Datamart integró
5
información de las distintas fuentes y aplicando las reglas de negocio vigentes. Además,
el diseño realizado es flexible para afrontar el problema de duplicación de clientes
existente en la organización.
Según Toainga (2014), en su tesis “Construcción de un Datamart orientado a las a ventas

para la toma de decisiones en la empresa AMEVET CIA. LTDA” menciona que, La
implementación de un datamart permite tener conocimiento de los procesos de venta que
se realizan actualmente mediante el sistema transaccional que tiene la empresa mejorando
los procesos actuales de ventas de los productos avícolas a través del análisis los reportes
de clientes, vendedores, productos y zonas de distribución, considerando a vendedores y
periodos de venta.
2.2 MARCO TEÓRICO

2.2.1 INFORMACIÓN TÁCTICA
De acuerdo a Francois (2004), la información táctica es aquella que muestra un
aspecto panorámico y central de la realidad y su evolución, sirviendo para proyectar y
prever futuras realidades, como las estadísticas, los análisis históricos, los informes y
documentos de situación política, social, económica y cultural. Con esta información y la
base ideológica se construyen los modelos para las diversas temáticas.
“Abarca periodos de tiempo relativamente cortos (no mayores a 12 meses); se emplea en

los niveles gerenciales medios para instrumentar programas de planeación estratégicas y
planes específicos para las áreas funcionales de la organización. Se centran alrededor de
los lineamientos de los planes subordinados, necesarios para instrumentar una estratégica
en particular, y después en el mantenimiento y control del rendimiento real contra los
planes definidos. Está orientada principalmente a soportar la toma de decisiones que se
asocia a gerencias o subdirecciones para alcanzar la misión empresarial; este tipo de
información es extraída específicamente de un área o departamento de la organización,
por lo que su alcance es local” (Thierauf, 1994, p. 29).
La gerencia intermedia necesita información operacional que le ayude con la actividad de

supervisión, control, toma de decisiones, administración y desempeño actual de la
organización y son responsables de encontrar las mejores medidas de ejecutar las
decisiones estratégicas de sus superiores (Effy, 2001, p. 342).
6
La información táctica es un proceso continuo y permanente, orientado al futuro cercano,
racionalizando la toma de decisiones, determinando las acciones. Y es sistémico, ya que
es una totalidad formada por el sistema y subsistemas, visto desde un punto de vista
sistémico. Es iterativo, ya que se proyecta y debe ser flexible para aceptar ajustes y
correcciones. Es una técnica cíclica que permite mediciones y evaluaciones conforme se
ejecuta. Es dinámica e interactiva con los demás, y es una técnica que coordina varias
actividades para conseguir la eficiencia de los objetivos deseados (Cawkel, 1999).
VENTA
Según la American Marketing Asociation, define a la venta como “el proceso personal o
impersonal por el que el vendedor comprueba, activa y satisface las necesidades del
comprador para el mutuo y continuo beneficio de ambos (el vendedor y del comprador)”.
El diccionario de Marketing de Cultural S.A., define a la venta como “un contrato en el

que el vendedor se obliga a transmitir una cosa o un derecho al comprador, a cambio de
una determinada cantidad de dinero”. También incluye en su definición, que “la venta
puede considerarse como un proceso personal o impersonal mediante el cual, el vendedor
pretende influir en el comprador”.
2.2.2 VENTAS
Según (Rivera, 2012) Los indicadores de ventas se definen como una magnitud
que expresa el comportamiento o desempeño de un proceso, que al compararse con algún
nivel de referencia permite detectar desviaciones positivas o negativas. También es la
conexión de dos medidas relacionadas entre sí, que muestran la proporción de la una con
la otra.
“Es el monto total cobrado por productos o servicios prestados. La venta es una acción
que se genera de vender un bien o servicio a cambio de dinero. Está orientado al futuro
cercano, racionalizando la toma de decisiones, determinando las acciones en función a la
totalidad formada por el sistema y subsistemas. Es iterativo, porque se proyecta y debe
ser flexible para aceptar ajustes y correcciones. Es una técnica cíclica que permite
mediciones y evaluaciones conforme se ejecuta” (Fernández, 2009, p. 54).
7
2.2.2.1 VENDEDOR
El vendedor es el elemento más importante de las ventas personales porque
permite establecer una comunicación directa y personal con los clientes actuales y
potenciales de la empresa ya que tiene la facultad de cerrar la venta y de generar y cultivar
relaciones personales a corto y largo plazo con los clientes (Kotler, Armstrong, 2003).
2.2.2.2 METAS
Según Cepymenews (2016) Las metas pueden definirse como pequeños
objetivos que el individuo se plantea para lograr llegar a un objetivo final en el ámbito
empresarial, toda organización requiere dentro de su planificación estratégica la
proyección de metas que se encuentren orientadas al logro de un objetivo.
Según Corahua (2011) Las metas personales o de equipo se deben hacer ajustándolas con
las metas anuales de ventas, ya que el objetivo mensual de ventas no puede ir al revés del
objetivo anual de ingresos de la empresa. Una vez definido el objetivo, se debe calcular
cuánto se necesita vender para cumplir el objetivo ya bien sea del departamento, equipo
o representantes individuales.
2.2.2.2 VENTAS POR VENDEDOR

Según Moreno (2014) Las ventas por vendedor son ventas realizadas por el
vendedor, Mide los ingresos de un vendedor por la venta de un producto.
Se calcula con la siguiente formula:
Venta Por Vendedor = Suma total Cantidad Vendida * por Vendedor
2.2.2.3 METAS POR VENDEDOR

Según Duran (2011) Son Cuotas asignada por cada vendedor para cumplir sus
objetivos de trabajo como vendedor día a día. Medir las metas de un vendedor de ventas
ayuda a incentivar a los vendedores y a determinar las compensaciones basadas en
resultados.
Metas Por Vendedor =Meta–Cantidad Vendida
8
2.2.2.5 METAS POR TIENDA
Según Baumgarten (2012) Las metas por tienda determinan las prioridades para
cada tienda, ayudan a que los resultados de la empresa sean medibles, y sirven como guía
para el crecimiento de la empresa. Las metas cubren las características dentro de su
definición para considerarse un objetivo inteligente.
El objetivo principal de la mayoría de las compañías dedicadas a las tiendas de cualquier

producto al consumo del cliente final es vender sus productos y obtener la mayor ganancia
posible (Según un reporte realizado por el Bureau of Labor Statistics, 2009).
Metas Por tienda =Meta día–Cantidad *Precio de Venta
2.2.2.6 LINEAS MAS VENDIDAS POR ESTILO

Una línea de productos es un grupo de productos relacionados entre sí que se
ofrecen a la venta. Al contrario que la agrupación de productos en la que varios productos
se combinan en uno, la creación de líneas de productos implica el ofrecer varios productos
relacionados entre sí pero de forma individual (Stanton, 2018).
Línea más vendida = Total cantidad vendida - cantidad venida por Estilo
2.2.2.7 VENTAS POR FORMA DE PAGO

Es el atributo que precisa la forma en la que se realizará el pago de una operación
de venta cuando el cliente cubrirá el total de la operación al momento de recibir la factura.
Para este punto proporciona un catálogo de formas de pago donde se incluyen algunas
reglas para incluir datos del ordenante o beneficiario, también se define que formas de
pago son bancarizadas y cuales pueden incluir el tipo de pago (Osorio, 2016). Se calcula
con la siguiente formula:
Venta Por Forma de Pago =Cantidad Vendida* Tipo de Pago
2.2.2.8 VENTA MENSUAL

Las proyecciones de ventas se muestran por lo general en términos monetarios
o de unidades. Para conocer el resultado se trabaja sobre un determinado periodo de
tiempo. El pronóstico de ventas puede calcularse sobre una base mensual (Villalobos,
9
2017). Se calcula con la siguiente formula:
Venta Mensual= desde fecha inicio y fecha fin * Total cantidad vendida
2.2.3 ALMACEN
El almacén es un lugar especialmente estructurado y planificado para custodiar,
proteger y controlar los bienes de activo fijo o variable de la empresa, antes de ser
requeridos para a la administración, la producción o a la venta de artículos o mercancías.
Todo almacén puede considerarse redituable para un negocio según el apoyo que preste a
las funciones productoras de utilidades: producción y ventas. Es importante hacer hincapié
en que lo almacenado debe tener un movimiento rápido de entrada y salida, o sea una
rápida rotación. Laudon (2004).
Según Kendall (2011) Todo manejo y almacenamiento de materiales y productos es algo

que eleva el costo del producto final sin agregarle valor, razón por la cual se debe conservar
el mínimo de existencias con el mínimo de riesgo de faltantes y al menor costo posible de
operación.
2.2.3.1 STOCK DISPONIBLE

Es el stock que marca el inventario y lo que debería haber realmente en almacén
debería ser siempre positivo o cero. Stock disponible es el que sirve para atender la
demanda ciclo: normal de los clientes. Es el que está en el lineal para atender las ventas
más inmediatas, es decir, las que están a la vista del consumidor. Sánchez (2014).
Según Booch (2007), los bienes disponibles que tiene una compañía para su explotación
comercial, refiere a la cantidad de bienes o productos que dispone una organización o un
individuo en un determinado momento para el cumplimiento de ciertos objetivos.
Stock Disponible = cantidad recibida –Cantidad despachada –Cantidad
2.2.3.2 TRANSFERENCIA A TIENDA POR ESTILO

Puede transferir inventarios de productos entre almacenes creando pedidos de
transferencia. También puede usar el diario de reclasificación de productos. Con los
pedidos de transferencia, se envía la transferencia de salida desde un almacén y se recibe
10
la transferencia de entrada en el otro almacén. Esto permite administrar las actividades de
almacén correspondientes y proporciona más certidumbre de que las cantidades del
inventario se actualizan correctamente. Zambrano (2014).
Transferencia =Stock disponible - Cantidad Requerida
2.2.3.3 STOCK TOTAL DE COMPAÑÍA

Los stocks representan generalmente una de las mayores inversiones que realiza
la empresa y sus costos de mantenimiento. Es así, que uno de los temas del área de la
dirección de producción más comentada en los últimos tiempos en todo el mundo, tanto al
nivel de las grandes empresas fabricantes como distribuidores y de las medianas y
pequeñas empresas, es el de la gestión de los materiales y el control de los stocks. Los
stocks representan los materiales que posee una empresa, en general recursos materiales
que no se utilizan en un momento determinado en previsión de necesidades futuras. Los
stocks resultan imprescindibles para proporcionar un buen servicio al cliente, efectuar las
operaciones de la fábrica lo más eficientemente posible manteniendo la producción a un
ritmo regular y para producir lotes de tamaño razonable (Castillo, 2010).
Stock Total = Cantidad disponible + cantidad recibida - Cantidad salida – cantidad

Vendida.
2.2.3.4 AJUSTE DE INVENTARIO

Un ajuste de inventario es un movimiento de entrada o salida de artículos al
almacén, es funcional para agregar el inventario inicial, pérdidas o aumentos de mercancía.
Para agregar un ajuste debe tener su lista de precios agregada, el catálogo de conceptos de
ajustes y abrir el módulo de ajustes de inventario y registrar uno nuevo. Un ajuste es el
asiento o registro contable, el cual se realiza para llevar el saldo de una cuenta a su valor
real (Herz Ghersi,2013).
Se calcula con la siguiente formulas:
Ajuste de Inventario Entrada= stock disponible + cantidad ajuste
Ajuste de Inventario Salida= stock disponible - cantidad ajuste
11
2.2.4. DATAMART
Según Güratan (2005), un Datamart es donde se almacenan datos, tiene que estar
separado, los datos se extraen de diferentes bases de datos para crear información que
sean confiables para la toma de decisiones en la empresa. Se le considera como un sistema
que da soporte en el proceso de toma de decisiones, también su importancia está en los
informes ya que arrojaran los resultados solicitados por el usuario. Hay similitudes entre
un Datamart y un Datawarehouse, sus estructuras y propósito son similares; Pero el
Datamart está creada solo para una área en específico. Los datamart almacenan menos
información ya fueron creadas para un propósito concreto.
Según Ramos (2011), El Datamart planteado será una herramienta que ofrecerá al usuario
un fácil acceso, entendible y amigable de la información, el usuario no necesitara de
conocimientos informáticos para poder manipular la herramienta. Esto es una gran
ventaja para la empresa porque podrá manipular convenientemente su información para
mejorar los procesos dela área, prestar más atención a los cliente fidelizándolos a si
mejorar las ventas, y anticiparse a los errores de ingreso de información.
Para Yalán y Palomino (2012), un Datamart es una base de datos departamental, especializada
en el almacenamiento de los datos de un área de negocio específica. Se caracteriza por disponer
la estructura óptima de datos para analizar la información al detalle desde todas las
perspectivas que afecten a los procesos de dicho departamento. Un datamart puede ser
alimentado desde los datos de un data Warehouse, o integrar por sí mismo un compendio de
distintas fuentes de información.
Según Mendoza (2011) un Datamart consiste en una colección de datos y un sistema de

análisis que extrae la información de varias fuentes de datos transaccionales, de manera
que los almacena y analiza para mostrar tendencias e indicadores de gestión del flujo del
negocio. Los datos son almacenados utilizando un modelo de datos conocido como
Modelo Estrella (Star Schema) con el objetivo de analizarlos de manera agrupada y
enfocada a un área de negocio específico.
Según Santiago (2006) se define como un almacén de datos especializado, orientado a un

tema, integrado, volátil y variante en el tiempo para apoyar un subconjunto especifico
de decisiones de administración. La principal diferencia entre una datamart y una
12
datawarehouse es que la primera es especializada y volátil. Hay tres enfoques para la
creación de una datamart:
a. Los datos pueden ser simplemente extraídos de la datawarehouse.
b. A pesar del hecho de que la datawarehouse pretende proporcionar un punto de
control único una datamart puede ser creado todavía en forma independiente
(es decir, no por medio de la extracción a partir de la datawarehouse.
c. Algunas instalaciones han seguido un enfoque de “primero la datamart” donde
estos son creados conforme van siendo necesarios y la datawarehouse general
es creada, como una consolidación de los diversos datamart.
Kimball y Ross (2013) se indica que un datamart presenta los datos de un único proceso
de negocio. Estos procesos de negocios cruzan los límites de las funciones de la
organización. Todos los datamart deben ser construidos usando dimensiones comunes y
hechas.
En Oracle (2012) se indica que un datamart es una forma simple de un almacén de datos
que se centra en un solo tema (o área funcional), tales como ventas, finanzas, o Marketing.
Datamarts son frecuentemente construidos y controlados por un solo departamento dentro
de una organización. Teniendo en cuenta su sola materia en el enfoque, los datamarts por
lo general obtienen datos de sólo unas pocas fuentes. Las fuentes pueden ser sistemas
operacionales internos, una central de almacenamiento de datos o de datos externos.
Lane (1999) afirma que, un DataMart es una forma más sencilla de un Datawarehouse
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 Datawarehouse, las cuales pueden ser sistemas
operacionales internos o un Datawarehouse interno o externo.
A) TIPOS DE DATAMART
Se definen dos tipos de DataMart, los dependientes y los independientes:
DEPENDIENTES: Son los que se construyen a partir de un Data Warehouse central, es
decir reciben sus datos de un repositorio empresarial central.
13
Figura 2.1. Datamart dependiente.
INDEPENDIENTES: Son aquellos DataMart 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.2. Datamart independiente
2.2.3.1 VENTAJAS Y DESVENTAJAS

VENTAJAS. -Para Nader (2002), los principales beneficios de utilizar
datamarts son:
a) Dado que un datamarts soporta menos usuarios que un data Warehouse se
puede optimizar para recuperación más rápida los datos que necesitan los
usuarios.
b) Menores cantidades de datos implica que se procesan antes, tanto las cargas de
datos como las consultas.
14
c) Las peticiones pueden acotarse al área o red sirve esos datos, sin afectar al resto
de los usuarios.
d) Las aplicaciones cliente, pide las consultas es independiente del servidor que
la procesa y del servidor de bases de datos que almacenan la información.
e) Los costos que implica la construcción de un datamarts son mucho menos a los
de la implementación de un data Warehouse.
DESVENTAJA. - No permite el manejo de grandes volúmenes de información por lo

que muchas veces se debe recurrir a un conjunto de datamarts para cubrir todas las
necesidades de información de la empresa (Vizuete y Yela, 2006).
2.2.4 METODOLOGIA HEFESTO

De acuerdo Espinoza (2010) la metodología Hefesto es propia para la
construcción de datamart, dataWarehouse, que partirá de la recolección de requerimientos
y necesidades de información de los usuarios, y concluirá en la confección de un esquema
lógico y sus respectivos procesos de extracción, transformación y carga de datos.
De acuerdo a Bernabeu (2010) Hefesto es una metodología propia, cuya propuesta está
fundamentada en una muy amplia investigación, comparación de metodologías
existentes, experiencias propias en procesos de confección de almacenes de datos. Cabe
destacar que HEFESTO está en continua evolución, y se han tenido en cuenta, como gran
valor agregado, todos los feedbacks que han aportado quienes han utilizado esta
metodología en diversos países y con diversos fines. La idea principal, es comprender
cada paso que se realizará, para no caer en el tedio de tener que seguir un método al pie
de la letra sin saber exactamente qué se está haciendo, ni por qué. La construcción e
implementación de un Data Warehouse puede adaptarse muy bien a cualquier ciclo de
vida de desarrollo de software, con la salvedad de que para algunas fases en particular,
las acciones que se han de realizar serán muy diferentes. Lo que se debe tener muy en
cuenta, es no entrar en la utilización de metodologías que requieran fases extensas de
reunión de requerimientos y análisis, fases de desarrollo monolítico que conlleve
demasiado tiempo y fases de despliegue muy largas. Lo que se busca, es entregar una
primera implementación que satisfaga una parte de las necesidades, para demostrar las
ventajas del data Warehouse y motivar a los usuarios, la metodología Hefesto sugiere
distribuir el proceso en cuatro fases:
15
Figura N° 2.1. Metodología HEFESTO, pasos (Bernabéu, 2010).
CARACTERÍSTICAS
Esta metodología tiene las siguientes características según (Bernabéu, 2010):
a) Los objetivos y resultados esperados en cada fase se distinguen fácilmente y
son sencillos de comprender.
b) Se basa en los requerimientos del usuario, por lo cual su estructura es capaz de
adaptarse con facilidad y rapidez ante los cambios en el negocio.
c) Reduce la resistencia al cambio, ya que involucra al usuario final en cada etapa
para que tome decisiones respecto al comportamiento y funciones del DW.
Utiliza modelos conceptuales y lógicos, los cuales son sencillos de interpretar
y analizar.
16
d) Es independiente del tipo de ciclo de vida que se emplee para contener la
metodología. Es independiente de las herramientas que se utilicen para su
implementación.
e) Es independiente de las estructuras físicas que contengan el DW y de su
respectiva distribución.
f) Cuando se culmina con una fase, los resultados obtenidos se convierten en el
punto de partida para llevar a cabo el paso siguiente.
g) Se aplica tanto para DM como para DW.
2.2.4.1 ANALISIS DE REQUERIMIENTO

Bernabeu (2010), menciona que el análisis de requisitos consta de los
siguientes pasos: a) Identificar preguntas. - El objetivo principal de esta fase, es la de
obtener e identificar las necesidades de información clave de alto nivel, que es esencial
para llevar a cabo las metas y estrategias de la empresa, y que facilitará una eficaz y
eficiente toma de decisiones. La idea central es, que se formulen preguntas complejas
sobre el negocio, que incluyan variables de análisis que se consideren relevantes, ya que
son estas las que permitirán estudiar la información desde diferentes perspectivas. Un
punto importante que debe tenerse muy en cuenta, es que la información debe estar
soportada de alguna manera por algún OLTP, ya que, de otra forma, no se podrá elaborar
el Data Warehouse; b) Identificar indicadores y perspectivas. - Una vez que se han
establecido las preguntas de negocio, se debe proceder a su descomposición para
descubrir los indicadores que se utilizarán y las perspectivas de análisis que intervendrán.
En cambio, las perspectivas se refieren a los objetos mediante los cuales se quiere
examinar los indicadores, con el fin de responder a las preguntas planteadas, por ejemplo:
clientes, proveedores, sucursales, países, productos, rubros, etc. Cabe destacar, que el
Tiempo es muy comúnmente una perspectiva; c) Modelo conceptual. - En esta etapa, se
construirá un modelo conceptual a partir de los indicadores y perspectivas obtenidas en
el paso anterior. A través de este modelo, se podrá observar con claridad cuáles son los
alcances del proyecto, para luego poder trabajar sobre ellos, además al poseer un alto
nivel de definición de los datos, permite que pueda ser presentado ante los usuarios y
explicado con facilidad.
17
Figura N° 2.2. Indicadores y perspectivas (Bernabeu, 2010)
Figura N° 2.3. Modelo conceptual (Bernabeu, 2010)
2.2.4.2 ANÁLISIS DE LOS PROCEDIMIENTOS DE TRANSACCIONES EN

LÍNEA (OLTP)
Bernabeu (2010) menciona que en el Análisis de los OLTP se analizarán las
fuentes OLTP para determinar cómo serán 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 definirán qué campos se incluirán en cada perspectiva.
Finalmente, se ampliará el modelo conceptual con la información obtenida en este paso.
El Análisis de los OLT tiene a) Conformar indicadores. - Hechos que lo componen con
su respectiva fórmula de cálculo Hecho1+Hecho2 y función de sumarización que se
utilizara para su agregación como SUM, AVG, COUNT; b) Establecer correspondencias.
- El objetivo de este paso, es el de examinar los OLTP disponibles que contengan la
información requerida, como así también sus características, para poder identificar las
correspondencias entre el modelo conceptual y las fuentes de datos. La idea es, que todos
los elementos del modelo conceptual estén correspondidos en los OLTP; c) Nivel de
granularidad. - Una vez que se han establecido las relaciones con los OLTP, se debe
seleccionar los campos que contendrá cada perspectiva, ya que será a través de estos por
los que se examinarán y filtrarán los indicadores. Para ello, basándose en las
correspondencias establecidas en el paso anterior, se debe presentar a los usuarios los
datos de análisis disponibles para cada perspectiva. Es muy importante conocer en detalle
18
que significa cada campo y/o valor de los datos encontrados en los OLTP, por lo cual, es
conveniente investigar su sentido, ya sea a través de diccionarios de datos, reuniones con
los encargados del sistema, análisis de los datos propiamente dichos, etc; 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 fórmula de cálculo.
Figura N° 2.4. Caso práctico, correspondencia (Bernabeu, 2010)
Figura N° 2.5. Modelo Conceptual ampliado (Bernabeu, 2010)
19
El proceso transaccional en línea OLTP (on-line Transactional Processing) es un tipo de
proceso especialmente rápido en el que las solicitudes de los usuarios son resueltas;
naturalmente, ello implica la concurrencia de un “mecanismo” que permite el
procesamiento de varias transacciones a la vez. (Torres, 2007)
Bernabeu (2009) afirma que, los sistemas OLTP representa toda aquella información
transaccional que genera la empresa en su accionar diario, además, de las fuentes externas
con la que puede llegar a disponer, estas fuentes de información, son de características
muy disímiles entre sí, en formato, procedencia, función, etc, entre los OLTP más
habituales que puedan existir en cualquier organización se encuentran los archivos de
texto, hipertextos, hojas de cálculo, informes semanales.
2.2.4.3 MODELO LOGICO DEL DATA WAREHOUSE

Bernabeu (2010) afirma que, el modelo lógico de data Warehouse se
confeccionará de la estructura del DW, 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
llevarán a cabo las acciones propias al caso, para diseñar las tablas de dimensiones y de
hechos. Finalmente, se realizarán las uniones pertinentes entre estas tablas. El modelo
lógico del data Warehouse consta de a) Tipo de Modelo lógico del DW. - Se debe
seleccionar cuál será el tipo de esquema que se utilizará para contener la estructura del
depósito 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,
constelación o copo de nieve, ya que esta decisión afectará considerablemente la
elaboración del modelo lógico; b) Tablas de dimensiones.- Se elegirá un nombre que
identifique la tabla de dimensión, se añadirá un campo que represente su clave principal,
se redefinirán los nombres de los campos si es que no son lo suficientemente intuitivos;
c) Tablas de hecho.- En este paso, se definirán las tablas de hechos, que son las que
contendrán los hechos a través de los cuales se construirán los indicadores de estudio; d)
Uniones.- Para los tres tipos de esquemas, se realizarán las uniones correspondientes
entre sus tablas de dimensiones y sus tablas de hechos. Los nombres de los campos si es
que no son lo suficientemente intuitivos.
20
Figura N° 2.6. Tablas de dimensiones (Bernabeu, 2010)
Figura N° 2.7. Tabla de hechos (Bernabeu, 2010)
Figura N° 2.8. Uniones (Bernabeu, 2010)
Según Inmon (2002), un data Warehouse es una colección de datos orientados a temas,
integrados, no-volátiles y variante en el tiempo, organizados para soportar necesidades
empresariales.
Según definición de INEI (2005), un Data Warehouse se crea al extraer datos desde una
o más bases de datos de aplicaciones transaccionales. La data extraída es transformada
para eliminar inconsistencias y resumida si es necesario, y luego es cargada en el Data
Warehouse. El proceso de transformar, crear el detalle de tiempo variante, resumir y
combinar los extractos de datos, ayudan a crear el ambiente para el acceso a la
21
información de la organización. Este nuevo enfoque orienta a las personas, en todos los
niveles de la organización, a efectuar su toma de decisiones con más responsabilidad.
El data Warehouse debe tener una estructura que permita entregar al usuario la
información que éste requiera, es necesario que se realice un proceso de análisis que
permita al desarrollador definir, en base a los requerimientos iníciales del usuario, el
modelo adecuado. Si la estructura inicial del data Warehouse no satisface todas las
necesidades iníciales, los desarrolladores se verán en la situación de tener que regresar al
comienzo del análisis y redefinir la estructura, corrigiendo errores (Valdiviezo, Herrera y
Jáuregui, 2007).
2.2.4.3.1 TIPOS DE MODELAMIENTO DE UN DW

a. ESQUEMA EN ESTRELLA
“El esquema estrella forma un diagrama en forma de estrella teniendo en el
centro de la estrella una o más 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 través de sus respectivas claves. En la siguiente figura
se puede apreciar un esquema en estrella estándar:
Figura N° 2.9. 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 sólo contiene el nivel que es la
clave primaria en la tabla y la llave foránea de su parentesco del nivel más cercano.”
(Díaz, 2002).
22
“Este esquema representa una extensión del modelo en estrella cuando las tablas de
dimensiones se organizan en jerarquías de dimensiones.” (Bernabeu, 2010).
Figura N° 2.10. Esquema en copo de nieve (Bernabeu, 2010)
2.2.4.3.2 DATA WAREHOUSE VS DATAMART

Datamart son almacenes de datos especializados, diseñados para soportar
necesidades de análisis específicas para un único departamento o área funcional de la
empresa, por ejemplo marketing, finanzas, producción, etc. Estos almacenes soportan
menos usuarios y menos cantidades de datos que un Data Warehouse centralizado, y por
lo tanto pueden ser optimizados para cargar y recuperar la información de forma más
rápida y eficaz que un Data Warehouse (T. Moss y Atre Shaku, 2003). En el caso de
MINEDU se adecúa a las necesidades específicas para responder a los objetivos. A
continuación en la Tabla 1.2 se presenta las diferencias que existen entre Data Warehouse
y Datamart:
23
Tabla 2.1. Diferencias entre warehouse vs datamart
Fuente: Castillo A., (2012).
2.2.4.4 PROCESO DE EXTRACCION, TRANSFORMACIÓN Y CARGA (ETL)

Bernabéu (2010) menciona que, en la Integración de datos se deberá proceder
a poblarlo con datos, utilizando técnicas de limpieza y calidad datos, procesos ETL, etc.;
luego se definirán las reglas y políticas para su respectiva actualización, así como también
los procesos que la llevarán a cabo. La Integración de datos está constituida por:
a. Carga inicial. - Debemos en este paso realizar la Carga Inicial al Datamart,

poblando el modelo de datos que hemos construido anteriormente. Para lo cual debemos
llevar adelante una serie de tareas básicas, tales como limpieza de datos, calidad de datos,
procesos ETL, etc. La realización de estas tareas puede contener una lógica realmente
compleja en algunos casos.
b. Actualización. -Cuando se haya cargado en su totalidad el datamart, se deben

establecer sus políticas y estrategias de actualización o refresco de datos.
Una vez realizado esto, se tendrán que llevar a cabo las siguientes acciones: Especificar
las tareas de limpieza de datos, calidad de datos, procesos ETL, etc., que deberán
realizarse para actualizar los datos del DW, además se debe especificar de forma general
y detallada las acciones que deberá realizar cada software.
24
Figura N° 2.11. Caso práctico, carga Inicial (Bernabeu, 2010)
En Zambrano (2011) se indica que los procesos ETL (de las siglas en inglés Extraction,
Transformation, Load) se encargan de las funciones de extracción de distintas fuentes de
datos, sean estas transaccionales o externas, transformación, realizando tareas de limpieza
y consolidación de datos y la carga de la data warehouse o datamart.
Según Cabanillas (2011), la construcción de ETL consta de tres sub etapas principales:
extracción, transformación y carga de datos; a) Extracción. - durante esta sub etapa se
siguen los procesos necesarios para obtener los datos que permiten efectuar la carga del
modelo físico. b) Transformación. - durante esta sub etapa se siguen los procesos para
convertir los datos fuente a fin de calcular las métricas y mantener un formato estándar
de los datos. c) Carga. - durante esta sub etapa se siguen los procesos necesarios para
poblar los datamarts.
Bernabeu (2010) afirma que, los sistemas ETL, se encargarán de tomar la información
desde diversas fuentes de datos, realizar ciertas transformaciones a los mismos y
finalmente almacenarlos de manera integrada dentro del DW. Estas transformaciones
tienen el propósito de asegurar la integridad de la información en el almacén. Entre las
operaciones principales que realizan se encuentran: la integración, el filtrado y la
depuración. El diseño de los procesos ETL, se lleva a cabo con la asistencia de
herramientas destinadas a tal fin. Por esta razón, solo será necesario enfocarse en la
generación de las sentencias SQL que serán utilizadas para extraer todos los datos de
requeridos desde las fuentes de información. También será posible incluir, entre los
procesos ETL, cualquier otro procedimiento que sea requerido para facilitar el
mantenimiento del modelo de datos.
25
2.2.5 PROCESAMIENTO ANALÍTICO EN LÍNEA OLAP (ON-LINE
ANALYTICAL PROCESSING)
Según, Laudon, K. y Laudon, J (2008), OLAP soporta el análisis de datos
multidimensionales, el cual permite a los usuarios ver los mismos datos en diferentes
formas utilizando múltiples dimensiones, obtener respuestas en línea a preguntas
específicas en un lapso de tiempo sumamente rápido aun cuando los datos están
almacenados en base de datos sumamente grande. OLAP representa las relaciones entre
los datos y cubos dentro de cubos de datos para permitir un análisis de datos más
complejos.
Según Nima (2009) define, Es una tecnología que permite a las aplicaciones de cliente el
acceso eficiente a estos datos.
“Olap Son aplicaciones que se encargan de analizar datos del negocio para generar
información táctica y estratégica que sirve de soporte para la toma de decisiones logrando
su máxima eficiencia y flexibilidad operando sobre Bases de datos multidimensionales.Se
basan en los cubos OLAP, que se construyen agregando, según los requisitos de cada
área o departamento, las dimensiones y los indicadores necesarios de cada cubo
relacional” (Laudon, K. y Laudon, J, 2008).
Según Vitt (2002), OLAP proporciona un modelo de datos intuitivo y conceptual, para
que los usuarios que no tengan experiencia como analistas puedan comprender y
relacionar los datos mostrados. Este modelo es llamado análisis multidimensional, siendo
habilitado para ver los datos a través de múltiples filtros, o dimensiones.
Existen variaciones de OLAP según la cantidad de datos y la eficiencia requerida. OLAP,

no se recomienda para consultas complejas y que recorran muchas tablas.
A. MOLAP (Multidimensional online analytical processing).

Según Vitt (2002), MOLAP ofrece el mayor rendimiento de recuperación de
información; porque los datos son colocados en estructuras especiales que se encuentran
en un servidor central.
Acrónimo de Multidimensional Online Analytical Processing, almacena los datos de una

base de datos multidimensional para la optimización de los tiempos de respuesta con
estructuras optimizadas para acceso multidimensional, las matrices multidimensionales
26
no admiten la ampliación dinámica o desbordamiento de la matriz lo cual lo hace poco
dinámico, pero a su vez con una gran capacidad de respuesta (Tamayo, M. y Moreno F.,
2006).
Según Torres (2007) el MOLAP tiene las siguientes ventajas y desventajas:

Ventajas
a) Excelente performance: los cubos MOLAP son construidos para tener una
rápida recuperación de datos y esta optimizado para operaciones.
b) Puede realizar cálculos complejos: ya que todos los cálculos han sido pre
generados cuando el cubo se crea. Por lo tanto los cálculos complejos se
almacenan y regresan su resultado rápidamente.
Desventajas
Limitado en el monto de datos a ser manejados. Porque todos los cálculos son construidos
cuando se genera el cubo, no es posible incluir grandes cantidades de datos en el cubo en
sí mismo. Esto no quiere decir que los datos del cubo no deriven de una gran cantidad de
datos. Si es posible, pero en este caso, solo la información de alto nivel puede ser incluida
en este.
B. ROLAP (Relational online analytical processing).

Según Vitt (2002), permite tomar ventaja de uno de sus más grandes beneficios,
el almacenamiento de inmensas cantidades de datos. El rendimiento de recuperación de
la información para ROLAP frecuentemente no es tan rápido como otras opciones de
almacenamiento. ROLAP es recomendado para consultas pesadas que no se usan muy a
menudo.
Acrónimo de Relational Online Analytical Processing, almacena los datos en un motor

relacional logrando una mejor flexibilidad mediante los tipos de análisis disponibles,
tener menor tiempo de respuesta para la elaboración de reportes, análisis de una enorme
cantidad de datos. Se implementa sobre tablas físicas diseñadas siguiendo un modelo en
estrella o copo de nieve (Tamayo, M. y Moreno F., 2006).
Según Torres (2007) el ROLAP tiene las siguientes ventajas y desventajas:

Ventajas
27
a) Puede almacenar Grandes cantidades de datos. La limitante de tamaño en la
tecnología ROLAP es la limitante de la base de datos relacional. En otras
palabras, ROLAP en sí misma no está limitada. Puede cubrir funcionalidad
inherente a la Base de Datos relacional. Las bases de datos relacionales ya
vienen con un set de funciones. Ya que esta tecnología se monta sobre esta
Base de Datos hereda todas estas funcionalidades.
Desventajas
a) Performance bajo. Ya que ROLAP es esencialmente múltiples Querys de SQL
en la base de datos relacional, el tiempo de respuesta se alarga entre el tamaño
de la Base de Datos, mientras sea más grande será más lenta.
b) Limitada funcionalidad SQL. Ya que la tecnología ROLAP utiliza básicamente
sentencias SQL o querys de la Base de Datos relacional, y SQL no aporta todas
las necesidades de consultas multidimensionales, ROLAP son limitadas a lo
que el lenguaje Base de Datos soporte. Se ha desarrollado últimamente
herramientas externas que permiten utilizar formulación más compleja que
pueda cubrir parte de estas deficiencias.
C. HOLAP (Hybrid online analytical processing).

Según VITT (2002), es un híbrido entre MOLAP y ROLAP, HOLAP no es
realmente un modo diferente de almacenamiento de datos. Más bien es la habilidad para
diseminar los datos a través de bases de datos relacionales y multidimensionales con la
finalidad de obtener lo mejor de ambos sistemas.
Acrónimo Hybrid Online Analytical Process, almacena datos con las dos técnicas
anteriores, utilizando MOLAP que ofrece análisis sobre los datos agregados, métricas o
indicadores precalculados y ROLAP que ofrece escalabilidad, cálculo en tiempo real de
reportes requeridos por usuarios, concurrencia y administración madura de los datos
(Tamayo, M. y Moreno F., 2006).
28
Tabla 2.2 Diferencias entre MOLAP, ROLAP, HOLAP
Fuente: Tamayo M., Moreno,F., (2006).
2.2.6 SISTEMA GESTOR DE BASE DE DATOS (SGBD)

Un sistema de gestión de base de datos (SGBD), consiste en una colección de
datos interrelacionados y una colección de programas para acceder a esos datos. Los datos
describen una empresa particular. El objetivo principal de un SGBD es proporcionar un
entorno que sea tanto conveniente como eficiente para las personas que lo usan para la
recuperación y almacenamiento de la información. (Silberschatz, Korth y Sudarshan,
2002).
“No debemos confundir una Base de Datos con un Sistema Gestor de Base de Datos. Una
Base de datos es la información almacenada, que cumple una serie de características y
restricciones, pero para que la información pueda ser almacenada y el acceso a la misma
satisfaga las características exigidas a una base de datos, es necesario que exista una serie
de procedimientos, un sistema software, que sea capaz de llevar a cabo tal labor. A este
sistema de software es lo que llamamos Sistema Gestor de Base de Datos (SGBD)”
(Nevado, s.f)
Según Alejandro (2010), un sistema de gestión de bases de datos almacena los registros
de usuarios, así como también los datos de los grupos dentro de sus propios catálogos de
sistema. De esta manera, cualquier conexión a este debe ser realizada con un usuario
específico, y cualquier usuario puede pertenecer a uno o más grupos definidos.
Luque et al. (2002) afirman que, un SGBD es una colección de programas de aplicación
que proporciona al usuario de la base de datos los medios necesarios para realizar las
29
siguientes tareas:
a. Definición de los datos a los distintos niveles de abstracción (físico, lógico y
externo).
b. Manipulación de los datos en la base de datos, es decir, la inserción,
modificación, borrado y acceso o consulta a los mismo.
c. Mantenimiento de la integridad de la base de datos, integridad en cuanto a los
datos en sí, sus valores y las relaciones entre ellos.
d. Control de la privacidad y seguridad de los datos en la base de datos.
e. Los medios necesarios para el establecimiento de todas aquellas características
exigibles a una base de datos.
BASE DE DATOS
Una base de datos de un Sistema de Información es la representación integrada de los
conjuntos de entidades instancia correspondiente a las diferentes entidades tipo del
Sistema de Información y de sus interrelaciones. Esta representación informática (o
conjunto estructurado de datos) debe poder ser utilizada de forma compartida por muchos
usuarios de distintos tipos. (Camps et al., 2005)
Es una colección de datos organizada en un formato estructurado que es definido como

metadatos que describe esa estructura. Puede pensar en los metadatos como información
sobre los datos almacenados, que define cómo se almacenan éstos en una base de datos.
(Oppel y Sheldon, 2009).
2.2.7 BASE DE DATOS RELACIONAL

De acuerdo a Osorio (2008), es un paradigma que se ha adoptado en las
tecnologías de la información, ninguno como el modelo relacional de las bases de datos
se ha consolidado de una manera tan categórica y unánime, pudiéndose decir que la actual
orientación a objetos debe su éxito a la consolidación de este modelo en la
implementación de las bases de datos.
De acuerdo a Silberschatz (2002), es un modelo de datos utilizado para modela problemas

reales y administrar datos dinámicamente, su idea fundamental son las relaciones que se
dan entre las entidades del diagrama como conjuntos de datos llamados tuplas, la mayoría
de veces se conceptualiza de una manera fácil de imagina, dándose cuenta que cada
relación fuese una tabla compuesta por registros representando las tuplas y los campos.
30
De acuerdo a Heurtel (2009), una base de datos relacional presenta una organización de
los datos basada en el modelo relacional desarrollado en 1970 por Edgar Codd. Es la
estructura más extendida actualmente; En una base de datos relacional, los datos se
organizan en tablas enlazadas de manera lógica. Una tabla incluye columnas (o campos)
que describen una fila (o registro). La relación entre las tablas se establece mediante una
columna.
De acuerdo a Coronel (2004),la base de datos relacional es un depósito de datos en el que

se mantiene su independencia .Sin embargo, el modelo de bases de datos relacional ofrece
varias ventajas importantes como independencia estructural, simplicidad conceptual
mejorada, diseño, ejecución, administración y uso más fácil de la base de datos.
31
CAPÍTULO III
METODOLOGÍA DE LA INVESTIGACIÓN
3.1. TIPO Y NIVEL DE INVESTIGACIÓN

El estudio es de tipo observacional, porque el investigador no ha intervenido en
la generación de datos.
El estudio es de tipo retrospectivo, porque utilizamos los datos generados en la empresa

Topi Top, que son registros pre existente que existen durante la realización de los
procesos de ventas y almacén.
El tipo de estudio es longitudinal, porque recolectamos datos para la variable de

investigación de varios meses del año 2017.
El nivel de investigación es descriptivo, porque nos limitamos a describir y presentar qué

información táctica requiere la empresa Topi Top para las áreas de ventas y almacén.
3.2. DISEÑO DE LA INVESTIGACIÓN

La información que se necesita para el estudio, se ha recolectado de la base de
datos existente del año 2017 de empresa Topi Top, esta información recolectada se
procesara mediante la técnica Hefesto, los indicadores se calculan en función a la
definición teórica y, los resultados que se obtienen serán presentados para las áreas de
ventas y almacén.
3.3. POBLACIÓN Y MUESTRA

A. POBLACIÓN
La población estuvo compuesta por todos los productos en almacén y los
productos vendidos de tienda principal Salaverry de la empresa Topi Top de Lima, para
el año 2017.
B. MUESTRA
No existe muestra, porque el presente estudio considera a todos los productos en
almacén y vendidos de la tienda principal, entonces es un censo.
32
3.4. VARIABLES E INDICADORES
3.4.1 DEFINICIÓN CONCEPTUAL DE LAS VARIABLES
PRIMERA VARIABLE DE INTERES

Ventas. - Las ventas son una acción que se genera de vender un bien o servicio a cambio
de dinero. Está orientado al futuro cercano, racionalizando la toma de decisiones,
determinando las acciones en función a la totalidad formada por el sistema y subsistemas.
VARIABLES DESCRIPTIVAS DE LA PRIMERA VARIABLE DE INTERES

Ventas por vendedor.- Son ventas realizadas por el vendedor, mide los ingresos de un
vendedor por la venta de un producto.
Metas por vendedor. – Son Cuotas asignada para cada vendedor para cumplir sus
objetivos de trabajo como vendedor día a día. Medir las metas de un vendedor ayuda a
incentivar a los vendedores y a determinar las compensaciones basadas en resultados.
Metas por tienda. –Las metas por tienda determinan las prioridades para cada tienda,
ayudan a que los resultados de la empresa sean medibles, y sirven como guía para el
crecimiento de la empresa. El objetivo principal de la mayoría de las compañías dedicadas
a las tiendas de cualquier producto al consumo del cliente final es vender sus productos y
obtener la mayor ganancia posible.
Líneas más vendidas por estilo.- Una línea de productos es un grupo

de productos relacionados entre sí que se ofrecen a la venta. Al contrario que la
agrupación de productos en la que varios productos se combinan en uno, la creación de
líneas de productos implica el ofrecer varios productos relacionados entre sí pero de forma
individual.
Ventas por forma de pago.- Es el atributo que precisa la forma en la que se realizará
el pago de una operación de venta cuando el cliente cubrirá el total de la operación al
momento de recibir la factura. Para este punto proporciona un catálogo de formas de pago
donde se incluyen algunas reglas para incluir datos del ordenante o beneficiario, también
se define que formas de pago son bancarizadas y cuales pueden incluir el tipo de pago.
Venta mensual.- Las proyecciones de ventas se muestran por lo general en términos
33
monetarios o de unidades. Para conocer el resultado se trabaja sobre un determinado
periodo de tiempo. El pronóstico de ventas puede calcularse sobre una base mensual.
SEGUNDA VARIABLE DE INTERES

Almacén.- El almacén es un lugar especialmente estructurado y planificado para
custodiar, proteger y controlar los bienes de activo fijo o variable de la empresa, antes de
ser requeridos para a la administración, la producción o a la venta de artículos o
mercancías. Todo almacén puede considerarse redituable para un negocio según el apoyo
que preste a las funciones productoras de utilidades: producción y ventas. Lo almacenado
debe tener un movimiento rápido de entrada y salida o sea una rápida rotación.
VARIABLES DESCRIPTIVAS DE LA SEGUNDA VARIABLE DE INTERES

Stock disponible. - El stock disponible es el que marca el inventario y lo que debería
haber realmente en almacén debería ser siempre positivo o cero. Stock disponible es el
que sirve para atender la demanda de ciclo normal de los clientes.
Transferencia a tienda por estilo.- La transferencia a tienda por estilo es aquella que se
puede transferir inventarios de productos entre almacenes creando pedidos de
transferencia. También puede usar el diario de reclasificación de productos con los
pedidos de transferencia, se envía la transferencia de salida desde un almacén y se recibe
la transferencia de entrada en el otro almacén. Esto permite administrar las actividades de
almacén correspondientes y proporciona más certidumbre de que las cantidades del
inventario se actualizan correctamente.
Stock total de compañía.- El stock total de compañía es la que representa una de las
mayores inversiones que realiza la empresa y sus costos de mantenimiento. Es así, que
uno de los temas del área de la dirección de producción más comentada en los últimos
tiempos en todo el mundo, tanto al nivel de las grandes empresas fabricantes como
distribuidores y de las medianas y pequeñas empresas, es el de la gestión de los materiales
y el control de los stocks. El stock total de compañía representa los materiales que posee
una empresa, en general recursos materiales que no se utilizan en un momento
determinado en previsión de necesidades futuras.
Ajuste de inventario.- Un ajuste de inventario es un movimiento de entrada o salida de
34
artículos al almacén, es funcional para agregar el inventario inicial, pérdidas o aumentos
de mercancía. Para agregar un ajuste debe tener su lista de precios agregada, el catálogo
de conceptos de ajustes y abrir el módulo de ajustes de inventario y registrar uno nuevo.
Un ajuste es el asiento o registro contable, el cual se realiza para llevar el saldo de una
cuenta a su valor real.
3.4.2. DEFINICIÓN OPERACIONAL DE LAS VARIABLES
PRIMERA VARIABLE DE INTERES

X: Ventas
VARIABLES DESCRIPTIVAS DE LA PRIMERA VARIABLE DE INTERES
X1: Ventas por vendedor
X2: Metas por vendedor
X3: Metas por tienda
X4: Líneas más vendidas por estilo
X5: Ventas por forma de pago
X6: Venta mensual
SEGUNDA VARIABLE DE INTERES

Y: Almacén
VARIABLES DESCRIPTIVAS DE LA SEGUNDA VARIABLE DE INTERES
Y1: Stock disponible.
Y2: Transferencia a tienda por estilo
Y3: Stock total de compañía
Y4: Ajuste de inventario
3.5 TÉCNICAS E INSTRUMENTOS PARA RECOLECTAR INFORMACIÓN

3.5.1 TÉCNICAS
Se utilizó la técnica de análisis documental para recolectar datos en relación a las
variables ventas y almacén.
35
3.5.2 INSTRUMENTOS
Se utilizó la ficha de análisis documental que se denominó, ficha de análisis de
la base de datos. Esta ficha permite obtener datos a partir de la base de datos de Topi
Top.
3.6 HERRAMIENTAS PARA EL TRATAMIENTO DE DATOS
Tabla 3.1. Herramientas tecnológicas para el tratamiento de datos.

SOFTWARE FABRICANTE SERVICIO
Es la versión más reciente de Microsoft
Microsoft
Windows 10 Windows, línea de sistemas operativos
Corporation
producida por Microsoft Corporation.
Sql server business Es el entorno que utilizará para desarrollar
intelligence Microsoft cubos de Procesamiento analítico en línea
development studio Corporation (OLAP) y modelos de minería de datos en
2014 SQL Server Analysis Services.
Es la última versión del sistema operativo
Microsoft Sql Server Microsoft Windows para servidores, ofrece el marco
2014 Corporation para instalar el servidor web y el servidor de
datos.
Es un Entorno Integrado de Desarrollo para
Microsoft
Visual Studio 2015 Sistemas operativos Windows. Soporta
Corporation.
varios lenguajes de programación.
Fuente: Elaboración propia.
3.7 TÉCNICAS PARA APLICAR LA METODOLOGÍA HEFESTO

Observando la revisión literaria desarrollada en el capítulo II, sección 2.2.4,
formulamos el proceso, que considera las fases para desarrollar el datamart que aplica el
método Hefesto, como se muestra en las tablas 3.2 a 3.5.
36
Tabla 3.2. Análisis de requisitos.
TAREA ENTREGABLE TÉCNICA RESPONSABLES
a. Entrevistas
Analista de
Identificar b. Formulación de
Lista de preguntas negocio,
preguntas preguntas
desarrollador
c. Observaciones
Identificar
indicadores y Lista de indicadores a. Entrevistas
Desarrollador
perspectivas de y perspectivas b. Encuestas
análisis
Realizar el Diagrama del Analista de
Construir el esquema en
modelo modelo conceptual negocio,
estrella
conceptual inicial. desarrollador
Fuente: Lapa,C., (2016).
Tabla N° 3.3: Análisis de los OLTP.

Lista de Determinación de Analista de
Conformar
indicadores función matemática o negocio,
indicadores
cuantificados. estadística desarrollador
Prueba de Analista de
Establecer
existencia de Comparación. negocio,
correspondencia
datos desarrollador
Nivel de Analista de
Determinar el nivel Análisis de las
granularidad de negocio,
de granularidad perspectivas
las perspectivas desarrollador
Diagrama de
Realizar el modelo Ampliación del
Modelo
conceptual modelo conceptual Desarrollador
Conceptual
ampliado con cada perspectiva
Ampliado
37
Tabla N° 3.4: Modelo lógico del datamart.
Realizar el Diagrama del
Esquema estrella Desarrollador
modelo lógico modelo lógico
a. Definir nombre a la
tabla de dimensión
Diagrama de las
Diseñar las tablas b. Añadir un campo de la Analista de negocio,
tablas de
de dimensiones clave principal desarrollador
dimensiones
c. Redefinir nombres de
campos
a. Definir nombre a la
tabla de hechos
Realizar las Diagrama de las b. Definir la clave Analista de negocio,
tablas de hechos tablas de hechos primaria desarrollador
c. Añadir campos de
hechos como indicadores
Diagrama del
Hacer uniones esquema de Esquema estrella desarrollador
uniones
Tabla N° 3.5: Proceso de ETL.

Extracción,
Carga del almacén a. Limpieza de datos
transformación de Desarrollador
intermedio b. Procesos ETL
la carga inicial
Analista de
Actualización de Datos cargados en Carga de todas las
negocio,
las tablas el Datamart tablas y dimensiones
desarrollador
Creación de
Creación de cubos Cubo
indicadores, atributos Desarrollador
multidimensionales multidimensional
y jerarquías.
38
CAPITULO IV
RESULTADOS DE LA INVESTIGACIÓN
4.1 RESULTADOS APLICANDO EL MÉTODO HEFESTO

4.1.1 ANÁLISIS DE REQUISITOS
Según el procedimiento desarrollado en las tablas 3.2 al 3.5, se indica la
metodología Hefesto, descrita en el capítulo II sección 2.2.6; fase de análisis de requisitos,
se obtiene la lista de preguntas indicadores, perspectivas y el diagrama del modelo
conceptual.
Tabla 4.1. Lista de preguntas

ÍTEM PREGUNTA FINALIDAD
Conociendo las cantidades podrá realizar
¿Cuántas ventas realizan al día,
1 la monitorización de indicadores y emitir
semanal, mensual y anual?
reportes oportunos.
¿Cuántas ventas realizan los Conociendo las cantidades podrá realizar
2 vendedores al día, semanal, la monitorización de indicadores y emitir
mensual y año? reportes oportunos.
¿Cuál y cuanto es la meta de Conociendo las cantidades podrá realizar
3 tiendas para cumplir sus objetivos la monitorización de indicadores y emitir
de venta? reportes oportunos.
¿Cuál y cuantos son las ventas del
vendedor?
reportes oportunos.
¿Cuál y cuantos son las ventas más
vendidas por línea por estilo?
reportes oportunos.
¿Cuál y cuantos son las ventas por
formas de pago?
reportes oportunos.
¿Cuánto es el stock disponible de
cada tienda?
reportes oportunos.
39
¿Cuáles y cuantos son las
transferencias realizadas de los
producto a las tiendas desde la
reportes oportunos.
central?
¿Cuánto es el stock total disponible
de compañía?
reportes oportunos.
¿Cuál y cuanto es el ajuste de
inventario?
reportes oportunos.
Fuente: Elaboración Propia
Tabla 4.2: Lista de indicadores

N° INDICADORES
IND1 Ventas por vendedor
IND2 Metas por vendedor
IND3 Metas por tienda
IND4 Líneas más vendidas por estilo
IND5 Ventas por forma de pago
IND6 Venta mensual
IND7 Stock disponible
IND8 Transferencia a tienda por estilo
IND9 Stock total de compañía
IND10 Ajuste de inventario

Fuente: Elaboración Propia.
40
Tabla 4.3: Lista de perspectivas
N° PERSPECTIVAS
1 Producto
2 Cliente
3 Empleado
4 Tienda
5 Tipo pago
6 Tiempo
7 Proveedor
PRODUCTO VENTAS POR

VENDEDOR
METAS POR
CLIENTE VENDER
MENSUAL
METAS POR
EMPLEADO TIENDA
LÍNEAS MÁS
TIENDA VENDIDAS POR
ESTILO
VENTAS
VENTAS POR
TIPO PAGO FORMA DE
PAGO
TIEMPO VENTA
MENSUAL
Figura 4.1. Diagrama del modelo conceptual inicial.
41
STOCK
DISPONIBLE
PROVEDOR TRANSFERENCIA
ALMACEN A TIENDA POR
ESTILO
STOCK TOTAL DE
COMPAÑÍA
AJUSTE DE
INVENTARIO
Figura 4.2. Diagrama del modelo conceptual inicial.
4.1.2 FASE DEL ANÁLISIS PROCESAMIENTO DE TRANSACCIONES EN

LÍNEA (OLTP)
Aplicamos la técnica para la fase de análisis de los procesamientos de
transacciones en línea (OLTP), presentada en la tabla Nro. 3.3 según la teoría del capítulo
II y la sección 2.2.5, en donde se obtendrá los indicadores sumariados, agregar llaves y
atributos, prueba de existencia de datos y diagrama de modelo conceptual ampliado.
Tabla 4.4. Lista de indicadores cuantificables

FUNCIÓN DE
N° INDICADORES HECHOS
AGREGACION
Venta Por Vendedor = Suma
IND 1 Ventas por vendedor total Cantidad Vendida por SUM
Vendedor
Metas Por Vendedor = Meta -
IND 2 Metas por vendedor
Cantidad Vendida SUM
(Meta día - Cantidad) * (Precio
IND 3 Metas por tienda
de Venta) SUM
42
Línea más vendida = Total
Líneas más vendidas por
IND 4 cantidad vendida - cantidad SUM
estilo
vendida por Estilo.
Venta Por Forma de Pago =
IND 5 Ventas por forma de pago Cantidad Vendida * Tipo de SUM
Pago.
Venta Mensual= desde fecha
IND 6 Venta mensual inicio y fecha fin * Total SUM
cantidad vendida
Stock Disponible = cantidad
recibida - (Cantidad
IND 7 Stock disponible SUM
Despachada - Cantidad
Vendida)
Transferencia = Stock
Transferencia a tienda por
IND 8 disponible - Cantidad SUM
estilo
Requerida.
Stock Total = Cantidad
disponible + cantidad recibida
IND 9 Stock total de compañía SUM
- (Cantidad salida - cantidad
Vendida)
Ajuste de Inventario
Entrada=stock disponible +
IND cantidad ajuste.
Ajuste de inventario SUM
10 Ajuste de Inventario
Salida=stock disponible -
cantidad ajuste.
43
Figura 4.2. Prueba de existencia de datos, correspondencia ventas.
44
Figura 4.3. Prueba de existencia de datos, correspondencia almacén.
45
Las relaciones encontradas con la prueba de existencia de datos que se muestra en la
Figura N° 4.3 se detallan a continuación en la tabla 4.5
Tabla 4.5. Relaciones de la Prueba de Existencia
N° RELACIONES
1 La tabla “PRODUCT” se relaciona con la perspectiva “Producto”.
2 La tabla “CUSTOMER” se relaciona con la perspectiva “Cliente”.
3 La tabla “EMPLOYEE” se relaciona con la perspectiva “Empleado”.
4 La tabla “STORE” se relaciona con la perspectiva “Tienda”.
La tabla “RECEIPT_TENDER” se relaciona con la perspectiva

5
“Tipo_pago”.
6 La tabla “VENDOR” se relaciona con la perspectiva “Proveedor”.
NIVEL DE GRANULARIDAD
En las tablas 4.6 a 4.16 se describe el nivel de granularidad de cada perspectiva para la
fase de Análisis OLTP.
Tabla 4.6. Nivel de Granularidad de la Perspectiva Producto

PRODUCT
NOMBRES DESCRIPCION
1 Código único de estilo referenciado a maestro de
StyleCode producto
2 SKU Código único de producto
3
Sizeld Código de único de talla
4
SizeCode Código de talla
5
ColorCode Código de color
6
Season Temporada
46
7
StatusCode Estado de producto
8
ALU Código barra exterior de producto
9
UPC Código barra de producto
10
Nonlnventory Producto no inventariado
11
LastCost Ultimo costo
12
AvgCost Costo promedio
13
WebProduct Producto web
14
CreationDate Fecha de creación
15
ChangeDate Fecha de última actualización
16
CreatedBy Usuario quien creo producto
17
ModifiedBy Usuario quien modifico
18
RetailPrice Precio de producto
19
SuggestedPrice Precio sugerido
20
FirstPrice Primer precio
21
NonDiscountable Producto no descontable
22
AskForPrice Precio de tienda
23
AskForClerk Vendedor asignado
24
ProductReference Producto referencia
25
ProductReferenceNo Código de referencia
26
FirstMarkDownDate Primera fecha de bajada de precio
27
LastMarkDownDate Ultimo fecha de bajada de precio
28
FormerRetailPrice Precio anterior
29
FormerCost Costo anterior
47
30
AllowDecimalQty Cantidad decimal
31
DiscontinueDate Fecha de discontinuidad
32
DeletedDate Fecha de eliminado
33
FClastCost Costo en dólar
34
FCRetailPrice Precio en dólar
35
TaxCode Código de tipo de cambio
36
LastSoldDate Fecha ultima de venta
37
LastOrderDate Fecha ultima orden de compra
38
FirstReceiveDate Primera fecha recibo de factura
39
LastReceiveDate Ultima fecha recibo de factura
40
IsMarkDown Indicado de bajada aplicada
41
MkdwReasonCode Motivo de bajada
42
Info1 Información adicional
43
SpecialOrder Compra especial
44
CartonCode Código de caja
45
PollStatusCode Estado de replicado a otra tienda
46
PriceEventNo Precio de bajada
47
Consignment Consignación
Tabla 4.7. Nivel de Granularidad de la Perspectiva Cliente

CUSTOMER
N° NOMBRES DESCRIPCION
1 CustomerNo Código único de cliente
2 StoreNo Código único de tienda referenciando a cliente
48
3
StatusCode Estado de cliente
4
CustomerType Tipo de cliente
5
Gender genero
7
FirstName Nombre
8
LastName Apellido paterno
9
MiddelenAME Apellido materno
10
UDF1 Campo 1 adicional definido por Usuario
11
12
13
14
15
17
CompanyName Razón social
18
Picture Imagen
19
SendEmail Estado envió por correo
20
Email Correo
21
WebPage Página web
22
LastVisit Ultima visita a tienda
24
LicenseNumber DNI
25
Info1 Información adicional 1
26
27
28
49
29
31
Notes Nota
32
CustReference Código referencia
33
DiscPercent Porcentaje de descuento
34
PriceLevelld Precio especial
35
ReasonCode Motivo
36
MemberClubld Código especial
37
Phone1 Teléfono 1
38
Phone2 Teléfono 2
39
EnableforRewards Estado de código puntos
40
CreationDate Fecha de creación
41
CretedBy Usuario quien creo
45
Blocked Bloqueo
50
ChangeDate Fecha de modificación
52
ModifiedBy Usuario quien modifico
55
PromoGroupld Grupo de promoción asignado
57
PollStatus Estado de replicación a otras tiendas
Tabla 4.8. Nivel de Granularidad de la Perspectiva Empleado
EMPLOYEE
1 EmployeeCode Es el código único de registro empleado

2 FirstName Nombre de empleado
3 LastName Primer nombre de empleado
50
4 MaidenName Segundo nombre de empleado
5 Languageld Código de idioma
6 Password Contraseña de empleado
7 Picture Foto de empleado
8 SSN Nro. De documento
9 FullName Nombre completo de empleado
10 Phone1 Nro. Primer teléfono
11 Phone2 Nro. Segundo teléfono
12 Address1 Primer dirección de empleado
13 Address2 Segundo dirección de empleado
14 City Ciudad
15 State País
16 ZipCode Código de abigeo
19 Departmentld Código de departamento que pertenece el empleado
20 Email Correo de empleado
21 StatusCode Estado de empleado
22 Punchld Código de ingreso
23 Deleted Registro que indica esta eliminado el empleado
24 Notes registro de comentario de empleado
25 Info1 RUC de empleado
26 CommissionPercent Registro de comisión
27 PIN Código de ingreso a sistema pos.net
28 MaxDiscountPercent Dato de Máximo descuento que puede aplicar empleado
29 CustomerNoReference Numero de referencia como cliente
30 HomeStoreNo Nro. Tienda asignada
31 CreatedBy Dato de usuario quien creo empleado
32 CreationDate Dato de fecha de creación
33 ModifiedBy Dato quien lo módico empleado
34 ChangeDate Dato de fecha de cambio
35 ChangePassword Cambio de password
36 PasswordExpDate Fecha de expiración de password
37 PasswordDate Fecha de cambio de password
38 PollStatus Estado que indica la replicación a otras bd
51
39 POApprover1 Primer Aprobador de orden de compra
40 POApprover2 Segundo Aprobador de orden de compra
41 POApprover3 Tercero Aprobador de orden de compra
Tabla 4.9. Nivel de Granularidad de la Perspectiva Tienda

STORE
NOMBRES DESCRIPCION
1 StoreNo Nro único de tienda
2 RegionCode Código de región
3
PrinceLevelld Código de nivel de precio asignado a tienda
4
StoreCode Código de tienda
5
StoreName Nombre tienda
6
CountryId Código de moneda
7
Adress1 Dirección 1
8
9
10
City Ciudad
11
State Departamento
12
ZipCode Código de país
13
Phone1 Teléfono 1
14
Phone2 Teléfono 2
15
Directions Nombre legal para Ticket
16
OpenDate Fecha de apertura
17
CloseDate Fecha de cierre
18
Warehouse almacén
52
19
StoreType Tipo de tienda
20
ActiveStatus Estado de tienda
21
22
23
24
25
26
27
28
29
30
31
RuleNo Información rol de tienda
32
CurrencyId Código de tipo moneda
33
GroupId Código de grupo
34
VIrtual Nombre virtual
35
Manager Administrador
36 MaxPercentAllowedRetu
rn Campo máximo descuento de tienda
37
BlockedCustomerType Bloqueo de cliente para tienda
38 UseReceipFlag1ForRecei
ptSequence Tipo de documento utilizar
39
StoreOrder Tienda para pedido
40
Outlet Tipo de tienda Oulet
53
41
EOMExclude Excluir de cierre de periodo
42
StoreEmail Correo de tienda
43
TimeFormat Formato de tienda
44
DummyCustomer Cliente por defecto
45
StoreExternalId Código referencial de tienda
46
CleanHoldsAtZOut Borrar ventas retenidas
47
TradeName Razón social de tienda
48
WebSiteUrl Visitas de web
49
WebServicePollURL url de web
50
CheckZOutBeforeTrx Una sola cierre de caja por día
51
StoreVendors Vendedor de tienda
52
CheckOutDate Fecha de apertura
53
StoreLogo Imagen de tienda
54
CreationDate Fecha de creación de tienda
55
ChangeDate Fecha de actualización
56
ModifiedBy Usuario quien módico ultimo
57
ImagesURL url de imagen de tienda
58
PollStatusCode Estado para pasar a otra tienda
59
DBName Nombre de base de datos que está conectado tienda
54
Tabla 4.10. Nivel de Granularidad de la Perspectiva Tipo_Pago
RECEIPT TENDER
1 StoreNo Código de tienda

2 Receiptld Condigo único de registro de venta
3 Lineld Condigo de líneas
4 Currencyld Código de tipo de moneda
5 Tenderld Código de tipo pago
6 TakeAmount Monto cobrado de transacción
7 GiveAmount Monto de vuelto
9 CardName Nombre de tarjeta
10 CardNumber Número de tarjeta
11 CardExpDate Fecha de expiración de tarjeta
12 CardAuthorization Código de autorización
13 EFT Indica que está habilitado pinpad
14 Notes Información de transacción de venta con tarjeta
15 Quotas Numero de cuotas
16 DeviceCode Nro de cuotas divididas
Tabla 4.11. Nivel de Granularidad de la Perspectiva Proveedor
VENDOR
1 VendorCode Código unió vendedor

2 VendorName Nombre de vendedor
3 Address1 Dirección 1
4 Address2 Dirección 1
5 City1 Ciudad 1
6 City2 Ciudad 2
7 State1 Departamento 1
8 State2 Departamento 2
55
9 ZipCode1 Código de país 1
10 ZipCode2 Código de país 2
11 CountryId1 Código de ciudad 1
12 CountryId2 Código de ciudad 2
13 Phone1 Teléfono 1
14 Phone2 Teléfono 2
19 WebPage1 Página web 1
20 WebPage2 Página web 2
22 Info1 Información adicional 1
23 Info2 Información adicional 2
24 Manufacture Es proveedor y también como marca
25 Notes comentario
26 PayToName Tipo de pago
27 PayToCountryId1 Pago desde país 1
28 PayToCountryId2 Pago desde país 2
29 PayToAddress1 Dirección de pago 1
30 PayToAddress2 Dirección de pago 1
31 PayToCity Ciudad donde pago
32 PayToState Departamento donde pago
33 PayToZipCode Pago de código postal
34 PayToPhone1 Datos de teléfono 1
35 PayToPhone2 Datos de teléfono 2
47 Deleted Estado de eliminado
50 VendorLogo Logo de vendedor
51 PollStatusCode Estado de replicación a otras tiendas
52 CreationDate Fecha de creación
53 CreatedBy Usuario quien creo
54 ChangueDate Fecha de modificación
55 ModifiedBy Usuario quien modifico
56
EMPLEADO TIPO PAGO TIENDA CLIENTE Ventas por vendedor
EmployeeCode StoreNo StoreNo CustomerNo
FirstName ReceiptId RegionCode StoreNo
LastName TenderId StoreCode StatusCode
FullName LineId StoreName CustomerType
CurrencyId Metas por vendedor
Gender
FirstNme
LastName
PRODUCTO MiddeleName Líneas más vendidas
StyleCode por estilo
SKU
Sizeld
SizeCode
ColorCode Ventas por forma de
Season pago
StatusCode
ALU
UPC
LastCost
AvgCost Venta mensual
CreationDate
RetailPrice
SuggestedPrice
FirstPrice VENTAS Stock disponible
NonDiscountable
AskForPrice
TIEMPO Transferencia a
tiempo_skey ALMACÉN tienda por estilo
Fecha
Anyo
nmes
Stock total de
PROVEEDOR
compañía
VendorCode
VendorName
Address 1
City1
CountryId1
Figura 4.4. Diagrama de modelo conceptual ampliado
57
4.1.3 FASE DE MODELO LÓGICO DEL DATAMART
Figura 4.5. Diagrama del modelo lógico.
58
TABLAS DE DIMENSIONES
Para las tablas de dimensiones se crea la base de datos “DataMarVenta”, donde se
involucra las tablas de la base de datos “TFL”, las cuales son todas aquellas que tienen
información de las ventas e información de almacén, con ellos se procederá a realizar el
datamart.
Así mismo, se realizó la carga inicial anticipado, para su buen manejo en las tablas
dimensión, con sus atributos que nos proporcionaran información sobre las ventas y metas
del producto.
PERSPECTIVA PRODUCTO:
La nueva tabla de dimensión tendrá el nombre DIMENSIÓN PRODUCTO.
Figura 4.6. Diagrama de la tabla dimensión Producto.
59
PERSPECTIVA CLIENTE:
La nueva tabla de dimensión tendrá el nombre DIMENSIÓN CLIENTE
Figura 4.7. Diagrama de la tabla dimensión Cliente.
PERSPECTIVA EMPLEADO:
La nueva tabla de dimensión tendrá el nombre DIMENSIÓN EMPLEADO
Figura 4.8. Diagrama de la tabla dimensión Empleado
60
PERSPECTIVA TIENDA:
La nueva tabla de dimensión tendrá el nombre DIMENSIÓN TIENDA.
Figura 4.9. Diagrama de la tabla dimensión Tienda
PERSPECTIVA TIPO PAGO

La nueva tabla de dimensión tendrá el nombre DIMENSIÓN FORMA DE PAGO.
Figura 4.10 Diagrama de la tabla dimensión Tipo Pago.
61
PERSPECTIVA TIEMPO:
La nueva tabla de dimensión tendrá el nombre DIMENSIÓN TIEMPO.
Figura 4.11. Diagrama de la tabla dimensión Tiempo.
62
PERSPECTIVA PROVEEDOR:
La nueva tabla de dimensión tendrá el nombre DIMENSIÓN PROVEEDOR.
Figura 4.12. Diagrama de la tabla dimensión Tiempo.
TABLAS DE HECHOS
En las siguientes figuras identificaremos las tablas de hechos, los cuales representaran la
información analizada, definiremos las tablas de hecho con los indicadores ya definidos
en el modelo conceptual.
63
Figura N° 4.1. Diagrama de la tabla de hechos. “CONSULTA_DESCUENTO”
Figura N° 4.2. Diagrama de la tabla de hechos. “VENTA”
Total por monto
por ventas
SUM
Total de cantidad
por ventas
SUM
Figura 4.13. Diagrama de la tabla de hechos. “VENTAS”
64
Total de monto de
compra
SUM
Total de Stock de
compañía
SUM
Figura 4.14. Diagrama de la tabla de hechos. “ALMACEN”
65
Total de ajuste de
inventario
Total de
transferencia a
tienda
SUM
Figura 4.15. Diagrama de la tabla de hechos. “DESPACHO”
66
UNIONES
Figura 4.16. Diagrama del esquema uniones, esquema estrella de la base de datos.
67
4.1.4 FASES DEL PROCESO ETL
CARGA INICIAL
Para la carga de nuestro modelo estrella se procede a llenar cada una de las dimensiones de nuestro modelo, las consultas usadas se
muestran en la figura Nº 4.1
Figura 4.1. Proceso ETL para la carga inicial.
68
Las tareas que lleva a cabo este proceso son:
Inicio: inicia la ejecución de limpieza de una base de datos vacía y posterior llenado.
a) Carga de Dimensión_producto: se ejecuta el proceso de carga de la

dimensión producto, más adelante se detallará el mismo.
b) Carga de Dimensión_cliente: se ejecuta el proceso de carga de la dimensión
cliente, más adelante se detallará el mismo.
c) Carga de Dimensión_empleado: se ejecuta el proceso de carga de la
dimensión empleado, más adelante se detallará el mismo.
d) Carga de Dimensión_ tienda: se ejecuta el proceso de carga de la dimensión
tienda, más adelante se detallará el mismo
e) Carga de Dimensión_tipo de pago: se ejecuta el proceso de carga de la
dimensión tipo de pago, más adelante se detallará el mismo.
f) Carga de Dimensión_proveedor: se ejecuta el proceso de carga de la
dimensión proveedor, más adelante se detallará el mismo.
g) Carga de Dimensión_tiempo: se ejecuta el proceso de carga de la dimensión
tiempo, más adelante se detallará el mismo.
h) Carga de Tabla de Hechos Ventas: se ejecuta el proceso de carga de la tabla
de hechos ventas, más adelante se detallará el mismo.
i) Carga de Tabla de Hechos Almacén: se ejecuta el proceso de carga de la
tabla de hechos almacén, más adelante se detallará el mismo.
j) Carga de Tabla de Hechos Despacho: se ejecuta el proceso de carga de la
tabla de hechos almacén, más adelante se detallará el mismo.
A continuación, se especificarán las tareas llevadas a cabo para cargar las dimensiones y
hechos para el proceso de carga se utiliza la herramienta de Integration Services
Connections Project de SQL server Business Intelligence Development Studio.
PROCESO ETL
Mediante las figuras de tal a tal, mostramos el codigo para poder migrar la información
existente de las tablas de la base de datos de la Empresa Topi Top a las dimensiones
creadas para generar los cubos.
69
Para lo cual se creo la Base de Datos datamart TLF, desde donde se obtendra la
informacion necesaria de las ventas y almacen para el datamart.
delete from HVenta

delete from dimCliente
delete from dimEmpleado
delete from dimProducto
delete from dimTiempo
delete from dimTienda
delete From dimFormaPago
Figura 4.2. Proceso ETL para validar la limpieza de la BD DataMarVenta
Tabla N°
select distinct 4.38: Proceso
(C.FirstName ETL para la tabla
+C.LastName)as DIMENSIONPERSONAcase
Nombre,CT.CountryName,
when len(rtrim(ltrim(isnull(CA.City,''))))= 0 then 'Lima' else CA.City END City
from TFL.dbo.CUSTOMER (nolock) C
inner join Tfl.dbo.CUSTOMER_ADDRESS (nolock) CA on
Ca.CustomerNo=C.CustomerNo
inner join TFL.dbo.COUNTRY (nolock) CT on Ct.CountryId=CA.CountryId
where C.StatusCode<>'C'
Figura 4.3. Proceso ETL para la tabla dimension Cliente.
select distinct E.EmployeeCode, E.FullName

from TFl.dbo.EMPLOYEE(nolock) E
US.EmployeeCode=E.EmployeeCode
where E.Deleted<>'1' and E.FullName<>''
Figura N° 4.4: Proceso ETL para la tabla dimension Empleado
Figura 4.4. Proceso ETL para la tabla dimension Cliente.
select distinct ps.StyleName,d.DeptName from tfl.dbo.PRODUCT_STYLE (nolock)

PS
inner join tfl.dbo.DEPARTMENT (nolock) D on D.DeptCode=Ps.DeptCode
Figura 4.5. Proceso ETL para la tabla dimension Producto.
70
select distinct year(Salesdate)*10000 +MONTH(Salesdate)*100
+day(Salesdate)as
Tabla N° tiemposky, FORMAT(Salesdate,
4.18: Proceso 'yyyy-MM-dd')
ETL para la tabla dimension as Fecha,
Tiempo
year(Salesdate) as anyo,
datename(mm,Salesdate)as nmes,ETL
Tabla N° 4.18: Proceso day(Salesdate)
para la tablaasdimension
ndia, Producto
DATENAME(dw,Salesdate)as ndesema,
iif(datepart(qq,Salesdate)=1, 'Trimestre 1',
iif(datepart(qq,Salesdate)=4, 'Trimestre 4',''))))as trimestre,
iif((month(Salesdate)-1)/6+1=1,'Semestre 1', 'Semestre 2') as semestre
from TFL.dbo.RECEIPT (nolock) S where s.StoreNo=62
Figura 4.6. Proceso ETL para la tabla dimension Tiempo.
select distinct
--S.StoreName,R.RegionName,S.City,
s.storeno, s.storename,SD.GoalInfo1,FORMAT(sd.GoalDate, 'yyyy-MM-dd') fechaM
from TFl.dbo.store (nolock) S
inner join TFL.dbo.STORE_DAILY_GOAL (nolock) SD on SD.StoreNo=S.StoreNo
where s.StoreNo=62
Figura 4.7. Proceso ETL para la tabla dimension Tienda.
select TenderId, TenderName From tfl..TENDER
Figura 4.8. Proceso ETL para la tabla dimension Forma de Pago.
71
select distinct
dp.producto_skey,dc.cliente_skey,
de.Empleado_skey,
dt.Tienda_skey,
DTM.tiempo_skey,
sum(rl.RetailPriceWTax) Precio
,sum(RL.Qty) cantidad
from TFL.dbo.RECEIPT_Line as Rl with(index(index_storeNo))
inner join TFL.dbo.RECEIPT as R with(index(index_storeNo)) on
RL.ReceiptId=R.ReceiptId
inner join TFL.dbo.CUSTOMER (nolock)as C on C.CustomerNo=R.CustomerNo
inner join TFL.dbo.PRODUCT (nolock)as P on P.SKU=RL.SKU
inner join TFL.dbo.PRODUCT_STYLE (nolock) PS on Ps.StyleCode=P.StyleCode
inner join TFL.dbo.STORE (nolock)as S on S.StoreNo=r.StoreNo
inner join TFL.dbo.EMPLOYEE E on e.EmployeeCode=Rl.Clerk
inner join DataMarVenta.dbo.dimCliente (nolock) DC on DC.NombreCliente
COLLATE DATABASE_DEFAULT=C.FirstName+''+C.LastName
inner join DataMarVenta.dbo.dimProducto (nolock) DP on DP.StyleName
COLLATE DATABASE_DEFAULT=ps.StyleName
inner join DataMarVenta.dbo.dimEmpleado (nolock) DE on DE.EmployeeCode
COLLATE DATABASE_DEFAULT=E.EmployeeCode
inner join DataMarVenta.dbo.dimTienda (nolock) DT on Dt.StoreNo= s.StoreNo
inner join DataMarVenta.dbo.dimtiempo(nolock) DTM on DTM.fecha
=format(Rl.SalesDate,'yyyy-MM-dd')
where Rl.StatusCode<>'C' and Rl.salescode not in('O','I')
and Rl.StoreNo=62 and dt.fechaMeta=format(R.SalesDate,'yyyy-MM-dd')
group by dp.producto_skey,dc.cliente_skey,
de.Empleado_skey,
Figura 4.9. Proceso ETL para la tabla consulta Ventas.
72
select
distinct
Producto_skey ,
Proveedor_skey ,
tiempo_skey ,
Sum(Vl.Qty*Vl.ExtPriceWTax)TotalCompra,
Sum(Vl.Qty)StockComp
from TFL.dbo.VOUCHER_LINE as VL with(index(index_storeNoVoucher))
inner join TFL.dbo.VOUCHER as V with(index(index_storeNoVoucherc)) on
VL.VoucherId=V.VoucherId
inner join TFL.dbo.PRODUCT (nolock)as P on P.SKU=VL.SKU
inner join TFL.dbo.PRODUCT_STYLE (nolock) PS on
Ps.StyleCode=P.StyleCode
inner join Tfl.dbo.VENDOR (nolock) Vd on Vd.vendorCode=PS.BrandCode
inner join DataMarVenta.dbo.dimProducto (nolock) DP on DP.StyleName
COLLATE DATABASE_DEFAULT=ps.StyleName
inner join DataMarVenta.dbo.dimProveedor (nolock) Dpr on
DPr.NombreProveedor COLLATE
DATABASE_DEFAULT=VD.VendorName
inner join DataMarVenta.dbo.dimtiempo (nolock) DTM on DTM.fecha
=format(Vl.ReceiveDate,'yyyy-MM-dd')
where VL.StatusCode<>'C' and VL.StoreNo=0
group by
Producto_skey ,
Proveedor_skey ,
tiempo skey
Figura 4.10: Proceso ETL para la tabla consulta almacén.
ACTUALIZACIÓN
Cuando se realice el cargado total del Datamart, se deben establecer sus políticas y
estrategias de actualización o refresco de datos.
Una vez realizado esto, se tendrán que llevar a cabo las siguientes acciones:
73
a) Especificar las tareas de limpieza de datos, calidad de datos, procesos ETL, que
deberán realizarse para actualizar los datos del DW.
b) Especificar de forma general y detallada las acciones que deberá realizar cada
software.
Las políticas que se establecen y las cuales se ha convenido con los usuarios son:
a) La información se refrescará cada mes.
b) Los datos de la dimensión “tiempo” se cargarán de manera incremental
teniendo en cuenta la fecha de la última actualización.
c) Los datos de las dimensiones utilizadas no varían en corto tiempo por eso no
serán cargados, solo se agregarán si existe algún incremento de algún
empleado.
d) Los datos de la tabla de hechos utilizados se cargarán de manera incremental
teniendo en cuenta la fecha de la última actualización que corresponden al
último mes a partir de la fecha
4.1.5 IMPLEMENTACIÓN DE CUBOS MULTIDIMENSIONALES

Se implementara el cubo multidimensional en Visual Studio 2015, es una
plataforma parte del SQL SERVER, que permite trabajar proyectos de inteligencia de
negocios.
CONFIGURAR EL ORIGEN DE DATOS

Realizará la conexión de los datos externos entre la plataforma de análisis de servicios
con una plataforma externa, la interfaz nos pedirá una serie de parámetros que nos pedirá
que mencionemos el servidor, así como el nombre de la de base datos “datamart tlf”, para
implementar el datamart.
74
Figura 4.11. Abriendo el asistente para orígenes de datos.
75
Figura 4.12. Administrador de conección
76
Figura 4.13. Iniciando la selección de la fuente de datos.
CONSTRUCCIÓN DE LA VISTA DE DATOS

Es una sección de la base de datos, que representa al conjunto de datos que forman parte
de la vista del origen de datos, definiremos el origen de datos que queremos conectar,
entonces optaremos el origen de datos que acabamos de realizar en el paso previo figura
N° 4.14 y 4.17.
El asistente solicitara las tablas que van a formar parte de nuestra vista y cómo se observa,
nos muestra todas las tablas de dimensiones, así como las tablas de hechos creadas en la
fase de modelo lógico para la creación del cubo.
77
Figura 4.14. Seleccionando las tablas de dimensiones y de hechos a nuestra vista
78
Figura 4.15. Diagrama del esquema de uniones
79
En la figura N° 4.15 se observa la primera vista creada, donde se encuentra las diferentes
tablas de dimensiones y de hechos, que forman parte de nuestra vista, así como las
diversas relaciones, entre las diferentes tablas de dimensiones y las tablas de hechos bajo
el modelo estrella compartida con cinco tablas de hechos.
DEFINICION DE LOS ATRIBUTOS DE LAS DIMENSIONES PARA EL CUBO

Se muestran tres secciones, la primera es la sección donde se encuantran los atributos que
forman parte de las dimesiones, la segunda seccion es la de jerarquias y la tercera es
donde estan las tablas fuentes la cual esta contenida con la base de datos externa, de donde
se extrae los atributos dela base de datos de las tablas de dimension.
Figura 4.16. Asistente para dimensiones
80
Figura 4.17. Definición de los atributos de la dimensión Empleado.
81
Figura 4.18. Definición de los atributos de la dimensión Cliente.
82
Figura 4.19. Definición de los atributos de la dimensión Producto.
83
Figura 4.20. Definición de los atributos de la dimensión Tiempo.
84
Figura 4.21. Definición de los atributos de la dimensión Tienda.
85
Figura 4.22. Definición de los atributos de la dimensión Forma de pago
86
Figura 4.23. Definición de los atributos de la dimensión Proveedor
87
Se realizará el paso de la figura N° 4.31 y 4.38, con todas las tablas de dimensión, para
poder realizar los cubos.
A. CONSTRUCCIÓN DEL CUBO MULTIDIMENSIONAL
Figura 4.24. Cargando las tablas de hechos consulta Ventas, consulta monto total,
consulta cantidad vendida, consulta forma de pago.
Figura 4.25. Cargando las dimensiones al cubo.
88
En la figura N° 4.26 se muestra los atributos de las diferentes dimensiones, entonces se
define las tablas que formaran parte del cubo.
Al cubo se cargaran todas las dimensiones observadas las cuales están seleccionadas.
Figura 4.26. Completando la carga al cubo.
89
La Figura N° 4.27 se muestra la configuración final del cubo, el contenido del cubo, las
dimensiones y las tablas de hechos.
Figura 4.27. Configuracion final de cubo Multidimensional.
90
DESARROLLO DE REPORTES
a. Reporte de ventas por vendedor
Figura 4.28. Ventas por Vendedor 2017.
b. Reporte de metas por vendedor
Figura 4.29. Metas por Vendedor 2017.
91
c. Reporte de líneas más vendidas por estilo
Figura 4.30. Líneas más vendidas por estilo 2017.
92
d. Reporte de metas por tienda
Figura 4.31. Metas por tienda.
93
Figura 4.32. Metas por tienda del mes de Enero.
Figura 4.33. Metas por tienda del mes de Febrero.
94
Figura 4.34. Metas por tienda del mes de Marzo.
Figura 4.35. Metas por tienda del mes de Abril.
95
Figura 4.36. Metas por tienda del mes de Mayo.
Figura 4.37. Metas por tienda del mes de Junio.
96
Figura 4.38. Metas por tienda del mes de Julio.
Figura 4.39. Metas por tienda del mes de Agosto.
97
Figura 4.40. Metas por tienda del mes de Setiembre.
Figura 4.41. Metas por tienda del mes de Octubre.
98
Figura 4.42. Metas por tienda del mes de Noviembre.
Figura 4.43. Metas por tienda del mes de Diciembre.
99
e. Reporte de ventas por forma de pago
Figura 4.44. Ventas por forma de pago.
100
f. Reporte de venta mensual
Figura 4.45. Venta mensual.
101
g. Reporte de transferencia a tienda por estilo
Figura 4.46. Transferencia a tienda por estilo.
102
h. Reporte de stock total de compañía
Figura 4.47. Stock total de compañía.
103
CAPÍTULO V
CONCLUSIONES Y RECOMENDACIONES
5.1. CONCLUSIONES
a) De acuerdo al marco teórico del capítulo II, sección 2.2.4, se construye el
método para el DataMart mostrado en el capítulo III, sección 3.5; usando el
método para el DataMart, se ha logrado el resultado que se muestra en el
capítulo IV, en las figura 4.28 al 4.45; que brinda información táctica para el
áreas de ventas, siendo los indicadores; ventas por vendedor, metas por
vendedor, metas por tienda, líneas más vendidas por estilo, ventas por forma
de pago, venta mensual.
b) De acuerdo al marco teórico del capítulo II, sección 2.2.4, se construye el
método para el DataMart mostrado en el capítulo III, sección 3.5; usando el
método para el DataMart se ha logrado el resultado que se muestra en el
capítulo IV, figura Nº 4.46 al 4.47; que brinda información táctica para el
área de almacén, siendo los indicadores; stock disponible, transferencia a
tienda por estilo, stock total de compañía, ajuste de inventario.
5.2 RECOMENDACIONES
a) Se recomienda realizar un estudio para obtener indicadores de las otras áreas
funcionales que no se han considerado en esta investigación; áreas que son:
Logística, finanzas, compras, marketing, impresión.
b) Se debe realizar un estudio a fin de implementar una aplicación web o móvil
que presente los indicadores para las áreas de ventas y almacén en tiempo real.
104
BIBLIOGRAFÍA
1. Álvarez, A. & Álvarez, O. (2014). Presupuesto público comentado. Lima,

Perú: Primera edición. Editorial pacifico.
2. Bernabeu R. D. (2010), Metodología Hefesto. Córdoba, Argentina: Quinta
edición. Editorial Tierra del sur.
3. Cabanillas, K. G. (2011). Análisis diseño e implementación de una solución de
Inteligencia de Negocios para el área de compras y ventas de una empresa
comercializadora de electrodomésticos (tesis de pregrado). Pontificia
Universidad Católica del Perú, lima, Perú.
4. Castillo, j. & Palomino, L. (2012). Implementación de un datamart como una
solución de Inteligencia de Negocios para el área de logística de T-Impulso
(tesis de pregrado). Universidad Nacional Mayor de San Marcos, lima, Perú.
5. Constitución policita del Perú (1993). Artículo 24. Recuperado de
http://pdba.georgetown.edu/Parties/Peru/Leyes/constitucion.pdf.
6. Chiavenato, I (2007). Administración de recursos humanos (5ta edición). Colombia:
McGraw-hill Interamericana. Pag. 286.
7. Decreto Supremo N° 290. (2012). Remuneración integra mensual (RIM),
Diario oficial el peruano, 23 de diciembre del 2012. art 57.
8. Dessler, G. (2001). Administración de Personal. México: Pearson.
9. Effy, O. (2001). Administración de Sistemas de Información. México, México
D.F (Segunda edición). México: Tomson Learning.
10. Espinoza, A. (2010). Desarrollo de un datamart para información táctica del
impuesto predial del servicio de administración tributaria de huamanga
(tesis), Universidad de San Cristóbal de huamanga, Ayacucho, Lima.
11. Francois D. (2004). Planificación Táctica y de Mediano Plazo (Primera
edición). Canadá: CECADI.
12. Heurtel, O. (2009), Php y MySQL Domine el Desarrollo de un sitio Web
Dinámico e Interactivo (Primera edición). Barcelona-España. Editorial ENI.
13. Inmon, W. H. (2002). Building the Data Warehouse. (3ª Ed). Estados unidos:
John Wiley & Sons. Inc.
14. Instituto Nacional de Estadística e Informática de Perú(2005), Manual de
Construcción de un Data Warehouse, Recuperado de
105
http://www.yoquese.com.ar/resources/external/material_toma_de_decisiones/
capitulo4-2.pdf
15. Laudon, k. y Laudon, J. (2008). Sistemas de Información Gerencial (Décima
edición). México, D.F., México: Pearson Educación.
16. Luque, I., Gómez, M., López, N. y Cerruela, G. (2002). Base de Datos.
ORACLE. México: Alfaomega Grupo Editor.
17. Moss, L. y Atre, S. (2003). Business Intelligence Roadmap: The Complete
Project Lifecycle for Decision-Support Applications. Boston: Addison Wesley.
18. Nader, J.(2003). Sistema de Apoyo gerencial Universitario (tesis)
www.itba.edu.ar/capis/epg-tesis-y-tf/nader-tesisdemagister.pdf.
19. Nevado Cabello Victoria, (s.f). Introducción a las Bases de Datos
Relacionales. España, Madrid: Visión Libros.
20. Nima, J. (2009). Soluciones OLAP con Microsoft SQL Server AnalysisServices.
Recuperado de http://www.eumed.net/libros-gratis/2009c/574/index.htm.
21. Osorio, L. (2008). Bases de datos relacional teoría y práctica. Primera edición
España: ITM.
22. Real Academia Española (2016). haber, recuperado de
http://dle.rae.es/?id=Jv4Frsm|Jv5KhSK
23. Rob, Coronel P. (2004), Sistema manejador de bases de datos (Quinta edición).
Madrid –España: Nieto.
24. Sánchez, S. (2014). Estrategias empresariales para la toma de decisiones.
recuperado de http://www.gestiopolis.com/estrategiasempresariales-para-la-
toma-de-decisiones/
25. Sandoya, K. M. (2008). Guía Práctica de Legislación Laboral. Colombia:
Sociedad.
26. Silberschatz Abraham, Korth Henry y Sudarshan S. (2005). Fundamentos de
bases de datos (4ta Ed.). España, Madrid: mcgraw-hill
27. Tierauf, R. (1994). Sistema de Información Gerencial para Control y
Planificación. México, D.F., México: Limusa S.A.
28. Toainga M. P. (2014). construcción de un datamart orientado a las ventas para
la toma de decisiones en la empresa amevet cia. ltda. universidad técnica de
Ambato de ecuador (tesis). Recuperado de
http://repositorio.uta.edu.ec/bitstream/123456789/8104/1/Tesis_t922si.pdf
106
29. Torres, L. (2007). Business Intelligence. Recuperado de
http://www.gravitar.biz/index.php/bi/bi-terminologia-1.
30. Ullman, J.D. y Widom, J. (1999). Introducción a los Sistemas de Bases de
Datos. Prentice Hall.
31. Ramos, S (2011) Microsoft Busines Intelligence (4ta Ed.).España Madrid:
Alicante.
32. Güratan, Isil. (2005). Desarrollo de un “the design and development of a
datawarehouse using sales database andrequirements of a retail group. (3ª
Ed). Estados unidos: Jack Ellacuriaga & Miller. Inc.
33. Vadillo, S. (2005). Administración de Remuneraciones. México: Editorial
Limusa.
34. Valdiviezo, M. J., Herrera, I. Z. S. y Jáuregui, G. D. (2007). Análisis y Diseño
de una Herramienta de Desarrollo de Soluciones para Inteligencia de
Negocios – Análisis dimensional (tesis). Pontificia Universidad Católica del
Perú. Lima. Perú.
35. Vitt, E. (2003). Business Intelligence Toma De Decisiones. México: primera
edición, Mc Graw-Hill.
36. Wikipedia la enciclopedia (2016), el haber, recuperado de
https://es.wikipedia.org/wiki/Salario
37. Yauli, G. (2008). Implementación de Datawarehouse de la Caja Rural de
ahorro y crédito Los Libertadores (tesis). Universidad Nacional San Cristóbal
de Huamanga, Ayacucho, Perú.
38. Zambrano, Jaime (2011). Análisis, diseño e implementación de un datamart
para el área de mantenimiento y logística de una empresa de transporte
público de pasajeros (tesis). Pontificia Universidad Católica del Perú, lima,
Perú.
107

Tesis Sis83 Men

Cargado por

Copyright:

Formatos disponibles

Tesis Sis83 Men

Cargado por

Información del documento

Descripción original:

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Sis83 Men

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL DE SAN CRISTÓBAL DE HUAMANGA

FACULTAD DE INGENIERÍA DE MINAS, GEOLOGÍA Y CIVIL

ESCUELA PROFESIONAL DE INGENIERÍA DE SISTEMAS

“DATAMART PARA INFORMACIÓN TÁCTICA DE VENTAS Y

Tesis Presentada por : Bach. Katy Lizbeth Meneses Mendoza

A mi madre quien me apoyo para poder llegar a

A mi hermana Tania quien me apoyo

La presente investigación desarrolla un Datamart para calcular los indicadores de ventas

La implementación del DataMart cumplió con los objetivos específicos planteados en la

De acuerdo a Francois (2004), la información táctica es aquella que muestra un aspecto

Mediante el apoyo en la toma de decisiones “Se busca ir más allá en la presentación de la

Mi motivación para la implementación del DataMart, se debe a que en la actualidad la

El objetivo es calcular indicadores de información táctica para el área de ventas con la

1.1 DIAGNÓSTICO Y ENUNCIADO DEL PROBLEMA

El área de ventas es la encargada de realizar las operaciones de ventas de los productos a

La empresa se encuentra entonces en la necesidad de equilibrar su producción, para lo

Tabla 1.1. Inventario y Venta

1.2 FORMULACIÓN DEL PROBLEMA DE INVESTIGACIÓN

1.4 JUSTIFICACIÓN Y DELIMITACIÓN DE LA INVESTIGACIÓN

En la importancia social, se apoyará al servicio de la empresa Topitop S.A y como

En el aspecto económico al contar con Datamart se podrá acceder a una información

2.1 ANTECEDENTES DE LA INVESTIGACIÓN

Según Moreno (2013), en su tesis “análisis, diseño e implementación de datamarts para

Según la investigación de Mauricio Mendoza Paitán en su tesis “Análisis, Diseño e

Según Fernández (2009), en su tesis “Análisis, diseño e implementación de un Datamart

Según Toainga (2014), en su tesis “Construcción de un Datamart orientado a las a ventas

2.2 MARCO TEÓRICO

“Abarca periodos de tiempo relativamente cortos (no mayores a 12 meses); se emplea en

La gerencia intermedia necesita información operacional que le ayude con la actividad de

El diccionario de Marketing de Cultural S.A., define a la venta como “un contrato en el

2.2.2.2 VENTAS POR VENDEDOR

Venta Por Vendedor = Suma total Cantidad Vendida * por Vendedor

2.2.2.3 METAS POR VENDEDOR

Metas Por Vendedor =Meta–Cantidad Vendida

El objetivo principal de la mayoría de las compañías dedicadas a las tiendas de cualquier

Metas Por tienda =Meta día–Cantidad *Precio de Venta

2.2.2.6 LINEAS MAS VENDIDAS POR ESTILO

2.2.2.7 VENTAS POR FORMA DE PAGO

Venta Por Forma de Pago =Cantidad Vendida* Tipo de Pago

2.2.2.8 VENTA MENSUAL

Según Kendall (2011) Todo manejo y almacenamiento de materiales y productos es algo

2.2.3.1 STOCK DISPONIBLE

Stock Disponible = cantidad recibida –Cantidad despachada –Cantidad

2.2.3.2 TRANSFERENCIA A TIENDA POR ESTILO

Transferencia =Stock disponible - Cantidad Requerida

2.2.3.3 STOCK TOTAL DE COMPAÑÍA

Stock Total = Cantidad disponible + cantidad recibida - Cantidad salida – cantidad

2.2.3.4 AJUSTE DE INVENTARIO

Ajuste de Inventario Entrada= stock disponible + cantidad ajuste

Ajuste de Inventario Salida= stock disponible - cantidad ajuste

Según Mendoza (2011) un Datamart consiste en una colección de datos y un sistema de

Según Santiago (2006) se define como un almacén de datos especializado, orientado a un

Figura 2.2. Datamart independiente

2.2.3.1 VENTAJAS Y DESVENTAJAS

DESVENTAJA. - No permite el manejo de grandes volúmenes de información por lo

2.2.4 METODOLOGIA HEFESTO

2.2.4.1 ANALISIS DE REQUERIMIENTO

Figura N° 2.3. Modelo conceptual (Bernabeu, 2010)

2.2.4.2 ANÁLISIS DE LOS PROCEDIMIENTOS DE TRANSACCIONES EN