Tuaexcomsis022 2016 PDF

UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES
UNIANDES – SANTO DOMINGO
FACULTAD DE SISTEMAS MERCANTILES.

CARRERA DE SISTEMAS
PROYECTO EXAMEN COMPLEXIVO PREVIO A LA OBTENCIÓN DEL TÍTULO

DE INGENIERO EN SISTEMAS E INFORMÁTICA
TEMA:
IMPLEMENTACIÓN DE UN DATAWAREHOUSE PARA LA TOMA DE
DECISIONES EN EL ÁREA LOGÍSTICA DE LA COMPAÑÍA PRONACA.
AUTOR: LCD. JARAMILLO DELGADO FREDDY RENE

ASESOR: ING. MARTINEZ CAMPAÑA CARLOS EDUARDO
AMBATO – ECUADOR
2016
APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN
CERTIFICACIÓN:
Quien suscribe, legalmente CERTIFICA QUE: El presente Trabajo de Titulación realizado

por el señor Freddy Rene Jaramillo Delgado, estudiante de la Carrera de Sistemas, Facultad
de Sistemas Mercantiles, con el tema “IMPLEMENTACIÓN DE UN DATAWAREHOUSE
PARA LA TOMA DE DECISIONES EN EL ÁREA LOGÍSTICA DE LA COMPAÑÍA
PRONACA”, ha sido prolijamente revisado, y cumple con todos los requisitos establecidos
en la normativa pertinente de la Universidad Regional Autónoma de los Andes -
UNIANDES-, por lo que apruebe su presentación.
Ambato, Septiembre de 2016
_______________________________
Ing. Martínez Campaña Carlos Eduardo.
ASESOR
DECLARACIÓN DE AUTENTICIDAD
Yo, Freddy Rene Jaramillo Delgado, estudiante de la Carrera de Sistemas, Facultad de

Sistemas Mercantiles, declaro que todos los resultados obtenidos en el presente trabajo de
investigación, previo a la obtención del título de INGENIERO EN SISTEMAS E
INFORMÁTICA, son absolutamente originales, auténticos y personales; a excepción de las
citas, por lo que son de mi exclusiva responsabilidad.
_______________________________
Lic. Jaramillo Delgado Freddy Rene
CI. 171446660-2
AUTOR
DERECHOS DE AUTOR
Yo, Freddy Rene Jaramillo Delgado, declaro que conozco y acepto la disposición constante
en el literal d) del Art. 85 del Estatuto de la Universidad Regional Autónoma de Los Andes,
que en su parte pertinente textualmente dice: El Patrimonio de la UNIANDES, está
constituido por: La propiedad intelectual sobre las Investigaciones, trabajos científicos o
técnicos, proyectos profesionales y consultaría que se realicen en la Universidad o por cuenta
de ella;
_______________________________
Lic. Jaramillo Delgado Freddy René
CI. 171446660-2
AUTOR
DEDICATORIA
El presente trabajo de investigación dedico a mi esposa Mayra Enriquez quien es mi apoyo

incondicional para el logro de mis objetivos.
A mis dos hijos Jearly y Josué, que son la razón de mi vida el tesoro más grande que Dios
me regaló y el motivo de mí existir.
A mis padres Mariana Delgado y Faustino Jaramillo que se sacrificaron en post de mi

bienestar, guiaron mis pasos con mucho amor, me enseñaron a continuar luchando para
vencer los obstáculos, sin perder la esperanza de conseguir las metas propuestas, a pesar de
los tropiezos y dificultades que se han presentado en el difícil sendero de mi vida.
Freddy Rene Jaramillo.

AGRADECIMIENTO
Primero y antes que nada, gracias a Dios, por estar junto a mí en cada paso, por fortalecer
nuestros corazones e iluminar nuestras mentes y por haber puesto en el camino a aquellas
personas que han sido soporte y compañía durante mis estudios.
A mi esposa Mayra Enriquez por ser mi motivación, apoyo incondicional en cada momento
de mi vida, pilar fundamental para el logro de la culminación de este trabajo.
A la Universidad Regional Autónoma de Los Andes, "Uniandes", por acogerme en sus aulas
y permitir que continúe con una mejor formación profesional.
A mi asesor de Tesis Ing. Carlos Martinez, por la infinita comprensión y colaboración en

guiarme en la realización y fortalecimiento del presente trabajo investigativo.
Freddy Rene Jaramillo.

ÍNDICE GENERAL
APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN.

DECLARACIÓN DE AUTENTICIDAD.
DERECHO DE AUTOR.
DEDICATORIA.
AGRADECIMIENTO.
RESUMEN EJECUTIVO.
ABSTRACT.
INTRODUCCIÓN. ................................................................................................................ 1
Antecedentes de la investigación. .......................................................................................... 1
Planteamiento del problema. ................................................................................................. 2
Formulación del problema. .................................................................................................... 2
Identificación de la línea de investigación. ........................................................................... 2
Justificación del tema. ........................................................................................................... 2
Objetivos................................................................................................................................ 3
Objetivo General.................................................................................................................... 3
Objetivos Específicos. ........................................................................................................... 3
1 CAPITULO I. MARCO TEÓRICO. ............................................................ 4
1.1 Origen y evolución del objeto de investigación. ........................................... 4
1.2 Análisis de distintas posiciones teóricas sobre el objeto de investigación. ... 4
1.3 Valoración crítica de los conceptos principales de las distintas posiciones
teóricas sobre el objeto de investigación. .............................................................................. 5
1.3.1 Business Intelligence. .................................................................................... 5
1.3.1.1 Introducción. .................................................................................................. 5
1.3.1.2 Definiciones. .................................................................................................. 5
1.3.1.3 Objetivo de las herramientas de inteligencia de negocios. ............................ 6
1.3.1.4 Características de la inteligencia de negocios. .............................................. 6
1.3.2 Sistemas de información. ............................................................................... 6
1.3.2.1 Sistemas de soporte a decisiones (DSS). ....................................................... 7
1.3.2.1.1 Función. ......................................................................................................... 7
1.3.2.1.2 Características. ............................................................................................... 7
1.3.3 Datawarehouse............................................................................................... 8
1.3.3.1 Definiciones. .................................................................................................. 8
1.3.3.2 Función. ......................................................................................................... 9
1.3.3.3 Características. ............................................................................................... 9
1.3.3.4 Arquitectura de un datawarehouse. ............................................................. 10
1.3.3.5 Estructura. .................................................................................................... 11
1.3.3.6 Proceso de extracción, transformación y carga ETL. .................................. 12
1.3.3.7 Modelo dimensional de un datawarehouse. ................................................. 14
1.3.3.7.1 Tablas de dimensiones. ................................................................................ 15
1.3.3.7.2 Tablas de hechos. ......................................................................................... 16
1.3.3.7.3 Nivel. ........................................................................................................... 17
1.3.3.7.4 Jerarquías. .................................................................................................... 18
1.3.3.7.5 Granularidad. ............................................................................................... 18
1.3.3.7.6 Relaciones. ................................................................................................... 18
1.3.3.7.7 Claves subrogadas. ...................................................................................... 19
1.3.3.8 Análisis OLAP. ............................................................................................ 19
1.3.4 Desarrollo de un datawarehouse basado en la metodología Ralph Kimball.
21
1.3.4.1 Planeación y administración del proyecto. .................................................. 22
1.3.4.2 Definición de los requerimientos del negocio. ............................................ 24
1.3.4.3 Diseño técnico de la arquitectura................................................................. 24
1.3.4.3.1 Back Room. ................................................................................................. 24
1.3.4.3.2 Front Room. ................................................................................................. 24
1.3.4.4 Selección e instalación del producto. .......................................................... 25
1.3.4.5 Modelamiento dimensional. ........................................................................ 25
1.3.4.5.1 Paso 1 – Seleccionar el Proceso de Negocio. .............................................. 26
1.3.4.5.2 Paso 2 – Declaración de granularidad. ........................................................ 26
1.3.4.5.3 Paso 3 – Identificación de Dimensiones. ..................................................... 26
1.3.4.5.4 Paso 4 – Identificación de Hechos. .............................................................. 26
1.3.4.5.5 Datawarehouse Bus Matrix. ........................................................................ 26
1.3.4.6 Diseño físico. ............................................................................................... 27
1.3.4.7 Diseño y desarrollo del proceso ETL. ......................................................... 27
1.3.4.7.1 Paso 1 – Trazar un plan de alto nivel........................................................... 28
1.3.4.7.2 Paso 2 – Seleccionar la herramienta ETL. ................................................... 28
1.3.4.7.3 Paso 3 – Desarrollar estrategias por defecto. ............................................... 28
1.3.4.7.4 Paso 4 – Profundizar la tabla objetivo. ........................................................ 28
1.3.4.7.5 Paso 5 – Poblar las tablas de dimensiones con los datos históricos. ........... 28
1.3.4.7.6 Paso 6 – Realizar la carga histórica de la tabla de hechos. .......................... 28
1.3.4.7.7 Paso 7 – Procesamiento incremental de la dimensiones.............................. 29
1.3.4.7.8 Paso 8 – Procesamiento incremental de los hechos. .................................... 29
1.3.4.7.9 Paso 9 – Operación y automatización del sistema ETL. ............................. 29
1.3.5 Herramientas para el desarrollo del datawarehouse. ................................... 29
1.3.5.1 Motor de base de datos. ............................................................................... 29
1.3.5.2 Herramienta ETL. ........................................................................................ 30
1.3.5.3 Microsoft Integration Services. ................................................................... 30
1.3.5.4 Microsoft Analysis Services. ....................................................................... 31
1.3.5.5 Herramienta de presentación. ...................................................................... 31
1.4 Conclusiones parciales. ............................................................................... 32
2 CAPITULO II MARCO METODOLÓGICO. ........................................... 33
2.1 Caracterización del sector, rama, empresa, contexto institucional o
problema seleccionado para la investigación. ..................................................................... 33
2.2 Descripción del procedimiento metodológico para el desarrollo de
investigación. 33
2.2.1 Modalidad de la Investigación. .................................................................... 33
2.2.2 Tipos de investigación. ................................................................................ 33
2.2.3 Técnicas ....................................................................................................... 34
2.2.4 Población. .................................................................................................... 35
2.3 Conclusiones parciales. ............................................................................... 44
3 CAPITULO III MARCO PROPOSITIVO. ................................................ 45
3.1 Planeación y administración del proyecto. .................................................. 45
3.1.1 Definición del proyecto. .............................................................................. 45
3.1.2 Alcance y justificación del proyecto. .......................................................... 45
3.2 Definición de los requerimientos del negocio ............................................. 46
3.3 Diseño técnico de la arquitectura................................................................. 48
3.3.1 Back room ................................................................................................... 48
3.3.2 Front room ................................................................................................... 49
3.4 Selección del producto................................................................................. 49
3.5 Identificar las dimensiones y mapear los datos. .......................................... 50
3.5.1 Modelo dimensional .................................................................................... 50
3.5.1.1 Dimensión artículo. ..................................................................................... 51
3.5.1.2 Dimensión cliente. ....................................................................................... 52
3.5.1.3 Dimensión proveedor. ................................................................................. 53
3.5.1.4 Dimensión Tipo Movimiento. ..................................................................... 54
3.5.1.5 Dimensión red de distribución..................................................................... 55
3.5.1.6 Dimensión Compañía. ................................................................................. 56
3.5.1.7 Dimensión Vehículos. ................................................................................. 57
3.5.1.8 Dimensión Tiempo. ..................................................................................... 58
3.5.2 Identificar los hechos ................................................................................... 58
3.5.2.1 Identificar las medidas. ................................................................................ 58
3.5.2.2 Abastecimiento y distribución de producto terminado ............................... 59
3.5.2.3 Abastecimiento de materia prima ................................................................ 62
3.5.2.4 Nivel de servicio OTIF. ............................................................................... 65
3.5.3 Datawarehouse busmatrix............................................................................ 67
3.6 Diseño físico. ............................................................................................... 67
3.6.1 Base de datos origen .................................................................................... 67
3.7 Diseño y desarrollo del proceso ETL. ......................................................... 68
3.7.1 Paso 1: Trazar un plan de alto nivel. ........................................................... 68
3.7.2 Paso 2: Funcionalidad de la herramienta ETL............................................. 68
3.7.3 Paso 3: Desarrollar estrategias por defecto.................................................. 68
3.7.3.1 Proyecto SSIS en Integration Services. ....................................................... 71
3.7.4 Paso 4: Poblar las tablas de dimensión con los datos. ................................. 71
3.7.4.1 Extracción de Datos. .................................................................................... 72
3.7.4.2 Transformación de Datos............................................................................. 72
3.7.4.3 Carga de datos. ............................................................................................ 72
3.7.5 Paso 5: Poblar las tablas de hecho con datos. .............................................. 72
3.8 Implementación de cubo. ............................................................................. 73
3.9 Visualización de datos. ................................................................................ 73
3.9.1 Tablero de control distribución de PT. ........................................................ 74
3.9.2 Tablero de control abastecimiento de materia prima................................... 75
3.9.3 Nivel de servicio OTIF ................................................................................ 75
CONCLUSIONES. .............................................................................................................. 76
RECOMENDACIONES. .................................................................................................... 77
BIBLIOGRAFÍA.
ANEXOS
ÍNDICE DE GRÁFICOS
Figura 1-1: Pirámide Sistemas de Información ..................................................................... 7

Figura 1-2: Arquitectura de un datawarehouse ................................................................... 10
Figura 1-3: Estructura de los datos de un datawarehouse ................................................... 11
Figura 1-4: Proceso ETL ..................................................................................................... 13
Figura 1-5: Esquema Estrella .............................................................................................. 15
Figura 1-6: Esquema copo de nieve .................................................................................... 15
Figura 1-7: Tablas de Dimensiones ..................................................................................... 16
Figura 1-8: Tabla de Hecho ................................................................................................. 17
Figura 1-9: Niveles en la Dimensión ................................................................................... 17
Figura 1-10: Jerarquía en la Dimensión. ............................................................................. 18
Figura 1-11: Relaciones en un Modelo ............................................................................... 18
Figura 1-12: OLAP (On-Line Analytical Processing) ......................................................... 19
Figura 1-13: Cubo OLAP .................................................................................................... 20
Figura 1-14: Operación OLAP - Drill Down ...................................................................... 21
Figura 1-15: Operación OLAP - Roll Up ............................................................................ 21
Figura 1-16: The Kimball Lyfecycle Diagramt ................................................................... 21
Figura 1-17: Datawarehouse Bus Matrix............................................................................. 27
Figura 1-18: Arquitectura Integration Services ................................................................... 31
Figura 1-19: Visualización datos de cubos en hoja de Excel .............................................. 32
Figura 2-1: Ilustración datos tabulados pregunta 1. ............................................................ 36
Figura 3-1: Back Room – Proyecto ..................................................................................... 48
Figura 3-2: Front Room – Proyecto ..................................................................................... 49
Figura 3-3: Diseño físico tabla de hecho abastecimiento y distribución de PT. ................. 61
Figura 3-4: Diseño físico tabla de hecho gestión logística MP ........................................... 64
Figura 3-5: Diagrama tabla temporal Mantanimiento_DW ................................................ 69
Figura 3-6: Estructura diagramas de base de datos temporal. ............................................ 69
Figura 3-7: Diagrama gestiónlog_PT .................................................................................. 70
Figura 3-8: Diagrama GestionLog_MP ............................................................................... 70
Figura 3-9: Diagrama NivelServicio. .................................................................................. 71
Figura 3-10: Esquema paquetes SSIS .................................................................................. 71
Figura 3-11: Carga datos hacia el cubo. .............................................................................. 72
Figura 3-12: Cubo OLAP en Analysis Services .................................................................. 73
Figura 3-13: Menú visualización de datos del cubo OLAP................................................. 74
Figura 3-14: TC – Distribución de producto terminado. ..................................................... 74
Figura 3-15: TC TM abastecidas de MP. ............................................................................ 75
Figura 3-16: TC Nivel de Servicio OTIF. ........................................................................... 75
ÍNDICE DE TABLAS
Tabla 2-1: La entrevista ....................................................................................................... 34

Tabla 2-2: Datos tabulados pregunta1. ................................................................................ 36
Tabla 2-3: Datos tabulados pregunta 2. ............................................................................... 37
Tabla 3-1: Mapeo de datos Dimensión Artículo ................................................................ 51
Tabla 3-2: Mapeo de datos Dimensión Cliente ................................................................... 52
Tabla 3-3: Mapeo de datos Dimensión proveedor............................................................... 53
Tabla 3-4: Mapeo de datos Dimensión Tipomovimiento .................................................... 54
Tabla 3-5: Mapeo de datos Dimensión redtransporte.......................................................... 55
Tabla 3-6: Mapeo de datos Dimensión compañiatrans ....................................................... 56
Tabla 3-7: Mapeo de datos Dimensión vehículo ................................................................. 57
Tabla 3-8: Mapeo de datos Dimensión Tiempo .................................................................. 58
Tabla 3-9: Medidas tabla de hecho gestión logística........................................................... 58
Tabla 3-10 : Medidas tabla de hecho Nivel de Servicio ...................................................... 59
Tabla 3-11: Mapeo de datos tabla de hecho gestionlog_PT ................................................ 60
Tabla 3-12: Mapeo de datos tabla de hecho gestionlog MP. ............................................... 63
Tabla 3-13: Mapeo de datos tabla de hecho nivelservicio................................................... 65
Tabla 3-14: Bus Matrix DW. ............................................................................................... 67
ANEXOS.
ANEXO 1- Modelo de la encuesta dirigido a los colaboradores del departamento de

logística.
ANEXO 2- Manual de implementación de un proyecto SSIS en Integration Services proceso
ETL.
ANEXO 3- Carga de datos ejecutando el proceso ETL.
ANEXO 4- Diagrama de flujo del funcionamiento del ETL por cada dimensión y tablas de
hecho.
ANEXO 5- Diseño e implementación de un cubo.
ANEXO 6- Creando conexión OLAP desde Microsoft Excel a SQL Server de Analysis
Services.
RESUMEN EJECUTIVO
Se ha evidenciado en los últimos años el crecimiento de información en el negocio pecuario

gestionado por el departamento de logística de la compañía PRONACA, lo cual constituye
un valioso recurso, se ha convertido en un problema al momento de manejar la información,
es aquí donde nace la necesidad del departamento logístico al no contar con una herramienta
informática que permita realizar análisis de datos.
El presente proyecto se ejecutó por la importancia de tener una aplicación datawarehouse

para gestionar toda la información que maneja el departamento de logística, con el fin de
superar estas debilidades, para ser más competitivos, eficientes y mejorar la toma de
decisiones.
Para el desarrollo de esta investigación se aplicó el método inductivo que parte de procesos
logísticos en abastecimiento de materias primas y distribución de producto terminado y de
la funcionalidad de cada proceso, el método deductivo que parte del conocimiento básico de
inteligencia de negocios, investigando las diferentes ramas que van dirigidas a la
implementación de este tipo de soluciones. Para el desarrollo de este tipo de proyecto de
datawarehouse se estableció usar la propuesta de Ralph Kimball, porque garantiza
funcionalidad, escalabilidad, permitiendo obtener un producto final de calidad.
El presente estudio está enmarcado en la línea de investigación de “Tecnologías de

