SISTEMA DE INFORMACIÓN GERENCIAL PARA LA INTEGRACIÓN...
123
SISTEMA DE INFORMACIÓN GERENCIAL PARA LA INTEGRACIÓN DE LAS VENTAS DE CADA SUCURSAL DE CALZADO EN UNA BODEGA DE DATOS USANDO SERVICIOS WEB SEGUROS CRISTANCHO FONSECA LADY JOHANNA ORJUELA DIAZ FABIO ALEXANDER UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA INGENIERÍA TELEMÁTICA BOGOTÁ 2015
Transcript of SISTEMA DE INFORMACIÓN GERENCIAL PARA LA INTEGRACIÓN...
SISTEMA DE INFORMACIÓN GERENCIAL PARA LA INTEGRACIÓN DE LAS VENTAS DE CADA SUCURSAL DE CALZADO EN UNA BODEGA DE DATOS USANDO
SERVICIOS WEB SEGUROS
CRISTANCHO FONSECA LADY JOHANNA
ORJUELA DIAZ FABIO ALEXANDER
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA TELEMÁTICA
BOGOTÁ 2015
2
SISTEMA DE INFORMACIÓN GERENCIAL PARA LA INTEGRACIÓN DE LAS VENTAS
DE CADA SUCURSAL DE CALZADO EN UNA BODEGA DE DATOS USANDO
SERVICIOS WEB SEGUROS
CRISTANCHO FONSECA LADY JOHANNA
COD. 20111378014
ORJUELA DIAZ FABIO ALEXANDER
COD. 20111378027
Proyecto presentado como requisito para obtener el título de
Ingeniería en Telemática
Proyecto De Prestación de Servicios Tecnológicos
TUTOR
ING. NORBERTO NOVOA
UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD TECNOLÓGICA
INGENIERÍA TELEMÁTICA
BOGOTÁ 2015
3
Nota de aceptación
_______________________________
_______________________________
Presidente del Jurado
______________________________
______________________________
Jurado
______________________________
Jurado
Bogotá, 19 de Noviembre de 2015
4
AGRADECIMIENTOS
Le damos las gracias a Dios por permitirnos la existencia, otorgarnos la salud y la
inteligencia para ser parte de este reto, a nuestros familiares que depositaron su
confianza, sus esfuerzos y sus consejos a seguir adelante, a nuestros hijos que son lo más
preciado a quienes dejamos este esfuerzo como ejemplo para sus vidas.
Agradecemos a profesores, amigos, y compañeros que aportaron un granito de arena para
la completitud de este proyecto como logro de nuestras vidas tanto personales como
profesionales.
5
Dedico este esfuerzo a todos los que creyeron que era posible ser un profesional a través de esfuerzo, dedicación y sacrificio para ser un ejemplo a seguir ante la sociedad y mi familia.
Fabio Alexander Orjuela Diaz
Dedico este proyecto a mi familia que creyó que era posible progresar por medio de la educación y a mis hijos que son el motor para seguir adelante e inculcarles buenas cosas a través del buen ejemplo.
Lady Johanna Cristancho Fonseca
6
TABLA DE CONTENIDOS
AGRADECIMIENTOS .............................................................................................................................4
TABLA DE CONTENIDOS .......................................................................................................................6
LISTADO DE TABLAS .............................................................................................................................9
LISTADOS DE ILUSTRACIONES ........................................................................................................... 10
INTRODUCCIÓN ................................................................................................................................. 12
1. GENERALIDADES ....................................................................................................................... 14
1.1 TÍTULO ............................................................................................................................... 14
1.2 TEMA ................................................................................................................................. 14
1.3 PLANTEAMIENTO DEL PROBLEMA .................................................................................... 14
1.3.1 Descripción ................................................................................................................ 14
1.3.2 Formulación del Problema ........................................................................................ 16
1.4 ALCANCES Y DELIMITACIONES .......................................................................................... 16
1.4.1 Alcances .................................................................................................................... 16
1.4.2 Delimitaciones ........................................................................................................... 17
1.5 OBJETIVOS ......................................................................................................................... 18
1.5.1 Objetivo General ....................................................................................................... 18
1.5.2 Objetivos Específicos ................................................................................................. 18
1.6 JUSTIFICACIÓN .................................................................................................................. 19
1.7 MARCO DE REFERENCIA .................................................................................................... 22
1.7.1 Marco Contextual...................................................................................................... 22
1.7.2 Marco Teórico ........................................................................................................... 28
1.7.3 Marco Metodológico................................................................................................. 42
1.7.4 Marco Conceptual ..................................................................................................... 46
1.8 FACTIBILIDAD .................................................................................................................... 51
1.8.1 Factibilidad Técnica ................................................................................................... 51
1.8.2 Factibilidad Operativa ............................................................................................... 52
7
1.8.3 Factibilidad Económica ............................................................................................. 53
1.8.4 Factibilidad Legal ....................................................................................................... 54
2. ANÁLISIS .................................................................................................................................... 56
2.1 REQUERIMIENTOS ............................................................................................................. 56
2.1.1 Listado de requerimientos ........................................................................................ 56
2.1.2 Detalle de requerimientos ........................................................................................ 57
2.1.3 Diagrama de requerimientos .................................................................................... 61
2.2 DIMENSIONES ................................................................................................................... 62
2.2.1 Listado de dimensiones ............................................................................................. 62
2.2.2 Detalle de las dimensiones ....................................................................................... 62
2.3 HECHOS ............................................................................................................................. 66
2.3.1 Listado de tablas de hechos ...................................................................................... 66
2.3.2 Detalle de las tablas de hechos ................................................................................. 66
3. DISEÑO ...................................................................................................................................... 68
3.1 DISEÑO DEL MODELO MULTIDIMENSIONAL..................................................................... 68
3.2 DATOS ............................................................................................................................... 69
3.3 MAPEO DE DATOS AL MODELO MULTIDIMENSIONAL ..................................................... 71
3.4 BACK ROOM ...................................................................................................................... 72
3.5 FRONT ROOM .................................................................................................................... 73
3.6 DEFINICIÓN DE ACTORES .................................................................................................. 73
3.7 INFRAESTRUCTURA PARA EL DATA WAREHOUSE ............................................................. 74
4. IMPLEMENTACIÓN .................................................................................................................... 75
4.1 PROCESO DE ETL ............................................................................................................... 75
4.1.1 ETL de dimensión cliente .............................................................................................. 77
4.1.2 ETL de dimensión producto .......................................................................................... 84
4.1.3 ETL de dimensión vendedor .......................................................................................... 89
4.1.4 ETL de dimensión de fechas .......................................................................................... 94
4.1.5 ETL de tabla de hechos de ventas ................................................................................. 97
4.2 PROCESO DE CREACIÓN DE DATA SOURCES VIEWS ...................................................... 102
8
4.3 PROCESO DE CONSTRUCCION DEL CUBO ....................................................................... 104
4.4 PROCESO DE CREACION DE CALCULATIONS ................................................................... 106
4.5 SEGURIDAD DEL APLICATIVO .......................................................................................... 107
4.6 REPORTES IMPLEMENTADOS .......................................................................................... 108
4.6.1 Ventas en el tiempo ................................................................................................ 108
4.6.2 Ventas por clientes.................................................................................................. 109
4.6.3 Informes de productos ............................................................................................ 110
4.6.4 Ventas por vendedor .............................................................................................. 111
4.7 GESTIÓN DE USUARIO ..................................................................................................... 112
4.8 DIAGRAMAS DE COMPONENTES .................................................................................... 113
4.9 DIAGRAMA DE DESPLIEGUE ............................................................................................ 114
5. PRUEBAS ................................................................................................................................. 115
5.1 PRUEBAS DE CONFIGURACIÓN ....................................................................................... 115
5.2 PRUEBAS FUNCIONALES Y CARGA .................................................................................. 115
6. CONCLUSIONES ....................................................................................................................... 120
7. BIBLIOGRAFIA .......................................................................................................................... 121
8. INFOGRAFIA ............................................................................................................................ 123
9
LISTADO DE TABLAS
Tabla 1: Recursos físicos ................................................................................................................... 51
Tabla 2: Presupuesto y fuentes de financiación ............................................................................... 53
Tabla 3: Requerimiento 001 .............................................................................................................. 57
Tabla 4: Requerimiento 002 .............................................................................................................. 57
Tabla 5: Requerimiento 003 .............................................................................................................. 58
Tabla 6: Requerimiento 004 .............................................................................................................. 58
Tabla 7: Requerimiento 005 .............................................................................................................. 59
Tabla 8: Requerimientos 006 ............................................................................................................ 59
Tabla 9: Requerimiento 007 .............................................................................................................. 60
Tabla 10: Requerimiento 020 ............................................................................................................ 60
Tabla 11: Dimensión de la tabla productos ...................................................................................... 63
Tabla 12: Dimensión de la tabla clientes .......................................................................................... 63
Tabla 13: Dimensión de la tabla vendedores .................................................................................... 64
Tabla 14: Dimensión de la tabla fechas ............................................................................................ 65
Tabla 15: Tabla de hechos de ventas ................................................................................................ 67
Tabla 16: Mapeo modelo destino vs fuentes de datos ..................................................................... 71
10
LISTADOS DE ILUSTRACIONES
Ilustración 1: Servicio Web 2 ............................................................................................................. 22
Ilustración 2: Estructura de invocación de un servicio web 3 ........................................................... 23
Ilustración 3: Esquema WSDL .......................................................................................................... 25
Ilustración 4: Apoyo de los sistemas de Información en la toma de decisiones ............................. 29
Ilustración 5: Datamart, proporciona información a un área de la organización ............................ 30
Ilustración 6: Descripción de capas ................................................................................................... 39
Ilustración 7: WS Security ................................................................................................................. 40
Ilustración 8: Ciclo de vida para la construcción de una bodega de datos según Ralph Kimball. 17 . 42
Ilustración 9: Modelo estrella .......................................................................................................... 44
Ilustración 10: Representación de notación E-R, de la estructura para la bodega de datos ........... 45
Ilustración 11: Diagrama de requerimientos .................................................................................... 61
Ilustración 12: Diagrama multidimensional del datamart ................................................................ 68
Ilustración 13: Diagrama E-R de la base de datos "VentaCentro" .................................................... 70
Ilustración 14: Wsdl con los métodos expuestos de la sucursal centro ........................................... 75
Ilustración 15: Configuración de conexión al wsdl ........................................................................... 76
Ilustración 16: Certificado de seguridad para la conexión al Wsdl de sucursal centro .................... 76
Ilustración 17: Proceso completo ETL para clientes ......................................................................... 77
Ilustración 18: Tarea de script para eliminación de Clientes ............................................................ 78
Ilustración 19: Configuración general de la tarea Web Services para clientes ................................. 78
Ilustración 20: Configuración de entrada de la tarea Web Services para clientes ........................... 79
Ilustración 21: Configuración de salida de la tarea Web Services para clientes ............................... 80
Ilustración 22: Configuración de entrada de la tarea Xml para clientes ........................................... 81
Ilustración 23: Configuración de tarea de flujo de datos de clientes ............................................... 82
Ilustración 24: Configuración de tarea XML para flujo de datos de clientes .................................... 83
Ilustración 25: Proceso completo ETL Productos .............................................................................. 84
Ilustración 26: Script de eliminación Productos ............................................................................... 84
Ilustración 27: Configuración general de la tarea Web Services para productos ............................. 85
Ilustración 28: Configuración de entrada de web services de productos ........................................ 86
Ilustración 29: Configuración de salida de tarea web services de productos .................................. 86
Ilustración 30: Configuración de tarea xml de productos................................................................. 87
Ilustración 31: Configuración de tarea de flujo de datos para productos ........................................ 87
Ilustración 32: Configuración de tarea XML para flujo de datos de productos ................................ 88
Ilustración 33: Proceso ETL completo Vendedores .......................................................................... 89
Ilustración 34: Script de eliminación Vendedores ............................................................................ 90
11
Ilustración 35: Configuración general de la tarea Web Services para vendedores .......................... 90
Ilustración 36: Configuración de entrada de web services de Vendedores ..................................... 91
Ilustración 37: Configuración de salida de tarea web services de vendedores ................................ 91
Ilustración 38: Configuración de tarea xml de vendedores .............................................................. 92
Ilustración 39: Configuración de tarea de flujo de datos para vendedores ..................................... 92
Ilustración 40: Configuración de tarea XML para flujo de datos de vendedores ............................. 93
Ilustración 41: Proceso completo ETL Ventas Centro ....................................................................... 97
Ilustración 42: Configuración general de la tarea Web Services para ventas .................................. 98
Ilustración 43: Configuración de entrada de web services de Ventas .............................................. 98
Ilustración 44: Configuración de salida de tarea web services de ventas ........................................ 99
Ilustración 45: Configuración de tarea xml de ventas ...................................................................... 99
Ilustración 46: Configuración de tarea de flujo de datos para ventas ............................................ 100
Ilustración 47: Configuración de tarea XML para flujo de datos de ventas .................................... 101
Ilustración 48: Data Source View Venta Sucursal (Vista del origen de datos) ............................... 103
Ilustración 49: Cubo Venta Sucursal ............................................................................................... 106
Ilustración 50: Proceso de creación de datos calculados ............................................................... 106
Ilustración 51: Seguridad de aplicativo de reportes ....................................................................... 107
Ilustración 52: Seguridad de servidor de reportes.......................................................................... 107
Ilustración 53: Informe consolidado de ventas............................................................................... 108
Ilustración 54: Reporte consolidado por clientes ........................................................................... 109
Ilustración 55: Informe consolidado de productos ......................................................................... 110
Ilustración 56: Reporte consolidado por vendedores..................................................................... 111
Ilustración 57: Gestión de usuarios en el sistema .......................................................................... 112
Ilustración 58: Diagrama de componentes ..................................................................................... 113
Ilustración 59: Diagrama de despliegue .......................................................................................... 114
Ilustración 60: Reporte de pruebas funcionales de ventas ............................................................ 116
Ilustración 61: Reportes de pruebas gráficamente de ventas ........................................................ 116
Ilustración 62: Reporte de pruebas funcionales de clientes ........................................................... 117
Ilustración 63: Reportes de pruebas gráficamente de clientes ...................................................... 118
Ilustración 64: Reportes de pruebas funcionales productos .......................................................... 118
Ilustración 65: Reportes de pruebas gráficamente de productos .................................................. 119
12
INTRODUCCIÓN
Los Sistemas de información y las tecnologías de información han cambiado la forma en que
operan las organizaciones actuales. A través de su uso se logran importantes mejoras, pues
automatizan los procesos operativos, suministran una plataforma de información necesaria para la
toma de decisiones y lo más importante, su implantación logra ventajas competitivas o reduce la
ventaja de los rivales1.
El sistema de información está clasificado como un sistema de apoyo a ejecutivos, donde ayudan a
los funcionarios de alto nivel a dirigir una organización. Su meta es proporcionar un acceso
inmediato, claro y fácil a información selectiva sobre factores claves que son fundamentales para
el logro de los objetivos estratégicos de una empresa.
Actualmente se maneja y han tomado importancia en el mundo del desarrollo de aplicaciones
empresariales los servicios web (Web Services), siendo un componente independiente que posee
un conjunto de funcionalidades que pueden ser accedidas desde cualquier lugar y/o plataforma
que disponibles a través de un medio común de comunicación como la internet (la Web), accedida
desde cualquier dispositivos tecnológicos que en la actualidad vienen surgiendo, permitiendo que
la información sea accedida de forma oportuna.
El propósito fundamental de construir el presente sistema de información es integrar la
información de las diferentes sucursales en una sola, abasteciendo la sede central con información
1 Tomado de: http://www.monografias.com/trabajos24/tics-empresas/tics-empresas.shtml
13
precisa, exacta de las ventas de cada una con el fin de apoyar al gerente en la toma de mejores
decisiones para aumentar su productividad y estar a la vanguardia del mercado.
El alcance del presente proyecto está enmarcado por sus objetivos, es decir está dirigido a
desarrollar una herramienta que permita cifrar y garantizar la confidencialidad de la información
que viaja por el mensaje SOAP del servicio web utilizando el estándar XML Encryption.
14
1. GENERALIDADES
1.1 TÍTULO
Sistema de información gerencial para la integración de las ventas de cada sucursal de calzado en
una bodega de datos usando servicios web seguros.
1.2 TEMA
Inteligencia de negocios, bodegas de datos, seguridad en servicios web, seguridad Informática.
1.3 PLANTEAMIENTO DEL PROBLEMA
1.3.1 Descripción
Existe un interrogante clave que se convierte en la situación problemática para el presente
proyecto: ¿cómo hacen los gerentes para obtener la información necesaria en la toma de alguna
decisión? Los gerentes requieren información exacta y oportuna, que sea rápida de obtener para
poder tomar decisiones en el momento de encontrar una tendencia anormal en sus mediciones o
indicadores gerenciales, además, la información debe poder obtenerse de manera sencilla,
mediante informes que puedan ser generados de forma rápida.
En el presente proyecto se toma como estudio a empresas encargadas de la venta de calzado con
diferentes sucursales en diferentes zonas de la ciudad que ofrecen diferentes modelos de calzado
para dama y caballero, que requieren adaptarse a las nuevas preferencias de los clientes, o mejor
15
aún anticiparse a ellas compitiendo con calidad, estilos, precios, marcas y colores para aumentar
significativamente sus ventas.
Las sucursales de calzado basan su negocio en cumplir una meta mensual en ventas contando
siempre con el stock mínimo de productos, estar a la vanguardia con la moda, con descuentos en
marcas, variedad de estilos y colores para satisfacer las necesidades de sus clientes, mejorar la
calidad de sus productos, reducir los tiempos de búsqueda de una referencia dada, logrando ser
más competitiva en un mercado cada vez más exigente.
Para un gerente que necesita acceder a la información precisa y detallada de las ventas de cada
sucursal, debe recolectar la información por medio de cada administrador encargado de la
sucursal, donde posteriormente la unifica, transforma y entrega un informe final, sin embargo los
tiempos de entrega del resultado obtenido de la recopilación se hacen bastante largos generando
la toma de decisiones apresuradas empíricas y perdida de negocios importantes para la
organización por no tener la información en tiempo real.
El inconveniente está en que la información de las ventas, que requiere conocer el gerente para
tomar sus decisiones, se encuentra dispersa en las distintas sucursales, esto genera demoras en la
entrega de un informe claro y conciso que dé a conocer el estado actual de las ventas totales de su
empresa incluyendo las ventas de cada almacén.
Muchas veces, la información se encuentra de forma manual archivada en facturas de venta que
aún no han sido sistematizadas, o en devoluciones en venta, esto genera demoras e impide
entregar una cifra confiable en tiempo real de las ventas de cada sucursal y hace más difícil la
16
tarea del gerente al tener que tomar decisiones o medir la proyección de ventas de su empresa
para aumentar su rentabilidad.
1.3.2 Formulación del Problema
¿Por qué resultaría importante implementar un sistema de información gerencial que permita la
integración de la información de ventas de las sucursales en una bodega de datos transformando
la información de manera gráfica para facilitar la toma de decisiones al gerente de la empresa?
1.4 ALCANCES Y DELIMITACIONES
1.4.1 Alcances
Permitirá generar proyecciones de ventas en base a la información almacenada en la
base de datos centralizada.
Generará reportes estadísticos por periodos de tiempo acerca de los productos por
marca y modelos con mayor y menos salida en el sistema.
Permitirá a la gerencia obtener información en tiempo real y clasificarla de acuerdo a las
prioridades que requiera.
Permitirá visualizar en graficas reportes de ventas de cada sucursal en un periodo de
tiempo preestablecido.
Logrará integrar la información de las diferentes sucursales de venta de calzado el
sistema de información gerencial.
17
1.4.2 Delimitaciones
El sistema podrá manejar información desactualizada si en las áreas que abastecen de
información no se realiza la constante actualización por ser sistemas independientes del
sistema de información gerencial.
El sistema no tendrá un sistema móvil, aunque puede ser visible en dispositivos móviles
pero a partir de un explorador web.
El sistema solo manejara productos de calzado para dama y caballero.
El sistema permitirá traer información únicamente de las ventas de cada sucursal.
18
1.5 OBJETIVOS
1.5.1 Objetivo General
Construir un sistema de información gerencial que permita la integración de la información de
ventas de las diferentes sucursales en una bodega de datos usando servicios web seguros y por
medio de una herramienta de reportes se le facilite al gerente el proceso de toma de decisiones.
1.5.2 Objetivos Específicos
Identificar las necesidades de información del gerente encargado de administrar cada
sucursal de venta de calzado.
Crear, desplegar e invocar el servicio web por medio de SSL
Definir y crear el datamart en topología estrella, orientadas a responder preguntas sobre
las ventas de la empresa.
Utilizar una herramienta de reportes que se alimente del datamart para visualizar la
información de las ventas en forma gráfica y faciliten los procesos de toma de decisiones.
19
1.6 JUSTIFICACIÓN
En todas las organizaciones se toman decisiones en rango de tiempos cortos o largos,
trascendentes o no, pero todas ellas sin estar exentas de riesgo. Quienes deben tomar las
decisiones, requieren de minimizar este riesgo, teniendo a mano la mayor cantidad de
información, la cual debe ser oportuna, eficiente y además que contenga valores agregados para
mejorar los procesos internos de acuerdo a la actividad de cada empresa.
Por esta razón este sistema de información se diseña para mejorar la administración del área de
ventas, de las sucursales de la empresa de calzado; además de proporcionarle al gerente de la
empresa, herramientas para mejorar sus capacidades de decisión, contando con la información
que considere necesaria y de esta manera analizar los problemas, visualizar situaciones complejas
o simplemente para crear nuevas proyecciones o productos que beneficien la compañía.
La planificación y la toma de decisiones se dificultan y muchas veces se basan simplemente en
experiencias y juicios pasados de los gerentes más que en datos fiables de un proceso confiable y
documentado.
Por lo tanto el gerente de la organización se debe apoyar en un sistema de información como
elemento básico y primordial en la orientación de su gestión y debe al máximo facilitarle el trabajo
ofreciéndole datos de calidad, útiles para la toma de decisiones, así como información a nivel
general de las ventas de cada sucursal en un rango de tiempo dado para medir su proyección a
futuro y poder desempeñar una buena dirección y control.
20
Lo anterior conlleva a que es necesario contar con un sistema de información eficiente y eficaz que
permita manejar y procesar mayor cantidad de información en forma más adecuada, rápida y
precisa, brindándola en tiempo real durante todo momento, apoyando al gerente para que sean
más competitivos, logrando así los objetivos planteados en el surgimiento de la compañía en el
sector económico y comercial en la que está proyectada.
La construcción de este sistema de información es importante porque además de apoyar la toma
de decisiones, es un recurso necesario que contiene la información sistematizada, actualizada y en
tiempo real de las ventas de cada sucursal de la empresa y sirve de apoyo a los jefes o
administradores de las diferentes áreas para ayudarlos a resolver sus problemas, identificar
oportunidades, planear su próximas acciones con base en los históricos de sus gestiones para
poder proyectar y fijar metas futuras y así incrementar las utilidades a nivel de experiencia y
lucrativos de la empresa en general logrando ser competitiva y posicionarse en un mercado cada
vez más exigente.
Una de las ventajas del sistema es conocer las ventas de cada sucursal en un rango de fechas
establecidas para hacer comparaciones y proyección a futuro del comportamiento de las ventas de
la compañía.
Además con la información que se le suministre al gerente de cada fabrica le permitirá tomar
decisiones tales como: fortalecer la sucursal de menor volumen de ventas aplicando estrategias
encaminadas a impulsar los productos de menor salida, rotar el personal de venta, abastecer sus
almacenes de las marcas y modelos en calzado de mayor salida y preferencia de sus clientes,
competir con descuentos, calidad y estimar sus precios por cada producto, etc.
21
Por otro lado para la integración de la información se hará uso de los servicios web que
proporcionan mecanismos de comunicación estándares entre diferentes aplicaciones sin importar
sus plataformas tecnológicas, creadas en las diferentes sucursales que conforman la empresa,
interactuando entre sí para presentar información dinámica al gerente, haciendo primordial e
importante para proporcionar interoperabilidad y extensibilidad entre estas aplicaciones y que al
mismo tiempo sea posible su combinación para realizar operaciones complejas que faciliten la
labor gerencial y el apoyo a la toma de decisiones.
Este proyecto manejara el sistema ROLAP, donde la información se almacena en tablas de una
base de datos relacional en una tabla de hechos, que es donde se almacena la historia de alguna
magnitud relevante para la empresa que necesita ser estudiada de forma exhaustiva, en este caso
son las ventas de la empresas.
Adicionalmente, esta tabla de hechos estará ligada a otras tablas en las que se almacenarán los
parámetros en función de los cuales varía la magnitud a estudiar, estos parámetros reciben el
nombre de dimensiones; típicamente, para la magnitud ventas, las dimensiones podrían ser: el
tiempo (por días, semanas, horas, los productos, la ubicación de las sucursales (norte o sur), los
clientes, los almacenes o centros de distribución, las promociones en marcas, etc.
Finalmente, el diseño de estas tablas dará lugar a una estructura en cuyo centro estará la tabla de
hechos y, alrededor de ésta y relacionadas con ella, estarán las tablas para las dimensiones, dando
lugar a un esquema en estrella.
22
1.7 MARCO DE REFERENCIA
1.7.1 Marco Contextual
Para contextualizar el trabajo se abordan dando algunos referentes históricos sin rigurosidad
temporal y secuencial, con respecto a los dos aspectos de mayor relevancia para el proyecto.
1.7.1.1 Servicio Web
El Servicio Web es un conjunto de protocolos y estándares que sirven para intercambiar datos
entre aplicaciones, además pueden utilizar distintas aplicaciones de software desarrolladas en
diferentes lenguajes de programación y ejecutadas sobre cualquier plataforma para intercambiar
datos en redes de ordenadores como Internet, en el que con solo hacer una petición, esta le
genera una respuesta.
Ilustración 1: Servicio Web 2
La interoperabilidad de los servicios web se consigue mediante la adopción de estándares
abiertos, para mejorar esta interoperabilidad se ha creado el organismo WS-I (web services),
encargado de desarrollar diversos perfiles para definir de manera más exhaustiva estos
estándares.2
2 (Calidad e Ingeniería del Software, 2007.Tomado de: http://www.slideshare.net/Zubin67/the-impact-of-soa)
23
Por todo esto una definición alternativa podría ser la siguiente: Un servicio Web es un
componente software que se basa en las siguientes tecnologías:
Un formato que describa la interfaz del componente (sus métodos y atributos) basado en
XML. Por lo general este formato es el WSDL (Web Service Description Language).
Un protocolo de aplicación basado en mensajes y que permite que una aplicación
interaccione (use, instancia, llame, ejecute) al servicio web. Por lo general este protocolo
es SOAP (Simple Object Access Protocol).
Un protocolo de transporte que se encargue de transportar los mensajes por internet. Por
lo general este protocolo de transporte es HTTP Text Transport Protocol) que es
exactamente el mismo que usamos para qué es exactamente el mismo que usamos para
navegar por la Web3.
Ilustración 2: Estructura de invocación de un servicio web 3
Según la figura anterior el servicio web es un sistema de software que soporta interoperabilidad
máquina a máquina por la red, además de una interfaz descripta en un formato procesable por la
máquina (WSDL), y finalmente vemos que otros sistemas interactúan con él usando mensajes
SOAP.
3 (Web Services, Introducción y Escenarios para su uso, 2009.
Tomado de: http://www.slideshare.net/Zubin67/the-impact-of-soa)
24
1.7.1.2 SOAP
(Simple Object Access Protocol) es un protocolo que realiza la comunicación entre un cliente y un
servidor a través de mensajes que están escritos en XML.
La funcionalidad que aporta SOAP es la de proporcionar un mecanismo simple y ligero de
intercambio de información entre dos puntos usando el lenguaje XML. SOAP no es más que un
mecanismo sencillo de expresar la información mediante un modelo de empaquetado de datos
modular y una serie de mecanismos de codificación de datos. Esto permite que SOAP sea utilizado
en un amplio rango de servidores de aplicaciones que trabajen mediante el modelo de
comunicación RPC (Remote Procedure Call).
Este protocolo basado en XML consta de tres partes:
El SOAP envelope, es el que define el marco de trabajo y además determina qué se puede
introducir en un mensaje, quién debería hacerlo y si es una operación opcional u
obligatoria.
Las reglas de codificación SOAP, son las que definen el mecanismo de serialización que
será usado para encapsular los distintos tipos de datos en los mensajes.
La representación SOAP RPC, es el que define el funcionamiento a la hora de realizar
llamadas a procedimientos y obtener sus resultados.4
4 (Christensen, Curbera, Meredith, & Weerawarana, Simple Object Access Protocol(SOAP), 2001)
25
1.7.1.3 WSDL
(Web services Description language), es un documento escrito en XML el cual describe algunas
características del servicio web, además de su localización y aquellos parámetros y métodos que
soporta, este proporciona la información necesaria al cliente para interaccionar con el servicio
Web. 5
WSDL es extensible y se pude utilizar para describir, prácticamente, cualquier servicio de red,
incluyendo SOAP sobre HTTP e incluso protocolos que no se basan en XML.
Ilustración 3: Esquema WSDL 6
5 (WSDL para la documentacion de servicios web, 2009)
6 (SOAP::WSDL, 2004. Tomado de: http://es.slideshare.net/arluadnaedoretniuq/componentes-de-
los-servicos-web)
26
WSDL describe la interfaz pública a los servicios Web. Está basado en XML y describe la forma de
comunicación, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para
interactuar con los servicios listados en su catálogo7. WSDL utiliza los siguientes elementos en la
definición de servicios de red.
1.7.1.4 XML
(Extensible Markup Language) XML no es más que un conjunto de reglas para definir etiquetas
semánticas que nos organizan un documento en diferentes partes. XML es un metalenguaje que
define la sintaxis utilizada para definir otros lenguajes de etiquetas estructurados.
Este metalenguaje consta de cuatro especificaciones -DTD (Document Type Definition) Definición
del tipo de documento. Es un archivo que especifica la estructura lógica de cada documento y
define tanto los elementos de una página como sus atributos.
XSL (eXtensible Stylesheet Language) Define o implementa el lenguaje de estilo de los
documentos escritos para XML Permitiendo modificar el aspecto de estos.
XLL (eXtensible Linking Language) Define el modo de enlace entre diferentes enlaces. Este
lenguaje de enlaces extensible tiene dos importantes componentes: Xlink y el Xpointer. Va
más allá de los enlaces simples que sólo soporta el HTML (HyperText Markup Language).
Se podrá implementar con enlaces extendidos
1.7.1.5 XML y Los Servicios Web
XML se utiliza en los servicios web porque:
7 (WebSphere Versión 6 Web Services Handbook Development, 2005)
27
Es un estándar abierto a cualquier tecnología. Es un lenguaje fácil de integrar a los
sistemas y compatibilidad con cualquier lenguaje. Esto quiere decir que la gran mayoría de
software, aplicaciones móviles, sistemas operativos permiten la compatibilidad con XML y
la comunicación entre distintas plataformas de software y hardware (y si bien recordamos
este es el sentido final de los Servicios Web).
Simplicidad de sintaxis esto quiere decir que es muy fácil de escribir código en XML y la
representación de los datos es casi entendible por cualquier ser humano. El hecho de que
XML sea tan fácil de codificar y de entender lo hace el lenguaje ideal para utilizarlo en los
servicios Web.
Independencia del protocolo de Transporte, el hecho de que XML es un lenguaje de
Marcado de Texto, no necesita de ningún protocolo de trasporte especial, solo necesita
de un protocolo que pueda trasferir texto o documentos simples8.
8 (El lenguaje de los servicios web, 2004)
28
1.7.2 Marco Teórico
Para este caso tomaremos como punto de partida los sistemas de información gerencial, esto nos
dará el punto de vista para afrontar el problema planteado y como aplicando estos conceptos se
puede lograr el resultado planteado como solución en la justificación.
1.7.2.1 Sistemas de Información Gerencial SIG
Los sistemas de información gerencial son una colección de sistemas de información que
interactúan entre sí y que proporcionan información tanto para las necesidades de las operaciones
como de la administración. Sin embargo debe recalcarse que es una colección de sistemas de
información y no un sistema “total”. En teoría, una computadora no es necesariamente un
ingrediente de un Sistema de Información Gerencial (SIG), pero en la práctica es poco probable
que exista un SIG complejo sin las capacidades de procesamiento de las computadoras. Este
concepto aunque más amplio, se ajusta plenamente porque los sistemas de información de todas
las funciones de la empresa están unidas cada vez más en un súper sistema, compuesto de
sistemas casi independientes, pero de tal modo que ninguno de ellos puede verse completamente
separado de los otros.
Es un conjunto de información extensa y coordinada de subsistemas racionalmente integrados que
transforman los datos en información en una variedad de formas para mejorar la productividad de
acuerdo con los estilos y características de los administradores. Esta transformación se realiza con
base en los criterios de calidad establecidos, que son el tiempo, la relevancia, la precisión, la
retroalimentación y la disponibilidad selectiva de los datos.
29
Ilustración 4: Apoyo de los sistemas de Información en la toma de decisiones 9
1.7.2.2 Data Warehouse
El Data Warehouse es un conjunto de procesos y acciones que involucran un almacenamiento de
datos no volátil, orientado a un tema, integrado e histórico para el soporte al proceso de toma de
decisiones de la gerencia.
Es una técnica para consolidar y administrar datos de diversas fuentes el propósito de responder
preguntas de negocios y tomar decisiones. Está constituido por la correcta organización e
interrelación de los desarrollos tecnológicos consistentes en consolidar datos desde una variedad
de fuentes; manejar grandes volúmenes de datos de una forma que no era posible, acceder a los
datos de una forma más directa, en “el lenguaje del negocio”, y analizarlos para obtener
relaciones complejas entre los mismos.
Un sistema Data Warehouse define un nuevo concepto para el almacenamiento de datos, integra
la información generada en todos los ámbitos de una actividad de negocio (ventas, producción,
finanzas, marketing, etc.) que proviene de diferentes fuentes, formatos y tipos en un único
depósito y permite un acceso y explotación de la información contenida en las bases de datos,
facilitando un amplio abanico de posibilidades de análisis multivariables que permitirán la toma de
decisiones estratégicas.
9 Tomado de: https://prezi.com/rpyczbsmvmj9/sistemas-de-informacion-gerencial/
30
1.7.2.3 Datamart
Un Datamart es una versión especial de almacén de datos (data warehouse). Son subconjuntos de
datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar
mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y
propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de
los mismos de la forma más conveniente según sus necesidades.
Ilustración 5: Datamart, proporciona información a un área de la organización 10
El datamart es un sistema orientado a la consulta, en el que se producen procesos batch de carga
de datos (altas) con una frecuencia baja y conocida. Es consultado mediante herramientas OLAP
(On line Analytical Processing - Procesamiento Analítico en Línea) que ofrecen una visión
multidimensional de la información. Sobre estas bases de datos se pueden construir EIS (Executive
Information Systems, Sistemas de Información para Directivos) y DSS (Decision Support Systems,
Sistemas de Ayuda a la toma de Decisiones). Por otra parte, se conoce como Data Mining al
proceso no trivial de análisis de grandes cantidades de datos con el objetivo de extraer
información útil, por ejemplo para realizar clasificaciones o predicciones.
10
tomado de: http://repository.javeriana.edu.co/bitstream/10554/7497/1/Tesis204.pdf - pag: 5
31
En síntesis, se puede decir que los datamarts son pequeños data warehouse centrados en un tema
o un área de negocio específico dentro de una organización.
32
1.7.2.4 ETL
Este término viene de inglés de las siglas Extract-Transform-Load que significan Extraer,
Transformar y Cargar y se refiere a los datos en una empresa. ETL es el proceso que organiza el
flujo de los datos entre diferentes sistemas en una organización y aporta los métodos y
herramientas necesarias para mover datos desde múltiples fuentes a un almacén de datos,
reformatearlos, limpiarlos y cargarlos en otra base de datos, datamart o bodega de datos. ETL
forma parte de la Inteligencia Empresarial (Business Intelligence), también llamado “Gestión de los
Datos” (Data Management).
La idea es que una aplicación ETL lea los datos primarios de unas bases de datos de sistemas
principales, realice transformación, validación, el proceso cualitativo, filtración y al final escriba
datos en el almacén y en este momento los datos son disponibles para analizar por los usuarios.
1.7.2.5 EXPLOTACIÓN
Es importante recordar que la Bodega de Datos no es un fin en sí misma, sino que es un medio
para solucionar una necesidad: el análisis de información y la toma de decisiones a través de los
datos de la empresa, objetivo que se logra con el proceso de explotación de la bodega de datos.
En esta etapa es donde se desarrolla la inteligencia del Negocio y por lo tanto es un componente
esencial del data warehouse, ya que es el punto de contacto directo con el usuario final, quien es
el encargado de tomar decisiones o acciones que redundan en beneficio de la compañía y en el
ROI (Retorno de la Inversión) del Data Warehouse.
Las herramientas utilizadas para el desarrollo de inteligencia del negocio pueden incluir software
de consultas, generadores de reportes, procesamiento analítico en línea, herramientas de minería
de datos, etc., dependiendo de los tipos de usuarios y sus requerimientos particulares. Sin
embargo, se hace necesaria la integración de varias herramientas puesto que una sola no satisface
todos los requerimientos.
33
Los niveles de aplicaciones típicas en esta etapa son: Consultas e Informes, OLAP, minería de
datos, Sistemas de Información Ejecutiva y Visualización Geográfica.
1.7.2.6 Análisis OLAP
OLAP (On-Line Analytical Processing). El Procesamiento Analítico en Línea es la técnica que
permite ver y manipular los datos por dimensiones, proveyendo a los gerentes y analistas fácil
acceso a la información con el fin de soportar el proceso de toma de decisión. En esta técnica de
análisis, en lugar de ejecutar múltiples consultas, los datos son estructurados para permitir un
acceso rápido y fácil a las respuestas de las preguntas que son típicamente formuladas. De esta
manera, OLAP, brinda flexibilidad en la visualización de la información.
Las herramientas OLAP pueden soportar requerimientos complejos de análisis, analizar datos
desde diferentes perspectivas y soportar análisis complejos contra un volumen determinado de
datos. Su objetivo fundamental es proveer al usuario final el fácil análisis de los datos, con la
potencia y confiabilidad de una base de datos corporativa, y con la posibilidad de ver los datos
desde diversos puntos de vista o dimensiones.
Permite vistas reformateadas y calculadas sin el riesgo de perder o corromper los datos originales
y hace que la información pueda ser compartida por varios usuarios sin tener que duplicar
archivos. En muchos casos los usuarios pueden adicionar o cambiar datos sin el riesgo de
sobrescribir la información original.
El uso más común de estas herramientas en una empresa se da en el análisis de ventas y compras
de materia prima. Gracias a este análisis se evalúa la rentabilidad de productos, capacidad de
producción o la demanda. Estos aspectos dependen directamente de los requerimientos del
negocio específicos para cada empresa.
Las herramientas OLAP están dirigidas principalmente a los usuarios finales por lo que requieren
de una interfaz simple y deben tener una buena integración con los sistemas que las alimentan.
34
1.7.2.7 Metadatos
Es la información que se puede tener de los datos que pertenecen a un sistema de información
(por ejemplo una bodega de datos). Los metadatos permiten mantener información de la
procedencia de la información, la periodicidad de cargue, su fiabilidad, la información de los
cálculos asociados al dato, su definición de negocio, entre otros. De esta última explicación se
deriva que la metadata permite hacerle un seguimiento efectivo a los datos almacenados en una
bodega, garantizando de esta forma la confiabilidad y los cambios que del mismo puedan
generarse en toda la cadena de transformación.
Dimensión Las dimensiones son los atributos de los hechos y se usan como base para realizar
operaciones de agrupamiento. Pueden ser fechas o textos y toman un número fijo de valores (son
discretas). También con frecuencia son parte de una jerarquía. Las dimensiones frecuentemente
corresponden con el ¿Qué? ¿Cuándo? ¿Dónde? ¿Quién? ¿Por qué? ¿Cómo? del negocio.
1.7.2.8 SOA (Service Oriented Architecture)
En ingeniería de Software contamos con múltiples opciones y posibilidades para resolver los
requerimientos de nuestros clientes. Siempre que un cliente nos expresa sus requisitos los
ingenieros y arquitectos de software contamos con las herramientas para analizar y definir la
mejor estrategia para cumplirlos.
Una de las opciones con las que contamos es la utilización de servicios (comúnmente Servicios
Web), los cuales podemos exponer, orquestar y consumir para dar solución a las necesidades
expuestas por nuestros clientes.
La arquitectura orientada a servicios (en inglés Service Oriented Architecture) consiste en un
grupo de metodologías y principios para el diseño y desarrollo de aplicaciones a partir de servicios.
El uso de estas metodologías y principios para el desarrollo de aplicaciones se conoce como
35
Análisis y Diseño Orientado a Servicios y su objetivo es establecer los servicios requeridos, sus
características y la forma como deben ser orquestados y consumidos.
Los servicios son componentes de software que contienen funcionalidades y procesos de
negocios que podemos usar para diferentes propósitos. Dichos servicios normalmente están
expuestos en Internet o en una Intranet mediante una interfaz claramente definida, la cual acepta
los llamados que se le realizan y envía las respuestas correspondientes. Mediante está interfaz
conocida como contrato el proveedor del servicio establece las reglas de comunicación, el
transporte, y los datos de estrada y salida que serán intercambiados por ambas partes.
En SOA los servicios no dependen de la condición de otro servicio, por ellos se dice que no
manejan estados (Sin Estado), esta característica permite que sean secuenciados (orquestados)
según las necesidades para realizar la lógica de negocio necesaria para resolver un requerimiento.
SOA nos permite integrar aplicaciones que pueden ser muy dispares, y que incluso pueden estar
construidas en diferentes lenguajes y plataformas. En un entorno Web Based SOA define como
integrar dichas aplicaciones y como los nodos de una red exponen sus recursos en forma de
servicios independientes para que otros puedan consumirlos mediante estándares establecidos.
1.7.2.9 Seguridad en Servicios Web
Los requerimientos o necesidades de seguridad que llegan a asegurar en un servicio web serian:
Autenticación. El requerimiento fundamental en las aplicaciones de Internet es poder identificar al
usuario así entonces, la autenticación es un proceso por el cual se puede identificar a una persona
o a un sistema y validar sus credenciales, normalmente se hace mediante el empleo de una
combinación de nombre de usuario y contraseña. Si la contraseña no es protegida
adecuadamente, entonces la autenticación se verá comprometida.
Otra manera de garantizar la autenticación, es por medio del uso de certificados, el cual se basa en
llaves privadas y públicas para encriptar la información y garantizar la autenticidad de los servicios,
36
para lograr esto se necesita de una Entidad Certificadora externa al Servicio con el fin de poder
garantizar la identidad de los clientes.
Autorización. Una vez que se ha autenticado al usuario, se le debe dar la autorización de acceso,
esto quiere decir que identifica a qué recursos tiene derecho el usuario, y cuáles recursos le serán
negados al momento de una petición. Esta autorización se hace a través del uso de ACL (Access
Control List), en esta lista se encuentran los usuarios y los tipos de acceso que tienen a los
recursos.
Integridad de Datos. Consiste en ofrecerle al cliente la seguridad de que la información que se
está enviando a través de la conexión con el proveedor, no ha sido alterada, esto quiere decir que
no se hará ninguna modificación a la información transportada por quien no esté autorizado a
hacerlo.
Confidencialidad. Es el proceso por el cual se asegura que la información no pueda ser leída, a
menos que se tenga autorización para ello. No basta con emplear la identificación del usuario y la
contraseña, sino que además la información es encriptada para protegerla.
No Repudiación. Asegurar que no se pueda negar el haber participado en una operación, esto
quiere decir que se debería mantener un historial de participación o de uso del sistema, de los
usuarios.
Auditar. Es el proceso de grabar los eventos relacionados con la seguridad en la comunicación y
tomar acciones basados en las ocurrencias de estos.
Vulnerabilidades de los Servicios web. Por tener la condición de ser públicos los SW están
expuestos a diversos ataques, a continuación enunciaremos los más importantes:
37
Ataques externos: Las aplicaciones de e-business intercambian información que es muy
valiosa. Las e-business son empresas que intercambian miles de registros de pacientes y
comercio de acciones que valen millones. Para los servicios web basados en Internet, los
ataques a estos sistemas pueden ser montados en cualquier máquina de escritorio en el
mundo utilizando herramientas de software muy simples.
Ataques internos: Se ha sabido que la mayoría de las violaciones de seguridad son realizadas
por empleados que se presumen son de confianza. Pueden establecer una trampa para
acceder a datos corporativos después de dejar la empresa. Además de que es posible que
puedan cometer fraudes creando clientes ficticios, a fin de negociar con acciones o fabricando
mercancías11
Los servicios web están diseñados para ser abiertos e interoperables. Desde que se establecen los
cortafuegos para permitir pasar el tráfico HTTP, las solicitudes de los servicios web por HTTP pasan
a través de los cortafuegos fácilmente, dejando a la red interna expuesta12.
Los datos envueltos en sobres SOAP proveen un camino para entender la estructura y el
significado de los datos que son enviados y recibidos por los servicios web.13
11 Bret Hartman, Donald J. Flinn, Konstantin Beznosov, Shirley Kawamoto, Mastering Web Services Security, Wiley
Publishing Inc., 2003, pág.350
12 Bret Hartman, Donald J. Flinn, Konstantin Beznosov, Shirley Kawamoto, Mastering Web Services Security, Wiley
Publishing Inc., 2003, pág.351
13 David Chappell, Java Web Services, O´Reilly, 2002, pág.227
38
1.7.2.10 Opciones de seguridad en SOAP
Puede ser implementada en 3 capas diferentes.
Transporte (HTTP, FTP, SMTP…).
Limitada a interacciones punto a punto.
Para las aplicaciones no es simple obtener el contexto de seguridad.
Aplicación
Soluciones ad-hoc, sin interoperabilidad.
Similitud con formularios de autenticación en aplicaciones Web.
No cometer errores es más complicado.
Necesario infraestructuras SSO.
Cabeceras SOAP
Mecanismo de extensión mediante cabeceras. SOAP no define por sí mismo qué cabeceras
usar. Surgen iniciativas de estandarización como WS-Security.
Sin embargo si la seguridad se delega al uso de extensiones, existe el riesgo de que cada
vendedor defina su propia extensión, dañando la interoperabilidad en los procesos. Esto se
puede evitar utilizando un estándar para extensiones de seguridad como WS-Security, creado
por el grupo de estandarización OASIS. Además de que si el estándar no satisface el escenario
que se requiere, existe la posibilidad de crear una extensión de seguridad propia.
39
Ilustración 6: Descripción de capas14
Del anterior diagrama se podría concluir que toda la solución estará encaminada a ofrecer
seguridad en la cabecera SOAP ya que se le agregaran tag xml al header del mensaje SOAP todo
esto bajo el estándar Ws-Security, en específico el estándar Xml Encryption.
Dentro de la cabecera del mensaje SOAP se podría implementaran diferentes tipos de seguridad a
los mensaje, la aplicación de uno o varios de estos solo dependerá del nivel de seguridad que se
quiera brindar, a continuación una imagen que muestra los diferentes tipos de seguridad en el
header SOAP.
14
http://webs.um.es/danielsm/miwiki/lib/exe/fetch.php?id=ponencias&cache=cache&media=soadvanced2009_-_seguridad_soa.pdf
40
Ilustración 7: WS Security15
Para cumplir con el alcance de este proyecto solo se implementaran dos de los anteriores tipos de
header: Encrypted Key y Encrypted Data.
1.7.2.11 Estándares de seguridad para Servicios Web
A continuación habláremos sobre los estándares que se usaran para la consecución de la
herramienta de seguridad, esto con el fin de dar una base estándar a la misma. Existen en la
actualidad varias iniciativas para logra un estándar para la seguridad de los web services, pero
basados en la investigación realizad se usaran la planteada por la OASIS (Organization for the
Advancement of Structured Information Standards).
15
http://webs.um.es/danielsm/miwiki/lib/exe/fetch.php?id=ponencias&cache=cache&media=soadvanced2009_-_seguridad_soa.pdf
41
Sin embargo, todos estos estándares son esfuerzos centrados en obtener un conjunto de
especificaciones que puedan ofrecer una solución completa en términos de asegurar los servicios
web16.
16 Mark O'Neill, et al, Web Services Security, McGraw-Hill/Osborne, 2003, pag 621
42
1.7.3 Marco Metodológico
Durante la etapa de investigación se encontraron varios autores quienes proponen metodologías
para el desarrollo de una bodega de datos, el más reconocido es R. Kimball17, quien brinda
conceptos necesarios para llevar a cabo el análisis y diseño de la bodega de datos planteada para
las fábricas de calzado.
El método presentado por Kimball (ver siguiente ítem, Ciclo de vida de la Bodega de datos)
además de estar extensamente expuesto en su bibliografía, se apoya en gran variedad de
ejemplos que facilitan la comprensión de los conceptos relacionados con diseño de bodegas de
datos.
1.7.3.1 CICLO DE VIDA DE LA BODEGA DE DATOS
La metodología de Kimball, presenta un marco de trabajo descrito en la ilustración 8, en la cual se
muestran las diferentes etapas durante todo el proceso de creación de la bodega.
Ilustración 8: Ciclo de vida para la construcción de una bodega de datos según Ralph Kimball. 17
17
R. Kimball, L. Reeves, M. Ross, W. Thornthwaite, The Data Warehouse Lifecycle toolkit. (United States of America: Wiley Computer Publishing, 1998).
43
La fase de planeación del proyecto, pretende establecer la definición y el alcance del proyecto de
la bodega de datos, incluyendo la valoración y justificación del negocio. La fase de definición de
requerimientos del negocio es donde se establece la base relacionada con la tecnología, los datos
y las aplicaciones del usuario.
La ruta de mayor importancia es la relacionada con los datos, en la cual se realiza el modelado
dimensional, partiendo de los requerimientos obtenidos y de las necesidades de análisis de los
usuarios; el diseño físico, el cual se enfoca en definir las estructuras físicas necesarias para
soportar el modelado dimensional; y la etapa ETL (Extract – Transform-Load Data Staging) en la
cual se diseña y desarrollan procesos para extraer, transformar y cargar datos.
Además se deben considerar otras rutas como la de tecnología en la cual se establece la
arquitectura y visión general del marco de trabajo y la ruta de aplicación en la cual se definen un
conjunto de aplicaciones de usuario final para consulta de datos.
Por último, a lo largo de todo el ciclo de vida se debe seguir una administración general del
proyecto la cual asegura que todas las actividades del ciclo de vida se alcancen y se sincronicen.
Asimismo, este autor basado en su experiencia en la construcción de bodegas de datos, plantea
una serie de soluciones para tener en cuenta en algunos casos especiales que se presentan en el
momento de realizar el modelado dimensional. Estas soluciones ayudan a garantizar una buena
representación de los requerimientos del negocio señalando conceptos relacionados con el diseño
de los datos, la arquitectura y la implementación.
44
1.7.3.2 MODELADO 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 ilustración 9).
Ilustración 9: Modelo estrella 18
1.7.3.3 DIAGRAMA EN ESTRELLA
El diagrama en estrella está conformado por una entidad central que corresponde a la tabla de
hechos “factura-venta”, y por un conjunto de trayectorias de entidades y relaciones de uno a
muchos, que corresponde a las dimensiones y a sus jerarquías. En la figura 4 se presenta un
diagrama en estrella con esta notación.
18
http://repository.unilibre.edu.co/bitstream/10901/5951/1/PinedaSuavitaAndresCamilo2011.pdf - pag 25
45
Ilustración 10: Representación de notación E-R, de la estructura para la bodega de datos 19
19
Tomado de: http://www.icesi.edu.co/contenido/pdfs/jbahamon-diseno_modelado_bodega_datos.pdf - pag 26
46
1.7.4 Marco Conceptual
Para el presente estudio se han definido varios términos relevantes en el proceso de elaboración
de la herramienta informática propuesta.
MDX: es un lenguaje para realizar queries en bases de datos multidimensionales, de la
misma forma análoga al SQL en bases de datos relacionales. Inicialmente fue definido
como parte de la especificación de OLAP OLE DB, y un lenguaje similar, mdXML, es parte
de la especificación XML for Analysis.
KPI: Son las siglas de Key Performance Indicators, ósea, indicadores clave del desempeño.
Los KPIs son métricas que se utilizan para cuantificar los resultados de una determinada
acción o estrategia en función de unos objetivos predeterminados; en cristiano,
indicadores que nos permiten medir el éxito de nuestras acciones. Un ejemplo sencillo de
KPI lo podemos encontrar en una inmobiliaria que este año se plantea vender 100 pisos
(no tengo ni idea de inmobiliarias, así que no se si la cifra que he dicho es una locura). Un
KPI aquí puede ser el número de pisos que vende un empleado por semana. Es un
indicador valido que informará a los responsables de la inmobiliaria de lo cerca o lejos que
están de cumplir sus objetivos.
Cubo: OLAP efectúa el almacenamiento lógico de los datos en arreglos o matrices
multidimensionales denominadas cubos. El cubo contiene los datos que son de interés
para los usuarios; organiza la información dentro de dimensiones y medidas en una
estructura multidimensional para soportar las preguntas que tienen los usuarios acerca de
los datos de su compañía. Además proporcionan un mecanismo para la consulta de datos
con rapidez y con una respuesta uniforme ante diferentes cantidades de datos que
contenga el cubo o por la complejidad de una consulta. Un cubo se compone de
dimensiones, jerarquías (niveles) y medidas.
47
Medidas: Es la información de cada hecho, evento o suceso del negocio. Generalmente
son valores numéricos, continuos y aditivos (es decir, que tiene sentido operarlos
matemáticamente).
Dimensión: Los atributos de tipo texto que describen cosas son organizados en
dimensiones. Es necesario establecer un criterio puramente de diseño y basado en los
requerimientos del negocio para establecer los atributos que se incluyen como
dimensiones y los que se pueden descartar al realizar la bodega de datos.
Nivel: Las dimensiones están construidas por niveles. Estos niveles representan la
jerarquía establecida por las estructuras organizacionales y modelos de datos que la
organización usa. Cada nivel inferior provee cada vez datos más detallados que relaciona a
la dimensión. Las herramientas especializadas para análisis OLAP permiten fijar este nivel
de granularidad en forma dinámica mientras el usuario final navega por su reporte. La
dimensión tiempo provee un claro ejemplo del uso de niveles. Se tiene el año en un nivel
superior, luego le siguen el semestre, trimestre, mes y por último en el nivel más inferior
se encuentra el día.
Integración de datos: Proceso cuya base es el conocimiento de los conceptos de negocio
que maneja una organización. Este proceso es incremental, quiere decir que se va
construyendo paso a paso en la organización; y además es evolutivo, esto es que a través
del tiempo los conceptos de negocio van aumentando.
Web Services: Un servicio web es un conjunto de protocolos y estándares que sirven para
intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en
lenguajes de programación diferentes, y ejecutadas sobre cualquier plataforma, pueden
utilizar los servicios web para intercambiar datos en redes de ordenadores como Internet.
WSDL Abreviación de Web Services Description Language, es un lenguaje especificado en
48
XML que se ocupa para definir los servicios web como colecciones de punto de
comunicación capaces de intercambiar mensajes. El WSDL es parte integral de UDDI y
parte del registro global de XML, en otras palabras es un estándar de uso público (no se
requiere pagar licencias ni royalties para usarlo).
UDDI Abreviación de (Universal Description, Discovery and Integration). Es un directorio
distribuido que opera en la Web que permite a las empresas publicar sus servicios web,
para que otras empresas conozcan y utilicen los servicios web que publican, opera de
manera análoga a las páginas amarillas.
REST Abreviación de (Representational State Transfer). Es un estilo de arquitectura que
ofrece un buen desempeño, escalabilidad y abstracción de recursos, donde cada petición
HTTP contiene toda la información necesaria para responder a la petición, sin necesidad
que el cliente ni el servidor tenga que recordar el estado de su comunicación.
SSL Secure Sockets Layer (SSL; en español «capa de conexión segura») SSL proporciona
autenticación y privacidad de la información entre extremos sobre Internet mediante el
uso de criptografía. Habitualmente, sólo el servidor es autenticado (es decir, se garantiza
su identidad) mientras que el cliente se mantiene sin autenticar.
SSL implica una serie de fases básicas:
+ Negociar entre las partes el algoritmo que se usará en la comunicación
+ Intercambio de claves públicas y autenticación basada en certificados digitales
+ Cifrado del tráfico basado en cifrado simétrico.
SOA: (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo
dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de
datos XML.
49
HTTPS: Hypertext Transfer Protocol Secure (en español: Protocolo seguro de transferencia
de hipertexto), más conocido por sus siglas HTTPS, es un protocolo de aplicación basado
en el protocolo HTTP, destinado a la transferencia segura de datos de Hipertexto, es decir,
es la versión segura de HTTP. El sistema HTTPS utiliza un cifrado basado en SSL/TLS para
crear un canal cifrado (cuyo nivel de cifrado depende del servidor remoto y del navegador
utilizado por el cliente) más apropiado para el tráfico de información sensible que el
protocolo HTTP. De este modo se consigue que la información sensible (usuario y claves
de paso normalmente) no pueda ser usada por un atacante que haya conseguido
interceptar la transferencia de datos de la conexión, ya que lo único que obtendrá será un
flujo de datos cifrados que le resultará imposible de descifrar. El puerto estándar para este
protocolo es el 443.
XML: siglas en inglés de extensible Markup Language ('lenguaje de marcas extensible'), es
un metalenguaje extensible de etiquetas desarrollado por el World Wide Web Consortium
(W3C).
WS I Basic Profile: es una especificación que consta de un conjunto de especificaciones
de servicios web no propietario junto con aclaraciones, ajustes, interpretaciones y
ampliaciones de las especificaciones que promueven la interoperabilidad,
como SOAP y WSDL.
WS Security: WS-Security (Seguridad en Servicios Web) es un protocolo de
comunicaciones que suministra un medio para aplicar seguridad a los Servicios Web. En
abril de 2004 el estándar WS-Security 1.0 fue publicado por Oasis-Open. En 2006 fue
publicada la versión 1.1. Originalmente desarrollado por IBM, Microsoft, y VeriSign, el
protocolo es ahora llamado oficialmente WSS y está desarrollado por un comité en Oasis-
Open.
50
SOAP: (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo
dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de
datos XML.
TCP: Es un protocolo de comunicación orientado a conexión y fiable del nivel de
transporte, actualmente documentado por IETF en el RFC 793. Es un protocolo de capa 4
según el modelo OSI.
Modelo lógico: Los componentes más importantes de un esquema son los cubos, medidas
y dimensiones:
Un cubo es una colección de dimensiones y medidas de un área en particular.
Una medida es una cantidad que se quiere medir, por ejemplo unidades vendidas de un
producto, o costos de inventario.
Una dimensión es un atributo, o conjunto de atributos en los cuales se pueden dividir
medidas en subcategorías. Por ejemplo, es posible dividir las ventas de productos por sus
colores, el género del cliente y la sucursal en donde es hecha la venta. Color, género y
tienda son dimensiones.
51
1.8 FACTIBILIDAD
1.8.1 Factibilidad Técnica
Los recursos tecnológicos con los que se cuenta para llevar a cabo el proyecto son:
Hardware
Articulo Características
1 Computador
Portátil
Procesador Intel(R) Pentium(R) 5 CPU a 2.66 GHz
Disco duro de 500 GB
Memoria de 4 GB
Tarjeta de red 10/100/1000
Unidad quemadora de DVD
6 Puertos USB 2.0
2 máquinas virtuales Procesador Intel(R) Pentium(R) 5 CPU a 2.66 GHz
Disco duro de 80 GB
Memoria RAM de 512 MB
Puertos USB 2.0
Impresora Impresora Epson multifuncional sistema de inyección
Tabla 1: Recursos físicos
Basado en la información anterior el proyecto es factible técnicamente ya que cuenta con el los
recursos técnicos para su desarrollo.
52
1.8.2 Factibilidad Operativa
Para la elaboración del proyecto se cuenta con la participación de personas comprometidas al
proyecto que serán piezas fundamentales en la mejor elaboración del sistema final.
Se tendrá como tutor del proyecto al Ingeniero NORBERTO NOVOA TORRES para la asesoría del
documento que llevara las pautas para presentarlo a la coordinación de la carrera para ser
evaluado y posteriormente aprobado.
La estudiante LADY JOHANNA CRISTANCHO FONSECA quien será la persona encargada de llevar a
cabo la elaboración del proyecto.
El estudiante FABIO ALEXANDER ORJUELA DIAZ quien será el segundo integrante del proyecto
encargado hacer la elaboración del proyecto.
A nivel operacional el proyecto es totalmente viable la factibilidad operativa gracias a que se
cuenta con el personal necesario para la ejecución del proyecto requerido y en condiciones
óptimas para su elaboración.
53
1.8.3 Factibilidad Económica
Los costos monetarios del proyecto se resumen en la siguiente tabla.
RECURSO ESTUDIANTE UNIVERSIDAD EMPRESA/ ENTIDAD OTRO
Bibliografía $40.000 $0 $0 $0
Papelería $200.000 $0 $0 $0
Telecomunicaciones $0 $0 $0 $0
Equipos 1000/480h $480.000 $0 $0 $0
Transporte $0 $0 $0 $0
Asistencia a eventos $0 $0 $0 $0
Gastos de
representación
$0 $0 $0 $0
Trabajo
Estudiante10.000/960h $9’600.000
$0 $0 $0
Trabajo Tutor
$/21.000/50
$0 $1’050.000 $0 $0
Trabajo Asesor $/h $0 3.6$0 $0 $0
Subtotal $10’320.000 $1’050.000 $0 $0
Imprevistos (10%) $1’130.000 $0 $0 $0
Total $11’450.000 $1’050.000 $0 $0
Tabla 2: Presupuesto y fuentes de financiación
[Hora Tutor 21.000 Hora Estudiante 10.000 Hora Maquina 1000 capacidad 70% 10% improvistos]
Los costos económicos serán asumidos por los ponentes de este proyecto de grado, quienes
contamos con los recursos necesarios para su implementación.
54
1.8.4 Factibilidad Legal
De acuerdo a la ley contra delitos informáticos (ley 1273) que menciona en su Artículo 269F: la
violación de datos personales, en nuestro caso trabajaremos con datos de prueba y no tendremos
acceso a los datos reales de la organización y de esta manera nos abstenemos de manipular la
información confidencial de las fábricas de calzado.
Nuestro sistema no contara con enlaces o ventanas emergentes que capturen datos personales,
de acuerdo a ello no incurriremos en ningún tipo de faltas al Artículo 269G:
SUPLANTACIÓN DE SITIOS WEB PARA CAPTURAR DATOS PERSONALES de la ley contra delitos
informáticos.
Para el ingreso al sistema se trabajara con un usuario de prueba que solo podrá realizar consultas
a la información, además las contraseñas estarán encriptadas en la base de datos como medio de
protección; De esta forma evitamos manipular el sistema informático y respetar los Artículos 269I:
HURTO POR MEDIOS INFORMÁTICOS Y SEMEJANTES y Artículo 269J: TRANSFERENCIA NO
CONSENTIDA DE ACTIVOS de la ley contra delitos informáticos.
La calidad del software que vamos a desarrollar será funcional, confiable de fácil uso, eficiente, de
fácil mantenimiento y portabilidad cumpliendo estándares de la ISO 9126.
El proyecto está sujeto a todas las normas legales de uso de software, y hardware. A continuación
se resumen las licencias de las herramientas tecnológicas que se usarán para el proyecto.
LICENCIA JAVA SE DEVELOPMENT KIT (JDK), VERSIÓN 7
Estos Términos Adicionales de la Licencia amplían o modifican los términos del Contrato de
Licencia de Código Binario. Los términos en mayúsculas que no se definan en los presentes
Términos Adicionales mantendrán el mismo significado que se les ha atribuido en el Contrato de
Licencia de Código Binario. Los presentes Términos Adicionales sustituyen cualquier término del
Contrato de Licencia de Código Binario o de cualquier licencia contenida dentro del Software con
los que sean contradictorios o incongruentes.
55
Uso interno del software y otorgamiento de la licencia de desarrollo. Sujeto a los términos y
condiciones de este Acuerdo y a las restricciones y excepciones que se establecen en el archivo
“README” del Software que se incorpora al presente por referencia, incluidas, sin limitación, las
Restricciones de la Tecnología Java de estos Términos Adicionales, SUN le otorga una licencia no
exclusiva, no transferible y limitada sin derechos de licencia, para reproducir y usar de manera
interna el Software completo y sin modificar a los efectos de diseñar, desarrollar y probar sus
Programas20.
LICENCIA NETBEANS
Desde Julio de 2006, NetBeans IDE es licenciado bajo la Common Development and Distribution
License (CDDL), una licencia basada en la Mozilla Public License (MPL). CDDL es una licencia de
código abierto (OSI) y libre, producida por Sun Microsystems, basada en la Mozilla Public License o
MPL, versión 1.1.
De acuerdo con los términos definidos anteriormente el proyecto es factible legalmente.
20 SUN MICROSYSTEMS, INC. CONTRATO DE LICENCIA DE CÓDIGO BINARIO, Fuente:
http://www.java.com/es/download/license.jsp
56
2. ANÁLISIS
Basados en la metodología para el desarrollo de un Data Warehouse elaborada por Ralph Kimball
para ejecutar proyectos de inteligencia de negocios se debe satisfacer con los siguientes ítems:
Planeación y administración del proyecto
Análisis de los requerimientos
Modelamientos dimensionales
Diseño técnico de la arquitectura
Procesos de ETL ( Extracción, Transformación y Carga)
Selección e instalación de productos
Características de aplicaciones para clientes finales
Mantenimiento y crecimiento de un data warehouse
El cual se establece claros procesos para todo el ciclo del desarrollo del proyecto (Ver ilustración
8), garantizando la calidad y eficiencia de la solución de inteligencia de negocios en las ventas de
calzado a través de sucursales.
2.1 REQUERIMIENTOS
Los requerimientos son descritos a través de un listado general, el detalle de cada uno de los
mismos y un diagrama de requerimientos con la consolidación.
2.1.1 Listado de requerimientos Los requerimientos del negocio se describen a continuación:
Valor de ventas por productos
Valor de ventas por vendedor
Valor de ventas por clientes
Valor de ventas a través del tiempo
Cantidad de productos vendidos
Cantidad de productos vendidos por vendedor
Cantidad de productos vendidos por cliente
Autenticación de usuarios
57
2.1.2 Detalle de requerimientos Requerimiento 001
# Requerimiento 001 Versión 1.0
Nombre Valor de ventas por productos
Descripción Esta consulta permite explorar el valor de las ventas por productos
a nivel general o por cada sucursal, discriminando estas ventas por
sus referencias de productos.
Prioridad Alta
Tipo Funcional
Fuente
Tabla 3: Requerimiento 001
Requerimiento 002
# Requerimiento 002 Versión 1.0
Nombre Valor de ventas por vendedor
Descripción Esta consulta permite explorar el valor de las ventas por vendedor
en general o por cada sucursal, discriminando estas ventas por
vendedor. Se muestra la información de las ventas de cada
vendedor de la más alta a la más baja.
Prioridad Alta
Tipo Funcional
Fuente
Tabla 4: Requerimiento 002
58
Requerimiento 003
# Requerimiento 003 Versión 1.0
Nombre Valor de ventas por clientes
Descripción Esta consulta permite explorar el valor de las ventas por clientes en
general o por cada sucursal, discriminando estas ventas por los
diferentes clientes.
Prioridad Alta
Tipo Funcional
Fuente
Tabla 5: Requerimiento 003
Requerimiento 004
# Requerimiento 004 Versión 1.0
Nombre Valor de ventas a través del tiempo
Descripción Esta consulta permite explorar el valor de las ventas en general o
por cada sucursal, discriminando estas ventas por las fechas de
venta. En el reporte se analiza las ventas por año, semestre,
trimestre, mes. Determinando donde se han evidenciado mayor
ventas y en qué momentos menores ventas.
Prioridad Alta
Tipo Funcional
Fuente
Tabla 6: Requerimiento 004
59
Requerimiento 005
# Requerimiento 005 Versión 1.0
Nombre Cantidad de productos vendidos
Descripción Se muestran las cantidades de productos vendidos que se han
realizado en general o por cada sucursal, discriminando por marca,
por color, por talla o por referencia.
Prioridad Alta
Tipo Funcional
Fuente
Tabla 7: Requerimiento 005
Requerimiento 006
# Requerimiento 006 Versión 1.0
Nombre Cantidad de productos vendidos por vendedor
Descripción Se muestran las cantidades de productos vendidos que se han
realizado en general o por cada sucursal, discriminando por cada
vendedor.
Prioridad Alta
Tipo Funcional
Fuente
Tabla 8: Requerimientos 006
60
Requerimiento 007
# Requerimiento 007 Versión 1.0
Nombre Cantidad de productos vendidos por cliente
Descripción Se muestran las cantidades de productos vendidos que se han
realizado en general o por cada sucursal, discriminando por cada
cliente.
Prioridad Alta
Tipo Funcional
Fuente
Tabla 9: Requerimiento 007
Requerimiento 020
# Requerimiento 020 Versión 1.0
Nombre Autenticación de usuarios
Descripción Se requiere crear un componente web que permita la
autenticación de usuarios mediante la validación de usuario y
contraseña contra una base de datos el cual le permitirá ingresar al
sistema donde podrá ver los reportes del aplicativo.
Prioridad Alta
Tipo Funcional
Fuente No aplica
Tabla 10: Requerimiento 020
61
2.1.3 Diagrama de requerimientos
Ilustración 11: Diagrama de requerimientos
62
2.2 DIMENSIONES
Se definen las dimensiones que soportan los requerimientos definidos. Las siguientes secciones
relacionan las tablas diseñadas para la base de datos con su dimensión correspondiente. Estas
dimensiones junto con las tablas de hechos cumplen con la granularidad de la información en el
datamart.
2.2.1 Listado de dimensiones Las dimensiones generadas para dar cumplimiento a la necesidad del negocio se describen a
continuación:
DimProductos
DimClientes
DimVendedores
DimFechas
2.2.2 Detalle de las dimensiones
Dimensión Productos
Contiene la información acerca de cada producto.
Campo-Nombre Tipo/Tamaño Descripción Llave primaria
idproducto numeric(18, 0) Llave primaria de producto Si
nombre_producto nvarchar(255) Nombre del producto No
referencia nvarchar(255) Referencia del producto No
fecha_creacion Datetime Fecha de creación del registro No
usuario_creacion nvarchar(255) Usuario que crea el registro No
estado Int Estado del producto No
63
idtipo nvarchar(255) Tipo de producto No
idcolor nvarchar(255) Color del producto No
valor_unitario numeric(18, 2) Valor del producto No
valor_iva numeric(18, 2) Iva del producto No
sucursal nvarchar(255) sucursal No
Tabla 11: Dimensión de la tabla productos
Dimensión Clientes
Contiene la información de los clientes que maneja la empresa.
Campo-Nombre Tipo/Tamaño Descripción Llave primaria
id numeric(18, 0) Llave primaria de cliente Si
idcliente numeric(18, 0) Identificación del cliente No
Sucursal nvarchar(255) Sucursal No
nombre_cliente nvarchar(255) Nombre del cliente No
apellido_cliente nvarchar(255) Apellido del cliente No
tipo_identificacion nvarchar(255) Tipo de identificación del cliente No
identificacion numeric(18, 0) Número de identificación No
fecha_nacimiento datetime Fecha de nacimiento No
usuario_creacion nvarchar(255) Usuario creador del registro No
fecha_creacion datetime Fecha de creación del registro No
estado int Estado del cliente No
Tabla 12: Dimensión de la tabla clientes
64
Dimensión Vendedor
Contiene la información de los vendedores de la empresa.
Campo-Nombre Tipo/Tamaño Descripción Llave primaria
idvendedor numeric(18, 0) Llave primaria de vendedor Si
nombre_vendedor nvarchar(255) Nombre del vendedor No
apellido_vendedor nvarchar(255) Apellido del vendedor No
identificacion nvarchar(255) Identificación del vendedor No
fecha_creacion datetime Fecha de creación del registro No
usuario_creacion nvarchar(255) Usuario de creación del registro No
estado numeric(2, 0) Estado del vendedor No
sucursal nvarchar(255) Sucursal a la que pertenece el vendedor No
Tabla 13: Dimensión de la tabla vendedores
Dimensión Fechas
Contiene información de las fechas en las que se realizan las ventas. Esta tabla contiene
información sobre años, semestres, trimestres, meses y días. Se tienen estos diferentes campos
para una misma fecha para permitir al usuario navegar por la dimensión dependiendo del grado
de profundidad de fecha que prefiera.
Campo-Nombre Tipo/Tamaño Descripción Llave primaria
skfecha Numeric(18,0) Llave primaria de fechas Si
Date Varchar(30) Formato de fecha No
Day Varchar(30) Descripción del día que se hizo la venta No
DaySuffix Varchar(30) Contiene información del día No
65
DayOfWeek Varchar(30) Contiene información del día de la
semana
No
DOWInMonth Int4 Contiene información del mes No
DayOfYear int Contiene información de un día del año No
WeekOfYear tinyint Contiene información de semana del año No
WeekOfMonth tinyint Contiene información de semana del mes No
Month tinyint Contiene información del mes No
MonthName varchar(9) Contiene información del nombre del
mes
No
Quarter tinyint Contiene información del trimestre No
QuarterName varchar(6) Contiene información del nombre del
trimestre
No
Year char(4) Contiene información del año en el que
se hizo la venta
No
StandardDate varchar(10) Contiene información del día No
HolidayText varchar(50) Contiene información de los días festivos No
Tabla 14: Dimensión de la tabla fechas
66
2.3 HECHOS
2.3.1 Listado de tablas de hechos En este datamart hay un solo hecho: el hecho de la transacción. Este hecho es el valor de una
venta: también es llamado una medida. Esta medida cumple con la granularidad definida, es decir
es el valor de una transacción individual de una venta.
Ventas
2.3.2 Detalle de las tablas de hechos
Tabla de hechos de ventas Registra información de las ventas que hace las sucursales de la fábrica de calzado. Existen campos
que corresponden a llaves foráneas para relacionar esta tabla con sus dimensiones.
Campo-Nombre Tipo/Tamaño Descripción Llave primaria
idventa numeric(18, 0) Llave primaria de ventas Si
sucursal nvarchar(255) Sucursal Si
Idvendedor numeric(18, 0) Id de vendedor Si
idcliente numeric(18, 0) Id de cliente Si
valor_total numeric(18, 2) Medida que muestra el valor que hizo a
un cliente de un producto determinado
en una fecha específica.
No
valor_iva numeric(18, 2) Valor del Iva del producto No
valor_bruto numeric(18, 2) Valor bruto No
fecha_venta Datetime Fecha de la venta Si
usuario_creacion nvarchar(255) Usuario creador del registro No
67
estado int Estado de la venta No
idproductosvendido numeric(18, 0) Código de los productos vendidos Si
idproducto numeric(18, 0) Id de producto Si
cantidad Int Cantidad de productos Si
valor_total_iva_pv numeric(18, 2) Valor del producto con iva Si
valor_total_pv numeric(18, 2) Valor total precio de venta Si
promocion nvarchar(255) Descuento del producto No
skfecha numeric(18, 0) Id de skfecha Si
skhora numeric(18, 0) Id de skhora No
Tabla 15: Tabla de hechos de ventas
68
3. DISEÑO
3.1 DISEÑO DEL MODELO MULTIDIMENSIONAL
Luego de haber realizado el levantamiento de requerimientos y determinadas las dimensiones y la
tabla de hechos que serán utilizadas se diseña el diagrama multidimensional. Este diagrama es de
tipo estrella dando un mayor rendimiento por la cantidad de información que se maneja, una
mayor claridad del diseño y mejor organización de los datos. A continuación se describe de forma
gráfica la solución implementada:
Ilustración 12: Diagrama multidimensional del datamart
69
3.2 DATOS
Los datos constituyen la información del data warehouse, se refieren al componente principal del
proceso o los procesos que llevan a la construcción de la aplicación final. Para el análisis de los
datos, se comienza por analizar los datos fuentes que manejan los procesos de la empresa, el tipo
de la base de datos y la estructura de las tablas.
Los datos totales están actualmente compuestos de tres sucursales (Centro, Norte, Sur), las cuales
cada una cuenta con un sistema OLTP, el cual gestiona una aplicación transaccional de cada punto
de venta permitiendo realizar la gestión de las ventas que se generan.
Cada una de las sucursales maneja su sistema OLTP de forma independiente almacenando la
información en una base de datos elaborada en Postgresql a través de un modelo E-R, con las
tablas necesarias para dar gestión a la información de clientes, productos, vendedores, ventas,
detalles de las ventas y tabla paramétrica con los listados necesarios para el manejo del aplicativo
como lista de tipo de documentos, tipos de colores, tipo de marcas, tipo de tallas.
Tanto la sucursal Centro, Norte y Sur cuentan con este sistema y un aplicativo web que gestiona
dicha información, adicionalmente este aplicativo contiene en su estructura unos servicios web
que podrán ser consumidos por cualquier aplicativo para obtener la información que contiene.
El diagrama de la base de datos relacional de la sucursal “Centro” se describe la siguiente
ilustración.
70
Ilustración 13: Diagrama E-R de la base de datos "VentaCentro"
71
3.3 MAPEO DE DATOS AL MODELO MULTIDIMENSIONAL
Para cargar los datos en el modelo multidimensional se requiere la información de las tablas del
modelo E-R mencionadas anteriormente de cada una de las sucursales. En la siguiente tabla se
pueden ver las tablas del modelo multidimensional y sus respectivas fuentes de datos.
TABLAS DE MODELO
MULTIDIMENSIONAL
FUENTE
SUCURSAL
CENTRO
FUENTE
SUCURSAL
NORTE
FUENTE
SUCURSAL
SUR
OTRAS
FUENTES
DIM_PRODUCTO WEB SERVICES
PRODUCTO
SERVICIO WEB
PRODUCTO
SERVICIO WEB
PRODUCTO
NO APLICA
DIM_VENDEDOR SERVICIO WEB
VENDEDOR
SERVICIO WEB
VENDEDOR
SERVICIO WEB
VENDEDOR
NO APLICA
DIM_CLIENTE SERVICIO WEB
CLIENTE
SERVICIO WEB
CLIENTE
SERVICIO WEB
CLIENTE
NO APLICA
DIM_FECHAS NO APLICA NO APLICA NO APLICA SCRIPT_FECHAS.SQL
DIM_HORAS NO APLICA NO APLICA NO APLICA SCRIPT_HORAS.SQL
VENTAS SERVICIO WEB
VENTAS,
PRODUCTOS-
VENDIDOS,
TIPO-COLOR,
TIPO-TALLA,
TIPO-MARCA
SERVICIO WEB
VENTAS,
PRODUCTOS-
VENDIDOS,
TIPO-COLOR,
TIPO-TALLA,
TIPO-MARCA
SERVICIO WEB
VENTAS,
PRODUCTOS-
VENDIDOS,
TIPO-COLOR,
TIPO-TALLA,
TIPO-MARCA
NO APLICA
Tabla 16: Mapeo modelo destino vs fuentes de datos
72
3.4 BACK ROOM
Es el área del data warehouse responsable de extraer y preparar los datos. Aquí se explicará cómo
se realizó el proceso ETL en la bodega central de información.
Se parte de los datos fuentes en los sistemas de información de cada sucursal de la empresa. Una
de las políticas del datawarehousing es no modificar los sistemas independientes pues se estarían
alterando sus procesos de negocios y de esta forma los procesos OLTP.
Extracción: Las tres sucursales manejan internamente una base de datos elaborada en Postgresql
en sus sistemas de información de ventas. En el proyecto se hará una extracción de la información
de las diferentes tablas que interesan para el desarrollo del modelo multidimensional de estrella.
Adicionalmente cada sucursal elaborará servicios web desplegados dentro de un servidor de
aplicaciones junto con el aplicativo OLTP y expuesto por medio de un WSDL, a través de un
protocolo HTTPS. Cada web services recopila información de las tablas: ventas, productos-
vendidos, productos, clientes, vendedores.
La herramienta de ETL será de tipo integrations services el cual nos permitirá realizar las
conexiones a los diferentes web services publicados por las diferentes sucursales para recopilar
toda la información, adicionalmente, se realizará la creación de tareas programadas para que
ejecuten las conexiones en un determinado tiempo (se configurará una vez al día, permitirá ser
modificado), de los proyectos configurados de integrations services, lo que aportará mantener
actualizada la información contenida en la bodega para sus posteriores ejecuciones de reportes.
73
Transformación: Para la transformación de los datos luego de obtener los datos de los web
services, se realizará la adecuación de la información en caso de tener anomalías o formatos
diferentes a los definidos en el datamart.
Carga: Luego de tener los datos consultados y transformados (de acuerdo a la necesidad), se hace
el proceso de carga en la estrella o modelo multidimensional que consiste en tomar estos datos
fuentes y guardarlos en la estrella de tal forma que queden listos para que se puedan utilizar
herramientas OLAP o de Análisis Multidimensionales. Finalmente, los datos extraídos y
transformados son cargados en la base de datos del modelo multidimensional descrito en la
ilustración 12.
3.5 FRONT ROOM
El datamart de ventas está estructurado de forma que se puede ver la información
multidimensional de las ventas con respecto a los clientes, productos, vendedores y en medidas
de tiempo (por día, mes, trimestre, semestre y año). Esta información se visualizará en el
aplicativo elaborado como presentación de la implementación del presente proyecto.
3.6 DEFINICIÓN DE ACTORES
Los actores que interactuaran con el sistema que permitirá la visualización de los reportes como
implementación del presente proyecto se han identificado como:
Administrador: Es el usuario que tendrá el acceso de crear los usuarios en el sistema.
Gerente Ventas: Es aquella persona encargada de visualizar los reportes de ventas.
Presidente: Es aquella persona encargada de visualizar todos los reportes de ventas, productos,
vendedores y clientes.
74
3.7 INFRAESTRUCTURA PARA EL DATA WAREHOUSE
La suite sobre la cual se dará la implementación es en Microsoft Bussiness Intelligence Study for
Consulting SQL SERVER 2012, basado en una licencia gratuita para implementación de proyectos
en universidades. Esta suite tiene distintas aplicaciones que serán utilizadas de acuerdo a la
necesidad del proyecto.
La base de datos de datamart se implementara en un servidor de SQL SERVER 2012.
La herramienta que nos permitirá realizar el proceso de ETL es: SSIS (Sql Server Integrations
Services).
La aplicación que nos permitirá realizar las tareas programadas o configuraciones de los Jobs es:
Sql Server Agent.
La aplicación que nos soportará la bodega de datos (datamart) es: SSAS (Sql Server Analytic
Services).
La herramienta que nos gestionará los reportes a nivel de servidor de reportes y generador de
informes es: SSRS (Sql Server Reporting Services).
La aplicación web de visualización de reportes estará implementada sobre un servidor Glassfish
4.0.
Este conjunto de herramientas nos permitirá dar solución al presente proyecto a nivel de
infraestructura de software.
75
4. IMPLEMENTACIÓN
4.1 PROCESO DE ETL
Para el proyecto se determinó utilizar una herramienta de ETL para las necesidades de extracción,
transformación y cargue de la información de las diferentes sucursales para el abastecimiento de
la bodega de datos en la ejecución del proyecto.
La herramienta consume los servicios web desarrollados en lenguaje de programación Java, cuya
función es consultar las distintas bases de datos de cada sucursal, por lo cual, extrae los datos de
las determinadas fuentes, adicionalmente realiza las transformaciones requeridas o necesarias de
los datos y finalmente carga los datos al modelo bidimensional implementado.
La publicación del servicio web esta publicado por medio de un protocolo seguro “https”, con el
fin de garantizar la confiabilidad de la información que se transporta.
Ilustración 14: Wsdl con los métodos expuestos de la sucursal centro
76
Luego de ubicar la publicación de los servicios, se opta por realizar la configuración de la conexión
hacia el WSDL, por medio del editor de conexiones de http del aplicativo de ETL. En este se
especifica la ruta del WSDL y se incorpora el certificado cliente que nos permite resolver la llave de
seguridad del protocolo donde se encuentra el servicio con el fin de garantizar que se tiene el
permiso para consumir la información.
Ilustración 15: Configuración de conexión al wsdl
Se crea un archivo con el nombre sucursalcentro.ctr el cual contiene la llave publica que nos
permitirá conectar con el wsdl publicado en la sucursal y de esta manera contener de forma
segura la información. Para este proyecto son certificados creados y verificados internamente sin
una entidad que lo garantice, debido a que es un prototipo lo que se presenta en la solución del
proyecto dentro de una red local. Para una implementación sobre un ambiente real, dado que
cada sucursal estará en punto distintos de la ciudad, esta si presentará un costo para obtener los
certificados.
Ilustración 16: Certificado de seguridad para la conexión al Wsdl de sucursal centro
Posteriormente de resolver la conexión por medio del protocolo seguro al wsdl que contiene los
diferentes métodos que nos permitirán obtener la información de los distintos clientes,
vendedores, productos y ventas., así podemos realizar la inicialización de los procesos de ETL.
77
4.1.1 ETL de dimensión cliente
El proceso de ETL (Extracción, transformación y carga) creado para la sucursal centro, accede a la
última información registrada de los diferentes clientes que tiene la sucursal, en este ítem se
especificará todo el paso a paso y en detalle el funcionamiento del Web Services, así como la
asignación del resultado en un archivo XML y finalmente el cargue de los datos por medio de la
tarea del flujo de datos. Ver la ilustración a continuación.
Ilustración 17: Proceso completo ETL para clientes
Configuración de tarea de script para borrado
Ejecutar SQL TASK borrado clientes: La primera tarea que ejecuta en el proceso anterior de ETL
(Extracción, transformación y carga) es eliminar los datos que encuentre de clientes para la
sucursal centro, dentro de la bodega de datos, esto con el fin de mantener siempre la última
versión de la información registrada de los clientes en la sucursal cada vez que se ejecute el
proceso. A continuación se puede ver el script utilizado para dicha acción.
78
Ilustración 18: Tarea de script para eliminación de Clientes
Configuración de tarea servicio web
Web Service Task Cliente Centro: La tarea del proceso ETL del web services, se conforma de
subtareas las cuales se configuran en las pestañas especificadas por el editor:
General: En la siguiente ilustración se visualiza los ítems que deben ser configurados para el
correcto funcionamiento de la tarea Web Services, en esta pestaña se especifica la ruta del archivo
WSDL (Web Service Description Language) llamado “NotificacionClienteImplementService.wsdl”
que proporciona la información de los clientes, este archivo es tomado de la publicación original
donde está expuesto el servicio web.
La conexión es segura ya que usa el protocolo HTTPS (Hypertext Transfer Protocol Secure) para
transferir la información de la base de datos de la sucursal llamada “VentaCentro”.
Ilustración 19: Configuración general de la tarea Web Services para clientes
79
Input: En la siguiente pestaña podemos seleccionar el método de entrada del servicio web
llamado “notificacionClientes”, relacionado con el servicio “NotificacionVentaImplementService”
que será utilizado para consumir la información de los clientes.
Ilustración 20: Configuración de entrada de la tarea Web Services para clientes
80
Output: Por último, en esta pestaña podemos configurar el archivo xml, que se dispondrá para
devolución del servicio web, con el nombre de “ResultadoClienteCentro” en respuesta a la
ejecución del método anterior dando por concluido la configuración general del web services para
clientes.
Ilustración 21: Configuración de salida de la tarea Web Services para clientes
81
Configuración de tarea de xml
XML Task Cliente Centro: La siguiente ilustración se configuran las propiedades aplicadas al
documento xml, este realizara una validación mediante la operación de tipo XSLT. También se
especifica que cada vez que se ejecute esta tarea se sobrescribirá el archivo
ResultadoClienteCentro.xml
Ilustración 22: Configuración de entrada de la tarea Xml para clientes
82
Configuración de la tarea de flujo de datos
Data Flow Task Cliente Centro: La siguiente ilustración finalmente es del flujo de datos del servicio
web implementado el cual inserta la información obtenida por el web services hacia la bodega de
datos. En este ítem lo que se toma es la información que se obtuvo y se asigna campo a campo
con la estructura de dimensión cliente del datamart.
Ilustración 23: Configuración de tarea de flujo de datos de clientes
XML Source: En esta tarea se configura la ruta en donde quedó alojado el archivo xml llamado
“ResultadoClienteCentro”, quien contiene la información del consumo del web services. En la
sesión del XSD es donde se especifica el archivo que se utilizara para comprobar la estructura de
los datos con sus respectivos tipos de datos propios al datamart para cuando haga la inserción no
ocurra ningún error.
83
Ilustración 24: Configuración de tarea XML para flujo de datos de clientes
Tarea Derived column: El componente nos permite generar la concatenación de los campos id-
clientes y nombre-sucursal, en uno solo para la generación de la llave primaria de la tabla con el
fin de no repetir registros entre los diferentes clientes obtenidos por las diferentes sucursales.
84
4.1.2 ETL de dimensión producto
La siguiente ilustración corresponde al proceso de ETL (Extracción, transformación y carga) creado
para la sucursal centro donde se accede a la última información que encuentra de los diferentes
productos que maneja la empresa, en este ítem se especificará en detalle el funcionamiento del
Web Services, como de la asignación del resultado en un archivo XML y finalmente el cargue de los
datos por medio de la tarea del flujo de datos.
Ilustración 25: Proceso completo ETL Productos
Configuración de tarea script para borrado de productos
Ejecutar SQL TASK borrado productos: La primera tarea que ejecuta en el proceso ETL es eliminar
los datos que encuentre de los diferentes productos que contiene la sucursal centro, dentro de la
bodega de datos, esto con el fin de mantener siempre la última versión de la información
registrada de los productos de la empresa. A continuación se puede ver el script utilizado para
dicha acción.
Ilustración 26: Script de eliminación Productos
85
Configuración de tarea de web services de productos
Web Service Task Productos Centro: La tarea de web services del proceso ETL se conforma de
subtareas las cuales se configuran en las pestañas especificadas por el editor:
General: En la siguiente ilustración se visualiza los ítem que deben ser configurados para el
correcto funcionamiento de la tarea del Web Services, en esta pestaña se especifica la ruta del
archivo WSDL llamado “NotificacionProductoImplementService” que proporciona la información
necesaria de cada uno de los productos, este archivo es tomado de la publicación original donde
está expuesto el servicio web.
La conexión es segura ya que usa el protocolo HTTPS para transferir la información.
Ilustración 27: Configuración general de la tarea Web Services para productos
86
Input: En ítem se especifica el método de entrada del servicio web llamado
“notificacionProductos”, relacionado con el servicio “NotificacionVentaImplementService”, que
será utilizado para consumir la información de los productos.
Ilustración 28: Configuración de entrada de web services de productos
Output: Por último, en esta pestaña podemos configurar el archivo xml, que se dispondrá para
devolución del servicio web, con el nombre de “ResultadoProductoCentro” en respuesta a la
ejecución del método anterior dando por concluido la configuración general del web services para
clientes.
Ilustración 29: Configuración de salida de tarea web services de productos
87
Configuración de tarea de xml
XML Task Producto Centro: La siguiente ilustración contiene las propiedades configuradas al
documento xml mediante la operación denominada “ResultadoProductoCentroSecondOperand”.
Ilustración 30: Configuración de tarea xml de productos
Configuración de flujo de datos de productos
Data Flow Producto Centro: La siguiente ilustración es del flujo de datos del servicio web
implementado.
Ilustración 31: Configuración de tarea de flujo de datos para productos
88
XML Source: En esta imagen podemos ver la ruta en la que quedó alojado el archivo xml llamado
“ResultadoProductoCentro”, quien contiene la información del consumo del web services. En la
sesión del XSD es donde se especifica el archivo que se utilizara para comprobar la estructura de
los datos con sus respectivos tipos de datos propios al datamart para cuando haga la inserción no
ocurra ningún error.
Ilustración 32: Configuración de tarea XML para flujo de datos de productos
Tarea Derived column: El componente nos permite generar la concatenación de los campos id-
clientes y nombre-sucursal, en uno solo para la generación de la llave primaria de la tabla con el
fin de no repetir registros entre los diferentes productos obtenidos por las diferentes sucursales.
89
4.1.3 ETL de dimensión vendedor
La presente ilustración nos permite ver el proceso de extracción, transformación y carga de datos
ETL (Extracción, transformación y carga) que se ha creado para la sucursal centro donde se accede
a la última información relacionada con los diferentes vendedores que maneja la empresa, en este
ítem se especificará en detalle el funcionamiento del Web Services, como de la asignación del
resultado en un archivo XML y finalmente el cargue de los datos por medio de la tarea del flujo de
datos.
Ilustración 33: Proceso ETL completo Vendedores
Configuración de tarea script para borrado de vendedor
Ejecutar SQL TASK borrado vendedor: La primera tarea que ejecuta en el proceso ETL es eliminar
los datos que encuentre de cada vendedor, especificando que los datos a borrar correspondan a la
sucursal centro, dentro de la bodega de datos, esto con el fin de mantener siempre la última
versión de la información registrada de los vendedores que maneja de la empresa. A continuación
se puede ver el script utilizado para dicha acción.
90
Ilustración 34: Script de eliminación Vendedores
Configuración de tarea de web services de vendedores
Web Service Task Vendedores Centro: La tarea de web services del proceso ETL se conforma de
subtareas las cuales se configuran en las pestañas especificadas por el editor:
General: En la siguiente ilustración se visualiza los ítem que deben ser configurados para el
correcto funcionamiento de la tarea del Web Services, en esta pestaña se especifica la ruta del
archivo WSDL llamado “NotificacionVendedorImplementService” que proporciona la información
necesaria de cada uno de los vendedores, este archivo es tomado de la publicación original donde
está expuesto el servicio web.
La conexión es segura ya que usa el protocolo HTTPS para transferir la información.
Ilustración 35: Configuración general de la tarea Web Services para vendedores
91
Input: En ítem se especifica el método de entrada del servicio web llamado
“NotificacionVendedores”, relacionado con el servicio “NotificacionVentaImplementService”, que
será utilizado para consumir la información de los vendedores.
Ilustración 36: Configuración de entrada de web services de Vendedores
Output: Por último, en esta pestaña podemos configurar el archivo xml, que se dispondrá para
devolución del servicio web, con el nombre de “ResultadoVendedorCentro” en respuesta a la
ejecución del método anterior dando por concluido la configuración general del web services para
vendedores.
Ilustración 37: Configuración de salida de tarea web services de vendedores
92
Configuración de tarea de xml
XML Task Vendedor Centro: La siguiente ilustración contiene las propiedades configuradas al
documento xml mediante la operación denominada “ResultadoVendedorCentroSecondOperand”.
Ilustración 38: Configuración de tarea xml de vendedores
Configuración de flujo de datos de vendedores
Data Flow vendedor Centro: La siguiente ilustración es del flujo de datos del servicio web
implementado.
Ilustración 39: Configuración de tarea de flujo de datos para vendedores
93
XML Source: En esta imagen podemos ver la ruta en la que quedó alojado el archivo xml llamado
“ResultadoVendedorCentro”, quien contiene la información del consumo del web services. En la
sesión del XSD es donde se especifica el archivo que se utilizara para comprobar la estructura de
los datos con sus respectivos tipos de datos propios al datamart para cuando haga la inserción no
ocurra ningún error.
Ilustración 40: Configuración de tarea XML para flujo de datos de vendedores
94
4.1.4 ETL de dimensión de fechas
Primero creamos la Tabla de dimensión tiempo la cual denominamos DIM_TIEMPO. El siguiente es
el script de creación.
/*Creación de la tabla*/
create table DIM_TIEMPO
(
FechaSK int not null,
Fecha date not null,
Año smallint not null,
Trimestre smallint not null,
Mes smallint not null,
Semana smallint not null,
Dia smallint not null,
DiaSemana smallint not null,
NTrimestre char(7) not null,
NMes char(15) not null,
NMes3L char(3) not null,
NSemana char(10) not null,
NDia char(6) not null,
NDiaSemana char(10) not null
constraint PK_DIM_TIEMPO PRIMARY KEY CLUSTERED
(
Fecha asc
)
)
Luego ejecutamos el script de carga de los datos.
/*Script de carga*/
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 inicial por si no coincide con los del servidor
SET DATEFORMAT dmy
SET DATEFIRST 1
BEGIN TRANSACTION
--Borrar datos actuales, si fuese necesario
--TRUNCATE TABLE FROM DI_TIEMPO
--Rango de fechas a generar: del 01/01/2010 al 31/12/2020
95
SELECT @FechaDesde = CAST('20100101' AS smalldatetime)
SELECT @FechaHasta = CAST(CAST(YEAR(GETDATE())+10 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 PAnalisys.dbo.DIM_TIEMPO
(
FechaSK,
Fecha,
Año,
Trimestre,
Mes,
Semana,
Dia,
DiaSemana,
NTrimestre,
NMes,
NMes3L,
NSemana,
NDia,
NDiaSemana
) VALUES
(
@FechaAAAAMMDD,
@FechaDesde,
@Año,
@Trimestre,
@Mes,
@Semana,
@Dia,
@DiaSemana,
@NTrimestre,
@NMes,
@NMes3l,
96
@NSemana,
@NDia,
@NDiaSemana
)
--Incremento del bucle
SELECT @FechaDesde = DATEADD(DAY, 1, @FechaDesde)
END
COMMIT TRANSACTION
97
4.1.5 ETL de tabla de hechos de ventas
A continuación ilustramos, como debe fluir el proceso de ETL (Extracción, transformación y carga)
que se ha creado para acceder a la última información de todas las ventas que se han registrado
dada una fecha determinada, en este ítem se especificará todo el paso a paso y en detalle el
funcionamiento del Web Services, así como la asignación del resultado en un archivo XML y
finalmente el cargue de los datos por medio de la tarea del flujo de datos. Ver la ilustración a
continuación.
Ilustración 41: Proceso completo ETL Ventas Centro
Configuración de tarea de web services de ventas
Web Service Task Ventas Centro: La tarea de web services del proceso ETL se conforma de
subtareas las cuales se configuran en las pestañas especificadas por el editor:
General: En la siguiente ilustración se visualiza los ítem que deben ser configurados para el
correcto funcionamiento de la tarea del Web Services, en esta pestaña se especifica la ruta del
archivo WSDL llamado “NotificacionVentaImplementService” que proporciona la información
necesaria de cada uno de las ventas de la sucursal, este archivo es tomado de la publicación
original donde está expuesto el servicio web.
La conexión es segura ya que usa el protocolo HTTPS para transferir la información
98
Ilustración 42: Configuración general de la tarea Web Services para ventas
Input: En ítem se especifica el método de entrada del servicio web llamado “NotificacionVentas”,
relacionado con el servicio “NotificacionVentaImplementService”, que será utilizado para consumir
la información de los vendedores.
Ilustración 43: Configuración de entrada de web services de Ventas
99
Output: Por último, en esta pestaña podemos configurar el archivo xml, que se dispondrá para
devolución del servicio web, con el nombre de “ResultadoVentaCentro” en respuesta a la
ejecución del método anterior dando por concluido la configuración general del web services para
ventas.
Ilustración 44: Configuración de salida de tarea web services de ventas
Configuración de tarea de xml
XML Task Ventas Centro: La siguiente ilustración contiene las propiedades configuradas al
documento xml mediante la operación denominada “ResultadoVentaCentroSecondOperand”.
Ilustración 45: Configuración de tarea xml de ventas
100
Configuración de flujo de datos de vendedores
Data Flow vendedor Centro: La siguiente ilustración es del flujo de datos del servicio web
implementado
Ilustración 46: Configuración de tarea de flujo de datos para ventas
XML Source: En esta imagen podemos ver la ruta en la que quedó alojado el archivo xml llamado
“ResultadoVentaCentro”, quien contiene la información del consumo del web services. En la sesión
del XSD es donde se especifica el archivo que se utilizara para comprobar la estructura de los datos
con sus respectivos tipos de datos propios al datamart para cuando haga la inserción no ocurra
ningún error.
101
Ilustración 47: Configuración de tarea XML para flujo de datos de ventas
102
4.2 PROCESO DE CREACIÓN DE DATA SOURCES VIEWS
El Data Sources View, es una vista que se crea para consultar y elegir determinados datos, así
como ocurre en el ambiente transaccional. La herramienta empleada es Analysis Services de SQL
server 2012.
Para iniciar el proceso de creación del Data Source Views, es importante tener creada previamente
la conexión al origen de datos.
Conexión al Origen de datos
En primer lugar creamos un proyecto de Analysis Services, en nuestro caso lo denominamos venta
Sucursal.
Una vez creado el proyecto procedemos a crear la conexión con el origen de datos, haciendo uso
del asistente. Borramos conexiones existentes y seleccionamos el motor de base de datos, el
nombre del servidor y luego la base de datos que vamos a utilizar como conexión, el tipo de
autenticación a la base de datos y finalmente se presiona el botón test de conexión.
Creación del Data Source View
Para iniciar este proceso seleccionamos la Opción New Data Sources View (Nueva vista del origen
de datos), y en este caso tendremos que elegir, primero la conexión y luego las tablas que vamos
a necesitar para fabricar nuestro cubo.
Dentro de estas tablas tenemos:
Cliente
Vendedor
Producto
Fechas
Ventas Elegimos un nombre a la vista que estamos creando, lo denominamos Venta sucursal View y presionamos finalizar. De esta manera el Analisys Service se conecta a nuestra base de datos y nos tiene la relación existente entre las tablas. La tabla Fechas aparece sin ninguna relación, la cual contiene fechas que corresponden a un rango de 2010 a 2020, que coinciden con las fechas en las que se efectuaron las ventas de cada sucursal. Es necesario que se haga manualmente la relación, hacia la tabla Ventas.
103
La presente ilustración nos representa el modelo que finalmente hemos creado.
Ilustración 48: Data Source View Venta Sucursal (Vista del origen de datos)
104
4.3 PROCESO DE CONSTRUCCION DEL CUBO
Para el proceso de creación del cubo, utilizamos la herramienta Analysis Services de SQL server
2012.
Es importante, antes de empezar a crear el cubo haber efectuado previamente la conexión al
origen de datos, después continuar con la creación de cada una de las tablas de dimensiones.
Creación de las tablas de Dimensiones
Seleccionamos la opción Dimensions, nueva dimensión, avanzamos con el asistente y nos
pregunta de dónde vamos a sacar nuestra dimensión, en nuestro caso de una tabla existente,
seleccionamos el Data Source View “Venta Sucursal View”.
Empezamos con la tabla clientes, nos pregunta cuál es la llave primaria, que es la que se va a
enlazar con las otras tablas, el nombre que se va a mostrar y si tiene algún atributo adicional para
agregar a nuestra dimensión se marca de lo contrario no es necesario. Este atributo nos va a
permitir reportear o categorizar los datos más adelante.
Cerramos nuestra dimensión y de la misma manera creamos las demás dimensiones para las
tablas vendedores, ventas y fechas y finalizar.
Creación del Cubo
Se deberá crear el cubo con las tablas existentes de la vista, es importante especificarle cual va a
ser la tabla de hechos que tiene los measure group (valores a calcular). En nuestro caso es la tabla
“Ventas”. La aplicación detecta como válidas las dimensiones ya existentes, si no lo hace se deberá
hacer un paso adicional para importar las dimensiones a nuestro cubo, seleccionar siguientes y por
último finalizar.
Adicionalmente, se incorpora al cubo las dimensiones que tienen relación con la tabla de hechos
en este caso las tablas
- Productos
- Clientes
- Vendedor
- Fechas
Se agregan entonces las Tablas así:
105
Clic derecho show tables, se selecciona y ok para agregar las tablas que él no agrego. Las tablas
Clientes, Vendedores y Fechas.
Una vez agregadas las tablas, agregamos las dimensiones Clientes, Vendedores, fechas, productos
Al agregarlas pinta el encabezado de las tablas en Azul, porque ya las reconoció como
dimensiones.
Si alguna de las dimensiones no está relacionada directamente con la tabla de hechos Ventas, es
necesario hacer un paso adicional:
Vamos a la ficha Uso de dimensión y allí vemos que algunas tablas no tienen relación directa con la
tabla de hechos. Para ello es necesario decirle como es dicha relación.
Si es relación referenciada, la tabla intermedia y la llave primaria de relación de cada una de las
tablas. Ok y lo mismo con las demás.
Es el momento de procesar el cubo para que carguen todos los datos al modelo bidimensional y
ver nuestro cubo trabajando. Para ello damos click en procesar, esperamos a que se efectué el
proceso y si todo marcha bien procesa nuestro cubo. En la siguiente ilustración encontramos el
cubo que se ha creado.
106
Ilustración 49: Cubo Venta Sucursal
4.4 PROCESO DE CREACION DE CALCULATIONS
Un dato calculado (Calculations) es el valor total de cada producto vendido ya que esto no se trae
directamente desde el datamart y es aquí donde se resuelve esa ecuación para tener el dato como
insumo al momento de generar reportes donde sea requerida esta información.
Ilustración 50: Proceso de creación de datos calculados
107
4.5 SEGURIDAD DEL APLICATIVO
Se implementa un aplicativo con arquitectura MVC utilizando leguaje de programación java y
framework Primefaces. Contiene una base de datos de seguridad y la respectiva gestión de los
usuarios y roles para poder acceder al contenido de los reportes.
Ilustración 51: Seguridad de aplicativo de reportes
Adicionalmente existe una seguridad adicional que es dada por el usuario que está en sesión en el
equipo el cual también asegura que la persona que visualice la información sea la idónea, ya que
los datos son de vital importancia para la compañía. Estos usuarios son asignados por el DLAP de
Windows.
Ilustración 52: Seguridad de servidor de reportes
108
4.6 REPORTES IMPLEMENTADOS
Los reportes implementados dan cumplimiento satisfactorio a los diferentes requerimientos
generados por el cliente.
4.6.1 Ventas en el tiempo
Se representa en un informe mediante gráficas lo ocurrido en las ventas generales. Donde se
describen las cantidades de ventas realizadas a través del tiempo. Por otra parte se grafica las
mismas ventas evaluadas por el valor total. Por última medida se genera una matriz detallada con
la información contenida en las ventas totales.
Ilustración 53: Informe consolidado de ventas
109
4.6.2 Ventas por clientes
Se representa en un informe mediante gráficas lo ocurrido en las ventas por clientes. Donde se
describen las cantidades de productos vendidos realizadas a los diferentes clientes. Por otra parte
se grafica las mismas ventas evaluadas por el valor total por clientes. Por última medida se genera
una matriz detallada con la información contenida en las ventas totales por clientes y sucursales.
Ilustración 54: Reporte consolidado por clientes
110
4.6.3 Informes de productos
Se representa en un informe mediante gráficas lo ocurrido en las ventas por productos. Donde se
describen las cantidades de productos vendidos por fechas. Por otra parte se grafica las mismas
ventas de productos evaluados por las cantidades totales por los tipo de calzado. Adicionalmente
se grafica la información de ventas por tallas de calzado. Por última medida se genera una matriz
detallada con la información contenida de los totales de productos.
Ilustración 55: Informe consolidado de productos
111
4.6.4 Ventas por vendedor
Se representa en un informe mediante gráficas lo ocurrido en las ventas por vendedores. Donde se
describen las cantidades de ventas realizadas por los vendedores inscritos a través del tiempo. Por
última medida se genera una matriz detallada con la información contenida en las ventas totales
realizadas por los vendedores.
Ilustración 56: Reporte consolidado por vendedores
112
4.7 GESTIÓN DE USUARIO
Se presenta la funcionalidad de gestionar usuarios dentro del aplicativo de presentación de
informes. La cual nos permite realizar consulta por los usuarios existentes en el sistema, modificar
la información de los mismos, crear nuevos usuarios con los diferentes roles que existen, como lo
son presidente, gerentes y/o administradores.
Ilustración 57: Gestión de usuarios en el sistema
113
4.8 DIAGRAMAS DE COMPONENTES
La siguiente figura representa el diagrama de componentes que muestra la conformación del
software, componentes y dependencias entre estas secciones, realizado para dar cumplimiento
con las especificaciones y requisitos del sistema.
Base de Datos SQL SERVER 2012SSIS (Sql Server Integrations
Services) ETL
SSAS (Sql Server Analytic Services)
Sql Server Agent JOBS SSRS (Sql Server Reporting Services)
Glassfish Server 4.0 Aplicación
Web
* *
*
*
* *
*
*
* *
Ilustración 58: Diagrama de componentes
114
4.9 DIAGRAMA DE DESPLIEGUE
La siguiente figura muestra la disposición de las particiones físicas del sistema de información y la
asignación de los componentes software a estas particiones. Es decir, las relaciones físicas entre
los componentes software y hardware en el sistema como planteamiento de solución de la
arquitectura y del aplicativo.
Servidor DBMS (SQL server 2012)
Servidor ETL Servidor Web
PC Sucursal Norte PC Sucursal Centro PC Sucursal Sur
B.DNorte B.DCentro B.DSur
**
*
*
* *
Servidor Modelo de Analisis
Servidor de Reportes Servidor Local B.D
Servidor Local Web
*
*
**
**
* *
**
* *
Publicación Reportes
Ilustración 59: Diagrama de despliegue
115
5. PRUEBAS
5.1 PRUEBAS DE CONFIGURACIÓN
ANEXO A. Manual del usuario.
El manual del usuario del aplicativo web de visualizador de reportes se encuentra adjunto en el CD
del proyecto.
ANEXO B. Manual del programador.
El manual del programador se encuentra adjunto en el CD del proyecto con el nombre de manual
del programador del aplicativo. Para entrar en detalle de la forma como fueron generados las
implementaciones de los reportes y el aplicativo a nivel de código puede ser inspeccionado el
manual del programador, el cual esta generado sobre la herramienta JAVADOC de java, cada
proyecto realizado tiene un archivo index.html que permite realizar la visualización general.
5.2 PRUEBAS FUNCIONALES Y CARGA
Para las pruebas de verificación y validación de las funcionalidades se crearon scripts de testing
con la herramienta badboy, la cual genera la secuencia de rutas que se ejecutan y se efectúan en
un archivo que permite ser exportado en formato .jmx extensión que puede ser ejecutada por la
herramienta Jmeter como solución para evaluación de pruebas funcionales y de carga la cual da
las siguientes estadísticas y gráficas.
Donde un número de 100 peticiones de muestras generan las medidas expresadas en
milisegundos.
No de muestras reporte de ventas. 100
Desviación: 1447
Rendimiento: 700,362 / minuto
Media: 1103
Mediana: 622
116
Se evidencia el resultado de las peticiones que se generan en el sistema al momento de ejecutar
un reporte de ventas y sus comportamientos de rendimiento gráficamente. Esta información nos
permite dar el aval de la funcionalidad aplicativo a nivel de pruebas de carga, generadas a partir de
requerimientos no funcionales con el fin de garantizar la eficacia y eficiencia del producto.
Ilustración 60: Reporte de pruebas funcionales de ventas
Ilustración 61: Reportes de pruebas gráficamente de ventas
117
No Muestras reporte clientes: 100
Rendimiento: 194,018 / minuto
Desviación: 3257
Media: 1480
Mediana: 551
Ilustración 62: Reporte de pruebas funcionales de clientes
118
Ilustración 63: Reportes de pruebas gráficamente de clientes
No Muestras reporte productos: 100 Rendimiento: 5633,803 / minuto Desviación: 9 Media: 26 Mediana: 25
Ilustración 64: Reportes de pruebas funcionales productos
119
Ilustración 65: Reportes de pruebas gráficamente de productos
120
6. CONCLUSIONES
En este proyecto se adquirió un conocimiento básico de la importancia de un sistema de
información gerencial para automatizar los procesos de la empresa y transformar los datos
en informes útiles para ayudar al gerente en la toma de mejores decisiones.
La información que le es proporcionada a un gerente debe estar relacionada con sus
tareas y responsabilidades, debe ser completa, clara, concisa y deberá contener todo lo
que se solicitó en un principio y como soporte final es indispensable documentar
claramente el requerimiento para evitar problemas futuros por mala interpretación.
Un datamart permite servir a un área del negocio como lo haría una bodega a varias áreas.
La especialización del datamart tiene un enfoque hacia la necesidad de un área específica,
que facilita la definición de la granularidad de los datos utilizados y sus dimensiones.
El data warehouse es mucho más que un producto. Es una serie de productos relacionados
entre sí que por medio de procesos bien definidos producen información útil para los
usuarios y nos permite Integrar y asociar información de varias fuentes en una sola. Para
que una solución de este tipo realmente tenga éxito, los usuarios deben aprovechar esta
información y ejecutar decisiones y acciones basadas en el conocimiento adquirido.
Para que un proyecto de data warehousing tenga éxito es necesario que exista una cultura
de información en la organización. Sin importar que tan minuciosa y grafica sea la
información si las decisiones son tomadas basadas en intuiciones y suposiciones y no hay
disposición al cambio, un proyecto de data warehouse está destinado a fracasar en la
organización.
121
7. BIBLIOGRAFIA
PRESSMAN, Roger. Ingeniería de Software. Un enfoque práctico. Editorial Mc Graw Hill. Quinta edición. 2012.
Mark Cade, Humphrey Sheil, Sun Certifed Enterprice Architek for java EE Study Guide. Editorial Pretice Hall. Segunda edición. Enero 2010.
Martin Kalin, Java Web Services: Up and Running. Editorial O`Really. 2013[3]
Mario Piattini. Web Services Security Development and Architecture: Theoretical and Practical Issues. Editorial Information Science Publishing, Enero 2010
Ramarao Kanneganti. SOA Security. Editorial Manning Publications, Enero 2008.
Anónimo (2008) “Norma Técnica Colombiana NTC 1486, Documentación. Presentación de tesis, Trabajos de Grado y Otros trabajos de Investigación. Colombia: ICONTEC.
Anónimo (2010) “Norma Técnica Colombiana NTC 5613, Referencias Bibliográficas, contenido, forma y estructura”. Colombia: ICONTEC. Jairo Amaya Amaya. (2003).Sistemas de Información. Colombia:Editorial SYC
Morales y Ariza(2004).Tecnología y trabajo asociado: en busca del equilibrio España:CIRIEC
Montes y Cepeda(2011). Sistema de Información gerencial: Editorial Nirvana
Ribas Lequerica Joan(2009). Web Services (edición especial) Guía práctica para usuarios Volumen 337 de Guías prácticas: Joan Ribas Lequerica
122
Bravo Santos Crescencio, Redondo Duque Miguel Ángel(2005). Sistemas interactivos y colaborativos en la Web: Ediciones de la Universidad de Castilla La Mancha
Chawla Rajesh, Chopra Vivek(2002). Servicios Web XML De programadores, para
programadores Profesional Series: Anaya Multimedia-Anaya Interactiva
Graham Steve, Davis Doug, Simeonov Simeon, Daniels Glen, Brittenham Peter,
Nakamura Yuichi, Fremantle Paul, Koenig Dieter, Zenther Claudia(2004). Building
Web Services with Java (XML, SOAP, USDL and UDDI): Sams Publishing
123
8. INFOGRAFIA
« BUSINESS INTELLIGENCE: CREACIÓN DEL PRIMER CUBO» [En línea].
Available: https://technet.microsoft.com/es-es/magazine/ee677579.aspx. [Último
acceso: 2015]
« GENERAR CIMIENTOS DE DATOS PARA UNA SOLUCIÓN DE BI» [En
línea] Available:https://technet.microsoft.com/es-es/magazine/2009.08.bipartii.aspx
[Último acceso: 2015]
« PLANEAR SU PRIMERA SOLUCIÓN DE MICROSOFT BI» [En línea].
Available: https://technet.microsoft.com/es-es/magazine/2009.08.bipartii.aspx
[Último acceso: 2015]
« CUÁL ES LA DIFERENCIA ENTRE MICROSOFT SSRS, SSIS Y SSAS»
[En línea]. Available: http://pyme.lavoztx.com/cul-es-la-diferencia-entre-microsoft-
ssrs-ssis-y-ssas-5599.html [Último acceso: 2015]
« SUN MICROSYSTEMS, INC. CONTRATO DE LICENCIA DE CÓDIGO
BINARIO» [En línea]. Available: http://www.java.com/es/download/license.jsp.
[Último acceso: 2015]
« SOA (Service Oriented Architecture)» [En línea]. Available:
http://desarrollandowebapps.blogspot.com/2013/02/soa-service-oriented-
architecture.html. [Último acceso: 2015].
« Industria del calzado » [En línea]. Available:
http://www.imebu.gov.co/hemeroteca/industria_calzado.pdf [Último acceso: 2014].
