SISTEMA PARA EL SOPORTE A LA TOMA DE … · 2.2.2 Conceptos De Data Warehouse ... 2.2.2.14...
230
SISTEMA PARA EL SOPORTE A LA TOMA DE DECISIONES ADMINISTRATIVAS EN LA FERRETERÍA METRÓPOLIS 84 LTDA. CESAR AUGUSTO OROZCO MANOTAS SANDRA MILENA PEÑARANDA SALAZAR MAURICIO RODRIGUEZ REBOLLEDO UNIVERSIDAD AUTÓNOMA DEL CARIBE FACULTAD DE INGENIERÍA PROGRAMA DE INGENIERÍA DE SISTEMAS BARRANQUILLA 2007
Transcript of SISTEMA PARA EL SOPORTE A LA TOMA DE … · 2.2.2 Conceptos De Data Warehouse ... 2.2.2.14...
1
SISTEMA PARA EL SOPORTE A LA TOMA DE DECISIONES
ADMINISTRATIVAS EN LA FERRETERÍA METRÓPOLIS 84 LTDA.
CESAR AUGUSTO OROZCO MANOTAS
SANDRA MILENA PEÑARANDA SALAZAR
MAURICIO RODRIGUEZ REBOLLEDO
UNIVERSIDAD AUTÓNOMA DEL CARIBE
FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS
BARRANQUILLA
2007
2
SISTEMA PARA EL SOPORTE A LA TOMA DE DECISIONES
ADMINISTRATIVAS EN LA FERRETERÍA METRÓPOLIS 84 LTDA.
CESAR AUGUSTO OROZCO MANOTAS
SANDRA MILENA PEÑARANDA SALAZAR
MAURICIO RODRIGUEZ REBOLLEDO
PROYECTO PARA OPTAR AL TITULO DE INGENIERO DE SISTEMAS
ASESOR TECNICO
ING. ALFONSO BORRÉ SARMIENTO
ASESOR METODOLOGICO
MsC. CLAUDIA ZAPATA
COORDINADOR DEL PROYECTO
ING. FABIAN RAMOS
UNIVERSIDAD AUTÓNOMA DEL CARIBE
FACULTAD DE INGENIERÍA
PROGRAMA DE INGENIERÍA DE SISTEMAS
BARRANQUILLA
2007
3
COMITÉ DE PROYECTO DE GRADO
ING. ENRIQUE SANTIAGO CHINCHILLA PRESIDENTE MsC. CLAUDIA ZAPATA FERREIRA ASESORA METODOLOGICA ING. ALFONSO BORRÉ SARMIENTO ASESOR TECNICO ING FREDDY BRICEÑO DIAZ MIEMBRO DEL COMITÉ ING. NELSON TARAZONA MENDEZ MIEMBRO DEL COMITÉ ING. FABIAN RAMOS MIEMBRO DEL COMITÉ
4
DEDICATORIA
A mis amados padres, las únicas personas que darían sus vidas por mí y quienes han sido mi apoyo incondicional,
motivo e inspiración.
Sandra
Dedicado a mi ausente padre, siempre presente en cada paso que doy en mi vida.
Mauricio
Al TodoPoderoso que me acompañó en los momentos difíciles y a mi familia por todo su apoyo incondicional
César
Dedicamos ésta meta alcanzada, a todas aquellas personas que creyeron y siguen creyendo aún en nosotros, pero sobre todo a quienes aún no lo hacen,
por darnos cada vez más energía para demostrar que estamos del lado de los campeones.
Sandra, Cesar y Mauricio.
5
AGRADECIMIENTOS
Jesús: ¿Qué haríamos los mortales sin tí? A ti Señor Jesús por tu fidelidad y amor, por ser la
fuente de gracia y vida que constantemente fluye sobre mi ser. Recibe de mí el honor, porque
todo lo que soy o pueda ser te lo debo a ti. Te amo Jesús! Sé que sin tí yo nada sería. Gracias,
porque puedo estar confiada sabiendo que tú cuidas de mí.
Sería imposible continuar, sin antes agradecer a los principales autores de éste logro:
mis padres. Expreso palabras de elogio a mi hermosa madre, a ella dedico el resultado de ésto
pues sólo su esfuerzo, dedicación y sacrificio han hecho de mí la persona que ahora soy. Éste
logro es más tuyo que mío, es el fruto de tu generosidad y amor. Te quiero mucho y agradezco
a Dios por tu vida. Te honro con todo mi amor! Y a mi papá, que aunque su ausencia hace
imposible celebrar juntos éste día, sé que estaría henchido de alegría. Para mí siempre estarás
presente, gracias por todo lo que dejaste sembrado en mí.
Agradezco igualmente, al joven más bello del mundo, mi mejor amigo y confidente, mi
motivo de inspiración, la alegría y romanticismo de mi vida: a mi negro precioso porque
siempre está ahí para animarme con su manera especial de decir las cosas. Gracias por tu ayuda
durante estos años, por tus teorías de importancia y prioridad, por sacrificar nuestro tiempo a
causa de mis horas de estudio y por entregar en mis manos la herramienta con la que se
terminó de perfilar el presente trabajo. Simplemente te amo más de lo que puedo expresar!
Quisiera expresar mi más sincero agradecimiento al Ing. Alfonso Borré Sarmiento, por
su paciencia, conocimientos transmitidos y orientaciones tutoriales, valiosas y útiles. Mil gracias
por toda su desinteresada ayuda, estoy segura que sin ella no hubiéramos culminado éste
proyecto.
6
Agradezco igualmente, al Ing. Ernesto Viloria su sincera amistad y guía, sus sabios
consejos, el tiempo que nos dedicó y sobre todo el habernos "aterrizado" en el momento justo.
Ing Ilma: lo prometido es deuda, muchas gracias por la amable sonrisa con la que
siempre nos atendió, por sus consejos y guía acertadas, por sus pacientes correcciones, por
cada hora que nos dedicó, por decirnos lo que nadie más nos dijo y por ayudarnos sin tener en
cuenta que nos éramos sus alumnos.
De igual modo, agradezco a la profesora Claudia Zapata, quien con sus observaciones
metodológicas contribuyó a la culminación del presente trabajo.
Manifiesto también, mi sincero agradecimiento a las familias de mis compañeros de
proyecto, por acogerme con tanta amabilidad. A la señora Juana Manotas y a la señora Elsa
Rebolledo, les expreso mi amplio agradecimiento por todas sus atenciones, por sus amigables
charlas y en fin haber abierto las puertas de sus respectivas casas para mí. Señora Juana, gracias
por haberme hecho sentir parte de su familia. Que Dios las prospere en todo cuanto
emprendan.
Bueno, finalmente expreso mis más sinceros respetos hacia mis compañeros de risas,
estudio y tesis: César y Mauro. Gracias por la amistad y confianza que me han brindado.
Mauro, no te dejes llevar por las circunstancias. César, ante ti me quedo sin palabras, tu entrega
me anima; síguele echando ganas a todo lo que emprendas. Los llevaré siempre en un lugar
especial de mi corazón. Nunca olviden que "Estamos Del Lado Del Que Es" !!
Por último, les doy las gracias a todas las personas que de alguna forma han intervenido en este
proceso.
Sandra Peñaranda Salazar
7
A todos los que aportaron su grano de arena para que todo fuese posible, a mis compañeros
Sandra y Cesar por apoyarme desde el principio con su disposición al proyecto, a mis amigos y
familiares por comprender mi sacrificio y a Dios por darme esta oportunidad tan linda de
crecer profesionalmente.
Mauricio Rodríguez
Le ofrezco mis agradecimientos a cada persona que de una u otra manera participaron en el
éxito de este proyecto.
Cesar Orozco
8
NOTA DE ACEPTACIÓN:
_______________________________
_______________________________
_______________________________
_______________________________
_______________________________
_______________________________
_______________________________
Firma del Presidente del Jurado
_______________________________
Firma del Jurado
_______________________________
Firma del Jurado
9
TABLA DE CONTENIDO
DEDICATORIA AGRADECIMIENTOS INTRODUCCION PLANTEAMIENTO DEL PROBLEMA ......................................................................23
1.1. Descripción Del Problema...............................................................................24 1.2. Formulación Del Problema..............................................................................25 1.3. OBJETIVOS ....................................................................................................25
1.3.1. Objetivo General Del Proyecto ................................................................25 1.3.2. Objetivos Específicos...............................................................................25
1.4. JUSTIFICACIÓN............................................................................................27 MARCOS DE REFERENCIA .......................................................................................28
2.1 Antecedentes Científicos Del Proyecto ...........................................................29 2.2 Marco Teórico.................................................................................................. 31
2.2.1 Historia De Los Sistemas Para Soporte A Las Decisiones.......................... 31 2.2.1.1 Reportes Ad Hoc................................................................................... 31 2.2.1.2 Programas Especiales De Extracción................................................... 31 2.2.1.3 Pequeñas Aplicaciones ......................................................................... 31 2.2.1.4 Centros De Información .......................................................................32 2.2.1.5 Sistemas Para El Soporte A La Toma De Decisiones ...........................32 2.2.1.6 Sistemas De Información Ejecutiva......................................................32
2.2.2 Conceptos De Data Warehouse ...................................................................33 2.2.2.1 Diferencia Entre Data Warehouse Y Bases De Datos Operacionales (OLTP) 34 2.2.2.2 Complejidad De Construir Y Usar Un Data Warehouse .....................35 2.2.2.3 El Administrador Del Data Warehouse Y La Crisis De La Planeación. 36 2.2.2.4 Elementos Que Componen Un Data Warehouse ................................37 2.2.2.5 El Concepto De Datamart (Mercado De Datos) .................................38 2.2.2.6 Proceso ETL ( Extracción, Transformación Y Carga) ........................39 2.2.2.7 Los Requerimientos De Un Data Warehouse......................................40 2.2.2.8 Arquitectura De Referencia Para El Data Warehouse .......................... 41 2.2.2.9 Concepto De Hechos...........................................................................44 2.2.2.10 Concepto De Dimensiones. .............................................................44 2.2.2.11 Jerarquías de una Dimensión................................................................45
10
2.2.2.12 Cambios En Una Tabla De Dimensión ............................................46 2.2.2.13 Concepto De Cubo............................................................................50 2.2.2.14 Operaciones Con OLAP................................................................... 51
2.2.3 Modelos De Construcción De Bases De Datos Multidimensionales...........52 2.2.4 El Ciclo De Vida Del Modelado Dimensional Del Negocio ........................53 2.2.5 Esquema De Modelado Starnet (Red De Estrella) .......................................54 2.2.6 Diagrama De Paquetes De Información ......................................................62 2.2.7 Metodología “Rapid Warehousing Methodology” De SAS Institute Para Un Proyecto De Data Warehouse............................................................................63
Definición De Los Objetivos ...............................................................................65 Definición De Los Requerimientos De Información..........................................66
2.2.8 Herramientas Para Data warehouse ............................................................69 2.3 Marco Conceptual............................................................................................77 2.4 Marco Legal .....................................................................................................80
DELIMITACIÓN...........................................................................................................85 3.1 Delimitación Temporal Y Espacial .................................................................86 3.2 Delimitación Técnica.......................................................................................86 3.3 Delimitación Financiera ..................................................................................87
3.3.1 Estructura De Descomposición Del Trabajo (EDT): .................................87 3.3.2 Diccionario De La EDT...............................................................................90 3.3.3 Información De Respaldo De La Estimación De Costos De Las Actividades...............................................................................................................95 3.3.4 Activos De Los Procesos De La Empresa ...................................................96 3.3.5 Depreciación De Los Equipos.....................................................................98 3.3.6 Cronograma Del Proyecto.......................................................................... 100 3.3.7 Gastos De Transporte, Papelería, Estadías Y Alimentación..................... 101 3.3.8 Contrato...................................................................................................... 102
DISEÑO METODOLÓGICO. .................................................................................... 104 4.1 Tipo De Investigación ................................................................................... 105 4.2 Tipo De Estudio ............................................................................................ 105 4.3 Método Utilizado ........................................................................................... 106 4.4 Técnicas De Recolección De La Información .............................................. 106 4.5 Población Objetivo......................................................................................... 107
4.5.1 Justificación Estadística De La Muestra....................................................... 107 4.5.2 Tamaño De La Muestra. ............................................................................... 108
ANÁLISIS E INTERPRETACIÓN DE RESULTADOS ........................................... 110 5.1 Análisis E Interpretación De Los Resultados ................................................111 5.2 Análisis E Interpretación De Los Resultados De Las Encuestas ................. 114
PROPUESTA................................................................................................................ 121 6.1 Solución.......................................................................................................... 122
6.1.1 Alternativas De Solución............................................................................ 122 6.1.2 Descripción De La Solución ...................................................................... 126
6.2 Requerimientos Del Sistema ......................................................................... 127
11
6.2.1 Definición De Requerimientos .................................................................. 128 6.2.2 Requerimientos No Funcionales ............................................................... 129 6.2.3 Especificación De Requerimientos ........................................................... 129 6.2.4 Paquetes De Información .......................................................................... 133 6.2.5 Negociación De Requisitos ....................................................................... 134 6.2.6 Evolución del sistema ................................................................................ 134 6.3 Diseño y Modelización Del Sistema .......................................................... 134
6.3.1.1 Modelado dimensional ....................................................................... 134 6.3.1.2 Acerca Del Datamart .......................................................................... 137 6.3.1.3 Nivel De Detalle Del Modelo............................................................. 137 6.3.1.4 Dimensiones....................................................................................... 137 6.3.1.5 Tablas De Hechos.............................................................................. 141 6.3.1.6 Diseño Técnico De La Arquitectura .................................................. 143 6.3.1.7 Mapeo De Los Datos En El Modelo Dimensional............................ 144
6.4 Implementación............................................................................................. 151 6.4.1 Back Room................................................................................................. 151 6.4.2 Extracción .................................................................................................. 151 6.4.3 Transformación.......................................................................................... 151 6.4.4 Carga .......................................................................................................... 152 6.4.5 Front Room ................................................................................................ 152 6.4.6 Infraestructura Del Data warehouse.......................................................... 153 6.4.7 Proceso de Extracción, Transformación y Carga...................................... 153 6.4.8 Herramienta Para El Proceso ETL ........................................................... 154 6.4.9 Proceso ETL Para La Dimensión Clientes................................................ 154 6.4.10 Proceso ETL Para La Dimensión Vendedores...................................... 162 6.4.11 Proceso ETL Para La Dimensión Producto .......................................... 164 6.4.12 Proceso ETL Para La Dimensión Tiempo ............................................ 165 6.4.13 Proceso ETL para las tablas de hechos ................................................. 167 6.4.14 Construcción De Los Cubos .................................................................. 170 6.4.15 Visualización De La Información ......................................................... 174 6.5 Pruebas....................................................................................................... 181
CONCLUSIONES Y RECOMENDACIONES .......................................................... 182 APENDICES................................................................................................................. 185
Formatos Fuente-Destino ......................................................................................... 186 Puntos A Considerar En La Captura De Requerimientos........................................ 189 Evaluación De La Infraestructura Existente ............................................................ 193 Generalidades Del Sistema........................................................................................ 196 Descripción De La Plataforma De Hardware Y Software ........................................ 198 Estudio De Factibilidad ............................................................................................ 200 Conocimientos Fundamentales De Las Bases De Datos ......................................... 201 Conocimientos en Gerencia de Proyectos.................................................................203 Glosario General ........................................................................................................ 206
ANEXOS ....................................................................................................................... 211
12
CUESTIONARIO DISEÑADO PARA EL PERSONAL DE GERENCIA MEDIA Y OPERATIVA DEL DEPARTAMENTO DE VENTAS ...................................... 212 ENTREVISTA REALIZADA A LOS GERENTES GENERAL Y GERENTE ADMINISTRATIVO................................................................................................. 216 ENTREVISTA DIRIGIDA AL GERENTE COMERCIAL Y AL COORDINADOR DE VENTAS. ............................................................................................................ 219 ENTREVISTA EFECTUADA AL REVISOR FISCAL..........................................222 ENTREVISTA DIRIGIDA AL GERENTE FINANCIERO..................................224 ENTREVISTA FINAL DIRIGIDA AL GERENTE COMERCIAL ......................226
BIBLIOGRAFIA ........................................................................................................... 228
13
ÍNDICE DE FIGURAS
Capítulo 2. MARCOS DE REFERENCIA
Figura 2.1 Elementos básicos de un data warehouse
Figura 2.2 Opción de implementación para los bloques de la arquitectura de referencia
Figura 2.3 Arquitectura de Referencia para el Data warehouse
Figura 2.4 Ejemplo de jerarquía de una dimensión
Figura 2.5 Ejemplo de un Cubo
Figura 2.6. Modelo en red de estrella para el análisis avanzado de las ventas en una empresa
comercializadora tradicional.
Figura 2.7 Descripción de hecho y de dimensiones en el modelado Starnet.
Figura 2.8 La adición de dimensiones surge por la combinación de las exigencias de
información en las consultas empresariales.
Figura 2.9 La línea recta que une las dimensiones expresa su adición en el modelo en estrella,
de esta forma se expresa la mezcla de criterios de análisis en la información deseada.
14
Figura 2.10 Las seis adiciones de dimensiones representan consultas empresariales con
diferentes criterios de análisis, cuya complejidad puede aumentas al exigirse más detalle en la
información.
Figura 2.11 La figura muestra nuestra estrella, cuyas dimensiones fueron rediseñadas según el
modelado en copo de nieve.
Figura 2.12 El modelo Snow Flake establece una jerarquía dimensional que permite un análisis
más detallado de los datos.
Figura 2.13 Metodología “Rapid Warehousing Methodology” por SAS Institute.
Figura 2.14 Arquitectura de Integration Services y la relación entre cada uno de los
elementos.
Figura 2.15 Arquitectura de Analysis Services.
Figura 2.16 Arquitectura de Reporting Services y la relación entre cada uno de los elementos.
Capítulo 3. DELIMITACIÓN
Figura 3.1 Principales actividades del proyecto en cronología de semanas anuales.
Capítulo 5. ANÁLISIS E INTERPRETACIÓN DE RESULTADOS
Figura 5.1 Representación de la segmentación de clientes.
15
Capítulo 6. PROPUESTA
Figura 6.1 Inteligencia de negocios en el Data Warehouse.
Figura 6.2 Diseño de la base de datos multidimensional de ventas.
Figura 6.3 Pasos generales de los procesos de extracción, transformación y carga de los datos.
Figura 6.3 Porcentajes de distribución de registros de clientes.
Figura 6.4 Porcentajes de distribución de registros de clientes del 2004 al 2007.
Figura 6.5 Distribución de registros de clientes.
Figura 6.6 Flujo de control que representa la extracción, transformación y población de la
dimensión cliente.
Figura 6.6.a Flujo de control “Poblar la dimensión clientes” en detalle.
Figura 6.7 Flujo de control que representan la extracción, transformación y población de la
dimensión vendedor.
Figura 6.7.a Flujo de control “Poblar la dimensión vendedores” en detalle.
Figura 6.8 Flujo de control “Poblar la dimensión producto”.
Figura 6.8.a Flujo de control “Poblar la dimensión producto” en detalle.
Figura 6.9 Flujo de control “Poblar la dimensión tiempo”.
16
Figura 6.9.a Flujo de control “Poblar la dimensión tiempo” en detalle.
Figura 6.9.b Mapeo fuente-destino para la dimensión tiempo.
Figura 6.10 Flujo de control “Poblar las tablas de hechos”.
Figura 6.10.a Flujo de control “Poblar las tablas de hechos venta” en detalle.
Figura 6.10.b Flujo de control “Poblar las tablas de hechos venta detalle” en detalle.
Figura 6.11 Estructura del cubo Ventas.
Figura 6.12 Estructura general implementada del cubo Ventas.
Figura 6.13 Estructura del cubo Detalle Ventas.
Figura 6.14 Estructura general implementada del cubo Detalle Ventas.
Figura 6.15 Diálogo para el inicio de sesión al administrador de reportes
Figura 6.16 Interfaz de inicio del administrador de reportes
Figura 6.17 Navegación establecida para el reporte linea_ventas
Figura 6.18 Camino de navegación para el reporte Clientes por vendedores.
Figura 6.19 Camino de navegación para el tipo de tipo_de_ventas_ventas.
Figura 6.20 Camino de navegación para el tipo de segmento_clientes_venta.
17
Figura 6.21 Camino de navegación para el tipo de vendedor_renta.
Figura 6.22 Camino de navegación para el tipo de tipoV_porcentaje
Figura 6.23 Camino de navegación para el tipo de vendedor_volumen.
Figura 6.24 Camino de navegación para el tipo de vendedor_rentabilidad.
Figura 6.25 Camino de navegación para el tipo de segmento_volumen.
18
ÍNDICE DE TABLAS
Capítulo 2. MARCOS DE REFERENCIA
Tabla 2.1 OLTP versus OLAP.
Tabla 2.2 Paquete de información correspondiente al análisis de las ventas.
Capítulo 4. DISEÑO METODOLÓGICO
Tabla 4.1 Número de empleados por cargo en el departamento de ventas de la Ferretería
Metropolis 84 Ltda.
Capítulo 6. PROPUESTA
Tabla 6.1 Ejemplo ilustrativo del formato deseado para monitorear los indicadores.
Tabla 6.2 Paquete de información, área tema: VENTAS.
Tabla 6.3 Paquete de Información, área tema: VENTAS_DETALLE.
Tabla 6.4 Estructura de la dimensión de tiempo dim_tiempo.
Tabla 6.5 Estructura de la dimensión de clientes dim_clientes.
19
Tabla 6.6 Estructura de la dimensión de productos dim_producto.
Tabla 6.7 Estructura de la dimensión para la línea de productos.
Tabla 6.8 Estructura de la dimensión para la línea de productos dim_segmento_cliente.
Tabla 6.9 Estructura de la dimensión para la línea de productos dim_vendedor.
Tabla 6.10 Estructura de la tabla de hechos fact_venta.
Tabla 6.11 Estructura de la tabla de hechos fact_ventas_detalle.
Tabla 6.12 Formato de mapeo fuente-destino para la dimensión de clientes.
Tabla 6.13 Formato fuente-destino para la dimensión de productos.
Tabla 6.14 Formato fuente-destino para la dimensión vendedor.
Tabla 6.15 Formato fuente-destino para la dimensión tipo de ventas.
Tabla 6.16 Formato fuente-destino para la Fact_venta.
Tabla 6.17 Formato fuente-destino para la Fact_venta_detalle.
20
INTRODUCCION
Toda empresa, independientemente del sector económico al que pertenezca, trabaja día a día en
pro de un incremento sustancial de su productividad y ventaja competitiva, lo cual
indiscutiblemente se consigue cuando la alta gerencia logra a través de una información que
facilite la gestión estratégica, la determinación del curso a seguir para su negocio al aprovechar la
información que a diario es almacenada en sus bases de datos transaccionales.
Sin embrago, la utilización de la información de las bases de datos operativas para tomar
decisiones, presenta varios problemas, dentro de los cuales cabe destacar la existencia de excesiva
información no compacta y poco ajustada para las diferentes áreas interesadas en tomar
decisiones, de la cual difícilmente se podría sacar conclusiones.
Dada la importancia de la toma de decisiones en la gerencia general de cualquier empresa,
el Data warehouse surge como una necesidad para el manejo simplificado de grandes volúmenes
de información. Luego, conforme la empresa comienza a usar diariamente la información
contenida en el Data warehouse a través del Sistema de Soporte de Decisiones (SSD), su
disponibilidad comienza a ser cada vez más importante; por lo que llega a considerarse como un
Sistema de Misión Crítica..
La solución propuesta en el presente proyecto consiste en diseñar e implementar un Data
warehouse en el departamento de ventas de la Ferretería Metrópolis 84 Ltda. que apoye al
conjunto de soluciones para soporte a la toma de decisiones administrativas en dicho
departamento, lo cual representa un incremento en la ventaja tecnológica competitiva de la
empresa.
21
La motivación más importante, para realizar este proyecto, es proporcionar un servicio
de tecnología de información costosa y estratégicamente significativa, a la altura de grandes
organizaciones como la corte de estado de Tennessee (Estados Unidos) e IBM quienes han
utilizado este tipo de sistemas para sus propósitos y necesidades estratégicas particulares.
Es por esto, que el proyecto plantea el desarrollo de una solución de Data warehouse
para una PYME (Pequeña Y Mediana Empresa), poniendo a su disposición la información
estratégica requerida en busca de incrementar su competitividad en el sector de la construcción
y de la ferretería en general, facilitándoles la capacidad de inteligencia y análisis que disponen
sus grandes competidoras.
Por otra parte, el proyecto servirá como referencia a futuros diseñadores en el área de
las bases de datos en la Ingeniería de Sistemas, sus diferentes carreras afines, las empresas
interesadas, en la comunidad científica y académica en general; sin mencionar la inspiración a
nuevos investigadores que podrán aportar sus ideas y teorías para un enriquecimiento del
conocimiento universal.
Además, se destaca el crecimiento del perfil profesional de todas las personas que
hemos estado involucradas en el desarrollo del proyecto; junto con la oportunidad de mejorar
las relaciones interpersonales para desempeñar mejores labores en equipo, un mayor
rendimiento laboral y una formación de valores y deberes humanos.
El texto se redactó por capítulos, existe un total de seis capítulos. En el capitulo 1 se
plantea el problema a resolver, se plantean los objetivos del proyecto y se realiza una
justificación de la aplicación. Toda la ambientación teórica y conceptual del proyecto, además
de información sobre trabajos de la misma natulareza realizados son cubiertos en el capítulo 2.
Las delimitaciones concernientes al proyecto se encuentran planteadas en el capítulo 3. Todo el
diseño metodológico relevante y básico para el proyecto se encuentra en el capítulo 4. El análisis
22
de los métodos de recolección de información especificados en el capítulo anterior se trata en
detalle en el capítulo 5. Una descripción completa de la solución se encuentra en el capítulo 6.
El texto contiene nueve apéndices: Una breve descripción del formato de mapeo Fuente-
destino, puntos a considerar en la captura de requerimientos, evaluación de la infraestructura
existente, generalidades del sistema, descripción de la plataforma de hardware y software,
estudio de factibilidad, conocimientos fundamentales de las bases de datos, conocimientos en
gerencia de proyectos y un glosario de términos clave y seis anexos complementarios.
23
C a p ì t u l o 1
PLANTEAMIENTO DEL PROBLEMA
24
1.1. Descripción Del Problema
El proyecto consiste en implementar un Data warehouse en el departamento de ventas de la
Ferretería Metrópolis 84 Ltda. debido a que en la actualidad la empresa cuenta con un módulo
estadístico que no se ajusta a las necesidades de la alta gerencia; con relación al establecimiento
de planes estratégicos para el beneficio de la compañía. Se ha identificado que el área
administrativa-comercial se encuentra limitada por los resultados imprecisos obtenidos en este
módulo, el cual requiere realizar cálculos complejos para analizar la información y resumirla, de
tal manera que le resulta muy difícil tomar decisiones. Además el departamento de sistemas debe
modificar el módulo permanentemente para materializar los nuevos requisitos del área
administrativa-comercial y simular una herramienta dinámica; ésta situación incide en el aumento
innecesario del esfuerzo por parte del gerente comercial al momento de obtener información
adecuada que le ayude a tomar decisiones acertadas y del departamento de sistemas en calidad de
proveedor de datos operacionales.
25
1.2. Formulación Del Problema
¿De qué manera se podría brindar información estratégica para soportar la toma de Decisiones
en la Ferretería Metrópolis 84 Ltda?
1.3. OBJETIVOS
1.3.1. Objetivo General Del Proyecto
Diseñar e implementar un sistema de soporte a la toma de decisiones administrativas en el
área de ventas de la Ferretería Metrópolis 84 Ltda. a través de la construcción de un
Datamart y de un sistema de despliegue que soporten el análisis multidimensional,
permitiendo la solución de las necesidades estratégicas de la empresa con relación a las
ventas.
1.3.2. Objetivos Específicos
• Explorar el ambiente operativo de la aplicación e identificar las fuentes técnicas útiles
para establecer las necesidades de información estratégica en el área de Ventas para
cada usuario del sistema con la finalidad de establecer requerimientos.
• Clasificar el área tema del Data Warehouse para identificar sus diversas funciones
empresariales y construir el diseño del Datamart, utilizando los requisitos capturados
en la etapa de requerimientos.
• Determinar el nivel de detalle del proceso de ventas para estipular la granularidad
asociada a la venta e identificar las medidas del negocio que serán incluidas con cada
registro dentro de la tabla de hechos para determinar los criterios de análisis.
26
• Documentar los criterios de análisis obtenidos en las entrevistas para la construcción
de las tablas de hechos y dimensiones del modelo lógico que aplicarán para el
Datamart.
• Realizar un análisis detallado sobre los datos candidatos del sistema transaccional
apoyado por un mapeo de datos destino y fuente para facilitar el proceso de extracción
de los elementos de datos.
• Organizar el espacio temporal para los datos (Data staging) para almacenar los datos
extraídos del sistema transaccional, de tal modo que sea optimizado el proceso de
población del esquema multidimensional.
• Elaborar y generar los reportes solicitados por el área de ventas de la empresa,
concretando así la funcionalidad de la herramienta.
• Garantizar la actualización automática dentro del lapso de tiempo establecido en los
requerimientos, de los datos del Data Warehouse con respecto a la Base de datos
transaccional para obtener información mas reciente.
27
1.4. JUSTIFICACIÓN
Gran parte del trabajo administrativo-comercial de la Ferretería Metrópolis 84 Ltda. tiene que
ver la toma de decisiones. El gerente comercial de la empresa con mucha frecuencia tiene que
manejar grandes cantidades de datos, sintetizarlos para obtener solo la información relevante y
tomar decisiones que beneficien a la organización respecto a las estrategias orientadas al
departamento de ventas.
Por anterior la solución propuesta se orienta en brindar a los ejecutivos de la empresa
información adecuada y en el momento oportuno, es decir, cuando ellos lo requieran. De igual
manera se permite a los ejecutivos acceder a la información relevante y actualizada sin
entrenamiento previo y sin intervención del personal de sistemas.
Por lo anterior, además de ser un proyecto académico, la presente propuesta busca:
• Mejorar la mayor cantidad de información relevante de la Ferretería Metrópolis 84
Ltda. respecto a las ventas en el menor tiempo posible con el objeto que se le facilite
decidir lo más adecuado.
• Apoyar el trabajo de los tomadores de decisiones a través del uso de este sistema,
mejorando el proceso de toma de decisiones y las decisiones resultantes.
• Convertir el conjunto de datos existentes en la empresa en información útil para la
toma de decisiones.
• Motivar a una mejora de la calidad y completitud de los datos capturados por los
sistemas transaccionales y concientizar en el efecto positivo que esto tiene en el sistema
estratégico.
• Facilitar la comunicación de información relevante hacia los niveles operativos y
viceversa a través de gráficas.
28
C a p ì t u l o 2
MARCOS DE REFERENCIA
29
2.1 Antecedentes Científicos Del Proyecto
Antes de abordar un proyecto, es de sabios indagar sobre trabajos, investigaciones o proyectos
realizados referentes al tema seleccionado para trabajar.
Conocer los antecedentes científicos guían el trabajo a realizar, los investigadores han
identificado el trabajo que lleva como título Modelamiento De Un Data Warehouse, Caso Práctico En
La Agroindustria1 realizado por Angélica Urrutia S., Hugo López G. Leoncio Jiménez C., Nenett Farías
M. quienes adelantaron el trabajo en la Escuela De Computación, Facultad De Ingeniería, Universidad
Católica Del Maule Casilla 617, Talca Chile en Noviembre 1999.
El proyecto plantea una metodología que permitió el modelamiento de un Data
Warehouse en una empresa frutícola de la VII región de Chile. La metodología se divide en
cuatro etapas: Planeación, Formulación y Análisis de Requerimientos, Diseño Conceptual, y
finalmente, Diseño Físico.
El tema reviste una gran importancia si se considera que no existe una metodología
aplicable de manera general y que garantice el éxito del proyecto. Lo que hay son experiencias
puntuales, como esta, que alertan de las dificultades, que tanto los desarrolladores como los
usuarios pueden encontrar en el terreno. Estas son discutidas en cada una de las etapas.
El trabajo Elicitación de requerimientos basados en la calidad de datos para sistemas para soporte a
decisiones2 realizado por Vaisman Alejandro el cual fue adelantado en la Universidad de Buenos Aires,
presenta una metodología para elicitación de requisitos con énfasis en la calidad de las
dimensiones y selección de fuentes de datos. Esta metodología apunta a la búsqueda de los datos
disponibles en las fuentes de datos operacionales que permite dar respuesta a un conjunto de
1 Modelamiento de un data warehouse, caso práctico en la agroindustria[11] 2 Data warehouses and OLAP : concepts, architectures, and solutions[4]
30
consultas (requerimientos funcionales) satisfaciendo ciertas condiciones de calidad de los datos
(requerimientos no funcionales). Con el propósito de cuantificar una respuesta dada una
pregunta, se ha adaptado la técnica de calidad despliegue de función (QFD). Finalmente, DSS-
METRIQ especifica un conjunto de formularios necesarios para el soporte del proceso de
elicitación de requerimientos.
El trabajo de grado que tiene como título Utilización De Información Histórica Para Decisiones
Empresariales3 el cuál fue realizado por Juan David Peña Rivera, Jesús Armando Suárez Daza el cual
fue adelantado en la Pontificia Universidad Javeriana, Facultad De Ingenieria.
El proyecto de grado contiene todos los componentes de una bodega de datos o
datamart. Como fuentes tienen una base de datos de contabilidad de la empresa Ubiquando,
hecha en Mysql de forma relacional y varios archivos de texto. El proceso de extracción,
transformación y carga, se desarrolló en el lenguaje java. La bodega de datos, o datamart fué
construida en una base de datos en PostgreSQL. y el análisis OLAP fué realizado utilizando el
servidor OLAP Mondrian. Todas estas herramientas son soportadas por varios sistemas
operativos, incluyendo Microsoft Windows y Linux.
El datamart proporciona información sobre las ventas de Ubiquando, al utilizar las
fuentes mencionadas para producir la información. Se desarrollan e implementan los
requerimientos de ventas determinados para la empresa. Dadas las características de los
proyectos anteriormente mencionados, podemos observar que el campo de los sistemas para
soporte a la toma de decisiones ha sido desarrollado bastante, sin embargo aún faltan demasiados
aspectos técnicos e implementación por desarrollar.
3 Utilización de información histórica para decisiones empresariales[10]
31
2.2 Marco Teórico
2.2.1 Historia De Los Sistemas Para Soporte A Las Decisiones
Dependiendo del tamaño y la naturaleza del negocio, muchas compañías han ido a través las
siguientes etapas en el intento de proveer información estratégica para la toma de decisiones. 4
2.2.1.1 Reportes Ad Hoc
Esta fue la etapa más temprana. Los usuarios, especialmente de Marketing y Finanzas, podrían
enviar solicitudes a IT para reportes especiales. IT podría escribir programas especiales,
típicamente uno para cada solicitud, y producir los reportes ad hoc..
2.2.1.2 Programas Especiales De Extracción
Esta etapa fue un intento de IT por anticipar cualquiera de los tipos de reportes que podrían ser
solicitados. IT podría escribir una suite (conjunto) de programas y ejecutarlos frecuentemente
para extraer datos desde otras aplicaciones, los cuales son utilizados para satisfacer solicitudes
para reportes especiales.
2.2.1.3 Pequeñas Aplicaciones
4 La sección 2.2.1 fue traducida del texto Data Warehousing Fundamentals A Comprehensive guide to IT Professionals pag 8 [5]
32
En esta etapa, IT ha formalizado el proceso de extracción. IT podría escribir aplicaciones
basadas en archivos de extracción. Los usuarios pueden estipular los parámetros para cada
reporte especial. Los programas de impresión podrían imprimir la información basados en
parámetros específicos. Algunas aplicaciones avanzadas podrían también permitir a los usuarios
ver información on-line.
2.2.1.4 Centros De Información
A principios de los 70’s, algunas compañías grandes crearon los que se denominó centros de
información. El centro de información fue un lugar donde los usuarios donde los usuarios
solicitaban reportes ad hoc o una vista especial de la información en pantalla El personal de IT
estaban presentes en los centros de información para ayudar a los usuarios obtener la
información en forma adecuada.
2.2.1.5 Sistemas Para El Soporte A La Toma De Decisiones
En esta etapa las compañías empezaron a construir sistemas más sofisticados para proveer
información estratégica. De nuevo, similar a los intentos anteriores, estos sistemas por
respaldados por los archivos de extracción. El sistema son dirigidos por el menú y proveen
información estratégica en línea y también la posibilidad de imprimir reportes especiales. Muchos
de los sistemas para el soporte a la toma de decisiones son dirigidos para marketing.
2.2.1.6 Sistemas De Información Ejecutiva
Fue el intento por brindar información estratégica al escritorio del ejecutivo. El criterio principal
es la simplicidad y la facilidad de uso. El sistema podría mostrar información importante todos
los días y proveer la capacidad de obtener reportes sencillos y de proyección. Sin embargo,
33
solamente pantallazas y reportes prefabricados están disponibles. Después de ver el total de
ventas por todo el país, si el ejecutivo desea hacer un análisis por región, por producto, o por
otra dimensión, no sería posible si dichos análisis no son tenidos en cuenta en el desarrollo de la
aplicación.
2.2.2 Conceptos De Data Warehouse
La siguiente sección fué adaptada del texto The Official Guide to Data WareHousing [1]
Es una técnica para consolidar y administrar datos de diversas fuentes con 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.
Las bases de datos operacionales se enfocan en almacenamiento de transacciones que
surgen como resultado de los eventos en flujo actividades en un sistema de información, por lo
que la carga de trabajo de las aplicaciones que administran esta funcionalidad es caracterizada
por un Proceso de Transacciones en línea (OLTP). Ver Sección 2.2.2.1 para mas detalles.
En contraste, un Data Warehouse permite un análisis de los datos procesados para
generar información valiosa dirigida al soporte a la toma de decisiones. La carga de trabajo que
soportan las aplicaciones que proporcionan su funcionalidad posee características
completamente diferentes y su procesamiento de información es ampliamente conocido como
Proceso Analítico en Línea (OLAP).
Las aplicaciones OLAP se basan en un modelado de bases de datos completamente
diferente al utilizado por las aplicaciones OLTP, el cual se llama Modelado Multidimensional que
34
intuitivamente representa datos bajo la metáfora de un cubo, en el cual cada dimensión física
representa un criterio para evaluar o analizar un evento o hecho.
2.2.2.1 Diferencia Entre Data Warehouse Y Bases De Datos
Operacionales (OLTP)
1. La información que se encuentra organizada para que una aplicación de negocios
recupere y actualice con facilidad no esta organizada de forma tal que un analista con
herramientas gráficas inteligentes de consulta pueda formular las preguntas empresariales
correctas.
2. La mayoría de los data warehouse contiene información histórica que se retira con
frecuencia de los sistemas operacionales, además debe ofrecer opciones para la adición,
condensación y granularidad que clasifican una gran cantidad de datos. Por lo anterior un
data warehouse es mucho mayor que las bases de datos operacionales.
3. Por lo volúmenes de información que deben gestionarse, el data warehouse
frecuentemente guarda información en diferentes medios de almacenamiento.
4. El data warehouse debe almacenar información histórica manejada en distintos
momentos por diferentes versiones de esquemas de datos y administrarla.
5. Se requiere al data warehouse para recopilar y organizar en un solo lugar información de
numerosas aplicaciones de software y múltiples bases de datos han acumulado en el
transcurso de los años.
35
A modo de complemento se mostrará a continuación y una tabla a modo de resumen:
OLTP OLAP
Usuario Típico empleado Profesional
Uso del Sistema operacional Análisis
Interacción con Usuarios predeterminada ad hoc
Unidad de Trabajo transacción Consulta
Características lectura/escritura Lectura
Registros accedidos decenas Millones
cantidad de Usuarios miles Cientos
Tabla 2.2 OLTP versus OLAP
2.2.2.2 Complejidad De Construir Y Usar Un Data Warehouse
Se hace alusión al rango de técnicas que se requieren para formular, desarrollar, implementar,
desplegar y exportar un data warehouse, entre las cuales tenemos:
1. Técnicas empresariales. Se relaciona con la compresión del significado de los datos
que contiene un data warehouse. También se refiere a determinar los requerimientos
corporativos y traducirlos a consultas que pueda satisfacer el data warehouse.
2. Técnicas de Análisis de datos. Necesarios para entender las evaluaciones de
información cuantitativa y derivar conclusiones basadas en hechos a partir de la
información histórica. Se incluye la habilidad para descubrir patrones y tendencias, para
deducir un valor futuro de las tendencias basadas en antecedentes, con el fin de
identificar anomalías y presentar recomendaciones coherentes de administración basados
en el análisis de la información del data warehouse. Estas técnicas se apoyan en las
matemáticas, estadística, experiencia, psicología y la intuición.
36
3. Técnicas de comunicación. Proporcionan una organización de GUIs (interfaces
gráficas de usuario) convenientes y fáciles de usar para apoyar las tareas de análisis. Es
necesario presentar los valores numéricos que conserva y organiza el data warehouse
utilizando despliegues intuitivos e informativos para que se perciban las tendencias y los
puntos de análisis. Estas técnicas se apoyan en la graficación, despliegue en forma de
árbol, despliegue en red, curvas de tendencias y análisis multidimensional.
2.2.2.3 El Administrador Del Data Warehouse Y La Crisis De La
Planeación.
La tarea de planear la construcción de un Data Warehouse o bodega de datos es intimidante para
cualquier diseñador, arquitecto o ingeniero de bases de datos y expertos en los sistemas de
información empresarial.
Para un administrador de un Data Warehouse existen dos aspectos claves que marcan
claramente la diferencia entre cualquier otro papel en la administración de los sistemas de
información:
1. Debe comprender el contenido y la ubicación del activo más complicado
perteneciente a la empresa: La información histórica.
Debe ser una autoridad en todo lo que está contenido en las tablas que administra sin importar
los motores de bases de datos que las contengan, incluyendo cada campo dentro de cada tabla.
Corregir errores y limpiar datos cuando sea necesario, generándose una gran responsabilidad.
2. Debe entender exactamente que es lo que mantiene la administración
despierta en las noches.
Se espera que el Data Warehouse contenga exactamente los datos requeridos para contestar las
preguntas sin respuesta.
37
Al cumplir con estas responsabilidades el administrador del Data Warehouse gana el
privilegio de poder entrar libremente en el círculo administrativo de la empresa en cualquier
momento para discutir las prioridades corporativas que se están atendiendo y tomar parte en las
decisiones administrativas.
Pero para llegar a esto debe cumplir su objetivo primordial y contestarse una pregunta:
• ¿Como puedo diseñar un Data Warehouse empresarial con tantos temas del negocio por
enfrentar, analizar y comprender?
Como siempre el nivel de complejidad en cualquier tipo de diseño puede ser manejado al
separar el todo en diferentes partes, ya que al ser un reto maestro en complejidad abarcar tantas
disciplinas empresariales en un solo intento es mejor optar por un equipo de trabajo, surgiendo
así el concepto de Data Mart o Mercado de Datos en el diseño y análisis del problema y los roles
de los diferentes participantes en el proyecto.
2.2.2.4 Elementos Que Componen Un Data Warehouse
La siguiente sección fué adaptada del texto Utilización de información histórica para decisiones
empresariales [10]
El Data Warehouse está conformado por:
1. El repositorio de datos o bodega de datos
2. Los procesos de:
2.1 Extracción.
2.2 Transformación.
2.3 Carga.
2.4 Herramienta para acceso a los datos.
38
2.2.2.5 El Concepto De Datamart (Mercado De Datos)
Un DataMart o Mercado de Datos es el conjunto de elementos de datos que tienen un tema de
negocios en común y que proporciona una capacidad de análisis especializado en diversos
criterios empresariales, descubrimiento de segmentos de datos con tendencias comunes,
detección de patrones repetitivos en períodos de tiempo paralelos, predicción de
comportamientos en datos futuros con base a los almacenados, auditoria del flujo de los
procesos operacionales junto con sus actores implicados, consolidación de los datos relacionados
con el tema de negocios para ser tratado de una forma mas específica y particular.
El término DataMart hace alusión a la imposibilidad de abordar todos los temas clave en
la toma de decisiones administrativas que son prioritarios en el análisis empresarial en el primer
intento de planeación en la construcción de un Data Warehouse.
Un DataMart es apenas una pequeña parte del todo del problema que será resuelto al
construir el Data Warehouse completo, ya que cada DataMart integra los eventos más
importantes de un tema de negocios según su relación en el flujo de procesos empresariales,
junto con los criterios de análisis ya sean estos comunes (Conformados) o específicos para un
evento dado.
Luego, la construcción de un Data Warehouse puede ser comparada con el proceso de
armar un rompecabezas, siendo cada una de sus piezas los DataMarts que encajan y se integran
de forma armoniosa solo al tener criterios comunes de análisis; entonces su complejidad se
incrementa debido a que los diseñadores deben construir las piezas del rompecabezas y
garantizar que compaginen entre cada una de ellas para formar el Data Warehouse.
Por esta razón los constructores del Data Warehouse no pueden diseñar DataMarts
aislados, ya que al no poder integrarse se convierten en el fracaso de los SSD y se manifiestan
como un “cuello de botella” al no proporcionar una vista integrada de la empresa, debido a que
39
ofrecen reportes que no pueden ser comparados y porque cada DataMart aislado es como una
pieza de rompecabezas que no encaja con ninguna otra, obstruyendo así el desarrollo de un Data
Warehouse empresarial integrado.
2.2.2.6 Proceso ETL ( Extracción, Transformación Y Carga)
La siguiente sección fué adaptada del texto Utilización de información histórica para decisiones
empresariales [10]
Para construir la bodega de datos se desarrollan en forma secuencial las tareas de extracción,
transformación y carga de los datos en el Datamart. El proceso de extracción consiste en la
obtención de la información desde las distintas fuentes (bases de datos, archivos operacionales,
documentos en Excel entre otras fuentes) tanto internas como externas mediante herramientas
de gestión de datos.
A continuación los datos son transformados para su almacenamiento en el depósito. La
tarea consiste en filtrado, limpieza, depuración, homogeneización e integración de la
información. Esto es requerido, ya que las bases de datos operacionales diseñadas para el soporte
de varios procesos del negocio tales como producción, cartera, entre otros frecuentemente
difieren en el formato.. Todas estas inconsistencias deben resolverse antes de realizar el último
paso de este proceso que corresponde a la carga de los datos en la bodega.
40
Figura 2.1 Elementos básicos de un data warehouse5
2.2.2.7 Los Requerimientos De Un Data Warehouse
La siguiente sección fué tomada del texto The Official Guide to Data WareHousing[1]
Para empezar a formular los requerimientos de una bodega de datos (data warehouse), hay que
tener en cuenta:
1. Un data warehouse es un sistema de aplicación empresarial con su propia base de datos.
Esta base de datos se genera a partir de otras bases de datos operacionales. El data
warehouse ofrece una serie de características y funciones para implementar procesos
empresariales y enlazarlos con otros procesos fuera del ámbito del data warehouse del
modo más eficiente posible.
2. El data warehouse posee una capacidad latente que se vuelve útil cuando las herramientas
de análisis y reporte se aplican con inteligencia a los datos que conserva el data
warehouse. Se necesita que el data warehouse soporte un gran número de herramientas 5 Traducido y adaptado del texto The Data Warehouse Toolkit : The Complete Guide To Dimensional Modelling pag 7[7]
41
de acceso operadas por una extensa gama de usuarios finales. También se requiere que el
data warehouse proporcione técnicas para resumir, a fin de que los usuarios finales
comprendan las lecciones de los antecedentes con mayor facilidad.
3. El data warehouse, en ocasiones es una tienda de datos operacionales, por lo tanto debe
distribuir información operacional de manera eficiente a un gran número de usuarios.
Además debe hacer los cambios tecnológicos necesarios para mover la información de su
base de datos operacional a la tecnología de almacenamiento que emplea.
2.2.2.8 Arquitectura De Referencia Para El Data Warehouse
El objetivo de la arquitectura de referencia es Integrar en una clasificación común los distintos tipos de
información necesarios para construir un data warehouse.
La palabra “referencia” significa que la arquitectura caracteriza la naturaleza “genérica” de
todos los Data warehouse. La arquitectura de referencia es una forma unificada y común de ver
los componentes de una solución de Data warehouse.
La arquitectura realiza los siguientes aportes6:
1. Ofrece un diagrama de un “anteproyecto” común que permite discutir costos,
estimados, riesgos y el alcance en el programa de implementación entre el inversionista y
el constructor.
2. El diagrama es un método de capturar en un punto de vista, la arquitectura permite
apreciar la visión global en fases, sin alterarlas.
6 The Official Guide to Data WareHousing[1]
42
3. Proporciona un modo de administrar el presupuesto de un proyecto de data warehouse
al manejar el ámbito de su implementación. Esto se maneja de muchas formas:
a. Selección de Metadatos.
b. Selección de fuentes de datos.
c. Implementación de un mercado de datos.
d. Selección de Técnicas que pueda manejar un Data warehouse.
4. La arquitectura separa la solución de un data warehouse en niveles cada vez más
detallados. En cualquier nivel es posible construir ó comprar cada componente. En
cualquier nivel es posible construir ó comprar cada componente. NOTA: Los bloques
“construcción del data warehouse”, “construcción del mercado de datos” y “Acceso y
uso” en conjunto con las capas “Administración de datos” y “Administración de
metadatos” son inversiones nuevas en el proyecto. El bloque “Fuentes de datos” en
conjunto con las capas “Transporte” e “Infraestructura” son inversiones existentes en la
empresa.
5. La arquitectura proporciona muchas opciones de implementación a saber:
a. Construir un data warehouse de amplitud empresarial.
b. Seleccionar pocas fuentes de información para construir el data warehouse,
mientras se reserva el derecho de admitir más en el futuro.
c. Definir una arquitectura múltiple, basada en diferentes tipos de plataforma para
los distintos componentes arquitectónicos para los diferentes componentes
arquitectónicos.
43
Figura 2.2 Opción de implementación para los bloques de la arquitectura de referencia7
d. Seleccionar componentes tecnológicos para el transporte (MiddleWare) y la
Infraestructura (RDBMS) que sean compatibles con la elección de la arquitectura.
Figura 2.3 Arquitectura de Referencia para el Data warehouse8
7 Creado por lo desarrolladores del proyecto 8 Adaptado del texto The Official Guide to Data WareHousing[1]
44
2.2.2.9 Concepto De Hechos
El modelo en red de estrella apunta a la búsqueda de un “evento” clave en el flujo de
información y movimiento de activos de cualquier compañía, que para ser exitosa necesita de
personas con el conocimiento del negocio, interacción con los procesos diarios transaccionales,
además de esto entrevistas con los tomadores de decisiones administrativas y una constante
confrontación de información.
Este evento denominado en la terminología del Modelado en red de estrella como
“Hecho”, es el que capta el interés de las personas responsables en la toma de decisiones y es el
centro de todos lo posibles análisis que pueda ofrecer el equipo de Arquitectos del Software en
su modelado de la solución. Está metodología se adapta perfectamente al concepto de Data
Warehouse ya que al centrarse en un tema (hecho) y definir sus criterios de análisis pone en
práctica todos los conceptos en la teoría de la construcción de los SSD.
Un hecho es una referencia a la medida o el valor que toma determinada variable que se
está analizando. Las medidas son resultados cuantificables, o indicadores clave de desempeño
usados para determinar el éxito de una operación de negocios. Dirigen hacia las respuestas a
preguntas relacionados a valores numéricos tales como la cantidad vendida, valor total de una
venta entre otras medidas.
2.2.2.10 Concepto De Dimensiones.
En una base de datos multidimensional, una dimensión es un “criterio o contexto” del análisis
que proporciona un punto de vista para los analistas de la información y que permite la
identificación de comportamientos comunes en los datos. Las dimensiones son las que limitan el
alcance de las consultas analíticas y miden el nivel de detalle del Datamart.
45
El nivel de detalle que proporcionan las dimensiones es denominado “Granularidad”
(Grain). Entonces, si el modelo permite llegar hasta un nivel de detalle mínimo en cada una de
sus dimensiones ofreciendo más niveles de análisis su nivel de granularidad es alto. Sin embargo
esta teoría implica problemas de diseño que deben ser considerados previamente a la
implementación del modelo, los cuales serán explicados y tratados a su debido momento.
2.2.2.11 Jerarquías de una Dimensión.
Las dimensiones están construidas por niveles o jerarquías. Estas jerarquías son representadas
por las estructuras organizacionales y modelos de datos que la empresa utiliza. 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 sigue un camino de navegación por su reporte. Un ejemplo claro de
jerarquía se ilustra en la Figura.2.4.
Figura 2.4 Ejemplo de jerarquía de una dimensión9
9 Tomado de la presentación La Investigación en OLAP y Data Warehousing: Pasado, Presente y Futuro – Vaisman Alejandro, slide 16
46
2.2.2.12 Cambios En Una Tabla De Dimensión
Cada tabla de dimensión tiene un ritmo de crecimiento que depende del flujo de información
del sistema transaccional de la empresa, y que puede cambiar dependiendo de las reglas del
negocio, de los movimientos del mercado, de los niveles de producción y de todos los factores
que afecten el movimiento.
Actualizaciones de las tablas de dimensiones:
Las tablas de dimensiones además de crecer por el almacenamiento habitual en las cargas de
datos, experimentan la actualización de los atributos de sus registros por causas los cambios en
el sistema transaccional, los cuales tienen una frecuencia determinada que dependen de los
factores que afectan el evento analizado. Es decir que al analizar las ventas
Dimensiones lentamente cambiantes (Slowly Changing Dimensions):
Las dimensiones lentamente cambiantes son aquellas que por movimientos o cambios de las
variables del negocio y sus reglas son regularmente actualizadas, donde solo los atributos de los
registros afectados serán el objeto de estudio de la modificación de la información.
Las formas en la que los cambios en los registros en una tabla de dimensión son
realizados dependen de la información que debe ser preservada en el Data Warehouse, siendo
la sobrescritura de sus atributos una opción no apropiada si se desea preservar un historial en
el Data Warehouse.
47
Primer (1) tipo de cambio: corrección de errores.
Estos cambios se dan debido a las correcciones de errores en el sistema fuente de los datos, los
cuales constantemente son errores de digitación de la información que traducen errores en la
gramática esperada de los datos en el sistema. Entre los más comunes se encuentran: digitación
de nombres, teléfonos, códigos y cualquier información que se encuentre atada al error
humano en su proceso de almacenamiento en la base de datos del sistema fuente.
En este tipo de cambio:
1. El atributo se sobrescribe con el nuevo valor directamente en el registro de la tabla de
dimensión.
2. El valor anterior no es preservado.
3. No se hace ningún otro cambio en el registro.
4. La llave de la dimensión o cualquier otro atributo no son afectados.
5. Es muy sencillo de implementar.
Segundo (2) tipo de cambio: preservación de la historia.
Estos cambios son los que permiten el control de los cambios del registro en la tabla de
dimensión y permiten un análisis más detallado de los cambios verídicos que no son originados
por errores de digitación sino que hacen parte de un acontecimiento que requiere la
preservación de un historial.
Podemos apreciarlo en el cambio del estado civil de un cliente:
48
Antes Después
Octubre 10/2007 Octubre 11/2007
El estado civil de Ana Pérez ha cambiado porque se casó el 10 de octubre del 2007, y
para mantener la historia de sus ventas en su estado marital anterior se ha creado un nuevo
registro a la fecha siguiente en el cual está la actualización de su información en el atributo
estado_civil.
Luego este tipo de cambio se caracteriza por:
1. Hacer referencia a cambios reales.
2. Tener la necesidad de preservar la historia del registro con una división antes-
después.
3. Todos los cambios a un mismo atributo deben ser preservados.
4. Agregar un nuevo registro en la tabla de dimensión con la actualización del registro
o los registros que han cambiado.
5. Garantiza que el registro original no es alterado ni en su llave ni sus atributos.
6. El nuevo registro es almacenado con una nueva llave subrogada.
Tercer (3) tipo de cambio: revisiones superficiales.
Una revisión superficial se manifiesta en una tabla de dimensiones como campos de control
que almacenan los cambios del atributo y su valor anterior para proporcionar mayor capacidad
de análisis.
cliente_k 12345
nombre Ana Pérez
cedula 95623144
estado_civil Soltera
12346
Ana Pérez
95623144
Casada
49
Si un cliente cambia de ciudad de residencia:
Antes Después
Octubre 10/2007 Octubre 11/2007
Se actualiza el campo anterior y el campo actual con los valores respectivos que marcan una
pauta de análisis temporal de la misma forma que el tipo de cambio 2.
Las principales características de este tipo de cambio son:
1. No se necesita la creación de un nuevo registro en la tabla de dimensión.
2. Las consultas existentes mostraran el valor actual sin tener que ser alteradas.
3. Cualquier consulta que necesite mostrar el valor anterior debe ser revisado.
4. Está técnica es aplicable solo para un cambio a la vez y en cambios sucesivos se
requiere del desarrollo de técnicas más sofisticadas.
Dimensiones grandes y muy cambiantes.
Una tabla de dimensión puede ser catalogada como grande por dos aspectos: si su número de
registros es grande o si la cantidad de atributos es grande. Puede ocurrir que ambos aspectos
estén contemplados en una sola tabla de dimensión, por lo que debe declararse como grande.
CLIENTES
cliente_k 12345
nombre Ana Pérez
cedula 95623144
ciudad_anterior Sin cambio
ciudad_actual Barranquilla
CLIENTES
12346
Ana Pérez
95623144
Barranquilla
Medellín
50
El manejo de los cambios en los registros en este tipo de tablas de dimensiones
depende de la frecuencia en la que se dan los mismos en el sistema transaccional, la cual
provocaría que los manejos de tipo 2 y 3 no generen los mejores resultados a largo plazo.
2.2.2.13 Concepto De Cubo
La siguiente sección fué adaptada del texto Utilización de información histórica para decisiones
empresariales [10]
El proceso analítico en línea OLAP efectúa el almacenamiento lógico de los datos en arreglos
ó matrices multidimensionales denominadas cubos. El cubo contiene los datos que son
requeridos por 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. El cubo se rige por una jerarquía que se establece según
los requerimientos de información. Véase la sección 2.2.2.11 jerarquías de una dimensión
51
Figura 2.5 Ejemplo de un Cubo10
2.2.2.14 Operaciones Con OLAP
Con la información que se analiza con OLAP se pueden realizar las siguientes
operaciones:
1. Drill Down y Roll Up: Estas dos operaciones permiten visualizar la información a un
nivel detalle distinto del actual.
2. Swap: Operación OLAP para intercambiar las filas por columnas de un reporte.
3. Slice and Dice: Estas dos operaciones permiten navegar a través de un cubo.
10 Adaptado de la presentación La Investigación en OLAP y Data Warehousing: Pasado, Presente y Futuro – Vaisman Alejandro, slide 17
52
2.2.3 Modelos De Construcción De Bases De Datos
Multidimensionales
Conociendo ya la diferencia entre un sistema de bases de datos OLTP y un sistema de bases de
datos OLAP, nos preguntamos entonces:
• ¿Cómo se modelan estas bases de datos y como se implementan?
Un modelo dimensional describe un proceso en términos de hechos y de dimensiones,
donde los hechos corresponden a la medida en la que es evaluado un proceso y las dimensiones
le dan un contexto a esta evaluación. Esta teoría es la base de los SSD que son los que auditan la
información, mientras que los sistemas transaccionales son los encargados de la ejecución de un
proceso en un negocio. Existen diversas metodologías de modelado de bases de datos
multidimensionales, de las cuales se destacan: el modelado en red de estrella y el modelado en
copo de nieve.
Estos dos modelos son la base del proceso analítico y son los que marcan la diferencia en
los alcances de una consulta empresarial que soporta una decisión Gerencial y una simple
consulta transaccional que no tiene valor agregado. Por ser entonces esta información tan
importante para la empresa, es de carácter obligatorio que al momento de ser proporcionada sea:
• Integrada: Debe tener una vista empresarial única y de criterios muy amplios.
• Consistente: Precisa y acorde con las reglas del negocio.
• Accesible: Fácil acceso para su análisis y estudio.
• Creíble: Solo debe existir un solo valor para cada uno de los hechos del negocio.
• Limitable en el tiempo: La información debe estar disponible en un marco de tiempo
de referencia estipulado.
53
Estas características son las bases de los SSD, y el diseñador dimensional debe garantizar
que su modelado cumpla con estas características. Incluso si los requerimientos de reportes
limitan el análisis a la información necesitada en ese momento por los usuarios, el debe diseñar
mirando en un futuro entregando un modelo flexible y adaptable a los cambios. Todo esto con el
fin de ofrecer evaluación de estrategias anteriores y permitir un OLAP con herramientas de
visualización de información ya sean estas construidas o adquiridas.
2.2.4 El Ciclo De Vida Del Modelado Dimensional Del Negocio
La siguiente sección fué adaptada del texto The Official Guide to Data WareHousing[1]
El ciclo de vida es un método iterativo basado en cuatro principios:
1. Orientado al negocio. Concentrarse en identificar los requerimientos del negocio y su
valor asociado. Utilizar esos esfuerzos para construir relaciones sólidas con el lado del
negocio que se ajusten a su sentido del negocio y a sus niveles de consultoría.
2. Construya una infraestructura de Información. Diseñe fundamentos de información
sencillos, integrados, fácil de usar, de alto rendimiento que le permitirán conocer un
amplio rango de requerimientos que haya identificado en toda la empresa.
3. Entregar incrementos significativos. Construir el data warehouse en incrementos que
puedan ser entregados en marcos de tiempo de 6 a 12 meses. Utilice claramente el valor
del negocio para determinar el orden de los incrementos.
4. Entregar la solución completa. Proveer todos los elementos necesarios para dar valor
a los usuarios del negocio. Esto significa que un Data warehouse sólido, bien diseñado,
de calidad, y accesible es sólo el comienzo. Se deben entregar herramientas de consultas
ad hoc, aplicaciones de reportes y análisis avanzado, entrenamiento, soporte, sitio web y
documentación.
54
2.2.5 Esquema De Modelado Starnet (Red De Estrella)
En nuestra investigación nos hemos encontrado con diversos conceptos para realizar un diseño
multidimensional de la base de datos para un sistema de soporte a la toma de decisiones (SSD)
basados en la arquitectura Data Warehouse, de los cuales siempre reluce el modelado en Red de
Estrella:
Figura 2.6 Modelo en red de
estrella para el análisis avanzado de
las ventas en una empresa
comercializadora tradicional.
En la figura 2.6 se aprecia que las ventas son el centro del modelo y que las puntas de la
estrella corresponden a sus criterios de estudio, los cuales proporcionan las perspectivas de
análisis que al ser combinadas según las demandas de información, ya sea en dos o incluso todas
en un solo cotejo empresarial; satisfacen los requerimientos de consulta que apoyan la toma de
decisiones gerenciales.
La elegancia del modelo dimensional reluce en el esquema en red de estrella al integrar de
forma equitativa los criterios del análisis empresarial, debido a que asume para cada uno de ellos
simetría en cuanto a los puntos de entrada de información para la evaluación de los eventos o
procesos.
55
Figura 2.7 Descripción de
hecho y de dimensiones en el
modelado Starnet.
La figura 2.7 identifica las partes principales del modelo Starnet, los hechos que son el
objeto de la exploración y las dimensiones que corresponden a los contextos en los que se
realizará el análisis.
Consultas Empresariales En El Contexto De Modelado STARNET.
En nuestra empresa es muy común que los gerentes estén interesados en realizar comparativos
de los diversos indicadores del estado de las ventas en general durante los diferentes periodos de
tiempo en un año específico con respecto a un criterio o la combinación de varios. Un ejemplo
de una consulta empresarial habitual sería:
• ¿Cuáles son los clientes hombres y mujeres que más compraron cemento gris en el
último trimestre del año 2007 pagando a contado, incluyendo cuál fue la cantidad en
unidades para cada uno y su vendedor asociado?
Este tipo de consulta requiere un arduo trabajo por parte del departamento de sistemas al
no tener implementada una solución para estos requerimientos y exige una gran precisión en sus
56
resultados ya que se tomará una decisión administrativa en Gerencia Comercial para diseñar una
campaña promocional dirigida al segmento del mercado obtenido.
Aplicada a nuestro modelo ejemplo sería la consulta más compleja que podría realizarse,
porque mezcla todos los criterios dimensionales para ver una venta y genera la adición de
dimensiones para consultas empresariales.
Adición De Dimensiones.
Cuando una consulta implica dos o más dimensiones se habla de “adición de dimensiones” en la
consulta:
Figura 2.8 La adición de
dimensiones surge por la
combinación de las exigencias
de información en las consultas
empresariales.
La adición de dimensiones indica cuando una consulta combina diferentes criterios de
análisis de los hechos para satisfacer las necesidades de información empresarial como la de
nuestro ejemplo. En este caso existe adición en todas nuestras dimensiones, ya que la consulta
ejemplo nos pide:
57
• Clientes hombres y mujeres que más compraron
• (Clientes por Género).
• Cemento gris (Producto).
• Último trimestre del año 2007 (Tiempo).
• Pagando a contado (Forma de pago).
• Cantidad en unidades para cada uno (Hecho de ventas).
• Vendedor asociado (Vendedor).
Para representarse la adición, se denota la relación trazando una línea recta entre las dos
dimensiones involucradas en la consulta:
Figura 2.9 La línea recta que une las dimensiones
expresa su adición en el modelo en estrella, de esta
forma se expresa la mezcla de criterios de análisis en la
información deseada.
La primera (1) adición de dimensiones indica una consulta que involucra tanto el tiempo
como una de las formas de pago. Esta consulta estaría originada de una pregunta:
• ¿Cuál fue el total en ventas (Sin importar la forma de pago) en el último trimestre del año
2007?
58
De esta forma cada adición agrega una dimensión como criterio en la consulta,
incrementando así su nivel de complejidad con cada dimensión adicionada hasta llegar al punto
en el que todas las dimensiones están incluidas, como en nuestra consulta ejemplo.
Figura 2.10 Las seis
adiciones de dimensiones
representan consultas
empresariales con diferentes
criterios de análisis, cuya
complejidad puede aumentas
al exigirse más detalle en la
información.
Cada línea de adición representa una consulta con más de un (1) criterio, la cual extrae
información que contiene distintos puntos de interés para los analistas tomadores de decisiones.
La adición de dimensiones puede darse entre cualquier dimensión sin importar su posición en la
estrella, debido a la flexibilidad del modelo.
Profundización
A mayor adición de dimensiones se forma un polígono cuyos lados se originan al conectarse las
líneas de cada adición. Este polígono nos indica que tan compleja es la consulta, cuanto mayor
sea el área, mayor será su nivel de complejidad. La “profundización” de una consulta se mide en
función del área del polígono resultante, y es directamente proporcional a la cantidad de
adiciones dimensionales.
59
Sin embargo para la satisfacción de la consulta ejemplo nuestro esquema de estrella se ve
limitado en cuanto a jerarquías de clasificaciones posibles para los criterios exigidos.
Extensión Del Modelado Starnet El Modelado Snowflake (Copo De Nieve)
El esquema de diseño en copo de nieve es un modelo en estrella que extiende en jerarquías cada
una de las dimensiones que forman parte de la estrella:
Figura 2.11 La figura muestra
nuestra estrella, cuyas dimensiones
fueron rediseñadas según el
modelado en copo de nieve.
Las dimensiones de Tiempo, forma de pago, vendedor, género y producto se han
estructurado nuevamente para tener un orden jerárquico que permite un análisis mas detallado de
la información. De este modo, aplicando todos los conceptos anteriores al nuevo modelo para
concretar la consulta empresarial obtenemos lo siguiente:
60
Figura 2.12 El modelo Snow Flake
establece una jerarquía dimensional que
permite un análisis más detallado de los
datos.
Igualmente la adición de dimensiones nos muestra la complejidad de la consulta
reflejándola en un polígono.
Implementación Del Modelado Multidimensional En Bases De Datos Analíticas
Teniendo entonces nuestro modelo de referencia para construir una base de datos dedicada
exclusivamente al análisis de la información y no al soporte operacional, surge un nuevo
interrogante para los arquitectos del Data Warehouse:
• ¿Cómo implementamos este diseño en un motor de base de datos?
Para cada modelo multidimensional de bases de datos analíticas tratado existe un
correspondiente diseño de tablas en un motor de base de datos, tanto para el modelado Starnet
61
(Red de estrella) como para el modelado SnowFlake (Copo de nieve), por medio del cual son
estructurados los cubos de datos que hacen posible el análisis avanzado de información, junto
con la minería de datos y todos beneficios que esta puede aportar para el crecimiento
empresarial.
Sin embargo, la escogencia del modelo base y su aplicación en la construcción de la
arquitectura del Data Warehouse depende de los requerimientos de detalle de la información.
Esto quiere decir que el alcance de los resultados a nivel de detalle de la información obtenida
esta atado al modelado dimensional de la base de datos que se ha implementado y a la calidad de
los datos que esta contiene almacenados.
Por esta razón se hace absolutamente necesaria una excelente identificación de los
eventos objeto del análisis empresarial y los criterios bajo los cuales se someterán para obtener la
información que apoyará la toma de decisiones administrativas.
Es importante destacar que el diseño dimensional no debe estar limitado a la
funcionalidad de un motor de bases de datos, por lo que la selección de la herramienta debe
basarse no solo en la compatibilidad con la plataforma del sistema de información existente y en
sus costos, sino también en la flexibilidad que demanda el modelo diseñado y de los
requerimientos de información, justificando la inversión en los beneficios obtenidos por las
herramientas de software, la ventaja competitiva y tecnológica, junto con la escalabilidad de un
producto actualizable y garantizado.
62
2.2.6 Diagrama De Paquetes De Información
La presencia de un diagrama de paquetes de información en la documentación de la etapa de
definición de requerimientos es la diferencia más significativa entre los sistemas operacionales y
los sistemas de bodega de almacenamiento de datos. Estos paquetes son los que contienen las
medidas críticas que evalúan el desempeño del negocio, los criterios de evaluación y sus métrica,
junto con el nivel de detalla de cada uno. 11
Tema de información: Análisis de Ventas
Periodos de
tiempo
Productos Formas de
pago
Año Grupo de
productos
Crédito
Semestre Productos Contado
Trimestre
Bimestre
Hechos o eventos medidos: Presupuesto de ventas, ventas anuales,
ventas mensuales, ventas trimestrales, ventas bimestrales, productos mas
vendidos…
Tabla 2.2. Paquete de información correspondiente al análisis de las Ventas.
Los paquetes de información permiten concretar los resultados de la etapa de captura de
requerimientos en un documento estándar donde son separados y agrupados los hechos y las 11 La sección 2.2.6 fué traducida del texto Data Warehousing Fundamentals A Comprehensive guide to IT Professionals[5]
63
dimensiones que tienen un tema del negocio en común que sería en nuestros caso el análisis de
las ventas.
Los principales beneficios de los paquetes de información son:
• Definen las áreas temáticas comunes del negocio.
• Diseñan las métricas clave para la evaluación del negocio.
• Deciden como deben ser presentados los datos.
• Determinan como los usuarios indagarán a través de los datos.
• Deciden la cantidad de datos que serán analizados o consultados por los usuarios.
• Deciden como será accedidos los datos.
• Establecen el nivel de Granularidad (Grain).
• Estiman el tamaño del Data Warehouse.
• Determinan la frecuencia de actualización de los datos.
• Concretan como debe ser empaquetada la información.
2.2.7 Metodología “Rapid Warehousing Methodology” De SAS
Institute Para Un Proyecto De Data Warehouse
La presente sección fue tomada de:
http://www2.sas.com/proceedings/sugi22/DATAWARE/PAPER132.PDF
La metodología para el desarrollo del proyecto será la establecida por el instituto SAS (statistical
analysis software)12. Dicha metodología es iterativa, y está basada en el desarrollo incremental
12 Para mas detalles sobre SAS, visite el sitio web http://www.sas.com/presscenter/bgndr_history.html
64
del proyecto de Data Warehouse dividido en cinco fases para que este concepto sea
correctamente aplicado en las organizaciones, y se asegure la calidad de este tipo de proyectos.
El correcto desarrollo de cada una de las fases planteadas en esta metodología garantiza
la calidad y el correcto proceso de desarrollo.
Figura 2.13 Metodología “Rapid Warehousing Methodology” por SAS Institute13.
Como punto de arranque de todo, es preciso "vender la idea" a los usuarios finales de
un Data Warehouse. Esto es así, por ser una idea bastante novedosa y sobre la que pueden
surgir recelos de su efectividad. Estos recelos se pueden eliminar comenzando por un pequeño
módulo, del cual se valoren los beneficios posteriores, para iniciar progresivamente el
desarrollo de nuevos módulos, cada uno con un coste unitario cada vez más reducido, pero sin
embargo con unos beneficios distribuidos cada vez mayores por poder cada vez incluir más 13 Tomado de http://dataprix.com/manual-adquisicion-datawarehouse
65
información. El simple hecho de realizar un informe de necesidades previas en el que se
enumeren la situación de los datos entre los diversos sistemas operacionales, puede ser un
hecho decisivo para emprender un proyecto de este tipo. Muchas veces la información
existente se encuentra tan poco normalizada, existen tantas discrepancias entre estos sistemas,
que el abordar un Data Warehouse en el que se limpien estos datos y se normalicen pueden
aportar un valor intangible: "la calidad y fiabilidad de la información".
La venta de esta idea no sólo se ha de realizar frente a la Dirección sino que es preciso
realizarla a todos los niveles: a la Dirección, Gerencia e incluso al área de Desarrollo.
Tras esta venta de la idea, comienzan dos fases similares al análisis de requisitos del
sistema: la definición de objetivos y requerimientos de información, en el que se analicen las
necesidades del comprador.
Definición De Los Objetivos
En esta fase se definirá el equipo de proyecto que debe estar compuesto por representantes del
departamento informático y de los departamentos usuarios del Data Warehouse además de la
figura de jefe de proyecto.
Los siguientes roles se identifican para el proyecto:
• Patrocinadores de negocio.
• Gerente del proyecto: Responsable de la gerencia de tareas y actividades cotidianas.
• Líder de negocios del proyecto: Con el gerente del proyecto monitorea el proyecto y lo
comunica a la organización. Tiene un alto entendimiento de los requerimientos del
negocio.
• Analista del sistema de negocios: Lidera las actividades de definición de requerimientos.
• Modelador de datos: responsable del análisis de datos y el modelo dimensional.
• Administrador de bases de datos de la bodega (DBA): Responsable de determinar
agregaciones, particiones y soporte a la base de datos.
66
• Diseñador de proceso ETL: Responsable del diseño de la extracción, transformación y
carga de la bodega.
• Desarrolladores de aplicación al usuario.
Se definirá el alcance del sistema y cuales son las funciones que el Data Warehouse
realizará como suministrador de información de negocio estratégica para la empresa. Se
definirán así mismo, los parámetros que permitan evaluar el éxito del proyecto.
Definición De Los Requerimientos De Información
Durante esta fase se mantendrán sucesivas entrevistas con los representantes del departamento
usuario final y los representantes del departamento de informática. Se realizará el estudio de los
sistemas de información existentes, que ayudaran a comprender las carencias actuales y futuras
que deben ser resueltas en el diseño del Data Warehouse
Asimismo, en esta fase el equipo de proyecto debe ser capaz de validar el proceso de
entrevistas y reforzar la orientación de negocio del proyecto. Al finalizar esta fase se obtendrá
el documento de definición de requerimientos en el que se reflejarán no solo las necesidades de
información de los usuarios, sino cual será la estrategia y arquitectura de implantación del Data
Warehouse.
Diseño Y Modelización
Los requerimientos de información identificados durante la anterior fase proporcionarán las
bases para realizar el diseño y la modelización del Data Warehouse.
En esta fase se identificarán las fuentes de los datos (sistema operacional, fuentes
externas, entre otras) y las transformaciones necesarias para, a partir de dichas fuentes, obtener
el modelo lógico de datos del Data Warehouse. Este modelo estará formado por entidades y
relaciones que permitirán resolver las necesidades de negocio de la organización.
67
El modelo lógico se traducirá posteriormente en el modelo físico de datos que se
almacenará en el Data Warehouse y que definirá la arquitectura de almacenamiento del Data
Warehouse adaptándose al tipo de explotación que se realice del mismo.
La mayor parte estas definiciones de los datos del Data Warehouse estarán
almacenadas en los metadatos y formarán parte del mismo.
Implementación
La implantación de un Data Warehouse lleva implícitos los siguientes pasos:
• Extracción de los datos del sistema operacional y transformación de los mismos.
• Carga de los datos validados en el Data Warehouse. Esta carga deberá ser planificada con
una periodicidad que se adaptará a las necesidades de refresco detectadas durante las
fases de diseño del nuevo sistema.
• Explotación del Data Warehouse mediante diversas técnicas dependiendo del tipo de
aplicación que se de a los datos:
• Query & Reporting.
• On-line analytical processing (OLAP).
• Executive Information System (EIS) ó Información de gestión.
• Decision Support Systems (DSS).
• Visualización de la información.
• Data Mining ó Minería de Datos.
La información necesaria para mantener el control sobre los datos se almacena en los
metadatos técnicos (cuando describen las características físicas de los datos) y de negocio
(cuando describen cómo se usan esos datos). Dichos metadatos deberán ser accesibles por los
usuarios finales que permitirán en todo momento tanto al usuario, como al administrador que
deberá además tener la facultad de modificarlos según varíen las necesidades de información.
68
Con la finalización de esta fase se obtendrá un Data Warehouse disponible para su uso
por parte de los usuarios finales y el departamento de informática. A continuación se explica la
forma de presentar la información a los diferentes niveles organizacionales.
NIVEL ESTRATEGICO (Alta Gerencia)
Balance ScoreCard Información
Consolidada
Generación de
alertas
DashBoard
Se dibuja la estratégia de la empresa
se divide en objetivos específicos y se
construyen los KPI’s
Conjunto de
reportes que dan
validez al
proyecto ante los
usuarios.
Respuesta
informativa a un
evento. Las alertas
están sujetas a: La
forma en que se
presenta al usuario;
La frecuencia que
se muestra al
usuario.
Consolida todos
los indicadores
operativos de la
empresa y el
detalle de cómo
se generó el
indicador.
NIVEL TÁCTICO(Personal Supervisor)
Reportes Drill-down/Drill-up Reportes Ad
Hoc
Acceso directo al Cubo
Capacidad para generar reportes
General-específico/Específico-
General.
Son reportes a la
medida, significa
elaborar reportes
al vuelo
totalmente
personalizables
Conexión directa al cubo para ser
manejado según las necesidades.
NIVEL OPERATIVO (Personal operativo)
Cualquiera de las características del
nivel táctico
Acceso a los datos del modelo multidimensional, sin
embargo esto no es la mejor opción. Es suficiente con dar
acceso al sistema transaccional.
69
Revisión
La construcción del Data Warehouse no finaliza con la implantación del mismo, sino que es una
tarea iterativa en la que se trata de incrementar su alcance aprendiendo de las experiencias
anteriores.
Después de implantarse, debería realizarse una revisión del Data Warehouse planteando
preguntas que permitan, después de los seis o nueve meses posteriores a su puesta en marcha,
definir cuáles serían los aspectos a mejorar o potenciar en función de la utilización que se haga
del nuevo sistema.
2.2.8 Herramientas Para Data warehouse
La sección 2.2.7 fue tomada de Microsoft Corporation Libros en pantalla de SQL Server
2005[9]
Motor De Base De Datos SQL Server 2005
El SQL Server 2005 Database Engine (Motor de base de datos de SQL Server 2005) de
Microsoft es el servicio principal para almacenar, procesar y proteger datos. El Database Engine
(Motor de base de datos) proporciona acceso controlado y procesamiento de transacciones
rápido para cumplir con los requisitos de las aplicaciones consumidoras de datos más exigentes
de su empresa. El Database Engine (Motor de base de datos) también proporciona
compatibilidad completa para mantener una alta disponibilidad.
Tareas Del Motor De Base De Datos14
14 Microsoft Corporation, Libros en Pantalla de SQL Server- Conceptos sobre el motor de base de datos[9]
70
El orden de los temas de la documentación del Database Engine (Motor de base de datos) se
corresponde con la secuencia principal de las tareas utilizadas para implementar un sistema que
utiliza el Database Engine (Motor de base de datos) para el almacenamiento de datos:
• Diseñar y crear una base de datos que contenga las tablas relacionales o los documentos
XML que el sistema necesita.
• Implementar sistemas para obtener acceso y cambiar los datos almacenados en la base de
datos, lo que incluye implementar los sitios Web o las aplicaciones que funcionan con los
datos, así como crear procedimientos que utilicen las herramientas y utilidades de SQL Server
para trabajar con los datos.
• Aplicar los sistemas implementados en la organización o en los clientes.
• Proporcionar soporte técnico administrativo diario para optimizar el rendimiento de la
base de datos.
SQL Server Integration Services (SSIS)
Microsoft SQL Server 2005 Integration Services (SSIS) es una plataforma que permite generar
soluciones de integración de datos de alto rendimiento, entre las que se incluyen paquetes de
extracción, transformación y carga (ETL) para el almacenamiento de datos.
Integration Services incluye herramientas gráficas y asistentes para generar y depurar
paquetes, tareas para realizar funciones de flujo de trabajo, como las operaciones de FTP, tareas
para ejecutar instrucciones SQL o para enviar mensajes de correo electrónico, orígenes y destinos
de datos para extraer y cargar datos, transformaciones para limpiar, agregar, mezclar y copiar
datos, un servicio de administración, el servicio Integration Services para administrar Integration
71
Services e interfaces de programación de aplicaciones (API) para programar el modelo de objetos
de Integration Services.
Arquitectura De Integration Services
Microsoft SQL Server 2005 Integration Services (SSIS) se compone de cuatro partes clave: el
servicio Integration Services, el modelo de objetos de Integration Services, el tiempo de
ejecución, los ejecutables de tiempo de ejecución de Integration Services, y la tarea Flujo de
datos que encapsula el motor de flujo de datos y los componentes de flujo de datos.
Aunque proporcionamos una breve descripción sobre Integration Servicies, no pretende
ser completo ni detallado. Para una referencia completa sobre Integration Servicies remitimos al
Microsoft SQL Server 2005 Integration Services.
72
Figura 2.14 Arquitectura de Integration Services y la relación entre cada uno de los
elementos15
15 Microsoft Corporation, Libros en Pantalla de SQL Server-> Arquitectura de Integration Services[9]
73
SQL Server Analysis Services (SSAS)
Microsoft SQL Server 2005 Analysis Services (SSAS) ofrece funciones de procesamiento
analítico en línea (OLAP) y minería de datos para aplicaciones de Business Intelligence. Analysis
Services admite OLAP y permite diseñar, crear y administrar estructuras multidimensionales que
contienen datos agregados desde otros orígenes de datos, como bases de datos relacionales. En el
caso de las aplicaciones de minería de datos, Analysis Services permite diseñar, crear y visualizar
modelos de minería de datos que se construyen a partir de otros orígenes de datos mediante el
uso de una gran variedad de algoritmos de minería de datos estándar del sector.
Arquitectura De Analysis Services
Microsoft SQL Server 2005 Analysis Services (SSAS) admite una arquitectura de cliente ligero. El
motor de cálculo de Analysis Services depende totalmente del servidor, por lo que todas las
consultas se resolverán en él. En consecuencia, para cada consulta sólo se necesita realizar un
viaje de ida y vuelta entre el cliente y el servidor, lo que produce un rendimiento escalable a
medida que las consultas aumenten en complejidad.
El protocolo nativo para Analysis Services es XML for Analysis (XML/A). Analysis
Services proporciona varias interfaces de acceso a datos para aplicaciones cliente pero todos
estos componentes se comunican con una instancia de Analysis Services a través de XML for
Analysis.
Se proporcionan varios proveedores distintos en Analysis Services para admitir diferentes
lenguajes de programación. Un proveedor se comunica con un servidor de Analysis Services
enviando y recibiendo XML for Analysis en paquetes SOAP sobre TCP/IP o sobre HTTP a
través de Servicios de Internet Information Server (IIS). La conexión HTTP utiliza un objeto
COM, denominado bombeo de datos y cuya instancia ha sido creada por IIS, que actúa como
conducto para los datos de Analysis Services. El bombeo de datos no examina de ningún modo
74
los datos subyacentes contenidos en la secuencia HTTP, ni ninguna de las estructuras de datos
subyacentes está disponible para el código en la propia biblioteca de datos.
Figura 2.15 Arquitectura de Analysis Services 16
16Microsoft Corporation, Libros en Pantalla SQL Server Conceptos y objetos de Analysis Services > Arquitectura de Analysis Services >[9]
75
SQL Server Reporting Services (SSRS)
Es una plataforma creada por Microsoft Corporation, está compuesta por: Reporting Services
XML Web Service, Servidor de reportes y el catálogo del servicio de reportes.
Figura 2.16 Arquitectura de Reporting Services y la relación entre cada uno de los elementos17
Reporting Services XML Web Service Este componente es importante por un par de razones. Primero, hace compatible a la
plataforma a otros lenguajes de programación. Porque Web services es construida bajo
estándares abiertos y utiliza XML para transferir información, reporting services puede ser
implementado en cualquier plataforma que soporte http y XML. Segundo Web Services
permite la comunicación a través de las redes. Utilizando HTTP, los mensajes pueden ser
17 Tomado del texto Professional SQL Server™ 2005 Reporting Services pag 83 [18]
76
enviados a través de firewalls y ayuda a los programadores implementar sistemas distribuidos
con facilidad.
Servidor De Reportes
Es el motor principal detrás de Reporting Services. Su Función principal es procesar y
presentar la información de los reportes.
Catálogo de Reporting Services
Reporting services almacena sus metadatos en SQL Server. Utiliza las bases de datos
ReportServer y ReportServerTempDB como medio de almacenamiento.
La base de datos ReportServer es el almacenamiento principal en Reporting Services. Contiene
todas las definiciones de reportes, modelos de reportes, fuentes de datos, planificación,
información de seguridad y snapshots.
Cuando se trabaja con reporting services, es importante prestar atención a la base de
datos ReportServer. Esta contiene información crítica relacionada a reporting services por lo
tanto debe realizarse una copia de seguiridad periódicamente.
La base de datos ReportServerTempDB es un almacenamiento temporal de la información de
Reporting Services. Porque Reporting Services se comunica utilizando el protocolo HTTP,
ningun estado se mantiene entre la aplicación cliente y el servidor. Por tanto se almacenan los
reportes que el usuario esta utilizando en una sesión.
77
2.3 Marco Conceptual
Área de presentación de datos: Lugar donde la bodega es organizada, almacenada y
disponible para consultas directas por los usuarios, herramientas de acceso a datos y otras
aplicaciones analíticas. El proceso de consulta tiene lugar en el área de presentación de los
datos.
Base de datos Multidimensional: Base de datos en la cual los datos son presentados en
cubos de datos, lo opuesto a las tablas en una plataforma de base de datos relacional.
Datamart: subconjunto especializado de una bodega de datos. Los diferentes datamarts
contienen diferentes combinaciones y selección de los mismos datos detallados identificados
en la bodega de datos, por esto puede decirse que los datamarts vienen a ser como una
extensión natural de la bodega de datos.
Data WareHouse: Por el inglés Data warehouse. Es una bodega de datos.
Dimensión lentamente cambiante (SCD): Es la tendencia de los registros de una dimensión
a cambiar gradualmente u ocasionalmente en el tiempo.
Fact Table (tabla de hechos): En un esquema en estrella (modelo dimensional), es la tabla
central con valores numéricos ó medidas.
Herramienta de acceso a datos: Herramienta cliente que consulta, obtiene o manipula datos
almacenados en una base de datos relacional, preferiblemente en un modelo dimensional
ubicado en área de presentación de datos.
Internet Information Services (IIS): Servidor Web propietario de Microsoft Corporation.
78
KPI (Key Performance Indicator): Indicadores claves de desempeño que enfocan a la
organización a una cultura de medición de los procesos del negocio.
Llave artificial (Surrogate key): Llaves enteras (integer) asignadas secuencialmente como
sean requeridas en el área de Stage para poblar una tabla de dimensión y unir esta con la tabla
de hechos. En la tabla de dimensión, la llave artificial es la primary key (llave primaria). En la
tabla de hechos, la llave artificial es una llave foránea a una dimensión específica. La llave
artificial no puede ser interpretada por sí misma. Las llaves artificiales son utilizadas en muchas
situaciones para manejar dimensiones lentamente cambiantes.
Medida del negocio: Métrica de desempeño capturada por un sistema transaccional y
presentado como un hecho en el modelo dimensional.
Metadata: Información sobre los datos almacenados en la bodega de datos, permite conocer
las fuentes de donde es extraído y reglas de negocio.
OLAP: ON LINE ANALYTICAL PROCESSING, tecnología que permite a los usuarios
tener una visión de los datos de una forma rápida, interactiva y fácil de usar.
OLTP: ON LINE TRANSACTIONAL PROCESSING, las aplicaciones de OLTP están
organizadas para ejecutar las transacciones para los cuales fueron hechos, como por ejemplo:
mover dinero entre cuentas, un cargo o abono, una devolución de inventario, etc. Por otro
lado, una bodega de datos está organizada en base a conceptos, como por ejemplo: clientes,
facturas, productos, etc.
Star Join Schema (Esquema en estrella) Representación genérica de un modelo
dimensional en una base de datos relacional en la cual una tabla de hechos compuestas por
llaves es unida a un número de tablas de dimensión, cada una con una llave primaria.
79
SQL Server Integration Services (SSIS) Es una plataforma para generar soluciones de
integración de datos de alto rendimiento, lo que incluye paquetes que proporcionan
procesamiento de extracción, transformación y carga (ETL) para almacenamiento de datos.
Server Analysis Services (SSAS) Ofrece funciones de procesamiento analítico en línea
(OLAP) y minería de datos para aplicaciones de Business Intelligence. Analysis Services admite
OLAP al permitir al usuario diseñar, crear y administrar estructuras multidimensionales que
contienen datos agregados de otros orígenes de datos, como las bases de datos relacionales.
Para aplicaciones de minería de datos, Analysis Services le permite diseñar, crear y visualizar
modelos de minería de datos. Estos modelos de minería de datos se pueden construir a partir
de otros orígenes de datos empleando una amplia variedad de algoritmos de minería de datos
estándar.
Proceso del negocio: Actividades principales operacionales o procesos soportados por el
sistema transaccional fuente, tales como ventas en una organización comercial. Seleccionar el
proceso del negocio es el primer paso en el diseño de un modelo dimensional.
80
2.4 Marco Legal
Ley 842 De 2003
La sección 2.4 fue tomada de DIARIO OFICIAL 45.340 DE 14 de octubre de 2003
A continuación se citarán los artículos concernientes a la profesión de ingeniería de la ley:
Artículo 6º. Requisitos para ejercer la profesión. Para poder ejercer legalmente la Ingeniería,
sus profesiones afines o sus profesiones auxiliares en el territorio nacional, en las ramas o
especialidades regidas por la presente ley, se requiere estar matriculado o inscrito en el Registro
Profesional respectivo, que seguirá llevando el Copnia, lo cual se acreditará con la presentación
de la tarjeta o documento adoptado por este para tal fin.
Artículo 12. Experiencia profesional. Para los efectos del ejercicio de la ingeniería o de alguna
de sus profesiones afines o auxiliares, la experiencia profesional solo se computará a partir de la
fecha de expedición de la matrícula profesional o del certificado de inscripción profesional,
respectivamente. Todas las matrículas profesionales, certificados de inscripción profesional y
certificados de matrícula otorgados con anterioridad a la vigencia de la presente ley conservan
su validez y se presumen auténticas.
Artículo 45. Régimen de inhabilidades e incompatibilidades que afectan el ejercicio. Incurrirán
en faltas al régimen de inhabilidades e incompatibilidades y por lo tanto se les podrán imponer
las sanciones a que se refiere la presente ley:
a) Los profesionales que actúen simultáneamente como representantes técnicos o
asesores de más de una empresa que desarrolle idénticas actividades y en un mismo
tema, sin expreso consentimiento y autorización de las mismas para tal actuación;
81
b) Los profesionales que en ejercicio de sus actividades públicas o privadas hubiesen
intervenido en determinado asunto, no podrán luego actuar o asesorar directa o
indirectamente a la parte contraria en la misma cuestión;
c) Los profesionales no deben intervenir como peritos o actuar en cuestiones que
comprendan las inhabilidades e incompatibilidades generales de ley.
Ley De Protección De Datos (Ley 25326) Certificadas Por ISI.
La sección 2.4.2 fue tomada del sitio Web http://isi.cieer.org.ar/proyectos.php.
A mediados de 2004 fue aprobada la Ley de Protección de Bases de Datos. Sencillamente el
objetivo a través de la misma es controlar lo que las empresas y organismos poseen
almacenados como datos de “la gente”, basado en la Ley de Habeas Data, ley existente en casi
todos los países del mundo que busca impedir que sea divulgada cierta información
confidencial como por ejemplo toda información sensible como Afiliación Política, Religiosa,
Sexo, etc.
Con el objeto de controlar la información que las empresas y organismos poseen de sus
clientes, afiliados, empleados, etc. uno sus principales activos, la información, y aumentar el
control el estado Argentino dispuso normas al respecto.
CIEER-ISI busca viabilizar los mecanismos de certificación de bases de datos, de acuerdo a
sus incumbencias profesionales, haciéndolo a través de profesionales matriculados (ISI),
asegurándole un verdadero proceso de fidelización de las mismas. Cabe aclarar que lo que
diferencia a cada profesional, son las incumbencias profesionales, que solo las puede dar la
UNIVERSIDAD, no las pueden dar, las maestrías, los colegios de profesionales, los cursos, ni
mucho menos la experiencia laboral.
82
Ética En Los Profesionales De TI
La sección 2.4.3 fue tomada de ETICA EN TI, De la Teoría General al Gobierno de TI,
Jeimy J. Cano, Ph.D, CFE
Debido a la naturaleza de confidencialidad de los datos manejados durante el desarrollo del
proyecto en la Ferretería Metropolis 84 Ltda, debe existir un marco de referencia alusivo a la
ética profesional del Ingeniero de los Sistemas de Información que fundamente su perfil
profesional para dirigir y participar en los proyectos de carácter de auditoria y análisis de las
estructuras de los datos históricos de una compañía.
Para todo profesional de TI es absolutamente imprescindible tener un perfil ético
profesional que le permita discernir las opciones o alternativas con las cuales cuenta al afrontar
una situación, definir su carácter con aplomo y diplomacia frente a los jefes administradores de
la compañía y poder tomar una decisión adecuada, previa a una evaluación de sus
consecuencias para todas las áreas de la compañía, para sus subalternos y para el sistema de
información.
Se especifican las obligaciones del profesional frente a todos los criterios sociales que se
ve afectados por su oficio, detalla las actitudes de un profesional de TI que no tiene formación
ética profesional y ofrece un cuadrante de Nivel de formación Ética vs Legalidad de las
acciones para definir su perfil y detectar fraudes en la compañía.
Ley Estatutaria Nº 221/07 Cámara- 027 /06 Senado, Habeas Data
La sección 2.4.4 fue tomada del Informe de Conciliación al Proyecto de ley Estatutaria No. 221/07Cámara -
027/06 Senado acumulado con el No. 05/06 Senado, “Por la cual se dictan las disposiciones generales del habeas
data y se regula el manejo de la información contenida en bases de datos personales, en especial la financiera,
crediticia, comercial, de servicios y la proveniente de terceros países y se dictan otras disposiciones”
83
A continuación se citan los artículos de la ley de la administración de los bancos de datos:
Artículo 4°. Principios de la administración de datos. En el desarrollo, interpretación y
aplicación de la presente ley, se tendrán en cuenta, de manera armónica e integral, los principios
que a continuación se establecen:
a) Principio de veracidad o calidad de los registros o datos. La información contenida en los
bancos de datos debe ser veraz, completa, exacta, actualizada, comprobable y comprensible. Se
prohíbe el registro y divulgación de datos parciales, incompletos, fraccionados o que induzcan a
error;
b) Principio de finalidad. La administración de datos personales debe obedecer a una finalidad
legítima de acuerdo con la Constitución y la ley. La finalidad debe informársele al titular de la
información previa o concomitantemente con el otorgamiento de la autorización, cuando ella sea
necesaria o en general siempre que el titular solicite información al respecto;
c) Principio de circulación restringida. La administración de datos personales se sujeta a los
límites que se derivan de la naturaleza de los datos, de las disposiciones de la presente ley y de los
principios de la administración de datos personales especialmente de los principios de
temporalidad de la información y la finalidad del banco de datos.
Los datos personales, salvo la información pública, no podrán ser accesibles por Internet o por
otros medios de divulgación o comunicación masiva, salvo que el acceso sea técnicamente
controlable para brindar un conocimiento restringido sólo a los titulares o los usuarios
autorizados conforme a la presente ley;
d) Principio de temporalidad de la información. La información del titular no podrá ser
suministrada a usuarios o terceros cuando deje de servir para la finalidad del banco de datos;
e) Principio de interpretación integral de derechos constitucionales. La presente ley se
interpretará en el sentido de que se amparen adecuadamente los derechos constitucionales, como
84
son el hábeas data, el derecho al buen nombre, el derecho a la honra, el derecho a la intimidad y
el derecho a la información. Los derechos de los titulares se interpretarán en armonía y en un
plano de equilibrio con el derecho a la información previsto en el artículo 20 de la Constitución y
con los demás derechos constitucionales aplicables;
f) Principio de seguridad. La información que conforma los registros individuales constitutivos
de los bancos de datos a que se refiere la ley, así como la resultante de las consultas que de ella
hagan sus usuarios, se deberá manejar con las medidas técnicas que sean necesarias para
garantizar la seguridad de los registros evitando su adulteración, pérdida, consulta o uso no
autorizado;
g) Principio de confidencialidad. Todas las personas naturales o jurídicas que intervengan en la
administración de datos personales que no tengan la naturaleza de públicos están obligadas en
todo tiempo a garantizar la reserva de la información, inclusive después de finalizada su relación
con alguna de las labores que comprende la administración de datos, pudiendo sólo realizar
suministro o comunicación de datos cuando ello corresponda al desarrollo de las actividades
autorizadas en la presente ley y en los términos de la misma.
85
C a p ì t u l o 3
DELIMITACIÓN
86
3.1 Delimitación Temporal Y Espacial
Delimitación Temporal
El proyecto se ceñirá a una estimación de tiempo de 8 meses, teniendo en cuenta los posibles
riesgos que se puedan presentar y cambiar en un instante dado la fecha de finalización del
proyecto.
Delimitación Espacial
El proyecto se limitará al espacio de trabajo del departamento de sistemas que pertenece a la
Ferretería Metrópolis 84 Ltda., ubicado en la Carrera 43 Calle 84 Esquina.
3.2 Delimitación Técnica
• Microsoft® SQL Server 2005 Enterprise Edition, motor de base de datos utilizado para
soporte de la base de datos multidimensional.
Microsoft® SQL Server Analysis Services.
Diseñador de MS SQL Server Analysis Services. Versión 9.00.1399.00
Microsoft® SQL Server Bussiness Intelligence Development .
Microsoft® SQL Server Integration Services
Diseñador de MS SQL Server Integration Services. Versión
9.00.1399.00
87
Microsoft® SQL Server Reporting Services
Diseñador de MS SQL Server Reporting Services. Versión 9.00.1399.00
Microsoft® SQL Server Management Studio.
• Microsoft® Server 2003 R2 Enterprise Edition Service Pack 1
• Microsoft® Visual Studio 2005. Versión 8.0.50727.42
• Microsoft®.NET Framework. Versión 2.0.50727.
• Microsoft Internet Information Server Versión 6.0
3.3 Delimitación Financiera
3.3.1 Estructura De Descomposición Del Trabajo (EDT)18:
Generación Inicial Del Proyecto
Costo en unidades de tiempo: 20 días.
• Generación de la idea del proyecto.
• Conformación del equipo de trabajo.
• Documentación inicial.
• Presentación y sustentación frente al área administrativa de la empresa.
• Acuerdo de reuniones según disponibilidad del equipo de trabajo.
18 Estrategias gerenciales: Gerencia de proyectos, gerencia para el emprendimiento, gestión tecnológica y gestión por resultados, Modulo 1 Gestión Operativa [15].
88
Análisis de Requerimientos:
Costo en unidades de tiempo: 120 días.
• Evaluación inicial de las necesidades de información del negocio.
• Acercamiento a la definición de requerimientos.
• Preparación de las entrevistas.
• Investigación previa a entrevistas.
• Selección de los entrevistados.
• Desarrollo del cuestionario.
• Inicio y desarrollo de la entrevista.
• Análisis e interpretación de resultados.
o Análisis e interpretación de los Resultados de las Entrevistas.
o Análisis e interpretación de los Resultados de las Encuestas.
• Definición de requerimientos.
o Requerimientos funcionales.
o Requerimientos no funcionales.
o Especificación de requerimientos.
o Paquetes de información.
o Negociación de requerimientos.
89
Modelos Del Sistema
Costo en unidades de tiempo: 18 días.
• Modelo dimensional. • El DataMart. • Definición de la granularidad. • Dimensiones.
o Dimensión tiempo. o Dimensión clientes. o Dimensión producto. o Dimensión tipo de venta. o Dimensión segmento de clientes. o Dimensión vendedor. o Tablas de hechos
Diseño técnico de la Arquitectura.
Costo en unidades de tiempo: 18 días.
• Datos.
• Mapeo de los datos en el modelo dimensional.
• Back Room.
o Extracción.
o Transformación.
o Carga.
• Front Room.
90
Infraestructura del Data warehouse.
Costo en unidades de tiempo: 40 días.
• Proceso de Extracción, Transformación y Carga.
• Herramientas para el proceso ETL.
• Proceso ETL para la dimensión Clientes.
o Determinación de registros candidatos.
o Conclusión.
o Selección de los registros de clientes a cargar.
• Proceso ETL para la dimensión Vendedores.
• Proceso ETL para la dimensión Productos.
• Proceso ETL para la dimensión Tiempo.
• Proceso ETL para la tabla de hechos.
3.3.2 Diccionario De La EDT19
Acercamiento a la definición de requerimientos: Etapa anterior a la captura de requerimiento donde se tiene una visión de las necesidades de información de la empresa. Acuerdo de reuniones según disponibilidad del equipo de trabajo: En esta etapa se escogieron los mejores días para realizar reuniones con los miembros del equipo de trabajo Análisis e interpretación de los Resultados de las Encuestas:
19 Estrategias gerenciales: Gerencia de proyectos, gerencia para el emprendimiento, gestión tecnológica y gestión por resultados, Modulo 1 Gestión Operativa [15].
91
Los resultados de la encuesta fueron tabulados y documentados, para luego ser analizados por los miembros del equipo de trabajo. Análisis e interpretación de los Resultados de las Entrevistas: Los resultados de las entrevistas fueron documentados formalmente, para luego ser analizados por los miembros del equipo de trabajo. Análisis Final: Conclusión final del análisis de las encuestas y de las entrevistas. Back Room: Construcción de la disposición lógica de la base de datos que sirve para realizar las operaciones de Extracción y transformación de los datos de la base de datos transaccional. Carga: Estructuración del proceso de llenado de las tablas del modelo dimensional en el Back Room. Conclusión(Proceso ETL para la dimensión Clientes): Análisis de los resultados de las consultas de sondeo a la tabla de clientes del sistema transaccional. Conformación del equipo de trabajo: El responsable directo con la empresa escogió a su equipo de trabajo bajo sus criterios de selección profesional. Datos(Diseño técnico de la Arquitectura): Los datos constituyen la información del Datamart, se refieren al componente principal de los procesos que llevan a la construcción de la aplicación. Definición de la granularidad: Definición del nivel de detalle. Desarrollo del cuestionario: Construcción de las preguntas del cuestionario general para el área de ventas de la empresa. Determinación de registros candidatos: Proceso de selección de los registros con mayor nivel de calidad y completitud de datos para el llenado de la dimensión clientes.
92
Dimensión clientes: Representación dimensional de los clientes del sistema transaccional. Dimensión producto: Representación dimensional de los productos del sistema transaccional. Dimensión segmento de clientes: Representación dimensional de los segmentos de clientes del sistema transaccional. Dimensión tiempo: Representación dimensional del tiempo y su nivel de detalle. Dimensión tipo de venta: Representación dimensional de los tipos de venta del sistema transaccional. Dimensión vendedor: Representación dimensional de los vendedores del sistema transaccional. Dimensiones: Criterios de análisis del modelado dimensional. Documentación inicial: Documentos de la etapa inicial del proyecto elaborados para la sustentación frente a la Universidad y el personal Administrativo. El DataMart: Mercado de datos del Data Warehouse. Especificación de requerimientos: Etapa en la que se definen los requerimientos del sistema. Evaluación inicial de las necesidades de información del negocio: Se evalúan las necesidades de la empresa para definir áreas críticas en el flujo de proceso que no disponen de información estadística adecuada. Extracción: Agrupación de los procesos de extracción de datos. Front Room: Estructura de visualización de los datos extraídos, transformados y cargados.
93
Generación de la idea del proyecto: Punto de partida donde el Coordinador de sistemas ofrece el Data Warehouse como proyecto de solución. Glosario: Terminología técnica Herramientas para el proceso ETL: Aplicación que permite la Extracción, Transformación y Carga de datos de una fuente a un destino. Inicio y desarrollo de la entrevista: Punto inicial de las entrevistas. Investigación previa a entrevistas: Antes de entrevistar con anticipación se determina el grado de importancia de la información proporcionada por el entrevistado. Mapeo de los datos en el modelo dimensional: Elaboración de un mapa que permite llevar los datos desde su origen en el sistema transaccional hasta sus tablas destino en el modelo dimensional. Modelo dimensional: Construcción del modelo base del sistema analítico. Modelos del sistema: Clasificación de los grupos de modelos del sistema. Negociación de requerimientos: Los requerimientos resultantes del análisis de las entrevistas fueron plasmados en consultas negociadas con los usuarios. Paquetes de información: Construcción de la estructura que permite la generación de un modelo en red de estrella a partir de los requerimientos. Preparación de las entrevistas: Etapa de preparación de las preguntas a los entrevistados. Presentación y sustentación frente al área administrativa de la empresa. Reunión con el área administrativa para la presentación y sustentación del proyecto. Proceso de Extracción, Transformación y Carga: Flujo de procesos crítico del Data Warehouse.
94
Proceso ETL para la dimensión Clientes: Proceso de Extracción, Transformación y Carga para la dimensión Clientes. Proceso ETL para la dimensión Productos: Proceso de Extracción, Transformación y Carga para la dimensión Productos. Proceso ETL para la dimensión Tiempo: Proceso de Extracción, Transformación y Carga para dimensión Tiempo . Proceso ETL para la dimensión Vendedores: Proceso de Extracción, Transformación y Carga para la dimensión Vendedores. Proceso ETL para la tabla de hechos: Proceso de Extracción, Transformación y Carga para la tabla de hechos. Requerimientos funcionales: Clasificación de las necesidades principales de información. Requerimientos no funcionales: Procesos, fuente de datos, documentos revisados y la base de datos estratégica Selección de los entrevistados: Proceso de selección del personal crítico en la toma de decisiones correspondiente a la dependencia directamente afectada por el proyecto. Selección de los registros de clientes a cargar: Proceso de selección de los registros más aptos para ser cargados a la dimensión clientes. Tablas de hechos: Construcción de la tabla de hechos del modelo dimensional. Transformación: Proceso de estandarización de los datos y de sus tipos.
95
3.3.3 Información De Respaldo De La Estimación De Costos De
Las Actividades.
• Estimado de días trabajados por persona en el proyecto de la fecha de inicio:
25 de Marzo 2007; hasta su fecha de finalización de acuerdo con la estimación de
tiempo de Ocho (8) meses calendario: 25 de Noviembre del 2007
• Total de tiempo estimado en días: 8 x 30 días = 240
Reducido por la proporción del tiempo muerto de 10% sobre el valor total:
240 – (240 x 0.1) = 216 días de trabajo.
• Valor del salario de un ingeniero: $1’350.00020
• Total de horas laboradas mensuales: 240 horas.
• Valor de la hora de trabajo: $1’350.000 / 240 horas = $5.625
• Promedio de horas diarias a la semana dedicadas al desarrollo del proyecto:
4 horas diarias.
• Precio de un (1) día de trabajo por integrante: 4 horas diarias x $5.625 = $22.500
Total del costo de fuerza de trabajo por persona:
$22.500 x 216 días de trabajo= $4’860.000
Total del costo de fuerza de trabajo: $14’580.000
20 Información proporcionada por el Departamento de Talento Humano de Ferretería Metropolis 84 Ltda., Octubre 31 del 2007
96
3.3.4 Activos De Los Procesos De La Empresa
Activos De Los Procesos De La Organización
Los activos comprometidos en los procesos de Ferretería Metrópolis 84 Ltda. afectados por el
proyecto son todos los, activos tanto físicos como no tangibles involucrados en la creación y
entrega de la información estratégica sobre las ventas a las áreas administrativas:
Activos Físicos
Corresponde a toda la infraestructura de hardware que soporta el sistema de información
existente desde sus entradas hasta sus salidas:
Servidores: La ausencia de un servidor especializado para el análisis de la información
estadística en Ferretería Metropolis 84 Ltda. y la generación de reportes históricos compromete
seriamente el desempeño general de la arquitectura Cliente/Servidor del sistema transaccional
Milenium que es de carácter 24/7 (24 horas al día, 7 días de la semana) encargado del soporte
operativo de la empresa.
Desempeño de la base de datos: Al no existir una base de datos diseñada e implementada en
un servidor especializado exclusivamente para un análisis exhaustivo de los datos, el
rendimiento de la base de datos decae al intentar generar reportes históricos directamente
sobre los datos almacenados por las transacciones operativas de la empresa cuando responde a
las consultas de la aplicación estadística existente.
Desempeño de la red de datos: Teniendo todos los servicios centralizados en un servidor
incluido el de la base de datos transaccional, la falencia en el rendimiento de la base de datos
hace que los otros servicios:
97
• Internet.
• Intranet.
• DHCP (Protocolo de configuración dinámica de clientes)
• DNS (Servicio de nombre de dominio).
• Servicio de Aplicaciones.
• Servicio de Impresión y Faxes.
• Servicio de almacenamiento masivo de información compartida.
Se encuentren en riesgo de no atender las peticiones de cada una de las máquinas
clientes de las dependencias de la empresa, incluyendo el área de ventas y generar perdidas
monetarias a la compañía, reduciendo así su patrimonio.
Funcionalidad del motor de base de datos existente: El motor de base de datos existente
Microsoft® SQL Small Business Server 2000 no dispone de las funciones requeridas para
ofrecer el análisis descrito por los administradores de la empresa.
De esta forma queda justificado el hecho de que es necesario disminuir el riesgo de
inactividad del sistema transaccional, separando el análisis estadístico del soporte operativo de
las transacciones empresariales: se hace necesario adquirir el motor de base de datos adecuado
que permita la funcionalidad necesaria de la arquitectura Data Warehouse y que mantenga la
compatibilidad con las herramientas en uso actual.
Activos No Tangibles De La Compañía
Los activos no tangibles de la compañía afectados por el proyecto son:
La información histórica: El activo más importante de la compañía, único, privado y
confidencial al que pocas personas tienen acceso y del que muchas personas desconocen su
98
potencial al ser integrado su contenido y clasificado, restringido su acceso y los privilegios de
modificación para cada usuario.
Las licencias de software: Parte lógica del sistema de información: Se hace necesaria la
adquisición de un motor de base de datos especializado, Microsoft® SQL Server 2005 Standard
Edition, que ofrece la solución y la funcionalidad necesaria para suplir las necesidades de
información detallada en los requerimientos de información estadística de la empresa y las
características técnicas del modelado de base de datos multidimensional.
Al adquirir una licencia de un motor de base de datos para propósito analítico se
incrementa el nivel de competitividad de la empresa, ya que Microsoft® SQL Server 2005
Standard Edition ofrece, además de una solución especializada para el sistema analítico,
disponibilidad del 99.9% en las aplicaciones de misión crítica, 35% de incremento en la
velocidad de los procesos transaccionales, costo total de propiedad (TCO) más bajo del
mercado, una plataforma completa de Inteligencia de Negocios, reportes en tiempo real y en
múltiples formatos, escalabilidad, herramientas de administración, replicación, notificación,
servicios de integración, servicios de análisis, servicios de reportes.
Valor de la licencia de software:
El costo de la licencia del software es de $3’573.60021 IVA INCLUIDO: 5 licencias de
usuarios incluidas.
3.3.5 Depreciación De Los Equipos.
Los equipos empleados en el desarrollo del proyecto han sufrido una depreciación a causa del
desgaste por su uso intenso para labores para las que no fueron construidos, ya que los
21 División de Alianzas Estratégicas de Dell del mes de Enero del año 2007, página 15. El precio puede cambiar dadas las condiciones del proveedor, de las condiciones del mercado y de la negociación del Coordinador del Departamento de Sistemas.
99
procesos de un Data Warehouse deben ser realizados por un servidor robusto y no por PCs de
escritorio ni equipos portátiles.
1. Equipo personal de Mauricio Rodríguez: Desde un principio se tomo como
equipo cliente durante la etapa de generación inicial del proyecto para digitalizar
información. Luego el modelado del sistema paso a una configuración de
servidor con plataforma Microsoft Windows 2003 Server R2, Microsoft SQL
Server 2005 Enterprise Edition, Microsoft Visual Studio 2005 para la
generación de pruebas de modelos y prototipos preliminares.
2. Equipo personal de Sandra Peñaranda: Este equipo fue destinado durante el
Análisis de requerimientos para digitalizar todos los documentos generados por
cada actividad de trabajo desglosada. También sirvió para digitalizar los
distintos capítulos de la tesis universitaria y para agrupar y centralizar la
información.
3. Equipo portátil de Cesar Orozco: Este equipo fue destinado para las pruebas en
las etapas finales del proyecto: Diseño técnico de la arquitectura e
Infraestructura e Infraestructura del Data warehouse. Estas etapas generan su
documentación respectiva digitalizada en el equipo personal de Sandra
Peñaranda y sus pruebas reducen el riesgo de fallos al implementar la solución
final en la arquitectura cliente/servidor de Ferretería Metropolis 84 Ltda.
Dado que los equipos no fueron usados el 100% del tiempo del proyecto para sus tareas
designadas, procedemos a estimar el costo de depreciación en una proporción del 70% del
tiempo de trabajo estimado con el tiempo muerto reducido: 216 días de trabajo x 0.7 = 151.2
= 151 días de trabajo.
Horas promedio diarias trabajadas: 4 horas diarias.
100
Para tener un marco de referencia utilizaremos el consumo de energía eléctrica y su valor en
KWs para los tres (3) equipos personales y para el portátil según HP y ENERGY STAR:
Consumo de electricidad de un PC de escritorio típica de 75W.
Consumo de un portátil de escritorio típico de 27.2W.
Consumo de electricidad de un Monitor CRT típico de 80W.
• Calculamos el consumo de energía
Consumo en energía= (75W+80W) x 151 x 4 = 93.620WH = 93,62KW
Consumo en pesos = 93,62 x $239.98 = $22.466.92 por Pc de escritorio.
• Calculamos luego el consumo de energía del portátil.
Consumo en energía= 36.1W x 151 x 4 = 21.804WH = 21,80KW
Consumo en pesos = 21,80 x $239.98 = $5.232.61 para el portátil.
Total de costos de depreciación de los equipos: $50.166,45
3.3.6 Cronograma Del Proyecto
Figura 3.1 Principales actividades del proyecto en cronología de semanas anuales.
101
Las actividades presentadas en el diagrama empleando la herramienta GanttProyect
2.0.2 de licencia GNU nos muestra en semanas anuales la continuidad y ejecución de las
actividades principales del proyecto que han sido desglosadas en el EDT.
3.3.7 Gastos De Transporte, Papelería, Estadías Y Alimentación
Transporte: Dado que el equipo de trabajo acordó reuniones los domingos por la
disponibilidad de horarios, cada semana en el cronograma indica una reunión del equipo de
trabajo indistintamente de la escogencia del sitio de trabajo, por lo que esta frecuencia coincide
con la alimentación y estadía.
Siendo tres (3) integrantes que se concretan en la casa de uno (1) disponemos de dos
(2) integrantes moviéndose por la ciudad:
$1.400 pasaje de transporte urbano los Domingos.
$3.000 almuerzo por persona.
Número de semanas: 34 semanas proyectadas = 34 reuniones.
Total de gastos en transporte:
$1.400 x 2 integrantes x 2 pasajes x 34 reuniones = $190.400
Total de gastos en comida y estadía:
$3.000 x 3 integrantes x 34 reuniones = $306.000
Promedio Total de gastos varios: $600.000
La papelería incluye la impresión del libro Ponniah Paulraj, Data Warehousing Fundamentals
A Comprehensive guide to IT Professionals John Wiley & Sons © 2001
Número de páginas: 518 páginas.
Resma de papel: $9000 (Cantidad de hojas: 520)
Capacidad de impresión de la impresora: 300 páginas por cartucho.
102
Precio del cartucho: $45.000
Precio de Impresora Lexmark 640 Series $95.000
Recarga del cartucho: $15.000
Total de gastos de papelería: $174.000
.
3.3.8 Contrato
Total de costos del proyecto: $8’872.126,45
A continuación se muestra la relación de todos los costos calculados del proyecto para una
avaluación monetaria:
DESCRIPCION DEL COSTO SUMA TOTAL DE DINERO
Total del costo de fuerza de trabajo $14’580.000
Costo de la licencia del software $3’573.600
Total de costos de depreciación de los equipos $50.278,64
Total de gastos en transporte $190.400
Total de gastos en comida y estadía $306.000
Total de gastos de papelería $174.000
Total de gastos varios $600.000
TOTAL COSTOS $19’474.278,64
Tabla 3.1 Descripción de costos y suma total de dinero.
Consensos sobre la delimitación financiera del proyecto:
1. Los costos de: fuerza de trabajo, depreciación de los equipos, gastos en transporte,
gastos en comida y estadía y de gastos de papelería no son de carácter obligatorio y la
103
empresa no está en compromiso de celebración de un contrato para la financiación de
los mismos.
2. El Costo de la licencia del software es de carácter necesario para una implementación
exitosa bajo los lineamientos del marco legal y su código ética profesional, y representa
un incremento significativo en el repertorio de herramientas de software competitivas.
104
C a p ì t u l o 4
DISEÑO METODOLÓGICO.
105
4.1 Tipo De Investigación
De acuerdo a los principales tipos de investigación según Caiceo y Mardones “Caiceo y
Mardones- Elaboración de tesis e informes Técnico-Profesionales-Editorial Conosur”, el presente proyecto
se adapta a la definición que dicho texto ofrece sobre la “Investigación Aplicada”, es decir, la
investigación que se caracteriza por la búsqueda de la utilización y confrontación de los
conocimientos teóricos que se adquieren con la realidad, esta investigación se encuentra
estrechamente vinculada con la investigación básica o teórica, pues depende de los resultados y
avances de esta última; recordemos que toda investigación aplicada requiere de un marco teórico.
4.2 Tipo De Estudio
Dadas las características del entorno en el cual se desarrollará este proyecto, es preciso realizar
una investigación que involucrará dos tipos de estudios; se requiere comenzar por un estudio
exploratorio, que constituye el primer nivel de conocimiento sobre el problema objeto de
investigación en el presente proyecto, para luego entrar a describir las características más
importantes del problema a través de un estudio descriptivo en el cual se ha de tener en cuenta
como elemento fundamental la muestra seleccionada.
106
4.3 Método Utilizado
En el ámbito general de los mecanismos para aprehender metódicamente la realidad, el presente
trabajo se inscribe en el llamado enfoque o método Analítico sintético debido a que se hizo necesario
un análisis por cada una de las fases que componen al proyecto para luego sintetizar de las fases
anteriores al momento de implementar la solución.
4.4 Técnicas De Recolección De La Información
El levantamiento y la recopilación de información del presente proyecto, se sustentará
principalmente en el diálogo y la conversación dirigida, con los gerentes de la empresa o
funcionarios en posiciones directivas en el departamento de ventas de la misma y con el personal
operacional de dicho departamento -los cuales son los usuarios actuales del sistema existente,
quienes nos proporcionarán requerimientos y serán afectados por el sistema propuesto- bajo los
criterios técnicos de la entrevista semi-estructurada o focalizada, en la cual existen una serie de
aspectos predeterminados sobre los cuales se quiere consultar al entrevistado, pero dejando un
margen o espacio para profundizar, complementar o enriquecer la información recopilada con
otros comentarios, opiniones o visiones del entrevistado, y que agreguen valor cualitativo a la
investigación
Esta técnica será además complementada con la observación de doce personas que
efectúan el trabajo operativo del departamento de ventas con el fin de estudiar, analizar y
determinar qué se está haciendo, cómo se está haciendo, quién lo hace, cuándo se lleva a cabo,
cuánto tiempo toma, dónde se hace y por que se hace. Encuestas o cuestionarios a las doce personas
que realizan el trabajo operacional del departamento de ventas para tomar un rápido y preciso
107
flujo de información sobre los comportamientos y necesidades que deben suplirse con la
implantación del sistema. Entrevistas a cinco personas que constituyen el personal administrativo y
táctico de la empresa. Diagramas de flujo con el fin de representar de manera gráfica los pasos del
proceso de ventas de la empresa y determinar cómo funciona realmente dicho proceso.
4.5 Población Objetivo
Población universo: Ferreterías de la ciudad de Barranquilla.
Población afectada: Ferrería Metrópolis 84 Ltda.
Población objetivo: Departamento de ventas de la Ferrería Metrópolis 84 Ltda.
4.5.1 Justificación Estadística De La Muestra
La población objetivo del proyecto se encuentra delimitada por Ferretería Metrópolis 84 Ltda –
Departamento de Ventas. Para calcular el tamaño de la población nos remitimos al manual de
funciones y procedimientos del cual obtuvimos la siguiente información relevante y de alta
confiabilidad: Véase Tabla 4.3
108
CARGOS INVOLUCRADOS
CON EL DEPARTAMENTO
DE VENTAS
CANTIDAD
DE
EMPLEADOS
Asesor de Ventas Interno 7
Asesor de Ventas Externo 2
Asesor de Ventas (pintura) 1
Coordinador de ventas 1
Coordinador de sala Corona 1
Tamaño de la Población (N) 12
Tabla 4.1 Número de empleados por cargo en el departamento de ventas de la Ferretería
Metropolis 84 Ltda.
Debido a la certificación de Calidad ISO 9001 que posee la empresa, utilizaremos un
nivel de confianza ideal del 95% y un nivel de significancia del 5%.
4.5.2 Tamaño De La Muestra.
Para determinar el tamaño representativo de la muestra (n) utilizaremos la ecuación 4.1,
donde N es el tamaño de la población, e es el nivel de significancia y n tamaño de la muestra.
Ne
Nn*1 2+
= (4.1)
109
Por lo tanto al reemplazar los valores tenemos que:
121212*05.01
122
=⇒=+
= nn
De esta manera, encontramos que el tamaño de muestra representativo a utilizar es de doce (12).
110
C a p ì t u l o 5
ANÁLISIS E INTERPRETACIÓN DE RESULTADOS
111
5.1 Análisis E Interpretación De Los Resultados
Luego de haberse efectuado las entrevistas con los gerentes de la empresa, se ofrecen la
presentación de las entrevistas llevadas a cabo (ver anexos B al F) y las conclusiones obtenidas a
partir de las opiniones de los gerentes sobre los tópicos referentes a los análisis necesarios para la
toma de decisiones.
El departamento de Ventas es uno de los pilares de la empresa y objeto de estudio del
presente proyecto. Los criterios concernientes respecto a la segmentación del mercado fueron
obtenidos a lo largo de las diferentes entrevistas y surgen del análisis de la información
proporcionada por cada una de las personas entrevistadas, para finalmente concluir que la
segmentación de los clientes, es cambiante en el tiempo. El gerente comercial discrimina sus
clientes básicamente por dos conceptos imprescindibles: Rentabilidad y Venta, en un lapso de
tiempo determinado.
112
Figura 5.1. Representación de la segmentación de clientes
Cada uno de estos cuadrantes al ser analizado proporciona un amplio conocimiento
sobre la segmentación de los clientes de la empresa, las compras efectuadas por los mismos y
los vendedores asociados a ventas específicas.
De igual manera, se pudieron establecer los criterios deseables para las diversas
comparaciones respecto al tiempo.
113
Analizando la actividad económica empresarial con el apoyo del departamento de
contabilidad se identificaron los hechos o eventos económicos que más tienen influencia en el
patrimonio de la empresa, a saber:
1. Hechos económicos:
• Hechos de ventas o ingresos.
• Hechos de compras o egresos.
2. Hechos financieros:
• Hechos de deudas.
• Hechos de créditos.
• Hechos de pagos.
• Hechos de cobros.
Luego, cotejando con la información ya conocida, se pudo establecer claramente como evento
económico objeto de análisis en el contexto de esta propuesta a el hecho de ventas, por lo que los
criterios de análisis que surgieron, corresponden a los requerimientos deseados por la gerencia.
114
5.2 Análisis E Interpretación De Los Resultados De Las
Encuestas
Las entrevistas con el personal gerencial de la empresa fueron complementadas con la
aplicación del instrumento cuestionario diseñado para el personal de gerencia media y
operativa del departamento de ventas, a objeto de conocer de primera fuente, la opinión sobre
los aspectos en estudio.
Luego de analizar lo comentado por los gerentes entrevistados en torno al proceso de
ventas actual y al proceso ideal deseado, al papel decisivo que debe jugar el correcto y
adecuado estado de la información frente a la toma de decisiones gerenciales, y de revisar los
resultados que arrojaron los instrumentos aplicados al personal operativo del departamento de
ventas de la organización, es posible afirmar que prevalece en los gerentes y funcionarios de la
empresa una actitud positiva hacia el desarrollo e implementación de un sistema especifico que
les sirva de soporte para tomar decisiones mas acertadas que beneficien el crecimiento de la
Ferretería Metrópolis 84 Ltda.
Parece existir un consenso entre los resultados, en cuanto a que la información de sus
bases de datos transaccionales no son lo suficientemente adecuadas como para tomar
decisiones, ésto expresado en la exigencia de reportes que el sistema transaccional no está en
capacidad de entregar por sí mismo, esto lejos de una ventaja, puede en un momento dado
limitar el crecimiento o impedir el aprovechamiento de oportunidades para la empresa.
Se acepta la existencia de un módulo estadístico, que en cierta forma, por su misma
naturaleza estática, no es adecuado para ajustarse a los requisitos frecuentemente cambiantes
que rodean el ambiente de la empresa.
115
Finalmente, podemos decir que se evidencia como aspecto positivo, el reconocimiento
de que la instauración de la solución propuesta es viable, la necesidad de la información
estratégica constituye una necesidad de primera mano y que existe un conocimiento claro por
parte de la gerencia de la empresa del alcance del proyecto.
A continuación, se presentan los resultados obtenidos en cada uno de los ítems incluidos en el
cuestionario.
Resultados Obtenidos
Pregunta Nº 1. ¿Conoce usted que es un Sistema de Soporte a la toma de Decisiones?
60%
40% SINO
El 60% de los consultados manifestaron estar en conocimiento de este tipo de
sistemas, y un 40% respondió desconocerlos, lo cual indica que una parte considerable de los
encuestados son concientes del trabajo que se desea realizar en la empresa.
116
Pregunta Nº 2. ¿Conoce usted que es una Bodega de Almacenamiento de Datos?
60%
40% SINO
Como era fácil de prever, el 60% de los consultados manifestó estar en conocimiento
de lo que es una Bodega de Almacenamiento de Datos, y un 40% respondió desconocerlos, lo
cual concuerda con el resultado anteriormente descrito.
Pregunta Nº 3. ¿Qué nivel de importancia tiene para usted la información estadística-histórica
para la generación de estrategias de mercadeo?
80%
20% 0%ALTOMEDIOBAJO
En este ítem se planteaba indagar el nivel de importancia considerado por los
encuestados respecto a la información histórica y conocer hasta qué punto podría existir una
adecuada aceptación del futuro sistema, y concebir este hecho como una ventaja o como un
factor antagónico para el proceso de desarrollo, dependiendo de los resultados arrojados.
Pregunta Nº 4. ¿Qué porcentaje de efectividad tiene el módulo de estadísticas actual en la
identificación de clientes potenciales?
70%
30%0%
ALTOMEDIOBAJO
117
Como objetivo básico que motiva la creación de este ítem, es visualizar hasta que punto
el personal operativo y de gerencia media se encuentran concientes de las necesidades de
información adecuada y no disponible dentro de la empresa. Por lo anterior, se puede inferir
que un alto porcentaje del personal vinculado al departamento de ventas desconoce la
necesidad existente dentro del mismo, respecto a la información histórica y estratégica de las
cuales carecen.
Pregunta Nº 5. ¿Cuál clasificación de los clientes cree usted que predomina más en las ventas
de la empresa?
50%
10%
40%
MASCULINO
FEMENINO
PERSONAJURIDICA
La intención en este ítem era determinar que tan identificado tiene cada representante
de ventas (Personal operativo) el segmento de clientes por género que están adquiriendo
artículos de la empresa.
Agrupadas las respuestas según cada caso, un 50% consideró estar de acuerdo con que
el grupo de clientes más amplio de la empresa corresponde al género masculino, seguido del
grupo de las personas jurídicas y en menor proporción el personal femenino.
Pregunta Nº 6. ¿A qué fuentes de información acude usted cuando necesita datos
estadísticos?
Pregunta Nº 7. ¿En que circunstancias de la toma de decisiones cree usted, que se requiere del
uso del modulo de estadísticas como herramienta de soporte?
118
Ahondando en la posición del funcionario de gerencia media de manera especifica y del
personal operativo de manera indirecta, al plantear esta pregunta, un 90% consideró la
alternativa “todas”, evidenciando de esta forma, la alta aceptación de información estadística.
Un 10% planteó estar en desacuerdo con el ítem ya referido.
Pregunta Nº 8. ¿Cree usted que la implementación de un sistema de soporte a la toma de
decisiones puede incrementar el volumen de las ventas en la empresa?
100%
0%
SINO
A objeto de ampliar lo establecido en las anteriores preguntas, se perseguía en este ítem
conocer el mayor o menor acuerdo en torno a las facilidades que podría proporcionar un
sistema que soporte la toma de decisiones dentro del área de ventas de la empresa.
En esta dirección, el 100% del personal encuestado estuvo muy de acuerdo con la
implementación de un sistema de soporte a la toma de decisiones.
Pregunta Nº 9. ¿Conoce usted empresas locales que tengan esta tecnología aplicada a sus
procesos de información?
70%
30%SINO
90%
10% 0%TODASALGUNASNINGUNA
119
Esta interrogación lleva implícita, en cierta forma, una opinión por parte de cada
miembro del departamento de ventas de la empresa sobre las tecnologías existentes que sirvan
de soporte para la toma de desiciones en las empresas locales.
Pregunta Nº 10. ¿Cuáles de las siguientes ventajas considera usted que ofrece u ofrecerá un
sistema de soporte a la toma de decisiones a nivel empresarial?
44%
16%
28%
11% PRODUCTIVIDADCONTROLDESARROLLOPRESTIGO
En la creencia, de cada persona se observa que aunque las opiniones son variadas, el
sistema planteado como solución es visto como proveedor de ventaja competitiva y de control
interno.
Pregunta Nº 11. ¿Cree usted que las empresas ferreteras de Barranquilla están preparadas para
asimilar este cambio tecnológico?
50%50%SINO
Pregunta Nº 12. ¿Le gustaría contar con un sistema de soporte a la toma de decisiones basado
en tecnología actual, en el cuál se almacene la información de todas las ventas de la empresa?
100%
0%
SINO
En la misma orientación de los interrogantes anteriores, se persigue corroborar la
opinión de quien labora en el departamento de ventas de la empresa, en lo relativo a la
120
conveniencia o no de instrumentar acciones en pro del establecimiento de un sistema confiable
para soportar desiciones estratégicas para el departamento en mención.
121
C a p ì t u l o 6
PROPUESTA
122
6.1 Solución
6.1.1 Alternativas De Solución
Hay varios tipos de sistemas de información para esta tarea: sistemas de apoyo para
la toma de decisiones, sistemas de información ejecutiva y sistemas expertos.22
a) Sistemas De Apoyo Para La Toma De Decisiones (SATD)
Para ahorrar tiempo y esfuerzo en su toma de decisiones, los administradores
utilizan Sistemas De Apoyo Para La Toma De Decisiones (SATD). Se trata de
sistemas de información de cómputo diseñados para ayudar a los administradores
a seleccionar una entre las muchas alternativas a un problema, y para ayudar a las
organizaciones a incrementar su participación en el mercado, reducir los costos,
aumentar la rentabilidad y mejorar la calidad del producto.
El sistema proporciona a los gerentes acceso a algunos análisis que antes no
estaban disponibles. Desde el punto de vista técnico ciertos análisis pudrían ser
realizados por los gerentes, pero esto llevaría demasiado tiempo y en ocasiones
decisiones tardías, y por lo tanto malas.
Los SATD proporcionan análisis rápidos y complejos considerando grandes
cantidades de datos e información. Aunque la presencia de los SATD aumenta
según el nivel de administración, se utilizan en todos los niveles y a menudo por
personal no administrativo.
22 Oz Effy, Administración de sistemas de información[13]
123
b) Sistemas De Información Ejecutiva (SIE)
Los sistemas de información para ejecutivos son un tipo especial de SATD que
auxilia en caso de sobrecarga de información, como la que padecen los ejecutivos
de alto rango, los SIE seleccionan los datos mas relevantes para el análisis y
presentan los datos en forma de relaciones y graficas fáciles de comprender y
utilizar para la toma de decisiones.
Sistemas De Información Ejecutiva (SIE) son apoyos para la toma de decisiones
especialmente diseñados para administradores de alto rango, que les
proporcionan la información más esencial para hacer funcionar sus
organizaciones. Los SIE son útiles para ejecutivos, que casi siempre padecen la
sobrecarga de información, el fenómeno por el cual un gran volumen de
información ocasiona que se deba decidir antes que nada lo que es importante,
en lugar de ayudar a solucionar de inmediato problemas y tomar decisiones. A
diferencia de otros apoyos para la toma de decisiones, los SIE no contienen
modelos analíticos; más bien consolidan y resumen datos que se obtienen dentro
de la organización y de fuentes externas.
Los administradores de alto nivel toman decisiones sirviéndose de información
muy resumida. Revisan proporciones, como ventas por empleados por trimestre
o por año, ventas por región, ganancia sobre inversión y rotación de inventarios
para diferentes artículos. Los SIE pueden mostrar estos datos en forma de
graficas para detectar fácilmente las excepciones. A diferencia de los SATD
típicos, muchos SIEs no requieren que el usuario introduzca los valores de
ningún paramento. El sistema interactúa con las bases y los deposito de datos de
la organización y utiliza modelos predeterminados o seleccionados para responde
a consultas, desplegando los resultados en la forma solicitada. El propósito de los
SIE no es tanto realizar análisis por medio de complicados modelos como la
124
“perforación” en bases y depósitos de datos, a fin de encontrar la información
más relevante para la toma de decisiones ejecutivas.
A menudo, un ejecutivo necesita primero un panorama general de la situación de
un negocio, como la relación entre investigación y desarrollo y las ganancias
durante los últimos tres años, o relación de rotación de inventario.
Pero es posible que necesite información mas detallada (y menos resumida) para
señalar un problema, por ejemplo una rotación de inventario baja (cuando la
empresa no vende sus existencias con suficiente rapidez) pude originarse por un
solo archivo que se vende con demasiada lentitud. Mediante la búsqueda o
“excavación”.
c) La Hoja De Cálculo Electrónica.
Son herramientas de software comercial y barato que permiten a los usuarios con
poca experiencia diseñar sus propios “sistemas SATD”, las cuales proporcionan
dos medios útiles para construcción:
1. Funciones programadas, como totales, promedios, funciones financieras,
funciones estadísticas, etc.
2. La capacidad de usar instrucciones SI- ENTONCES. Al combinar las
instrucciones con funciones preprogramadas pueden crearse modelos de
toma de decisiones lo suficientemente complejos utilizando macros, que
también pueden utilizarse para desplegar información en forma de graficas.
d) Sistemas Expertos.
Esta solución se basa en la predicción de tendencias en los resultados de los
procesos de una empresa tales como ventas, embarque entre otros, basados en
métodos estadísticos para generar nuevo conocimiento. Esta solución se basa en
herramientas de Minería de Datos, por lo tanto es necesario personal y
125
herramientas especializados, razón por la cual los costos se incrementan haciendo
de la solución un privilegio para pocas organizaciones.
Teniendo en cuenta a que el tipo de información requerida para la toma de decisiones
estratégicas es diferente a la que podemos encontrar en los sistemas transaccionales. Es
necesario un nuevo tipo de entorno sistemático con el propósito de proveer información
estratégica para el análisis y monitorear el desempeño.
Este nuevo entorno sistemático debe tener como características lo siguiente:
• Base de datos diseñada para tareas analíticas.
• Datos desde muchas aplicaciones.
• Fácil de utilizar para los usuarios.
• Lectura intensa de datos.
• Interacción directa de los usuarios con el sistema sin la asistencia de los profesionales
de la información.
• Contenido actualizado periódicamente y estable.
• Debe contener datos actuales e históricos.
• Permitir a los usuarios ejecutar consultas y obtener resultados en línea.
• Permitir a los usuarios iniciar reportes.
Debido a lo anterior concluimos que un data warehouse es la única solución viable para
satisfacer necesidades de información para toma de decisiones estratégica en una empresa.
126
6.1.2 Descripción De La Solución
La demanda del proyecto obtuvo el aval del gerente general de la Ferretería Metrópolis 84
Ltda., quien identificó necesidades de información específica, concisa y consistente sobre el
proceso de ventas de su negocio con el fin de tomar mejores decisiones estratégicas para la
empresa y así mejorar su posicionamiento comercial y su competitividad en el mercado de la
comercialización de materiales y productos para la construcción.
Figura 6.1. Inteligencia de negocios en el DW23.
Esta necesidad se satisface al implantar la solución Datawarehouse, la cual se mantiene
separada de los sistemas para las operaciones diarias y esencialmente soporta la toma de
decisiones estratégicas para la inteligencia de negocios.
Específicamente, el proyecto se centra en un Datamart, encargado de transformar los
datos operativos de la empresa en información útil sobre sus ventas, utilizando análisis OLAP.
Actualmente, la empresa cuenta con la plataforma Microsoft SQL SERVER 2000, en la
cual tiene implementada su sistema transaccional. Con el objetivo de continuar bajo el mismo
proveedor de tecnología estándar de la empresa, ceñirse a los lineamientos tecnológicos 23 Data Warehousing Fundamentals A Comprehensive guide to IT Professionals[5]
127
establecidos por la misma y evitar incurrir en gastos adicionales innecesarios, toda la solución
desarrollada se encuentra bajo la plataforma Microsoft SQL SERVER 2005 Enterprise Edition
debido a que posee las herramientas adicionales para la normal culminación del proyecto. Esta
plataforma incluye el motor de base de datos y las herramientas para inteligencia de negocios
Integration Services a un costo menor respecto a otros productos para el mismo objetivo
existentes en el mercado.
6.2 Requerimientos Del Sistema
El proyecto contiene todos los componentes de una bodega de datos o datamart. Como fuente
de datos se tiene una base de datos transaccional unificada de la empresa, implementada en
Microsoft SQL SERVER 2000 de forma relacional y como fuentes de información: el manual
de procedimientos y funciones, el plan estratégico de la organización e información variada de
la empresa. La bodega de datos o datamart está construida en una base de datos bajo Microsoft
SQL SERVER 2005. Finalmente, el análisis OLAP y el proceso de extracción, transformación
y carga son realizados utilizando el paquete Analysis Services.
El datamart proporciona información estratégica sobre las ventas de la Ferretería
Metrópolis 84 Ltda. Como producto de la utilización de las fuentes de datos y otros
documentos anteriormente especificados. Se desarrollan e implementan los requerimientos de
ventas determinados luego del levantamiento y análisis de requerimientos que son acordados
con la empresa.
128
6.2.1 Definición De Requerimientos Requerimientos Funcionales
Para realizar el levantamiento de requerimientos se efectuaron entrevistas con los futuros
usuarios de la solución y encuestas con el personal operativo del área de ventas y tecnológico
de la empresa.
Los requerimientos del negocio se describen a continuación:
1. Mostrar ventas por cliente por tiempo.
2. Mostrar ventas por línea de producto por productos por tiempo.
3. Mostrar ventas por clientes por tipo de venta por segmento de cliente.
4. Mostrar ventas por productos por cliente por segmento de cliente.
5. Mostrar porcentaje de ventas por línea de producto por producto por tiempo.
6. Mostrar rentabilidad por vendedor por tipo de venta por tiempo.
7. Mostrar rentabilidad por venta por producto en promoción por tiempo.
8. Mostrar ventas por línea de producto por producto por segmento de cliente.
9. Mostrar Clientes por vendedor en el tiempo.
10. Mostrar ventas por vendedor en el tiempo.
11. Mostrar Porcentaje de ventas por tipo de venta por tiempo.
12. Mostrar los clientes por vendedor por volumen de compra por tiempo.
13. Mostrar los clientes por vendedor por rentabilidad de cliente por tiempo.
14. Mostrar ventas por línea de productos por vendedor por tiempo.
15. Mostrar el volumen de compras por línea de productos por producto por segmento de
cliente por tiempo.
16. Mostrar cantidad de clientes por segmento de clientes por vendedor por tiempo.
17. Visualizar y monitorear el cumplimiento los indicadores básicos de ventas en el tiempo.
129
Estos requerimientos fueron acordados con la empresa para su implementación, todos
ellos soportados con los datos almacenados en la base de datos transaccional. Los
requerimientos anteriormente mencionados pertenecen a la categoría de requerimientos
funcionales.
6.2.2 Requerimientos No Funcionales
Los procesos, la fuente de datos, los documentos revisados y la base de datos estratégica se
incluyen en la categoría de requerimientos no funcionales.
6.2.3 Especificación De Requerimientos
El intervalo de tiempo utilizado para el análisis temporal comparativo para la solución fue
establecido a conveniencia de la empresa en el lapso del año 2004 hasta el año 2007.
• Mostrar ventas por cliente por tiempo.
Descripción: Esta consulta permite visualizar el valor de las ventas de la Ferretería Metropolis
84 Ltda., discriminando estas ventas por sus segmentos de clientes por tiempo. Al hacer drill
down se exploran las ventas por clientes individuales por tiempo.
• Mostrar ventas por línea de producto por productos por tiempo.
Descripción: Esta consulta permite explorar el valor de las ventas de la Ferretería Metrópolis
84 Ltda., discriminando estas ventas por sus líneas de productos y por tiempo. Al hacer drill
down se exploran las ventas por productos individuales por tiempo.
130
• Mostrar ventas por tipo de venta por clientes por segmento de cliente.
Descripción: Esta consulta permite explorar el valor de las ventas según un cliente especifico
por tipo de venta en la ferretería Metropolis 84 Ltda., discriminándolas por segmento de
cliente.
• Mostrar ventas de productos por segmento de cliente por cliente.
Descripción: Esta consulta permite comprender el comportamiento de las ventas que se han
hecho a los clientes con sus respectivos productos, de esta manera podemos saber los
productos específicos que han sido vendidos a los segmentos de clientes.
• Mostrar porcentaje de ventas por producto por línea de producto por tiempo.
Descripción: Esta consulta permite analizar a que porcentaje corresponde, el valor de la venta
de un producto respecto a su línea, discriminando estas ventas por tiempo.
• Mostrar rentabilidad por vendedor por tipo de venta por tiempo.
Descripción: Esta consulta nos brinda la posibilidad de analizar la rentabilidad por cada
vendedor de la Ferretería Metropolis 84 LTDA, por tipo de venta efectuada en un tiempo
dado.
• Mostrar rentabilidad por venta por producto en promoción por tiempo.
Descripción: Esta consulta construye un reporte donde se visualiza la rentabilidad respecto a
las ventas por producto que se incluye en una promoción. Este requerimiento no es factible
por el momento, debido a la carencia de un mecanismo apropiado para almacenar la
información correspondiente a las promociones realizadas en la Ferretería Metrópolis 84
LTDA. Este requerimiento debe ser solucionado en primera instancia por la empresa en el
sistema transaccional, por último por el sistema estratégico.
131
• Mostrar ventas por producto por línea de producto por segmento de cliente.
Descripción: Esta consulta facilita el análisis de las ventas por línea de producto por segmento
de cliente en un tiempo determinado. A nivel de detalle podremos ver las ventas por
productos individuales para un determinado segmento de cliente.
• Mostrar ventas por vendedor en el tiempo.
Descripción: En este reporte veremos el total de las ventas por cada vendedor en un tiempo
determinado.
• Mostrar Ventas por Clientes por vendedor en el tiempo.
Descripción: En este reporte veremos el total de las ventas por cliente por cada vendedor en
un tiempo determinado.
• Mostrar Porcentaje de ventas por tipo de venta por tiempo.
Descripción: En este reporte veremos el porcentaje por cada tipo de ventas en un tiempo
determinado.
• Mostrar los clientes por vendedor por volumen de compra por tiempo.
Descripción: En este reporte veremos el volumen de compra por cliente en un tiempo
determinado, con la finalidad de analizar el mejor cliente por cada vendedor según la cantidad
adquirida.
• Mostrar los clientes por vendedor por rentabilidad de cliente por tiempo.
Descripción: En este reporte veremos la rentabilidad de un cliente atendido por un vendedor
específico.
132
• Mostrar ventas por línea de productos por vendedor por tiempo.
Descripción: En este reporte veremos las ventas por línea de productos vendidos por un
representante de ventas (vendedor) específico.
• Mostrar el volumen de compras por línea de productos por producto por
segmento de cliente por tiempo.
Descripción: En este reporte veremos la cantidad de productos perteneciente a una línea de
producto, comprados por un segmento de clientes específico en un lapso de tiempo
determinado.
• Mostrar cantidad de clientes por segmento de clientes por vendedor por tiempo.
Descripción: En este reporte veremos la cantidad de clientes perteneciente a segmento de
cliente específico, asociados a un vendedor en un lapso de tiempo determinado.
• Visualizar y monitorear el cumplimiento los indicadores básicos de ventas en el
tiempo.
Descripción: Los indicadores de éxito utilizados por el gerente comercial para la toma de
decisiones respecto a las ventas son la rentabilidad y el total de la venta. A través de este
reporte se podrá ver en un momento dado el estado actual del cumplimiento de la
rentabilidad meta y ventas. Ver tabla 6.1
Rango Tiempo
Parámetro Meta Actual Cumplimiento (%)Ventas $ 103000000 $ 67000000 65,04 Rentabilidad 20 % 4,5% 2,25
Tabla 6.1 Ejemplo ilustrativo del formato deseado para monitorear los indicadores.
133
6.2.4 Paquetes De Información
Los paquetes de información hacen parte la metodología para obtener requerimientos dentro
del proceso de diseño del sistema data warehouse basado en dimensiones del negocio. Esta
metodología incorpora las medidas básicas y las dimensiones a través de las cuales los usuarios
analizarán estas medidas.
Dimensiones Clientes Tiempo Tipo de
Venta Vendedor Segmento
de cliente Nombre completo cliente
Año Descripción del tipo de venta
Nombre completo Vendedor
Descripción segmento
Correo electrónico cliente
Semestre
Teléfono Trimestre Dirección Mes Día del mes Día de la
semana
Jera
rqu
ía/
Cat
egor
ía
Hechos: Total venta, Rentabilidad bruta Tabla 6.2 Paquete de información, área tema: VENTAS.
Dimensiones Clientes Tiempo Vendedor Producto Segmento
de cliente Nombre completo cliente
Año Nombre completo Vendedor
Descripción Descripción segmento
Correo electrónico cliente
Semestre Línea de producto
Teléfono Trimestre Dirección Mes Día del mes Día de la
semana
Jera
rqu
ía/
cate
gorí
a
Hechos: cantidad vendida de producto, subtotal venta Tabla 6.3 Paquete de Información, área tema: VENTAS_DETALLE.
134
6.2.5 Negociación De Requisitos
Los requerimientos tomados en esta fase del proyecto fueron negociados con la empresa y son
los que se van a implantar en la solución. Solo un requisito es técnicamente no factible, véase la
sección 6.2.1 la descripción de Mostrar rentabilidad por venta por producto en promoción por
tiempo.
6.2.6 Evolución del sistema
La solución propuesta cubre sólo los procesos de ventas; sin embargo, ésta puede extenderse
para abarcar los demás procesos llevados a cabo en las diferentes áreas restantes de la
Ferretería Metropolis 84 Ltda
6.3 Diseño y Modelización Del Sistema
6.3.1.1 Modelado dimensional
Para iniciar el modelamiento dimensional se debe tener en cuenta el principal objetivo de
cualquier bodega de datos o datamart: el análisis de la información. Este análisis es realizado
por medio de reportes, por lo tanto al modelar el datamart se debe tener como base la
información deseada en los reportes.
Dada la definición de los requerimientos se identifican reportes de ventas que
contengan información sobre: segmentos de clientes, clientes individuales, líneas de productos,
productos individuales y períodos del tiempo en que se realizaron las ventas.
Estas categorías son dimensiones en el modelo dimensional y la tabla en donde aparece
la medida, que es el valor de las ventas, es llamada tabla de hechos. La relación de la tabla de
135
hechos con las tablas de dimensiones es de uno a muchos. Esto se comprende lógicamente por
el modelo del negocio, a varios segmentos de clientes, de varias líneas de productos en
diferentes períodos del tiempo. En las siguientes secciones se detalla cada componente del
modelo dimensional.
136
DIM_CLIENTECLIENTE_SK
IDENTIFICACION
NOMBRE_CLIENTE
DIRECCION_CLIENTE
GENERO
CORREO_ELECTRONICO
TELEFONO
DIM_PRODUCTOPRODUCTO_SK
CODIGO_EMP
CODIGO_PRODUCTO
DESCRIPCION_PRODUCTO
LINEA
DIM_TIEMPOTime_Key
NUMERO_DIA_SEMANA
NOMBRE_DIA_SEMANA
NUMERO_DIA_MES
NUMERO_DIA_YEAR
SEMANA_NUMERO_YEAR
NOMBRE_MES
NUMERO_MES
TRIMESTRE
YEAR
SEMESTRE
TRIMESTRE_FISCAL
FISCAL_YEAR
SEMESTRE_FISCAL
FECHA_COMPLETA
DIM_TIPO_VENTACODIGO_TIPO_SK
CODIGO_TIPO_VENTA
DESCRIPCION
DIM_VENDEDORVENDEDOR_SK
CODIGO_EMP
CODIGO_VENDEDOR
IDENTIFICACION
NOMBRE_VENDEDOR
FACT_VENTACODIGO_INTERNO
CODIGO_CLIENTE
TIPO_VENTA
CODIGO_FACTURA
FECHA_VENTA
CODIGO_VENDEDOR
RENTA_BRUTA
VALOR_VENTA
FACT_VENTA_DETALLECODIGO_INTERNO
CODIGO_CLIENTE
CODIGO_PRODUCTO
FECHA_VENTA
CODIGO_VENDEDOR
CANTIDAD_VEND_PROD
SUBTOTAL_VENTA
DIM_SEGMENTO_CLIENTECODIGO_SEGMENTO
DESCRIPCION
S_CAMBIOS_SEGMENTOCODIGO_CLIENTE
FECHA_INICIO
FECHA_FINAL
CODIGO_SEGMENTO
Figura 6.2 Diseño de la base de datos multidimensional de Ventas.
137
6.3.1.2 Acerca Del Datamart
El modelo diseñado e implementado consiste en un datamart. Este concepto busca centrarse
en un objetivo único o en el análisis de un área específica de la empresa. Una bodega de datos
abarca todas las áreas de una empresa y está compuesta de varios datamarts. Para el caso de
nuestro proyecto, el objetivo único es analizar el área de ventas de la Ferretería Metropolis 84
Ltda.
El datamart implementado en este proyecto tiene una fuente de datos origen que pobla
el datamart, una base de datos transaccional unificada creada en Microsoft SQL SERVER
2000.
6.3.1.3 Nivel De Detalle Del Modelo
Se definió la granularidad de la tabla de hechos como la más baja o granular posible. Esta
granularidad corresponde a una venta de un producto a un cliente en una fecha determinada,
es decir una transacción individual. Se considera también el total de ventas de un cliente. De
ésta forma será posible llegar al grado de detalle de consultar una venta específica, aunque éste
no sea el objetivo de un datamart. La medida, es un campo de la tabla de hechos que
corresponde al valor de una venta con la granularidad establecida.
6.3.1.4 Dimensiones
Se definen a continuación las dimensiones que soportan los requerimientos definidos,
cumpliendo con la granularidad de la tabla de hechos. Las siguientes secciones relacionan las
tablas diseñadas para la base de datos estratégica con su dimensión correspondiente.
138
Dimensión Tiempo
Tabla: DIM_TIEMPO
Contiene información de las fechas en que se realizan las ventas. Esta tabla incluye
información sobre el año, semestre, cuarto, trimestre, bimestre, mes y día. Se tienen diferentes
campos para una misma fecha permitiendo al usuario navegar por la dimensión dependiendo
del grado de profundidad de fecha que prefiera.
CAMPOS TIPO DESCRIPCION Time_Key int Llave de día. NUMERO_DIA_SEMANA tinyint Número del día en la semana. NOMBRE_DIA_SEMANA nvarchar(10) Nombre del día en la semana. NUMERO_DIA_MES tinyint Número del día en el mes. NUMERO_DIA_YEAR smallint Número del día en el año. SEMANA_NUMERO_YEAR tinyint Número de la semana en el año.NOMBRE_MES nvarchar(10) Nombre del mes. NUMERO_MES tinyint Número del mes en el año. TRIMESTRE tinyint Trimestre del año. YEAR varchar(4) Dígitos que representan al año. SEMESTRE tinyint Semestre del año. TRIMESTRE_FISCAL tinyint Trimestre fiscal. FISCAL_YEAR varchar(4) Año Fiscal. SEMESTRE_FISCAL tinyint Semestre fiscal. FECHA_COMPLETA nvarchar(10) Fecha en formato completo. FECHA datetime Fecha en formato completo.
Tabla 6.4 Estructura de la dimensión de tiempo dim_tiempo.
139
Dimensión Clientes
Tabla: DIM_CLIENTE
Contiene la información de los clientes que maneja la empresa.
CAMPO TIPO DE DATO
DESCRIPCION
CLIENTE_SK int Llave artificial del cliente. IDENTIFICACION varchar(10) Llave de negocio. NOMBRE_CLIENTE varchar(125) Nombre completo del cliente. DIRECCION_CLIENTE varchar(100) Dirección del cliente. GENERO varchar(1) Genero del cliente. CORREO_ELECTRONICO
varchar(35) Correo electrónico del cliente.
TELEFONO varchar(12) Teléfono principal del cliente. Tabla 6.5 Estructura de la dimensión de clientes dim_clientes.
Dimensión Producto
Tabla: DIM_PRODUCTO
Contiene la información de los productos que ofrece la empresa.
CAMPO TIPO DE DATO
DESCRIPCION
PRODUCTO_SK int Llave artificial del producto. CODIGO_EMP varchar(3) Llave de negocio asociada al
código del producto. CODIGO_PRODUCTO varchar(8) Llave de negocio del producto. DESCRIPCION_PRODUCTO
varchar(100) Descripción del producto.
LINEA varchar(45) Línea de producto. Tabla 6.6 Estructura de la dimensión de productos dim_producto.
140
Dimensión Tipo De Venta
Tabla: DIM_TIPO_VENTA
Contiene la información sobre los tipos de ventas que se realizan en la empresa.
CAMPO TIPO DE DATO
DESCRIPCION
CODIGO_TIPO_SK int Llave artificial para el tipo de venta.
CODIGO_TIPO_VENTA varchar(10) Llave de negocio para el tipo de venta.
DESCRIPCION varchar(50) Descripción del tipo de venta.
Tabla 6.7 Estructura de la dimensión para la línea de productos.
Dimensión segmento de clientes
Tabla: DIM_SEGMENTO_CLIENTE
Contiene la información sobre los tipos de Clientes (segmento) que maneja la empresa.
CAMPOS TIPO DE DATO
DESCRIPCION
CODIGO_SEGMENTO int Llave para el segmento de cliente. DESCRIPCION varchar(80) Descripción para el segmento de
cliente. Tabla 6.8 Estructura de la dimensión para la línea de productos dim_segmento_cliente.
141
Dimensión Vendedor
Tabla: DIM_VENDEDOR
Contiene la información sobre los vendedores que laboran en la compañía.
CAMPOS TIPO DE DATO
DESCRIPCION
VENDEDOR_SK int Llave artificial para el vendedor. CODIGO_EMP varchar(3) Llave de negocio asociada al código del
vendedor. CODIGO_VENDEDOR varchar(10) Llave de negocio para el vendedor. IDENTIFICACION varchar(10) Identificación del vendedor. NOMBRE_VENDEDOR varchar(55) Nombre completo del vendedor.
Tabla 6.9 Estructura de la dimensión para la línea de productos dim_vendedor.
6.3.1.5 Tablas De Hechos
En este datamart hay un solo hecho: el hecho de la transacción de una venta. Este hecho es la
rentabilidad y el valor de una venta; también son llamadas medidas. Estas medidas cumplen
con la granularidad definida, es decir, los valores de una transacción individual y general de una
venta. Los demás campos son llaves foráneas, para relacionar esta tabla con sus dimensiones.
Tabla: FACT_VENTA
Registra la información de las ventas y rentabilidad globales por cliente, vendedor que hace la
empresa.
142
CAMPOS TIPO DE DATO
DESCRIPCION
CODIGO_INTERNO int Código interno del hecho. CODIGO_CLIENTE int Cliente asociado a la venta. FECHA_VENTA int Fecha de la venta. CODIGO_VENDEDOR int Llave para el vendedor. CODIGO_FACTURA varchar(10) Llave de negocio para la factura. TIPO_VENTA int Código asociado al tipo de venta. RENTA_BRUTA float Porcentaje de rentabilidad bruta de la
venta. VALOR_VENTA float Valor total de la venta.
Tabla 6.10 Estructura de la tabla de hechos fact_venta.
Tabla: FACT_VENTA_DETALLE
Registra la información de las ventas y rentabilidad en detalle por cliente, vendedor que hace la
empresa.
CAMPOS TIPO DE DATO
DESCRIPCION
CODIGO_INTERNO int Código interno del hecho. CODIGO_CLIENTE int Cliente asociado a la venta. CODIGO_PRODUCTO int Código asociado al producto. FECHA_VENTA int Fecha de la venta. CODIGO_LINEA_PRODUCTO int Código asociado a la línea de
producto. CODIGO_VENDEDOR int Llave para el vendedor CANTIDAD_VEND_PROD int Cantidad vendida de un producto.SUBTOTAL_VENTA float subtotal de una Venta
Tabla 6.11 Estructura de la tabla de hechos fact_ventas_detalle.
143
6.3.1.6 Diseño Técnico De La Arquitectura
Datos
Los datos constituyen la información del Datamart, se refieren al componente principal de los
procesos que llevan a la construcción de la aplicación.
Para el análisis de los datos, se comienza por revisar los datos fuente que maneja el
proceso de ventas de la empresa, la base de datos transaccional y la estructura de sus tablas. La
ferretería Metrópolis 84 Ltda tiene actualmente un modelo relacional en su sistema OLTP.
Esta base de datos se encuentra implementada en Microsoft SQL SERVER 2000 y es
denominada Metropolis.
Para construir el datamart, se requiere la información relacionada con las ventas. Para
este caso en especial, las tablas utilizadas de la base de datos Metropolis fueron:
• VTADFCT: Almacena la información referente al detalle de la factura. Contiene el valor
total de la venta, el detalle de producto por venta de un cliente en específico.
• VTACFCT: Almacena la información relacionada al encabezado de la factura.
• CLIENTE: Almacena la información relacionada con el cliente.
• INVARTICULO: Almacena la información correspondiente a los productos
comercializados por la empresa.
• CLTVEND: Almacena información sobre vendedores de la Ferretería Metrópolis 84
Ltda.
• INVSUBGRPART: Almacena información a cerca de las líneas de cada producto
comercializado por la empresa.
144
6.3.1.7 Mapeo De Los Datos En El Modelo Dimensional
El mapeo de los datos en el modelo dimensional tiene la finalidad de realizar el proceso de
cargar los datos a la base de datos multidimensional más ameno y reducir el porcentaje de
error, el cual que es muy alto cuando se gestionan datos entre fuentes de Información, hemos
apoyado este proceso mediante un formato de mapeo Fuente-Destino donde Relacionamos las
tablas y campos origen con las tablas y campos destino.
A continuación se muestran los formatos.
145
FUENTE DESTINO Base
de datos
Tabla Columna Tipo de
dato
Tamaño Tipo SCD
Base de
datos
Tabla Columna Tipo de
dato
Tamaño Transformación
NITCLT Varchar 10 IDENTIFICACION varchar 10 Selección la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
NMBCLT Varchar 100 NOMBRE_CLIENTE varchar 125 Selección la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
DIRCLT Varchar 100 DIRECCION_CLIENTE varchar 100 Conversión: todo valor NULL se convertirá a ANONIMO
SEXO Varchar 1 GENERO varchar 1 Completar: 1. Obtener los registros que tengan valores null y vacíos en el campo sexo. 2. Averiguar a través de un patrón a que género pertenece el cliente.
EMAILCLT Varchar 35 CORREO varchar 35 Conversión: 1. Obtener los registros que tengan valores null y vacíos en e campo emailctl. 2. Colocar a todo valor NULL y vacío como ANONIMO. 3.Filtrar los registros por el contenido de un arroba en el patrón caracteres 4.cambiar por anonimo los que no cumplen con el patron anterior.
Met
rop
olis
CLIE
NTE
S
TEL1CLT Varchar 12
Tipo I Conservación de la historia del cliente.
Dw
met
rop
olis
DIM
_CLI
EN
TE
TELEFONO varchar 12 Conversión: todo valor NULL se convertirá a ANONIMO
Tabla 6.12 Formato de mapeo fuente-destino para la dimensión de clientes.
146
FUENTE DESTINO
Base de
datos
Tabla Columna Tipo de
dato
Tamaño Tipo SCD
Base de
datos
Tabla Columna Tipo de
dato
Tamaño Transformación
CDGART varchar 8 CODIGO_PRODUCTO varchar 8 Selección la información de estecampo se obtendrá en su estadooriginal, no es necesaria ningunatransformación.
EMPCDG varchar 3 CODIGO_EMP varchar 3 Selección la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
INV
ART
ICU
LO
DSCART varchar 100
Tipo I Conservación de la historia del artículo-.
DESCRIPCION_PRODUCTO varchar 100 Selección la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
Met
rop
olis
INV
SUBG
RPA
RT
DSCSUBGRP varchar 45
Dw
met
rop
olis
DIM
_PRO
DU
CTO
LINEA varchar 45 Selección la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
Tabla 6.13 Formato fuente-destino para la dimensión de productos.
147
FUENTE DESTINO
Base de datos
Tabla Columna Tipo de dato
Tamaño Tipo SCD
Base de datos
Tabla Columna Tipo de dato
Tamaño Transformación
EMPCDG varchar 3 CODIGO_EMP Varchar 3 Selección la información de este campo no es necesita ninguna transformación.
CDGVND varchar 10 CODIGO_VENDEDOR Varchar 10 Selección la información de este campo no es necesita ninguna transformación.
NMBVND varchar 50 NOMBRE_VENDEDOR varchar 50 Completar y estandarizar el formato de los nombres de vendedor.
CLTV
EN
D
CEDVND Varchar 10 IDENTIFICACION Varchar 10 Selección la información de este campo no es necesita ninguna transformación.
NMBCMPEMP varchar 55 NOMBRE_VENDEDOR Varchar 55 Selección la información de este campo no es necesita ninguna transformación.
Met
rop
olis
NM
EM
PLE
AD
O
CEDULA varchar 10
Tipo I Conservación de la historia de vendedores
Dw
met
rop
olis
DIM
_VE
ND
ED
OR
IDENTIFICACION varchar 10 Selección la información de este campo no es necesita ninguna transformación.
Tabla 6.14 Formato fuente-destino para la dimensión vendedor.
148
FUENTE DESTINO
Base de datos
Tabla Columna Tipo de
dato
Tamaño Tipo SCD
Base de
datos
Tabla Columna Tipo de
dato
Tamaño Transformación
Met
rop
olis
VTA
CFCT
TPOFCT varchar 1
Dw
met
rop
olis
DIM
_TIP
O_V
EN
TA
CODIGO_TPO_VENTA varchar 1
Selección: la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
Tabla 6.15 Formato fuente-destino para la dimensión tipo de ventas.
149
FUENTE DESTINO Base de
datos Tabla Columna Tipo
de dato
Tamaño Tipo SCD
Base de
datos
Tabla Columna Tipo de
dato
Tamaño Transformación
NMRRMS varchar 10 CODIGO_FACTURA varchar 10
Selección: la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
RENTA float 8 RENTA_BRUTA float 8
Selección: la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
Met
rop
olis
VTA
CFCT
TOTAL float 8
No aplica para la Fact. table
Dw
met
rop
olis
FACT
_VE
NTA
VALOR_VENTA float 8
Selección: la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
Tabla 6.16 Formato fuente-destino para la Fact_venta.
150
FUENTE DESTINO
Base de datos
Tabla Columna Tipo de
dato
Tamaño Tipo SCD
Base de
datos
Tabla Columna Tipo de
dato
Tamaño Transformación
CNTART float 8 CANTIDAD_VEND_PROD float 8
Selección: la información de este campo se obtendrá en su estado original, no es necesaria ninguna transformación.
Met
rop
olis
VTA
CFCT
SUBTOTAL float 8
No aplica para la Fact. table
Dw
met
rop
olis
FACT
_VE
NTA
SUBTOTAL_VENTA float 8
Completar: Si el campo SUBTOTAL es null entoces se calcula el subtotal para los registros utilizando los campos CNTART, PRECIO, ARTDSCT de la misma tabla.
Tabla 6.17 Formato fuente-destino para la Fact_venta_detalle.
6.4 Implementación
6.4.1 Back Room
El Back Room corresponde al área del Data warehouse responsable de extraer y preparar los
datos. A continuación se explicará como se realizó el proceso ETL en la bodega. Iniciamos con
los datos fuentes almacenados en el sistema transaccional de la Ferretería Metrópolis 84 Ltda.
Una de las políticas principales del datawarehousing es no modificar los sistemas de la
empresa pues se estarían alterando sus procesos de negocios y de esta forma los procesos
OLTP.
6.4.2 Extracción
En esta tarea, se hizo una extracción de los valores de los campos de las tablas involucradas
para el desarrollo del modelo en estrella.
La herramienta de ETL utilizada es SQL Server Business Intelligence Development
Studio con la cual se creó un proyecto de Integration Services para apoyar la tarea de
extracción de datos.
6.4.3 Transformación
En esta tarea, se construyeron los formatos fuente-destino para facilitar el proceso de mapeo
de los datos. Véase Mapeo de los datos en el modelo multidimensional. Esta tarea es guiada
por los requerimientos respecto a los datos, por lo tanto estos determinan las operaciones
efectuadas sobre ellos. Los datos transformados durante esta tarea, son almacenados en un
área de Stage.
152
6.4.4 Carga
Esta tarea se inicia, luego de tener los datos transformados en el área de Stage. El proceso
consiste en tomar dichos datos y almacenarlos en el modelo multidimensional de tal forma que
queden listos para ser accedidos a través de herramientas OLAP. o de Análisis
Multidimensional.
Finalmente, los datos extraídos y transformados son almacenados (LOAD) en la base
de datos multidimensional de la Figura 6-2.
6.4.5 Front Room
El Front Room del datamart de ventas de la Ferretería Metrópolis 84 LTDA corresponde a la
estructura que permite ver la información multidimensional de las ventas con respecto a los
clientes, segmentos de clientes, productos, líneas de producto y en medidas de tiempo (por día,
mes, trimestre, semestre y año).
La actualización de la información que sirve como base para la generación de reportes es diaria.
153
6.4.6 Infraestructura Del Data warehouse
Las bases de datos y los servidores OLAP funcionan sobre configuraciones muy similares, por
tal motivo la configuración es la siguiente:
Sistema Operativo: Windows Server 2003.
Memoria RAM: 1 Gb
Disco Duro: 120 Gb.
Procesador: Pentium 4 de 3.4Ghz.
Esta es una buena configuración que permitirá soportar el SQL Server 2005 con sus
herramientas integradas.
6.4.7 Proceso de Extracción, Transformación y Carga
En esta sección, se utiliza la documentación obtenida en el plan de mapeo de los datos para
realizar el proceso ETL (Extraction, Transformation and Load), véase la sección 6.2.7.7. En
este proceso se extraen los datos fuente que se encuentran en la base de datos Metropolis.
El primer paso del proceso en general, consiste en extraer los datos de las tablas
fuentes implicadas véase la sección 6.2.7.1. Se utilizará la palabra ANONIMO para los campos
cuyos valores sean igual a Null o vacío.
154
Figura 6.3 Pasos generales de los procesos de extracción, transformación y carga de los datos.
6.4.8 Herramienta Para El Proceso ETL
Para apoyar al proceso ETL, se utilizó la herramienta SQL Server Integration Services véase la
sección 2.2.10
6.4.9 Proceso ETL Para La Dimensión Clientes
Determinación De Registros Candidatos
Objetivo: Determinar el origen del conjunto de registros de la tabla clientes del sistema
transaccional, que son candidatos adecuados para poblar la dimensión cliente del sistema
estratégico (DIM_CLIENTE), ejerciendo un control adecuado de manipulación de los datos
para satisfacer los requerimientos sobre la información de clientes.
Rango de tiempo requerido: Enero 1 del 2004 a Marzo 6 del 2007.
Total registros de la base de datos:
select count(*) Total_Clientes_Todos_los_años
from dbo.CLIENTES
155
Clasificacion registros de la base de datos según campo fecha (AUDFEC):
Total de clientes en el 2003
select count(AUDFEC) Total_clientes_2003
from dbo.CLIENTES
where AUDFEC>=20030101 and AUDFEC<=20031231
Total de clientes en el 2004
select count(AUDFEC) Total_clientes_2004
from dbo.CLIENTES
where AUDFEC>=20040101 and AUDFEC<=20041231
Total de clientes en el 2005
select count(AUDFEC) Total_clientes_2005
from dbo.CLIENTES
where AUDFEC>=20050101 and AUDFEC<=20051231
Total de clientes en el 2006
select count(AUDFEC) Total_clientes_2006
from dbo.CLIENTES
where AUDFEC>=20060101 and AUDFEC<=20061231
Total de clientes en el 2007
select count(AUDFEC) Total_clientes_2007
from dbo.CLIENTES
156
where AUDFEC>=20070101 and AUDFEC<=20071231
Total de clientes en el lapso de Enero 2004 a Marzo de 2007
select count(AUDFEC) Total_2004_2007
from dbo.CLIENTES
WHERE AUDFEC BETWEEN 20040101 and 20041231 or
AUDFEC BETWEEN 20050101 and 20051231 or
AUDFEC BETWEEN 20060101 and 20061231 or
AUDFEC BETWEEN 20070301 and 20070331
Porcentajes:
Total Clientes 2004 - 2007 = 99,404%
Total Clientes 2003 = 0,594%
Figura 6.4.a Porcentajes de Distribución de Registros de Clientes.
157
Figura 6.4.b Porcentajes de Distribución de Registros de Clientes del 2004 al 2007.
0
10000
20000
30000
40000
50000
60000
Registros
Total clientes 2004 – 2007
Total Clientes 2003
Total nulos
Figura 6.5 Distribución de registros de clientes. Conclusión
El porcentaje total de registros hallados en la base de datos transaccional que cumplen con el
requerimiento de tiempo anteriormente especificado es del 99,404%, éstos corresponden al
158
conjunto de registros de la tabla clientes que son candidatos para poblar el diseño
multidimensional.
Selección De Los Registros De Clientes A Cargar
Teniendo en cuenta que no se pueden cargar valores vacíos o nulos en las tablas que
componen un modelo multidimensional, se procedió a verificar el estado de completitud de los
registros candidatos. A continuación, se expondrán las opciones existentes.
Opción 1:
Estado ideal de completitud de los campos requeridos para el modelo multidimensional.
select COUNT(*)
from dbo.CLIENTES
WHERE AUDFEC BETWEEN 20040101 and 20070331
AND (NMBCLT IS NOT NULL AND NMBCLT NOT LIKE '') AND
(NITCLT IS NOT NULL AND NITCLT NOT LIKE '') AND
(DIRCLT IS NOT NULL AND DIRCLT NOT LIKE '') AND
(SEXO IS NOT NULL AND SEXO NOT LIKE '') AND
(TEL1CLT IS NOT NULL AND TEL1CLT NOT LIKE '')AND
(EMAILCLT IS NOT NULL AND EMAILCLT NOT LIKE '' AND EMAILCLT LIKE
'%@%')
Porcentaje: 0,246%
159
Opción 2:
Datos completos solo en los campos NMBCLT (nombre), NITCLT (NIt del cliente)
TEL1CLT (teléfono principal) y EMAILCLT (correo electrònico).
select COUNT(*)
from dbo.CLIENTES
WHERE AUDFEC BETWEEN 20040101 and 20070331
AND (NMBCLT IS NOT NULL AND NMBCLT NOT LIKE '') AND
(NITCLT IS NOT NULL AND NITCLT NOT LIKE '') AND
(TEL1CLT IS NOT NULL AND TEL1CLT NOT LIKE '') AND
(EMAILCLT IS NOT NULL AND EMAILCLT NOT LIKE '' AND EMAILCLT LIKE
'%@%')
Porcentaje: 0,428%
Opción 3:
Datos completos solo en los campos NMBCLT (nombre), NITCLT (NIt del cliente)
TEL1CLT (teléfono principal).
select COUNT(*)
from dbo.CLIENTES
WHERE AUDFEC BETWEEN 20040101 and 20070331
AND (NMBCLT IS NOT NULL AND NMBCLT NOT LIKE '') AND
(NITCLT IS NOT NULL AND NITCLT NOT LIKE '') AND
(TEL1CLT IS NOT NULL AND TEL1CLT NOT LIKE '')
160
Porcentaje: 75,961 %
Opción 4:
Datos completos solo en los campos NMBCLT (nombre) y NITCLT (NIt del cliente).
select COUNT(*)
from dbo.CLIENTES
WHERE AUDFEC BETWEEN 20040101 and 20070331 AND
NMBCLT IS NOT NULL AND NMBCLT NOT LIKE '' AND
NITCLT IS NOT NULL AND NITCLT NOT LIKE ''
Porcentaje: 100 %
La Opción 1 corresponde al estado ideal de completitud de los datos del sistema
transaccional actual de la Ferretería Metrópolis 84 LTDA; sin embargo, la cantidad de registros
del lapso de tiempo de Enero del 2004 a Marzo del 2007 que se hallan en buenas condiciones
de completitud para ser cargados en el modelo multidimensional, no son lo suficientemente
representativos dentro del total de registros de la base de datos por lo anterior, la consulta de la
Opción 4 se utilizará en el proceso de extracción de datos de los clientes teniendo en cuenta
que es la opcion mas viable debido a que los unicos campos del sistema actual completos a
cabalidad al mismo tiempo son el nombre del cliente y su correspondiente numero de Nit. Los
campos cuyo valor sea igual a vacio o nulo seran completados con la palabra representativa
ANONIMO.
161
Habiendo hecho el análisis descrito anteriormente, procedemos a ejecutar el proceso
ETL para la dimensión Cliente.
La Figura 6.6 muestra el paquete responsable del proceso ETL para la dimensión
cliente, para conocer más detalles a cerca del proceso de mapeo, véase la tabla 6.12.
Figura 6.6 Flujo de control que representa la extracción, transformación y población de la dimensión cliente.
En la Figura 6.6.a observamos el conjunto de procesos de transformación aplicados a
los registros de clientes provenientes de su fuente en la base de datos origen. El flujo de datos
contiene una conexión OLEDB y dos columnas derivadas que corrigen los valores nulos y el
formato del correo electrónico.
162
Figura 6.6.a Flujo de control “Poblar la dimensión clientes” en detalle.
6.4.10 Proceso ETL Para La Dimensión Vendedores
La Figura 6.7 muestra el paquete responsable del proceso ETL para la dimensión vendedor,
para conocer más detalles a cerca del proceso de mapeo, véase la tabla 6.14.
Figura 6.7 Flujo de control que representan la extracción, transformación y población de la dimensión vendedor.
En la Figura 6.7.a observamos el conjunto de procesos de transformación aplicados
a los registros de clientes provenientes de su fuente en la base de datos origen. El flujo de
datos contiene 3 conexiones OLEDB, una columna derivada que corrige los valores nulos de
la cédula.
163
La conexión OLEDB “Vendedores_ced_nula” contiene la siguiente consulta:
select EMPCDG,CDGVND,CEDVND,NMBVND
from dbo.CLTVEND
WHERE CEDVND IS NULL
La conexión OLEDB “Vendedores_Ok” contiene la siguiente consulta:
select emp.CEDULA,vend.EMPCDG,vend.CDGVND,emp.NMBCMPEMP
from dbo.CLTVEND as vend,dbo.NMEMPLEADO as emp
where emp.CEDULA=vend.CEDVND
La conexión OLEDB “Otros vendedores” contiene la siguiente consulta:
select CDGVND,case when (CEDVND is null)or(CEDVND like '') then CDGVND
else CEDVND end as CEDULA,NMBVND
from dbo.CLTVEND
where CEDVND not in (select CEDULA from dbo.NMEMPLEADO)
164
Figura 6.7.a Flujo de control “Poblar la dimensión vendedores” en detalle.
6.4.11 Proceso ETL Para La Dimensión Producto
La Figura 6.8 muestra el paquete responsable del proceso ETL para la dimensión producto,
para conocer más detalles a cerca del proceso de mapeo, véase la tabla 6.13.
Figura 6.8. Flujo de control “Poblar la dimensión producto”.
165
Figura 6.8.a Flujo de control “Poblar la dimensión producto” en detalle.
6.4.12 Proceso ETL Para La Dimensión Tiempo
La Figura 6.9 muestra el paquete responsable del proceso ETL para la dimensión vendedor. El
proceso de mapeo se muestra en la figura 6.9.b.
Figura 6.9 Flujo de control “Poblar la dimensión tiempo”.
La figura 6.9.a Muestra un origen para archivo sin procesar del tiempo, un condicional
para cargar los años correspondientes del 2003 hasta 2020.
166
Figura 6.9.a Flujo de control “Poblar la dimensión tiempo” en detalle.
Figura 6.9.b Mapeo fuente-destino para la dimensión tiempo.
167
6.4.13 Proceso ETL para las tablas de hechos
La Figura 6.8 muestra el paquete responsable del proceso ETL para la dimensión producto,
para conocer más detalles a cerca del proceso de mapeo, véase la tablas 6.16 y 6.17.
Figura 6.10 Flujo de control “Poblar las tablas de hechos”.
La Figura 6.11.a muestra en detalle el flujo de control “Poblar la tabla de hechos
venta”. El flujo de datos consta de una conexión OLEDB a la base de datos fuente, una
conversión de tipo de dato de la fecha de venta, una columna derivada que representa el
formato correcto de la fecha de venta, una búsqueda en las dimensiones cliente, tiempo,
vendedor y tipo de venta para obtener las llaves artificiales de cada una. .
La conexión OLEDB contiene la siguiente consulta que representa los datos de entrada para el
proceso ETL:
select
VC.NMRRMS,VC.CDGCLT,VC.FCHFCT,VC.CDGVEND,VC.TPOFCT,VC.RENTA,
CASE WHEN VC.VENTANG=0 THEN VC.VENTAG ELSE VC.VENTANG END AS
TOTAL
from VTADFCT VD,VTACFCT VC
168
WHERE VC.NMRRMS=VD.NMRRMS
AND VC.EMPCDG=VD.EMPCDG
Figura 6.10.a Flujo de control “Poblar las tablas de hechos venta” en detalle.
El resultado del proceso deja por fuera 18.558 registros de ventas que no poseen
cliente ni vendedor válido en los registros actuales, por tal razón éstos son llamados ventas sin
registro histórico.
La Figura 6.11.b muestra en detalle el flujo de control “Poblar la tabla de hechos venta
detalle” El flujo de datos consta de una conexión OLEDB a la base de datos fuente, una
conversión de tipo de dato de la fecha de venta, una columna derivada que representa el
formato correcto de la fecha de venta, una búsqueda en las dimensiones cliente, tiempo,
producto y vendedor para obtener las llaves artificiales de cada una.
169
La conexión OLEDB contiene la siguiente consulta que representa los datos de entrada
para el proceso ETL:
select
VC.NMRRMS,VD.CNTART,VC.CDGCLT,VD.CDGART,VD.AUDFEC,VC.CDGVEND,
CASE WHEN VD.SUBTOTAL IS NULL THEN
ROUND((VD.CNTART*VD.PRECIO)*(1-VD.ARTDSCT/100),1) ELSE VD.SUBTOTAL
END AS ST
from VTADFCT VD,VTACFCT VC
WHERE VC.NMRRMS=VD.NMRRMS
AND VC.EMPCDG=VD.EMPCDG
AND VD.AUDFEC IS NOT NULL
Figura 6.10.b Flujo de control “Poblar las tablas de hechos venta detalle” en detalle.
170
6.4.14 Construcción De Los Cubos
Estructura Del Cubo Ventas
El cubo se basa en la tabla de hechos FACT_VENTA.. En este cubo se almacena información
relacionada con la venta total, relacionándola con el cliente, vendedor, tipo de venta y tiempo
en el cual ocurre esta venta. Véase la figura 6.11. En esta estructura se crea un campo
calculado en la tabla de hechos, el cual carga el segmento de clientes en forma automática
desde la tabla temporal S_CAMBIO_CLIENTE.
La estrategia para poblar este cubo consiste en extraer los datos necesarios de
diferentes fuentes y cargarlos a cada dimensión como se describe en la sección 6.4.6.
Figura 6.11 Estructura del cubo Ventas.
171
La Figura 6.12 muestra la estructura de todo el cubo Ventas. La dimensión cliente es
utilizada para determinar los clientes de la Ferretería Metrópolis 84 Ltda.; en esta dimensión se
manejan seis niveles: Cliente, Correo electrónico, Dirección Cliente, Género, Identificación y
teléfono. La dimensión Tipo de Ventas es usada para analizar las ventas según su tipo; en esta
dimensión se manejan tres niveles: código, tipo de venta y descripción. La dimensión
Segmento de Cliente es utilizada el análisis por segmento de cliente, esta dimensión posee dos
niveles que representan valores de los dos ejes de un plano y un concepto que representa la
naturaleza de la segmentación de clientes. La dimensión vendedor y la dimensión tiempo son
utilizadas para análisis por vendedor y por tiempo.
Figura 6.12 Estructura general implementada del cubo Ventas.
172
Estructura Del Cubo Detalle Ventas
El cubo se basa en la tabla de hechos FACT_VENTA_DETALLE. En este cubo se almacena
información sobre una venta, relacionándola con el producto, cliente y tiempo en el cual
ocurre esta venta. Además existen las dimensiones DIM_VENDEDOR y DIM_TIEMPO que
permite conocer quienes son los vendedores y en que tiempo se ha realizado una venta.
Este cubo está diseñado para suplir una necesidad de un reporte Diario. Tiene una
granuralidad baja debido a que el registro con menor granuralidad es una sola venta a un
cliente de un solo producto.
La estrategia para poblar este cubo consiste en extraer los datos necesarios de diferentes
fuentes y cargarlos a cada dimensión como se describe en la sección 6.4.6.
Figura 6.13 Estructura del cubo Detalle Ventas.
173
A diferencia del cubo anterior, la Figura 6.14 muestra la dimensión producto la cual
permite saber cual fue el producto involucrado en la venta, además se puede conocer la línea
de productos a la cual pertenece. Las demás dimensiones cumplen la misma función descrita
en la sección 6.4.6.2.2
Figura 6.14 Estructura general implementada del cubo Detalle Ventas.
174
6.4.15 Visualización De La Información
Para la implementación de los reportes se utilizó la plataforma de Microsoft Reporting
Services. En primera instancia, fue necesario instalar y configurar el servicio Internet
Information Services (IIS), de igual forma para el servicio ASP:NET.
El proceso va guiado por un ciclo de vida de los reportes24 que consiste en tres actividades:
Autorización: Los reportes son autorizados utilizando el diseñador de reportes incluido
en Visual studio .NET.
Administración. La administración de reportes se encuentra a cargo del Admi nistrador
de informes, aplicación web utilizada para administrar e implementar los archivos de
definición de reportes (.rdl), orígenes de datos compartidos, configuración, y es
utilizado para ver y exportar datos de los reportes.
Presentación. Los reportes son presentados al usuario a través de administrador de
reportes o de una aplicación personalizada.
El administrador de reportes funciona como un repositorio de los reportes
implementados. La aplicación despliega los reportes mediante accesos directos a éstos. Para
acceder a la aplicación, primero ejecutar una ventana del navegador de su preferencia (se
recomienda el uso de Internet Explorer) y colocar la dirección con el siguiente formato,
http://<servidor>/<Instancia administrador de reportes>. La Figura 6.15 muestra una
ventana de diálogo para ingresar a la aplicación. El usuario y contraseña deben ser válidos
para el dominio en el sistema operativo, es decir, deben ser los mismos con los cuáles se
ingresa al sistema operativo.
24 Professional SQL Server™ 2005 Reporting Services pág 64 [18]
175
Figura 6.15 Diálogo para el inicio de sesión al administrador de reportes
En la Figura 6.16 se muestra la interfaz de inicio del administrador de reportes, la carpeta
FM_reportes contiene los reportes que dan solución a los requerimientos de información para
la empresa. La carpeta orígenes de datos contiene una conexión al cubo de ventas, la cual se
utiliza para incluir los datos en los reportes.
176
Figura 6.16 Interfaz de inicio del administrador de reportes
Los reportes tienen en común dos parámetros de fecha que permite establecer y analizar la
información en un rango de tiempo. Los requerimientos del sistema (véase la sección 6.2.1) se
agruparon por afinidad y complemento como sigue:
NOTA: Por razones de confidencialidad los datos en las imágenes han sido modificados.
177
• Los requerimientos dos y ocho son incluidos en el reporte linea_ventas
Figura 6.17 Navegación establecida para el reporte linea_ventas
• Los requerimientos uno, nueve y diez son incluidos en el reporte Clientes por vendedores.
Figura 6.18 Camino de navegación para el reporte Clientes por vendedores.
178
• El requerimiento tres es incluido en el reporte tipo_de_ventas_ventas.
Figura 6.19 Camino de navegación para el tipo de tipo_de_ventas_ventas.
• El requerimiento cuatro es incluido en el reportes segmento_clientes_venta.
Figura 6.20 Camino de navegación para el tipo de segmento_clientes_venta.
179
• El requerimiento seis es incluido en el reporte vendedor_renta.
Figura 6.21 Camino de navegación para el tipo de vendedor_renta.
• El requerimiento once es incluido en el reporte tipoV_porcentaje.
Figura 6.22 Camino de navegación para el tipo de tipoV_porcentaje.
180
• El requerimiento doce es incluido en el reportes vendedor_volumen.
Figura 6.23 Camino de navegación para el tipo de vendedor_volumen.
• El requerimiento trece es incluido en el reportes vendedor_rentabilidad.
Figura 6.24 Camino de navegación para el tipo de vendedor_rentabilidad.
181
• El requerimiento quince es incluido en el reportes segmento_volumen.
Figura 6.25 Camino de navegación para el tipo de segmento_volumen.
6.5 Pruebas
De acuerdo al compromiso adquirido entre los desarrolladores del proyecto y la empresa, las
pruebas del sistema se constituyen en responsabilidad de la misma por motivos de la naturaleza
de confidencialidad de los datos involucrados en dicho sistema y por políticas instauradas en la
empresa respecto a la protección de los datos. Por lo anterior, no es posible en este apartado
mostrar ningún tipo de información.
182
C a p ì t u l o 7
CONCLUSIONES Y RECOMENDACIONES
183
Una vez caracterizado el problema, desarrollado los planteamientos teóricos, revisadas las
argumentaciones conceptuales vinculadas a éste, efectuadas las actividades relativas al desarrollo
del proyecto y una vez analizados los resultados obtenidos, es apropiado establecer algunas
consideraciones finales, que a manera de conclusiones, se presentan a continuación:
En primera instancia, cabe resaltar que el desarrollo óptimo del proceso de
implementación de un Data warehouse se encuentra estrechamente relacionado con la
presencia de líderes patrocinadores del proyecto dentro de la empresa, que estén sólidamente
interesados en secundar la materialización de la idea a cabalidad. De lo contrario, todo esfuerzo
será en vano y seria preferible abandonar el proyecto.
El éxito de un proyecto de ésta naturaleza radica en el nivel de completitud que maneje el
sistema transaccional de la empresa, pues éste detalle es el que le permite a la solución entregar la
información adecuada a los tomadores de decisiones. Por esta razón, sugerimos a la empresa
fomentar la cultura y concientización de éste hecho, en todas sus áreas operativas encargadas del
almacenamiento diario de los datos
En el desarrollo del proyecto en la Ferretería Metrópolis 84 Ltda. el equipo encontró
datos de muy baja calidad de clientes; llámese datos con muy baja calidad como el nivel de
completitud y el nivel de credibilidad de éstos. Esta situación no es muy deseable sobre todo si
se trata de información de clientes, sabiendo que su filosofía de trabajo es orientada al cliente.
La Ferretería Metrópolis 84 Ltda. debe implementar un método que corrija esta grave
falencia que hemos descubierto de los datos que son capturados por su sistema transaccional.
184
De igual manera es necesario que la empresa refleje el manejo en el sistema
transaccional de las promociones efectuadas en la empresa.
Es necesario diseñar una estructura de cursos de formación a medida, que tendrán como
objetivo el proporcionar la formación necesaria para el mejor aprovechamiento de la
funcionalidad incluida en el sistema entregado a la empresa a través de prácticas sobre el
desarrollo realizado, las cuales permitirán fijar los conceptos adquiridos y servirán como
capacitación a los usuarios.
Finalmente, podemos concluir del presente proyecto que es de carácter innovador y con
proyección a nivel internacional. En Colombia, este tipo de sistemas se constituyen en un área
poco explotada en la costa, destacándose un liderazgo en el interior.
185
APENDICES
186
APÉNDICE A
Formatos Fuente-Destino
En el presente apartado, se pretende hacer la aclaración pertinente respecto a los formatos
Fuente-Destino que fueron usados para el adecuado desarrollo del proyecto.
El objeto principal, de un formato Fuente-Destino consiste en relacionar las tablas y
campos origen de la base de datos o sistema transaccional, con las tablas y campos destino de
la base de datos multidimensional con la finalidad de servir como apoyo en el proceso de carga
(LOAD) de datos al sistema multidimensional. La importancia de dichos formatos reside en la
facilidad que proveen, al relacionar la información que se requiere con la información existente,
de tal modo que la cantidad de errores al efectuar dicha correspondencia sea igual a cero.
Los campos o columnas que componen el formato se detallan a continuación:
Base de datos : Este campo corresponde al repositorio de datos que será utilizado en
el proceso, independientemente de su naturaleza (fuente o destino).
Tabla: Este campo del formato indica la estructura en la cual se almacenan los datos
187
Columna: Indica la unidad con valor informativo de una tabla y base de datos
especifica, en la cual se extrae o se almacena información.
Tipo de dato: Indica la naturaleza de la información tomada o almacenada en una
tabla específica, independiente del tipo de base de datos: fuente o destino.
Tamaño: Concierne a la cantidad de caracteres que son asignados a un campo
determinado.
Tipo SCD (Slowly Changing Dimension): Ésta columna, almacena tres posibles
valores: No aplica para el campo, reemplazar valor y almacena historia.
Transformación: Hace referencia a los procesos que se lleván a cabo para adecuar los
datos para el destino. Los procesos básicos son: selección, combinación, completar,
conversión.
188
FUENTE DESTINO Base de
datos Tabla Columna Tipo de
dato Tamaño Tipo
SCD Base de
datos Tabla Columna Tipo de
dato Tamaño Transformación
TABLA A-1. Formato de Mapeo Fuente-destino.
APÉNDICE B
Puntos A Considerar En La Captura De Requerimientos
B.1 Consideraciones Básicas
Conclusiones: la compilación de todos los requerimientos de las entrevistas deberían
organizarse por temas. Cada conclusión debe estar asociada con los entrevistados y las
fechas de la entrevista.
Asuntos: una lista por separado debería resaltar los asuntos críticos del negocio. No
todos los asuntos del negocio necesitan soluciones de BI.
Oportunidades: las oportunidades de negocios deberían extraerse y resaltarse de las
conclusiones.
B.2 Requerimientos Funcionales
¿Qué tipo de información se necesita en la organización? ¿Qué tipo de preguntas no se
han podido responder y por qué?
¿Qué reportes son los que quieren?
190
¿Cuáles son los reportes más importantes? ¿Cuáles son menos importantes?
¿Qué reportes pueden ser reemplazados por consultas normales?
¿Qué tipo de consultas utilizarán los analistas del negocio?
B.3 Requerimientos De Datos
¿Cuáles son los datos que las personas de la organización necesitan? ¿De dónde se
pueden obtener los datos en la actualidad?
¿Qué tan limpios están los datos en la actualidad? ¿Qué tan limpios deberían ser?
¿Qué información es considerada como la más critica para el negocio?
¿Pueden los datos ser resumidos? En caso afirmativo, ¿Por cuántas dimensiones?
¿Podrán los analistas querer la capacidad de investigar en detalle? ¿Qué grado de detalle
debe tener?
¿Otras personas de la organización necesitan los mismos datos? ¿Sabemos quienes son?
¿Estarán disponibles para validar los metadatos?
¿Cuáles son las expectativas para el tiempo de vida y la disponibilidad de los datos?
¿Cuáles son las expectativas para el tiempo de vida y la disponibilidad de los datos?
B.4 Requerimientos Históricos
¿Cuántos años de historial debemos considerar?
¿Podemos iniciar la colección histórica desde este punto en adelante o tenemos que
cargar datos desde archivos viejos?
191
B.5 Requerimientos De Seguridad
¿Qué tan seguros deben ser lo datos? ¿Qué tipo de seguridad existe en la fuente de
datos operacionales?
¿Son los requerimientos de seguridad homogéneos?
¿Quienes deberían acceder a los datos?
B.6 Requerimientos De Desempeño
¿Cual es el tiempo más lento de respuesta permisible?
B.7 Requerimientos De Calidad De Datos
Existen 3 categorías para verificar la calidad de los datos:
La calidad de los datos existentes.
La calidad deseada de los datos.
Priorización para la limpieza de los datos
La calidad de los datos afecta especialmente al personal estratégico, operativo, servicio al
cliente y marketing.
B.8 Requerimientos De La Plataforma De Hardware
El hardware debe tener el suficiente poder para manejar requerimientos complejos de acceso y
análisis contra grandes volúmenes de datos.
192
Debe ser escalable porque se presentaran rápidos respecto a:
Volumen de datos.
Frecuencia de actualización.
Patrones de acceso a datos.
Número de reportes y consultas.
Número de personas accediendo a la base de datos.
Número de herramientas utilizando la base de datos.
Número de sistemas operacionales alimentando la base de datos.
193
APÉNDICE C
Evaluación De La Infraestructura Existente
C.1 Introducción
La infraestructura empresarial consiste en dos grandes componentes:
Infraestructura técnica: tales como hardware, middleware y sistemas de administración
de bases de datos.
Infraestructura no técnica: tales como estándares, metadatos, reglas del negocio y
políticas.
C.2 Puntos A Considerar
C.2.1 Hardware
¿Cuál es la plataforma de hardware que se tiene o se usa actualmente?
¿Bajo qué plataforma se debería implementar la aplicación?
194
¿Necesitamos hardware nuevo? ¿Cuál es su costo?
¿Necesitamos más personal para mantenimiento del nuevo hardware?
¿Puede el hardware nuevo integrarse con la plataforma existente?
¿Como será la escalabilidad de el nuevo hardware para afrontar el posible incremento
de procesamiento y volúmenes de datos?
C.2.2 Red
¿Qué tipo de LAN se esta utilizando?
¿Qué tipo de WAN estamos utilizando?
¿El ancho de banda de nuestra WAN es suficiente para crecer?
C.2.3 Middleware
¿Qué tipo de middleware se utiliza actualmente?
¿Tenemos el suficiente middleware para recibir los datos fuente desde plataformas
heterogéneas y transferirlas al entorno de data warehouse?
¿Cuál es la arquitectura de la fuente operacional?
¿Necesitamos nuevo middleware? ¿Cuál es su costo?
¿La conexión será permanente entre los datos fuente y las bases de datos destino?
¿Cuál de nuestro hardware, software y middleware es propietario? ¿Tenemos que
comprarlo o realizar leasing?
195
C.2.4 DBMS
¿Cuál es el DBMS que se está utilizando?
¿Necesitaremos adquirir un nuevo DBMS? cuál es su costo?
¿Será compatible el nuevo DBMS con nuestro sistema operativo?
¿Qué herramientas de software se utilizarán con el DBMS?
¿Nuestro personal posee las habilidades necesarias para usar y administrar el nuevo
DBMS?
¿Será necesario contratar más personal para DBA (Administrador de base de datos)?
C.2.5 Herramientas Y Estándares
¿Como se están analizando los datos en la actualidad? ¿Qué herramientas para consulta
utilizan?
¿Qué herramientas y utilidades necesitan?
¿Con qué otra herramienta se necesita interactuar?
¿Tenemos conocimiento de problemas con la infraestructura técnica?
196
APÉNDICE D
Generalidades Del Sistema
El apartado cita las características generales del sistema de información que lo definen en
cuanto a:
D.1 Proceso de toma de requerimientos: La captura de los requerimientos de un sistema de
soporte a la toma de decisiones se basa en entrevistas con los administradores del negocio y
gira entorno a la generación de reportes estadísticos, indicadores de gestión, estrategias
financieras y de mercadeo, además del mejoramiento de los sistemas transaccionales.
D.2 Características de modelado de los datos: La base de datos que maneja el sistema es
modelada bajo los estándares de la construcción de un Data Warehouse y su funcionalidad
apunta a la creación de información valiosa a partir de datos dispersos.
D.3 Características de la red de datos: La arquitectura Cliente/Servidor es la que soporta la
comunicación de este sistema informacional, de la misma forma en la que los sistemas
transaccionales tienen máquinas servidoras y clientes con peticiones; un sistema estratégico se
197
basa en el mismo principio y centraliza sus servicios en una máquina cuya capacidad de
procesamiento debe soportar las exigencias de información requeridas por los usuarios.
D.4 Características del motor de la base de datos: El motor de la base de datos de los sistemas
estratégicos se diferencia por basarse en los diseños de red en estrella y copo de nieve, permitir
un Proceso Analítico en Línea de los datos y mostrar la información en reportes con diferentes
formas de visualización.
D5. De los procesos ETL: El sistema demanda conocimientos avanzados de los procesos de
redefinición de la estructura lógica de los datos para adaptarlos al modelado adecuado y
aprovechar al máximo la funcionalidad del motor de base de datos.
D6. De los procesos de calidad de los datos: Los datos analizados entran en procesos de
auditoria en niveles de: significado de los daos, completitud y estructura lógica transaccional en
el que los conocimientos del negocio y de las normativas de las base de datos transaccionales
toman una gran relevancia para el criterio decisorio.
D7. De los conocimientos de l uso de las herramientas y el motor de la base de datos: El uso
de todas las aplicaciones de software que hacen parte en el desarrollo del proyecto entra a
prueba para satisfacer los requerimientos informacionales durante las últimas etapas del ciclo
de vida del proyecto.
198
APÉNDICE E
Descripción De La Plataforma De Hardware Y Software
A continuación se describe la plataforma de hardware:
Dada la centralización excesiva de los servicios1 de la arquitectura actual de la Ferretería
Metrópolis 84 Ltda. se ha recomendado la adquisición de un servidor dedicado
exclusivamente al análisis estadístico. Pero debido a que el proyecto estará en periodo de
pruebas de sus resultados se implementará en un servidor de la red que soportará el
procesamiento de la información con expectativas de una decisión final del Coordinador del
área de Sistemas.
La adquisición de la licencia de Microsoft® SQL Server 2005 Standard Edition es de
carácter obligatorio para mantener la legalidad del software como activo de la compañía y es la
que permitirá un crecimiento del sistema y un soporte continuo sobre problemas en
plataformas Microsoft®.
199
La compatibilidad de Microsoft® SQL Server 2005 Standard Edition con la plataforma
de hardware y software existente en Ferretería Metrópolis 84 Ltda. hace que el sistema de
información tenga la posibilidad de crecer sin futuros traumatismos que en su momento se
traduzcan en perdidas para la compañía. Además de que el paquete ofrece las aplicaciones
necesarias como solución candidata a los requerimientos de información.
200
APÉNDICE F
Estudio De Factibilidad
El estudio de factibilidad del proyecto está basado en un análisis costos/beneficios
proporcionado por el Costo total del proyecto y por los Beneficios obtenidos a largo plazo por
la capacidad de análisis otorgada por la información obtenida desde el sistema de información:
Total costos del proyecto: $19’474.278,64
201
APÉNDICE G
Conocimientos Fundamentales De Las Bases De Datos
El apartado hace referencia a los conceptos básicos de las bases de datos relacionales que
forman parte del conocimiento integral de los administradores de las bases de datos y de los
sistemas de información, los cuales son necesarios para poder entender cierta terminología.
Actualmente se maneja una gran cantidad de datos por lo que es necesario disponer de medios
de hardware y software que tradicionalmente la información se almacenaba en ficheros, estos
ficheros no guardaban ninguna relación entre sí y los datos podían repetirse dando lugar a
información redundante y en algunos casos. A veces es necesario cambiar algunos registros y
esto implicaba que todos los programas de aplicación debían modificarse y adaptarse, existía
dependencia entre los ficheros y los programas que utilizaban estos ficheros.
A finales de los 60 surgen las Bases de datos, donde se almacenan todos los datos que
necesita la empresa y los programas no se han de preocupar del almacenamiento físico de esos
datos y ningún cambio en la estructura de los datos afectará a los programas que los utilizan.
202
En una base de datos existe una visión de los datos que no tiene porqué ser la misma que la
visión física, es decir, existe una independencia de lo almacenamiento con respecto a los datos
que los utilizan.25
1ª definición: Podemos definir una base de datos como un conjunto de datos interrelacionados y
almacenados sin redundancias perjudiciales o innecesarias, los cuales se caracterizan por:
1.- Servir a una o más aplicaciones.
2.- Existir independencia entre los datos y los programas que los manejan.
2ª definición: Una base de datos es una colección de datos que están lógicamente relacionados
entre sí, los datos están estructurados según un modelo de base de datos. que refleja las
relaciones y restricciones que tienen estos datos en el mundo real. La descripción y definición
de los datos se encuentra almacenada en la propia base de datos.
3ª definición: Es un conjunto de información que cumple 3 cosas:
1.- Es estructurada.
2.- Es accesible por múltiplos usuarios de forma simultánea.
3.- Existe independencia entre los datos y los programas que los van a tratar.
A estas tres características podemos añadir:
• Coherencia.
• No redundancia innecesaria.
• Seguridad.
25 1 Informática: Curso Diseño de bases de datos en SQL SENA, Modulo 1 Conocimientos fundamentales de
base de datos.
203
APÉNDICE H
Conocimientos en Gerencia de Proyectos
El apartado hace referencia a todos los conocimientos en la Gerencia de Proyectos empleados
durante el desarrollo del proyecto hasta su culminación, incluyendo todos los documentos
generados utilizados como soporte y los conceptos aplicados en la estructuración y
organización de las actividades realizadas.
H.1 Estructura de Descomposición del Trabajo26 (EDT): Es una estructura exhaustiva,
jerárquica y descendente formada por los entregables y las tareas necesarias para desarrollar un
proyecto. La EDT es una herramienta muy común y crítica en la gestión de proyectos.
El propósito de una EDT es documentar el alcance del proyecto. Su forma jerárquica
permite una fácil identificación de los elementos finales. Siendo un elemento exhaustivo en
cuanto al alcance del proyecto, la EDT sirve como la base para la planificación del proyecto.
Todo trabajo a ser hecho en el proyecto debe poder rastrear su origen en una o más entradas
de la EDT.
26 Estrategias Gerenciales: Gerencia de proyectos, gerencia para el emprendimiento, gestión tecnológica y gestión
por resultados SENA, Modulo 1 Gestión Operativa.
204
Una EDT es una simple y organizada presentación del trabajo requerido para
completar el proyecto. Existen muchas maneras de organizar la presentación de este trabajo.
Por ejemplo, se puede organizar de acuerdo a las fases del ciclo de vida del proyecto (Inicio,
Planificación, Ejecución, Control y Cierre), mostrando cada fase como un elemento del nivel
más alto.
Otra forma de organizarla es teniendo en cuenta las responsabilidades funcionales.
Algo importante de recordar es que la EDT documenta el alcance del proyecto, no su plan de
ejecución.
Mientras la organización estructura jerárquicamente a las personas para desarrollar el
trabajo, la EDT estructura jerárquicamente los productos a ser producidos y en los cuales las
personas trabajarán.
H.2 Maneras de construir una EDT
De arriba hacia abajo:
1. Inicie con el objetivo del Proyecto.
2. Desagregue en partes.
3. Determine los Hitos de cada parte.
4. Identifique las actividades necesarias para obtener los resultados.
5. Para fases tempranas del proyecto.
De abajo hacia arriba:
1. Defina un listado de actividades detalladas.
2. Agrupe por:
• Entregables.
• Destrezas.
205
• Cronología.
3. Usualmente trabajo de grupo.
H.3 Propósito de la EDT
Entregar una base para la estimación de los recursos del proyecto:
• Subcontratos
• Proveedores y sus productos
• Servicios
• Cualquier otro recurso identificable
Un ejemplo de una EDT muy sencillo de una ED para pintar una habitación:
• Preparar materiales.
o Comprar pintura.
o Comprar una escalera.
o Comprar brochas y rodillos.
o Comprar removedor de papel tapiz.
• Preparar la habitación.
o Quitar el papel tapiz viejo.
o Quitar la decoración desmontable.
o Cubrir el piso con papel periódico viejo.
o Cubrir los switches de luz con cinta.
o Cubrir los muebles con sábanas.
• Pintar la habitación.
• Limpiar la habitación.
o Desechar o guardar la pintura sobrante.
o Limpiar las brochas y rodillos.
o Desechar los periódicos.
o Quitar las sábanas.
206
APÉNDICE I
Glosario General
I.1 Introducción.
Este apéndice recopila y define los términos generales usados para describir el Data warehouse
con el objetivo de especificar una base común de entendimiento para nuestros lectores.
Además, este glosario provee otros términos y definiciones adicionales utilizados en este o
relacionados con el presente proyecto.
I.2 Términos.
Actualización de datos. Es la actividad que consiste en actualizar el contenido de los datos
del data warehouse después de terminar la carga (load) inicial de los mismos.
Análisis multidimensional. Análisis simultáneo de múltiples dimensiones de datos.
Área tema. Los datos en el data warehouse se encuentran orientados a las principales áreas
temáticas de la empresa, tales como clientes o productos.
207
Base de datos multidimensional. Es un repositorio de datos que es diseñado alrededor de
un conjunto de dimensiones y en la cual los datos son presentados en cubos de datos, lo cual
se constituye en el término opuesto a las tablas en una plataforma de base de datos relacional.
Base de datos operativa. Véase Base de datos transaccional.
Base de datos transaccional. Es una base de datos que apoya la ejecución de un proceso
comercial o de negocio, grabando la actividad de negocio y sirviendo como el sistema de
registro. También es llamada base de datos OLTP.
Cubo. Nombre para la estructura dimensional en una base de datos OLAP.
Datamart. Un Datamart es un subconjunto especializado de una bodega de datos. Los
datamarts contienen diferentes combinaciones y selección de los mismos datos detallados
identificados en la bodega de datos, por esto puede decirse que los datamarts vienen a ser
como una extensión natural de la bodega de datos.
Data mining. Es un proceso que, a través del descubrimiento y cuantificación de relaciones
predictivas en los datos, permite transformar la información disponible en conocimiento útil
de negocio.
Data staging. El data staging está entre los sistemas operacionales fuente y el área de
presentación de datos. El área datos data staging del data warehouse es al mismo tiempo el área
de almacenamiento de los datos y de cambios, en el cual se limpian los datos, se transforman,
se duplican, se combinan, se archivan y se preparan los datos para ser usados en el data
warehouse.
Atributo. Columna o campo en una tabla de dimensión.
208
Columna. Estructura de datos que contiene un item de dato individual en una fila o registro.
Equivalente a un campo de base de datos.
Consultas Ad hoc. Consultas Formuladas por el usuario según la necesidad del momento.
Dimensión lentamente cambiante (SCD). Corresponde a la traducción del término Slowly
Changing Dimension, el cual indica la tendencia que tienen los registros de una dimensión a
cambiar de manera gradual u ocasional a través del tiempo.
Diseñador de reportes. Interfaz utilizada para crear orígenes de datos, consultas y conjunto
de datos y definición de reportes.
Drill down. Este término corresponde a la operación OLAP que nos permite visualizar los
datos desde lo más general hasta lo más particular.
Esquema en estrella. El esquema en estrella o Star Join Schema es una representación
genérica de un modelo dimensional en una base de datos relacional en la cual una tabla de
hechos compuesta por llaves, es unida a un número de tablas de dimensión, cada una con una
llave primaria.
Fact table. En un esquema en estrella (modelo dimensional), ésta corresponde a la tabla
central con valores numéricos ó medidas.
Herramienta de acceso a datos: Herramienta cliente que consulta, obtiene o manipula datos
almacenados en una base de datos relacional, preferiblemente en un modelo dimensional
ubicado en área de presentación de datos.
Llave artificial (surrogate key). Las llaves artificiales son llaves cuyos valores son enteros
(integer), los cuales son asignados de manera secuencial como sean requeridas en el área de
209
Stage para poblar una tabla de dimensión y unir esta con la tabla de hechos. En la tabla de
dimensión, la llave artificial es la llave primaria (primary key). En la tabla de hechos, la llave
artificial es una llave foránea a una dimensión específica. La llave artificial no puede ser
interpretada por sí misma y son utilizadas en muchas situaciones para manejar dimensiones
lentamente cambiantes.
Medida del negocio: Métrica de desempeño capturada por un sistema transaccional y
presentado como un hecho en el modelo dimensional.
Metadata. Información sobre los datos almacenados en la bodega de datos, permite conocer
las fuentes de donde es extraído y reglas de negocio.
Middleware. Software que provee transparencia en la heterogeneidad entre tecnología de
hardware y software.
Null. Este es el valor de un campo de datos o registro para el cual no existe valores.
OLAP. Siglas de On Line Analytical Processing. Es una tecnología que permite le permite a los
usuarios tener una visión de los datos de una forma rápida, interactiva y fácil de usar.
OLTP. Siglas de On Line Transactional Processing. Este termino es usado para definir cualquier
sistema que reúne datos usando las transacciones entre la fuente de datos y la base de datos.
Las aplicaciones de OLTP están organizadas para ejecutar las transacciones para los cuales
fueron hechos, como por ejemplo: mover dinero entre cuentas, un cargo o abono, una
devolución de inventario, etc. Por otro lado, una bodega de datos está organizada en base a
conceptos, como por ejemplo: clientes, facturas, productos, etc.
Paquete de información. Un paquete consiste en una colección organizada de conexiones,
elementos de flujo de control, elementos de flujo de datos, controladores de eventos, variables
210
y configuraciones que se pueden ensamblar con la ayuda de las herramientas gráficas de diseño
proporcionadas por SQL Server 2005 Integration Services (SSIS) o mediante programación.
Proceso del negocio: Actividades principales operacionales o procesos soportados por el
sistema transaccional fuente, tales como ventas en una organización comercial. Seleccionar el
proceso del negocio es el primer paso en el diseño de un modelo dimensional.
Query. Son las consultas que se pueden realizar sobre una base de datos o sobre una bodega
de datos, las cuales permiten manipular la información de dichos repositorios.
RDBMS. Manejador de bases de datos relacional, constituyen la base para los sistemas OLTP.
Roll up. Esta operación OLAP facilita el desplazamientos entre los niveles superiores para
obtener información agregada, ver acumulados y totalizadores (sumarizaciones).
Sistema de soporte a la toma de decisiones (SSTD). Se trata de sistemas de información de
cómputo diseñados para ayudar y soportar la toma de decisiones de los administradores.
Slice and dice. Es el proceso de separar y combinar datos del data warehouse.
SQL Server Integration Services (SSIS). Es una plataforma para generar soluciones de
integración de datos de alto rendimiento, lo que incluye paquetes que proporcionan
procesamiento de extracción, transformación y carga (ETL) para almacenamiento de datos.
SQL Server Analysis Services (SSAS). Ofrece funciones de procesamiento analítico en línea
(OLAP) y minería de datos para aplicaciones de Business Intelligence. Analysis Services admite
OLAP al permitir al usuario diseñar, crear y administrar estructuras multidimensionales que
contienen datos agregados de otros orígenes de datos, como las bases de datos relacionales.
211
ANEXOS
212
ANEXO A
CUESTIONARIO DISEÑADO PARA EL PERSONAL DE GERENCIA MEDIA Y
OPERATIVA DEL DEPARTAMENTO DE VENTAS
213
CUESTIONARIO
1. ¿Conoce usted que es un Sistema de Soporte a la toma de Decisiones?
a.) Si.
b.) No.
2. ¿Conoce usted que es una Bodega de Almacenamiento de Datos?
a.) Si.
b.) No.
3. ¿Qué nivel de importancia tiene para usted la información estadística-histórica para la
generación de estrategias de mercadeo?
a.) Alto.
b.) Medio.
c.) Bajo.
4. ¿Qué porcentaje de efectividad tiene el módulo de estadísticas actual en la identificación de
clientes potenciales?
a.) Alto.
b.) Medio.
c.) Bajo.
5. ¿Cuál clasificación de los clientes cree usted que predomina más en las ventas de la empresa?
a.) Masculino.
b.) Femenino.
c.) Persona jurídica.
214
6. ¿A qué fuentes de información acude usted cuando necesita datos estadísticos? Enumérelas.
7. ¿En que circunstancias de la toma de decisiones cree usted, que se requiere del uso del
modulo de estadísticas como herramienta de soporte?
a.) Todas.
b.) Algunas.
c.) Ninguna.
8. ¿Cree usted que la implementación de un sistema de soporte a la toma de decisiones puede
incrementar el volumen de las ventas en la empresa?
a.) Si.
b.) No.
9. ¿Conoce usted empresas locales que tengan esta tecnología aplicada a sus procesos de
información?
a.) Si.
b.) No.
10. ¿Cuáles de las siguientes ventajas considera usted que ofrece u ofrecerá un sistema de
soporte a la toma de decisiones a nivel empresarial?
a.) Productividad.
b.) Control.
c.) Desarrollo.
d.) Prestigio.
11. ¿Cree usted que las empresas ferreteras de Barranquilla están preparadas para asimilar este
cambio tecnológico?
a.) Si.
b.) No.
215
12. ¿Le gustaría contar con un sistema de soporte a la toma de decisiones basado en tecnología
actual, en el cuál se almacene la información de todas las ventas de la empresa?
a.) Si.
b.) No.
216
ANEXO B
ENTREVISTA REALIZADA A LOS GERENTES GENERAL Y GERENTE
ADMINISTRATIVO.
217
ENTREVISTA 1
ENTREVISTADOS:
Gerente general: Enrique Javier Oliva.
Gerente Administrativo Y Financiero: Argemiro Avilez.
ENTREVISTADORES: Cesar Orozco, Sandra Peñaranda, Mauricio Rodríguez.
OBJETIVO: El propósito de esta entrevista es obtener los criterios más importantes en la toma
de decisiones administrativas en el área de ventas de la Ferretería Metrópolis 84 Ltda, buscando
una descripción del proceso de ventas y los actores involucrados. Además, realizar una
presentación introductoria a la construcción de un Data Warehouse y los sistemas de soporte a la
toma de decisiones y medir el conocimiento de los entrevistados respecto a esta temática.
1. ¿Cuáles son los artículos que mas frecuentemente compran los clientes?
2. ¿Cuál es la rentabilidad del cliente? ¿es negativa? ó ¿es positiva?
3. ¿Existe una comparación de ventas y tipos de ventas con relación al tiempo?
218
4. Respecto a las ventas a crédito, ¿Quienes son los clientes principales?, ¿Quienes se
encuentran al día y quienes no?
5. ¿Cuál es el enfoque de ventas de la compañía?
6. ¿De que manera se miden los presupuestos?
7. ¿Que expectativas tiene respecto al proyecto de construcción de un sistema de soporte
a la toma de decisiones en la compañía?
219
ANEXO C
ENTREVISTA DIRIGIDA AL GERENTE COMERCIAL Y AL COORDINADOR DE
VENTAS.
220
ENTREVISTA 2
ENTREVISTADOS:
Gerente Comercial: Alex Francisco Sánchez Martínez.
Coordinador De Ventas: Jorge Sierra.
ENTREVISTADORES: Cesar Orozco, Sandra Peñaranda, Mauricio Rodríguez.
OBJETIVO: La finalidad primordial de esta entrevista es realizar la captura inicial de
requerimientos de la gerencia comercial y de la coordinación del área de ventas; además, conocer
de qué manera se están llevando a cabo las estrategias de comercialización y los análisis de
presupuestos.
1. ¿Cuales son los Objetivos Estratégicos Comerciales de la empresa?
2. ¿Cuales son los indicadores de gestión de los procesos que generan impacto en los
objetivos estratégicos comerciales de la empresa?
3. ¿Como coordina y supervisa el cumplimiento de los indicadores de gestión de la
empresa?
4. ¿Como monitorea los indicadores de gestión del área comercial y cual es su relación
con el presupuesto?
5. ¿Como realiza el análisis del presupuesto?
6. ¿Cuáles son las variables financieras que inciden en el presupuesto que se proyectará
en el análisis de ventas?
221
7. ¿En que intervalos de tiempo realiza comparativos de los presupuestos?
8. ¿Cuáles son las acciones establecidas para alcanzar los objetivos en cuanto a clientes
y mercado?
9. ¿Cómo segmenta el mercado?
10. ¿Quiénes son los directores comerciales de los proveedores y cómo sostiene las
condiciones comerciales pactadas?
11. ¿Cuáles son las estrategias de comercialización de productos, cómo las determina,
en base a que?
12. ¿Cómo está organizado el inventario? ¿Existen líneas de productos en el sistema de
información de manera digital? ¿Cuáles son y cómo están clasificadas?
13. ¿Con que módulos específicos del aplicativo de estadísticas utiliza actualmente para
el desempeño de sus funciones?
14. ¿Cuál es el grado de satisfacción respecto al funcionamiento del aplicativo de
estadísticas?
15. ¿Tiene sugerencias con relación al aplicativo de estadísticas para optimizar el
desempeño de sus funciones?
222
ANEXO D
ENTREVISTA EFECTUADA AL REVISOR FISCAL
223
ENTREVISTA 3
ENTREVISTADOS:
Revisor Fiscal: Teresa Oliva de Moscote.
Auxiliar Contable, Asistente Revisor Fiscal: Stefany Ramos.
ENTREVISTADORES: Cesar Orozco, Sandra Peñaranda, Mauricio Rodríguez.
1. ¿Cuales son los reportes de ventas en los módulos de estadística y de contabilidad que
mas utiliza en la toma de decisiones?
2. ¿Cuales son sus criterios de interés para analizar las ventas?
3. ¿Que influencia tiene el periodo fiscal en la generación de reportes y en la toma de
decisiones?
4. ¿Con que frecuencia se generan estos reportes y cual es el horizonte de tiempo para el
análisis de las ventas?
5. ¿Cual es el tiempo máximo que podría esperar por la información requerida?
224
ANEXO E
ENTREVISTA DIRIGIDA AL GERENTE FINANCIERO
225
ENTREVISTA 4
ENTREVISTADO:
Gerente Financiero: Argemiro Aviles.
ENTREVISTADORES: Cesar Orozco, Sandra Peñaranda, Mauricio Rodríguez.
1. ¿Cuales son los reportes de ventas en los módulos de estadística y de contabilidad que
mas utiliza en la toma de decisiones?
2. ¿Cuales son sus criterios de interés para analizar las ventas?
3. ¿Que influencia tiene el periodo fiscal en la generación de reportes y en la toma de
decisiones?
4. ¿Con que frecuencia se generan estos reportes y cual es el horizonte de tiempo para el
análisis de las ventas?
5. ¿Cual es el tiempo máximo que podría esperar por la información requerida?
226
ANEXO F
ENTREVISTA FINAL DIRIGIDA AL GERENTE COMERCIAL
227
Entrevista Final Toma Final De Requerimientos
ENTREVISTADO:
Gerente Comercial: Alex Francisco Sánchez Martínez.
ENTREVISTADORES: Cesar Orozco, Sandra Peñaranda, Mauricio Rodríguez.
OBJETIVO: Validar los avances respecto a los requerimientos del proyecto y aclarar dudas
concernientes a segmentación de los clientes, códigos de los vendedores, presupuesto e
indicadores de éxito.
1. ¿Qué variables tiene en cuenta para la segmentación de los clientes?
2. ¿Cuáles son los indicadores de gestión del proceso de ventas que generan impacto en
los objetivos estratégicos de la empresa?
3. ¿De que manera influye el presupuesto en el proceso de ventas?
4. ¿Existe un método claro y definido para la gestión de promociones?
5. Requerimientos adicionales.
228
BIBLIOGRAFIA
[1]. Harjinder S. Hill, Prakash C. Rao, The Official Guide to Data WareHousing. Que
Publishing – 1996 Prentice Hall.
[2]. Vaisman Alejandro, La Investigación en OLAP y Data Warehousing: Pasado, Presente
y Futuro, jornadas de data mining facultad de ciencias exactas y naturales Universidad
de Buenos Aires 29 septiembre de 2006.
[3]. Mundy Joy, Thornthwaite Warren, Kimball Ralph, The Microsoft Data Warehouse
Toolkit : With SQL Server 2005 and the Microsoft Business Intelligence Toolset John
Wiley & Sons © 2006
[4]. Wrembel Robert , Koncilia Christian Data warehouses and OLAP : concepts,
architectures, and solutions, IRM Press © 2007
[5]. Ponniah Paulraj, Data Warehousing Fundamentals A Comprehensive guide to IT
Professionals John Wiley & Sons © 2001 pp 1-89.
[6]. Kimball Ralph, Reeves Laura, Ross Margy, The Data warehouse Lifecycle Toolkit
Expert methods for Designing, Developing, and Deploying Data Warehouses Wiley
Publishing, Inc 1998.
229
[7]. Kimball Ralph, Ross Margy, The Data Warehouse Toolkit : The Complete Guide To
Dimensional Modelling John Wiley & Sons © 2002
[8]. Sampieri Hernadez Roberto Metodología de la Investigación Mc grawHill © 2003
[9]. Libros en pantalla de Microsoft SQL Server 2005 © 2005 Microsoft Corporation.
[10]. Peña Juan, Suárez Jesús Utilización de información histórica para decisiones
empresariales Pontificia Universidad Javeriana, Bogotá, Colombia 2005
[11]. Urrutia angélica, López Hugo, Jiménez Leoncio, Farias Nennett, Modelamiento de un
data warehouse, caso práctico en la agroindustria Universidad Católica del Maule,
Talca,Chile 1999.
[12]. Sitio Web oficial del Kimball Group http://www.kimballgroup.com/html/about.html
[13]. Oz Effy, Administración de sistemas de información 2da edición, Thomson Learning
,2001
[14]. Cohen Daniel, Asín Enrique Sistema de Información para los negocios: Un enfoque
para la toma de decisiones, 3ra edición Mc grawHill 2000
230
[15]. SENA Estrategias gerenciales: Gerencia de proyectos, gerencia para el
emprendimiento, gestión tecnológica y gestión por resultados, Modulo 1 Gestión
Operativa.
[16]. http://www.hp.com/sbso/espanol/news/energy-star.html
[17]. http://www.eu-energystar.org/es/es_008p.shtml#electricity
[18]. Turley Paul, Bryant Todd, Counihan James, DuVarney Dave Professional SQL
Server™ 2005 Reporting Services Wiley Publishing © 2006