información y comunicaciones”
Con la implementación del concepto de datawarehouse dentro del departamento de logística

se está inculcando en las jefaturas y gerencias de la institución, para una administración
eficaz de los directivos encargados del negocio, obteniendo como producto, información útil
del negocio a analizar.
ABSTRACT
It has been demonstrated in the last few years the growth of information in the livestock
business managed by the logistics department of the company PRONACA, which constitutes
a valuable resource, has become a problem at the time to handle the information, it is here
where is born the need of the logistics department by not having a computer tool that permits
to perform data analysis.
This project was implemented by the importance of having an application datawarehouse to

manage all the information that handles the logistics department, with the aim of overcoming
these weaknesses, to be more competitive, efficient and improve decision-making.
For the development of this research was applied the inductive method that parts of the
logistics processes in terms of the supply of raw materials and distribution of finished
product and the functionality of each process, the deductive method that parts of the basic
knowledge of business intelligence, investigating the different branches that are directed to
the implementation of this type of solutions. For the development of this type of project of
datawarehouse was established using the proposal of Ralph Kimball, because it ensures
functionality, scalability, allowing to obtain a high quality final product.
The present study is framed in the research line of "information technologies and
communications"
With the implementation of the concept of datawarehouse within the logistics department is
to inculcate in the headquarters and the managements of the institution for the effective
management of the managers of the business, obtaining as product, useful information of the
business to analyze.
TEMA: IMPLEMENTACIÓN DE UN DATAWAREHOUSE PARA LA TOMA DE
DECISIONES EN EL ÁREA LOGÍSTICA DE LA COMPAÑÍA PRONACA.
INTRODUCCIÓN.
Antecedentes de la investigación.
En la actualidad, la manera cómo se gestiona la información en el mundo es cada vez más
importante y genera ventajas competitivas, es por esta razón que se han venido desarrollando
un conjunto de estrategias y herramientas enfocadas a la administración y creación de
conocimiento mediante el análisis de datos como son el estudio del datawarehouse como
apoyo soporte a la toma de decisiones de manera que pueda responder a las necesidades en
el ámbito gerencial y a las nuevas tecnologías de información y comunicación, de ahí que se
ha investigado la herramienta tecnológica datawarehouse basada en Business Intelligence
(BI).
En la actualidad, el dinámico mundo de los negocios plantea la necesidad de disponer de un

acceso rápido y sencillo a la información para la toma de decisiones, pudiéndose evidenciar el
interés de los sectores empresariales tanto privados como públicos con relación a los beneficios
de los (DSS), los cuales han sido implementados por empresas importantes del mundo en áreas
como finanzas, contabilidad, venta – marketing, manufactura, gestión logística, entre otros.
En el Ecuador el uso de los sistemas de soporte a la toma de decisiones, se encuentra en

pleno desarrollo, de acuerdo a lo que se ha podido evidenciar en la página oficial del (BCE,
2015) quienes cuentan con un sistema de información para la toma de decisiones financieras
y económicas, de igual forma en el sitio web del (INEC, 2015) cuenta con un sistema
estadístico como un auxiliar fundamental para la toma de decisiones de política pública,
también se ha podido evidenciar que las grandes empresas sobre todo las trasnacionales
instaladas en el país son las que están empleando esta tecnología para la gestión de sus
procesos de negocio, además, existen varias consultoras que ofrecen esta herramienta para
pequeñas y medianas empresas, ofertando como beneficios la eficiencia y eficacia en la toma
de las decisiones.
Con los antecedentes detallados se afirma que se puede desarrollar una aplicación
datawarehouse en la empresa “PRONACA”, en el negocio pecuario gestión logística región
Santo Domingo.
1
Planteamiento del problema.
La empresa PRONACA área de logística regional Santo Domingo actualmente no cuenta
con el suficiente flujo de información para las gerencias del departamento de logística.
Entendiendo que la información no se encuentra estructurada y procesada. Los datos están
almacenados en diferentes bases de datos (ERP, Excel, sistema de gestión pesaje (Aries)), y
para poder llevar a cabo la obtención de reportes necesitamos demasiado tiempo. Los
gerentes requieren tener el acceso a la información de una manera más personalizada y
rápida, debido a que en algunas ocasiones se ha perdido tiempo en tomar acciones en
eventualidades por la falta inmediata de información estructurada, de forma que se pueda
analizar y tener un soporte en la toma de decisiones. Uno de los problemas principales se da
cuanto a la generación de reportes, estos son realizados de una forma manual, lo que requiere
tiempo para el área de sistemas en la generación de los mismos además causando un gran
tráfico en la base de datos de producción. Reflejándose en el tiempo de espera de cada
consulta realizada a la base de datos.
Formulación del problema.

Deficiente gestión de la información para la toma de decisiones en el área logística de la
compañía PRONACA.
Identificación de la línea de investigación.

El presente trabajo investigativo se enmarca en la línea denominada:
Tecnologías de información y comunicaciones.
Justificación del tema.

En base a mis conocimientos adquiridos sobre esta investigación en la implementación de
un datawarehouse, he podido ver la importancia de tener información tratada en un negocio
para la toma de decisiones. Dentro de la gestión logística se aumentará la capacidad de
generar y recoger datos, los cuales serán identificados, categorizados y resumidos para
aportar con información analítica, la misma que podrá ser utilizada eficiente y
oportunamente; esto apoyará la toma de decisiones permitiendo incrementar la credibilidad
institucional.
Con la informatización de la sociedad y dentro de estas las empresas, ha crecido a nivel
mundial la capacidad de generación y almacenamiento de la información, que no puede ser
analizada por los métodos tradicionales existentes, mientras mayor es la capacidad para
2
almacenar más y más datos, mayor es la incapacidad para extraer información realmente útil
de éstos en las empresas. Mucha información importante, quedaba sepultada y disgregada,
y los sistemas existentes no estaban preparados para el nuevo reto.
Por ello se plantea una solución basada en tecnologías de información mediante la

implementación de un almacén de datos (datawarehouse), para obtener un producto que
permita generar información tratada y útil, la cual apoyará el análisis del negocio (procesos)
que se requieran, como son: Gestión logística pecuaria en abastecimiento de materia prima,
distribución de producto terminado a diferentes tipos de clientes, lo que permitirá dar soporte
a los directivos del negocio en la toma de decisiones.
En el campo de la investigación podemos decir que este tema constituye un aporte científico
del investigador, ya que es original por no existir un tema igual.
Objetivos.
Objetivo General.
Implementar un datawarehouse para mejorar la toma de decisiones en el área de logística de
la compañía PRONACA.
Objetivos Específicos.
 Realizar el análisis y levantamiento de los requerimientos para la construcción de un
datawarehouse.
 Estudio bibliográfico de herramientas para construir un datawarehouse, y la gestión
de la información.
 Implementar el datawarehouse para el área logística regional Santo Domingo.
3
1 CAPITULO I. MARCO TEÓRICO.
1.1 Origen y evolución del objeto de investigación.
Dentro del marco histórico que presenta la gestión logística en las empresas al nivel mundial,
los procesos de abastecimiento de materias primas y distribución de producto terminado, se
originaron por las necesidades de abastecerse de materia prima para cumplir sus demandas
en su producción y colocar sus productos en el lugar y tiempo adecuado, con el pasar del
tiempo estas necesidades fueron creciendo ya que la demanda de los diferentes productos
iban en aumento, esto ocasiono mayores flujos por lo que se requería de mayor recursos
como el talento humano, el transporte y la información, uno de ellos y el más importante
para la administración logística son los datos, grandes cantidades de datos que deben ser
tratados para lograr una buena toma de decisiones en la administración de sus recursos.
1.2 Análisis de distintas posiciones teóricas sobre el objeto de investigación.

Según (Casanovas & Cuatrecasas, 2003). La gestión logística se debe encargar de “coordinar
y gestionar, como un sistema único, los flujos de información y de materiales de un extremo
al otro del canal, a fin de obtener con un coste mínimo el mejor nivel de servicio al cliente,
al mismo tiempo que reducir la inactividad asociada al conducto”, generando para la empresa
un valor agregado que contribuya al buen funcionamiento de todos sus procesos.
En el sitio web de la revista É Logística (Tesler, 2010) cita que “Las soluciones de Business
Intelligence ofrecen diferentes maneras para ver, analizar y presentar métricas corporativas,
como Key Performance Indicators (KPI) con el uso de tableros de control, análisis
interactivo, informes estándar o al publicar información al momento que sea necesario,
usando el medio necesario dentro de una infraestructura integrada para mejorar el
desempeño corporativo al tomar mejores decisiones.”
En el sitio web de la revista (Logistec, 2014) cita que “En la actualidad, la inteligencia de
negocios o Business Intelligence puede aportar muchísimo más valor a la logística que en el
pasado. Esto se debe a que la cadena de valor del negocio logístico hoy en día puede recoger
los datos en tiempo real y disponer de estos en cualquier momento gracias a las tecnologías
de las telecomunicaciones.”
De acuerdo a los autores citados se puede concluir que por medio de herramientas de
inteligencia de negocios aplicado al análisis de la información en los procesos de
4
abastecimiento de materias primas y distribución de producto terminado, permite mejorar
significativamente la toma de decisiones.
1.3 Valoración crítica de los conceptos principales de las distintas posiciones teóricas
sobre el objeto de investigación.
1.3.1 Business Intelligence.

1.3.1.1 Introducción.
Hoy en día en las empresas y organizaciones, la gestión de información es un elemento clave
para poder competir de mejor manera en un mercado muy cambiante, y de una sociedad de
negocio. La información que se maneja es de vital importancia, porque en ella se fundamenta
la toma de decisiones, sirviendo de pilar para el crecimiento y gestión, como también de
guía en la consecución de los objetivos que persiguen las empresas. Además cada vez es más
importante saber qué es lo que sucede con los negocios que en ellas se gestiona, y de cómo
mejorarlas. Por otro lado existen organizaciones las cuales poseen un sin número de datos,
pero que a su vez no cuentan con información, esto se debe por el gran problema de que no
saben qué hacer ni cómo utilizar esos datos en beneficio propio, y como resultado, hoy en
día gran parte del sector empresarial no sabe que cuentan con información valiosa capaz de
ser utilizada para mejorar la competitividad del negocio.
Aquí es donde nace el concepto de Business Intelligence o Inteligencia de Negocios, como
solución para el soporte de toma de decisiones, mediante la generación y análisis de
información, y con la que se busca el conocimiento organizacional. (Rojas & Duque, 2010)
1.3.1.2 Definiciones.
Para definir inteligencia de negocios partiremos de la definición de Gartner editada en el
libro del autor: (Cano, 2007): “BI es un proceso interactivo para explorar y analizar
información estructurada sobre un área (normalmente almacenada en un datawarehouse),
para descubrir tendencias o patrones, a partir de los cuales derivar ideas y extraer
conclusiones. El proceso de inteligencia de negocios incluye la comunicación de los
descubrimientos y efectuar los cambios”.
Una definición más amplia es la que proponen The datawarehouse Institute, “Business
Intelligence (BI) es un término paraguas que abarca los procesos, las herramientas, y las
5
tecnologías para convertir datos en información, información en conocimiento y planes para
conducir de forma eficaz las actividades de los negocios.”
Cavalcanti define como: “Un concepto actualizado que va más allá de la gestión empresarial.
Consiste en la utilización de productos y soluciones con tecnologías analíticas avanzadas
para transformar los datos en información que ayuda a los distintos niveles de la
organización en la toma de decisiones y otras contribuciones, casi todas en análisis de
estrategias.” (Puerta Gálvez, 2015)
1.3.1.3 Objetivo de las herramientas de inteligencia de negocios.

El objetivo principal de la inteligencia de negocios es mejorar la toma de decisiones del
negocio a través del uso de herramientas tecnologías que permitan reunir, almacenar,
analizar, y proporcionar acceso a los datos de gestión de la empresa.
1.3.1.4 Características de la inteligencia de negocios.

Tienen en común las siguientes características:
 Accesibilidad a la información.- Los datos son la fuente principal de este concepto
y lo primero que debe garantizar este tipo de herramientas y técnicas será el acceso
de los usuarios a los datos con independencia de la procedencia de estos.
 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 permitan seleccionar y manipular sólo aquellos datos que les interesen.
 Orientación al usuario final.- Se busca independencia entre los conocimientos
técnicos de los usuarios y su capacidad para utilizar estas herramientas. (Espinosa,
DATAPRIX, 2010)
1.3.2 Sistemas de información.

Las empresas son cada vez más conscientes de la importancia de disponer de más y mejor
información, actualizada, estructurada, fácilmente accesible y adaptada a sus necesidades
concretas, como un soporte en la toma de decisiones.
Según Andreu, Ricart y Valor (1991). Definen que, el sistema de información: “Es el
conjunto formal de procesos que operando sobre una colección de datos estructurada de
acuerdo con las necesidades de una empresa, recopila, elabora y distribuye la información
necesaria para la operación de dicha empresa y para las actividades de dirección y control
correspondientes, apoyando, al menos en parte, los procesos de toma de decisiones
6
necesarios para desempeñar las funciones de negocio de la empresa de acuerdo con su
estrategia”. (Lapiedra Almaí, Devece Carañana , & Guiral Herrando, 2011)
Figura 1-1: Pirámide Sistemas de Información

Fuente: (Ferrer Mos, 2015)
1.3.2.1 Sistemas de soporte a decisiones (DSS).

Un sistema de información basado en un computador interactivo, flexible y adaptable,
especialmente desarrollado para apoyar la solución de un problema de gestión no
estructurado para mejorar la toma de decisiones. Utiliza datos, proporciona una interfaz
amigable y permite la toma de decisiones en el propio análisis de la situación. (Turban, 1995)
1.3.2.1.1 Función.
La función principal del Sistema de Soporte de Decisiones es la de apoyar a la toma de
decisiones mediante el análisis de las variables de un negocio con la generación y evaluación
de diferentes alternativas de decisión, todo esto utilizando modelos y herramientas
computacionales.
1.3.2.1.2 Características.
El sistema de soporte de decisiones es una de las herramientas más emblemáticas de la
inteligencia de negocios, estas son algunas de sus características principales:
 Informes dinámicos e interactivos, de manera que el usuario no tenga que limitarse
a los listados predefinidos que se configuraron en el momento de la implantación, y
que no siempre responden a sus dudas reales.
7
 No requiere conocimientos técnicos, un usuario no técnico puede crear nuevos
gráficos e informes y navegar entre ellos, solo con “arrastrar y soltar” y examinar la
información disponible o crear nuevas métricas.
 Rapidez en el tiempo de respuesta, ya que la base de datos suele ser un
datawarehouse corporativo o un datamart, con modelos de datos en estrella o copo
de nieve. Este tipo de bases de datos están optimizadas para el análisis de grandes
volúmenes de información.
 Integración entre todos los sistemas, el proceso de ETL previo a la implantación
de un sistema de soporte a la decisión garantiza la calidad y la integración de los
datos entre las diferentes unidades de la empresa.
 Cada usuario dispone de información adecuada a su perfil, no se trata de que
todo el mundo tenga acceso a toda la información, sino de que tenga acceso a la
información que necesita para que su trabajo sea lo más eficiente posible.
 Disponibilidad de información histórica, en estos sistemas está a la orden del día
comparar los datos actuales con información de otros períodos históricos de la
compañía, con el fin de analizar tendencias, fijar la evolución de parámetros de
negocio, entre otros.
1.3.3 Datawarehouse.
1.3.3.1 Definiciones.
En la actualidad existen muchas definiciones para el datawarehouse, las más conocidas e
importantes que fueron citadas por (Días & Cnesa, 2010) son: Bill Inmon y Ralph Kimball.
Inmon (considerado por muchos el padre del concepto) dice: “Un Data Warehouse es un
conjunto de datos orientados por temas, integrados, variantes en el tiempo y no volayiles, que
tienen por objetivo dar soporte a la toma de decisiones”.
Kimball (considerado el principal promotor del enfoque dimensional para el diseño de almacenes
de datos), dice: ”Un datawarehouse e la copia delos datos transaccionales específicamente
estructurada para la consulta y el análisis. También fue Kimball quien determinó que un data
warehouse no era más que: “la unión de todos los Data marts de una entidad”. Defiende por tanto
una metodología ascendente (Bottom-up) a la hora de diseñar un almacén de datos.
8
1.3.3.2 Función.
La principal función de un datawarehouse es almacenar datos para convertirlos en
información útil para las empresas, esta información debe estar disponible para las gerencias
en el momento que requieran y con un formato adecuado sin afectar las operaciones de los
sistemas operacionales.
1.3.3.3 Características.
Según definió Bill Inmon, el datawarehouse se caracteriza por ser:
 Integrado.- Los datos almacenados en el datawarehouse deben integrarse en una

estructura consistente, por lo que las inconsistencias existentes entre los diversos
sistemas operacionales deben ser eliminadas. La información suele estructurarse
también en distintos niveles de detalle para adecuarse a las distintas necesidades de
los usuarios.
 Temático.- Sólo los datos necesarios para el proceso de generación del conocimiento
del negocio se integran desde el entorno operacional. Los datos se organizan por
temas para facilitar su acceso y entendimiento por parte de los usuarios finales. Por
ejemplo, todos los datos sobre clientes pueden ser consolidados en una única tabla
del Datawarehouse. De esta forma, las peticiones de información sobre clientes serán
más fáciles de responder dado que toda la información reside en el mismo lugar.
 Histórico.- El tiempo es parte implícita de la información contenida en un
Datawarehouse. En los sistemas operacionales, los datos siempre reflejan el estado
de la actividad del negocio en el momento presente. Por el contrario, la información
almacenada en el datawarehouse sirve, entre otras cosas, para realizar análisis de
tendencias. Por lo tanto, el Datawarehouse se carga con los distintos valores que toma
una variable en el tiempo para permitir comparaciones.
 No volátil.- El almacén de información de un Datawarehouse existe para ser leído, y
no modificado. La información es por tanto permanente, significando la
actualización del Datawarehouse la incorporación de los últimos valores que tomaron
las distintas variables contenidas en él sin ningún tipo de acción sobre lo que ya
existía. (Espinosa, El Rincon del Business Intelligense, 2009)
9
1.3.3.4 Arquitectura de un datawarehouse.
Para comprender el concepto de datawarehouse, es importante considerar los procesos que
lo conforman. A continuación se describen dichos procesos clave en la gestión de un
datawarehouse: (Fernandez, 2009)
Figura 1-2: Arquitectura de un datawarehouse

Fuente: (Duque Galvez, 2010)
Sistemas origen.- En cuanto a los sistemas origen, son en donde se encuentra los datos de
interés y que serán objeto de extracción, estos orígenes pueden ser desde múltiples lugares
como por ejemplo las bases de datos, así como también hojas de cálculo, archivos planos,
Sistemas ERP (Enterprise Resource Planning), entre otros que serán los que proveerán los
datos de interés.
Staging Area (Area Temporal).- Es un área en la que se almacenará de manera temporal
todos los datos que son extraídos de los sistemas origen según las necesidades planteadas
del negocio. La función primordial es minimizar la afectación a los sistemas origen, porque
cuando se realiza la carga al Datawarehouse, los orígenes de datos no intervendrán hasta que
se realice una próxima carga.
ODS (Operational Data Store).- Como su nombre indica, esta área es la que va a dar
soporte a los sistemas operacionales. El modelo de datos del almacén de datos operacional
sigue una estructura relacional y normalizada, para que cualquier herramienta de reporting
o sistema operacional pueda consultar sus datos. Está dentro del datawarehouse porque se
aprovecha el esfuerzo de integración que supone la creación del almacén de datos
corporativo para poder atender también a necesidades operacionales, pero no es obligatorio,
10
y ni siquiera es algo específico del Business Intelligence, los ODS ya existían antes de que
empezáramos a hablar de BI y de DWH.
Datawarehouse.- Los datos a ser cargados en el almacén provendrán del Staging Area así
como también puede ser desde el ODS. Aquí los modelos de datos no serán tan normalizados
como lo es en los sistemas origen y en el ODS, aquí sucede lo contrario y se realizan técnicas
de des normalización.
Data marts.- Es un subconjunto de los datos del datawarehouse cuyo objetivo es responder
a un determinado análisis, función o necesidad, con una población de usuarios específica. Al
que en un datawarehouse, los datos están estructurados en modelos de estrella o copo de
nieve y un data mart puede ser dependiente o independiente de un datawrehouse. Por
ejemplo, un posible uso seria para la minería de datos o para la información de marketing.
El data mart está pensado para cubrir las necesidades de un grupo de trabajo o de un
determinado departamento dentro de la organización. (Días & Cnesa, 2010)
1.3.3.5 Estructura.
Los datawarehouses tienen una estructura distinta. Hay niveles diferentes de
esquematización y detalle que delimitan, en la siguiente figura se puede apreciar mejor su
estructura. (INEI, 1997)
Figura 1-3: Estructura de los datos de un datawarehouse

Fuente: (Bernabeu, 2010)
 Detalle de datos actuales.- En gran parte, el interés más importante radica en el

detalle de los datos actuales, debido a que refleja las ocurrencias más recientes, las
11
cuales son de gran interés, es voluminoso, ya que se almacena al más bajo nivel de
granularidad, casi siempre se almacena en disco el cual es de fácil acceso, aunque su
administración sea costosa y compleja.
 Detalle de datos antiguos.- La data antigua es aquella que se almacena sobre alguna
forma de almacenamiento masivo. No es frecuentemente accesada y se almacena a
un nivel de detalle, consistente con los datos detallados actuales. Mientras no sea
prioritario el almacenamiento en un medio de almacenaje alterno, a causa del gran
volumen de datos unido al acceso no frecuente de los mismos, es poco usual utilizar
el disco como medio de almacenamiento.
 Datos ligeramente resumidos.- Son aquellos que proviene desde un bajo nivel de
detalle y sumarizan o agrupan los datos bajo algún criterio o condición de analisis.
Este nivel del datawarehouse casi siempre se almacena en disco.
 Datos completamente resumidos.- Estos datos son compactos y fácilmente
accesibles, a veces se encuentra en el ambiente de dfatawarehouse y en otros, fuera
del límite de la tecnología que ampara al datawarehouse. (De todos modos, los datos
completamente resumidos son parte del datawarehouse sin considerar donde se
alojan los datos físicamente.)
 Metadata.- El componente final del datawarehouse es el de la metadata. De muchas
maneras la metadata se sitúa en una dimensión diferente al de otros datos del
datawarehouse, debido a que su contenido no es tomado directamente desde el
ambiente operacional. La metadata juega un rol especial y muy importante en el
datawarehouse y es usada como: Un directorio para ayudar al analista a ubicar los
contenidos del datawarehouse, y es una guía para el mapping de datos de cómo se
transforma, del ambiente operacional al de datawarehouse. Una guía de los
algoritmos usados para la esquematización entre el detalle de datos actual, con los
datos ligeramente resumidos y éstos, con los datos completamente resumidos, etc.
(INEI, 1997)
1.3.3.6 Proceso de extracción, transformación y carga ETL.

El ETL (Extract, Transform and Load) es un proceso destinado a la extracción,
transformación y carga de datos procedentes de una base de datos transaccional para un
datawarehouse. En este proceso son obligatorias la extracción y la carga ya que si los datos
12
estuvieran en el mismo formato o lenguaje de destino no será necesario hacer la
transformación. (Puerta Gálvez, 2015)
Existe un conjunto básico de procesos de suma importancia detrás de una arquitectura de

datawarehouse, que garantizan la calidad de datos que en ella se almacenarán. Este proceso
de Extracción, Transformación y Carga, también conocido como ETL o proceso de
integración de datos, cumple con la función principal de organizar e integrar el flujo de datos
desde múltiples fuentes, hacia un destino que es el almacén de datos (Datawarehouse). El
proceso ETL brinda soporte a la gestión de datos que se va a realizar, obteniendo calidad de
los mismos dentro de un almacén como se puede apreciar en la figura 1-4. (Duque Galvez,
2010)
Figura 1-4: Proceso ETL

Este proceso general se encuentra subdividido en tres subprocesos fundamentales como se

detalla a continuación:
 Extracción.- Esta etapa del proceso debe basarse en la búsqueda de las
informaciones más importantes en sistemas fuentes o externas y que estén en
conformidad con el modelo del datawarehouse. Esta búsqueda en la mayoría de los
casos, es dificultada por el hecho de las informaciones estar almacenadas en fuentes
distintas de datos. En su primer momento es normal que la carga inicial sea hecha
para que todos los datos del sistema original sean transferidos a un área del
datawarehouse llamada de Stage y posteriormente pasada para el área llamada ODS,
también en el datawarehouse. Después de eso las demás cargas serán incrementales
que según Kimball es la más eficiente y carga solamente los registros que fueron
alterados o insertados en la base original. (Puerta Gálvez, 2015)
13
 Transformación.- Es el subproceso más laborioso con respecto a los otros dos,
debido a que en esta etapa se realiza el refinamiento de los datos que han sido
extraídos de las diferentes fuentes, por lo que aquí se especificará pasos de acuerdo
a los datos que van a ser tratados dando valor para los usuarios. Este proceso incluye
corrección de errores, decodificación, borrado de campos que no son de interés,
generación de claves, agregación de información, etc., lo que es más conocido como
limpieza de los datos fuentes. (Duque Galvez, 2010)
 Carga.- El último subproceso se caracteriza por realizar la carga hacia el
datawarehouse, los datos que previamente han sido extraídos y tratados en los dos
subprocesos anteriores para contar con datos de calidad, ahora se procederá a realizar
la carga de los mismos a un nuevo ambiente que es el de almacén de datos, para ello
es importante implementar métodos y/o maneras de carga de datos con el fin de
controlar por ejemplo datos actualizados o históricos. (Rojas & Duque, 2010)
1.3.3.7 Modelo dimensional de un datawarehouse.

Un datawarehouse adopta un modelo dimensional en su estructura de almacenamiento,
caracterizado por ser un esquema en estrella o copo de nieve, lo que permite maximizar el
rendimiento de las consultas, a continuación una definición de modelo dimensional: “El
modelado dimensional es una forma de acercar los datos a la manera en que estos serán
convertidos en información útil para los usuarios del negocio. La aplicación del modelo
dimensional tiene lugar en la fase de diseño lógico, lo que permite la traducción del esquema
resultante del diseño conceptual al plano lógico.” (Leon, 2014)
 Esquema estrella.
Consiste en estructurar la información en procesos, vistas y métricas recordando a
una estrella (por ello el nombre). A nivel de diseño, consiste en una tabla de hechos
y una o varias tablas de dimensión por cada punto de vista de análisis que participa
de la descripción de ese hecho. En la tabla de hecho encontramos los atributos
destinados a medir (cuantificar): sus métricas. La tabla de hecho presenta uniones
con dimensiones. (Días & Cnesa, 2010)
14
Figura 1-5: Esquema Estrella
 Esquema copo de nieve.

Es un esquema de representación derivado del esquema en estrella, en el que las
tablas de dimensión se normalizan en múltiples tablas. Por esta razón, la tabla de
hecho deja de ser la única tabla del esquema que se relaciona con otras tablas y
aparecen nuevas uniones. (Días & Cnesa, 2010)
Figura 1-6: Esquema copo de nieve

1.3.3.7.1 Tablas de dimensiones.

Las tablas de dimensiones definen como están los datos organizados lógicamente y proveen
el medio para analizar el contexto del negocio, mediante los cuales los usuarios podrán filtrar
15
y manipular la información almacenada en la tabla de hechos. En la siguiente figura se puede
apreciar un ejemplo.
Figura 1-7: Tablas de Dimensiones

Cada tabla posee un identificador único y al menos un campo o dato de referencia que
describe los criterios de análisis relevantes para la empresa, los datos dentro de estas tablas,
que proveen información del negocio o que describen alguna de sus características, son
llamados datos de referencia. Cada tabla de dimensión podrá contener los siguientes campos:
 Clave principal o identificador único.
 Clave foráneas.
 Datos de referencia primarios que identifican la dimensión. Ej: nombre del cliente.
 Datos de referencia secundarios: datos que complementan la descripción de la
dimensión. Por ejemplo: e-mail del cliente, fax del cliente, etc. (Bernabeu, 2010)
1.3.3.7.2 Tablas de hechos.

Las tablas de hechos contienen, precisamente, los hechos que serán utilizados por los
analistas de negocio para apoyar el proceso de toma de decisiones. Contienen datos
cuantitativos. Los hechos son datos instantáneos en el tiempo, que son filtrados, agrupados
y explorados a través de condiciones definidas en las tablas de dimensiones. Los datos
presentes en las tablas de hechos constituyen el volumen de la bodega, y pueden estar
compuestos por millones de registros dependiendo de su granularidad y antigüedad de la
organización. Los más importantes son los de tipo numérico. El registro del hecho posee una
clave primaria que está compuesta por las claves primarias de las tablas de dimensiones
16
relacionadas a este. En la siguiente figura se puede apreciar lo anterior misionado.
(Bernabeu, 2010)
Figura 1-8: Tabla de Hecho

1.3.3.7.3 Nivel.
En las dimensiones se pueden especificar características (atributos) en particular de acuerdo
a cada dimensión. Estos atributos necesitan ser ordenados o agrupados de acuerdo a un fin
en específico como por ejemplo se puede observar en la Figura 1-9, en la cual dos
dimensiones se encuentran agrupadas de cierta manera, a estas agrupaciones son llamadas
niveles.
Figura 1-9: Niveles en la Dimensión

Para garantizar que existan registros únicos en cada dimensión es necesario contar con una
clave única para cada nivel de agregación, la misma que se recomienda sea secuencial.
17
1.3.3.7.4 Jerarquías.
Las jerarquías son estructuras lógicas usadas para categorizar los datos, de acuerdo a los
niveles definidos, la jerarquía también ayuda a definir la navegación por la información que
va a tener la dimensión en un orden (de los niveles) definido. (Duque Galvez, 2010)
Figura 1-10: Jerarquía en la Dimensión.

1.3.3.7.5 Granularidad.
La granularidad es el nivel de detalle en que se almacena la información. Por ejemplo:
Las ventas pueden expresarse por día y los objetivos por mes. El atributo de granularidad de
la relación normal permite gestionar este caso sin problema. En todos los casos, y de forma
especial en el caso de una dimensión realizadora de funciones, usted define en la relación la
columna o columnas del grupo de medidas ligadas al atributo de granularidad. (Gauchet,
2011)
1.3.3.7.6 Relaciones.
Las relaciones mantienen la integridad de la información del negocio, referenciando datos
entre diferentes tablas, en este caso, relacionando las dimensiones con los hechos, como por
ejemplo la relación Producto – Ventas, Almacén – Pedidos, etc.
Figura 1-11: Relaciones en un Modelo

18
1.3.3.7.7 Claves subrogadas.
Una clave subrogada es un identificador único que se asigna a cada registro de una tabla de
dimensión. Esta clave, generalmente, no tiene ningún sentido específico de negocio. Son
siempre de tipo numérico. Preferiblemente, un entero autoincremental. (Urquizu, 2009)
1.3.3.8 Análisis OLAP.

El procesamiento analítico en línea permite obtener acceso a datos organizados y agregados
de orígenes de datos empresariales, organiza subconjuntos de datos con una estructura
multidimensional de manera que represente un significado especial o responda a una
pregunta en particular (Gomez, 2010). OLAP (On-Line Analytical Processing) o
Procesamiento Analítico en línea, surge como contraste a OLTP (On-Line Transactional
Processing) que define a los sistemas de ambientes transaccionales.
El análisis multidimensional (Análisis OLAP), parte de una visión de la información como
dimensiones de negocio, en la que hay que tomar en cuenta que se debe de olvidar lo que
son las tablas y campos, dando mayor énfasis a lo que son las dimensiones y medidas.
Figura 1-12: OLAP (On-Line Analytical Processing)

Las herramientas OLAP se caracterizan por subdividirse en tres tipos de acuerdo a la manera
de almacenar los datos, estos son:
 ROLAP (Relational OLAP).
Arquitectura en la que se almacenan los datos en un motor de base de datos
relacional, pero de igual manera se proporciona la funcionalidad analítica. A través
de esta implementación se soporta de mejor manera las capacidades OLAP con
respecto a las bases de datos relacionales, en el sentido que realiza consultas directas
a la base de datos, e igualmente presenta los datos de la manera multidimensional
19
caracterizada por la arquitectura. Los esquemas más comunes sobre los que se trabaja
son estrella o copo de nieve. La arquitectura está compuesta por un servidor de datos
relacional y el motor OLAP.
 MOLAP (Multidimentional OLAP).
En este tipo de arquitectura los datos se almacenan de manera dimensional en un
servidor de base de datos multidimensional, permitiendo optimizar los tiempos de
respuesta en la información, ya que al ser sumarizada y/o agregada ayuda mucho a
los datos calculados por adelantado como por ejemplo los totales, lo que aumenta el
desempeño de análisis.
Para tener un idea de cómo funciona la tecnología OLAP se puede hacer una analogía
con la representación de un cubo, y es aquí donde nace el término de los cubos de
información, que no son otra cosa más que el análisis multidimensional de los
datos, como se puede apreciar en la figura 1-13 a continuación.
Figura 1-13: Cubo OLAP

Fuente: (Sanches, 2012)
En un análisis OLAP se implementan funcionalidades las cuales permiten interpretar la

información de diferentes maneras, estas funciones u operaciones entre las más importantes
son:
 Drill down.- Desglosar una métrica de lo general a lo particular por la jerarquía de
sus dimensiones.
20
Figura 1-14: Operación OLAP - Drill Down
 Roll up.- Agregar una métrica de lo particular a lo general por la jerarquía ascendente
de sus dimensiones.
Figura 1-15: Operación OLAP - Roll Up

1.3.4 Desarrollo de un datawarehouse basado en la metodología Ralph Kimball.
Ralph Kimball plantea una metodología para el desarrollo de soluciones de BI/DWH, que
garantiza buenas prácticas para la implementación de un proyecto de este tipo, mediante la
consecución de una serie de pasos a seguir durante toda la administración del proyecto, como
se muestra en la figura a continuación.
Figura 1-16: The Kimball Lyfecycle Diagramt

Fuente: (Kimball, 2008)
21
En base a esta metodología, se tomará los puntos con mayor importancia para que sean
especificados, y se realizará ciertas adecuaciones para este proyecto según las necesidades
que se presenten. (Kimball, 2008)
1.3.4.1 Planeación y administración del proyecto.
Definición del proyecto.
En la definición se identifica el escenario para poder determinar el alcance del proyecto, en
el sentido que se puede apreciar de donde se origina la demanda dentro de la organización.
Los posibles escenarios originados dentro de una empresa son:
 Demanda de un sector del negocio.- Un Sector en específico como por ejemplo los
directivos del negocio.
 Demasiada demanda de la información.- Se caracteriza por provenir de más de un
sector del negocio, por ejemplo aparte de los directivos del negocio, los de la empresa
y ciertos gerentes relacionados con el negocio.
 En busca de demanda.- Escenario en el que se encuentra involucrado el presidente
o directivo principal de la empresa.
Determinar preparación de la empresa para un proyecto de Datawarehouse.

Son cinco factores importantes según la metodología de Ralph Kimball, las que se deben
tomar en cuenta para poder iniciar un proyecto de almacén de datos, estos son:
 Patrocinio de la gerencia del negocio.
 Motivación del negocio.
 Acompañamiento del departamento de tecnología y de negocio.
 Presencia de cultura analítica.
 Factibilidad.
Desarrollo del alcance preliminar.
Se centra en definir de manera preliminar el alcance del proyecto, para poder hacerlo, la base
debe ser los requerimientos del negocio. Para la definición del alcance es importante seguir
los siguientes parámetros:
Desarrollo de la Justificación del Negocio.
En la Justificación se deben especificar e identificar el costo y beneficio que está relacionado
con el proyecto.
Los componentes a ser considerados de inversiones y costos son los siguientes:
22
Costos de Hardware.- Se toma en cuenta el costo de acuerdo a los equipos que serán
utilizados para el proyecto.
 Costos de Software.- Tomar en cuenta el costo de Software que se necesitara para
el proyecto, como software para ETL, reportería, entre otros.
 Recursos Internos.- Recursos con los que la organización cuenta para el proyecto.
 Recursos Externos.- En caso de necesitar algún tipo de consultoría o servicio
externo a la organización.
 Costos de Mantenimiento.- La mayoría de productos de hardware y software
necesitan de un mantenimiento.
 Soporte.- Todo lo que es el soporte a los usuarios ya sean estos a través de help desk.
 Costos de Crecimiento.- Se debe considerar nuevos requerimientos, mejoras
tecnológicas de los productos relacionados de software.
Se considera también los retornos y beneficios a obtener, como:
 Incremento de ganancias.
 Incremento en los niveles de servicio a los clientes.
 Aumento de información para la empresa, y su rápido acceso a ella.
Planeación del Proyecto.

Se debe especificar un nombre para el proyecto, así como los roles de la(s) persona(s) que
participara en el proyecto, dependiendo la participación de cada una y requerimientos que se
hayan especificado.
Los principales roles para el proyecto son:
 Patrocinadores de negocio.
 Gerente o administrador del proyecto.
 Líder de negocio del proyecto.
 Analista de negocio.
 Arquitecto de datos.
 Modelador de datos.
 Administrador de base de datos.
 Diseñador de proceso de ETL.
 Desarrolladores de aplicaciones de BI para usuarios.
 Educador o capacitador del almacén de datos.
 Administración del proyecto
23
Aquí se deberá considerar las reuniones con el equipo de trabajo, el monitoreo de estado del
proyecto realizado periódicamente, el alcance y estrategias de comunicación ya sea con el
equipo de trabajo o con usuarios externos, en estos últimos esencialmente la manera de tratar
por ejemplo cuando llegan nuevos requerimientos a los cuales hay que ver la manera de
manejar estas situaciones.
1.3.4.2 Definición de los requerimientos del negocio.
Los requerimientos de los usuarios del negocio ayudan a definir el diseño e implementación
del datawarehouse, es por esto que desde una perspectiva macro los requerimientos son el
centro del negocio y por ende factor de éxito para un satisfactorio desarrollo de un
datawarehouse.
Algo importante a tener en cuenta es saber identificar y asociar los requerimientos desde una
perspectiva macro y así como también desde pequeñas perspectivas.
Para empezar se debe hablar con los usuarios del negocio, sobre sus trabajos, objetivos, e
intentar conocer cómo y en base a que toman decisiones, al contrario lo que no se debe hacer
es preguntar a los usuarios que datos quieren que aparezca o conste en el datawarehouse, ya
que al conocer su objetivos, decisiones, metas tendremos una mayor perspectiva de que
desean o de qué tipo de información manejan más frecuencia.
1.3.4.3 Diseño técnico de la arquitectura.

Se detalle el ambiente de integración, junto con las tecnologías a utilizar, y el cómo va a
funcionar, uniendo tres factores que son: los requerimientos, el entorno técnico, y las
estrategias de diseño a implementar.
Para determinar el diseño técnico se basará en dos divisiones que son:
1.3.4.3.1 Back Room.

Se implementa la integración de datos mediante el proceso de ETL, desde el origen de los
datos hasta la carga de los mismos en el datawarehouse que es la base destino.
1.3.4.3.2 Front Room.

Parte pública y presentable del datawarehouse, en la cual se implementa las aplicaciones
necesarias para poder presentar al usuario final con el fin de que puedan analizar los datos
almacenados en el datawarehouse.
24
En esta etapa, el entregable es diseño de la arquitectura de todo el proceso de integración de
los datos y de la presentación de los mismos, con el fin de obtener un esquema gráfico del
funcionamiento del datawarehouse.
1.3.4.4 Selección e instalación del producto.

Mediante las especificaciones tratadas en el diseño técnico de la arquitectura, se visualiza de
mejor manera el ambiente en el cual se va a desarrollar el proyecto. Se evalúa las
herramientas a utilizar de acuerdo a cada sección o área del proceso de desarrollo. Con lo
cual estará dirigido para:
 Plataforma DBMS.
Existen dos tipos, motor relacional y motor OLAP, lo que se deberá tener en cuenta
cuales son las necesidades, para seleccionar una o ambas opciones.
 Herramienta ETL.
Se evalúa la herramienta a utilizar, tomando en cuenta aspectos importantes, como si
es funcional, y si cumple las posibles necesidades a presentarse en el desarrollo,
como por ejemplo si la herramienta puede generar claves subrogadas y hacer
búsquedas de ellas, entre otras; esto ayudará determinar la herramienta a utilizar.
 Herramienta BI.
Para seleccionar la mejor opción de una herramienta de Front room o de presentación,
se debe tomar en cuenta la funcionalidad, versatilidad y manejo amigable para el
usuario final. En esta etapa como entregable, son las herramientas a utilizar en cada
sección de desarrollo.
1.3.4.5 Modelamiento dimensional.

El modelado dimensional es una técnica de diseño lógico que busca presentar los datos en
un marco de trabajo estándar que es intuitivo y permite acceso de alto desempeño. Es
inherentemente dimensional y se adhiere a una disciplina que usa el modelo relacional con
restricciones de consideración. Cada modelo dimensional está compuesto de una tabla con
una llave múltiple llamada tabla de hechos y un conjunto de tablas llamadas tablas
dimensión. Cada tabla dimensión está compuesta por una llave simple que corresponde
exactamente a uno de los componentes de la llave múltiple en la tabla de hechos. Esta
estructura característica, similar a una “estrella” es a menudo llamada “Esquema Estrella”,
ver figura 1-5. (Mendoza, Cobos, Acosta, Gomez Florez, & Muñoz, 2006)
25
En el modelo dimensional se especifican las medidas y las características. Las medidas son
usualmente numéricas y son referidas a los hechos, mientras que las características de estas
medidas son representadas por las dimensiones, describiendo por ejemplo quien, que,
cuando, de la medida.
Según la tesis elaborada por Duque Gálvez cita cuatro pasos para el diseño dimensional:
1.3.4.5.1 Paso 1 – Seleccionar el Proceso de Negocio.

El primer paso es determinar el proceso que va a ser modelado. Esto es un poco formalismo
ya que la selección del proceso es básicamente referente a los requerimientos que se tomaron,
a través de ello ya se puede determinar cuál será el proceso a que se va a modelar. Los
procesos de negocio son la parte fundamental del datawarehouse, y es aconsejable
construirlo de manera iterativa es decir un proceso por momento. Vale recalcar que cada
proceso de negocio puede producir una o varias tablas de hechos.
1.3.4.5.2 Paso 2 – Declaración de granularidad.
El segundo paso es definir claramente el nivel de granularidad lo que es lo mismo un registro
de la tabla de hecho y decir exactamente la representación de la medida de la tabla de hechos.
1.3.4.5.3 Paso 3 – Identificación de Dimensiones.
El tercer paso es determinar las dimensiones aplicables a la tabla de hechos en el nivel de
granularidad que se detalló. Al agregar nuevas dimensiones los atributos de estas deben
cumplir con la misma granularidad que se haya definido.
1.3.4.5.4 Paso 4 – Identificación de Hechos.
El paso final es identificar los hechos o medidas del negocio. Para la mayoría de los procesos
orientados a transacciones, solo hay algunos hechos fundamentales, que miden por ejemplo
la cantidad o monto. (Duque Galvez, 2010)
1.3.4.5.5 Datawarehouse Bus Matrix.

Es una Matriz Procesos versus Dimensiones comunes, la cual permite tener un panorama
más claro del datawarehouse, al mostrar las dimensiones, hechos, de acuerdo al proceso de
negocio.
26
Figura 1-17: Datawarehouse Bus Matrix
En la etapa de modelamiento dimensional, como entregable es el diseño de la base de datos

del datawarehouse, es decir el modelo de las tablas, junto con la matriz de procesos-hechos
vs. dimensiones.
1.3.4.6 Diseño físico.

Esta etapa se centra en definir la estructura física, como:
 Configuración del entorno de base de datos.
 Creación de espacios de tablas para datos y metadatos.
 Creación de tablas, para el datawarehouse y para las bases origen en caso de ser
necesario.
 Creación de llaves primarias y foráneas.
 Creación de índices en las tablas.
 Desarrollo de tablas temporales (Staging Area) en caso de ser necesario.
En esta etapa, el entregable son los scripts, que son generados al finalizar el diseño y
desarrollo físico. (Kimball, 2008)
1.3.4.7 Diseño y desarrollo del proceso ETL.

El desarrollo del Sistema ETL es un desafío para un proyecto de este tipo ya que se debe
tomar en cuenta aspectos como: estudio y análisis de los datos, integración de los mismos
con el objetivo de resolver problemas de calidad, cargas automáticas; por lo que se considera
fundamental al proceso ETL en el marco de desarrollo de un proyecto de BI/DWH.
Se plantean pasos para el diseño y desarrollo de un proceso ETL, estos son:
27
Desarrollo del Plan ETL.
1.3.4.7.1 Paso 1 – Trazar un plan de alto nivel.
Se diseña un mapa mediante cuadros que especifican la actividad a realizar, con el fin de
mostrar el flujo de datos, desde el origen hacia el destino.
1.3.4.7.2 Paso 2 – Seleccionar la herramienta ETL.
Se selecciona la herramienta ETL adecuada, tomando en cuenta las funcionalidades que se
van a utilizar.
1.3.4.7.3 Paso 3 – Desarrollar estrategias por defecto.
Teniendo la idea de cómo va a funcionar el proceso ETL, se desarrollará estrategias con el
fin de garantizar y aumentar el rendimiento del mismo, como por ejemplo:
Administración de cambios en los atributos de las dimensiones.
 Carga de datos.
 Frecuencia de carga.
 Organización del área temporal ETL.
 Secuencia de los procesos de transformaciones.
 Registro y manejo de errores.
1.3.4.7.4 Paso 4 – Profundizar la tabla objetivo.
Se diseña la jerarquía de las tablas objetivo mediante gráficos, es decir, se le da un orden a
los niveles de las dimensiones, con lo que se puede apreciar la estructura desde un nivel
macro hasta el más detallado.
Desarrollo de Carga Inicial.

1.3.4.7.5 Paso 5 – Poblar las tablas de dimensiones con los datos históricos.
Las dimensiones (tablas objetivo) serán pobladas por primera vez, para lo cual se
implementarán actividades como:
 Extracción de datos
 Transformaciones
 Carga de datos.
1.3.4.7.6 Paso 6 – Realizar la carga histórica de la tabla de hechos.
Al igual que las dimensiones, se realizará el poblado de los hechos por primera instancia,
tomando en cuenta los datos de las dimensiones, y asignando adecuadamente los registros
de las mismas a la de sus respectivos hechos.
28
De igual manera se implementará las actividades de extracción, transformación según la
necesidad, y de carga de datos.
Desarrollo de carga incremental.

1.3.4.7.7 Paso 7 – Procesamiento incremental de la dimensiones.
Las dimensiones serán pobladas de manera incremental, es decir a partir de la segunda carga
de datos. Al igual que el poblado inicial, se realizará las transformaciones, y carga de datos,
con la diferencia ahora, que la extracción se realizará exclusivamente con datos nuevos o
que hayan cambiado en el origen.
1.3.4.7.8 Paso 8 – Procesamiento incremental de los hechos.
Así mismo el poblado incremental se realizará a partir de la segunda carga a la tabla de
hecho, y tomando en cuenta únicamente de los datos nuevos o que hayan sufrido cambios;
y al igual que la carga inicial se implementa las demás actividades como transformaciones.
1.3.4.7.9 Paso 9 – Operación y automatización del sistema ETL.
Con el fin de garantizar la ejecución periódica del proceso ETL, es necesario automatizar
los trabajos y transformaciones.
Según la herramienta ETL que se haya seleccionado, esta implementará pasos para
configurar tareas programadas, permitiendo que por cierto tiempo como por ejemplo cada
día se proceda automáticamente con el poblado de datos hacia el Datawarehouse. Esto es de
gran ayuda, en el sentido que no se necesitará la intervención humana para que se realice el
proceso ETL.
Como entregable en la etapa de Diseño y Desarrollo ETL es el documento con las
especificaciones de acuerdo a cada paso de la misma sobre el Proyecto, lo que muestra cómo
funcionará el proceso ETL. (Duque Galvez, 2010)
1.3.5 Herramientas para el desarrollo del datawarehouse.

Las herramientas que se especificarán a continuación serán utilizadas para el desarrollo del
proyecto. Se dividió en tres tipos de herramientas las cuales serán objeto de uso de acuerdo
a cada etapa en que se encuentre el desarrollo del mismo.
1.3.5.1 Motor de base de datos.

Como se apreció hasta el momento un datawarehouse es un almacén, y desde el punto de
vista técnico es una base de datos con cualidades y características específicas de rendimiento.
29
Es por ello la importancia de una base de datos para una aplicación de este tipo, ya que es la
base, y el núcleo en el cual reposarán los datos que previamente han sido tratados.
Por lo que para la creación de la base de datos se debe tomar en cuenta ciertas
funcionalidades como:
 Alto rendimiento y gestión de datos.
 Alta escalabilidad y desempeño para el crecimiento exponencial de datos, lo cual
depende mucho de la cantidad de datos a tratar y ser alojados en el almacén. (Duque
Galvez, 2010)
1.3.5.2 Herramienta ETL.

Hoy en día existe en el mercado varias herramientas ETL de diferente proveedor o casa
comercial, aparte de esto se debe tomar en cuenta funcionalidades que permitan el buen
desarrollo del proceso ETL para lo cual se formuló características básicas que debe tener un
herramienta de este tipo, lo que permite garantizar el trato de los datos.
Extracción de datos desde archivos planos, hojas de cálculo, bases de datos.
Carga de datos de forma masiva en bases de datos.
 Limpieza de datos.
 Interfaz gráfica amigable.
 Unificar datos.
 Seguridad de la información transmitida.
 Retención temporal de información hasta conseguir sincronización.
 Conectividad con diferentes motores de base de datos.
 Soporte de la herramienta para problemas técnicos.
 Interfaz para implementación de código SQL.
1.3.5.3 Microsoft Integration Services.

Es una plataforma para la actualización de almacenamiento de datos, limpieza y minería de
datos, y la administración de objetos y datos de SQL Server. Los paquetes pueden funcionar
en solitario o junto con otros paquetes para hacer frente a las complejas necesidades de la
empresa.
Integration Services puede extraer y transformar datos de diversos orígenes como archivos
de Excel, archivos planos y orígenes de datos relacionales y, después, cargarlos en uno o
varios destinos. (Microsoft, 2014)
30
Figura 1-18: Arquitectura Integration Services
Fuente: (Mendoza Rivera, 2008)
1.3.5.4 Microsoft Analysis Services.

Analysis Services de Microsoft SQL Server es un servidor de nivel intermedio para procesos
analíticos en línea (OLAP) y minería de datos. El sistema Analysis Services incluye un
servidor que administra cubos de datos multidimensionales para analizarlos y proporciona
un rápido acceso a la información de los cubos, organiza los datos de un almacenamiento de
datos en cubos con datos de agregación pre calculados para proporcionar respuestas rápidas
a consultas analíticas complejas. (Nima Ramos, 2009)
1.3.5.5 Herramienta de presentación.

Como parte de la explotación del datawarehouse es importante contar con una herramienta
que permita brindar una interfaz de usuario final, con facilidades y funcionalidades
amigables que permitan una mayor y mejor interpretación de los datos que se encuentran en
el almacén. Por lo que es recomendable que para la selección de una herramienta de este
tipo, ella cuente con funcionalidades como:
 Visualización de gráficos para análisis.
 Navegabilidad dimensional.
 Soporte para agregaciones y sumarizaciones.
 Interfaz amigable para el usuario final.
 Opciones de filtrado o condicionales.
 Soporte a operaciones OLAP como Dril Down, Roll Up, Slice, Dice.
Con las funcionalidades antes mencionadas, facilitará el análisis de datos por parte de los
usuarios finales.
31
 Microsoft Excel.
Es mucho más que una simple hoja de cálculo. Se ha convertido en la herramienta
multipropósito del puesto de escritorio: permite realizar cálculos, tratar y consolidar
datos, realizar el control de gestión, crear cuadros de mando. Muchas de estas
actividades que han encontrado su lugar natural dentro de Excel se aplican de forma
lógica en el sistema decisional. Aun así Excel es la herramienta ideal para el puesto
de trabajo en lo que respecta al consumo de datos decisionales: su interfaz es
conocida, posee una gran potencia de cálculo y de formateo de datos orientada a
business intelligence. Por último, es capaz de conectarse a orígenes de datos
relacionales o decisionales. (Gauchet, 2011)
Figura 1-19: Visualización datos de cubos en hoja de Excel

Elaboración: Freddy Jaramillo.
1.4 Conclusiones parciales.

 A lo largo de esta presente investigación dentro del marco teórico se logra constatar
la importancia de tratar los datos para tener información concreta al momento de la
toma de decisiones, esto como herramienta para los altos mandos dentro de una
empresa.
 Esta investigación nos ha permitido conocer y validar las teorías propuestas por
diferentes autores sobre la toma de decisiones, también conocer las diferentes
tecnologías existentes en el mercado que nos ayudan a elaborar una buena aplicación
de BI.
32
2 CAPITULO II MARCO METODOLÓGICO.
2.1 Caracterización del sector, rama, empresa, contexto institucional o problema
seleccionado para la investigación.
En 1957 nació INDIA, empresa precursora del grupo, dedicada a la importación de insumos
agrícolas. Creció en la industria avícola con la incubación, venta de huevos comerciales y
más adelante fortaleció el campo agrícola con la investigación y producción de semillas.
En 1979 se crea PRONACA, Procesadora Nacional de Aves, que se convierte en
Procesadora Nacional de Alimentos en 1999.
En los 90 diversificó su producción en cárnicos y otros alimentos, e inició la exportación de
palmito en conserva. En el nuevo siglo PRONACA lleva su modelo de producción y
comercialización de palmito a Brasil y productos listos a Colombia.
Esta empresa es el resultado de años de trabajo, creatividad y constancia. Como empresa
procesadora y comercializadora de alimentos, ha alcanzado el reconocimiento por la alta
calidad de sus productos que provienen de los sectores: cárnico, agroindustrial y acuacultura.
Actualmente, es una empresa orgullosamente ecuatoriana, que alimenta bien y genera
desarrollo en el sector agropecuario con responsabilidad social y ambiental.
2.2 Descripción del procedimiento metodológico para el desarrollo de investigación.

2.2.1 Modalidad de la Investigación.
Para el desarrollo del proyecto se utiliza el método inductivo, este método se utilizará para
el análisis de la información in-situ que se obtuvo de las encuestas aplicadas a los
colaboradores involucrados en los procesos y entrevista al jefe regional de logística y
correlacionar con la información del marco teórico respecto a los datawarehouse, esto como
herramienta de apoyo en la toma de decisiones. El método deductivo ha permitido estructurar
el marco teórico en forma técnica, científica y ensayar con los resultados que se obtiene de
las encuestas a través de las conclusiones que se deducen de principios, categorías y de la
idea a defender planteada.
2.2.2 Tipos de investigación.

También se aplicó el método cualitativo porque ha permitido incorporar los resultados
estadísticos a un análisis e interpretación crítica por parte del investigador para la validación
del proyecto.
El método cuantitativo sirvió para identificar los datos pasando por una serie de análisis,
procesamiento de los datos numéricos, estadística de los hechos y factores que inciden en la
33
utilización de datawarehouse por el gerente del negocio logístico y su influencia en la gestión
logística pecuaria.
Y de campo porque se ha acudido al lugar donde se producen los hechos para adquirir datos
primarios (PRONACA – Departamento de logística pecuaria regional Santo Domingo).
2.2.3 Técnicas
Las técnicas de investigación utilizados para obtener información del estado situacional son
las siguientes:
Entrevista.- Utilizado como un medio natural de comunicación, la misma que se aplicó al

jefe logístico regional Santo Domingo Ing. Kelvin Ortiz, con el fin de obtener información
relevante, misma que fue estructurada con 5 preguntas previamente elaboradas y
adicionalmente acoger sugerencias, consejos, opiniones y experiencias a ser tomadas en
cuenta en el desarrollo del proyecto, las preguntas y la descripción de las respuestas se
detallan a continuación:
N°- Preguntas Respuesta narrativa

¿Cada que tiempo son requeridos los Se hace una reunión de entrega de
informes y reportes gerenciales sobre su resultados cada mes de todos los
1
departamento? departamentos, la misma que es
presentada en informes y reportes.
¿Para la construcción de estos informes y Se requiere de varios recursos
reportes que recursos tecnológicos son tecnológicos para obtener los reportes de
empleados? los sistemas transaccionales, como
2
también se requiere de otros programas
como el uso de Excel y Word para
gráficos y proyecciones.
¿Cuánto tiempo le toma en elaborar estos Se cuenta con un periodo de una semana
3
informes y reportes? para presentar dichos reportes.
¿La información presentada que tan La información es confiable, sin embargo
4 confiable es? al momento de presentarla se puede ver
ciertos errores.
¿Qué tan complejo es elaborar estos En realidad es bastante complejo, se
5 informes y reportes? requiere de mucho tiempo para elaborar
estos informes y reportes.
Tabla 2-1: La entrevista
Fuente: Jefe regional de logística.
Encuesta.- Fue aplicada a los colaboradores con relación directa al proceso de gestión
logística en abastecimiento y distribución, que a su vez sirvió para tabular, graficar y analizar
34
la información que brindó un conocimiento amplio de las necesidades y del problema a
solucionar; así como a determinar el nivel de aceptación, impacto y beneficios que
proporcionará con la implementación del sistema datawarehouse en la empresa.
Encuesta dirigida a los colaboradores.- Este instrumento contiene la caracterización y

descripción de las causas y los efectos de la aplicación datawarehouse en los procesos gestión
logística en abastecimiento y distribución en la toma de decisiones del negocio
2.2.4 Población.
La población a la que se va a dirigir la encuesta está conformada por 20 personas, por cual
se toma la totalidad de la misma.
Anexo 1. Modelo de la encuesta dirigida a los colaboradores del departamento de

logística regional Santo Domingo “PRONACA”.
35
Cuestionario tabulado las respuestas de la encuesta.
Pregunta 1.
¿Conoce usted que es un sistema de datawarehouse y para qué sirve?
Respuesta Cantidad Porcentaje

Si 2 10,00%
No 18 90,00%
Tabla 2-2: Datos tabulados pregunta1.
10%
Si
No
90%
Figura 2-1: Ilustración datos tabulados pregunta 1.

Interpretación: La grafica refleja que el 90% de las personas encuestadas desconocen para
que sirven un datawarehouse.
Análisis: Esto implica que la mayoría de los colaboradores del área de logística con una
charla o capacitación podrían conocer y entender sobre los beneficios que brinda un
datawarehouse.
Fuente: Colaboradores del área de logística.
36
Pregunta 2.
¿Ud necesita tener información puntual para la tomar decisiones?

Si 20 100,00%
No 0 0,00%
Tabla 2-3: Datos tabulados pregunta 2.
10%
Si
No
90%

Interpretación: La grafica refleja que el 100% de las personas encuestadas necesitan tener
información puntual para la toma de decisiones.
Análisis: Se demuestra que la mayoría de personas encuestadas necesitan información

puntual para la toma de decisiones.
Fuente: Colaboradores del área de logística.
37
Pregunta 3.
¿Los reportes obtenidos de sistemas informáticos son rápidos?

Nunca 15 75,00%
Alguna vez 3 15,00%
Casi siempre 2 10,00%
Siempre 0 0,00%
0%
10%
Nunca
25% Alguna vez

Casi siempre
65% Siempre

Interpretación: Se observa que el 75% opina que la velocidad para obtener reportes nunca
es rápido, el 15% alguna vez, el 10% casi siempre y el 0% siempre.
Análisis: La mayoría de los encuestados, manifiesta que nunca es rápida la velocidad para
obtener los reportes.
Fuente: Colaboradores del ares de logística.
38
Pregunta 4.
¿De los reportes obtenidos siempre encuentras la totalidad de los datos que necesitas?

Nunca 15 75,00%
Alguna vez 3 15,00%
Siempre 0 0,00%
0%
10%
Nunca
25% Alguna vez

Casi siempre
65% Siempre

Interpretación: Se observa que el 75% opina que nunca obtiene los datos requeridos en un
reporte, el 15% alguna vez obtuvo los datos requeridos, el 10% casi siempre, y el 0%
siempre.
Análisis: En este caso podemos apreciar que la mayoría de los colaboradores encuestados
no obtienen los datos completos al momento de sacar un reporte de los sistemas informáticos,
por lo que necesitan elaborar nuevas campos en Excel para obtener lo requerido,
convirtiéndose en una actividad lenta y compleja.
39
Pregunta 5.
¿Puedes obtener reporte histórico de los sistemas informáticos?

Si 0 0,00%
No 20 100,00%
10%
Si
No
90%

Interpretación: Se observa que el 100% de los encuestados no puede obtener reportes

históricos.
Análisis: El total de las personas encuestadas nos responde que de los sistemas informáticos
no es posible obtener reportes históricos de más de un año.
40
Pregunta 6.
¿Te gustaría tener la información en el momento oportuno?

Si 20 100,00%
No 0 0,00%
10%
Si
No
90%

Interpretación: Se observa que el 100% de los encuestados le gustaría obtener la

información en el momento oportuno.
Análisis: El total de las personas encuestadas nos responde que, el tener la información a la
mano aporta a la toma de decisiones oportunamente.
Fuente: Colaboradores del departamento de logística.
41
Pregunta 7.
¿Cree usted que mejoraría el desempeño en su puesto de trabajo con las estadísticas de la
gestión logística que se obtendría del datawarehouse?
Si 15 75,00%
No 1 5,00%
Tal vez 4 20,00%

8%
17%
Si
No
Tal vez
75%

Interpretación: Se observa que el 75% responde que si mejoraría las actividades de su

puesto de trabajo ya que contaría con datos puntuales en su gestión, el 5% opina que no
mejoraría, y el 20% tal vez.
Análisis: La mayoría de los encuestados manifiestan que si mejoraría la gestión que realiza
en su puesto de trabajo al contar con datos estadísticos y una minoría opina que tal vez o no
aportaría mayor cosa en la mejorar de su gestión.
Fuente: Colaboradores de área de logística.
42
Pregunta 8.
¿Frecuentemente obtiene reportes de los sistemas informáticos?

Nunca 0 0,00%
Alguna vez 2 10,00%
Siempre 13 65,00%
0%
10%
Nunca
25% Alguna vez

Casi siempre
65% Siempre

Interpretación: Se observa que el 0% opina que nunca obtiene reportes de los sistemas
informáticos, el 10% alguna vez se requiere un reporte, el 25% casi siempre y el 65%
siempre.
Análisis: La mayoría de los encuestados manifiestan que necesitan obtener datos de los
reportes generados por los sistemas informáticos, ya que son imprescindibles para el análisis
de los mismos.
43
2.3 Conclusiones parciales.
De la entrevista aplicada al jefe regional de logística se obtuvo como resultado una
información muy detallada acerca de los procesos que realizan para obtener informes y
reportes estratégicos de la gestión logística, de esta manera se obtendrá un datawarehouse
acorde a las necesidades que se realiza en este departamento y esto a su vez permite optimizar
tiempo y recursos. Y de la encuesta realizada a los empleados, se pudo apreciar que existe
una gran acogida y aceptación que avala el desarrollo e implantación de un datawarehouse
para la empresa.
La no existencia de una herramienta datawarehouse incide significativamente en los

procesos logísticos ya que claramente se ha podido notar al momento de la toma de
decisiones que se requiere de varios recursos tecnológicos, ya que a más de los reportes
obtenidos por el sistema transaccional de la empresa se requiere de otros programas como:
Word y Excel para gráficos y proyecciones que no son los ideales para este tipo de trabajo.
44
3 CAPITULO III MARCO PROPOSITIVO.
Para el desarrollo del datawarehouse, se utilizará como guía la metodología de Ralph
Kimball tratada en el capítulo I. Esto permitirá realizar el proyecto en base a pasos que
garantizan la calidad del mismo. Metodología que será adaptada a las necesidades del
proyecto.
3.1 Planeación y administración del proyecto.

3.1.1 Definición del proyecto.
Para el desarrollo de este proyecto se identificó el alto interés por parte del departamento de
logística, manifestando su interés por obtener información que les permita tomar sus
decisiones en función al monitoreo del negocio.
Por lo que se definió el proyecto, dirigiéndole a las áreas interesadas, como proyecto inicial
de este tipo.
3.1.2 Alcance y justificación del proyecto.

En cuanto a estos puntos, ya fueron definidos en las especificaciones del proyecto en el
capítulo I. Pero vale recalcar de manera puntual, el alcance de proyecto, que es el desarrollo
de un datawarehouse, el cual mantendrá información de análisis, de la gestión logística tanto
en abastecimiento de materia prima, abastecimiento y distribución de producto terminado
para granjas de aves, cerdos y comerciales. Su justificación, es de contar con información
útil para el soporte de decisiones en función al análisis de la información.
Para la planeación del proyecto se definió los roles a cumplir en el desarrollo del proyecto,
que son:
Desarrollador del proyecto.

Persona única la cual estará encargada de:
 Desarrollar.
 Monitorear el Desarrollo.
 Diseñar y Modelar.
 Analizar Negocio.
Jefes Departamentales.
Personas con alto rango en el negocio a las cuales se les va a ir notificando periódicamente
los avances del proyecto, los jefes de:
45
 Gestión tecnológica.
 Jefe regional de logística
Personal involucrado en el departamento.
Empleados que participan activamente en la gestión logística de abastecimiento y
distribución.
3.2 Definición de los requerimientos del negocio

Para la definición de los requerimientos se realizaron 4 actividades que ayudaron a
determinar las necesidades de los usuarios del negocio, estas son:
 Realizar la petición a las áreas controladoras del negocio (gestión logística en
abastecimiento y distribución), acerca de qué tipo de información necesita y tratan
diariamente.
 Reunión con los jefes y coordinadores del departamento de logística.
 Realizar el estudio de los reportes implementados en los sistemas actuales de la
compañía, sistemas relacionados a los procesos del negocio. En este punto vale
recalcar que se dio más énfasis a los reportes estadísticos, ya que a través de ellos se
puede recopilar información relevante para el negocio a evaluar.
 Estudiar los negocios con el fin de entender las necesidades de los usuarios.
Tomando en cuenta los puntos anteriores se obtuvo los requerimientos que se mencionan a
continuación:
Gestión logística.
La jefatura de logística supo dar a conocer la información que le interesa y sobre la cual se
soportan para la toma de decisiones, estas son:
 TM abastecidas de MP.
 Costo de transporte.
 Dólares por TM transportada.
 TM despachadas de PT.
 TM despachadas por especie
 Ordenes atendidas.
 Cumplimiento de reaprovisionamiento.
 Cumplimiento pedidos
 Cantidades despachadas.
46
 Costo redes de distribución.
 Análisis de la información en un horizonte de tiempo, anual, trimestral, mensual,
semanal.
 Costo logístico por tonelada comercial [$/TM].
Indicadores.
 Entregas a tiempo.
Descripción: Este indicador representa las entregas a tiempo sobre el total de
entregas.
 Entregas completas.
Descripción: Este indicador representa las entregas completas sobre el total de
entregas.
 Tiempo de ciclo de pedido
Descripción: Media del valor de tiempo pasado desde que un cliente emite un pedido
hasta que lo recibe.
 Costo de transporte medio unitario.
Descripción: Costo total de transporte sobre el número de unidades movidas.
 Volumen por red de transporte x 100
 Volumen total expedido
 Utilización de transporte.
Descripción: Costo total de transporte por red sobre kilogramos totales movidos por
red.
 Costo por kilómetros.
Descripción: Costo total de trasporte sobre kilómetros totales recorridos.
Mencionada la información que le interesa a la parte directiva de logística, manifestaron

consultas para la visualización que se tomará en cuenta, los mismos que se especifican a
continuación:
Cantidad recibida de ítems por:
 Proveedor.
 Familia de ítem.
 Volúmenes.
 Tiempo de recepción
47
Cantidades despachadas de ítems por:
 Tipo de Cliente.
 Cliente
 Red de cliente.
 Zona de cliente.
 Familia de Ítem.
 Volúmenes.
Nivel de servicio:
 A tiempo.
 Completo.
 OTIF.
3.3 Diseño técnico de la arquitectura.

En el diseño de la arquitectura se definió dos ambientes, el primero es el Back Room y el
segundo que es Front Room, los mismos que serán detallados a continuación.
3.3.1 Back room

Los datos para la población del datawarehouse, serán extraídos del servidor de base de datos
SQL Server 2008 R2 de la empresa PRONACA y de hojas de Excel donde hay información
relevante para logística. El proceso ETL se lo realizará mediante la herramienta Microsoft
SQL Server Integration Services (SSIS), y el datawarehouse será alojado en el servidor de
base de datos de SQL Server.
Figura 3-1: Back Room – Proyecto

48
3.3.2 Front room
En esta sección se especifica la arquitectura de presentación del datawarehouse, mediante
aplicaciones dirigidas al usuario final.
Es parte del datawarehouse en donde se encuentra los datos que ya han sido tratados y
almacenados, posteriormente se procede a la presentación de acuerdo al tipo de aplicación
de usuario final que se utilice. Para el desarrollo del presente proyecto se implementará una
arquitectura de ambiente analítico para poder diseñar los cubos OLAP.
Figura 3-2: Front Room – Proyecto

3.4 Selección del producto.

Para la selección de los productos a utilizar se tomó en cuenta las características planteadas
anteriormente en el Capítulo I - Sección 4 sobre las Herramientas para el desarrollo de un
datawarehouse, con lo cual se planteó las siguientes herramientas a ser utilizadas en el
proyecto:
Plataforma DBMS.
La plataforma a utilizar es el motor de base de datos SQL Server 2008 R2 ya que la compañía
PRONACA cuenta con la licencia y su estructura de base de datos esta sobre esta plataforma.
Vale recalcar que este motor tiene incorporado la funcionalidad de la tecnología OLAP, por
lo que aparte de ser el motor de base de datos, será también un servidor o base de datos
OLAP.
Herramienta ETL.
En cuanto a la herramienta ETL se utilizó Microsoft SQL Server Integration Services (SSIS)
por su versatilidad y facilidad de su manejo.
49
Herramienta DW.
Para la construcción del cubo se utilizó Analysis Services por su facilidad en el manejo.
3.5 Identificar las dimensiones y mapear los datos.

3.5.1 Modelo dimensional
El modelo lógico para el departamento de logística de la compañía PRONACA, fue realizado
siguiendo el esquema de estrella que optimiza el tiempo de respuesta en consultas complejas,
siguiendo los pasos del modelo dimensional de Ralph Kimball.
Las dimensiones que hemos analizado en el departamento de logística son:
 DIMENSION_ARTICULO
 DIMENSION_CLIENTE
 DIMENSION_VEHICULOSP
 DIMENSION_PROVEEDOR
 DIMENSION_TIPOMOVIMIENTO
 DIMENSION_TIEMPO
 DIMENSION_RUTA
 DIMENSION_REDTRANSPORTE
 DIMENSION_COMPAÑIATRANS
 HECHO_GESTIONLOG_MP
 HECHO_GESTIONLOG_PT
 HECHO_NIVELSERVICIO
50
Tabla 3-1: Mapeo de datos Dimensión Artículo
Nombre de la Tabla: DIMENSION_ARTICULO
3.5.1.1 Dimensión artículo.
Tipo de Tabla: DIMENSION

Tablas Origen: ARTICULOS, AUXILIAR_ARTICULOS
DESTINO ORIGEN
Nombre Columna Descripción Tipo de Dato/Tamaño Clave Sistema/Tabla Campo Origen Tipo de Dato/Tamaño
ID_ARTICULO Clave primaria Subrogada int Primaria Sistema ETL
mismos están clasificados por tipo y especie.
CODIGO_ARTICULO código del articulo char(10) articulos código char(10)
51
NOMBRE_ARTICULO Descripción del articulo varchar(50) articulos titulo varchar(50)
PRESENTACION_ARTICULO Peso en kg por unidad nvarchar(4) auxiliar_articulos presentación nvarchar(255)
Clasificación de la especie de
ESPECIE_ARTICULO animales nvarchar(10) auxiliar_articulos especie nvarchar(255)
TIPO_ARTICULO Tipo de Articulo nvarchar(10) auxiliar_articulos tipo nvarchar(255)
NEGOCIO_ARTICULO Calcificación de negocio nvarchar(15) auxiliar_articulos negocio nvarchar(255)
Fuente: Proyecto DW.

Contiene la información acerca de los artículos que maneja el departamento de logística, los
Tabla 3-2: Mapeo de datos Dimensión Cliente
Nombre de la Tabla: DIMENSION_CLIENTE
3.5.1.2 Dimensión cliente.

Tablas Origen: CLIENTES, AUXILIAR_ZONACLIENTE
DESTINO ORIGEN
ID_CLIENTE Clave primaria subrogada int Primaria Sistema ETL
CODIGO_CLIENTE Codigo Cliente varchar(6) clientes codcli varchar(6)
52
NOMBRE_CLIENTE Nombre Cliente varchar(100) clientes nomcli varchar(100)
DIRECCION_CLIENTE Direccion del Cliente nvarchar(100) clientes dircli nvarchar(100)
Clacificacion del Cliengte por
TIPO_CLIENTE tipo char(20) clientes tipocli char(20)
Zona de ubicación de los
ZONA_CLIENTE Clientes. nvarchar(15) auxiliar_zonacliente zona nvarchar(255)

categorías, que son: Clientes relacionados, Clientes Integrados, Clientes Comerciales.
Contiene información de clientes atendidos por logística, estos se clasifican en tres
Tabla 3-3: Mapeo de datos Dimensión proveedor
Nombre de la Tabla: DIMENSION_PROVEEDOR
3.5.1.3 Dimensión proveedor.
Tablas Origen: PROVEEDOR, ALMACENES
DESTINO ORIGEN
ID_PROVEEDOR Clave primaria subrogada int Primaria Sistema ETL
53
CODIGO_PROVEEDOR Código Proveedor char(6) Sistema ETL código varchar(6)
NOMBRE_PROVEEDOR Nombre Proveedor varchar(100) Sistema ETL nombrep varchar(100)
Dirección Proveedor
DIRECCION_PROVEEDOR varchar(100) Sistema ETL direcp nvarchar(100)
Clasificación de Proveedor
TIPO_PROVEEDOR por tipo char(10) Sistema ETL tipo_proveedor char(20)

proveedor: Almacenes (propios de la empresa), Proveedores (Ajenos a la empresa)
Contiene información de proveedores de materia prima, este se clasifica por tipo de
Tabla 3-4: Mapeo de datos Dimensión Tipomovimiento
Nombre de la Tabla: DIMENSION_TIPOMOVIMIENTO
Tablas Origen: PESAJE
3.5.1.4 Dimensión Tipo Movimiento.
DESTINO ORIGEN
54
ID_MOVIMIENTO Clave primaria subrogada int Primaria Sistema ETL
CODIGO_MOVIMIENTO Código movimiento nvarchar(2) pesaje codigo_mov decimal(11,6)
TIPO_MOVIMIENTO Clasificacion movimientos nvarchar(20) Sistema ETL tipo_mov varchar(100)
DETALLE_MOVIMIENTOClase de tipo movimiento nvarchar(30) Sistema ETL Clase_mov varchar(100)

transacciones de Logística, se clasifican por: Abastecimiento, Distribución.
Contiene información de los diferentes Tipos de Movimientos realizados en las
integrados, relacionados.
Tabla 3-5: Mapeo de datos Dimensión redtransporte

Nombre de la Tabla: DIMENSION_REDTRANSPORTE
Tablas Origen: DETALLE_PESAJE
3.5.1.5 Dimensión red de distribución.
DESTINO ORIGEN
55
ID_REDTRANS Clave primaria subrogada int Primaria Sistema ETL
CODIGO_REDTRANS codigo red transporte char(4) detalle_pesaje codred char(4)
DESCRIPCION_REDTRANS
descripcion red de transporte cahr(15) Sistema ETL

Contiene información de las diferentes redes de distribución manejadas en logística, se
clasificad por: Red primaria, red secundaria, red comercial, materia prima, red de granjas,
Logística.
Tabla 3-6: Mapeo de datos Dimensión compañiatrans

Nombre de la Tabla: DIMENSION_COMPAÑIATRANS
3.5.1.6 Dimensión Compañía.
Tablas Origen: PROPITRAN
DESTINO ORIGEN
ID_COMPAÑIATRANS Clave primaria subrogada int Primaria Sistema ETL
Código compañía transporte
CODIGO_COMPAÑIATRANS char(6) propitran Codigopv char(6)
56
Nombre de la compañía
transporte
NOMBRE COMPAÑIATRANS char(35) propitran propieta char(35)
Dirección compañía de
DIR_COMPAÑIATRANS transporte char(35) propitran direccionp char(35)
Telefonos de la diferentes
compañias
TELEFONO_COMPAÑIATRANS char(9) propitran telefonop char(9)

Contiene información de las diferentes compañías de transporte que prestan servicios a
Contiene la placa del vehículo.
Tabla 3-7: Mapeo de datos Dimensión vehículo

3.5.1.7 Dimensión Vehículos.
Nombre de la Tabla: DIMENSION_VEHICULO

Tablas Origen: VEHICULOS
DESTINO ORIGEN
57
ID_VEHICULO Clave primaria subrogada int Primaria Sistema ETL Clave primaria sobrogada
int
PLACA_VEHICULO codigo vehiculo char(7) vehiculos placa char(7)

3.5.1.8 Dimensión Tiempo.
Contiene la Información acerca del horizonte de tiempo de las actividades de logística, esta
dimensión es elaborada con un procedimiento almacenado.
Tabla 3-8: Mapeo de datos Dimensión Tiempo
Nombre de la Tabla: DIMENSION TIEMPO
Tablas Origen: Procedimiento para crear tabla tiempo
Nombre Columna Descripción Tipo de Dato/Tamaño Clave

FechaSK Clave primaria subrogada int
Fecha Clave primaria date Primaria
Año Año de fecha smallint
Nmes Nombre del mes Char(15)
Nsemana Nombre de la semana Char(10)
Ndiasemana Nombre del día de la semana Char(10)

3.5.2 Identificar los hechos

Los hechos a definir soportarán los requerimientos establecidos cumpliendo con la
granularidad especificada para cada negocio. El mapeo de los datos será especificado en
cada hecho.
En el desarrollo del datawarehouse se definirán hechos referentes a las transacciones que se
realicen de acuerdo al negocio.
Los hechos tendrán dimensiones en común así como también dimensiones específicas para
el negocio.
3.5.2.1 Identificar las medidas.
Las medidas que se implementan en los hechos cumplen con el detalle de granularidad que
se especificaron anteriormente.
Tabla 3-9: Medidas tabla de hecho gestión logística

Medida Detalle
Kilos Especifica los kg movidos
km recorridos km recorridos en rutas especificas
diferencias peso kg encontrados como diferencias de peso de un punto a otro
valor flete Valor del flete según su ruta y TM transportadas
58
Tabla 3-10 : Medidas tabla de hecho Nivel de Servicio
Medida Detalle
Insuficiencia Pedidos no entregados
Cumplimiento % cumplimiento de pedidos
A tiempo % cumplimiento de pedidos en la fecha programada
OTIF Pedidos entregados a tiempo y completos

3.5.2.2 Abastecimiento y distribución de producto terminado

Contiene los indicadores (medidas) de las transacciones de abastecimiento y distribución de
producto terminado, PT recibidos desde otros almacenes pertenecientes al mismo negocio y
la distribución de los mismos a nuestros clientes, además se especifican las claves foráneas
que permite relacionar con las dimensiones.
59
Tabla 3-11: Mapeo de datos tabla de hecho gestionlog_PT
Nombre de la Tabla: HECHO_GESTIONLOG_PT
Tipo de Tabla: HECHO
PESAJE, DIMENSION_ARTICULO, DIMENSION_VEHICULO, DIMENSION_COMPAÑIATRANS, DIMENSION_PROVEEDOR, DIMENSION_RUTA,
Tablas Origen: DIMENSION_TIEMPO, VALORTRA
DESTINO ORIGEN
ID_DISTRIBUCION Clave primaria subrogada int Primaria Sistema ETL
Clave foranea de la dimensión
ID_VEHICULO VEHICULO int Primaria foranea DIMENSION_VEHICULO ID_VEHICULO INT
ID_COMPAÑIATRANS COMPAÑIATRANS int Primaria foranea DIMENSION_COMPAÑIATRANS ID_COMPAÑIATRANS INT
ID_ARTICULO ARTICULO int Primaria foranea DIMENSION_ARTICULO ID_ARTICULO INT
ID_PROVEEDOR PROVEEDOR int Primaria foranea DIMENSION_PROVEEDOR ID_PROVEEDOR INT
60
ID_CLIENTE CLIENTE int Primaria foranea DIMENSION_CLIENTE ID_CLIENTE INT
ID_MOVIMIENTO TIPOMOVIMIENTO int Primaria foranea DIMENSION_MOVIMIENTO ID_MOVIMIENTO INT
Calve foranea de la dimension
ID_RUTA RUTA int Primaria foranea DIMENSION_RUTA ID_RUTA INT
ID_FECHA TIEMPO date Primaria foranea DIMENSION_FECHA ID_FECHA INT
ID_REDTRANS REDTRANS int Primaria foranea DIMENSION_REDTRANSPORTE ID_REDTRANS INT
KILOS Kilos despachados decimal(15,2) pesaje pesokilos decimal (15,4)
Diferencia de kg entre peso enviado
DIFERENCIA_PESO y recibido decimal(9,2) pesaje diferencia decimal (9,2)
VALOR_FLETE Valor flete decimal(11,2) pesaje netotrans decimal (11,2)
KMS_RECORRIDO Kilometros recorridos por ruta decimal(5,0) valortra kmsvt decimal (5,2)

DIAGRAMA GESTIÓN LOGÍSTICA DE PRODUCTO TERMINADO.
Figura 3-3: Diseño físico tabla de hecho abastecimiento y distribución de PT.

3.5.2.3 Abastecimiento de materia prima

Contiene los indicadores (medidas) de las transacciones de abastecimiento y distribución de
materia prima que se recibe de los diferentes proveedores y almacenes propios del negocio,
además distribución de MP a otras plantas, y las claves foráneas que permite relacionar con
las dimensiones.
61
Tabla 3-12: Mapeo de datos tabla de hecho gestionlog MP.
Nombre de la Tabla: HECHO_GESTIONLOG_MP
PESAJE, DIMENSION_ARTICULO, DIMENSION_CLIENTE, DIMENSION_VEHICULO, DIMENSION_COMPAÑIATRANS, DIMENSION_PROVEEDOR,
Tablas Origen: DIMENSION_RUTA, DIMENSION_REDTRANS, DIMENSION_TIEMPO, VALORTRA
DESTINO ORIGEN
ID_GESTIONLOG Clave primaria subrogada INT Primaria Sistema ETL
ID_VEHICULO VEHICULO INT Primaria foranea DIMENSION_VEHICULO ID_VEHICULO INT
ID_COMPAÑIATRANS COMPAÑIATRANS INT Primaria foranea DIMENSION_COMPAÑIATRANS ID_COMPAÑIATRANS INT
ID_ARTICULO ARTICULO INT Primaria foranea DIMENSION_ARTICULO ID_ARTICULO INT
ID_PROVEEDOR PROVEEDOR INT Primaria foranea DIMENSION_PROVEEDOR ID_PROVEEDOR INT
62
ID_CLIENTE CLIENTE INT Primaria foranea DIMENSION_CLIENTE ID_CLIENTE INT
ID-MOVIMIENTO TIPOMOVIMIENTO INT Primaria foranea DIMENSION_MOVIMIENTO ID_MOVIMIENTO INT
ID_RUTA RUTA INT Primaria foranea DIMENSION_RUTA ID_RUTA INT
ID_FECHA TIEMPO date Primaria foranea DIMENSION_TIEMPO fecha date
ID_REDTRANS REDTRANS INT Primaria foranea DIMENSION_REDTRANSPORTE ID_REDTRANS INT
KILOS Kilos despachados decimal(15,2) pesaje pesokilos decimal (15,2)
Diferencia de kg entre peso enviado
DIFERENCIA_PESO y recibido decimal(9,2) pesaje diferencia decimal (9,2)
VALOR_FLETE Valor flete decimal(11,2) pesaje netotrans decimal (11,2)
KMS_RECORRIDO Kilometros recorridos por ruta decimal(5,0) valortra kmsvt decimal (5,2)

DIAGRAMA GESTIÓN LOGÍSTICA MATERIA PRIMA
Figura 3-4: Diseño físico tabla de hecho gestión logística MP

3.5.2.4 Nivel de servicio OTIF.

Contiene los indicadores que miden el nivel de servicio gestionado por el departamento de
logística.
63
Tabla 3-13: Mapeo de datos tabla de hecho nivelservicio
Nombre de la Tabla: HECHO_NIVELSERVICIO
Tablas Origen: TABLAS DE EXCEL BASE_PEDIDOS_M12, DIMENSION_ARTICULO, DIMENSION_CLIENTE, DIMENSION_TIEMPO
DESTINO ORIGEN
ID_SERVICIO Clave primaria subrogada INT Primaria Sistema ETL
ID_CLIENTE CLIENTE INT Primaria foranea DIMENSION_CLIENTE ID_CLIENTE INT
64
ID_ARTICULO ARTICULO INT Primaria foranea DIMENSION_ARTICULO ID_ARTICULO INT
ID_FECHA TIEMPO date Primaria foranea DIMENSION_TIEMPO fecha date
INSUFICIENCIA Kilos no despachados float BASE_PEDIDOS_M12 Sistema ETL numerico
CUMPLIMIENTO Pedidos entregados float BASE_PEDIDOS_M12 Sistema ETL numerico
A_TIEMPO Fecha de pedido cumplido a tiempo float BASE_PEDIDOS_M12 Sistema ETL numerico
OTIF Kilometros recorridos por ruta float BASE_PEDIDOS_M12 Sistema ETL numerico

3.5.3 Datawarehouse busmatrix
Tabla 3-14: Bus Matrix DW.

Dimensiones Comunes
Compañía Transporte
Movimiento
Proveedor
Recorrido
Vehículo
Articulo
Tiempo
Cliente
Red
Proceso de Negocio Tabla de hecho Granularidad
GestionLog_MP Un registro por cada movimiento X X X X X X X X X
Gestion Logistica
GestionLog_PT Un registro por cada movimiento X X X X X X X X X
Pecuaria
Nivel de servicio Un registro por cada movimiento X X X

3.6 Diseño físico.

El diseño físico se realizó en función a la base de datos ya mencionada, SQLServer 2008
R2.
 Base de datos temporal.
Se diseña una base de dato temporal, donde se incorpora las tablas con los datos
tratados necesarios de las bases de datos y de tablas de Excel, para la elaboración del
datawarehouse, esta DDB se denomina Mantenimiento DW.
 Base de datos temporal con estructura de datawarehouse.
Se diseña una base de datos temporal con estructura de un datawarehouse, donde se
incorpora los datos ya tratados desde su origen.
 Índices.
Se configura los índices en las diferentes dimensiones y tablas de hecho con la
finalidad de mejorar la velocidad de búsqueda, el tipo de índice que se utilizo es el
NO AGRUPADO (NONCLUSTERED).
Sintaxis:
CREATE NONCLUSTERED INDEX NOMBRE
ON TABLA (CAMPO INDEXADO)
3.6.1 Base de datos origen

Primero se empezará especificado los scripts de creación para la base de datos origen, lo que
permitirá llevar a cabo la técnica de extracción CDC (Change Data Capture) la misma que
65
será explicada en el diseño ETL para su mayor entendimiento así como de la funcionalidad
que aportará.
3.7 Diseño y desarrollo del proceso ETL.

Desarrollo del plan ETL.
A continuación se elaborará un mapa gráfico del funcionamiento ETL de cada una de las
dimensiones y tabas de hecho, el cual permitirá tener una mayor idea de cómo se ejecutará
el proceso ETL.
3.7.1 Paso 1: Trazar un plan de alto nivel.

En este paso se diseña diagramas de flujo de cada dimensión y tabla de hecho para entender
el funcionamiento del proceso ETL,
Revisar Anexo 4. Diagrama de flujo del funcionamiento del ETL por cada dimensión
y tablas de hecho.
3.7.2 Paso 2: Funcionalidad de la herramienta ETL

Se renombro este paso en función a que ya se especificó la herramienta ETL a utilizar por lo
que a continuación se detallará las funcionalidades a utilizar.
Para la elaboración de los procesos ETL se utilizará dos herramientas del Sofware ETL de
Microsoft SQL Server 2008. Estas son:
 Integration Services, que va a permitir diseñar las transformaciones y trabajos de
manera gráfica y amigable.
 Agente SQL Server, permiten ejecutar el proceso ETL periódicamente mediante
Jobs, tareas programadas con periodo de tiempo.
3.7.3 Paso 3: Desarrollar estrategias por defecto.

Para elaborar el proceso ETL se diseñó dos bases de datos:
 Base de datos Mantenimiento DW.- Esta es una DDB temporal, donde cargamos
los datos necesarios para la elaboración del datawarehouse, extraemos los datos
desde la DDB origen denominada Almacen_M12, los datos son transferidos por
medio de un paquete (Extrae_datos), creado en un proyecto SSIS denominado
Proceso_ETL.
66
Diagrama tabla temporal (Mantenimiento DW).
Figura 3-5: Diagrama tabla temporal Mantanimiento_DW

 Base de datos DW_PRONACA.- Esta DDB se diseña con estructura de un

datawarehouse, en esta etapa cargamos los datos provenientes de la DDB
Mantenimiento_DW que ya fueron previamente tratados, además incorporamos las
claves foráneas, aquí ya encontramos el diagrama de los diferentes cubos como son:
Figura 3-6: Estructura diagramas de base de datos temporal.

67
Diagrama GestionLog_PT
Figura 3-7: Diagrama gestiónlog_PT

Diagrama GestionLog_MP
Figura 3-8: Diagrama GestionLog_MP

68
Diagrama NivelServicio.
Figura 3-9: Diagrama NivelServicio.

3.7.3.1 Proyecto SSIS en Integration Services.

Se diseña un proyecto SSIS denominado Proceso_ETL, aquí creamos cuatro paquetes para
realizar el ETL, se denominan de la siguiente manera:
Figura 3-10: Esquema paquetes SSIS

Elaboración: Freddy Jaramillo
Mayor detalle se explica en el Anexo 2 denominado Manual de implementación de un

proyecto SSIS en Integration Services proceso ETL.
3.7.4 Paso 4: Poblar las tablas de dimensión con los datos.

En este paso ejecutamos el ETL para cargar los datos desde las DDB origen hacia los
diferentes cubos, esto se lo realiza por medio del proyecto SSIS que ya se mencionó en el
paso anterior. Mayor detalle en el Anexo 3. Manual técnico carga de datos por medio del
proceso ETL.
69
3.7.4.1 Extracción de Datos.
La extracción de los datos se lo realizará mediante sentencias SQL a las tablas de la base
origen. Como resultado devolverá todos los registros de acuerdo a la tabla consultada debido
a que es el proceso de carga inicia.
3.7.4.2 Transformación de Datos.
Los datos antes de ser cargados en el almacén serán transformados según lo requieran, para
lo cual se especificó ciertas transformaciones que se mencionan a continuación de acuerdo
a cada dimensión, los datos a las tablas de hecho se cargan por medio de procedimientos
almacenados.
3.7.4.3 Carga de datos.
Los datos ya tratados procedemos a cargarlos por medio de una tarea de procesamiento de
Analysis Services.
Figura 3-11: Carga datos hacia el cubo.

3.7.5 Paso 5: Poblar las tablas de hecho con datos.

En este paso ejecutamos el ETL para cargar los datos desde las DDB origen hacia los
diferentes cubos, esto se lo realiza por medio del proyecto SSIS que ya se mencionó en el
paso anterior, específicamente se llama procedimientos almacenados. Mayor detalle en el
Anexo 3. Manual técnico carga de datos por medio del proceso ETL.
70
3.8 Implementación de cubo.
Después de realizar el proceso de ETL y una vez que el datawarehouse ya contiene los datos
se procede a la construcción y publicación de los cubos con la herramienta Analysis Services
para el análisis OLAP. Para el caso práctico se presenta en resumen el procedimiento para
la creación y publicación de un cubo, el Anexo 5, detalla cada uno de los pasos que a
continuación se enumeran:
1. Creación de conexión.- Antes de crear un cubo se debe crear la conexión a la base de
datos de donde se va extraer la información.
2. Creación de vistas de origen de datos.- Se crea un esquema de vista de origen de datos
que es la base para la creación del cubo.
3. Creación de cubos.- Se procede con la creación de los cubos.
4. Creación de dimensiones.- Añadir las dimensiones de acuerdo al diseño del cubo.
5. Creación de jerarquías.- Al momento de la creación de los cubos se debe configurara
las jerarquías, normalmente la jerarquías se configuran a las dimensiones de tiempo,
geográficas etc.
6. Creación de medidas.- Añadir medidas en los cubos de información de acuerdo al
requerimiento.
Figura 3-12: Cubo OLAP en Analysis Services

3.9 Visualización de datos.

Para visualizar los datos, hemos utilizado Microsoft Excel donde se crea las conexiones
OLAP hacia los diferentes cubos. Revisar el Anexo 6. Creando conexión OLAP desde
Microsoft Excel a SQL Server de Analysis Services.
71
Figura 3-13: Menú visualización de datos del cubo OLAP.
3.9.1 Tablero de control distribución de PT.

En este tablero de control podeos visualizar información clasificados por tipo de negocio,
especie, y zona de clientes; contar con estos dato actualizados y comparado en el tiempo nos
ayuda en la toma de decisiones sobre la administración de nuestros recursos (medio de
transporte, capacidad de bodegas, recurso humano).
Figura 3-14: TC – Distribución de producto terminado.

72
3.9.2 Tablero de control abastecimiento de materia prima
En este tablero de control podemos visualizar TM de materias primas abastecidas a la planta
de producción, conocer esta información nos permite administrar nuestros recursos
(transporte, productividad logística).
Figura 3-15: TC TM abastecidas de MP.

3.9.3 Nivel de servicio OTIF
El OTIF es un indicador de desempeño de la industria logística que refleja el porcentaje de
despachos que llegan a tiempo (On Time), con el producto y cantidad solicitados, y al lugar
indicado por el cliente (In Full). En el caso de grandes empresas intensivas en procesos
logísticos y recepciones de despachos, como una gran tienda o un hipermercado, resulta
imperativo que este índice sea superior al 90%.
Figura 3-16: TC Nivel de Servicio OTIF.

73
CONCLUSIONES.
La implementación de un datawarehouse con alcance para la gestión logística, generó

información analítica dentro de un nivel organizacional táctico – operativo, producto de los
requerimientos de directivos del negocio.
Para el desarrollo del datawarehouse fue indispensable contar con el apoyo tanto del área de
informática, los cuales brindan el soporte tecnológico, así como del área referente al negocio
con el fin de evaluar en conjunto las necesidades, y ser ente activo durante todas las etapas
de desarrollo.
En el diseño del modelamiento dimensional, es importante identificar el nivel de detalle o

granularidad hasta el que va llegar el análisis, esto permite realizar diseños que lo soporte, y
que garantice la integridad de datos durante el proceso ETL.
La importancia de entender cómo se evidencia el negocio en los sistemas transaccionales,

como son las bases de datos es fundamental, puesto que ayuda a tener mejor visión sobre los
datos y permitir seleccionar los adecuados para el análisis de la información, después que
hayan sido integrados por medio del proceso ETL.
74
RECOMENDACIONES.
Se recomienda como alcance para los desarrollos futuros del datawarehouse, trabajar en
conjunto con las TIC y las diferentes regiones, con el fin de visionar y conformar indicadores
representativos, que sean objeto de medición dentro del negocio logístico al nivel nacional.
Es recomendable contar con el apoyo técnico del área informática y del departamento
logístico, con el fin de recoger adecuadamente las necesidades, y que las mismas sean
reflejadas en el diseño del datawarehouse.
Se recomienda tomar en cuenta la granularidad con el fin de determinar técnicamente, como

obtener los datos de las fuentes, integrarlos y sin que esto modifique la relación de los
mismos cuando se encuentren en el ambiente de datawarehouse.
Se recomienda llevar a cabo un estudio del negocio y de la veracidad de fuentes de datos que
lo respalda, con el fin de sustentar un origen de calidad para la integración de datos.
75
BIBLIOGRAFÍA.
 BCE. (julio de 2015). Banco Central del Ecuador. Obtenido de

https://www.bce.fin.ec/
 Bernabeu, R. D. (2010). Data warehousing: Investigación y Sistematización de
Conceptos – Hefesto: Metodología propia para la Construcción de un Data
Warehouse. Cordova - Argentina.
 Cano, J. L. (2007). Business Intelligence.
 Casanovas, A., & Cuatrecasas, l. (2003). Logistica Empresarial: Gestión Integral de
la información y material en la empresa. Barcelona: Ediciones Gestión 2000 SA.
 Días, J., & Cnesa, J. (2010). Introducción a Business Intelligence. Barcelon, España:
UOC.
 Duque Galvez, A. (abril de 2010). Tesis: IMPLEMENTACIÓN DE UN
DATAWAREHOUSE PARA EL INSTITUTO GEOGRÁFICO MILITAR.
Sangolqui-Quito, Pichincha, Ecuador.
 Espinosa, R. (28 de novimbre de 2009). El Rincon del Business Intelligense.
Obtenido de https://churriwifi.wordpress.com/2009/11/
 Espinosa, R. (25 de febrero de 2010). DATAPRIX. Obtenido de
http://www.dataprix.com/blogs/respinosamilla/qu-business-intelligence
 Fernandez, C. (22 de julio de 2009). Dataprix. Obtenido de de
http://www.dataprix.com/arquitectura-data-warehouse-areas-datos-nuestro-
almacen- corporativo
 Ferrer Mos, S. (12 de Febrero de 2015). www.Pertutatis.cat. Obtenido de Per
Tutatis!: http://pertutatis.cat/la-piramide-de-los-diferentes-tipos-de-sistemas-de-
informacion/
 Gauchet, T. (2011). SQL Server 2008 R2: Implementación y despliegue de una
solución de Business Intelligence. Barcelona: ENI.
 Gomez, R. (abril de 2010).
http://revistas.utp.edu.co/index.php/revistaciencia/article/view/1803.
 INEC. (julio de 2015). Instituto Ecuatoriano de Estadisticas y Censos. Obtenido de
http://www.inec.gob.ec/estadisticas/
 INEI. (1997). Obtenido de
http://www.ongei.gob.pe/publica/metodologias/Lib5084/14.HTM
 Kimball, R. (2008). The DataWarehouse Lifecycle Toolkit, segunda edision.
 Lapiedra Almaí, R., Devece Carañana , C., & Guiral Herrando, J. (2011).
Introducción a la gestión de sistemas de información en la empresa.
 Leon, M. (22 de febrero de 2014). Obtenido de
http://luisleonin.blogspot.com/2014/02/modelado-dimensional-y-data-
warehouse.html
 Logistec. (2014). Business Intelligence: Mejorando la eficiencia en la cadena de
valores. Logistec, http://www.revistalogistec.com/index.php/supply-chain-
management/380-estrategia-logistica/1528-business-intelligence-mejorando-la-
eficiencia-de-la-cadena-de-valor. Obtenido de
http://www.revistalogistec.com/index.php/supply-chain-management/380-
estrategia-logistica/1528-business-intelligence-mejorando-la-eficiencia-de-la-
cadena-de-valor
 Mendoza Rivera, R. (7 de febrero de 2008). In SlideShare. Obtenido de
http://es.slideshare.net/rimenri/business-inteligence-ms-sql-server
 Mendoza, M., Cobos, C., Acosta, L., Gomez Florez, L., & Muñoz, J. (2006). Bodega
de datos y OLAP en Unicauca Virtual. Revista de la facultad de ingenierías físico
mecánicas, 4.
 Microsoft. (2014). Microsoft Developer Network. Obtenido de
https://msdn.microsoft.com/es-es/library/ms141026.aspx
 Nima Ramos, J. D. (2009). Soluciones OLAP con Microsoft SQL Server Analysis
Services.
 Puerta Gálvez, A. (2015). Business Intelligence y la tecnologia de la informacion. IT
Campus Academy.
 Rojas, C., & Duque, A. (abril de 2010). Repositorio digital ESPE. Obtenido de
http://repositorio.espe.edu.ec/handle/21000/336
 Sanches, G. (8 de abril de 2012). McGud II. Obtenido de
http://gusmc.wikispaces.com/1.2+Bases+de+datos+multidimensionales+%28BDM
%29
 Tesler, J. (10 de octubre de 2010). É Logistica. Obtenido de
http://www.logisticamx.enfasis.com/notas/15627-la-tecnologia-como-soporte-la-
actividad-logistica
 Turban, E. (1995). Decision support and expert systems: management support
systems. Englewood Cliffs: Prentice Hall.
 Urquizu, P. (16 de junio de 2009). Business Intelligense facil. Obtenido de
http://www.businessintelligence.info/serie-dwh/claves-subrogadas.html
ANEXOS
ANEXO 1- Modelo de la encuesta dirigido a los colaboradores del departamento de
logística.
1. ¿Conoce usted que es un sistema de datawarehouse y para qué sirve?

___Si ___No
2. ¿Ud. necesita tener información puntual para la tomar decisiones?

___Si ___No
3. ¿Los reportes obtenidos de sistemas informáticos son rápidos?

___Nunca ___ Algunas veces ___Casi siempre ___Siempre
4. ¿De los reportes obtenidos siempre encuentras la totalidad de los datos que necesitas?
5. ¿Puedes obtener reporte histórico de los sistemas informáticos?

___SI ___No
6. ¿Te gustaría tener la información en el momento oportuno?

___SI ___No
7. ¿Cree usted que mejoraría el desempeño en su puesto de trabajo con las estadísticas de la
gestión logística que se obtendría del datawarehouse?
___ Si ___ No ___Tal vez
8. ¿Frecuente mente obtiene reportes de los SI?

ANEXO 2 Manual de implementación de un proyecto SSIS en Integration Services
proceso ETL.
Creamos un nuevo proyecto en Integration services, le damos el nombre de Proceso_ ETL
Creamos conexión a origen de datos.
Creamos las vistas de origen de datos donde incorporamos todas las tablas requeridas, en
este caso creamos dos vistas denominadas de la siguiente manera:
Diseño de la vista Abast_Dist_PT, dentro de estas vistas anexaremos los Query
correspondientes que será el proceso mediante el cual trataremos los datos desde su origen.
Script extracción de datos tabla pesaje.

Con este script extraemos los datos necesarios desde la BDD de origen, también son tratados
y depurados, para ser cargados a la BDD temporal denominada Mantenimiento_DW. En la
tabla DETLLE_PESAJE_PT
SELECT
CASE WHEN ROW_NUMBER() OVER (PARTITION BY ticketpeso
ORDER BY ticketpeso) = 1 THEN 1 ELSE 0 END num_transaccion, dbo.pesaje.ticketpeso,
dbo.pesaje.placast,
CAST(CASE
WHEN codigopv = 'tr0000' THEN REPLACE(codigopv, 'TR0000', 'TR0157')
WHEN codigopv = 'TR0026' THEN REPLACE(codigopv, 'TR0026', 'TR1709')
ELSE codigopv
END AS NVARCHAR(6)) AS COD_COMPAÑIA,dbo.pesaje.codigo, dbo.pesaje.codigod,
dbo.pesaje.codigovt, dbo.pesaje.codigop, dbo.pesaje.pesoartic, dbo.pesaje.fechasale,
dbo.pesaje.pesosalida,
CASE
WHEN (codigopv = 'TR0157' OR
codigopv = 'tr0000' OR
codigopv = 'pm0198' OR
codigopv = 'tr0685') AND (codigod LIKE '80%') AND pesoartic = 2 THEN 0
ELSE netotrans
END AS netotrans, dbo.pesaje.cantsacos, dbo.pesaje.presentac, dbo.pesaje.pesokilos,
dbo.pesaje.diferencia,
CASE
WHEN (codigop = 'M11' OR
codigop = 'M13' OR
codigop = 'M31' OR
codigop = 'M88' OR
codigop = 'M89') AND (pesoartic = 4) AND codigo LIKE 'T%' THEN '01'
WHEN (codigopv = 'tr0487' OR
codigopv = 'tr1495') AND (codigod LIKE '80%') AND pesoartic = 2 AND codigo LIKE 'T%' THEN
'02'
WHEN (codigod LIKE '0IN%' OR
codigod LIKE '2IN%') AND pesoartic = 2 AND codigo LIKE 'T%' THEN '04'
WHEN codigod LIKE 'M86%' AND pesoartic = 3 AND codigo LIKE 'T%' THEN '05'
WHEN codigod LIKE 'B%' AND pesoartic = 3 AND
codigo LIKE 'T%' THEN '06'
codigopv = 'tr0685') AND (codigod LIKE '80%') AND pesoartic = 2 AND codigo LIKE 'T%' THEN
'07'
WHEN codigop = 'M34' OR
codigop = 'M75' OR
codigop = 'M33' AND (codigo LIKE 'S%' OR
codigo LIKE 'VM%' OR
codigo LIKE 'MD%' OR
codigo LIKE 'QU%' OR
codigo LIKE '25%' OR
codigo LIKE '00%') AND pesoartic = 4 THEN '08'
WHEN codigod LIKE 'M%' AND pesoartic = 3 AND codigo LIKE 'T%' THEN '10'
ELSE '11'
END AS codred,
CASE
WHEN valortra.kmsvt IS NULL
THEN 0
ELSE valortra.kmsvt
END AS kmsvt
FROM dbo.pesaje FULL OUTER JOIN
dbo.valortra ON pesaje.CODIGOVT = VALORTRA.CODIGOVT
WHERE(dbo.pesaje.pesosalida <> 'N') AND (dbo.pesaje.pesoartic = 2 OR
dbo.pesaje.pesoartic = 3 OR
dbo.pesaje.pesoartic = 4) AND (dbo.pesaje.codigo <> '' AND pesokilos IS NOT NULL)
Script extracción de datos tabla histpesa.

y depurados, para ser cargados a la BDD temporal denominada Mantenimiento_DW en la
tabla DETALLE_PESAJE_PT.
SELECT
CASE
WHEN ROW_NUMBER() OVER (PARTITION BY ticketpeso
ORDER BY ticketpeso) = 1 THEN 1
ELSE 0
END num_transaccion, histpesa.ticketpeso, dbo.histpesa.placast,
CAST(CASE
WHEN codigopv = 'tr0000' THEN REPLACE(codigopv, 'tr0000', 'tr0157')
ELSE codigopv
END AS NVARCHAR(6)) AS COD_COMPAÑIA,dbo.histpesa.codigo, dbo.histpesa.codigod,
dbo.histpesa.codigovt, dbo.histpesa.codigop, dbo.histpesa.pesoartic, dbo.histpesa.fechasale,
dbo.histpesa.pesosalida,
CASE WHEN (codigopv = 'TR0157' OR
codigopv = 'tr0685') AND (codigod LIKE '80%') AND pesoartic = 2 THEN 0
ELSE netotrans
END AS netotrans, dbo.histpesa.cantsacos, dbo.histpesa.presentac, dbo.histpesa.pesokilos,
dbo.histpesa.diferencia,
CASE
WHEN (codigop = 'M11' OR
codigop = 'M13' OR
codigop = 'M31' OR
codigop = 'M88' OR
codigop = 'M89') AND (pesoartic = 4) AND codigo LIKE 'T%' THEN '01'
codigopv = 'tr1495') AND (codigod LIKE '80%') AND pesoartic = 2 AND codigo LIKE 'T%'
THEN '02'
WHEN (codigod LIKE '0IN%' OR
codigod LIKE '2IN%') AND pesoartic = 2 AND codigo LIKE 'T%' THEN '04'
WHEN codigod LIKE 'M86%' AND pesoartic = 3 AND codigo LIKE 'T%' THEN '05'
WHEN codigod LIKE 'B%' AND pesoartic = 3 AND
codigo LIKE 'T%' THEN '06'
codigopv = 'tr0685') AND (codigod LIKE '80%') AND pesoartic = 2 AND codigo LIKE 'T%'
THEN '07'
WHEN codigop = 'M34' OR
codigop = 'M75' OR
codigop = 'M33' AND (codigo LIKE 'S%' OR
codigo LIKE 'VM%' OR
codigo LIKE 'MD%' OR
codigo LIKE 'QU%' OR
codigo LIKE '25%' OR
codigo LIKE '00%') AND pesoartic = '4' THEN '08'
WHEN codigod LIKE 'M%' AND codigo LIKE 'T%' AND pesoartic = 3 THEN '10'
ELSE '11'
END AS codred,
CASE
WHEN valortra.kmsvt IS NULL THEN 0
ELSE valortra.kmsvt
END AS kmsvt
FROM dbo.histpesa FULL OUTER JOIN dbo.valortra ON HISTPESA.CODIGOVT =
VALORTRA.CODIGOVT
WHERE(dbo.histpesa.pesosalida <> 'N') AND (dbo.histpesa.pesoartic = 2 OR
dbo.histpesa.pesoartic = 3 OR dbo.histpesa.pesoartic = 4) AND (dbo.histpesa.codigo <> '' AND pesokilos
IS NOT NULL)
Diseño de la vista Abastecimiento_MP
Script extracción de datos tabla histpesa.

tabla DETALLE_PESAJE_MP.
SELECT
CASE
ELSE 0
END num_transaccion, histpesa.ticketpeso, dbo.histpesa.placast,
CAST(CASE WHEN codigopv = 'tr0000' THEN REPLACE(codigopv,'tr0000','TR0157')
ELSE codigopv
END AS NVARCHAR(6)) AS COD_COMPAÑIA, dbo.histpesa.codigo, dbo.histpesa.codigod,
dbo.histpesa.codigovt,
dbo.histpesa.codigop, dbo.histpesa.pesoartic, dbo.histpesa.fechasale, dbo.histpesa.pesosalida,
CASE
codigopv = 'tr0685') THEN 0
ELSE netotrans
END AS netotrans, dbo.histpesa.cantsacos, dbo.histpesa.presentac, pesokilos,
dbo.histpesa.diferencia,
CASE
WHEN (pesoartic = 4 OR pesoartic = 6) THEN '01'
WHEN pesoartic = 1 THEN '03'
ELSE '11'
END AS codred,
CASE
ELSE valortra.kmsvt
END AS kmsvt
FROM dbo.histpesa FULL OUTER JOIN dbo.valortra ON HISTPESA.CODIGOVT =
VALORTRA.CODIGOVT
WHERE(dbo.histpesa.pesosalida <> 'N') AND (dbo.histpesa.pesoartic = 1 OR dbo.histpesa.pesoartic = 4 OR
dbo.histpesa.pesoartic = 6) AND (dbo.histpesa.codigo LIKE 'M%') AND
(dbo.histpesa.codigod = 'M12') AND (dbo.histpesa.codigop <> '' AND pesokilos IS NOT NULL)
Script extraccon de datos tabla pesaje

tabla DETALLE_PESAJE_MP.
SELECT
CASE
ELSE 0
END num_transaccion, dbo.pesaje.ticketpeso, dbo.pesaje.placast,
CAST(CASE
WHEN codigopv = 'tr0000' THEN REPLACE(codigopv, 'tr0000', 'TR0157')
ELSE codigopv
END AS NVARCHAR(6)) AS COD_COMPAÑIA, dbo.pesaje.codigo, dbo.pesaje.codigod,
dbo.pesaje.codigovt,
dbo.pesaje.codigop, dbo.pesaje.pesoartic, dbo.pesaje.fechasale, dbo.pesaje.pesosalida,
CASE
codigopv = 'tr0685') THEN 0
ELSE netotrans
END AS netotrans, dbo.pesaje.cantsacos, dbo.pesaje.presentac, pesokilos, dbo.pesaje.diferencia,
CASE
WHEN (pesoartic = 4 OR
pesoartic = 6) THEN '01'
WHEN pesoartic = 1 THEN '03'
ELSE '11'
END AS codred,
CASE
ELSE valortra.kmsvt
END AS kmsvt
FROM dbo.pesaje FULL OUTER JOIN dbo.valortra ON pesaje.CODIGOVT = VALORTRA.CODIGOVT
WHERE(dbo.pesaje.pesosalida <> 'N') AND (dbo.pesaje.pesoartic = 1 OR
dbo.pesaje.pesoartic = 4 OR dbo.pesaje.pesoartic = 6) AND (dbo.pesaje.codigo LIKE 'M%') AND
(dbo.pesaje.codigod = 'M12') AND (dbo.pesaje.codigop <> '' AND pesokilos IS NOT NULL)
 Procedimiento almacenado para crear la tabla tiempo.

create procedure Carga_Tiempo
as
begin
DECLARE @FechaDesde as smalldatetime, @FechaHasta as smalldatetime
DECLARE @FechaAAAAMMDD int
DECLARE @Año as smallint, @Trimestre char(2), @Mes smallint
DECLARE @Semana smallint, @Dia smallint, @DiaSemana smallint
DECLARE @NTrimestre char(7), @NMes char(15)
DECLARE @NMes3l char(3)
DECLARE @NSemana char(10), @NDia char(6), @NDiaSemana char(10)
SET DATEFORMAT dmy
SET DATEFIRST 1
BEGIN TRANSACTION
SELECT @FechaDesde = CAST('20100101' AS smalldatetime)
SELECT @FechaHasta = CAST(CAST(YEAR(GETDATE())+2 AS CHAR(4)) + '1231' AS
smalldatetime)
WHILE (@FechaDesde <= @FechaHasta) BEGIN

SELECT @FechaAAAAMMDD = YEAR(@FechaDesde)*10000+
MONTH(@FechaDesde)*100+
DATEPART(dd, @FechaDesde)
SELECT @Año = DATEPART(yy, @FechaDesde)
SELECT @Trimestre = DATEPART(qq, @FechaDesde)
SELECT @Mes = DATEPART(m, @FechaDesde)
SELECT @Semana = DATEPART(wk, @FechaDesde)
SELECT @Dia = RIGHT('0' + DATEPART(dd, @FechaDesde),2)
SELECT @DiaSemana = DATEPART(DW, @FechaDesde)
SELECT @NMes = DATENAME(mm, @FechaDesde)
SELECT @NMes3l = LEFT(@NMes, 3)
SELECT @NTrimestre = 'T' + CAST(@Trimestre as CHAR(1)) + '/' + RIGHT(@Año, 2)
SELECT @NSemana = 'Sem ' +CAST(@Semana AS CHAR(2)) + '/' +
RIGHT(RTRIM(CAST(@Año as CHAR(4))),2)
SELECT @NDia = CAST(@Dia as CHAR(2)) + ' ' + RTRIM(@NMes)
SELECT @NDiaSemana = DATENAME(dw, @FechaDesde)
INSERT INTO BI_Temporal.dbo.DIMENSION_TIEMPO
(
FechaSK,Fecha,Año,Trimestre,Mes,Semana,Dia,DiaSemana,NTrimestre,NMes,NMes3L,NSemana,NDi
a,NDiaSemana
) VALUES
(
@FechaAAAAMMDD,@FechaDesde,@Año,@Trimestre,@Mes,@Semana,@Dia,@DiaSemana,@
NTrimestre,@NMes,@NMes3l,@NSemana,@NDia,@NDiaSemana
)
SELECT @FechaDesde = DATEADD(DAY, 1, @FechaDesde)
END
COMMIT TRANSACTION
end
Go
Una vez listo nuestras vistas, continuamos con la creación de los paquetes SSIS, que es
donde se diseñan los flujos de datos con diferentes conexiones organizadas, en este proyecto
creamos cuatro paquetes que son:
Paquete Extrae_Datos..- En este paquete extraemos los datos desde la DDB origen
Almacen_M12, de cada una de las tablas necesarias, además incorporamos datos desde
tablas electrónicas de Excel son datos manejados por el departamento de logística.
 Flujo de control Extrae datos desde su origen.
Paquete Transforma_datos.- Con este paquete logramos incorporar datos a una DDB con
estructura de un datawarehouse, además incorporamos claves foráneas para mejorar el
rendimiento de búsqueda.
 Flujo de control Transforma datos.
Procedimientos almacenados para cargar datos a la DDB DW_PRONACA.

 Script Procedimiento almacenado CARGA_GESTIONLOG_MP.
create procedure CARGA_GESTIONLOG_MP
as
begin
insert into DW_PRONACA..HECHO_GESTIONLOG_MP
(
ID_VEHICULO,ID_COMPAÑIATRANS,ID_ARTICULO,ID_PROVEEDOR,ID_RUTA,ID_FECHA,I
D_REDTRANS,
ID_MOVIMIENTO,valor_flete,MERMAS,PESO_KILOS,KMS_RECORRIDO,CUENTA_REGISTRO
)
select
ID_VEHICULO,ID_COMPAÑIATRANS,ID_ARTICULO,ID_PROVEEDOR,ID_RUTA,COD_FECH
A,ID_REDTRANS,ID_MOVIMIENTO,
CASE
WHEN ID_COMPAÑIATRANS =4 AND NETO<>0 THEN 0
ELSE NETO
END AS NETO,
case
when diferencia < 0 then diferencia
else 0
end as DIFERENCIA,PESOKILOS,KMS_RECORRIDOS,CUENTA_REGISTRO
from Mantenimiento_DW..DETALLE_PESAJE_MP PE
inner join DIMENSION_VEHICULOS dv on pe.COD_PLACA=dv.PLACA_VEHICULO
inner join DIMENSION_COMPAÑIATRANS dco on
pe.COD_COMPAÑIA=dco.CODIGO_COMPAÑIATRANS
inner join DIMENSION_ARTICULO da on pe.COD_ARTICULO=da.COD_ARTICULO
inner join DIMENSION_PROVEEDOR pr on pe.COD_PROVEEDOR=PR.CODIGO_PROVEEDOR
inner join DIMENSION_TIPOMOVIMIENTO tm on
pe.COD_TIPOMOVIMIENTO=tm.CODIGO_MOVIMIENTO
inner join DIMENSION_TIEMPO dt on pe.COD_FECHA=dt.FECHA
inner join DIMENSION_RUTA rc on pe.COD_RUTA=rc.CODIGO_RUTA
inner join DIMENSION_REDTRANSPORTE rt on pe.COD_RED=rt.CODIGO_REDTRANS
end
go
 Script Procedimiento almacenado CARGA_GESTIONLOG_PT.

create procedure CARGA_GESTIONLOG_PT
as
begin
insert into DW_PRONACA..HECHO_GESTIONLOG_PT
(
ID_VEHICULO,ID_COMPAÑIATRANS,ID_ARTICULO,ID_CLIENTE,ID_PROVEEDOR,ID_RUT
A,ID_FECHA,
ID_REDTRANS,ID_MOVIMIENTO,valor_flete,MERMAS,PESO_KILOS,KMS_RECORRIDO,CUE
NTA_REGISTRO
)
select
ID_VEHICULO,ID_COMPAÑIATRANS,ID_ARTICULO,ID_CLIENTE,ID_PROVEEDOR,ID_RUT
A,COD_FECHA,ID_REDTRANS,ID_MOVIMIENTO,NETO,
case when diferencia < 0 then diferencia
else 0
end as DIFERENCIA,PESOKILOS as CANT_NETA,KMS_RECORRIDOS,CUENTA_REGISTRO
from Mantenimiento_DW..DETALLE_PESAJE_PT PE
inner join DIMENSION_VEHICULOS dv on pe.COD_PLACA=dv.PLACA_VEHICULO
inner join DIMENSION_COMPAÑIATRANS dco on
pe.COD_COMPAÑIA=dco.CODIGO_COMPAÑIATRANS
inner join DIMENSION_ARTICULO da on pe.COD_ARTICULO=da.COD_ARTICULO
inner join DIMENSION_PROVEEDOR pr on pe.COD_PROVEEDOR=PR.CODIGO_PROVEEDOR
inner join DIMENSION_CLIENTE dc on pe.COD_CLIENTE=dc.CODIGO_CLIENTE
inner join DIMENSION_TIPOMOVIMIENTO tm on
pe.COD_TIPOMOVIMIENTO=tm.CODIGO_MOVIMIENTO
inner join DIMENSION_TIEMPO dt on pe.COD_FECHA=dt.FECHA
inner join DIMENSION_RUTA rc on pe.COD_RUTA=rc.CODIGO_RUTA
inner join DIMENSION_REDTRANSPORTE rt on pe.COD_RED=rt.CODIGO_REDTRANS
end
go
 Script Procedimiento almacenado CARGA_NI VELSERVICIO

create procedure CARGA_NIVELSERVICIO
as
begin
declare @cumplimiento float
insert into DW_PRONACA..HECHO_NIVELSERVICIO
(
ID_CLIENTE,ID_articulo,fecha,insuficiencia,cumplimiento,a_tiempo,OTIF
)
select
ID_CLIENTE,ID_ARTICULO,fecha_pedido,
case when Cant_Despachado>Cant_Pedidos
then 0 else(Cant_Pedidos-Cant_Despachado)
end as Insuficiencia,
case when Cant_Despachado>=Cant_Pedidos
then 1
else round(Cant_Despachado/Cant_Pedidos,2)
end as cumplimiento,
case when Fecha_despachado<=fecha_pedido
then 1
else 0
end as a_tiempo,
((case when Cant_Despachado>=Cant_Pedidos
then 1
else round(Cant_Despachado/Cant_Pedidos,2)
end)*(case when Fecha_despachado<=fecha_pedido then 1 else 0
end)) AS OTIF
from Mantenimiento_DW..DETALLE_PEDIDOS_PT DP
INNER JOIN DIMENSION_CLIENTE DC ON DP.Cod_Cliente=DC.CODIGO_CLIENTE
INNER JOIN DIMENSION_ARTICULO DR ON DP.Cod_articulo=DR.COD_ARTICULO
INNER JOIN DIMENSION_TIEMPO dt on dp.fecha_pedido=DT.Fecha
order by fecha_pedido
end
go
Paquete Carga_datos.- En este paquete actualizamos nuestros cubos por medio de una tarea
de procedimiento de Analisis Services.
Paquete ETL.- En este paquete demostramos la lógica inherente a un proyecto de
Extracción, Transformación y Carga (ETL). ETL es un proyecto que, por naturaleza, es
dividido en tres etapas: la primera etapa es responsable de extraer los datos de orígenes, la
segunda etapa es responsable de la aplicación de varias transformaciones, como la calidad
de datos y las reglas del negocios, y la última etapa es responsable de cargar los datos de
origen transformados al destino.
Por ello hemos configurado este paquete (ETL) como el padre de los paquetes hijos
(extrae_datos, transforma_datos, carga_datos).
ANEXO 3 Carga de datos ejecutando el proceso ETL.
Extracción de datos.- La extracción de los datos se lo realizará con la herramienta
Integration Services mediante sentencias SQL a las tablas de la base origen. Como resultado
devolverá todos los registros de acuerdo a la tabla consultada debido a que es el proceso de
carga inicia.
 Flujo de control extrae datos artículo.
 Flujo de control extrae datos clientes
 Flujo de control extrae datos vehículos.
 Flujo de control extrae datos red_transporte.

 Flujo de control extrae datos pesaje y histpesa gestión producto terminado.
 Flujo de control extrae datos pesaje y histpesa gestión materia prima.
ANEXO 4 Diagrama de flujo del funcionamiento del ETL por cada dimensión y tablas
de hecho.
Plan ETL Dimension Artículos
Plan ETL Dimension Clientes
Plan ETL Dimensión Compañía de transporte
Plan ETL Dimensión Proveedores

Plan ETL Dimension Tipo de movimiento
Plan ETL Dimension Vehículos
Plan ETL Dimension Ruta recorrido
Plan ETL Dimension Red transporte

Plan ETL Tabla de Hecho Gestión logística materia prima.
Plan ETL Tabla de Hecho Gestión logística abastecimiento y distribución de producto
terminado.
Plan ETL Tabla de Hecho Nivel de servicio OTIF.
ANEXO 5 Diseño e implementación de un cubo.

Este manual de usuario está enfocado en todos los pasos técnicos que se debe realizar para
una creación y una publicación de un cubo de información para un análisis OLAP.
Interface de usuario.
Para empezar debemos crear nuestro proyecto de Analysis Services.
Creamos la conexión a la fuente de datos, que es la base de datos donde se encuentran

nuestros datos:
Configuramos la conexión al servidor de base de datos:
Definimos que tipo de credenciales usará Analysis Services para conectarse a la fuente de
datos, usaremos la cuenta del servicio
Ya tenemos la conexión a nuestra fuente de datos, ahora vamos a crear la Vista, con la cual
podemos especificar las tablas a usar para nuestro cubo, crear campos calculados, etc...
Seleccionamos la fuente de datos.

Seleccionamos las tablas de Hechos, que serán nuestros grupos de medidas para nuestro
cubo:
Luego seleccionamos las tablas relacionadas a cada tabla de Hecho, si las tablas tienen bien
definidas todas las claves primarias y foráneas podemos simplemente usar el botón "Agregar
tablas relacionadas".
Esta lista nuestra vista de fuentes de datos.

Ahora continuamos creando las dimensiones:
A partir de tablas existentes en nuestra Vista de Fuente de Datos:
Seleccionamos los atributos que se visualizaran en nuestra dimensión:
De esa manera ya tenemos creadas nuestras dimensiones.

Una vez creados todas la dimensiones. Podemos continuar creando el cubo.
Usando las tablas de Hechos de nuestra Vista de Fuente de Datos creada:
Seleccionamos las tablas de hecho que va a ser nuestro grupo de medidas.
Seleccionamos las dimensiones a incluir en el cubo:

Listo!, ahora ya podemos procesar nuestros cubo, para esto configuremos la
implementación.
Ya podemos consultar la información de nuestro cubo, cruzando dimensiones y medidas

desde el browser del Analysis Services
ANEXO 6 Creando conexión OLAP desde Microsoft Excel a SQL Server de Analysis
Services.
1. Crear conexión de Excel a un cubo de SQL Server de Analisys Services
2. Conectar con el servidor de la base de datos.- Aquí se escribe el nombre del servidor
donde se encuentra diseñado el cubo OLAP.
3. En credenciales de conexión.
 Para usar el nombre de usuario y la contraseña actuales de Windows, haga clic en
Usar autenticación de Windows.
 Para escribir el nombre de usuario y la contraseña de una base de datos, haga clic en
Utilizar el nombre de usuario y la contraseña siguientes y, a continuación, escriba el
nombre de usuario y la contraseña en los cuadros de texto Nombre de usuario y
Contraseña correspondientes.
En este caso seleccionamos la primera opción.
4. Seleccionar la base de datos y el cubo que requiera.- Seleccionamos la base de datos

que contiene la información requerida, como también la tabla o cubo.
5. Guardar el archivo de datos y finalizar.- Guardamos el archivo de conexión dando un

nombre y colocando la ruta que deseemos.
6. Seleccionar como desea ver los datos en el libro de Excel.- Y para finalizar
seleccionamos la forma como queremos ver la información en una hoja de Excel.

Tuaexcomsis022 2016 PDF

Cargado por

Información del documento

Título 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

Tuaexcomsis022 2016 PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD REGIONAL AUTÓNOMA DE LOS ANDES

UNIANDES – SANTO DOMINGO

FACULTAD DE SISTEMAS MERCANTILES.

PROYECTO EXAMEN COMPLEXIVO PREVIO A LA OBTENCIÓN DEL TÍTULO

AUTOR: LCD. JARAMILLO DELGADO FREDDY RENE

Quien suscribe, legalmente CERTIFICA QUE: El presente Trabajo de Titulación realizado

Ambato, Septiembre de 2016

Yo, Freddy Rene Jaramillo Delgado, estudiante de la Carrera de Sistemas, Facultad de

Ambato, Septiembre de 2016

Ambato, Septiembre de 2016

El presente trabajo de investigación dedico a mi esposa Mayra Enriquez quien es mi apoyo

A mis padres Mariana Delgado y Faustino Jaramillo que se sacrificaron en post de mi

Freddy Rene Jaramillo.

A mi asesor de Tesis Ing. Carlos Martinez, por la infinita comprensión y colaboración en

Freddy Rene Jaramillo.

APROBACIÓN DEL ASESOR DEL TRABAJO DE TITULACIÓN.

Figura 1-1: Pirámide Sistemas de Información ..................................................................... 7

Tabla 2-1: La entrevista ....................................................................................................... 34

ANEXO 1- Modelo de la encuesta dirigido a los colaboradores del departamento de

Se ha evidenciado en los últimos años el crecimiento de información en el negocio pecuario

El presente proyecto se ejecutó por la importancia de tener una aplicación datawarehouse

El presente estudio está enmarcado en la línea de investigación de “Tecnologías de

Con la implementación del concepto de datawarehouse dentro del departamento de logística

This project was implemented by the importance of having an application datawarehouse to

En la actualidad, el dinámico mundo de los negocios plantea la necesidad de disponer de un

En el Ecuador el uso de los sistemas de soporte a la toma de decisiones, se encuentra en

Formulación del problema.

Identificación de la línea de investigación.

Justificación del tema.

Por ello se plantea una solución basada en tecnologías de información mediante la

1.2 Análisis de distintas posiciones teóricas sobre el objeto de investigación.

1.3.1 Business Intelligence.

1.3.1.3 Objetivo de las herramientas de inteligencia de negocios.

1.3.1.4 Características de la inteligencia de negocios.

1.3.2 Sistemas de información.

Figura 1-1: Pirámide Sistemas de Información

1.3.2.1 Sistemas de soporte a decisiones (DSS).

 Integrado.- Los datos almacenados en el datawarehouse deben integrarse en una

Figura 1-2: Arquitectura de un datawarehouse

Figura 1-3: Estructura de los datos de un datawarehouse

 Detalle de datos actuales.- En gran parte, el interés más importante radica en el

1.3.3.6 Proceso de extracción, transformación y carga ETL.

Existe un conjunto básico de procesos de suma importancia detrás de una arquitectura de

Figura 1-4: Proceso ETL

Este proceso general se encuentra subdividido en tres subprocesos fundamentales como se

1.3.3.7 Modelo dimensional de un datawarehouse.

 Esquema copo de nieve.

Figura 1-6: Esquema copo de nieve

1.3.3.7.1 Tablas de dimensiones.

Figura 1-7: Tablas de Dimensiones

1.3.3.7.2 Tablas de hechos.

Figura 1-8: Tabla de Hecho

Figura 1-9: Niveles en la Dimensión

Figura 1-10: Jerarquía en la Dimensión.

Figura 1-11: Relaciones en un Modelo

1.3.3.8 Análisis OLAP.

Figura 1-12: OLAP (On-Line Analytical Processing)

Figura 1-13: Cubo OLAP

En un análisis OLAP se implementan funcionalidades las cuales permiten interpretar la

Figura 1-15: Operación OLAP - Roll Up

Figura 1-16: The Kimball Lyfecycle Diagramt

Determinar preparación de la empresa para un proyecto de Datawarehouse.

Planeación del Proyecto.