Tesis - Sie Casagrande S.A.A PDF

UNIVERSIDAD PRIVADA “ANTENOR ORREGO”
FACULTAD DE INGENIERÍA
ESCUELA PROFESIONAL DE INGENIERÍA DE
COMPUTACIÓN Y SISTEMAS
Tesis:
“SISTEMA DE INFORMACIÓN EJECUTIVO DE
PRODUCCIÓN PARA LA GERENCIA DE CAMPO DE LA
EMPRESA AGROINDUSTRIAL CASA GRANDE S.A.A.”
Trabajo de Investigación para Optar el Título Profesional de

INGENIERO DE COMPUTACIÓN Y SISTEMAS
Autores:
Br. León Paredes Vladimir Ulianov

Br. Portocarrero Regalado Luis Alberto
Asesor:
Ing. MARKO RAUL ALVARADO RODRIGUEZ
Trujillo – Perú
2005
i
“SISTEMA DE INFORMACION EJECUTIVO DE
PRODUCCIÓN PARA LA GERENCIA DE CAMPO DE LA
EMPRESA AGROINDUSTRIAL CASA GRANDE S.A.A.”
Aprobado por:
Ing. Elmer González Herrera.

Presidente
Ing. Christian Araujo Gonsález.

Secretario
Ing. Carlos Castillo Diestra.

Vocal
Asesor:
Ing. Marko Raúl Alvarado Rodríguez.
ii
PERSONAL INVESTIGADOR
Autores:
Br. León Paredes Vladimir Ulianov.
Br. Portocarrero Regalado Luis Alberto.
iii
DEDICATORIA
A Dios, por darme su infinito amor,

misericordia, salud y sabiduría; a Pablo
León, mi padre, por ser el ejemplo para mi
vida, también por su paciencia y gran
sabiduría; a mi madre Elda Paredes, por su
inmenso amor maternal, comprensión y
apoyo en todo momento, a mi hermana
Andrea, tú que siempre estás ahí para
brindarme tu apoyo; a mis tíos Julio y Juana
por el cariño que me dan siempre; a
Carolina, por hacerme creer en el amor y
lograr hacerme sonreír cada día. Me ayudan
a mejorar todos los días de mi vida por el
amor que me brindan.
Con amor para Ustedes.
Vladimir Ulianov León Paredes.
A Dios por darme la oportunidad de lograr
mi objetivo y dar a mis padres Alberto y
Dina fuerzas para vencer las vicisitudes de
la vida y haber hecho realidad su esfuerzo, a
mis hermanos por su constante apoyo, a mis
engreídas Fressia y Kiara quienes han sido
parte importante en este proyecto y a
Marisela por su amor y por ser la madre de
mi hijo Fabián Alonso, a quienes les dedico
con mucho amor y gratitud.
Luis Alberto Portocarrero Regalado.
iv
AGRADECIMIENTO
El presente trabajo no hubiera llegado a su culminación sin la ayuda valiosa de

personas en quienes confiamos y que confiaron en nosotros, a quienes va nuestro
agradecimiento:
A nuestro asesor Ing. Marko Raúl Alvarado Rodríguez por sus consejos y
orientaciones que fue contribución importante durante el desarrollo de la tesis.
A nuestro amigo el Sr. Víctor Elguera Sevillano por su apoyo y orientación que
fue de gran ayuda para el desarrollo y diseño del Sistema Ejecutivo para la Gerencia de
Campo.
Al Ing. Ricardo Mendoza Rivera por brindarnos su confianza, por la gran ayuda
que significó y compartir sus conocimientos con nosotros.
A la Gerencia de Campo de la Empresa Agroindustrial Casa Grande S.A.A., por

brindarnos todas las facilidades para aplicar nuestros conocimientos con el desarrollo
del presente Sistema de Información Ejecutivo.
A nuestros amigos y compañeros quienes cada día nos dieron aliento,

motivación y deseo para que las cosas nos salgan bien a lo largo del proyecto.
Atentamente:
Vladimir Ulianov León Paredes & Luis Alberto Portocarrero Regalado.
v
ÍNDICE GENERAL
Aprobado por: ...................................................................................................................................................................................... ii

DEDICATORIA ................................................................................................................................................................................ iv
AGRADECIMIENTO ....................................................................................................................................................................... v
ÍNDICE GENERAL .......................................................................................................................................................................... vi
ÍNDICE DE FIGURAS Y TABLAS ............................................................................................................................................... viii
RESUMEN ....................................................................................................................................................................................... xii
ABSTRACT ..................................................................................................................................................................................... xiii
INTRODUCCIÓN .......................................................................................................................................................................... xiv
HIPÓTESIS:.......................................................................................................................................................................................xx
OBJETIVOS: ......................................................................................................................................................................................xx
Objetivo General: ..................................................................................................................................................................... xx
Objetivos Específicos: ............................................................................................................................................................. xx
CAPITULO 1 .................................................................................................................................................................................... 22
FUNDAMENTO TEÓRICO Y METODOLOGÍA......................................................................................................................... 22
1.1. FUNDAMENTO TEÓRICO ................................................................................................................................... 22
1.1.1. INTRODUCCION A LOS SISTEMAS DE INFORMACIÓN ..................................................................... 22
1.1.1.1. Definición de los Sistemas de Información ....................................................................................... 22
1.1.1.2. Tipos de información que suministra un sistema de información ................................................. 23
1.1.1.3. Tipos De Sistemas De Información .................................................................................................... 24
1.1.2. SISTEMAS DE INFORMACIÓN EJECUTIVO ............................................................................................ 27
1.1.2.1. ¿QUÉ ES UN SIE? ............................................................................................................................................. 28
1.1.2.2. Lo que debe contener un SIE ........................................................................................................................... 29
1.1.2.3. CARACTERÍSTICAS DE UN SIE....................................................................................................... 33
1.1.2.4. EL PROCESO DE DESARROLLO DE UN EIS ................................................................................. 34
1.1.2.5. IMPLANTACIÓN EXITOSA DE UN SIE ......................................................................................... 34
1.1.2.6. FACTORES DEL ÉXITO DE UN SIE ................................................................................................. 34
1.1.3. INDICADORES DE GESTIÓN...................................................................................................................... 35
1.1.4. DATA MART .................................................................................................................................................. 36
1.1.5. DATA WAREHOUSE .................................................................................................................................... 37
1.1.5.1. OPERACIONES EN UN DATA WAREHOUSE .............................................................................. 38
1.1.5.2. MODELAMIENTO MULTIDIMENSIONAL ................................................................................... 41
1.1.5.3. MODELADO DEL DATA WAREHOUSE ........................................................................................ 42
1.1.6. BASE DE DATOS MULTIDIMENSIONAL ................................................................................................. 42
1.1.7. SQL SERVER PARA EL DATA MART ........................................................................................................ 43
1.1.8. DATA TRANSFORMATION SERVICE (DTS) ........................................................................................... 44
1.1.9. PROCESAMIENTO ANALÍTICO EN LÍNEA (OLAP) .............................................................................. 44
1.1.10. CUBOS OLAP ................................................................................................................................................. 44
1.2. METODOLOGÍAS................................................................................................................................................... 48
1.2.1. METODOLOGIA PARA EL DESARROLLO DE UN SISTEMAS DE INFORMACIÓN PARA
EJECUTIVOS ........................................................................................................................................................................ 48
1.2.1.1. Identificación de las Alternativas para el Desarrollo del Sistema. ................................................. 49
1.2.1.2. Creación de la Propuesta. ................................................................................................................... 49
vi
1.2.1.3. Determinación de las Necesidades del Ejecutivo. ............................................................................ 51
1.2.1.4. Creación del Sistema y Presentación de un Prototipo ..................................................................... 51
1.2.1.4.1. Desarrollo e implementación de la base de datos estratégica. ................................................... 52
1.2.1.4.2. Planeación......................................................................................................................................... 52
1.2.1.4.3. Determinación de los Requerimientos .......................................................................................... 60
1.2.1.4.4. Análisis ............................................................................................................................................. 63
1.2.1.4.5. Diseño y Modelización.................................................................................................................... 65
1.2.1.4.6. Construcción .................................................................................................................................... 66
1.2.1.4.7. Prueba ............................................................................................................................................... 67
1.2.1.4.8. Desarrollo ......................................................................................................................................... 67
1.2.2. RESUMEN SISTEMA EJECUTIVO............................................................................................................... 68
1.2.3. DIAGRAMA DE GANTT DE LAS ACTIVIDADES ................................................................................... 69
CAPITULO 2 .................................................................................................................................................................................... 70
ANÁLISIS Y RESULTADOS........................................................................................................................................................... 70
2.1. IDENTIFICACIÓN DE LAS ALTERNATIVAS PARA EL DESARROLLO DEL SISTEMA EJECUTIVO.
70
2.2. CREACIÓN DE LA PROPUESTA ......................................................................................................................... 72
2.2.1. ELABORACIÓN DEL PROYECTO .............................................................................................................. 72
2.2.2. DEFINICIÓN DE LA PROPUESTA AL EJECUTIVO ................................................................................ 76
2.3. DETERMINACIÓN DE LAS NECESIDADES DEL EJECUTIVO ................................................................... 77
ORGANIGRAMA DE LA EMPRESA ............................................................................................................................................ 79
2.4. CREACIÓN DEL SISTEMA Y PRESENTACIÓN DEL PROTOTIPO ............................................................ 99
2.4.1. DISEÑO E IMPLEMENTACIÓN DE LA BASE DE DATOS ESTRATÉGICA ........................................ 99
2.4.2. CREACIÓN DEL SISTEMA Y PRESENTACIÓN DEL PROTOTIPO .................................................. 186
2.4.2.1. MODELOS USE CASE ...................................................................................................................... 186
2.4.2.2. MODELO USE CASE DEL SISTEMA EJECUTIVO ....................................................................... 187
2.4.2.3. DISEÑO DE LA INTERFAZ HOMBRE-MAQUINA..................................................................... 188
2.4.2.4. DIAGRAMA DE COLABORACIONES .......................................................................................... 195
2.4.2.5. DIAGRAMA DE SECUENCIAS ...................................................................................................... 197
2.4.3. PRUEBAS PARA EL SISTEMA EJECUTIVO ............................................................................................ 200
2.4.3.1. Prueba de Caja Negra para el SIE .................................................................................................... 200
CAPÍTULO 3 .................................................................................................................................................................................. 202
DISCUSIÓN .................................................................................................................................................................................... 202
3.1. MANERA PRESENCIAL ...................................................................................................................................... 203
3.1.1. DISEÑO PRE-EXPERIMENTAL, PRE-PRUEBA Y POST-PRUEBA....................................................... 203
3.1.2. CÁLCULO DE LOS INDICADORES DE LA HIPÓTESIS ....................................................................... 204
3.1.3. APLICACIÓN DEL RANGO DE SATISFACIÓN A LOS INDICADORES DE LA HIPÓTESIS ......... 213
3.1.4. ANÁLISIS ESTADISTICO PARA LA PRUEBA PRESENCIAL DE LA HIPÓTESIS ............................ 215
3.2. MANERA NO PRESENCIAL ............................................................................................................................... 218
CAPITULO 4 .................................................................................................................................................................................. 224
CONCLUSIONES Y RECOMENDACIONES............................................................................................................................. 224
REFERENCIAS BIBLIOGRÁFICAS ............................................................................................................................................. 226
ANEXOS ......................................................................................................................................................................................... 229
vii
ÍNDICE DE FIGURAS Y TABLAS
Pág.
Figura I.1 Distribución de las Zonas de Producción…………………………………. xvii
Capítulo 1 22
Figura 1.1 Categoría de los Sistemas de Información………………………………… 23
Figura 1.2 Sistema de Soporte de Decisiones (DSS)………………………………….. 27
Figura 1.3 Lo que debe contener un SIE……………………………………………… 30
Figura 1.4 Tipos de operaciones en un Data Warehouse……………………………… 38
Figura 1.5 Cubo OLAP………………………………………………………………... 45
Figura 1.6 Esquemas Relacionales y Cubos…………………………………………... 46
Figura 1.7 Jerarquía de los Cubos OLAP……………………………………………... 47
Figura 1.8 Medidas de un Cubo………..……………………………………………… 47
Figura 1.9 Método para el Desarrollo de SIE basado en Prototipos…………………... 48
Figura 1.10 Ciclo de Desarrollo……………………………………………………….. 52
Figura 1.11 Pasos de la Fase de Planeación…………………………………………... 53
Figura 1.12 Método de Desarrollo Espiral……………………………………………. 55
Figura 1.13 Algunas dimensiones para restringir el ámbito de una primera
implementación del DW………………………………………………….. 56
Figura 1.14 Requerimientos para la solución del Data Warehouse…………………… 60
Tabla 1.1 Perspectivas del Data Warehouse establecidas mediante el Diagrama de
Zachman………………………………………………………………….. 61
Figura 1.15 Molde para una Consulta Empresarial…………………………………… 64
Figura 1.16 Esquema Estrella…………………………………………………………. 65
Tabla 1.2 Resumen de entregables de Sistema Ejecutivo…………………………….. 68
Capítulo 2 70
Tabla 2.1 Alternativas de Desarrollo………………………………………………...... 70
Tabla 2.2 Cuadro de Evolución de alternativas de desarrollo del SIE………………... 71
Tabla 2.3 Características de Hardware……………...………………………………… 83
Tabla 2.4 Costos de los Servicios Profesionales……………………………………… 88
Tabla 2.5 Total de horas de uso de la Computadora………………………………...… 89
Tabla 2.6 Costo por servicios de Hardware y Equipos…………………………..…… 89
Tabla 2.7 Costo utilización de Software…….………………………………………… 90
Tabla 2.8 Costo por Materiales…………………………………………..…………… 91
Tabla 2.9 Costo por Materiales……………………………………………………….. 91
Tabla 2.10 Costo por Servicios………………………………………………………... 92
Tabla 2.11 Costo por Bibliografía…………………………………………………….. 92
Tabla 2.12 Total de estimación de Costos…………………………………………….. 93
Tabla 2.13 Ejemplo Indicadores de Gestión…………………………………………... 97
Tabla 2.14 Criterio de Evaluación…………………………………………………….. 97
Tabla 2.15 Criterio de Evaluación…………………………………………………..… 98
Tabla 2.16 Criterio de Evaluación……………………….……………………………. 98
Figura 2.1 Enfoque de Implementación……………………………………………….. 99
viii
Figura 2.2 Método de Desarrollo Espiral……………………………………………... 100
Figura 2.3 Arquitectura de referencia de Datawarehouse…………………………….. 102
Figura 2.4 Base de Datos Transaccional………………………………………………. 109
Tabla 2.17 Tabulación de objetos de tecnología de fuentes de datos por áreas Tema... 110
Tabla 2.18 Atributos de la tabla Dimensiones………………………………………… 111
Tabla 2.19 Nombre de las tablas Dimensiones………………………………………... 112
Figura 2.5 Diseño Físico de la Base de Datos del Data Mart……………………...….. 113
Figura 2.6 Modelo Starnet Vehículo………………………………………………….. 114
Figura 2.7 Modelo Starnet Personal…………………………………………………... 115
Figura 2.8 Modelo Starnet Insumos…………………………………………………… 116
Tabla 2.20 Matriz para Seleccionar el Data Mart…………………………………….. 128
Tabla 2.21 Objetivos de las Tablas de Hechos………………………………………. 129
Tabla 2.22 Dimensiones de Tabla de Hechos Vehículo……………………………… 130
Tabla 2.23 Dimensiones de Tabla de Hechos Insumos………………………………. 130
Tabla 2.24 Dimensiones de Tabla de Hechos Personal………………………………. 130
Tabla 2.25 Hechos de cada Tabla de Hechos………………………………………… 131
Figura 2.9 Diagrama de la Tabla de Hechos Vehículo …..…………………………… 132
Figura 2.10 Diagrama de la Tabla de Hechos Insumos ……………………………… 132
Figura 2.11 Diagrama de la Tabla de Hechos Personal..…………………………………………….. 133
Tabla 2.26 Detalle de las claves de las Dimensiones…………………………………. 133
Tabla 2.27 Detalle de las Medidas de las Tablas de Hechos………………………….. 134
Tabla 2.28 Tabla de Hechos del Data Mart………..…………………………………. 135
Figura 2.12 Jerarquía de los Atributos de la Dimensión Geografía …………………. 136
Tabla 2.29 Detalle de la .Dimensión Geografía………………………………………. 136
Figura 2.13 Jerarquía de los Atributos de la Dimensión Tiempo…………………….. 137
Tabla 2.30 Detalle de la Dimensión Tiempo…………………………………………. 137
Figura 2. 14 Jerarquía de los Atributos de la Dimensión Producto…………………… 138
Tabla 2.31 Detalle de Dimensión Producto……………………………………………
138
Figura 2. 15 Jerarquía de los Atributos de la Dimensión Estado de Campo…………..
138
Tabla 2.32 Detalle de Dimensión Estado de Campo..…………………………………
138
Figura 2.16 Jerarquía de los Atributos de la Dimensión Personal…………………….
139
Tabla 2.32 Detalle de Dimensión Personal…………………………………………….
139
Figura 2.17 Jerarquía de los Atributos de la Dimensión Vehículo……………………
Tabla 2.34 Detalle de Dimensión Vehículo…………………………………………… 140
Figura 2.18 Jerarquía de los Atributos de la Dimensión Insumo..…………………… 140
Tabla 2.35 Detalle de Dimensión Insumo..…………………………………………… 141
Figura 2.19 Tabla de Hechos Vehículo……………………………………………….. 141
Figura 2.20 Tabla de Hechos Insumos……………………………………………….. 142
Figura 2.21 Tabla de Hechos Personal………………………………………………... 143
Figura 2.22 Esquema Estrella del Data Mart..………………………………………... 143
Tabla 2.36 Nombres estándares para las Tablas Hechos y Dimensiones……………... 144
Tabla 2.37 Determinación de las Agregaciones……………………………………… 145
Figura 2.23 Geografía_Dim…………………………………………………………… 146
ix
Figura 2.24 Tiempo_Dim……………………………………………………………... 147
Figura 2.25 Producto_Dim……………………………………………………………. 147
Figura 2.26 EstadoCampo_Dim………………………………………………………. 147
Figura 2.27 Personal_Dim…………………………………………………………….. 148
Figura 2.28 Vehículo_Dim……………………………………………………………. 148
Figura 2.29 Insumo_Dim…………………………...…………………………………. 148
Figura 2.30 Data Mart…………………………………………………………………. 149
Figura 2.31 Workflows de los Pasos de Transformación..……………………………. 150
Figura 2.32 Diagrama de Workflow con Restricciones de Precedencia……………… 152
Figura. 2.33 Paquete de Servicio de Transformación de Datos………………………. 154
Figura 2.34 Ventana de Código para el Paso Limpieza Datos………………………... 156
Figura 2.35 Poblamiento de la Dimensión Geografía………………………………… 158
Figura 2.36 Poblamiento de la Dimensión Tiempo…………………………………... 159
Figura 2.37 Poblamiento de la Dimensión Producto………………………………….. 161
Figura 2.38 Poblamiento de la Dimensión Estado de Campo………………………… 162
Figura 2.39 Poblamiento de la Dimensión Personal…………………………………... 163
Figura 2.40 poblamiento de la Dimensión Vehículo………………………………….. 164
Figura 2.41 Poblamiento de la Dimensión Insumo…………………………………… 165
Figura 2.42 Poblamiento de la tabla Hechos Vehículo………………………………... 166
Figura 2.43 Poblamiento de la tabla de Hechos Personal…………………………….. 168
Figura 2.44 Poblamiento de la tabla de hechos Insumo………………………………. 169
Figura 2.45 Elección de la tabla de Hechos…………………………………………… 171
Figura 2.46 Elección de las Medidas…………………………………………………. 172
Figura 2.47 Elección de las Dimensiones……………………………………………... 173
Figura 2.48 Nombre del Cubo………………………………………………………… 173
Figura 2.49 Selección del Tipo de Almacenamiento………………………………….. 174
Figura 2.50 Seleccionamos la Agregación……………………………………………. 174
Figura 2.51 Estructura del Cubo………………………………………………………. 175
Figura 2.52 Procesando el Cubo………………………………………………………. 175
Figura 2.53 Mostrando Datos…………………………………………………………. 176
Figura 2.54 Elección de la Tabla de Hechos………………………………………….. 176
Figura 2.56 Elección de las Dimensiones……………………………………………... 178
Figura 2.57 Nombre del Cubo……………………………………………………....... 178
Figura 2.58 Estructura del Cubo………………………………………………………. 179
Figura 2.60 Selección del tipo de Almacenamiento………………………………….. 180
Figura 2.61 Mostrando Datos…………………………………………………………. 180
Figura 2.62 Elección de la tabla de Hechos…………………………………………… 181
Figura 2.64 Elección de las Dimensiones…………………………………………….. 182
Figura 2.65 Nombre del Cubo………………………………………………………… 183
x
Figura 2.66 Selección del Tipo de Almacenamiento………………………………….. 183
Figura 2.68 Estructura del Cubo……..………………………………………………... 184
Figura 2.69 Mostrando Datos del Cubo……………………………………………….. 185
Figura 2.70 Modelo Use Case del Negocio…………………………………………… 185
Figura 2.71 Modelo Use Case del Sistema Ejecutivo…………………………………. 186
Figura 2.72 Acceso al Sistema………………………………………………………… 187
Figura 2.73 Pantalla Principal………………………………………………………… 188
Figura 2.74 Hectáreas Preparadas................................................................................... 188
Figura 2.75 Hectáreas Preparadas por Zona................................................................... 189
Figura 2.76 Hectáreas Preparadas por Anexo................................................................. 189
Figura 2.77 Hectáreas Preparadas por Campo................................................................ 190
Figura 2.78 Hectáreas Preparadas por Campo Indices................................................... 191
Figura 2.79 Archivo........................................................................................................ 191
Figura 2.80 Información de la Empresa………………………………………………. 192
Figura 2.81 Configurar Parámetros…………………………………………………… 192
Figura 2.82 Registrar Usuario…………………………………………………………. 193
Figura 2.83 Registro Usuario Nuevo………………………………………………….. 193
Capítulo 3 194
Figura 3.1 Resultado de Satisfacción………………………………………………….. 202
Figura 3.10 Resultado de Satisfacción………………………………………………… 208
Figura 3.14 Resultado de Satisfacción…………………………….…………………... 210
Tabla 3.19 Hipótesis Estadística………………………………………………………. 213
Figura 3.20 Rango de Aceptación y Rechazo…………………………………………. 216
217
xi
RESUMEN
“SISTEMA DE INFORMACIÓN EJECUTIVO DE PRODUCCIÓN

PARA LA GERENCIA DE CAMPO DE LA EMPRESA
AGROINDUSTRIAL CASA GRANDE S.A.A.”
Por:
Br. León Paredes, Vladimir Ulianov.
Br. Portocarrero Regalado, Luis Alberto
El presente proyecto se centra en el desarrollo de un Sistema de Información Ejecutivo

para la Gerencia de Campo de la Empresa Agroindustrial Casa Grande S.A.A, que
permita monitorear de manera rápida y confiable su información para que el nivel
ejecutivo pueda acceder a información oportuna y resumida.
Para la construcción del Sistema de Información Ejecutivo, comenzaremos nuestro

trabajo con el desarrollo de la metodología planteada por Daniel Cohen Karen y
Enrique Asín Lares para la construcción del SIE, así mismo será necesario la
construcción de una Base de Datos Estratégica (DATA MART específicamente) para
consolidar la información estratégica en la cual se emplea la metodología planteada por
Ralph Kimball, y SQL Server para la construcción del DATA MART y dando como
resultado el presente documento titulado: ”SISTEMA DE INFORMACIÓN EJECUTIVO
DE PRODUCCIÓN PARA LA GERENCIA DE CAMPO DE LA EMPRESA
AGROINDUSTRIAL CASA GRANDE S.A.A”.
En conclusión, el SIE construido permite brindar un mejor análisis de los datos que
maneja la Gerencia de Campo. Este análisis es dinámico, permite que los datos sean
accesibles de la forma como el usuario piensa analizarlo.
El SIE, permite a la Gerencia de Campo desarrollar estrategias más efectivas y rentables

en el manejo de su gestión.
xii
ABSTRACT
“EXECUTIVE INFORMATION SYSTEM PRODUCTION AREA

FOR CASA GRANDE S.A.A. AGRARIAN INDUSTRY, FARMING
FIELD MANAGEMENT”
By:
Bs. León Paredes, Vladimir Ulianov.
Bs. Portocarrero Regalado, Luis Alberto
The present project is forused in the development of a Executive Information System

Production Area for Casa Grande S.A.A. Agrarian Industry, Farming Field
Management; that is, the project will allow us to manage in a quick and reliable way its
information so that the executive level persons can access in opportune and summarized
way to the information.
For the building of the Executive Information System, we will begin our work effort
with the methodology developed by Daniel Cohen Karen and Enrique Asín Lares,
likewise it will be necessary the construction of a Strategic database (DATA MARTS
specifically) to consolidate the strategic information in which the methodology is used
outlined by Ralph Kimball, and SQL Server for the construction of the one DATA
MART and giving the present titled document as a result: “EXECUTIVE
INFORMATION SYSTEM PRODUCTION AREA FOR CASA GRANDE S.A.A
AGRARIAN INDUSTRY, FARMING FIELD MANAGEMENT”
In conclusion, the SIE built allows a better analysis of the data that handle the Farming
Field Management. This analysis is dynamic, it allows that the data been accessed in the
way like the user plans to analyze it.
The SIE allows to the Farming Field Management to develop more effective and more
profitable strategies in the handling of its administration.
xiii
INTRODUCCIÓN
La inteligencia y el éxito de las organizaciones dependen fuertemente de las

decisiones tomadas por sus gestores y por sus colaboradores. Esas decisiones demandan
plazos cada vez más cortos y exigen atención redoblada a los ambientes interno y
externo de la empresa. En ese contexto, la Tecnología de la Información (TI) tiene un
papel relevante en el tratamiento, en la disponibilidad y en el acceso de las
informaciones.
En el trepidante mundo de las empresas, tomar la decisión adecuada en el
momento adecuado es de vital importancia para garantizar la supervivencia de la
empresa. Por lo tanto, se plantea un reto importante para los directivos: cómo garantizar
que se está adoptando una buena decisión. La actual globalización económica el ritmo
de cambio acelerado que vive nuestra sociedad, está obligando a las empresas a asumir
un cambio continuo, en una búsqueda constante de mejora de su competitividad. Ante
esto, sólo cabe proponer como única garantía, la de basar las decisiones en un profundo
conocimiento del negocio.
Como respuesta a esta necesidad, aparecen herramientas que facilitan la toma de
decisiones, tal es el caso de las herramientas EIS (Executive Information System). Si las
empresas de hoy no asumen un planteamiento de sus Sistemas Informáticos como
Sistemas de Información, es decir, más allá de un mero software de soporte de
funciones administrativas y no aprovechan el potencial como generadores de ventajas
competitivas desde una perspectiva de apoyo a la toma de decisiones y a la estrategia de
la organización, esto implicará que su posición en el sector será perjudicada en el
tiempo. La responsabilidad del EIS es hacer posible el salto del “dato” a la
“información”. Por supuesto esto no se logra sólo con el Sistema Informático; mucho
más valioso que ese son los analistas y expertos que trabajan en torno a él, dotándole de
contenidos, comentario, ideas, etc.
Es por eso, que, en la actualidad, el auge de los Sistemas Informáticos ha traído
consigo que los Directivos de la Empresa Agroindustrial Casa Grande se encuentren
interesados en explotar la información acumulada de sus Sistemas Informáticos, para
tener elementos que garanticen que se están tomando decisiones acertadas y adecuadas.
xiv
Descripción del Problema:
La Empresa Agroindustrial Casa Grande S.A.A. está ubicado en el Valle

Chicama, al norte de la ciudad de Trujillo departamento de La Libertad. Las oficinas
administrativas se encuentran en el distrito Casa Grande, provincia Ascope,
departamento de La Libertad; y tiene una extensión de 29 384.03 hectáreas en la cual
está dividido en 4 zonas y 20 anexos estratégicamente.
En el Anexo I se muestra la Organización de la Empresa para el cumplimiento
de sus funciones y el logro de sus objetivos.
La Empresa Agroindustrial Casa Grande S.A.A. cuenta con 29 384.03 hectáreas
la cual está dividida estratégicamente con 4 zonas y 20 anexos alejados en un promedio
de 12 Km. con sus respectivos campos, el más cercano es dos Km. y el más alejado 56
Km., a continuación, mostramos las diferentes Zonas con sus respectivos Anexos:
Zona 1: Casa Grande

 Casa Grande.
 Mocan.
 Santa Clara.
 Lache.
 Facalá.
 Capilla.
Zona 2: Roma
 Roma.
 La Constancia.
 Mocollope.
 Cepeda.
 Potrero de los Piscos.
 Pampas de Ventura.
Zona 3: Farías
 Farías.
 Molino Cajanleque.
xv
 Ticmar.
 Veracruz.
 Chuín.
Zona 4: Sausal
 Sausal.
 Chicamita.
 Pampas de Jaguey.
Distancia entre los Anexos y las Oficinas Administrativas que se encuentra en Casa
Grande:
Anexo Distancia (Km)
Mocan 11.5
Santa Clara 6.3
Lache 2.1
Facalá 4.0
Capilla 8.5
Roma 4.8
La Constancia 4.5
Mocollope 4.7
Cepeda 8.8
Potrero de los Piscos 10.0
Pampas de Ventura 14.2
Farías 8.2
Molino Cajanleque 10.8
Ticmar 14.1
Veracruz 18.4
Chuín 10.5
Sausal 20.0
Chicamita 11.0
Pampas de Jaguey 56.0
xvi
Para un mejor entendimiento de las distancias entre Casa Grande y los Anexos
agruparemos a éstos en tres zonas:
1. Zona de Producción de Caña I: Mocan, La Quinta (pertenece a Mocan hay se
encuentra un reservorio)
2. Zona de Producción de Caña II: Casa Grande, Santa Clara, Lache, Facala,
Capilla, Cepeda, Potreros de los Piscos, Pampas de Ventura, Roma, Mocollope,
Farías, Ticmar, Veracruz, Molino Cajanleque, Chuín, y La Constancia.
3. Zona de Producción de Caña III: Sausal, Pampa de Jaguey, y Chicamita
Figura I.1 Distribución de las Zonas de Producción
xvii
Análisis del Problema:
En la Gerencia de Campo se cuenta con información valiosa, las cuales no son

aprovechadas eficientemente puesto que se deben elaborar informes semanales,
mensuales y ocasionalmente en el momento que sean necesario y volverlos a depurar,
de nada nos serviría estos reportes o gráficos si no se sabe qué hacer con ellos. La
gerencia de Campo presenta problemas al no contar con formas de almacenamiento de
datos que cubran los requerimientos de la información y evite la pérdida de tiempo y
esfuerzo, así como brindar un soporte oportuno al momento de tomar decisiones. Hasta
el momento la información solicitada por los Jefes de Campo (Gerente de Campo, Sub.
Gerente de Campo, Jefes de Zonas y Administradores de Anexos) que es hacia donde
estamos orientando el problema, tiene que ser nuevamente procesada en la Gerencia de
Campo, lo que ocasiona un retraso en la toma de decisiones de dicha área, ya que esta
no satisface sus expectativas debido que en varias ocasiones se encontró duplicidad de
datos. Cabe señalar que la importancia de estos informes es que ayudan a los Jefes de
Campo (Gerente de Campo, Sub. Gerente de Campo, Jefes de Zonas y Administradores
de Anexos) a tomar decisiones oportunas y adecuadas. Esto nos indica que la Gerencia
de Campo no cuenta con una base de datos estratégica que pueda ser explotada al
máximo y a la vez ser utilizada por otros sistemas de información permitiendo
visualizar proyecciones gráficas en el momento que se requiera información relevante,
siendo esto necesario para una mejor toma de decisiones.
Es por ello que surge la necesidad de los ejecutivos de contar con un software
que le permita planificar, controlar y disponer de información necesaria para tomar
decisiones oportunas y adecuadas. Por tal motivo se está realizando el estudio para
mejorar esta situación en los Anexos, Jefaturas de Zona y en la Gerencia de Campo, la
cual se logrará con la ayuda de un Sistema de Información Ejecutivo para la Gerencia
de Campo de la Empresa Agroindustrial Casa Grande S.A.A., no se puede negar que la
calidad de las decisiones está en función directa al tipo de información disponible. Estas
decisiones deberán estar soportadas por la información que brinde la Base de Datos
Estratégica (Data Mart).
xviii
En resumen, podemos destacar los siguientes problemas:
 Falta de un software apropiado para los Ejecutivos, que permita mostrar en tiempo
real los principales indicadores de la empresa.
 Retrasos en el procesamiento de la información por parte de cada anexo.
 No se cuenta con estrategias adecuadas, ni se cuenta con un soporte a la toma de
decisiones; por lo tanto, la información se encuentra dispersa y no procesada.
 Falta de información estratégica real, oportuna y adecuada, debido a que la
información que llega a los directivos no son reales, muchas veces son promedios
de los datos.
 Los reportes que se elaboran para los Ejecutivos son muy “fríos” (carecen de
información estratégica real, oportuna y adecuada) lo que genera que los
directivos no tengan una visión real del contexto y sumándose a esto, la falta de
procesamiento oportuno.
 Las operaciones son tediosas, no existe una planificación en el control de la
información a nivel de la gerencia.
El Sistema de Información Ejecutivo de Producción que se desarrollará, estará
orientado hacia el logro de los objetivos de la Gerencia de Campo, permitiéndole contar
con información estratégica, oportuna, libre de errores que monitoree los factores más
relevantes de la Gerencia de Campo, el cual servirá de ayuda en la toma de decisiones a
los Jefes de Campo (Gerente de Campo, Sub. Gerente de Campo, Jefes de Zonas y
Administradores de Anexos).
Formulación del Problema:

¿Cómo se puede contar con información estratégica y oportuna para monitorear
los factores críticos de la gerencia de campo y en un formato adecuado que de apoyo a
una toma de decisiones adecuada?
xix
HIPÓTESIS:
El Sistema de Información Ejecutivo de Producción de la Empresa Agroindustrial
Casa Grande S.A.A. proporcionará información estratégica y oportuna para monitorear
los factores críticos de la gerencia de campo y en un formato adecuado que de apoyo a
una toma de decisiones adecuada.
OBJETIVOS:
Objetivo General:
Desarrollar e implementar un Sistema de Información Ejecutivo de Producción
para la Gerencia de Campo en la Empresa Agroindustrial Casa Grande S.A.A.
Objetivos Específicos:
 Identificar las alternativas de desarrollo para el Sistema de Información
Ejecutivo.
 Determinar las necesidades del ejecutivo mediante técnicas de encuestas y
entrevistas.
 Crear la propuesta de desarrollo para el Sistema de Información Ejecutivo.
 Diseño y modelamiento de la Base de Datos Estratégica de Producción
utilizando le metodología de Ralph Kimball y herramienta SQL Server 2000.
 Construir incrementalmente el SIE con la ayuda del usuario de manera
interactiva mediante la presentación de prototipos a partir de la Base de Datos
Estratégica.
 Realizar las pruebas al Sistema de Información Ejecutivo.
El presente informe de tesis está organizado en cuatro capítulos con lo cual se

pretende facilitar el uso y entendimiento del mismo, dando a continuación una
breve descripción:
xx
Capítulo 1. Fundamento Teórico y Metodología.
En este capítulo nos concentraremos en el Fundamento Teórico y Metodología,
en el que describiremos primero la Metodología empleada para la construcción de la
base de datos estratégica (Data Mart) planteada por Ralph Kimball, usando como
herramienta SQL Server 2000. Luego nos concentraremos en el Fundamento Teórico y
Metodología en la que describiremos la Metodología empleada para la construcción del
Sistema de Información para Ejecutivos (SIE) planteada por Daniel Cohen Karen y
Enrique Asín Lares, para lo cual se hizo una pequeña modificación. (KIMCOLA)
Capítulo 2. Resultados.
En este capítulo se muestra el desarrollo de los pasos enunciados en el Esquema
Metodológico. Mostramos los resultados obtenidos con relación a los objetivos
planteados al inicio de este proyecto.
Capítulo 3. Discusión.
Este capítulo es muy importante ya que se muestra la contratación de la hipótesis
luego de haber sido evaluado por los usuarios.
Capítulo 4. Conclusiones y Recomendaciones.

Aquí se encuentran las conclusiones a las que se llegó después de haber
culminado el proyecto y las recomendaciones resultadas de la experiencia de la misma.
En la parte final de la documentación se encuentran anexos con información adicional,
referidos a los capítulos enunciados.
Con el presente trabajo se espera contribuir a una compresión de los Sistemas de
Información para Ejecutivos y que sirva como consulta para otros trabajos similares que
se realicen más a delante.
LOS AUTORES.
xxi
Sistema de Información Ejecutivo León & Portocarrero
CAPITULO 1
FUNDAMENTO TEÓRICO Y METODOLOGÍA
1.1. FUNDAMENTO TEÓRICO
1.1.1. INTRODUCCION A LOS SISTEMAS DE INFORMACIÓN

En la mayoría de las organizaciones o negocios los planes y metas, así
como el desarrollo de éstas y todos aquellos obstáculos encontrados en la actividad
gerencial de las empresas constituyen información.
En los extensos sistemas empresariales, los gerentes han de recibir
información para poder dirigirlos y controlarlos. Por tanto, la información es la base
de todas las actividades realizadas en una organización, deben desarrollarse
sistemas para producirlos y administrarlos. El objetivo de tales sistemas es
examinar y recuperar los datos provenientes del ambiente, el cual captura los datos
a partir de las transacciones y operaciones efectuadas en la organización para
poderla presentar de una manera exacta y confiable (información) cuando se lo
requiera para que de esta manera pueda tomarse decisiones.
1.1.1.1. Definición de los Sistemas de Información

Un sistema de información es un conjunto de elementos que interactúan
entre sí con el fin de apoyar las actividades de una empresa o negocio. En
un sentido amplio, un sistema de información no necesariamente incluye
equipo electrónico (hardware). Sin embargo, en la práctica se utiliza como
sinónimo de “sistema de información computarizado”.
[COH-00]
Un sistema de información realiza cuatro actividades básicas: entrada,
almacenamiento, procesamiento y salida.
[COH-00]
22
1.1.1.2. Tipos de información que suministra un sistema de información

Los sistemas de información se han dividido de acuerdo al siguiente
esquema:
ESTRATÉGICO
TÁCTICO
TECNICO OPERATIVO
INTER-INSTITUCIONAL
Figura 1.1 Categoría de los Sistemas de Información

Fuente: [REY02]
Sistemas Estratégicos, orientados a soportar la toma de decisiones, facilitan la

labor de la dirección, proporcionándole un soporte básico, en forma de mejor
información para la toma de decisiones. Se caracterizan porque son sistemas sin
carga periódica de trabajo, es decir, su utilización no es predecible, al contrario de
los casos anteriores, cuya utilización es periódica. Destacan entre estos sistemas: los
Sistemas de Información Gerencial (MIS), Sistemas de Información Ejecutivos
(EIS), Sistemas de Información Georeferencial (GIS), Sistemas de Simulación de
Negocios (BIS y que en la práctica son sistemas expertos o de Inteligencia
Artificial- AI).
Sistemas Tácticos, diseñados para soportar las actividades de coordinación de

actividades y manejo de documentación, definidos para facilitar consultas sobre
información almacenada en el sistema, proporcionar informes y, en resumen,
facilitar la gestión independiente de la información por parte de los niveles
intermedios de la organización. Destacan entre ellos: los Sistemas Ofimáticos (OA),
Sistemas de Transmisión de Mensajería (E-mail y Fax Server), coordinación y
23
control de tareas (Work Flow) y tratamiento de documentos (Imagen, trámite y

bases de datos documentarios).
Sistemas Táctico-Operativos, que cubren el núcleo de operaciones tradicionales de

captura masiva de datos (Data Entry) y servicios básicos de tratamientos de datos,
con tares predefinidas (Contabilidad, facturación, almacén, presupuesto, personal y
otros sistemas administrativos). Estos sistemas están evolucionando con la irrupción
de censores, autómatas, sistemas multimedia, bases de datos relacionales más
avanzadas y data warehousing.
Sistemas Interinstitucionales, este último nivel de sistemas de información recién

está surgiendo, es consecuencia del desarrollo organizacional orientado a un
mercado de carácter global, el cual obliga a pensar e implementar estructuras de
comunicación más estrechas entre la organización y el mercado (Empresa
Extendida, Organización Inteligente e Integración Organizacional), todo esto a
partir de la generalización de las redes informáticas de alcance nacional y global
(INTERNET), que se convierten en vínculo de comunicación entre la organización
y el mercado, no importa donde esté la organización (INTRANET), el mercado de
la institución (EXTRANET) y el mercado (RED GLOBAL).
Sin embargo, la tecnología data warehousing basa sus conceptos y diferencias
entre dos tipos fundamentales de sistemas de información en todas las
organizaciones: los sistemas técnico-operacionales y los sistemas de soporte de
decisiones. Este último es la base de un Data Warehouse.
[REY02]
1.1.1.3. Tipos De Sistemas De Información
Sistemas Técnico-Operacionales
Como su nombre indica, son los sistemas que ayudan a manejar la
empresa con sus operaciones cotidianas. Éstos son los sistemas que
operan sobre el “backbone” (columna vertebral) de cualquier
empresa o institución, entre las que se tiene sistemas de ingreso de
órdenes, inventario, fabricación, planilla y contabilidad, entre otros.
Debido a su volumen e importancia en la organización, los sistemas
24
operacionales siempre han sido las primeras partes de la empresa a

ser computarizados. A través de los años estos sistemas
operacionales se han extendido, revisado, mejorado y mantenido al
punto que hoy, ellos son completamente integrados en la
organización. Desde luego, la mayoría de las organizaciones grandes
de todo el mundo, actualmente no podrían operar sin sus sistemas
operacionales y los datos que estos sistemas mantienen.
[REY02]
De Gestión y Administración
Proporcionan información necesaria para controlar la evolución de la
organización, el cumplimiento de los objetivos operativos y la
situación económico-financiera. En un principio, esta información se
suministraba solamente por medio de informes, pero en la actualidad
puede consultarse directamente en el ordenador, si está almacenada
correctamente. Un ejemplo de este tipo puede ser un Sistema de
Gestión de Personal.
Para la Dirección
Llamados también “EIS” por las siglas del término Executive
Information Systems, son un paso más en la evolución de los
anteriores, ya que relacionan en la misma base de datos toda la
información significativa de la evolución de la organización, su
distribución y su entorno de operaciones. Estos sistemas,
preferentemente gráficos, permiten acceder a la información tanto
vertical como horizontalmente. El término “vertical” se refiere a un
acceso jerárquico de la información, mientras el término “horizontal”
hace referencia a los análisis comparativos y es aquí donde entra en
juego la información del entorno.
[WEB2-92]
25
Sistemas De Soporte De Decisiones (DSS)

Por otra parte, hay otras funciones dentro de la empresa que tienen
que ver con el planeamiento, previsión y administración de la
organización. Estas funciones son también críticas para la
supervivencia de la organización, especialmente en nuestro mundo de
rápidos cambios.
Las funciones como “planificación de marketing”, “planeamiento
de ingeniería” y “análisis financiero”, requieren además, de
sistemas de información que los soporte. Pero estas funciones son
diferentes de las operacionales y los tipos de sistemas y la
información requerida son también diferentes. Las funciones basadas
en el conocimiento son los sistemas de soporte de decisiones.
Estos sistemas están relacionados con el análisis de datos y la toma
de decisiones, frecuentemente, decisiones importantes sobre cómo
operará la empresa, ahora y en el futuro. Estos sistemas no sólo
tienen un enfoque diferente al de los operacionales, sino que, por lo
general, tienen un alcance diferente.
Mientras las necesidades de los datos operacionales se enfocan
normalmente hacia una sola área, los datos para el soporte de
decisiones, con frecuencia, toma un número de áreas diferentes y
necesita cantidades grandes de datos operacionales relacionadas.
Son estos sistemas sobre los que se basa la tecnología Data Mart y
Data Warehouse.
[REY02]
26
Figura 1.2 Sistema de Soporte de Decisiones (DSS)

Fuente: [ART02]
1.1.2. SISTEMAS DE INFORMACIÓN EJECUTIVO

El acceso rápido para los ejecutivos a los hechos y cifras sobre las
instalaciones es más fácil e intuitivo que nunca utilizando los Sistemas de
Información para Ejecutivos (Executive Information Systems) - EIS. Estos
sistemas ofrecen una serie de Interfaces Visuales con el Usuario (VUIs -
Visual User InterfacesTM) para navegar en el ambiente o en los sistemas de
Enterprise Resource Planning ERP (Planeación de Recursos Empresariales).
Éstos se pueden configurar para adaptarse a las necesidades y preferencias de
cada usuario. Los SIE permiten incluso al más casual de los usuarios
convertirse en un poderoso consumidor de conocimiento (FM
KnowledgeTM) en cuestión de minutos. El SIE (SISTEMAS DE
INFORMACIÓN EJECUTIVO) más que un sistema, es un nuevo concepto
de administración en una Organización.
Un SIE a nivel ejecutivo no es necesariamente un extracto de los sistemas
Aplicativos.
[WEB - 1999]
27
1.1.2.1. ¿QUÉ ES UN SIE?

Según Daniel Cohen Karen y Enrique Asín Lares, un
Sistema de Información para Ejecutivos se define, como un
sistema computacional que provee al ejecutivo acceso fácil a
información interna y externa al negocio con el fin de dar
seguimiento a los factores críticos del éxito. De esta definición se
desprende el hecho de que los SIE se enfocan primordialmente a
proporcionar información de la situación actual de la compañía y
dejan en un plano secundario la visualización o proyección de esta
información en escenarios futuros. Este último enfoque es provisto
por los DSS.
[COH-00]
"EIS se refiere a cualquier sistema de software que muestre
información ejecutiva de las diferentes áreas del negocio en un solo
sistema, facilitando el monitoreo de la empresa."
"Un EIS es un sistema de información que permite a los
ejecutivos acceso rápido y efectivo a información compartida,
crítica para el negocio, utilizando interfaces gráficas." [González,
Marisol].
Con anterioridad a la aparición de los SIE, la información que
le llegaba a un ejecutivo de la alta dirección ostentaba un marcado
carácter estructurado y en formatos previamente establecidos, sin
embargo, los Sistemas de Información para la Dirección brindan la
posibilidad de navegar entre los datos y descender a través de los
sucesivos niveles de información en la dirección que se desee. El
rumbo se establecerá en consonancia con el contenido de la
información que sea encontrada hasta que se averigüen las causas
de los problemas. Al fijar el grado de agregación que se desea que
tenga la información, se contrarresta el excesivo énfasis realizado
en el análisis individualizado por funciones, centros o
departamentos, con el que se ofrece una imagen fragmentada de la
actividad empresarial. Este tipo de aplicativo no surge por
28
generación espontánea, su llegada obedece a una serie de causas,

las cuáles comentaremos someramente, que convergieron con su
aparición.
A pesar de la posterior aparición de los Sistemas de Soporte a
la Decisión o DSS, los directivos continuaban recibiendo
información con un carácter globalizador muy limitado,
eminentemente de carácter financiera, con una gran orientación
hacia el corto plazo y, con frecuencia, referida a periodos de tiempo
atrasados. Como consecuencia de lo expuesto, estas herramientas
MIS y DSS proporcionaban una respuesta parcial y poco ágil en
relación a las necesidades de información que requiere la toma de
decisiones estratégicas. Este escenario propició la aparición de los
SIE, los cuáles surgieron con el fin de suministrar a los ejecutivos
información MIS integrada, combinada y unificada. A pesar de que
los directivos ya demandaban Sistemas de Información para la
Dirección a principios de los años setenta, tuvieron que esperar
hasta la década siguiente para disponer de ellos.
[ART02]
1.1.2.2. Lo que debe contener un SIE
Si consideramos que una pantalla de información valiosa es un
SIE, prácticamente cualquier hoja de cálculo e incluso un reporte
de producción podría serlo. Para ser considerado un SIE, un
sistema debe reunir una serie de características adicionales a las
que por defecto debe contener al formar parte de la Tecnología de
Business Intelligence, es decir, brindar información y que sirva de
apoyo a la toma de decisiones.
Un típico SIE cuenta con funciones que le permiten al usuario
notar rápidamente los errores y los valores destacables de la
información.
[ART02]
29
Figura 1.3 Lo que debe contener un SIE

Fuente: [ART02]
 Interfaz gráfica fácil de usar y ver

La heterogeneidad en cuanto a la formación académica que un
usuario final posee, es enorme. Puestos claves pueden ser
asumidos por Economistas, Administradores, Contadores,
Informáticos, Actuarios, Ingenieros Industriales, etc., el único
elemento común es un mínimo de conocimientos necesarios
para manejar una herramienta como Excel. Sin embargo, lo que
no está bien definido es el límite superior de sus conocimientos.
Un SIE está diseñado para un usuario final que no forzosamente
domina herramientas computacionales complejas, e
independientemente de que las domine, no debe invertir una
parte importante de su tiempo en conocer y, posteriormente,
utilizar herramientas complicadas. Bajo esta filosofía es que se
menciona como una característica de los SIE el que posean
interfaces gráficas sencillas, que tengan una curva de
aprendizaje corta y, además, deberán ser vistosas e intuitivas
para facilitar la labor de monitoreo del tomador de decisiones.
La idea es que se interactúe con el sistema el menor tiempo
30
posible, de hecho, solo cuando alguna propiedad de una métrica

indique que es necesario conocer el porqué de un valor.
 Alarmas o semáforos
Un típico SIE cuenta con funciones que le permiten al usuario
notar rápidamente los errores y los valores destacables de la
información. Es una de las características principales, ya que las
propiedades que le son asignadas a los valores son las que
permiten verdaderamente "monitorear" la información, de otro
modo el ver datos planos provocaría que el usuario investigue
cada uno de los valores y, posteriormente, los compare contra
identificadores antes de poder determinar si son "buenos" o
"malos". La tendencia es hacia interactuar cada vez menos con
los sistemas y para ellos, las alarmas se vuelven indispensables,
ya que disparan indicadores para que el ejecutivo solo ponga
atención donde se han sobrepasado ciertos rangos de tolerancia.
Estos indicadores pueden ir desde simples colores de letra y
fondos, hasta el envío de correos electrónicos o mensajes por
radiolocalizador.
 Tableros de Control
Surgiendo en Francia con el nombre de Tableau de Bord, el
Tablero de Control es una herramienta que en un principio
utilizaba indicadores financieros para permitir desarrollar
diferentes procesos de negocio. Su especialización ha tomado el
camino hacia el CMI (Cuadro de Mando Integral), que ya es una
poderosa herramienta para dirección, que no solo utiliza
indicadores financieros, sino también los no financieros para
dirigir de forma proactiva a la empresa en la consecución de
objetivos a mediano y largo plazo. El Tablero de Control no
forzosamente implica una metodología de trabajo, en ese sentido
es algo más sencillo que puede llegar a un nivel de
31
especialización tan amplio como uno lo quiera, por ejemplo,

empleando la metodología del Balanced Scorecard para
implementar un sistema de monitoreo del estado de salud
corporativa. Un Tablero de Control es una utilería en la cual el
usuario puede monitorear con indicadores de cualquier tipo a su
empresa o el área que tenga a su cargo. Diversos componentes le
apoyan en esa actividad, pues cada indicador puede asociarse a
un tipo de control específico. Con el tablero de control se
pretende destacar los principales aspectos a monitorear, ya sea
para el control o para la comunicación. El fin último es tener la
información necesaria para apoyar una decisión en la menor
cantidad de pantallas.
Hay que considerar también que, por la misma evolución de los
SIE, la función de controlar con un tablero sigue siendo la más
común, pero no es la única, en algunos casos se comienza a
sustituir la palabra Control por Comunicación; no debe
sorprendernos si entendemos el motivo.
 Administración De Una Sola Página

De la mano del Tablero de Control, la Administración de una
Sola Página significa colocar el mayor número posible de
indicadores destacables de la empresa en el menor número
posible de páginas, además, permitir la navegación hacia otras
páginas con más información, ya que, definitivamente es
prácticamente imposible colocar toda la información valiosa en
un solo lugar.
 Integración De Información Proveniente De Los Cubos

El usuario tiene muchas veces la necesidad de tener información
proveniente de múltiples sistemas o bases de datos. De hecho,
para tomar una decisión estratégica es necesario poseer
información de toda la empresa, no solo de una parte de ella. Un
32
SIE debe permitir integrar información de cualquier aplicación y

presentársela al usuario final de una forma transparente para él.
Esto es la base para no moverse entre aplicaciones, al integrar la
información de múltiples fuentes de información es posible la
Administración de una Sola Página en un Tablero de Control, el
no hacerlo representa una limitante al usuario con la
consecuencia de moverse hacia otras pantallas e, incluso, hacia
otras aplicaciones con información dispersa.
[ART02]
1.1.2.3. CARACTERÍSTICAS DE UN SIE

Las principales características de los sistemas de información
para ejecutivos (SIE) son las siguientes:
 Están diseñados para cubrir las necesidades específicas y
particulares de la alta administración de la empresa.
 Extraen, filtran, comprimen y dan seguimiento a
información crítica del negocio.
 Implica que los ejecutivos puedan interactuar en forma
directa con el sistema sin el apoyo o auxilio de
intermediarios.
 Es un sistema desarrollado con altos estándares en sus
interfaces hombre-máquina, caracterizado por gráficas de
alta calidad, información tabular y en forma de texto.
 Pueden accesar información que se encuentra en línea,
extrayéndose en forma directa de las bases de datos de la
organización.
 El sistema está soportado por elementos especializados de
hardware, tales como monitores o videos de alta resolución
y sensibles al tacto, ratón e impresoras con tecnología
avanzada.
[GIL - 97]
33
1.1.2.4. EL PROCESO DE DESARROLLO DE UN EIS

El proceso de desarrollo de un EIS tiene características que lo
hacen único. En primera instancia, porque es el primer sistema
que se desarrolla en la empresa dirigido al ejecutivo; quien es el
usuario de este sistema. En segundo lugar, las técnicas utilizadas
para el análisis y desarrollo de los tradicionales Sistemas
Transaccionales no necesariamente funcionan en un 100% de
manera similar durante el desarrollo de un EIS.
[GIL - 97]
1.1.2.5. IMPLANTACIÓN EXITOSA DE UN SIE

Para que un ejecutivo utilice un SIE, debe implantarse
considerando los siguientes factores importantes que se sugiere
para asegurar una implantación con éxito del SIE:
 Ejecutivo comprometido e informado con el proyecto.
 Socio operativo.
 Personal idóneo en el departamento de informática.
 Tecnología apropiada.
 Administración de los datos.
 Relación clara con los objetivos del negocio.
 Manejo de la resistencia al cambio.
 Administración adecuada de la evolución y expansión del
sistema.
[GIL - 97]
1.1.2.6. FACTORES DEL ÉXITO DE UN SIE
Para que un SIE tenga éxito es necesario que cumpla con los
siguientes factores:
 QUE SE VEA BIEN. Para que un SIE se vea bien debe de

estar orientado al uso gráfico de las pantallas, lo cual habilita a los
ejecutivos a acceder la información relevante sin entrenamiento
previo.
34
 QUE SEA RELEVANTE. Un SIE debe dar a los ejecutivos

acceso a los datos que son importantes para la organización y
que se han identificado como críticos para el éxito de la
empresa.
 QUE SEA RÁPIDO. Se necesita tiempos de respuestas

cortos, de lo contrario los ejecutivos dirán que están
perdiendo su tiempo. Por lo general un SIE distribuye
información variada o agregada, la cual debe proporcionarse
más rápido que cualquier otra aplicación de sistemas.
[GIL - 97]
 QUE LA INFORMACIÓN ESTÉ DISPONIBLE Y

ACTUALIZADA. Un SIE debe proporcionar a los ejecutivos
la información en el momento oportuno, es decir, cuando
ellos lo requieran. Además, la información que se presente al
ejecutivo debe estar actualizada para que tenga validez, ya
que no sirve utilizar información que no esté vigente.
[COH-00]
1.1.3. INDICADORES DE GESTIÓN

Un indicador de gestión es una variable cuantitativa cuya finalidad es
entregar información acerca del cumplimiento de una meta.
Es un instrumento que permite la medición y, por lo tanto, su calidad y su
utilidad estará determinada principalmente por la claridad y relevancia de la
meta que tiene asociada.
[Web4 - 02]
Metas, son la expresión concreta del plan de gestión para el logro de los
objetivos estratégicos de la Unidad Ejecutora. Pueden ser de producción
(toman en cuenta los productos y la población objetivo atendida) o de
gestión (se proponen mejorar los procesos).
[Web4 -02]
35
1.1.4. DATA MART

Data Mart es un subconjunto de una bodega de datos para un propósito
específico. Se puede ver como una vista de la bodega de datos orientada a
un aspecto de un negocio, con un tiempo de vida reducido. Su función es
apoyar a otros sistemas para la toma de decisiones. Un Data Mart debe de
permitir queries de muchas formas usando herramientas OLAP.
Un Data Mart es simplemente un pequeño Data Warehouse. Usualmente la
data en un Data Mart es un subconjunto de la data que se encuentra en un
amplio Data Warehouse. Un Data Mart es específico para un departamento
en particular.
[MIC-98]
Es un subconjunto lógico del Data Warehouse. Un Data Warehouse está

hecho por la unión de varios Data Marts. El Data Mart sólo constituye
una parte particular de una empresa.
[KIM-98]
El Data Mart es una parte de un Data Warehouse para un uso

departamental. Almacén de datos históricos relativos a un departamento
de una organización, utilizado por una herramienta OLAP para procesar
información, elaborar informes y vistas.
[DEL-02]
Un Data Mart es parte de un Data Warehouse. Es usado para temas
particulares o actividades específicas de negocios. Puede ser una solución
táctica.
[MEN-02]
Beneficios claves del servicio de creación de Data Marts
1. Transforma datos básicos en Data Marts orientados al contexto,

optimizados para el análisis, asegurando que los datos sean accesibles
de la forma en que los usuarios del negocio piensan (según fecha,
localización, producto, cliente, ventas, etc.).
36
2. Proporciona dimensionalidad, permitiendo combinar múltiples

entradas con una jerarquía reutilizable y extensible.
3. Escala a través de la empresa, desde soluciones para departamentos
hasta plataformas empresariales, soportando todas las mayores bases
de datos.
4. Proporciona un movimiento de datos consistente y transformación
para crear, cargar y desplegar modelos e informes de negocio.
Las bases de datos de cada empresa contienen información que sirve
para atender mejor a los clientes, reducir costes y mejorar ventas. Pero
realmente hay que realizar una verdadera minería para explotarla. La
progresión exponencial de las exigencias del usuario avanzado para
explotar esta información dio origen a varias y nuevas tecnologías
entre ellas Data Mart (Ver Anexo B).
1.1.5. DATA WAREHOUSE

Un Data Warehouse o Depósito de Datos es una colección de datos
orientado a temas, integrado, no volátil, de tiempo variante, que se usa
para el soporte del proceso de toma de decisiones gerenciales.
Un Data Warehouse es un conjunto de herramientas. Es una colección
de datos para asistir en el soporte de decisiones y análisis.
[MIC-98]
Un Data Warehouse es una fuente o almacén de consultas de data en la
empresa. El Data Warehouse es nada más que la unión del total de Data
Mart constituidos.
[KIM-98]
Un Data Warehouse es una base de datos que contiene: datos
empresariales, integra colección de datos históricos, datos dirigidos al
usuario, datos consolidados y consistentes y datos estructurados para
distribución y consulta.
[MEN-02]
Un Data Warehouse es un ingrediente esencial en el conjunto de
soluciones para el soporte de decisiones en una empresa. [HAR-96]
37
Un Data Warehouse es un almacén de datos integrado en una

estructura consistente, organizado por temas, con valores históricos e
información no volátil.
[MAP-02]
Data Warehouse o almacén de datos, es una colección de información

corporativa, derivada directamente de los sistemas operacionales (DB) y
de algunos datos externos. Su propósito es soportar la toma de decisiones
en un negocio.
[MOR-99]
El Data Warehouse impone un procesamiento y pensamiento distinto,

la cual se sustenta por un modelamiento de base de datos propio,
conocido como Modelamiento Multidimensional el cual busca ofrecer al
usuario una visión respecto de la operación del negocio.
1.1.5.1. OPERACIONES EN UN DATA WAREHOUSE

En la figura se muestra algunos de los tipos de operaciones que se
efectúan dentro de un ambiente data warehousing
Figura 1.4 Tipos de operaciones en un Data Warehouse

Fuente: [REY02]
38
a) Sistemas Operacionales
Los sistemas administrados por los sistemas de aplicación
operacionales son la fuente principal de datos para el Data
Warehouse.
Las bases de datos operacionales se organizan como archivos
indexados (UFAS; VSAM), bases de datos de redes/jerárquicas
(I-D-S/II, IMS, IDMS) o sistemas de bases de datos relacionales
(DB2, Oracle, Informix, etc.). Según las encuestas.
Aproximadamente del 70% a 80% de las bases de datos de las
empresas se organizan usando DBMSs no relacional.
[REY02]
b) Extracción, Transformación y Carga de Datos
Se requieren herramientas de gestión de datos para extraer datos
desde bases de datos y/o archivos operacionales, luego es
necesario manipular o transformar los datos antes de cargar los
resultados en el Data Warehouse.
Tomar los datos desde varias bases de datos operacionales y
transformarlos en datos requeridos para el depósito, se refiere a la
transformación o a la integración de datos. Las bases de datos
operacionales, diseñadas para el soporte de varias aplicaciones de
producción, frecuentemente difieren en el formato.
Los mismos elementos de datos, si son usados por aplicaciones
diferentes o administrados por diferentes softwares DBMS,
pueden definirse al usar nombres de elementos inconsistentes, que
tienen formatos inconsistentes y/o ser codificados de manera
diferente. Todas estas inconsistencias deben resolverse antes que
los elementos de datos sean almacenados en el Data Warehouse.
[REY02]
c) Metadata
Otro paso necesario es crear la Metadata. La Metadata (es decir,
datos a cerca de datos) describe los contenidos del Data
Warehouse. La metadata consiste de definiciones de los
39
elementos de datos en el depósito, sistemas(s) del (os)

elemento(s) fuente. Como la data, se integra y transforma antes de
ser almacenada en información similar.
[REY02]
d) Acceso de Usuario final
Los usuarios accesan al Data Warehouse por medio de
herramientas de productividad basadas en GUI (Graphical User
Interface – Interfaz Gráfica de Usuario). Pueden proveerse a los
usuarios del Data Warehouse muchos de estos tipos de
herramientas.
Estos pueden incluir software de consultas, generadores de
reportes, procesamiento analítico en línea, herramientas
data/visual mining, etc., dependiendo de los tipos de usuarios y
sus requerimientos particulares. Sin embargo, una sola
herramienta no satisface todos los requerimientos, por lo que es
necesaria la integración de una serie de herramientas.
[REY02]
e) Plataforma del Data Warehouse

La plataforma para el Data Warehouse es casi siempre un servidor
de base de datos relacional. Cuando se manipulan volúmenes muy
grandes de datos puede requerirse una configuración en bloque de
servidores UNIX con multiprocesador simétrico (SMP) o un
servidor con procesador paralelo masivo (MPP) especializado.
Los extractos de la data integrada/transformada se cargan en el
Data Warehouse. Uno de los más populares RDBMSs disponibles
para Data Warehousing sobre la plataforma UNIX (SMP y MPP)
generalmente es Teradata. La elección de la plataforma es crítica.
El depósito crecerá y hay que comprender los requerimientos
después de 3 o 5 años.
Muchas de las organizaciones quieran o no escogen una
plataforma por diversas razones: el Sistema X es nuestro sistema
40
elegido o el Sistema Y está ya disponible sobre un sistema UNIX

que nosotros ya tenemos. Uno de los errores más grandes que las
organizaciones cometen al seleccionar la plataforma, es que ellos
presumen que el sistema (Hardware y/o DBMS) escalará con los
datos. El sistema de depósito ejecuta las consultas que se pasa a
los datos por el software de acceso a los datos del usuario.
Aunque un usuario visualiza las consultas desde el punto de vista
de un GUI, las consultas típicamente se formulan como pedidos
SQL, porque SQL es un lenguaje universal y el estándar es de
hecho para el acceso a datos.
[REY02]
f) Datos Externos
Dependiendo de la aplicación, el alcance del Data Warehouse
puede extenderse por la capacidad de acceder a la data externa.
Por ejemplo: los datos accesibles por medio de servicios de
computadora en línea (tales como CompuServe y América On
Line) y/o vía Internet, pueden estar disponibles a los usuarios del
Data Warehouse.
[REY02]
1.1.5.2. MODELAMIENTO MULTIDIMENSIONAL

Se conoce como Modelamiento Multidimensional a la técnica del
diseño lógico usado por el Data Warehouse, el cual es diferente del
modelo Entidad – Relación. El Modelamiento Multidimensional busca
presentar los datos en un marco de trabajo estándar que es intuitivo y
permite acceder al alto desempeño.
[KIM98]
La estructura básica de un Data Warehouse para el Modelo

Multidimensional está definida por dos elementos: Esquemas y Tablas.
(Ver Anexo C).
41
1.1.5.3. MODELADO DEL DATA WAREHOUSE

Existen muchas técnicas para modelar un Data Warehouse. Las técnicas
más populares son:
a) Esquema Estrella
El esquema estrella es un paradigma de modelado que tiene un
solo objeto en medio conectado con varios objetos de manera
radial. El esquema estrella refleja la visión del usuario final de
una consulta empresarial: hechos tales como ventas,
compensación, pago y facturas se clasifican por una o más
dimensiones. El objeto en el centro de la estrella se denomina
Tabla de Hechos y los objetos conectados a ella se denominan
Tablas de Dimensión.
[HAR96]
b) Esquema Copo de Nieve
El esquema copo de nieve es una extensión del esquema
estrella en donde cada uno de los puntos de la estrella se divide
en más puntos. En esta forma de esquema, las tablas de
dimensión del esquema estrella contienen más normas. Las
ventajas que proporciona el esquema de copo de nieve son
mejorar el desempeño de consultas debido a un mínimo
almacenamiento en disco para los datos y mejorar el
desempeño mediante la unión de tablas más pequeñas con
normas. Así mismo el esquema copo de nieve incrementa la
flexibilidad de las aplicaciones debido a la aplicación de
normas y por lo tanto disminuye la granularidad de las
dimensiones.
[HAR96]
1.1.6. BASE DE DATOS MULTIDIMENSIONAL

Base de datos de estructura basada en dimensiones orientada a consultas
complejas y alto rendimiento. Puede utilizar un SGBDR en estrella (Base de
42
datos Multidimensional a nivel lógico) o SGBDM (Base de dalos

Multidimensional a niveles lógico y físico o Base de datos Multidimensional
Pura).
[DEL02]
Las bases de datos multidimensionales están compuestas por dimensiones que
son atributos estructurales de un cubo, organizadas con jerarquías de
categorías que describen la data en tablas. Estas categorías típicamente
describen un conjunto de miembros similares sobre los cuales los usuarios
quieren basar sus análisis. Por ejemplo, la dimensión geografía podría incluir
niveles por Países, Regiones, Estados y Ciudades.
[COR02]
Una base de datos multidimensional permite almacenar los datos de tal forma
que se optimiza el acceso a la información cuando nos encontramos ante
necesidades no previstas en el momento de la creación de la base de datos. La
representación habitual de una base de datos multidimensional es un cubo en
3D. No obstante, una base multidimensional puede generar muchas más
dimensiones, incluso llegar a quince o veinte.
[BUS02]
1.1.7. SQL SERVER PARA EL DATA MART

Entre las importantes áreas de liderazgo e innovación de Microsoft SQL
Server cabe citar:
 Primera base de datos que se amplía desde los portátiles a la empresa
mediante el mismo código base y que ofrece una compatibilidad del
código del 100%.
 Primera base de datos que soporta la configuración automática y la auto
optimización.
 Primera base de datos con un servidor OLAP integrado.
 Primera base de datos con los servicios de transformación de datos
(Data Transformation Service, DTS) integrados.
43
El marco de almacenamiento de datos Microsoft (Data Warehousing

Framework) constituye el primer planteamiento de amplia cobertura para la
resolución de los problemas que plantea la utilización de metadatos.
1.1.8. DATA TRANSFORMATION SERVICE (DTS)

Los Servicios de Transformación de Datos (DTS) de Microsoft® SQL
Server™ 2000 proporcionan las herramientas necesarias para extraer,
transformar y consolidar los datos de fuentes dispares a destinos únicos o
múltiples. Dichas herramientas de DTS permiten crear soluciones para el
movimiento de datos personalizadas que se ajustan a las necesidades
especiales de una organización, tal como ilustran los siguientes casos:
El almacén de datos contiene datos históricos sobre las operaciones
empresariales, datos que se resumen gracias a los servicios de análisis de
Microsoft SQL Server 2000. Se hace preciso actualizar el almacén de datos
cada noche desde la base de datos de procesamiento de transacciones en línea
(OLTP), sistema éste que se encuentra funcionando 24 horas al día, por lo
que el rendimiento, en este caso concreto, es fundamental.
El DTS permite importar, exportar y transformar data desde múltiples
orígenes de datos. Al usar DTS, se puede: copar el esquema de la BD entre
DBMS, crear y personalizar transformación de objetos y construir Data
Warehouse y Data Mart. (Ver Anexo E). [MEN-02]
1.1.9. PROCESAMIENTO ANALÍTICO EN LÍNEA (OLAP)

En respuesta a los problemas asociados al realizar análisis de datos sobre
base de datos del tipo OLTP surge una técnica, ofreciendo tipos de
arquitectura útil para la base de datos multidimensional. (Ver Anexo D).
1.1.10. CUBOS OLAP

Un cubo es una multidimensional estructura que almacena los datos de tu
sistema OLAP. Multidimensional significa que los cubos te permiten mirar
tu data en varios caminos o de varias maneras. [MIC98]
El cubo es un elemento clave en el proceso analítico en línea OLAP y
consta de medidas (o datos cuantitativos como ventas o costos) y
44
dimensiones. La modelación multidimensional de datos es una forma de

facilitar el análisis empresarial en línea y de mejorar el rendimiento de las
consultas.
El administrador de OLAP le permitirá convertir los datos almacenados en
bases de datos relacionales en información empresarial significativa y fácil
de explorar con sólo crear un cubo de datos. Los conceptos y terminología
asociados con los cubos se describen en las siguientes pantallas.
[TUT98]
Figura 1.5 Cubo OLAP

Fuente: [FGCP-01]
ESQUEMAS RELACIONALES Y CUBOS
La manera más común de administrar datos relacionales para su empleo

multidimensional es un esquema de estrella. Un esquema de estrella
consiste en una única tabla de hechos que se combina con varias tablas
de dimensiones. La tabla de hechos contiene los datos numéricos que se
corresponden con las medidas de un cubo. Las columnas de la tabla de
dimensiones, tal como implica su nombre, asignan los niveles
jerárquicos de una dimensión.
[TUT98]
45
Figura 1.6 Esquemas Relacionales y Cubos

Fuente: [TUT98]
DIMENSIONES DE UN CUBO
Las dimensiones de un cubo representan distintas categorías para
analizar datos empresariales. Categorías tales como fecha, geografía o
línea de productos son dimensiones típicas de cubos.
Nota: los cubos no están limitados a tres dimensiones. Pueden
contener hasta 64 dimensiones.
[TUT98]
DIMENSIONES Y JERARQUIAS
Las dimensiones se suelen organizar en jerarquías de información que
se asignan a columnas en una base de datos relacional. Las jerarquías
de dimensiones están agrupadas en niveles que constan de los
miembros de una dimensión. Podrá unir los niveles de una dimensión
para formar los valores de los que constará el siguiente nivel superior:
Por ejemplo, en una dimensión temporal, los días se unen en meses y
los meses forman trimestres.
[TUT98]
46
Figura 1.7 Jerarquía de los Cubos OLAP

Fuente: [TUT-98]
MEDIDAS DE UN CUBO
Las medidas son los valores cuantitativos contenidos en la base de
datos que desea analizar. Las medidas típicas son ventas, costos y
datos presupuestarios. Las medidas se analizan contra las distintas
categorías de dimensiones de un cubo. Por ejemplo, tal vez desee
analizar datos de ventas y de presupuestos (sus medidas) para un
determinado producto (una dimensión) correspondientes a varios
países (niveles específicos de una dimensión geográfica) durante dos
años concretos (niveles de una dimensión temporal).
[TUT98]
Figura 1.8 Medidas de los Cubos OLAP

Fuente: [TUT98]
47
1.2. METODOLOGÍAS
1.2.1. METODOLOGIA PARA EL DESARROLLO DE UN SISTEMAS

DE INFORMACIÓN PARA EJECUTIVOS
Metodología de Cohen y Karen [COH 00]
Identificación de las alternativas para el desarrollo del sistema.
Creación de la propuesta.
Determinación de las necesidades del

Ejecutivo.
Creación del sistema y presentación de un

prototipo.
Figura 1.9 Método para el Desarrollo de SIE basado en Prototipos.

Fuente: [COH 00]
48
1.2.1.1. Identificación de las Alternativas para el Desarrollo del

Sistema.
Existen diferentes alternativas para el desarrollo de un SIE.
Antes de crear la propuesta para el desarrollo del sistema debe
elegirse la alternativa que se desee. A continuación, se
mencionan algunas alternativas que existen para su desarrollo:
 Desarrollar el sistema de manera interna a partir de cero. Esto

significa que el departamento de sistemas de información
asignará a un equipo de trabajo para el desarrollo del sistema.
 Otra alternativa es hacer modificaciones a los sistemas
actuales con el fin de cubrir los requisitos del ejecutivo.
 Desarrollar el sistema a partir de cero con la ayuda de
desarrolladores externos con experiencia en SIE.
[COH 00]
1.2.1.2. Creación de la Propuesta.

[COH 00]
En este paso debe escribirse o elaborarse una presentación de
la propuesta del SIE. La creación de la propuesta ayudará a
tener un apoyo más sólido para el desarrollo del sistema y a
minimizar la resistencia por parte de los ejecutivos. Además,
puede contribuir a que la administración acepte el proyecto.
Las principales razones que existen para presentar de manera
formal una propuesta de un SIE son:
 Claro entendimiento con el ejecutivo. Este aspecto se

refiere a que el desarrollo del SIE se haga tomando como
base lo que piensa el desarrollador y lo que espera el
ejecutivo. Por lo general los ejecutivos no disponen de
mucho tiempo para dedicarlo al desarrollador del SIE y es
49
muy común que esté esperando algo diferente de lo que en

realidad es. Es por ello que la presentación de la propuesta
ayudará para asegurar que se comparten las mismas ideas.
 Reducir la resistencia al cambio. No todos los ejecutivos

aceptarán al mismo tiempo el concepto de un SIE. Con
frecuencia, cuando se desarrolla un nuevo proyecto existen
personas que están de acuerdo, otras a quienes es
indistinto y algunas que nos están de acuerdo. Quienes no
están de acuerdo con un proyecto no participan en él y
resulta perjudicial implantarlo cuando existe resistencia
activa. Una ventaja de la creación y presentación de la
propuesta es que puede conocerse la resistencia que existe
al desarrollo del SIE y darle dirección detallando muchos
de los beneficios que se obtienen al utilizar un sistema de
este tipo.
 Manejar las expectativas. En la elaboración y

presentación de una propuesta deben ponerse en una
balanza las expectativas. De la misma manera en que se
hable de los beneficios que puedan lograse con un SIE,
deben informarse los riesgos que implica y de los recursos
que requiere. Es importante considerar este último aspecto
ya que la mayoría de los fracasos se deben a que no se
explicaron los riesgos y las necesidades de recursos y solo
se destacó lo ventajoso que sería utilizar este sistema.
 Lograr el compromiso de los recursos. Cuando se

elabora y se presenta la propuesta para el desarrollo de un
SIE deben considerarse los recursos que se requiere para
llevarla acabo. Existen personas que sólo acostumbran
justificar los costos; sin embargo, es importante hacer un
50
pronóstico del dinero, del personal y del tiempo que se

necesitara para cumplir la propuesta.
1.2.1.3. Determinación de las Necesidades del Ejecutivo.

[COH 00]
Este paso consiste en determinar las necesidades del ejecutivo.
Turban sugiere un conjunto de estrategias para ello:
 Cuestionar al ejecutivo acerca de cuáles son las preguntas que
le gustaría formular al término de un período.
 Aplicar la metodología relacionada con los factores críticos
del éxito.
 Realizar entrevistas con los directores o gerentes de las
diferentes áreas funcionales de la empresa, con el objetivo de
conocer qué información considera relevante.
 Enumerar los principales objetivos de la empresa a corto y
mediano plazos y definir la información necesaria para darle
seguimiento.
 Preguntar a los ejecutivos cuales son los datos que no les
gustarían que llegaran a manos de la competencia.
 Determinar la información que utiliza en la actualidad el
ejecutivo para monitorear la situación de la empresa.
1.2.1.4. Creación del Sistema y Presentación de un Prototipo
[COH 00]
La clave para la creación de SIE exitoso es el prototipo. En
ocasiones, un SIE se describe como un prototipo que nunca
termina. Estos sistemas deben evolucionar constantemente y la
velocidad con se realizan los cambios es muy importante para
el éxito.
51
1.2.1.4.1. Desarrollo e implementación de la base de datos

estratégica.
Etapas según la metodología de Ralph Kimball
[KIM 98]:
Para la construcción del Data Warehouse se sigue el
mismo ciclo de perfeccionamiento que todos los
desarrollos de software, en la siguiente figura se
muestra las etapas:
Figura 1.10 Ciclo de Desarrollo
1.2.1.4.2. Planeación
 Consiste en hacer una selección de la estrategia de
implementación.
 Selección de la metodología de desarrollo.
 Selección del ámbito de implementación.
 Selección del enfoque arquitectónico.
 Desarrollo de un programa y del presupuesto del
proyecto.
 Desarrollo de escenario de uso empresarial.
Para el data Warehouse, se realiza una planeación que
consiste en hacer selecciones de la estrategia de
implementación, la metodología de desarrollo, del
ámbito de implementación, del enfoque
arquitectónico, desarrollo de un programa y del
52
presupuesto del proyecto, desarrollo de escenarios de

uso empresarial y recopilación de metadatos.
a. Selección de la Estrategia de
Implementación
b. Selección Metodología de
Desarrollo
P
c. Selección del ámbito de
L
Implementación
A
N
E d. Selección del enfoque
A Arquitectónico
C
I
e. Desarrollo de un Programa y
Ó
del Presupuesto del Proyecto
N
f. Desarrollo de Escenarios de
uso Empresarial
g. Recopilación de Metadatos
Figura 1.11 Pasos de la Fase de Planeación
Las decisiones claves aquí son la selección del

enfoque, la selección de la arquitectura apropiada
del almacén de datos; la selección adecuada del
ámbito de información, fuentes de datos y tamaño
de metamodelo y la estimación de planes de
programa y proyectos y justificaciones de
presupuesto.
53
DESARROLLO DE LA FASE DE
PLANEACIÓN:
a. SELECCIÓN DE LA ESTRATEGIA DE
IMPLEMENTACION
(Enfoque de abajo hacia arriba (de lo
particular a lo general)
Generalmente comienza con experimentos y
prototipos basados en tecnología.
Se recomienda bajo los escenarios:
 Cuando la tecnología por implementar se
encuentra en el extremo izquierdo de la curva
de madurez de la tecnología. Hay oposición
grande y conservadora ante la nueva
tecnología sin una consideración suficiente.
 Cuando la organización no está todavía
comprometida con la tecnología del AD, pero
busca una evaluación tecnológica para
determinar cómo, dónde y cuándo desplegar
esta tecnología.
 Cuando la organización trata de obtener una
idea de los costos y gastos adicionales de
implementar y desplegar la tecnología del
Almacén de Datos-DW.
 Cuando no están claros los objetivos
empresariales, ni tampoco las afectaciones a
procesos actuales por el uso del Data
Warehouse.
 Cuando la organización está realizando una
inversión oportunista, en vez de estratégica, en
la tecnología del Data Warehouse.
54
b. SELECCIÓN DE LA METODOLOGÍA
DE DESARROLLO
Metodología de desarrollo espiral
Este método es partidario de la rápida
generación de sistemas cada vez más
funcionales con intervalos cortos entre
versiones sucesivas.
Se utilizará este método cuando:
 No se pueden predecir con claridad ni
anticipación la dirección de un mercado y
sus requerimientos.
 El tipo de colocación en el mercado es un
ingrediente importante en la
implementación de un producto.
 Es necesario una mejora iterativa para hacer
correcciones en el mercado.
 La ventaja competitiva sostenida proviene
de mejoras súbitas en forma continua.
 A la organización le toma por lo menos seis
meses absorber las versiones sucesivas de
software.
Despliegue
Planeación
Liberación de fase 2
Construcción
Requerimientos
Análisis y Diseño
Figura 1.12 Método de Desarrollo Espiral
55
Dadas las características anteriormente

señaladas, se recomienda usar el modelo de
desarrollo en espiral, para la construcción de un
Data Warehouse.
c. SELECCIÓN DEL ÁMBITO DE

IMPLEMENTACIÓN
La motivación principal del proyecto del
almacén de datos es una primera
implementación que produzca beneficios
inmediatos a un grupo de usuarios.
Después del ámbito puede restringirse a muchas
dimensiones:
Números y tipos de
departamentos atendidos
Números de fuentes
de datos
Subconjunto del modelo

empresarial selecionado
Presupuesto
asignado
Tiempo asignado al
primer proyecto
Figura 1.13 Algunas dimensiones para

restringir el ámbito de una primera
implementación del DW
d. SELECCIÓN DEL ENFOQUE

ARQUITECTÓNICO
El implementador dispone de las siguientes
opciones Arquitectónicas:
Solo Data Warehouse.
56
Esta arquitectura reconoce que, por lo general,

todas las aplicaciones del Data Warehouse
requieren diversas operaciones que se aplican
sobre las fuentes de datos, como depuración,
integración, resumen y adición. Por lo tanto,
tiene sentido aplicar estas operaciones una vez
y traer los datos de las fuentes a un Data
Warehouse centralizado. En una arquitectura
como ésta, un solo Data Warehouse lógico
alimenta a todos los usuarios finales con
información para apoyo en las decisiones.
e. DESARROLLO DE UN PROGRAMA Y
DEL PRESUPUESTO DEL PROYECTO
Uno de los aspectos más importantes de la
planeación consiste en poder realizar lo
siguiente:
Reservar un presupuesto adecuado para el
programa al tiempo que se compromete el
gasto en el proyecto específico. La planeación
de este presupuesto se basa en dos enfoques:
Estimar los costos del Data Warehouse,
asignando costos en base a los componentes de
la arquitectura de referencia.
f. DESARROLLO DE ESCENARIOS DE
USO EMPRESARIAL
Un factor de éxito fundamental para asegurar
que el Data Warehouse sea utilizable, consiste
en hacer que los usuarios finales se involucren
en el establecimiento de expectativas de lo que
puede ofrecer el Data Warehouse.
57
Los escenarios empresariales son una

importante herramienta del prototipo de
requerimientos. Un escenario de uso
empresarial consta de los siguientes
ingredientes:
 Un usuario empresarial claramente
identificado, como un gerente de
producción de accesorios para automóvil,
con un papel empresarial bien definido.
 Un área funcional que respalde el Data
Warehouse o el mercado de datos y que lo
utilice cuando esté terminado, como la de
planeación de productos y análisis del
mercado.
 Una o más consultas empresariales de
interés crucial para el área funcional que no
satisfagan actualmente a los sistemas de
información existentes. Las consultas
empresariales deben formularse en términos
precisos empleando el lenguaje común de
negocios que entiendan los usuarios finales
y el área funcional.
g. RECOPILACIÓN DE METADATOS
Parte de la fase de planeación del Data
Warehouse, es la necesidad de recopilar varios
elementos de diseño relacionadas con los
metadatos.
Metadatos, es el término que se emplea para las
definiciones de datos. Los metadatos son el
ingrediente de anteproyecto que se utiliza para
construir el Data Warehouse.
58
Los metadatos reunidos durante la fase de

planeación del Data Warehouse provienen de
muchas fuentes como las siguientes:
 Los modelos empresariales construidos por
la organización son modelos de datos
abstractos utilizados para caracterizar los
tipos de información que necesita, recopila
y utiliza una organización. Los modelos
empresariales deben basarse en la
naturaleza del negocio, no en los sistemas
de información actuales que producen y
consumen información. Sin embargo,
muchas organizaciones construyen modelos
empresariales de datos a partir de una
perspectiva de abajo hacia arriba,
comenzando con las organizaciones de sus
bases de datos actuales.
 Los depósitos y diccionarios de datos que
manejan los administradores de datos
contienen definiciones de datos
operacionales ubicados en diversas bases de
datos relacionales y no relacionales. Estos
se mantienen actualizados y proporcionan
una valiosa fuente de definiciones para
comenzar a construir extractores de datos
para la obtención de datos operacionales.
 Las fuentes externas de datos que se
requieren para responder consultas
empresariales pueden estar estructuradas o
no para el acceso y recuperación. Los datos
estructurados los proporcionan las fuentes
de información de terceros, como Dow
59
Jones y las fuentes de datos adquiridos. Los

metadatos que definen los datos de estas
fuentes se incorporarán al metamodelo de
Data Warehouse.
1.2.1.4.3. Determinación de los Requerimientos

Se identificará la información que requiere el
usuario para desempeñar sus tareas. En esta etapa
se especifica las funciones específicas que se
obtendrán del Data Mart describiendo con claridad
los requerimientos tales como:
 Definir los requerimientos del propietario.
 Definir los requerimientos del usuario final.
Estos requerimientos permitirán tener el ambiente
operativo en el que se entregará el Data Mart.
R
E a. Definir los requerimientos del propietario
Q
U
E
b. Definir los requerimientos del arquitecto
R
I
M
I
c. Definir los requerimientos del desarrollador
E
N
T
O d. Definir los requerimientos de los usuarios
S finales
Figura 1.14 Requerimientos para la solución del Data

Warehouse
Marco de referencia de análisis de
requerimientos. Una forma directa de ver los
requerimientos, es a través de las diversas
perspectivas del marco de referencia de Zachman.
60
QUÉ CÓMO DÓNDE QUIÉN CUÁNDO POR QUÉ
. Sistema de . Negocio
soporte para las . Oficina del . Mensualmente . Objetivos
. Analizar datos . Departamento de
Dueño decisiones para Departamento de . Trimestralmente . Decisiones de
históricos Mercadotecnia
análisis de ingresos Mercadotecnia . Anualmente Mercadotecnia
del cliente Promocional
. Objetivos
. Áreas tema . Profundizar . Escritorio
Usuario . Administradores . Información Operacionales
. Dimensiones . Reportar . Sala de conferencias
Empresarial . Analistas fluida . Soporte de
. Granularidad . Consultar del departamento
Decisiones
. Administradores de
. Datawarehouse Datos y de Base de . Data Warehouse y
Implementador . Áreas tema . LAN
y funciones del Datos ciclo de . Objetivos
de tecnologías . Metamodelo del . Trabajo Corporativo
Mercado de . Analista de Dominio actualización de Técnicos
de información Data Warehouse en Red
Datos . Programador de carga
aplicaciones
Tabla 1.1. Perspectivas del Data Warehouse establecidas mediante el Diagrama de
Zachman [HAR-96]
Para realizar esta fase de análisis de
requerimientos de acuerdo a:
a. Requerimientos del propietario

Estos requerimientos se captarán en términos
de:
 Áreas Tema
Son los temas de interés de diversas
funciones empresariales. Una selección
cuidadosa de las áreas tema contiene el
ámbito de implementación del Data
Warehouse al tiempo que maximiza su
utilidad.
 Granularidad
Se refiere al nivel de detalle de la
información requerida. La Granularidad
tiene una relación directa con las
actividades de resumen y adición que deben
realizarse sobre los datos fuente. A menor
Granularidad, mayor cantidad de detalle. En
general, los datos operacionales se
consideran como el nivel más bajo de
Granularidad. Para incrementar su
Granularidad (y su utilidad para quienes
61
toman las decisiones), los datos

operacionales deben resumirse y
acumularse todavía más. Por lo regular,
entre mayor sea la Granularidad, mayor
será la cantidad de procesamiento requerido
para convertir y resumir los datos
operacionales.
 Dimensiones
Un Data Warehouse un gran conjunto de
datos operacionales e históricos mediante
múltiples dimensiones de categorización.
Una importante, es el tiempo. A los datos
operacionales se les asigna un registro de
tiempo (fecha y hora) en la fuente, para
establecer una referencia de tiempo con los
datos.
b. Requerimientos del arquitecto

Arquitecto, es la persona responsable de diseñar
los diversos componentes del Data Warehouse
para sustentar las necesidades actuales y futuras.
Los arquitectos deben de compilar una serie de
requerimientos que coincidan con la visión del
propietario, así como de un conjunto de
requerimientos que reflejen la implementación
de la tecnología.
c. Requerimientos del desarrollador

Si el arquitecto ve al Data Warehouse en
abstracto, el desarrollador debe verlo en
concreto. Los requerimientos del desarrollador
son un refinamiento de los del arquitecto, con
62
decisiones tomadas respecto a la selección de

plataformas y la separación de la arquitectura de
datos y la arquitectura de aplicación,
relacionadas con la tecnología que utilizará para
realizar las mismas.
d. Requerimientos de los usuarios finales

El usuario final ve al Data Warehouse como
una gran caja negra cuyo acceso principal es a
través de aplicaciones y herramientas de
consulta y reportes, junto con cierto tipo de
ubicación de la información contenida dentro
del Data Warehouse.
1.2.1.4.4. Análisis
En esta etapa se analizarán las necesidades propias
del Data Mart que permitirá tener en forma precisa
las necesidades estructuradas, que son decisiones
donde las condiciones, alternativas, acciones y
reglas de acción podrán determinarse.
En esta etapa, significa convertir los
requerimientos acopiados en la fase anterior de
requerimientos, en un conjunto de especificaciones
que pueden apoyar en el diseño de la base de datos
del Data Warehouse.
En esta fase se modela el Data Warehouse,
siguiendo los siguientes pasos:
 Construir las áreas tema a partir de consultas
empresariales.
 Construir las dimensiones – traducir el modelo
DER al modelo multidimensional, de acuerdo a
los requerimientos de información y
necesidades de análisis.
63
Dimensiones
Área
Tema
TIEMPO
Anual
TIEMPO
Tipo Producto
PRODUCTO
Zona
GEOGRAFÍA
Figura 1.15 Molde para una Consulta Empresarial
 Modelar el Data Warehouse, utilizando el

Esquema Estrella.
Esquema Estrella
Es un paradigma de modelado que tiene un solo
objeto en el medio conectado con varios objetos de
manera radial. Refleja la visión del usuario final de
una consulta empresarial. Un esquema estrella
lógico sencillo tiene una sola tabla de hechos y
varias dimensiones conectadas a ellas.
Su estructura base es similar: Una tabla central y un
conjunto de tablas que la atienden radialmente,
como su nombre lo indica, tiene forma de
“estrella”, el centro lo compone una o más Tablas
Hechos, y las puntas de la estrella son las Tablas
Dimensión.
Ejemplo Esquema Estrella:
64
TABLA DE HECHOS VEHÍCULO

-Geografia_key
Vehículo_Dim -Vehiculo_Key EstadoCampo_Dim
-Vehiculo_Key -Tiempo_Key
-EstadoCampo_Key
+Tipo Vehiculo() -EstadoCampo_Key
-Producto_Key +Nombre del Estado de Campo()
+Condicion()
+Costo Transporte()
+Cantidad Hectareas()
Geografía_Dim Producto_Dim Tiempo_Dim

-Geografia_key -Producto_Key -Tiempo_Key
+Descripción() +Tipo de Caña() +Año Mes()
+Descripcion()
Figura 1.16 Esquema Estrella
 Extracción: Seleccionar datos y diferentes

métodos.
 Transformar: validar, limpiar, integrar y fechar.
 Transporte poner los datos en el Data
Warehouse.
(HAR-96)
1.2.1.4.5. Diseño y Modelización

En esta fase de diseño, los modelos lógicos
desarrollados en la fase de análisis se
convierten en modelos físicos. Los procesos
identificados en la fase de análisis sirven para
conectar las fuentes de datos operacionales con
el Data Warehouse, el DW con las
herramientas de estación de trabajo del usuario
final, se convierten en diseños para programas
que realizarán las tareas requeridas por los
procesos.
65
En la fase de diseño se encuentran las siguientes

dos actividades principales:
 Diseño detallado de la arquitectura de datos.
 Diseño detallado de la arquitectura de
aplicación.
[WEB8 – 00]
1.2.1.4.6. Construcción
La fase de construcción es responsable de
implementar físicamente los diseños
desarrollados durante la fase de diseño. Por
medio de decisiones juiciosas “hacer en
comparación con comprar”, es posible integrar
una solución de Data Warehouse bastante
rápido. Además, mediante una sopesada
incorporación de las inversiones existentes, es
posible acelerar la tarea de desarrollo.
La construcción del Data Warehouse es similar
a la construcción de un sistema de base de datos
relacional grande. La mayoría de las
aplicaciones que se necesitan construir son las
siguientes:
 Programas que creen y modifiquen las bases
de datos para el Data Warehouse.
 Programas que extraigan datos de fuentes
relacionales y no relacionales.
 Programas que efectúen búsquedas en bases
de datos muy grandes.
66
1.2.1.4.7. Prueba
La fase de prueba tiene que ver con los retos de
instalación, puesta en servicio y uso de la
solución del Data Warehouse.
Esta fase tiene un componente único denominado
comercialización de información. Esto reconoce
que la mercancía que suministra el Almacén de
Datos a sus usuarios finales es la propia
información. La comercialización comprende la
capacidad de hacer énfasis en la disponibilidad,
los beneficios y el empaque para hacerla atractiva
al usuario final.
1.2.1.4.8. Desarrollo
En esta fase se desarrolla el software original que
sea necesario, también se interactúa con el usuario
para desarrollar la documentación indispensable
del software que expliquen tanto y cómo se utilizó
cierto procedimiento conforme se codificó de
cierta forma. La documentación esencial para
probar el programa y darle mantenimiento una vez
que la aplicación se a puesto en marcha.
67
1.2.2. RESUMEN SISTEMA EJECUTIVO
ACTIVIDAD RESULTADOS
Aplicaron de encuestas, cuestionarios.
Levantamiento de información.
Evaluar Alternativas de Elegir la alternativa de desarrollo para el SIE.

desarrollo. Justificación del uso de la propuesta elegida
Elaboración del proyecto.
Creación de la propuesta.
Definición de la propuesta al ejecutivo.
Elaboración de cuestionarios.
Realizar las entrevistas a las personas necesarias
Determinación de las necesidades
Realizar un planeamiento estratégico.
del ejecutivo
Identificación de los factores de gestión.
Establecer las políticas para los índices.
Diseño e Implementación de la Base de Datos
Estratégica.
Creación del sistema y
Diseño de la interfaz Hombres – Maquina.
presentación del prototipo. Codificación del Sistema.
Pruebas del SIE.
Tabla 1.2 Resumen de entregables de Sistema Ejecutivo
68
1.2.3. DIAGRAMA DE GANTT DE LAS ACTIVIDADES
Mayo 2004 Jun 2004 Jul 2004 Ago 2004 Sep 2004 Oct 2004 Nov 2004 Dic 2004
ID Nombre de tarea
2/5 9/5 6/6 4/7 1/8 8/8 5/9
1 Levantamiento de Información
2 Evaluar Alternativas de Desarrollo
3 Creación de la Propuesta
4 Determinación de las Necesidades del Ejecutivo
5 Elaboración de cuestionarios
6 Realizar entrevistas
7 Realizar planeamiento estratégico de la gerencia
8 Identificar factores críticos
9 Creación del sistema y presentacion del prototipo
10 Diseño e implementación de la base de datos estratégica

11 Diseño de la interfaz hombre-maquina
12 Codificación del sistema
13 Prueba del sistema
14 Elaboración del informe del SIE y los manuales
69
CAPITULO 2
ANÁLISIS Y RESULTADOS
2.1. IDENTIFICACIÓN DE LAS ALTERNATIVAS PARA EL

DESARROLLO DEL SISTEMA EJECUTIVO.
En la primera etapa del desarrollo del SIE, debe elegirse una alternativa de
desarrollo, las cuales pueden ser:
DESCRIPCION ALTERNATIVA
Desarrollar el sistema de manera interna partiendo
Número 1
de cero.
Modificar el sistema actual con la finalidad de
Número 2
cubrir los requisitos del ejecutivo.
Desarrollar el sistema partiendo de cero con la
ayuda de desarrolladores externos (comprar el Número 3
sistema).
Tabla 2.1 Alternativas de Desarrollo
La Gerencia no cuenta con un Sistemas de Información Ejecutivo, ni con una

base de datos estratégica, la cual nos permita acceder a la información y
procesarla de acuerdo al interés del ejecutivo, para realizar modificaciones o
cambios como especifica la alternativa número 1, por lo tanto, no se tomará
en cuenta para la evaluación.
EVALUACIÓN DE LAS ALTERNATIVAS

A continuación, se presenta un cuadro que evalúa las alternativas número 1 y
número 3 para el desarrollo del SIE (ver anexo W), teniendo como criterios:
Costo, La adaptación del Sistema Ejecutivo y el tiempo que tomará
desarrollarlo.
70
Varia
Adaptación del
Evaluación Tiempo
Costo ($) SIE Casa
(Meses)
Grande
Alternativa
Alternativa Número 1 8,667.87 (Ver Tabla 2.13) Seis Completa
Alternativa Número 3 19,826.60 (Ver Anexo J) Ocho Medio
Tabla 2.2 Cuadro de Evolución de alternativas de desarrollo del SIE
Una vez evaluada las dos alternativas, se escogió la alternativa número 1:

“Desarrollar el sistema de manera interna partiendo de cero” (ver Tabla 2.13).
Con dicha alternativa se tendrá que asignar a un equipo de trabajo para el
desarrollo del sistema.
A continuación, justifica nuestra decisión:
- Los costos de la alternativa número 1: serán mínimos teniendo en cuenta
que el desarrollo de este sistema, forma parte de un proyecto de tesis. Es de
mencionar que los costos concernientes a hardware y software para la etapa
de la instalación del sistema serán cubiertos en su totalidad por La Gerencia
de Campo.
- Los costos de la alternativa número 3: son muy altos los cuales ascienden a
12,500 dólares aproximadamente, según la cotización que se hizo a la
empresa SOFOS (Ver Anexo J), dedicada a la implementación de software,
teniendo como cláusula de venta que toda modificación al sistema será
recargado un costo adicional dependiendo de la complejidad del mismo así
como la entrega sólo del ejecutable los cual no nos permitirá contar con el
código fuente del programa. Cabe mencionar que en el presupuesto de la
Gerencia de Campo no se considera gastos por este rubro.
71
2.2. CREACIÓN DE LA PROPUESTA
2.2.1. ELABORACIÓN DEL PROYECTO
DATOS GENERALES DEL PROYECTO
a.1. Título
“Sistema De Información Ejecutivo de Producción para la Gerencia de
Campo de la Empresa Agroindustrial Casa Grande S.A.A.”
a.2. Duración del Proyecto

Las actividades a desarrollar durante todo el proyecto se detallan en el
cronograma de actividades del proyecto el cual se detalla en la Figura 2.1.
La duración de cada actividad se obtuvo de acuerdo a la experiencia de los
tesistas en actividades de desarrollo de sistemas y de acuerdo con el
encargado de la coordinación de proyectos de la empresa el Ingeniero
Agrónomo Carlos Carbonel.
a.3. Recursos
a.3.1. Personal
a.3.1.1. Investigador
 Dos Bachilleres en Ingeniería de Comparación y
Sistemas.
a.3.1.2. Asesor
 Un ingeniero en Computación y Sistemas.
a.3.1.3. Personal de Apoyo
 Un Ingeniero especialista en base de datos
multidimensional.
a.3.2. Bienes
a.3.2.1. Materiales
Útiles de escritorio
 Papel bond tamaño A4 de 80 gr.
72
 Papel Bulki tamaño oficio.

 Lapiceros, correctores, folders manila, portaminas,
plumones, reglas, engrapador, perforador, clips, goma,
cinta scoctch, etc.
Suministros de Cómputo
 Diskettes 3m HD de 1.44 MB.
 CD-ROM
 Tinta para impresora Canon S 200x de color negro.
 Tinta para impresora Canon S 200x de colores.
 Tinta para impresora Canon I250 de color negro.
 Tinta para impresora Canon I250 de colores.
Textos
 Visual Basic 6.0.
 SQL Server 2000.
 Diseño e implementación de Data Warehouse.
a.3.2.2. Hardware
 01 computadora Pentium III de 1 Ghz, disco duro de 20
GB, Memoria RAM de 256 MB, monitor de 15”,
memoria de video de 16 MB, CD-ROM creative 52x,
disquetera, teclado, mouse 3D.
 01 impresora Canon S 200x.
 01 impresora Canon i250.
a.3.2.3. Software
 Microsoft Windows Advanced Server 2000.
 SQL Server 2000.
 Microsoft Visual Basic versión 6.0.
 Microsoft Office 2000.
73
a.3.2.4. Servicios
 Servicio de tipeo.
 Servicio de empastado.
 Servicio de fotocopiado.
 Servicio de anillado.
 Servicio de acceso a internet.
 Servicio de telefonía local.
 Servicio de telefonía celular.
 Servicio de transporte urbano.
 Servicio de transporte de taxi.
PLAN DE DESARROLLO
b.1. Definición del Problema

La Gerencia de Campo de la Empresa Agroindustrial Casa Grande S.A.A.,
no cuenta con información estratégica Y oportuna sobre los indicadores de
evaluación para la producción final de azúcar. Como consecuencia de la
misma no permite tomar decisiones oportunas y adecuadas.
Es por tal motivo que se necesita construir un Sistema de Información
Ejecutivo de Producción, que proporcionará información cimentada para
ayudar a los ejecutivos a monitorear en tiempo real las unidades, mediante
indicadores que les permita prestar evaluar con mayor eficacia, aquellos
indicadores de gestión, y de esta manera apoyar al ejecutivo a tomar las
decisiones correctas y oportunas dentro del proceso de la dirección.
b.2. Fundamento Teórico

Definición de Sistema de Información Ejecutivo (SIE)
Los SIE son sistemas de información que permiten el fácil acceso a la
información interna y externa que intervienen en los factores críticos de
éxito de las empresas, estos sistemas están diseñados para facilitar la toma
de decisiones a los ejecutivos, están fundamentados en Bases de Datos
74
Estratégicas y presentados sobre una interfaz amigable con el usuario y así

presentar la información de manera preferentemente gráfica.
b.3. Justificación
La utilización de un sistema de información Ejecutivo se verá claramente
justificado, puesto que proporcionará los datos necesarios a los ejecutivos
para analizar la situación actual, identificar problemas inmediatos y en base
a ello encontrar soluciones, tomar decisiones inteligentes sobre el uso de
recursos limitados tanto humanos como financieros. Por otra parte,
permitirá disminuir el tiempo en la confección y presentación de reportes,
facilitándole a los ejecutivos de la Gerencia de Campo poder llevar a cabo
otras funciones propias de su cargo.
Con el uso de los sistemas de información computarizados, la Gerencia
tendrá la siguiente justificación:
 Social
 Facilitar tanto a obreros como al personal administrativo obtener
información ordenada y oportuna.
 Mejorar la asignación de campos de cultivo a los obreros ya sean
eventuales, contratados y estables.
 Mejorar la imagen institucional brindando a los empleados,
obreros y público en general, una adecuada información mediante
modernos equipos de cómputo.
 De Gestión
 Facilitar la rapidez de los procesos para la toma de decisiones
oportunas por parte de la dirección, obteniendo información en
línea.
 Disminuir errores en el procesamiento de información para la alta
gerencia.
 El manejo de información relevante por parte de los ejecutivos
permitirá mejorar la productividad de la empresa.
75
 Técnica
 Permitir mejorar en forma sustancial la manera anticuada y tediosa
en la obtención de información con la incorporación de
tecnologías nuevas.
2.2.2. DEFINICIÓN DE LA PROPUESTA AL EJECUTIVO

La Gerencia de Campo de la Empresa Agroindustrial Casa Grande,
necesita a diario tomar decisiones, por lo tanto, el manejo actualizado
y real de su información, constituía un trabajo tedioso y complicado
que se prolongaba por mucho tiempo.
Para dar solución inmediata a un problema de esta naturaleza en una
organización que maneja volúmenes grandes de información, se
propuso a la Gerencia de Campo la construcción de un Sistema de
Información Ejecutivo que permita un análisis y seguimiento de los
factores de gestión de la Gerencia de Campo; los datos relevantes y
los resultados que nos proporciona el DATA MART, la misma que
de manera rápida permitirá calcular los índices de gestión o factores
críticos, para mostrar la situación actual de la Gerencia.
La información diaria que procesa el sistema transaccional es
aprovechada por la base de datos estratégica y luego es procesada por
el Sistema de Información Ejecutiva propiamente hecho, con el fin de
obtener como respuesta aquellos índices de gestión según sea lo
determinado por el usuario.
A continuación, haremos una lista de los principales índices que el
sistema va a manejar:
 Cantidad de hectáreas preparadas, sembradas y cosechadas.
 Costos de mano de obra para la preparación, siembra y
cosecha.
 Costo por el uso de transporte en la preparación, siembra y
cosecha.
 Costo empleado en el uso de insumos en la preparación,
siembra y cosecha.
76
Para determinar la toma de decisiones es muy importante para el

ejecutivo el manejo de información del SIE y poder determinar
anticipadamente la correcta utilización de los recursos.
2.3. DETERMINACIÓN DE LAS NECESIDADES DEL EJECUTIVO

Se presenta a continuación el plan estratégico de la Empresa Agroindustrial
Casa Grande S.A.A.
A. Reseña Histórica
La Empresa Casa Grande, es una empresa económica social creada por
Decreto Ley DL. 17716. Por ley de reforma agraria paso a ser propiedad de
sus trabajadores bajo la forma de Cooperativa con el nombre de La
Empresa Agroindustrial Casa Grande S.A.A., está ubicado en el Valle
Chicama, a 46 Km. al norte de la ciudad de Trujillo departamento de La
Libertad. Las oficinas administrativas se encuentran en el distrito Casa
Grande, provincia Ascope, departamento de La Libertad. El capital social
asciende a la suma de S/. 788’339,272 las que se encuentran suscritas y
pagadas íntegramente. La empresa de sus propias acciones cuenta con
25,710 acciones.
Tiene una extensión de 29,384.03 hectáreas en la cual está dividido en 4
zonas y 20 anexos estratégicamente distribuidas. A continuación, se
describe la división geográfica:
La Empresa Agroindustrial Casa Grande S.A.A. cuenta con 29,384.03
hectáreas la cual está dividida estratégicamente con 4 zonas y 20 anexos
alejados en un promedio de 12 Km. Con sus respectivos campos. El más
cercano es dos Km. y el más alejado 56 Km.
77
Zona 1: Casa Grande

Zona 3: Farías
 Casa Grande.
 Mocan.  Farías.
 Santa Clara.  Molino Cajanleque.
 Lache.  Ticmar.
 Facalá.  Veracruz.
 Capilla.  Chuín.
Zona 2: Roma Zona 4: Causal
 Roma.  Sausal.
 La Constancia.  Chicamita.
 Mocollope.  Pampas de Jaguey.
 Cepeda.
 Potrero de los Piscos.
 Pampas de Ventura.
78
División Abastecimiento
Gerencia Comercial
División Ventas
Dpto. Oficina Lima
Dpto. Control de Bines
División Finanzas
Asesoría Legal
Gerencia Administrativa
Asesoría
División Conatbilidad
División Adm. Perso.
ORGANIGRAMA DE LA EMPRESA
Dpto. Sistemas y Met.

Control Presupuestal
División Procesami.
Junta de Accionistas
Gerencia General
Directorio
División Ext Mant.

Gerencia de Ingenio
79
División Energía
División Produccion
División Laboratorio
División Campo Farias
Asesoría Auditora.
Gerencia de Campo
División Campo Casa
División Campo Roma
División Campo Sausal
Unidad de Producción
Unidad de Estación
El cambio de propiedad y de sistema, así como de la conducción

empresarial, produjeron desajustes sumados a diversos factores de orden
externo como precios, mercados y situaciones climáticas adversas,
desembocaron en bajas producciones y productividades, bajas
rentabilidades, alto endeudamiento y perdida de patrimonio.
En la Gerencia de Campo y en los anexos, se cuenta información valiosa,
puesto que se deben elaborar informes semanales, mensuales y
ocasionalmente en el momento que sean necesario y volverlos a depurar, de
nada nos serviría estos reportes o gráficos si no se sabe qué hacer con ellos.
La gerencia de Campo presenta problemas al no contar con formas de
almacenamientos datos que cubran los requerimientos de información y
evite la pérdida de tiempo y esfuerzo, así como brindar un soporte oportuno
al momento de tomar decisiones. Hasta el momento la información
solicitada por los Jefes de Campo (Gerente de Campo, Sub. Gerente de
Campo, Jefes de Zonas y Administradores de Anexos) que es en donde
estamos orientando el problema, tiene que ser nuevamente procesada en la
Gerencia de Campo, lo que ocasiona un retraso en la toma de decisiones de
dicha área, ya que esta no satisface sus expectativas, debido que en varias
ocasiones se encontró duplicidad de datos. Cabe señalar que la importancia
de estos informes es que ayudan al Jefe de Campo (Gerente de Campo) a
tomar decisiones oportunas y adecuadas. Esto nos indica que la Gerencia de
Campo no cuenta con una base de datos estratégica que pueda ser explotada
al máximo y a la vez ser utilizada por otros sistemas de información
permitiendo visualizar proyecciones gráficas en el momento que se requiera
información relevante, siendo esto necesario para una mejor toma de
decisiones.
Es por ello que surge la necesidad de los ejecutivos de contar con un
software que le permita planificar, controlar y disponer de información
necesaria para tomar decisiones oportunas y eficaces. Por tal motivo se está
realizando el estudio para mejorar esta situación en los Anexos, Jefaturas de
Zona y en la Gerencia de Campo la cual de logrará con la ayuda de un
Sistema de Información Ejecutiva para la Gerencia de Campo de la
80
Empresa Agroindustrial Casa Grande S.A.A., ya que no se puede negar que

la calidad de las decisiones está en función directa al tipo de información
disponible. Estas decisiones deberán estar soportadas por la información
que brinde la Base de Datos Estratégica (Data Mart).
En resumen, podemos destacar los siguientes problemas:
 Falta de un software apropiado para los Ejecutivos, que permita

mostrar en tiempo real los principales indicadores de la empresa.
 Retrasos en el procesamiento de la información por parte de cada
anexo.
 No se cuenta con estrategias adecuadas, ni se cuenta con un soporte a
la toma de decisiones, por lo tanto, la información se encuentra
dispersa y no procesada.
 Falta de información estratégica real, oportuna y adecuada, debido a
que la información que llega a los directivos no son reales muchas
veces son promedios de los datos.
 Los reportes que se elaboran para los Ejecutivos son muy “fríos”
(carecen de información estratégica real, oportuna y adecuada) lo que
genera que los directivos no tengan una visión real del contexto y
sumándose a esto que no son procesadas oportunamente.
El Sistema de Información Ejecutivo de Producción que se desarrollará,
estará orientado de manera realista hacia el logro de los objetivos de la
Gerencia de Campo, permitiéndole contar con información estratégica,
oportuna, libre de errores que monitoree los factores más relevantes de la
Gerencia de Campo con la que se permitirá ayudar a la toma de decisiones
al Gerente de Campo.
B. Visión
En el 2010, la Empresa Agroindustrial Casa Grande S.A.A. es una empresa
competitiva en su rubro, la cual utiliza con alta eficiencia sus recursos
potenciales para lograr una máxima productividad con una filosofía de
óptima calidad.
81
Cuenta para tales logros, con infraestructura adecuada y con personal

calificado y especializado, que trabaja en equipo a través de una
organización horizontal con una administración autogestionaria y eficiente.
C. Misión Institucional
“La Empresa Agroindustrial Casa Grande S.A.A. está comprometida a ser
líder nacional en la fabricación del azúcar y derivados.”
D. Valores
 Calidad de Servicio
 Responsabilidad
 Puntualidad
 Identidad Regional
 Compromiso con la Institución
E. Funciones Institucionales
- Cultivo de la caña de azúcar.
- Producción de azúcar para el consumo diario.
- Producción de melaza, bagazo y alcohol.
- Asesorar y apoyar a todo el grupo humano que labora en la empresa a
fortalecer su capacidad para enfrentar los retos que se les impongan.
F. Objetivos de la Alta Dirección

- Suministrar a la alta dirección la información de los indicadores
principales del área de Gerencia de Campo necesaria, en interfaces
amigables que necesiten de un mínimo de entendimiento para su uso, de
manera que apoyen eficazmente a una mejor toma de decisiones.
- Buscar la mejor solución tecnológica, que permita a los directivos mejorar
el conocimiento del comportamiento de la institución al facilitarle
información en tiempo real de los factores críticos de éxito de la empresa,
permitiéndole analizar cómo afectan estos dentro del contexto, facilitando
82
la localización de relaciones causa-efecto sobre los intereses de la

organización.
- Contar con la tecnología que permita a los gerentes y sub-gerentes de ser
habilitados a conectarse desde sus computadoras personales y en red a
sistemas que provean de datos reales, precisos, para tener una mejor idea
de las tendencias e incidencias que ocurren en el área y así tomar
decisiones necesarias para resolver problemas netamente estratégicos.
G. Estudio de Factibilidad
El proyecto se apoya en tres principios básicos de factibilidad:
Técnica, Económica y operativa; los que deberán ser satisfechos para
merecer su desarrollo posterior.
a. Factibilidad Técnica
A continuación, se detalla las características y requisitos mínimas
necesarias en cuanto a Hardware para el funcionamiento del Sistema de
Información Ejecutivo:
- Computadora para el desarrollo del proyecto, con los siguientes

requerimientos:
Equipo Características
Microprocesador Pentium IV 3.0 MHz.
Disco Duro 80 GB.
Memoria RAM 512 MB.
Tarjeta de video 64 MB.
CD-ROM 52X
CD-RW 52X 24X 52X
Puertos E/S Midi, Serie, Paralelo, USB
Tarjeta de Red Ethernet 10/100
Drive Floppy 1.44 MB.
Monitor 17”
Teclado 101 Teclas
Mouse Dos botones
Tabla 2.3 Características de Hardware
83
b. Factibilidad Económica
A continuación, detallamos los beneficios:
b.1. Beneficios Intangibles

 Permite mejorar la toma de decisiones del ejecutivo.
 Permite al ejecutivo mejorar sus conocimientos en la gestión y
el uso de las tecnologías de información, permitiéndoles un
mejor aprovechamiento del potencial de éstas.
 Permite mejorar el uso por parte de las organizaciones de las
tecnologías de información, ya que, con mayor formación
informática, el ejecutivo puede acelerar el uso de las
tecnologías de información en toda la organización.
 Permite mejorar la comprensión y el control de la Gerencia de
Campo por parte del ejecutivo. Al ampliar su modelo mental,
tanto de la gerencia como de su entorno competitivo, le
permitirá al ejecutivo un mejor conocimiento y compresión de
las relaciones causa – efecto.
 Permite mejorar los procesos de planificación y control, al
facilitar la información de manera rápida y de mejor calidad,
teniendo un gran impacto sobre los procesos de la Gerencia de
Campo.
b.2. Beneficios Tangibles

 Ahorro de costo por la distribución de la información, beneficio
obtenido por la disminución del uso de papel para distribuir la
información.
 Permitirá ahorrar el costo por necesitar servicios de personal de
apoyo para la recolección, confección y distribución de la
información resumida para el ejecutivo.
84
c. Factibilidad Operativa
En cuanto al estudio realizado a la factibilidad operacional, podemos
demostrar que el desarrollo de la implementación del Sistema de
Información Ejecutivo, surge de la necesidad de obtener información
consolidada en tiempo real para el ejecutivo de la Empresa. La
implementación del SIE nos ofrece la posibilidad de ayudar a los
máximos responsables de la conducción de la Empresa, siendo ésta la
Gerencia de Campo en el proceso de dirección estratégica,
proporcionándole aquella información que le permita al ejecutivo tener
conocimiento de sus variables relevantes del entorno que condicionan la
estrategia, a tomar para la solución de cada problema.
La aplicación podrá ser operativa para todos los ejecutivos de la
Gerencia de Campo, por ser un sistema amigable y fácil de navegar. El
SIE se considera viablemente operativo por lo siguiente:
 Durante el desarrollo se consideró técnicas que garanticen lograr
una aplicación fácil de usar.
 La aplicación será útil como herramienta informativa ya que
mostrará datos relevantes y previamente procesados, que contribuirá
con el objetivo de proveer información oportuna y adecuada a los
ejecutivos de manera que contribuya a mejorar la toma de
decisiones de los mismos.
H. Planificación de los Recursos

A continuación, se describe los diferentes recursos con los que se contó
para el desarrollo del Sistema de Información Ejecutivo, desde su
concepción hasta su implementación, los cuales son:
a. RECURSOS DE HARDWARE
a.1. Máquina de Desarrollo
Están conformados por los equipos que servirán de soporte para
las tareas de implementación de la aplicación, así como la
85
documentación de la tesis. A continuación, se detalla las

características de la computadora:
 Computadora Pentium III de 1Ghz., Disco Duro de 40 GB,
Memoria RAM: 128 MB, Monitor 15”, Memoria de video:
16 MB, disquetera, teclado, Mouse 3D.
a.2. Dispositivo de Captura y Digitalización

Se necesitó dispositivos de entrada (con tarjeta de video y de
scanner que permitirán la captura de video, sonido e imagen y
digitalizarlos) y de salida (como la tarjeta de video y sonido que
generará salida al video y sonido de la aplicación). Se utilizó los
siguientes dispositivos:
 Tarjeta de sonido Creative Labs.
 CD – ROM: Creative Infra 52X.
 Parlantes.
 Scanner AcerScan Prisa 620C.
a.3. Equipos de Impresión

Dispositivos que permitieron imprimir los informes
correspondientes a la documentación del desarrollo de la tesis. Se
utilizó las siguientes impresoras:
 Impresora Canon S200x.
 Impresora Canon i250.
b. RECURSOS DE SOFTWARE
b.1. Herramientas de Desarrollo
Durante el proceso de desarrollo de programación e
implementación de la aplicación se utilizó los siguientes
softwares:
 Microsoft SQL 2000 Server.
 Crystal Report 8.5
 Rational Rose
86
 Microsoft Visual Basic 6.0.

 Microsoft Office 2000.
b.2. Sistema Operativo

Software de base con interfaz gráfico, que permite operar la
computadora y sirve para ejecutar los programas aplicativos.
Durante la ejecución del presente trabajo se utilizó el siguiente
sistema operativo:
 Microsoft Windows Advanced Server 2000.
I. Estimación de Costos
A continuación, se detalla los costos estimados de acuerdo a los diferentes
rubros para el desarrollo del proyecto:
Costos por Servicios Profesionales

El costo de los servicios profesionales se tomará sólo de los tesistas, por
no haber pagado tanto al asesor como al especialista en Base de Datos
Multidimensional.
87
RECURSOS
Total Nro. Total Costo ($)
SERVICIOS PROFESIONALES Días Horas Horas Hora Total
Levantamiento de información. 6 4 24 1 24
Evaluar Alternativas de desarrollo. 5 2 10 1 10
Creación de la propuesta 5 3 15 1 15
Determinación de las necesidades del
ejecutivo. 54 18 1195 8.5 1148
Elaboración del cuestionario. 6 2 12 1 12
Realizar entrevistas. 12 5 60 2 120
Realizar planeamiento estratégico a
la E.A.C.G.S.A.A. 6 3 18 2 36
Identificar los factores de gestión. 30 8 240 3.5 980
Creación del sistema y presentación
de un prototipo. 137 23 865 6.39 1,917.00
Diseño e implementación de la base
de datos estratégica. 60 8 480 3.5 1,680.00
Diseño de la interfaz Hombre –
Máquina. 12 5 60 2 100
Codificación del sistema 50 5 250 0.4 100
Prueba del sistema 15 5 75 0.49 37
Elaboración del informe del SIE y los
manuales. 7 8 56 2 112
TOTAL EN SERVICIOS PROFECIONALES 3,226.00
Tabla 2.4 Costos de los Servicios Profesionales
Costos por Utilización de Hardware y equipos

Para el caso del número de horas que se utilizó en la computadora, se ha
tomado como punto de referencia el cuadro anterior donde especifica
las horas que el profesional las utilizó para realizar, desde el diseño
hasta la elaboración del informe, a continuación, se resume en el
siguiente cuadro:
88
Descripción de la Tarea Horas

SERVICIOS DE LA MAQUINA DE DESARROLLO
. Diseño e implementación de la base de datos estratégica. 480
. Diseño de la interfaz Hombre – Máquina. 60
. Codificación del sistema. 250
. Prueba del sistema. 75
. Elaboración del informe del SIE. 56
TOTAL DE LA MAQUINA DE DESARROLLO 921
Tabla 2.5 Total de horas de uso de la Computadora
En la siguiente tabla se detalla los servicios de hardware y equipos,

teniendo en cuenta el total de horas de la máquina de desarrollo (921
horas) que se estimó en la tabla anterior.
Hora Costo ($)

Recurso Cantidad utilizada x Hora Total
equipo
SERVICIOS DE HARDWARE Y EQUIPOS
. Máquina de desarrollo 1 921 1 921
. Impresora Canon i250 1 37 11 407
1 72 5 360
. Impresora Canon S200X
. Scanner 1 3 7 21
TOTAL SERVICIOS HARDWARE Y EQUIPOS 1,709
Tabla 2.6 Costo por servicios de Hardware y Equipos
Costos por Utilización de Software

Para la elaboración de este cuadro, debemos tener en cuenta que de
acuerdo al mercado la vida útil de un software es de dos años (36
meses).
89
Días Costo ($)

Recurso Costo del utilizados
Software por el Mes Total
($) Software
SERVICIOS POR SOFTWARE
. Microsoft SQL Server. 600 35 16.67 583.45
. Microsoft Visual Basic. 500 72 13.89 1,000.08
300 7 8.33 58.31
. Microsoft Office 2000.
. Microsoft Advanced Server 2000. 400 124 11.11 1,377.64
. Crystal Report 8.5.
. Rational Rose.
Vida útil del software (36 meses).
TOTAL SERVICIOS POR SOFTWARE 3,019.48
Tabla 2.7 Costo Utilización de Software
Costo por Materiales

Costo ($)
Recurso Cantidad Unidad
Unid. Total
UTILES DE ESCRITORIO
. Tres (03) millares de papel bond
3 Millar 12.18
tamaño A4 de 80 gr. 4.06
. Un (01) ciento de papel bulki tamaño
1 Ciento 0.72
oficio. 0.72
. Cinco (05) lapiceros. 5 Unidad 0.28 1.40
3 Unidad 2.60 7.80
. Tres (03) correctores.
. Un (01) resaltador. 1 Unidad 1.16 1.16
6 Unidad 0.28 1.68
. Seis (06) fólderes manila.
. Un (01) portamira. 1 Unidad 2.03 2.03
2 Unidad 1.16 2.32
. Dos (02) cajas de carboncillos.
. Un (01) engrapador. 1 Unidad 2.32 2.32
1 Unidad 1.74 1.74
. Un (01) perforador.
90
. Un (01) porta clips. 1 Unidad 1.44 1.44

1 Unidad 0.58 0.58
. Una (01) caja clips.
. Una (01) goma en barra UHU. 1 Unidad 0.87 087
1 Unidad 0.58 0.58
. Una (01) cinta scotch.
. Dos (02) plumones para escritura
2 Unidad 1.16 2.32
pizarra acrílica.
SUB TOTAL 20.98
Tabla 2.8 Costo por Materiales
Costo ($)
Recurso Cantidad Unidad Unid. Total
SUMINISTRO DE COMPUTO
. Dos (02) cajas de diskettes 3M de
2 Caja 6.00 12.00
1.44 MB.
. Una (01) caja de CD-ROM. 1 Caja 31.00 31.00
. Tres (03) tintas para Impresora Canon
S200X de color negro. 3 Unidad 10.00 30.00
. Tres (03) tintas para Impresora Canon
i250 de color negro. 3 Unidad 10.00 30.00
. Tres (03) tinta para impresora Canon
i250 de colores. 3 Unidad 15.00 45.00
SUB TOTAL 72.00
TOTAL MATERIALES 273.27
Tabla 2.9 Costo por Materiales
91
Costos por Servicios
Costo ($)
Concepto Cantidad Unidad Unid. Total
SERVICIOS GENERALES
. Servicio de tipeo. 5 Juego 23.00 115.00
5 Unidad 4.00 20.00
. Servicio de empastado.
. Servicio de fotocopiado. 2000 Hojas 0.01 20.00
10 Anillado 1.01 10.1
. Servicio de anillado.
. Servicio de acceso a internet. 75 Hora 0.58 43.50
100 Llamada 1.14 114.00
. Servicio de telefonía local.
. Servicio de telefonía celular. 55 Llamada 0.29 15.95
250 Servicio 0.23 57.5
. Servicio de transporte de bus.
. Servicio de transporte de taxi. 30 Servicio 0.58 17.4
TOTAL SERVICIOS GENERALES 413.45

Tabla 2.10 Costo por Servicios
Costos por bibliografía
Costo ($)
Concepto Cantidad Unidad Unid. Total
. Un (01) libro de Visual Basic 6.0. 1 Unidad 6.67 6.67
. Un (01) libro de SQL Server. 1 Unidad 20 20
TOTAL BIBLIOGRAFÍA 26.67
Tabla 2.11 Costo por Bibliografía
92
Resumen total de los costos:
DESCRIPCIÓN DE LOS RECURSOS Total ($)

SERVICIOS PREFESIONALES (Ver Tabla 2.5)
3,226.00
SERVICIOS HARDWARE Y EQUIPOS (Ver Tabla 2.7) 1,709.00
SERVICIOS POR SOFTWARE (Ver Tabla 2.8) 3,019.48
MATERIALES (Ver Tabla 2.10) 273.27
SERVICIOS GENERALES (Ver Tabla 2.11) 413.45
BIBLIOGRAFIA (Ver Tabla 2.12 26.67
TOTAL DE ESTIMACIÓN DE COSTOS 8667.87
Tabla 2.12 Total de Estimación de Costos
J. Análisis del Entorno

a. Fortalezas
 Excelente calidad de sus suelos, clima y temperatura ideal para el
cultivo de la caña de azúcar.
 Bajo régimen pluviométrico, facilitando la cosecha todo el año.
 Difusor y trapiches (2 líneas).
 Liderazgo y Tecnología de campo e ingenio.
 Talleres y maestranza.
b. Debilidades
 Bajos rendimientos de campo (90 Ton/Ha).
 Baja eficiencia de fábrica (trabaja a un 50%).
 Pérdidas económicas desde 1,979.
 Quiebra de autoridad y disciplina.
 Altos costos del azúcar, 90 soles la bolsa se vende 67 soles.
 La no realización de paradas anuales de fábrica de fábrica por más
de 10 años.
93
c. Amenazas
 Pérdida de patrimonio.
 Pérdida del mercado local. Importaciones de azúcar a bajos precios.
 Pérdidas económicas anuales acumuladas
En 129 años (1979 - 1997) se tiene una pérdida total acumulada en
Dólares de $ 467’196,87 (en dólares).
Pérdida del ejercicio 1,998 (en soles) S/. 213’632,487
Pérdida del ejercicio 1,999 (en soles) S/. 90’188,397
d. Oportunidades
 Plantaciones de caña de terceros.
 Fábrica diseñada para moler 10,000 Ton., de caña/Ha. Y obtener
1,000 Ton. de azúcar/día.
 Subproductos para lanzar proyectos rentables.
 Alcohol etílico.
 Esteres.
 Pulpa y papel.
 Ácido aconítrico.
 Butanol.
 Acetona.
 Ácido láctico.
K. Factores Críticos de Éxito

Para que el Sistema de Información Ejecutivo de Producción tenga éxito, se
fundamenta los siguientes factores críticos de éxito en los siguientes puntos:
 Comprometer a los altos ejecutivos a fomentar su implementación.
 Pedir al ejecutivo la asignación de un ejecutivo operativo con quien
coordinaremos las actividades entre los altos ejecutivos, así como con
los especialistas en información gerencial.
 Contar con un especialista en información gerencial (aquel que
usualmente genera la información requerida por el ejecutivo) con el fin
94
de asegurar que el SIE entregue la información a los altos ejecutivos y

sea la correcta de acuerdo a los requerimientos de los mismos.
 Incluir en la implementación del SIE la tecnología de información
(hardware y software) necesaria y apropiada.
 Construir una base de datos multidimensional (Datawarehouse) con
mecanismos que filtren y consoliden la información relevante e
importante de acorde a los requerimientos del usuario final.
 Implementar el SIE de Producción, utilizando gráficos para mostrar la
información requerida.
 Permitir al ejecutivo la toma de decisiones en el momento oportuno.
L. Indicadores de Gestión
De acuerdo a las entrevistas realizadas (Anexo A), se encontraron los
siguientes indicadores:
Indicadores Generales de la Gerencia de Campo

 Cantidad de Hectáreas preparadas, cosechadas y sembradas.
 Cantidad invertida en mano de obra para la preparación, siembra
y cosecha.
 Cantidad invertida en insumos para la preparación, siembra y
cosecha.
 Cantidad invertida en los vehículos para la preparación, siembra
y cosecha.
INDICADOR CONSULTAS UNIDAD
Cuál es la cantidad de hectáreas preparadas para los
Cantidad de Hectáreas diferentes tipos de caña producidas en una determinada
Hectáreas
preparadas zona o anexo o campo en los diferentes meses,
trimestres y años.
Cuál es la cantidad de hectáreas sembradas para los
Hectáreas
sembradas zona o anexo o campo en los diferentes meses,
trimestres y años.
Cuál es la cantidad de hectáreas cosechadas para los
Hectáreas
cosechadas zona o anexo o campo en los diferentes meses,
trimestres y años.
Cantidad invertida en Conocer la cantidad invertida para los tipos de insumo Soles
95
la preparación usados en la preparación en los diferentes campos de un

anexo de una zona determinada en el año, trimestre o año
vigente.
Conocer la cantidad invertida para los tipos de insumo

Cantidad invertida en usados en la siembra en los diferentes campos de un
Soles
la siembra anexo de una zona determinada en el año, trimestre o
año vigente.
Conocer la cantidad invertida para los tipos de insumo
Cantidad invertida en usados en la cosecha en los diferentes campos de un
Soles
la cosecha anexo de una zona determinada en el año, trimestre o
año vigente.
inversión en mano de Cuál es el costo de la mano de obra por campo, zona y
obra para la anexo en un mes o trimestre de un año específico para la Soles
preparación preparación.
Cuál es el costo de la mano de obra por campo, zona y
inversión en mano de
anexo en un mes o trimestre de un año específico para la Soles
obra para la Siembra
siembra.
Cuál es el costo de la mano de obra por campo, zona y
Inversión en mano de
anexo en un mes o trimestre de un año específico para la Soles
obra para la cosecha
cosecha.
Cantidad invertida en Determine los niveles de inversión de transporte para la
los vehículos para la preparación utilizado por zona, anexo y campo en un Soles
preparación período determinado.
Cantidad invertida en Determine los niveles de inversión de transporte para
los vehículos para la siembra utilizado por zona, anexo y campo en un período Soles
siembra determinado.
Cantidad invertida en Determine los niveles de inversión de transporte para la
los vehículos para la cosecha utilizado por zona, anexo y campo en un período Soles
cosecha determinado.
Cantidad invertida en
Determinar el costo de transporte por tipo de caña en la
los vehículos para la Soles
preparación por períodos determinados.
preparación
siembra por períodos determinados.
siembra
cosecha por períodos determinados.
cosecha
Cuál es el costo de personal por zonas, anexos o
mano de obra para la
campos en un período de tiempo determinado, ya Soles
preparación sea mensual, trimestral o anual para la preparación.

siembra sea mensual, trimestral o anual para la preparación.

cosecha sea mensual, trimestral o anual para la preparación.
96
M. Política Establecidas Para los Indicadores de Gestión

La forma de evaluar y las políticas establecidas para los indicadores,
está dada por el Gerente General de Empresa Agroindustrial Casa
Grande S.A.A.
A continuación, haremos una descripción detallada de la política para
obtener los indicadores de gestión:
Para el caso de la comparación entre cantidad de hectáreas (preparadas,
sembradas y cosechadas), el INDICADOR OBTENIDO es el
coeficiente que resulta de la comparación del RESULTADO obtenido
con el SIE, con la META establecida por la gerencia.
LA meta es establecida de acuerdo con proyecciones que se realizan a
nivel Gerencial.
Re sultado
Indicador Obtenido = Coeficiente 1 
Meta
INTERPRETACIÓN
INDICADOR
UNIDAD INDICADOR META RESULTADO OBTENIDO M R B
Propuesta
Hectáreas Hectáreas 1 por la Obtenido con el SIE. Coeficiente < 0.4 0.5 - 0.8 > 0.8
Gerencia.
Tabla 2.13 Ejemplo Indicadores de Gestión
CRITERIO DE EVALUACIÓN
INTERPRETACIÓN CRITERIO COLOR DEL SEMÁFORO

> 0.8 Bueno Verde
0.5 - 0.8 Regular Amarillo
< 0.4 Malo Rojo
Tabla 2.14 Criterio de Evaluación
En el caso de la comparación de los costos, el INDICADOR

OBTENIDO es el coeficiente que resulta de la comparación del
97
RESULTADO obtenido con el SIE, con la META establecida por la

gerencia.
Re sultado
Indicador Obtenido = Coeficiente 2 
Meta
INDICADOR INTERPRETACIÓN
UNIDAD INDICADOR META RESULTADO
OBTENIDO M R B
Costos de
Soles 1 150,000 180,000 1,2 >1.03 0.8-1.03 <0.8
Transporte
Mano de
Soles 1 100,000 92,000 0,92 >1.03 0.8-1.03 <0.8
Obra
Vehículo Soles 1 100,000 60,000 0,60 >1.03 0.8-1.03 <0.8
Personal Soles 1 >1.03 0.8-1.03 <0.8

CRITERIO DE EVALUACIÓN
INTERPRETACIÓN CRITERIO COLOR DEL SEMÁFORO

< 0.8 Bueno Verde
0.8 –1.03 Regular Amarillo
>1.03 Malo Rojo
98
2.4. CREACIÓN DEL SISTEMA Y PRESENTACIÓN DEL
PROTOTIPO
2.4.1. DISEÑO E IMPLEMENTACIÓN DE LA BASE DE DATOS

ESTRATÉGICA
Para el desarrollo e implementación de la base de datos estratégica,

construiremos un Data Mart, para lo cual se utilizó la metodología
planteada por Ralph Kimball.
[KIM - 98]
1. PLANEACIÓN
Selección de la estrategia de implementación

Para seleccionar la estrategia de implementación tomaremos como
referencia teórica al punto 1.2.1.4.2, apartado 1, del capítulo1.
Estudiando bajo que consideraciones se elige los enfoques;
elegimos el Enfoque de abajo hacia arriba (de lo particular a lo
general) para nuestro estudio, por ser quien se adhiere a la realidad
de los escenarios de la organización ya que esta no se encuentra
todavía comprometida con la tecnología del Datawarehouse, pero
busca la evaluación tecnológica para determinar cómo, dónde, y
cuándo desplegar esta tecnología, además existe una oposición
grande y conservadora ante la nueva tecnología sin una
consideración suficiente. Esta se muestra a continuación:
Conducido por la tecnología Conducido por el negocio
Enfoque de abajo hacia arriba
Figura 2.1 Enfoque de Implementación
99
Metodología de Desarrollo
Para seleccionar este punto de la fase de la planeación tomamos
como referencia teórica el punto 1.2.1.4. del capítulo 1.
Elegimos la Metodología de desarrollo en espiral porque no están
disponibles los requerimientos al concebir el sistema por vez
primero e implementarlo en su primera versión, y lo más
importante es el tiempo de culminación del proyecto; lo que
haremos será un proyecto que se irá mejorando de acuerdo a las
necesidades del ejecutivo.
A continuación, se presenta el método de desarrollo elegido:
Despliegue
Planeación
Construcción
Requerimientos
Análisis y Diseño
Figura 2.2 Método de Desarrollo Espiral
Ámbito de implementación
Para el ámbito de implementación de la Empresa Agroindustrial
Casa Grande S.A.A. tomaremos como área de estudio La Gerencia
de Campo.
La Gerencia de Campo, es la encargada de monitorear el
desarrollo de producción en la preparación, siembra y cosecha
brindando informes que ayuden a los Jefes de Campo (Gerente de
Campo, Sub. Gerente de Campo, Jefes de Zonas y Administradores
de Anexos) a tomar decisiones oportunas y adecuadas, como por
ejemplo a una mejor utilización del agua y una mejor aplicación de
los insumos.
100
El ámbito del proyecto del Data Mart estará determinado a partir de

la perspectiva del usuario empresarial del Data Mart.
Para lo cual se formularon las siguientes preguntas:
 ¿Cuál es el área que necesita utilizar inicialmente el Data

Mart?
 ¿Cuál es el rango de consultas empresariales a las que debe
responder inicialmente el Data Mart?
Después de haber realizado un estudio detallado de funcionamiento

de la Empresa, las respuestas obtenidas fueron las siguientes:
a) La Gerencia de Campo de la Empresa Agroindustrial Casa

Grande S.A.A. es un punto clave para aplicar decisiones
estratégicas que mejoren aún más el funcionamiento y
producción de la Empresa.
b) El rango de consultas empresariales que debe responder
inicialmente el Data Mart es de 18 a 20 consultas.
Enfoque Arquitectónico
El enfoque arquitectónico que se ha elegido para la construcción

del Datawarehouse es la arquitectura de referencia.
Se seleccionó esta arquitectura porque permitirá integrar en una
clasificación común los distintos tipos de información necesarios
para construir el Datawarehouse. La referencia significa que la
arquitectura es independiente de un distribuir y caracteriza la
naturaleza “genérica” de todos los Datawarehouse.
101
ARQUITECTURA DE REFERENCIA
Administración de Datos
Fuentes de Creación del Creación del Acceso y Uso
Datos Datawarehouse Mercado de del
Datos Datawarehouse
Administración de Metadatos
Transporte
Infraestructura
Figura 2.3 Arquitectura de referencia de Datawarehouse
Presupuesto del proyecto para la BD

El presupuesto para el desarrollo de la base de datos estratégica
(DATA MART), está incluido en el análisis realizado en la parte
2.3. Sección H.
2. DETEMINACION DE LOS REQUERIMIENTOS

Para identificar los requerimientos de información dentro de la
institución, se ha utilizado el instrumento de la observación
pudiendo ser observador cercano de todo el proceso que pasan los
datos para convertirse en información para los altos ejecutivos de la
empresa, que soporten cada una de sus decisiones de acuerdo a las
necesidades de la misma, concluyendo que éstas no son confiables
por presentar errores en su confección; así como también de
entrevistas formales con los Gerentes, quienes explicaron sus
necesidades de ser suministrados de información rápida, verídica,
histórica y consolidada, de cada uno de las actividades que le
brinde una visión general sobre el comportamiento de los mismos
dentro de la gerencia de campo.
102
Requerimientos del propietario

Tomando como referencia los objetivos empresariales, el ámbito y
objetivos del Datawarehouse, los requerimientos del propietario
son:
 Implementar un sistema de información que proporcione a la
alta gerencia de información en tiempo real los índices de
gestión gerencial que ayude a mejorar considerablemente el
proceso de la toma de decisiones.
 Promover en el personal de mando medio y alto actitudes
gerenciales nuevas, inyectándoles el espíritu de equipo de
trabajo, para enfrentar los desafíos de la introducción de nuevas
tecnologías de información.
 Establecer un marco de referencia y un conjunto de estándares
que sean críticos para la eficiencia del Datawarehouse.
 Acceder en tiempo real a las variables que definen el estado de
la institución.
Requerimientos del arquitecto

 Extraer datos importantes y de trascendencia de los
operacionales u externos para ser cargados o transformados y
luego almacenarlos en el Datawarehouse.
 Limpiar y/o transformar los datos operacionales para estar
estandarizados al momento de la carga del Datawarehouse.
 Añadir a toda información extraída la fecha de los datos
operacionales.
 Utilizar aplicaciones de acceso rápido, confiables que tengan un
soporte en el mercado local.
 Implementar una arquitectura del Datawarehouse de manera
central, de tal forma que soporte todos los requerimientos de
información de toda la institución.
103
Requerimientos del desarrollador

 Identificar las tablas de hechos, ya que es posible tener más de
una. Por cada aspecto del negocio que interese estudiar, debe
aparecer una tabla de hechos.
 Identificar las tablas de dimensiones de acuerdo a la base de
datos BDCasaGrandeSAA (esto decir, cuáles son los
parámetros que interesa realizar el estudio).
 Comprobar que ninguna tabla de hechos oculta tabla de
dimensiones. Al heredar la estructura de las bases de datos
operacionales, esto ocurre muy a menudo, al encontrarnos que
no se han eliminado atributos que ya no interesan.
 Comprobar que ninguna de las tablas de dimensiones oculta una
tabla de hechos. Esto conducirá a la tabla a un crecimiento
anormal muy por encima de los límites aceptables para este tipo
de tablas.
 Mantener la consistencia, confiabilidad y actualidad de la
información.
 Manejar los metadatos y el metamodelo del Datawarehouse.
 Asegurar que los mecanismos de transporte, base de datos,
computadoras y mecanismos de comunicación estén listos y
disponibles todo el tiempo.
 Proporcionar soporte técnico inmediato y capacidad de ayuda
en línea para asistir a los usuarios cuando falle el sistema o
cuando tengan preguntas operacionales.
 Mejorar el tiempo de respuesta de acceso. Se obtienen mejoras
en el desempeño mediante una recuperación eficiente, así como
por medio del manejo del tamaño de los datos que debe
mantener el Datawarehouse.
 Implementar el sistema con protección de seguridad contra
pérdida y/o uso no autorizado de los recursos del sistema.
 Extraer, filtrar, consolidar y visualizar los datos críticos de la
evolución de la gerencia de campo de la institución.
104
 Separar lógica y física la base de datos operacional de la del

almacén de datos (DW).
Requerimientos del usuario final

 Contar con información operacional que sea “clara y real” de
manera que simplifique el análisis.
 Obtener información histórica en un lenguaje entendible de
modo coherente y lógico, permitiendo entender rápidamente la
información.
 Presentar la información, incorporando simultáneamente:
gráficos, tablas, permitiendo imprimir algunos datos
gerenciales.
 Implementar una Interface amigable con el usuario, necesitando
de un mínimo de entrenamiento para su uso.
3. ANÁLISIS
En esta parte se hará un análisis de cada requerimiento del usuario
final y definiendo algunas tablas de la base de datos operacional de
la parte de la Gerencia de Campo de la Empresa Agroindustrial
Casa Grande S.A.A que actuarían como dimensión dentro del Data
Mart. También se definirá las posibles mediciones dentro del Data
Mart.
a. ANÁLISIS DE LA VISIÓN DE ARRIBA HACIA ABAJO

 Definición de las Consultas Empresariales
A continuación, empezaremos a definir nuestro Esquema del
Datawarehouse sintetizando las áreas tema, que se obtienen
de las consultas empresariales que a continuación traemos de
páginas anteriores; empezando a marcar en base a los aspectos
que son de interés para la institución:
105
CONSULTAS EMPRESARIALES
NRO CONSULTAS UNIDAD
Cuál es la cantidad de hectáreas preparadas para los diferentes
1. tipos de caña producidas en una determinada zona o anexo o Hectáreas
campo en los diferentes meses, trimestres y años.
Cuál es la cantidad de hectáreas sembradas para los diferentes tipos
2. de caña producidas en una determinada zona o anexo o campo en Hectáreas
los diferentes meses, trimestres y años.
Cuál es la cantidad de hectáreas cosechadas para los diferentes
3. tipos de caña producidas en una determinada zona o anexo o Hectáreas
campo en los diferentes meses, trimestres y años.
Conocer la cantidad invertida para los tipos de insumo usados en la
4. preparación en los diferentes campos de un anexo de una zona Soles
determinada en el año, trimestre o año vigente.
5. siembra en los diferentes campos de un anexo de una zona Soles
6. cosecha en los diferentes campos de un anexo de una zona Soles
7. Cuál es el costo de la mano de obra por campo, zona y anexo en un
Soles
mes o trimestre de un año específico para la preparación.
Soles
mes o trimestre de un año específico para la siembra.
Soles
mes o trimestre de un año específico para la cosecha.
Determine los niveles de inversión de transporte para la
10. preparación utilizado por zona, anexo y campo en un período Soles
determinado.
11. Determine los niveles de inversión de transporte para siembra
Soles
utilizado por zona, anexo y campo en un período determinado.
12. Determine los niveles de inversión de transporte para la cosecha
Soles
13. Determinar el costo de transporte por tipo de caña en la
Soles
preparación por períodos determinados.
14. Determinar el costo de transporte por tipo de caña en la siembra
Soles
por períodos determinados.
15. Determinar el costo de transporte por tipo de caña en la cosecha
Soles
Cuál es el costo de personal por zonas, anexos o campos en un
16. período de tiempo determinado, ya sea mensual, trimestral o anual Soles
para la preparación.
para la siembra.
106
 Definir las Áreas Tema, a partir de las Consultas

Empresariales
Combinando los términos tema de las consultas empresariales y
teniendo en cuenta que El proceso comercial a modelar dentro
de la empresa será la producción de caña: las áreas tema a
partir de las consultas empresariales de producción son:
Geografía
Tiempo
Producto
Estado de Campo
Personal
Vehículo
Insumo
b. ANÁLISIS DE LAS FUENTES DE DATOS

 Estructuras de tablas de la base de datos CasaGrande
Utilizando la técnica tradicional para modelar conceptualmente
la realidad, utilizaremos el Modelo Entidad / Relación de la
base de datos BDCasaGrandeSAA), con la cual
construiremos posteriormente la base de datos
multidimensional, que integra los datos de toda el área de
producción de esta empresa el cual es nuestro foco de estudio.
 Elección de la herramienta Microsoft SQL Server 2000

Para la extracción y filtración de datos de la base de datos
operacional BDCasaGrandeSAA a la base de datos del
Datawarehouse CasaGrande Mart así como la administración y
gestión de la misma. Por lo que la mejor herramienta para lo
mencionado anteriormente se ajusta a las necesidades y
requerimientos de la misma, utilizamos SQL Server 2000 por
las siguientes razones:
107
 Permite hacer copias de seguridad activas en línea de alto

rendimiento, con un impacto mínimo en los sistemas en
funcionamiento.
 Cuenta con un optimizador de consultas con múltiples fases,
permitiendo buscar de esta manera el plan óptimo para
consultas y mejorar el rendimiento de consultas complejas.
 Permite realizar importaciones y transformaciones de datos
mediante una herramienta llamada DTS, obteniendo para ello
los datos de diversos tipos de bases de datos de origen múltiples
y heterogéneos, tanto de manera interactiva como automática.
 Por ser un producto de mayor difusión y conocimiento en el
mercado que hace posible su menor costo de compra a
comparación de otros productos, así como el menor costo en
soporte.
 Servicio de Transformación de Datos (DTS)
Utilizaremos los servicios de transformación de datos (DTS,
Data Transformation Services) porque proporcionan
funcionalidad para importar, exportar y transformar datos entre
Microsoft SQL Server 2000 y cualquier formato de archivo
OLE DB, ODBC o de texto, utilizaremos este servicio por las
razones siguientes:
 Genera almacenes y puestos de datos en Microsoft SQL Server
al importar y transferir los datos desde varios orígenes
heterogéneos interactivamente o automáticamente en función de
una programación regular.
 Crea objetos de transformación personalizada que pueden
integrarse con productos de otras compañías.
 Tener acceso a aplicaciones mediante proveedores de OLE DB
de otras compañías. Esto permite que las aplicaciones para las
que existe un proveedor del OLE DB se utilicen como origen y
destino de datos.
 Crea transformaciones personalizadas.
108
Figura 2.4 Base de Datos Transaccional
109
c. ANÁLISIS DEL DATAWAREHOUSE

Después de haber estudiado las diferentes técnicas se concluyó que
para el modelado del Datawarehouse, para nuestro estudio se eligió
el Esquema Estrella, por las razones siguientes:
 Crea un BD con tiempos de respuesta rápidos.
 Proporciona un diseño fácil de modificar.
 Simula como “ven” los datos de los metadatos.
 Simplifica la navegación de los metadatos.
 Facilita la interacción con herramientas frontales.
 Tabulación de las fuentes de datos y del área tema

Teniendo en consideración que la base de datos operacional
BDCasaGrandeSAA es el único origen de datos para el
componente de almacenamiento físico de la DW, realizamos la
tabulación de tecnología de fuente de datos y del área de temas.
Área Tema Fuente Tecnología Objeto
GEOGRAFÍA BD BDCasaGrandeSAA GEOGRAFÍA Tabla

TIEMPO BD BDCasaGrandeSAA TIEMPO Tabla
PRODUCTO BD BDCasaGrandeSAA PRODUCTO Tabla
ESTADO DE CAMPO BD BDCasaGrandeSAA ESTADO DE CAMPO Tabla
PERSONAL BD BDCasaGrandeSAA PERSONAL Tabla
VEHÍCULO BD BDCasaGrandeSAA VEHÍCULO Tabla
Tabla 2.17 Tabulación de objetos de tecnología de fuentes de datos por áreas Tema
110
 Confección de atributos, dimensiones, tablas de hechos y tablas

factuales del Datawarehouse
 Realizando el estudio para que el DW cumpla con las
consultas empresariales elegimos las siguientes dimensiones
que se aplicarán a cada registro de la tabla de hechos,
describiendo de esta manera todos los atributos
dimensionales de tipo texto discreto, que llenarán cada tabla
dimensional. A continuación, presentamos las dimensiones
elegidas para nuestro estudio:
Atributos de la Tabla DIMENSIONES

Zona Marca Anual
Anexo Placa Trimestre
Cuartel Tipo Insumo Mes
TipoCaña NombreInsumo Fecha
CodCaña Ins_codigo NomEstadoCampo
TipoVehículo Categoría EstCampo_codigo
TipoEmleado
Tabla 2.18 Atributos de las Tablas Dimensiones
 Realizando la respectiva técnica anteriormente señalada,

elegimos los hechos mesurables que poblarán cada registro
de la tabla de hechos. Nuestros hechos mesurables son
cantidades numéricas similares a costo de transporte,
cantidad de hectáreas, costo mano de obra, etc. A
continuación, mostramos los hechos:
 Por cada una de una de nuestras tablas Dimensiones que
serán enlazadas en la Tabla de Hechos se describe a
continuación los nombres de las Tablas Dimensiones:
111
Nombre de las Tablas Dimensiones
Geografía_Dim Vehículo_Dim Tiempo_Dim

Producto_Dim Insumo_Dim EstadoCampo_Dim
Personal_Dim
Tabla 2.19 Nombre de las Tablas Dimensiones
 Para nuestro estudio las tablas fact, las denominaremos

Fact_Vehículo, Fact_Insumos, Fact_Personal que son las
que poseen los datos (hechos) sobre las diferentes
combinaciones de las dimensiones y su clave primaria de
esta tabla, se crea combinando las claves primarias de las
Dimensiones que han sido elegidas en el área tema a partir
de las consultas empresariales.
112
Figura 2.5 Diseño Físico de la Base de Datos del Data Mart
113
d. VISIÓN DE LAS CONSULTAS EMPRESARIALES

Para este punto se modelará mediante el Modelo Starnet, el cual
permite capturar el “molde” de una consulta y ubicaremos
actividades como las de profundización y adición. El modelo
Starnet proporcionará un inicio de abajo hacia arriba para el
modelado del Datawarehouse, con base en el análisis de
consultas empresariales.
 Construcción del Modelo STARNET
Reuniendo todas las dimensiones anteriormente descritas,
resulta el Modelo Starnet (Red Estrella), como se muestran
en las figuras:
MODELO STARET: VEHÍCULO
GEOGRAFÍA
PRODUCTO
Zona
Anexo
Tipo caña
Cuartel
Año Trimestre Mes Semana
TIEMPO Nombre estado de ESTADO DE

campo CAMPO
Placa
Marca
Condición
Tipo
vehiculo
VEHICULO
Figura 2.6 Modelo Starnet Vehículo
114
MODELO STARNET: PERSONAL
GEOGRAFÍA
PRODUCTO
Zona
Anexo
Tipo caña
Cuartel
ESTADO
Año Trimestre Mes Semana DE CAMPO
TIEMPO
Nombre estado de
Nombre de campo
empleado
Tipo
empleado
Categoria
PERSONAL
Figura 2.7 Modelo Starnet Personal
115
MODELO STARNET: INSUMOS
GEOGRAFÍA
PRODUCTO
Zona
Anexo
Tipo caña
Cuartel
Año Trimestre Mes Semana
TIEMPO Nombre estado de ESTADO DE

campo CAMPO
Tipo
Insumo
Nombre
Insumo
INSUMO
Figura 2.8 Modelo Starnet Insumos
El modelo Starnet forma la base de desarrollo de nuestro

Datawarehouse.
 Modelamiento de las Consultas Empresariales

Para identificar que dimensiones van a formar parte de
cada consulta empresarial y tener un mejor
entendimiento, modelaremos el “molde” de cada
consulta y ubicar actividades como las de
profundización y adición.
En nuestro estudio debemos tener en cuenta que para
la construcción del Datawarehouse se confeccionará un
116
prototipo, por esta razón se tomará las siguientes consultas

empresariales para la confección de los moldes y son las
siguientes:
1. Cantidad de hectáreas preparadas para los diferentes tipos de caña producidas en

una determinada zona, anexo y campo, en los diferentes meses, trimestres y años.
Producto
Tiempo
Tipo Caña Año
Trimestre
Mes
Nº Hectáreas Semana
Preparadas
Cuartel
Anexo Geografía
Zona
2. Cantidad de hectáreas sembradas para los diferentes tipos de caña producidas en

una determinada zona, anexo y campo, en los diferentes meses, trimestres y años.
Producto
Tipo caña
Tiempo
Año
Cantidad de Trimestre
hectáreas Mes
sembradas
Cuartel
Anexo Geografía
Zona
117
3. Cuál es la cantidad de hectáreas cosechadas para los diferentes tipos de caña

producidas en una determinada zona o anexo o campo en los diferentes meses,
trimestres y años.
Producto
Tipo caña
Tiempo
Año
Cantidad de Trimestre
hectáreas Mes
cosechadas
Cuartel
Anexo Geografía
Zona
4. Conocer la cantidad invertida para los tipos de insumo usados en la preparación

en los diferentes campos de un anexo de una zona determinada en el año,
trimestre o año vigente.
Insumo
Tipo insumo
Estado Campo
Tiempo
Estado Campo Año
Trimestre
Mes
Insumos Semana
Invertidos
Cuartel
Anexo Geografía
Zona
118
5. Conocer la cantidad invertida para los tipos de insumo usados en la siembra en

los diferentes campos de un anexo de una zona determinada en el año, trimestre o
año vigente.
Insumo
Tipo insumo
Estado Campo
Tiempo
Estado Campo Año
Trimestre
Mes
Insumos Semana
Invertidos
Cuartel
Anexo Geografía
Zona
6. Conocer la cantidad invertida para los tipos de insumo usados en la cosecha en

año vigente.
Insumo
Tipo insumo
Estado Campo
Tiempo
Estado Campo Año
Trimestre
Mes
Insumos Semana
Invertidos
Cuartel
Anexo Geografía
Zona
119
7. Cuál es el costo de la mano de obra por campo, zona y anexo en un mes o

trimestre de un año específico para la preparación.
Personal
Estado Campo
Categoría
Estado Campo
Tipo Empleado
Tiempo
Nombre del Empleado Año
Trimestre
Mes
Costo Mano de Semana
Obra
Cuartel
Anexo Geografía
Zona

trimestre de un año específico para la siembra.
Personal
Estado Campo
Categoría
Estado Campo
Tipo Empleado
Tiempo
Trimestre
Mes
Obra
Cuartel
Anexo Geografía
Zona
120

trimestre de un año específico para la cosecha.
Personal
Estado Campo
Categoría
Estado Campo
Tipo Empleado
Tiempo
Trimestre
Mes
Obra
Cuartel
Anexo Geografía
Zona
10. Determine los niveles de inversión de transporte para la preparación utilizado por
zona, anexo y campo en un período determinado.
Vehículo
Estado Campo
Tipo Vehículo
Estado Campo Condición
Marca Tiempo
Año
Placa
Trimestre
Mes
Costo Semana
Transporte
Cuartel
Anexo Geografía
Zona
121
11. Determine los niveles de inversión de transporte para siembra utilizado por zona,
anexo y campo en un período determinado.
Vehículo
Estado Campo
Tipo Vehículo
Marca Tiempo
Año
Placa
Trimestre
Mes
Costo Semana
Transporte
Cuartel
Anexo Geografía
Zona
12. Determine los niveles de inversión de transporte para la cosecha utilizado por
Vehículo
Estado Campo
Tipo Vehículo
Marca Tiempo
Año
Placa
Trimestre
Mes
Costo Semana
Transporte
Cuartel
Anexo Geografía
Zona
122
13. Determinar el costo de transporte por tipo de caña en la preparación por períodos
determinados.
Vehículo
Estado Campo
Tipo Vehículo
Marca Tiempo
Año
Placa
Trimestre
Mes
Costo Semana
Transporte
Cuartel
Anexo Geografía
Zona
14. Determinar el costo de transporte por tipo de caña en la siembra por períodos
determinados.
Vehículo
Estado Campo
Tipo Vehículo
Marca Tiempo
Año
Placa
Trimestre
Mes
Costo Semana
Transporte
Cuartel
Anexo Geografía
Zona
123
15. Determinar el costo de transporte por tipo de caña en la cosecha por períodos
determinados.
Vehículo
Estado Campo
Tipo Vehículo
Marca Tiempo
Año
Placa
Trimestre
Mes
Costo Semana
Transporte
Cuartel
Anexo Geografía
Zona
16. Cuál es el costo de personal por zonas, anexos o campos en un período de tiempo
determinado, ya sea mensual, trimestral o anual para la preparación.
Personal
Categoria
Tipo Estado Campo
Tiempo
Estado Campo Año

Nombre
Trimestre
Mes
Costo de Semana
Personal
Cuartel
Anexo Geografía
Zona
124
determinado, ya sea mensual, trimestral o anual para la siembra.
Personal
Categoria
Tipo Estado Campo
Tiempo
Estado Campo Año

Nombre
Trimestre
Mes
Costo de Semana
Personal
Cuartel
Anexo Geografía
Zona
determinado, ya sea mensual, trimestral o anual para la cosecha.
4.
Personal
Categoria
Tipo Estado Campo
Tiempo
Estado Campo Año

Nombre
Trimestre
Mes
Costo de Semana
Personal
Cuartel
Anexo Geografía
Zona
125
4. DISEÑO Y MODELIZACION
Diseño del Data Mart

Recordemos que nuestro proyecto está enfocado a un área específica de
empresa, como es la gerencia de campo, por consiguiente, es
importante construir la Base de Datos Multidimensional que lo soporte,
para ello estamos utilizando las fases del Ciclo de Vida de un Data
Warehouse (Data Mart) de Ralph Kimball.
DISEÑO LÓGICO
Esta parte llamada Modelamiento Dimensional, busca presentar los
datos en un marco de trabajo estándar.
Identificaremos los Componentes del Modelo desarrollando el Método
de los Cuatro Pasos. Luego, se construirá el primer diagrama para el
modelo y se detallará cada componente del diagrama.
IDENTIFICACIÓN DE LOS COMPONENTES

Para identificar los componentes utilizaremos el método propuesto por
Ralph Kimball.
El Método de los Cuatro Pasos
Consiste en cuatro elecciones:
 Elección del Data Mart.

 Elección del Objetivo de la Tabla de Hechos.
 Elección de las Dimensiones.
 Elección de los Hechos.
126
Cada paso está desarrollado a continuación:
1. Elección del Data Mart

En este paso identificaremos los posibles Data Mart que se
pueden construir en la Empresa. En nuestro caso
identificaremos el área que está en estudio por este proyecto, el
cual ya tenemos conocimiento sobre su Modelo General de
Datos, pero hacemos mención de otras posibles áreas que serían
objeto de otro estudio.
Entonces, para identificar nuestra Base de Datos Estratégica en
estudio recurrimos al siguiente método:
 Método de la Matriz
Menciona los posibles hechos relacionados y que son usados
juntos. Listamos las entidades que apoyan a estos hechos.
 Listado de los Data Marts

Según la situación general de la Empresa, se identificó las
posibles fuentes de Data Marts que corresponderán a las filas de
la matriz:
Gerencia de Campo.
Gerencia de Ingenio.
Gerencia Administrativa.
 Listado de Dimensiones
Para los posibles Data Mart mencionados anteriormente
listamos las siguientes posibles dimensiones:
Geografía
Tiempo
Producto
127
Estado de Campo
Personal
Vehículo
Labor
Insumo
 Marcado de las Intersecciones

Ordenamos las filas y las columnas en una tabla, dando forma a
la matriz, y marcamos las intersecciones donde exista una
dimensión relacionada a un Data Mart.
de
Geografía
Vehículo
Producto
Personal
Tiempo
Insumo
Campo
Estado
Labor
Gerencia de Campo        
Gerencia de Ingenio     
Gerencia    
Administrativa
Tabla 2.20 Matriz para Seleccionar el Data Mart
Para elegir el Data Mart seleccionaremos el encabezamiento de

una de las filas de la matriz que representa nuestro caso en
estudio, llamado Gerencia de Campo.
Para el fácil manejo de las consultas hechas por el usuario, en el
Data Mart se consideró cuatro tablas de Hechos: Vehículo,
Insumos, Labor y Personal.
128
2. Elección del Objetivo de las Tablas Hechos

Este paso consiste en declarar como es el Registro del Hecho en
las Tablas de Hechos, es decir hay que definir claramente y
exactamente que registros de cada Tabla de Hechos figurarán en
el diseño del modelado del Data Mart.
Tomamos la siguiente definición para cada Tabla de Hechos:
Tabla de Hechos Objetivo
Vehículo “Controlar la cantidad de hectáreas preparadas, sembradas y

cosechadas, y la situación de transporte.”
Insumos “Controlar el uso de los insumos.”
Personal “Controlar la situación del personal de la empresa.”
Tabla 2.21 Objetivos de las Tablas de Hechos
Al enunciar el objetivo de cada Data Mart, van a intervenir las

posibles dimensiones que se explicarán a continuación.
3. Elección de las Dimensiones

Al establecer el objetivo para cada Tabla de Hechos, podemos
escoger cuales serán nuestras dimensiones para cada una de
estas tablas. El objetivo por sí mismo establece cuales serán
nuestras dimensiones.
A continuación, por cada objetivo escogeremos las

dimensiones:
129
Tabla de Hechos Objetivos Dimensiones
Geografía
Producto
“Controlar la cantidad de hectáreas
Vehículo preparadas, sembradas y cosechadas, y Estado de Campo
el costo de transporte.” Vehículo
Tiempo
Tabla 2.22 Dimensiones de Tabla de Hechos Vehículo
Tabla de Hechos Objetivos Dimensiones

Geografía
Producto
Insumos “Controlar el uso de los insumos.” Tiempo
Estado de Campo
Insumo
Tabla 2.23 Dimensiones de Tabla de Hechos Insumos
Tabla de Objetivos Dimensiones

Hechos
Geografía
Producto
“Controlar la situación del personal de
Personal Estado de Campo
la empresa. ”
Personal
Tiempo
Tabla 2.24 Dimensiones de Tabla de Hechos Personal
Como se puede ver la mayoría de las dimensiones elegidas

pertenecen a las Entidades del Método de Datos General
descritos anteriormente. Otras dimensiones son la unión de
entidades.
130
4. Elección de los Hechos

El objetivo de cada Tabla de Hechos también permite definir
los hechos y hace claro el enlace que estos hechos deben tener.
En nuestro caso tenemos:
Tabla de Hechos Hechos
Cantidad de hectáreas preparadas. Cantidad de hectáreas

sembradas.
Cantidad de hectáreas cosechadas.
VEHÍCULO Cantidad de inversión por vehículo para la preparación.
Cantidad de inversión por vehículo para la siembra.
Cantidad de inversión por vehículo para la cosecha.
Cantidad de insumos utilizado para la preparación.
INSUMOS Cantidad de insumos utilizado para la siembra.
Cantidad de insumos utilizado para la cosecha.
PERSONAL La inversión por mano de obra.
Tabla 2.25 Hechos de cada Tabla de Hechos
DIAGRAMA DE LA TABLA DE HECHOS
Para esta etapa se prepara un diagrama lógico para cada Tabla

de Hechos completada. Cada Diagrama nombra a la Tabla de
Hechos, establece su objetivo y muestra todas las dimensiones
conectadas a las Tablas de Hechos.
131
Diagrama de la Tabla de Hechos Vehículo
TABLA DE HECHOS
VEHÍCULO
PRODUCTO ESTADO DE CAMPO
Objetivo:
“Controlar la cantidad de
hectáreas preparadas,
sembradas y cosechadas, y
TIEMPO la situación de transporte ” VAHICULO
GEOGRAFIA
Figura 2.9 Diagrama de la Tabla de Hechos Vehículo
Diagrama de la Tabla de Hechos Insumos
TABLA DE HECHOS INSUMOS

PRODUCTO ESTADO DE CAMPO
Objetivo:
“Controlar el uso de los

insumos”
TIEMPO INSUMO
GEOGRAFIA
Figura 2.10 Diagrama de la Tabla de Hechos Insumos
132
Diagrama de la Tabla de Hechos Personal
TABLA DE HECHOS
PRODUCTO PERSONAL ESTADO DE CAMPO
Objetivo:
“Controlar la situación del

personal de la empresa”
TIEMPO PERSONAL
GEOGRAFIA
Figura 2.11 Diagrama de la Tabla de Hechos Personal
Detalles de las Tablas Dimensiones

Nombre de la Tabla Nombre de la Columna Longitud Descripción de la Columna
Llave primaria única para la

Dimensión Geografía Geografia_Key 8
Dimensión Geografía

Dimensión Tiempo Tiempo_Key 8
Dimensión Tiempo

Dimensión Producto Producto_Key 8
Dimensión Producto
Dimensión Estado de Llave primaria única para la

EstadoCampo_Key 8
Campo Dimensión Estado de Campo

Dimensión Personal Personal_key 8
Dimensión Personal

Dimensión Vehículo Vehiculo_Key 8
Dimensión Vehículo

Dimensión Insumo Insumo_key 8
Dimensión Insumo
Tabla 2.26 Detalle de las claves de las Dimensiones
133
 Detalles de las Tablas Hechos
Nombre de Nombre da la Columna Longitud Descripción de la Columna

la Tabla
Hecho Cantidad de hectáreas

CantidadHectáreas 8
Vehículo preparadas.

Vehículo sembradas.

Vehículo cosechadas.
Hecho Cantidad de inversión por

CostoHectáreas 8
Vehículo vehículo para la preparación.

CostoHectáreas 8
Vehículo vehículo para la siembra.

CostoHectáreas 8
Vehículo vehículo para la cosecha.
Cantidad de insumos
Hecho
CostoInsumo 8 utilizado para la preparación.
Insumos
Hecho Cantidad de insumos

Costo Insumo 8
Insumos utilizados para la siembra
Cantidad de insumos
Hecho
CostoInsumo 8 utilizado para la cosecha.
Insumos
Hecho La inversión por mano de

CostoPersonal 8
Personal obra.
Tabla 2.27 Detalle de las Medidas de las Tablas de Hechos
134
Por consiguiente, de las dos tablas completadas anteriormente se

obtienen las siguientes Tablas de Hechos:
TABLA DE HECHOS
VEHÍCULO TABLA DE HECHOS
INSUMOS
Geografia_key
Vehículo_Key Geografia_key
Tiempo_Key Insumo_Key
EstadoCampo_Key Tiempo_Key
Producto_Key EstadoCampo_Key
Producto_Key
Cantidad de hectáreas preparadas
Cantidad de hectáreas sembradas Cantidad de insumos utilizado
Cantidad de hectáreas cosechadas para la preparación
Cantidad de inversión por Cantidad de insumos utilizado
vehículo para la preparación para la siembra
Cantidad de inversión por Cantidad de insumos utilizado
vehículo para la siembra para la cosecha
Cantidad de inversión por
vehículo para la cosecha
TABLA DE HECHOS
PERSONAL
Geografia_key
Personal_Key
Tiempo_Key
EstadoCampo_Key
Producto_Key
La inversión por mano de obra.
Tabla 2.28 Tabla de Hechos del Data Mart
135
 Detalle de las Tablas Dimensión

De acuerdo a nuestras Dimensiones elegidas anteriormente
construimos los Detalles y sus jerarquías de cada una de ellas
mostrando su cardinalidad aproximada:
Dimensión Geografía
Zona
Anexo
Cuartel
Figura 2.12 Jerarquía de los Atributos de la Dimensión Geografía
Nombre del Descripción del Cambiando Valores de

Atributo Atributo Política Muestra
Representa las zonas Casa
Zona geográficas de la No Actualizar Grande,
empresa Roma
Casa
Representa los anexos
Anexo No Actualizar Grande,
de cada zona
Mocán
Vizcaino,
Representa los campos
Cuartel No Actualizar Talambo
de cultivo de las zonas
Tabla 2.29 Detalle de Dimensión Geografía
136
 Dimensión Tiempo
Año
Trimestre
Mes
Semana
Figura 2.13 Jerarquía de los Atributos de la Dimensión Tiempo

Representa el año 1998, 1999,
Año No Actualizar
laboral 2000
Representa los Trimestre 1,
Trimestre No Actualizar
trimestres del año Trimestre 2
Enero,
Representa los meses
Mes No Actualizar Febrero
del año
Representa las semanas Semana 1,

Semana No Actualizar
del mes Semana 2
Tabla 2.30 Detalle de Dimensión Tiempo
137
 Dimensión Producto
Descripción
Figura 2. 14 Jerarquía de los Atributos de la Dimensión Producto

Caña Azul,
Representa el Tipo de
Descripción No Actualizar Caña Casa
Caña
Grande
Tabla 2.31 Detalle de Dimensión Producto
Dimensión Estado de Campo
Nombre del
Estado de
Campo
Figura 2. 15 Jerarquía de los Atributos de la Dimensión Estado de Campo

Nombre del Preparación,
Describe el nombre del
Estado de No Actualizar Siembra,
Estado del Campo
Campo Cosecha
Tabla 2.32 Detalle de Dimensión Estado de Campo
138
 Dimensión Personal
Categoría
Tipo
Empleado
Nombre
Empleado
Figura 2.16 Jerarquía de los Atributos de la Dimensión Personal

Magíster,
Representa la categoría
Categoría No Actualizar Ingeniero,
del empleado
Obrero
Sub Gerente,
Tipo de Representa el tipo de
No Actualizar Administrador,
Empleado cargo del empleado
Mayordomo
Maria, Luis,
Nombre del Representa el nombre
No Actualizar Ana
Empleado del empleado
Tabla 2.32 Detalle de Dimensión Personal
139
 Dimensión Vehículo
Tipo
Vehículo
Condición
Marca
Placa
Figura 2.17 Jerarquía de los Atributos de la Dimensión Vehículo

Trailer,
Representa el tipo de
Tipo Vehículo No Actualizar Automóvil,
vehículo de la empresa
Maquinaria
Representa la condición
Propio,
Condición del vehículo en la No Actualizar
Particular
empresa
Oshkosh,
Describe la marca del Volvo,
Marca No Actualizar
vehículo Nissan
Describe el número de PG2365,

Placa No Actualizar
placa del vehículo UE5695
Tabla 2.34 Detalle de Dimensión Vehículo
140
 Dimensión Insumo
Nombre
Insumo
Tipo Insumo
Figura 2.18 Jerarquía de los Atributos de la Dimensión Insumo

Urea,
Nombre Describe el nombre del Farmetrin -
No Actualizar
Insumo insumo 80,
Gasolina 84
Abono ,
Representa el tipo de
Tipo Insumo No Actualizar Herbicidas,
insumo
Combustible
Tabla 2.35 Detalle de Dimensión Insumo
Esquema Estrella
Sabiendo el número de Tablas de Hechos y las Dimensiones
asociadas a éstas, orientamos nuestro Data Mart al Esquema
Estrella para una mejor visualización del Modelo para el Diseño
Físico.
Para una mejor comprensión, listamos primero los componentes
que intervendrán el esquema, luego dividimos el Data Mart en
cinco gráficos: El esquema estrella de cada Tabla de Hechos y el
Diseño Lógico del Data Mart.
141
Componente: TABLA DE HECHOS VEHÍCULO

Componente: TABLA DE HECHOS INSUMOS
Componente: TABLA DE HECHOS PERSONAL
Componente: TABLA DE DIMENSIÓN GEOGRAFIA
Componente: TABLA DE DIMENSIÓN TIEMPO
Componente: TABLA DE DIMENSIÓN PRODUCTO
Componente: TABLA DE DIMENSIÓN ESTADO DE
CAMPO
Componente: TABLA DE DIMENSIÓN PERSONAL
Componente: TABLA DE DIMENSIÓN VEHÍCULO
Componente: TABLA DE DIMENSIÓN PERSONAL

-Geografia_key
Vehículo_Dim -Vehiculo_Key EstadoCampo_Dim
-Vehiculo_Key -Tiempo_Key
-EstadoCampo_Key
+Tipo Vehiculo() -EstadoCampo_Key
-Producto_Key +Nombre del Estado de Campo()
+Condicion()
+Costo Transporte()

+Descripcion()
Figura 2.19 Tabla de Hechos Vehículo
142
TABLA DE HECHOS INSUMOS

Insumo_Dim -Geografia_key
-Insumo_Key EstadoCampo_Dim
-Insumo_Key
-Tiempo_Key -EstadoCampo_Key
+Tipode Insumo() -EstadoCampo_Key +Nombre del Estado de Campo()
+Nombre del Insumo() -Producto_Key
+Cantidad()

+Descripcion()
Figura 2.20 Tabla de Hechos Insumos
TABLA DE HECHOS PERSONAL

Personal_Dim -Geografia_key
-Personal_Key -Personal_Key EstadoCampo_Dim
+Nombre del Empleado() -Tiempo_Key -EstadoCampo_Key

+Tipo Empleado() -EstadoCampo_Key +Nombre del Estado de Campo()
+Categoría() -Producto_Key
+Costo Mano Obra()

+Descripción() +Tipode Caña() +Año Mes()
+Descripcion()
Figura 2.21 Tabla de Hechos Personal
143

Vehículo_Dim -Geografia_key
-Vehiculo_Key -Vehiculo_Key
-Tiempo_Key
+Tipo Vehiculo()
-EstadoCampo_Key
+Condicion()
-Producto_Key
+Costo Transporte()
Personal_Dim
-Personal_Key
+Nombre del Empleado()
Geografía_Dim
+Tipo Empleado()
-Geografia_key TABLA DE HECHOS PERSONAL
+Categoría()
+Descripción() -Geografia_key
-Personal_Key
-Tiempo_Key
-EstadoCampo_Key
-Producto_Key
Insumo_Dim +Costo Mano de Obra()
Producto_Dim
-Insumo_Key
-Producto_Key
+Tipode Insumo()
+Nombre del Insumo() +Tipode Caña()
+Descripcion()
TABLA DE HECHOS INSUMOS Tiempo_Dim

-Geografia_key -Tiempo_Key
-Insumo_Key EstadoCampo_Dim
+Año Mes()
-Tiempo_Key -EstadoCampo_Key
-EstadoCampo_Key
+Nombre del Estado de Campo()
-Producto_Key
+Cantidad()
Figura 2.22 Esquema Estrella del Data Mart
144
DISEÑO FISICO DE LAS TABLAS PARA UN DATA

MART
Se tiene que tener en cuenta:

Modificar nombres a nombres estándar, si fuera necesario.
Para nuestro Data Mart se realizaron los siguientes cambios:
DISEÑO LÓGICO DISEÑO FÍSICO

Tabla de Hechos Vehículo Fact_ Vehículo
Tabla De Hechos Insumos Fact_Insumos
Tabla De Hechos Personal Fact_Personal
Dimensión Geografía Geografía_Dim
Dimensión Tiempo Tiempo_Dim
Dimensión Producto Producto_Dim
Dimensión Estado De Campo EstadoDeCampo_Dim
Dimensión Personal Personal_Dim
Dimensión Vehículo Vehículo_Dim
Tabla 2.36 Nombres estándares para las Tablas Hechos y Dimensiones
5. IMPLEMENTACIÓN DEL DATA MART
 DETERMINACIÓN DE LAS AGREGACIONES
Determinamos las agregaciones por defecto que tendrán cada

Hecho o Medidas en las Tablas de Hechos. La mayoría de las
reglas de agregación son sumas, como veremos a continuación:
145
Tabla de Hechos Regla de

Hechos
Agregación
Tabla_Hecho_
Cantidad_Hectáreas_Preparadas Sum
Vehículo
Tabla_Hecho_
Cantidad_Hectáreas_Sembradas Sum
Vehículo
Tabla_Hecho_
Cantidad_Hectáreas_Cosechadas Sum
Vehículo
Tabla_Hecho_
Cantidad_InversiónporVehículo_Preparación Sum
Vehículo
Tabla_Hecho_
Cantidad_InversiónporVehículo_Siembra Sum
Vehículo
Tabla_Hecho_
Cantidad_InversiónporVehículo_Cosecha Sum
Vehículo
Tabla_Hecho_ Cantidad_InsumosUtilizado_
Sum
Insumos Preparación.
Tabla_Hecho_
Cantidad_InsumosUtilizado_ Siembra. Sum
Insumos
Tabla_Hecho_ Cantidad_InsumosUtilizado_
Sum
Insumos Cosecha.
Tabla_Hecho_
Inversión_ManodeObra. Sum
Personal
Tabla 2.37 Determinación de las Agregaciones
 CONSTRUCCIÓN DE LAS TABLAS Y LA BASE DE

DATOS EN SQL SERVER
Después de haber realizado el Diseño Físico de las tablas

pasamos a la etapa de construcción de dichas tablas utilizando
SQL Server.
146
Tabla 1: Geografía_Dim
Figura 2.23 Geografía_Dim
Tabla 2: Tiempo_Dim
Figura 2.24 Tiempo_Dim
Tabla 3: Producto_Dim
Figura 2.25 Producto_Dim
147
Tabla 4: EstadoCampo_Dim
Figura 2.26 EstadoCampo_Dim
Tabla 5: Personal_Dim
Figura 2.27 Personal_Dim
Tabla 6: Vehículo_Dim
Figura 2.28 Vehículo_Dim
148
Tabla 8: Insumo_Dim
Figura 2.29 Insumo_Dim
149
Figura 2.30 Data Mart
150
 EXTRACCIÓN DE LOS DATOS Y TRANSFORMACIÓN

Para completar la construcción del Data Mart debemos poblar cada Tabla
de la Base de Datos. <como ya conocemos la estructura de cada tabla,
ahora debemos seguir los siguientes pasos para el poblamiento:
 Definición de los Pasos de Transformación.

 Definición de los Workflows.
 Creación de los Paquetes de Servicio de Transformación de Datos
(DTS).
Definición de los Pasos de Transformación

Para un correcto Doblamiento de los datos debemos
definir los Pasos de Transformación, con la unidad de
trabajo como parte de un proceso de transformación. Para
poblar el Data Mart se tiene que realizar los siguientes
pasos:
Paso 1: Limpiando Dimensiones, consiste en eliminar los datos de

todas las Dimensiones y Tablas de Hechos, paso que nos permite
asegurar de que no pueda existir duplicidad de datos.
Paso 2: Poblamiento de la Dimensión Geografía, consiste en ejecutar

una sentencia SQL, para transferir datos a la Dimensión Geografía.
Paso 3: Poblamiento de la Dimensión Tiempo, una sentencia SQL,

para transferir datos a la Dimensión Tiempo.
Paso 4: Poblamiento de la Dimensión Producto, consiste en mover

los datos de la Tabla Caña para poblar la Dimensión Producto.
151
Paso 5: Poblamiento de la Dimensión Estado de Campo, consiste en

mover los datos de la Tabla Estado Campo para poblar la Dimensión
Estado de Campo.
Paso 6: Poblamiento de la Dimensión Personal, consiste una

sentencia SQL, para transferir datos a la Dimensión Personal.
Paso 7: Poblamiento de la Dimensión Vehículo, consiste en mover

los datos de la Tabla Vehículo para poblar la Dimensión Vehículo.
Paso 8: Poblamiento de la Dimensión Insumo, una sentencia SQL,

para transferir datos a la Dimensión Insumo.
Paso 10: Poblamiento de las Tablas de Hechos.
Definición de los Workflows
Figura 2.31 Workflows de los Pasos de Transformación
152
Restricciones de Precedencia:
a) La Limpieza de las Dimensiones o Datos (Paso 1) debe realizarse al inicio

del proceso.
b) El Poblamiento de la Dimensión Geografía (Paso 2) debe realizarse sólo
cuando se tenga la seguridad de que el Paso 1 se ha ejecutado con éxito.
c) El Poblamiento de la Dimensión Tiempo (Paso 3) debe realizarse sólo
d) El Poblamiento de la Dimensión Producto (Paso 4) debe realizarse sólo
e) El Poblamiento de la Dimensión Estado de Campo (Paso 5) debe
realizarse sólo cuando se tenga la seguridad de que el Paso 1 se ha
ejecutado con éxito.
f) El Poblamiento de la Dimensión Personal (Paso 6) debe realizarse sólo
g) El Poblamiento de la Dimensión Vehículo (Paso 7) debe realizarse sólo
h) El Poblamiento de la Dimensión Insumo (Paso 8) debe realizarse sólo
i) El Poblamiento de las Tablas de Hechos (Vehículo, Insumos, Personal)
debe realizarse sólo cuando se tenga la seguridad de que el Paso
2,3,4,5,6,7,8,9,10 se hayan ejecutado con éxito.
Una vez conocido las relaciones de precedencias diagramaremos el

Workflows que se necesitará realizar al construir el paquete de poblamiento
del Data Mart, para la Gerencia de Campo de la Empresa.
153
Éxito
PASO 1 PASO 2
Éxito
PASO 3
Éxito
PASO 3
Éxito
PASO 4
Éxito
PASO 5
Éxito
PASO 6
Éxito
PASO 7
Éxito
PASO 8
Éxito Éxito
PASO 9 PASO 10
Figura 2.32 Diagrama Workflow con Restricciones de Precedencia
154
Creación de Paquetes de Servicio de Transformación de Datos (DTS)
Definidos los pasos de la Transformación de Datos y las Restricciones de

Precedencia; podemos crear el paquete Servicio de Transformación de
Datos (DTS); recordemos que un DTS tiene como objetivos importar,
exportar y realizar cambios en el formato de datos.
Para su construcción utilizaremos el Servicio de Transformación de Datos
SQL Server 2000, aquí los datos pueden ser almacenados en varios
formatos y en muchos lugares diferentes lo cual no es ningún problema.
Al utilizar los Servicios de Transformación de Datos (DTS) del SQL
Server 2000, se podrá importar y exportar datos entre múltiples orígenes
heterogéneos mediante una arquitectura basada en OLE DB. Los paquetes
son los objetivos principales de los Servicios de Transformación de Datos.
Basándonos en Workflow con restricciones de la figura anterior, creamos
el paquete DTS al cual llamamos “Poblamiento General Data Mart Casa
Grande”, con los pasos previos definidos así como todas sus restricciones.
155
Figura. 2.33 Paquete de Servicio de Transformación de Datos
156
Sentencias de cada paso de Workflow
Paso 1: Limpieza Datos

Añadimos una tarea al paquete al cual tendrá por nombre “Limpieza Datos”,
con la siguiente sentencia:
TRUNCATE TABLE Fact_Vehiculo

TRUNCATE TABLE Fact_Personal
TRUNCATE TABLE Fact_Insumos
DELETE FROM Geografía_Dim
DELETE FROM Tiempo_Dim
DELETE FROM Producto_Dim
DELETE FROM EstadoCampo_Dim
DELETE FROM Personal_Dim
DELETE FROM Vehículo_Dim
DELETE FROM Insumo_Dim
Esta sentencia nos permite limpiar los datos de todas las tablas de nuestro
Data Mart. Esta limpieza asegura que no exista duplicidad de datos.
157
Figura 2.34 Ventana de Código para el Paso Limpieza Datos
Paso 2: Poblamiento de la Dimensión Geografía

Para transferir los datos históricos a la Dimensión Geografía se efectúan los
siguientes pasos:
a. Definimos una sentencia SQL como origen de datos.
SELECT ZONA.Zon_Nombre, ANEXO.Anex_Nombre,

CAMPO.Camp_Nombre,
CAMPO.Camp_Codigo
FROM ANEXO INNER
JOIN
158
CAMPO ON ANEXO.Anex_Codigo =
CAMPO.Anex_Codigo
INNER
JOIN
ZONA ON ANEXO.Zon_Codigo = ZONA.Zon_Codigo
b. Determinamos la Dimensión Geografía como destino de datos.

c. En las transformaciones se determina que columnas del origen
corresponderán con las de la Dimensión destino.
Figura 2.35 Poblamiento de la Dimensión Geografía
159
Paso 3: Poblamiento de la Dimensión Tiempo

Para el poblamiento de la Dimensión Tiempo se efectúan los siguientes
pasos:

SELECT DISTINCT
Act_FecInicio AS TheDate, datepart(ww, Act_FecInicio) As semana,
DatePart(mm, Act_FecInicio) AS [Month], DatePart(yy, Act_FecInicio) AS
[Year],
DatePart(qq, Act_FecInicio) AS [Quarter], Act_FecInicio,
RTRIM(dbo.f_mes( month(Act_FecInicio))) +
'_' + convert(char(4),year(Act_FecInicio)) AS AñoMonth,
DatePart(wk, Act_FecInicio) AS WeekOfYear
FROM Actividad s
WHERE Act_FecInicio is not null
b. Determinamos la Dimensión Tiempo como destino de datos.
160
Figura 2.36 Poblamiento de la Dimensión Tiempo
Paso 4: Poblamiento de la Dimensión Producto

Para el poblamiento de la Dimensión Producto se efectúan los siguientes
pasos:
a. Se define la tabla Caña como origen de datos de la Base de Datos
Operacional.
b. Determinamos la Dimensión Producto como destino de datos.
161
Figura 2.37 Poblamiento de la Dimensión Producto
Paso 5: Poblamiento de la Dimensión Estado de Campo

Para el poblamiento de la Dimensión Estado de Campo se efectúan los
siguientes pasos:
a. Se define la tabla Estado Campo como origen de datos de la Base de
Datos Operacional.
b. Determinamos la Dimensión Estado de Campo como destino de datos.
162
Figura 2.38 Poblamiento de la Dimensión Estado de Campo
Paso 6: Poblamiento de la Dimensión Personal

Para el poblamiento de la Dimensión Personal se efectúan los siguientes
pasos:
SELECT CAT_EMPLEADO.Cat_Nombre, PERSONA.Per_Nombre,

PERSONA.Per_Apellido,
EMPLEADO.Per_Codigo, CARGO.Carg_Descripcion
FROM CARGO
INNER
JOIN
163
EMPLEADO ON CARGO.Carg_Codigo =
EMPLEADO.Carg_Codigo INNER
JOIN
CAT_EMPLEADO ON EMPLEADO.Empl_Categoria
= CAT_EMPLEADO.Empl_Categoria INNER
JOIN
PERSONA ON EMPLEADO.Per_Codigo =
PERSONA.Per_Codigo
b. Determinamos la Dimensión Personal como destino de datos.

Figura 2.39 Poblamiento de la Dimensión Personal
164
Paso 7: Poblamiento de la Dimensión Vehículo

Para el poblamiento de la Dimensión Vehículo se efectúan los siguientes
pasos:
a. Se define la tabla Vehículo como origen de datos de la Base de Datos
Operacional.
b. Determinamos la Dimensión Vehículo como destino de datos.
Figura 2.40 poblamiento de la Dimensión Vehículo
Paso 8: Poblamiento de la Dimensión Insumo

Para el poblamiento de la Dimensión Insumo se efectúan los siguientes pasos:
165
SELECT TIPOINSUMO.TipIns_Descripcion,
INSUMO.Ins_Descripcion,
INSUMO.Ins_Codigo
FROM INSUMO INNER
JOIN
TIPOINSUMO ON INSUMO.TipIns_Codigo
= TIPOINSUMO.TipIns_Codigo
b. Determinamos la Dimensión Insumo como destino de datos.

Figura 2.41 Poblamiento de la Dimensión Insumo
166
Poblamiento de las Tablas Hecho
Para poblar los datos de la tabla de hechos VEHICULO se tiene que efectuar
los siguientes pasos:
a. Efectuamos la consulta SQL.
SELECT dg.Geografia_key, dl.Vehiculo_Key, dt.Tiempo_Key,

de.EstadoCampo_Key, dp.Producto_Key, SUM(ActVeh_Costo) AS
Valor, SUM(ActVeh_Hectarea) as Hectarea
--a.act_codigo, a.camp_codigo, a.EstCamp_Codigo, va.Lab_codigo,
va.Fecha,SUM(Valor) as VLabores
FROM BDCasaGrandeSAA..actividad a INNER JOIN
BDCasaGrandeSAA..actividad_vehiculo al ON a.act_codigo =
al.act_codigo
INNER JOIN CasaGrande_Mart..Geografia_dim dg ON
a.Camp_Codigo=dg.Camp_Codigo
INNER JOIN CasaGrande_Mart..Vehiculo_dim dl ON al.Veh_Codigo
= dl.Vehiculo
INNER JOIN CasaGrande_Mart..Tiempo_dim dt ON
al.ActVeh_Fecha = dt.Fecha
INNER JOIN CasaGrande_Mart..EstadoCampo_dim de ON
de.EstCampo_Codigo = a.EstCamp_Codigo
INNER JOIN CasaGrande_Mart..Producto_dim dp ON dp.cod_caña =
a.caña_codigo
167
Figura 2.42 Poblamiento de la tabla Hechos Vehículo
Para poblar los datos de la tabla de hechos PERSONAL se tiene que

efectuar los siguientes pasos:
SELECT dg.Geografia_key, dl.Personal_Key, dt.Tiempo_Key,
de.EstadoCampo_Key, dp.Producto_Key,
SUM(EmpAct_Soles) AS Valor
va.Fecha, SUM(Valor) as VLabores
BDCasaGrandeSAA..Empleado_actividad al ON a.act_codigo =
al.act_codigo
168

a.Camp_Codigo = dg.Camp_Codigo
INNER JOIN CasaGrande_Mart..Personal_dim dl ON al.per_Codigo =
dl.Empleado
al.EmpAct_Fecha = dt.Fecha
a.caña_codigo
GROUP BY dg.Geografia_key, dl.Personal_Key, dt.Tiempo_Key,
de.EstadoCampo_Key, dp.Producto_Key
Figura 2.43 Poblamiento de la tabla de Hechos Personal
169
Para poblar los datos de la tabla de hechos INSUMO se tiene que efectuar los
siguientes pasos:

SELECT dg.Geografia_key, dl.Insumo_Key, dt.Tiempo_Key,
de.EstadoCampo_Key, dp.Producto_Key,
SUM(Act_Ins_Cantidad) AS Valor
va.Fecha, SUM(Valor) as VLabores
BDCasaGrandeSAA..Activ_Insumo al ON a.act_codigo = al.act_codigo
a.Camp_Codigo = dg.Camp_Codigo
INNER JOIN CasaGrande_Mart..Insumo_dim dl ON al.Ins_Codigo =
dl.Ins_codigo
al.Act_Ins_Fecha = dt.Fecha
a.caña_codigoGROUP BY dg.Geografia_key, dl.Insumo_Key,
dt.Tiempo_Key, de.EstadoCampo_Key,p.Producto_Key
170
Figura 2.44 Poblamiento de la tabla de hechos Insumo
CREACIÓN DE LOS CUBOS MULTIDIMENSIONALES
Con el estilo de navegación que presenta los datos OLAP (un modelo fácil e
intuitivo), el usuario final puede tener simple consultas de los datos y
comprender el origen de su información.
En un modelo de datos OLAP, los datos son vistos bajo la forma de cubos
que contienen dimensiones y unidades de medida. OLAP permite la creación
de consultas muy complejas, organizar los datos en forma de reportes para
producir nuevas estadísticas, así como seleccionar y ordenar datos.
Para la construcción de los cubos (INSUMOS, PERSONAL,
TRANSPORTE) seguiremos los siguientes pasos:
 Definición del cubo.
 Almacenamiento del cubo.
 Procesamiento del cubo.
171
a) DEFINICIÓN DEL CUBO INSUMOS

- Identificar la tabla de Hechos Insumo
Teniendo en cuenta el modelo lógico caracterizado por un
modelo estrella escogemos las medidas necesarias y
apropiadas que formarán parte del cubo Insumo, para
nuestro caso tenemos:
Soles Insumo
- Identificar las Dimensiones
Las dimensiones son las siguientes:
Tiempo, Producto, Estado de Campo, Insumo, Geografía.
CRACION DE LOS CUBOS EN EL ANALYSIS SERVICES
Figura 2.45 Elección de la tabla de Hechos
172
Figura 2.46 Elección de las Medidas
Figura 2.47 Elección de las Dimensiones
173
Figura 2.48 Nombre del Cubo
Figura 2.49 Selección del Tipo de Almacenamiento
174
Figura 2.50 Seleccionamos la Agregación
Figura 2.51 Estructura del Cubo
175
Figura 2.52 Procesando el Cubo
Figura 2.53 Mostrando Datos
176
b) DEFINICIÓN DEL CUBO PERSONAL

- Identificar la tabla de Hechos Personal
apropiadas que formarán parte del cubo Personal, para
Costo mano Obra
- Identificar las Dimensiones

Geografía, personal, tiempo, estado de campo,
producto.
CRACION DE LOS CUBOS EN EL ANALYSIS SERVICES
Figura 2.54 Elección de la Tabla de Hechos
177
178
179
Figura 2.60 Selección del tipo de Almacenamiento
180
Figura 2.61 Mostrando Datos
c) DEFINICION DEL CUBO TRANSPORTE

- Identificar la tabla de Hechos Transporte
apropiadas que formarán parte del cubo Personal, para
Costo Transporte
Cantidad Hectáreas
- Identificar las dimensiones

Geografía, tiempo estado de campo, producto, vehículo.
181
CREACIÓN DE LOS CUBOS EN EL ANALYSIS SERVICES
Figura 2.62 Elección de la tabla de Hechos
182
183
Figura 2.66 Selección del Tipo de Almacenamiento
184
Figura 2.69 Mostrando Datos del Cubo
185
2.4.2. CREACIÓN DEL SISTEMA Y PRESENTACIÓN DEL

PROTOTIPO
2.4.2.1. MODELOS USE CASE
MODELO USE CASE DEL NEGOCIO
Gerente de
Campo Preparacion
Jefe de
Campo
Siembra
Jefe de Zona
Cosecha
Figura 2.70 Modelo Use Case del Negocio
186
2.4.2.2. MODELO USE CASE DEL SISTEMA EJECUTIVO
Definir Indicador
Analizarndo Indicadores
Gerente General
Preparacion Tabular Mostrando Cantidad de
Hectareas Preparadas
Mostrando Costos por
Mostrando Costos Insumos en Hectareas Preparadas
Preparacion
<<extend>> Mostrando Costos de Mano de
Definir Meta Mostrando Costos de
Obra en Preparacion
Transporte en Preparacion
<<extend>>
Analizar Indicadores Preparacion

Analizando Indicador Grafico
Preparacion
Mostrando Costos por
Hectareas Sembradas
<<extend>>
Analizando Indicador Siembra
<<extend>> Tabular
Mostrando Costos de Mano
de Obra en Siembra
<<extend>> Mostrando Cantidad de
Hectareas Sembradas
Analizando Indicador Siembra Mostrando Costos de
Gerente de Campo. Vehiculos en Siembra
Mostrando Costos de Insumos
para la Siembra
<<extend>>
<<extend>>
Analizando Indicador Siembra

Poblamiento del Data Mart Grafico Mostrando Costos por
Hectareas
Analizando Indicador Cosecha

<<extend>> Mostrando Cantidad de
Tabular
Hectareas Cosechadas
Mostrando Costos Insumos para
la Cosecha
Analizar indicadores Cosecha
Mostrando Costos de Mano de

Mostrando Costos de Obra para la Cosecha
Transporte para la Cosecha
<<extend>>
Analizando Indcador Siembra

Grafico
Figura 2.71 Modelo Use Case del Sistema Ejecutivo
187
2.4.2.3. DISEÑO DE LA INTERFAZ HOMBRE-MAQUINA
Figura 2.72 Acceso al Sistema
Figura 2.73 Pantalla Principal
188
Figura 2.74 Hectáreas Preparadas
Figura 2.75 Hectáreas Preparadas por Zona
189
Figura 2.76 Hectáreas Preparadas por Anexo
190
Figura 2.77 Hectáreas Preparadas por Campo
Figura 2.78 Hectáreas Preparadas por Campo Indices
191
Figura 2.79 Archivo
Figura 2.80 Información de la Empresa
192
Figura 2.81 Configurar Parámetros
Figura 2.82 Registrar Usuario
193
Figura 2.83 Registro Usuario Nuevo
194
2.4.2.4. DIAGRAMA DE COLABORACIONES
1. Diagrama de Colaboración para la Preparación
3: Buscar Dx Dim_Geog : Dim_Geografia
4: DevDx Dim_Geog
1: Selecc. Preparacion 2: Preparar Dx
5: 6:
13: Selecc. Repor Ind 14: Preparar Dx Indicador 7: Buscar Dx RealesTab_Hech
8: Dev Dx Tab_Hech
: Tomador : Elaborador Indicador : Buscador Datos : Tabla_Hechos
Decisiones 9:
12: Dx Devueltos 10: Buscar Indicador
17: Datos Devueltos 15: Buscar Datos Indicador
11: Dev DxIndicador

16: Datos Devueltos Indicador
: Indicador
2. Diagrama de Colaboración para la Siembra
4: DevDx Dim_Geog
1: Selecc. Siembra 2: Preparar Dx
5: 6:
8: Dev Dx Tab_Hech
Decisiones 9:
11: Dev DxIndicador

: Indicador
195
3. Diagrama de Colaboración para la Cosecha
4: DevDx Dim_Geog
1: Selecc. Cosecha 2: Preparar Dx
5: 6:
8: Dev Dx Tab_Hech
Decisiones 9:
11: Dev DxIndicador

: Indicador
196
2.4.2.5. DIAGRAMA DE SECUENCIAS
1. Diagrama de Secuencia para la Preparación
: Tomador : Elaborador Indicador : Buscador Datos : Dim_Geograf ia : Tabla_Hechos : Indicador

Decisiones
Selecc. Preparacion
Preparar Dx
Buscar Dx Dim_Geog
Dev Dx Dim_Geog
Dev Dx Indicador
Selecc. ReporeReal
Prepar. Dx Reporte
Buscar Dx RealesTab_Hech
Dev Dx Tab_Hech
Dev Dx Ind
Buscar Indicador
Dev DxIndicador
Dx Dev ueltos
Selecc. Repor Ind
Preparar Dx Indicador
Buscar Datos Indicador
Datos Dev ueltos Indicador

Datos Dev ueltos
197
1. Diagrama de Secuencia para la Siembra

Decisiones
Selecc. Siembra
Preparar Dx
Buscar Dx Dim_Geog
Dev Dx Dim_Geog
Dev Dx Indicador
Selecc. Reporte Real
Prepar. Dx Reporte
Dev Dx Tab_Hech
Dev Dx Ind
Buscar Indicador
Dev DxIndicador
Dx Dev ueltos
Selecc. Repor Ind

Datos Dev ueltos
198
3. Diagrama de Secuencia para la Cosecha

Decisiones
Selecc. Cosecha
Preparar Dx
Buscar Dx Dim_Geog
Dev Dx Dim_Geog
Dev Dx Indicador
Selecc. Reporte Real
Prepar. Dx Reporte
Dev Dx Tab_Hech
Dev Dx Ind
Buscar Indicador
Dev DxIndicador
Dx Dev ueltos
Selecc. Repor Ind

Datos Dev ueltos
199
2.4.3. PRUEBAS PARA EL SISTEMA EJECUTIVO
2.4.3.1. Prueba de Caja Negra para el SIE

Se aplicó la prueba a las siguientes personas:
 El Gerente de Campo de la empresa
 El Jefe de Zona de la empresa
 El Jefe de Anexo de la empresa
Los resultados se observan en la siguiente tabla:
Nº Valor
Requerimientos %
Pruebas
Cuál es la cantidad de hectáreas preparadas para los diferentes tipos
de caña producidas en una determinada zona o anexo o campo en 1 4 100
Cuál es la cantidad de hectáreas sembradas para los diferentes tipos
Cuál es la cantidad de hectáreas cosechadas para los diferentes tipos
preparación en los diferentes campos de un anexo de una zona 1 3 75
siembra en los diferentes campos de un anexo de una zona 1 3 75
cosecha en los diferentes campos de un anexo de una zona 1 3 75
Cuál es el costo de la mano de obra por campo, zona y anexo en un
1 4 100
mes o trimestre de un año específico para la preparación.
1 4 100
mes o trimestre de un año específico para la siembra.
1 4 100
mes o trimestre de un año específico para la cosecha.
Determine los niveles de inversión de transporte para la
preparación utilizado por zona, anexo y campo en un período 1 3 75
determinado.
Determine los niveles de inversión de transporte para siembra
1 3 75
Determine los niveles de inversión de transporte para la cosecha
3 75
utilizado por zona, anexo y campo en un período determinado. 1
Determinar el costo de transporte por tipo de caña en la preparación
1 4 100
Determinar el costo de transporte por tipo de caña en la siembra por 1 4 100
200
períodos determinados.
Determinar el costo de transporte por tipo de caña en la cosecha por
1 4 100
período de tiempo determinado, ya sea mensual, trimestral o anual 1 4 100
para la siembra.
Considerando los datos obtenidos de las pruebas aplicadas a los usuarios del Sistema de
Información Ejecutivo, se puede observar que el sistema tiene una ponderación entre el
75% y el 100%, considerando el grado de satisfacción, los usuarios se muestran
COMPLETAMENTE SATISFECHO del sistema implementado.
201
CAPÍTULO 3
DISCUSIÓN
Para la contratación de la hipótesis se ha considerado lo siguiente:
Formulación del Problema

¿Cómo se puede contar con información estratégica y oportuna para monitorear los
factores críticos de la gerencia de campo y en un formato adecuado que de apoyo a una
toma de decisiones adecuada?
Hipótesis
El Sistema de Información Ejecutivo de Producción de la Empresa Agroindustrial Casa
Grande S.A.A. proporcionará información estratégica y oportuna para monitorear los
factores críticos de la gerencia de campo y en un formato adecuado que de apoyo a una
toma de decisiones adecuada.
Luego definimos las variables que intervienen en la veracidad o falsedad de la hipótesis,
las cuales son:
 Variable Independiente (VI): Sistema de Información Ejecutivo de Producción.

 Variables Dependientes (VD): Información estratégica y oportuna para
monitorear los factores críticos de la gerencia de
campo y en un formato adecuado que de apoyo a una
toma de decisiones adecuada.
La información estratégica, oportuna en un formato adecuado a la que se refiere el

Gerente de Campo, que es el usuario del SIE, son los requerimientos dichos
anteriormente. Cada requerimiento es valioso para la toma de decisiones dentro de la
Gerencia de Campo.
202
3.1. MANERA PRESENCIAL
VI Información VD
Valiosa y oportuna
Gerencia de Campo de la
Empresa Agroindustrial
Casa Grande S.A.A
3.1.1. DISEÑO PRE-EXPERIMENTAL, PRE-PRUEBA Y POST-PRUEBA
PRE-PRUEBA (O1): Es la medición previa de X a G.

POST-PRUEBA (O2): Corresponde a la nueva medición de X a G.
Se determinó usar el diseño pre experimental pre-prueba post-prueba, porque
nuestra hipótesis se adecua a este diseño. Este diseño experimenta con u n
solo grupo de sujetos el cual s medido a través de un cuestionario antes y
después de presentar el estímulo (SIE). Este diseño se presenta de la
siguiente manera:
G O1 X O2
Donde:
X: Tratamiento, estímulo (SIE)
O: Medición a sujetos (Cuestionario)
G: Grupo de sujetos (Empleados de la Institución)
El espacio muestral que se tomó para la medición de los indicadores de la

hipótesis, correspondió al total de personas que operan el SIE en la Gerencia de
Campo, siendo el Gerente de Campo, a esta persona se les aplicó un
cuestionario, antes de interactuar con el SIE (O1) y después de interactuar con
el mismo (O2).
203
Al concluir la investigación se establecen las diferencias entre O1 y O2 para

determinar si hay o no incremento en los resultados obtenidos.
3.1.2. CÁLCULO DE LOS INDICADORES DE LA HIPÓTESIS

Para el cálculo de los indicadores de la hipótesis en el SIE propuesto, se
realizó un cuestionario (Ver Anexo F) en donde se evaluó al Gerente de
Campo luego de haber interactuado con el SIE.
Los valores que los usuarios dieron a la respuesta del cuestionario fueron
aplicados según el rango de satisfacción que a continuación se muestra:
19. ¿Se puede conocer la cantidad de hectáreas preparadas para los diferentes tipos
de caña producidas en una determinada zona o anexo o campo en un determinado
período?
8.5
10
SATISFACION
8
6
4
2 0
0
ANTES DEL SIE DESPUES DEL SIE
Figura 3.1 Resultado de Satisfacción
Resultado: 0 antes del sistema 8.5 después del SIE, el SIE nos
permite conocer la cantidad de hectáreas preparadas en una
determinada ubicación y tiempo.
204
20. ¿Se puede conocer la cantidad de hectáreas sembradas para los diferentes tipos de
caña producidas en una determinada zona o anexo o campo en un determinado
período?
10 8
SATISFACION
8
6
4
2 0
0

Resultado: 0 antes del sistema 8 después del SIE, el SIE nos
permite conocer la cantidad de hectáreas sembradas en una
21. Cuál es la cantidad de hectáreas cosechadas para los diferentes tipos de caña
producidas en una determinada zona o anexo o campo en los diferentes meses,
trimestres y años.
9
10
SATISFACION
8
6
4 2.5
2
0

permite conocer la cantidad de hectáreas cosechadas en una
205
22. Conocer la cantidad invertida para los tipos de insumo usados en la preparación
en los diferentes campos de un anexo de una zona determinada en el año,
trimestre o año vigente.
8.5
10
SATISFACION
8
6
4
2 0
0

permite conocer la cantidad invertida para los tipos de insumos
usados en la preparación en una determinada ubicación y tiempo.
23. Conocer la cantidad invertida para los tipos de insumo usados en la siembra en
año vigente.
10 8
SATISFACION
8
6
2.5
4
2
0

usados en la siembra en una determinada ubicación y tiempo.
206
24. Conocer la cantidad invertida para los tipos de insumo usados en la cosecha en
año vigente.
9
10
SATISFACION
8
6
4
1
2
0

usados en la cosecha en una determinada ubicación y tiempo.
9
10
SATISFACION
8
6
4 2
2
0

permite conocer el costo de la mano de obra usados en la
preparación en una determinada ubicación y tiempo.
207
8.5
10
SATISFACION
8
6
2.5
4
2
0

permite conocer el costo de la mano de obra usados en la siembra en
una determinada ubicación y tiempo.
8.5
10
SATISFACION
8
6
4
2 0
0

permite conocer el costo de la mano de obra usados en la cosecha en
una determinada ubicación y tiempo.
208
28. Determine los niveles de inversión de transporte para la preparación utilizado por
8.5
10
SATISFACION
8
6
4
2 0
0

permite conocer los niveles de inversión de transporte usados en la
preparación en una determinada ubicación y tiempo.
29. Determine los niveles de inversión de transporte para siembra utilizado por zona,
anexo y campo en un período determinado.
10 8
SATISFACION
8
6
4
2 0
0

siembra en una determinada ubicación y tiempo.
209
30. Determine los niveles de inversión de transporte para la cosecha utilizado por
8.5
10
SATISFACION
8
6
4
2 0
0

cosecha en una determinada ubicación y tiempo.
31. Determinar el costo de transporte por tipo de caña en la preparación por períodos
determinados.
10 8
SATISFACION
8
6
4 2
2
0

permite conocer el costo de transporte por tipo de caña usados en la
preparación en un determinado tiempo.
210
32. Determinar el costo de transporte por tipo de caña en la siembra por períodos
determinados.
8.5
10
SATISFACION
8
6
2.5
4
2
0

siembra en un determinado tiempo.
33. Determinar el costo de transporte por tipo de caña en la cosecha por períodos
determinados.
9
10
SATISFACION
8
6
4
2 0
0

Resultado: 0 antes del sistema 8 después de usar el SIE, el SIE nos
cosecha en un determinado tiempo.
211
determinado, ya sea mensual, trimestral o anual para la preparación.
8.5
10
SATISFACION
8
6
4
2 0
0

Resultado: 0 antes del sistema 8.5 después de usar e SIE, el SIE nos
permite conocer el costo de personal por zonas, anexos o campos en
un período de tiempo determinado, ya sea mensual, trimestral o
anual para la preparación.
35. Cuál es el costo de personal por hectáreas en un período de tiempo determinado,

ya sea mensual, trimestral o anual para la siembra.
8.5
10
SATISFACION
8
6
2.5
4
2
0

Resultado: 2.5 antes de usar el SIE 8.5 después de usar el SIE Con
el SIE el costo de personal por zonas, anexos o campos en un
período de tiempo determinado, ya sea mensual, trimestral o anual
212
36. Cuál es el costo de personal por hectáreas en un período de tiempo determinado,

ya sea mensual, trimestral o anual para la cosecha.
9
10
SATISFACION
8
6
4
2 0
0

Resultado: 0 antes de usar el SIE 9 después de usar el SIE, el SIE
permite conocer el costo de personal por zonas, anexos o campos en
un período de tiempo determinado, ya sea mensual, trimestral o
anual para la preparación.
3.1.3. APLICACIÓN DEL RANGO DE SATISFACIÓN A LOS

INDICADORES DE LA HIPÓTESIS
Los valores aplicados a los indicadores de la hipótesis Antes del uso del SIE
después del uso del SIE se muestran en la siguiente tabla:
ANTES
DESPUES
CONSULTAS DEL
DEL SIE
SIE
Cuál es la cantidad de hectáreas preparadas para los diferentes tipos de
caña producidas en una determinada zona o anexo o campo en los 0 8.5
diferentes meses, trimestres y años.
Cuál es la cantidad de hectáreas sembradas para los diferentes tipos de
caña producidas en una determinada zona o anexo o campo en los 0 8
Cuál es la cantidad de hectáreas cosechadas para los diferentes tipos de
2.5 9
caña producidas en una determinada zona o anexo o campo en los
213

preparación en los diferentes campos de un anexo de una zona 0 8.5
siembra en los diferentes campos de un anexo de una zona determinada 2.5 8
en el año, trimestre o año vigente.
cosecha en los diferentes campos de un anexo de una zona determinada 1 9
en el año, trimestre o año vigente.
Cuál es el costo de la mano de obra por campo, zona y anexo en un mes o
2 9
2.5 8.5
0 8.5
Determine los niveles de inversión de transporte para la preparación
0 8.5
Determine los niveles de inversión de transporte para siembra utilizado
0 8
por zona, anexo y campo en un período determinado.
Determine los niveles de inversión de transporte para la cosecha utilizado
0 8.5
por zona, anexo y campo en un período determinado.
Determinar el costo de transporte por tipo de caña en la preparación por
2 8
Determinar el costo de transporte por tipo de caña en la siembra por
2.5 8.5
Determinar el costo de transporte por tipo de caña en la cosecha por
0 9
Cuál es el costo de personal por zonas, anexos o campos en un período de
tiempo determinado, ya sea mensual, trimestral o anual para la 0 8.5
preparación.
214

tiempo determinado, ya sea mensual, trimestral o anual para la 2.5 8.5
preparación.
tiempo determinado, ya sea mensual, trimestral o anual para la 0 9
preparación.
PROMEDIOS 17.50 153.50
3.1.4. ANÁLISIS ESTADISTICO PARA LA PRUEBA PRESENCIAL DE LA

HIPÓTESIS
La prueba de la hipótesis se ha empleado el método estadístico T StudentN,

utilizado para determinar la prueba de significancia de diferencia de dos
muestras por ser n<30.
HIPÓTESIS ESTADÍSTICA
H0: No es necesario el uso del Sistema de información Ejecutiva El Sistema

de Información Ejecutivo de Producción de la Empresa Agroindustrial Casa
Grande S.A.A. proporcionará información estratégica y oportuna para
monitorear los factores críticos de la gerencia de campo y en un formato
adecuado.
H1: Es necesario el Sistema de Información Ejecutivo de Producción de la
Empresa Agroindustrial Casa Grande S.A.A. proporcionará información
estratégica y oportuna para monitorear los factores críticos de la gerencia de
campo y en un formato adecuado.
El detalle del resultado de las respuestas previamente tabuladas al
aplicar el cuestionario se muestra en el Anexo H.
215
H0 : D  0
HIPÓTESIS ESTADÍSTICA :
H0 : D  0
NIVEL DE SIGNIFICANCIA:
  0.05
d
t0  , con distribución t con n-1 grados de libertad
S
n
n
d i
d i
, cálculo del promedio de las diferencias
n
ESTADÍSTICA DE PRUEBA:
di  X i  Yi , diferencia de valores
n
n
( d i ) 2
d i
2
 i
n
S d2  i
, varianza
n 1
Tabla 3.19 Hipótesis Estadística
Procedemos a realizar los cálculos y obtenemos los siguientes datos:
di  X i  Yi  136 .000
La media:
n
d i
d i
= 7.558
n
La varianza:
n
n
( d i ) 2
d i
2
 i
n
1053 .00 
18496 .00
S d2  i
= 18 = 1.497
n 1 18  1
La Desviación Estándar: S 2 = 1.223
216
Ahora simplemente aplicamos la fórmula:
7.556
t0  = 26.2033 t0  26.2033
1.223
18
Ahora necesitamos compara nuestro valor observado con el valor de t-student de una
tabla al 5% de significancia y con 18-1 grados de libertad, este valor es t0.05[17] = 2.110.
Figura 3.20 Rango de Aceptación y Rechazo
Puesto que nuestro valor observado es mayor que el t de la tabla al 5% y con 17 grados
de libertad, rechazamos la hipótesis nula de No es necesario el uso del Sistema de
información Ejecutiva
El Sistema de Información Ejecutivo de Producción de la Empresa Agroindustrial Casa
Grande S.A.A. proporcionará información estratégica y oportuna para monitorear los
factores críticos de la gerencia de campo y en un formato adecuado.
Así concluimos que Es necesario el Sistema de Información Ejecutivo de Producción
de la Empresa Agroindustrial Casa Grande S.A.A. proporcionará información
estratégica y oportuna para monitorear los factores críticos de la gerencia de campo
y en un formato adecuado.
217
3.2. MANERA NO PRESENCIAL

La muestra que se tomo fue Al Gerente de Campo de la Empresa Agroindustrial
Casa Grande SAA, al cual se le aplico un cuestionario (Ver Anexo G) el cual
comprobará si el SIE proporcionará información estratégica y oportuna para
monitorear los factores críticos de la gerencia de campo y en un formato adecuado.
1. La forma como se accesa a la información del sistema mediante interfaces,

tabulaciones y reportes, a su criterio es:
85%
0% 0% 0%
Exelente Bueno Regular Malo
El Gerente de campo respondió que la forma de acceder a la información del

sistema es EXCELENTE.
2. La calidad de información que suministra el sistema a su criterio, es:
75%
0% 0% 0%
El Gerente de Campo respondió que la calidad de la información es BUENA
3. La variedad en la presentación de la forma de la información en el sistema es a su

parecer:
218
100%
0% 0% 0%
El gerente de Campo respondió que la variedad en la presentación de la forma de

información es EXCELENTE.
4. El tiempo de respuesta del sistema frente a una petición suya es:
100%
0% 0% 0%
Excelente Bueno Regular Malo

5. Las conformidades de los datos suministrados por el sistema se ajustan a la

realidad, de manera:
100%
0% 0% 0%

219
6. Su adaptación al manejo del sistema fué:
75%
0% 0% 0%
7. Dentro de la fiabilidad de la información que suministra el sistema Ud. Confía

que la información sea:
75%
0% 0% 0%
220
8. El aprendizaje para el manejo del sistema fué muy:
75%
0% 0% 0%
9. El contar con un sistema de este tipo, considera que beneficia a la empresa frente
a la competencia, de manera:
100%
0% 0% 0%
El beneficio que se obtiene al contar con un sistema de este tipo EXCELENTE
221
10. Su moral como Gerente de Campo frente a la introducción de nuevas tecnologías

al área es :
100%
0% 0% 0%
El Gerente de campo respondió que su moral es EXCELENTE, no hay oposición

al cambio.
11. Las pantallas de presentación a su criterio se encuentran personalizas:
100%
0% 0% 0%
El Gerente respondió que sí están personalizadas.
222
12. El sistema a su parecer ha cumplido con los requerimientos que Ud. propuso
antes de su construcción:
100%
0% 0% 0%
El Gerente de Campo afirmo que el sistema cumple con los requerimientos que la
Gerencia propuso.
Luego de haber evaluado al usuario del Sistema de Información Ejecutiva (SIE),

concluimos que: El Sistema de Información Ejecutivo de Producción de la Empresa
Agroindustrial Casa Grande S.A.A. proporcionará información estratégica y oportuna
para monitorear los factores críticos de la gerencia de campo y en un formato adecuado.
223
CAPITULO 4
CONCLUSIONES Y RECOMENDACIONES
CONCLUSIONES
1. La identificación de la alternativa de desarrollo del SIE se eligió entre tres
alternativas:
Alternativa 1: Desarrollar el sistema de manera interna partiendo de cero.
Alternativa 2: Modificar el sistema actual con la finalidad de cubrir los
requisitos del ejecutivo.
Alternativa 3: Desarrollar el sistema partiendo de cero con la ayuda de
desarrolladores externos (comprar el sistema).
De acuerdo a la evaluación en costo, tiempo y a su adaptación a la
gerencia de campo, elegimos la alternativa 1, desarrollar el SIE de manera
interna a partir de cero.
2. La presentación de la propuesta al Ejecutivo, ayudó a tener un apoyo más
sólido para el desarrollo del SIE y para minimizar la resistencia del
Ejecutivo.
3. Realizar entrevistas a los usuarios finales y observar el ámbito en estudio,
permitió determinar las necesidades del ejecutivo.
4. La utilización de manera correcta de la tecnología Data Warehouse puede
llegar a ser un sistema eficaz y adecuado en la entrega de la información
de gestión a los usuarios finales.
5. El implementar el SIE bajo la tecnología DW para el hospital de manera
incremental permitirá ahorrar costos del mismo.
6. El SIE genera información oportuna y adecuada de soporte a la toma de
decisiones a los ejecutivos, generando ventaja competitiva.
224
RECOMENDACIONES
 Para la identificación de la mejor alternativa de desarrollo del SIE es

imprescindible evaluar las ventajas y desventajas de cada una de las mismas,
tomando como criterio costo, tiempo y adaptación del SIE.
 Para presentar de manera formal una propuesta de desarrollo de un SIE
debemos incluir en ella los beneficios que pueden lograrse en la construcción
del SIE y plantear en forma detallada los recursos para cumplir con la
propuesta. Creando con ello un claro entendimiento entre el desarrollador y
los ejecutivos.
 Una correcta formulación de las preguntas en el tiempo y a las personas
adecuadas, así como una exhaustiva observación en el medio de estudio
genera que se logre determinar los requerimientos del ejecutivo.
 Para la construcción del Data Warehouse, lograr en primer lugar evaluar la
consistencia del BD operacional debido a que éste, es el origen de los datos
de la Base de Datos Multidimensional, para no obtener información inexacta
por inconsistencias en su estructura.
 Crear un ambiente de confianza y proporcionar una adecuada instrucción a
los usuarios finales sobre el software Sistema de Información Ejecutiva de
Producción, permitiendo a ellos mismos expresar sus nuevas peticiones a los
miembros encargados de la implementación del sistema, de manera que las
próximas versiones mejorará el nivel de consultas y por lo tanto la
información será más valiosa.
 Evaluar el nivel de conocimiento en computación, manejo de Software,
dentro de las organizaciones.
 Para la etapa de la prueba del sistema, debe existir la participación de los
usuarios finales, para garantizar que el sistema ha sido probado con un gran
número de situaciones posibles.
225
REFERENCIAS BIBLIOGRÁFICAS
LIBROS
[COH-00] COHEN KAREN, Daniel; ASIN LARES, Enrrique; “Sistema de
Información para los Negocios”; 3ra. Edición, Interamericana de México
S.A., Ediciones Mc. Graw Hill; 2000.
[GIL-97] GIL PECHUAN, Ignacio, “SISTEMAS Y TECNOLOGIAS DE LA
INFORMACION PARA LA GESTION”, 1ra Edición, Editorial
Fernández, ciudad España, 1997.
[WCC-02] CUEBAS CABRERA, Walter “Modulo De Soporte A La Toma De
Decisiones Para El Sistema Meca Aplicando Características Olap”.
México, 2002.
[MIC-98] MICRSOFT CORPORATION. Designing and Implementing a Data
Warehouse using Microsoft SQL Server 7.0. 1998 Microsoft Corporation.
USA.
[KIM-98] KIMBAL, Ralph; REEVES, Laura; ROSS, Margy; THORNTHWAITE,
Warren. “The Data Warehouse lifecycle Toolkit”. 1era. Edición. 1998.
Editorial Cargraphics S.A. Colombia.
[HAR-96] HARJINDER, Gill y PRAKASH, Rao. Data Warehousing. 1era. Edición
1996. Editorial Pretince Hall Hispanoamericana S.A. México.
REVISTAS
[MEN-02] MENDOZA, Ricardo. Microsoft SQL 7.0 OLAP Services. Diseño e
implementación de un Data Warehouse. Universidad Cesar Vallejo.
2002. Perú
[TUT-98] TUTORIAL SQL SERVER. Servicios OLAP. 1998. USA
226
TESIS
[CAL-01] CALDERON CEDANO, Carlos; ROJAS MORENO, Carol;
“Construcción de un sistema de información ejecutivo para el análisis y
control de los índices de gestión de la gerencia de ventas de la empresa
Perfiles y Proyectos Metálicos de Trujillo”
Tesis para optar el Título de Ingeniero de Computación y sistemas 2001:
Trujillo – Perú.
[JUSROS] Justiniano y Rosmeri
REFERENCIAS A INTERNET
[REY-02] REYNOSO, Luis. “Desarrollo con SQL Server”. SQL Max Connections.
Url: www.sqlmax.com. 2002. Argentina.
[ART-02] “Técnicas de análisis”. BITAM
Url: www.bftsystems.com/Tecanalisis.htm. 2002.
[FGCP-01] FERRANDO GIRON, Santiago José; CARRERA PERPIÑAN, Iván José,
“Soluciones Data Warehouse bajo el Nuevo Modelo e-bussines: la
necesidad de integrar la información”.
Url: www.virtual.epm.br/healthcare/spanish/, 2001.
[WEB2-99] “MODELO DE REFERENCIA DE UN PROYECTO O CICLO DE
VIDA” Url: www.map.es/esi/silice/Dsamed.hotm, 1999.
[WEB8-00] GRUPO EIDOS. “Algoritmo. La revista para el programador de base de
datos”. Mario Piattini. España.
Url: www.eidos.es/revista.baseDW.html. 2000. España.
[WEB4-02] “SISTEMAS DE INFORMACIÓN”. Los Indicadores de Gestión.
Url: www.enferteuel.org/formación/temas/tema14.doc, 2002.
[DEL-02] DE LA HERRAN GASCON, Manuel. “Concepto de Base de Datos
Multidimensionales”. Red Científica.
Url: www.aircenter.net/oracle/c0001p0005.htlm. Enero del 2002.
227
[MED-02] MEDINA CONSULTING RUBIK. “Foundation for OLAP”. Media

Consulting.
Url: www.solgenia.com/mexico/olap/olapstory.htm. Enero 2002. México.
[MAP-02] MAP CONSEJO SUPERIOR DE INFORMÁTICA. “Glosario”.
Url: www.ideasa.com.pe/Datawarehouse.htm. 2001. Perú.
[MOR-99] MORALES, Eduardo. “DataMart”. Instituto Tecnológico y de Estudios
Superiores de Monterrey.
Url: www.mor.itesm.mx/~emorales/cursos/kDd/datamart.html. 1999.
México.
[COR-02] CORPORATION CIPHER. “OLAP”. Corporation CIPHER.
Url: www.cipher.com.ve/olap.html. 2002. Venezuela.
[BUS-02] BUSINESS & DECISION. “Datawarehouse”. Business & Decision.
Url: www.businessdecision.com/esp/decouvrir/Datawarehouse.htm. 2002.
España.
[MOR-98] MORALES, Eduardo. “On Line Analytical Precessing”.
Url: www.mor.itesm.mx/~emorales/Cursos/KDD/NODE167.html. 1998.
México.
[WEB8-00] GRUPO EIDOS. “La revista para el programador de base de datos. Mario
Piattini-España.
Url: www.eidos.es/revista/baseDW.html. 2000. España.
[WEB5-00] Introducción al análisis de datos
www.virtual.epm/material/healthcare/spanish/b0105.pdf
[IDE-01] 01 IDEASA DataMart
www.fisicc-ufm.edu/~progra6/Datawarehouse/datamart. 2001.
228
ANEXOS
ANEXO A
ENTREVISTAS Y CUESTIONARIOS PARA LA

CONSTRUCCIÓN DEL MART
CUESTIONARIO PARA ENTREVISTA Nº 1: Gerente de Campo
A. LAS RESPONSABILIDADES
 Describe su área y su relación con el resto de la compañía.

 ¿Cuáles son sus responsabilidades primarias?
B. LOS OBJETIVOS COMERCIALES Y PROBLEMAS
 ¿Cuáles son los objetivos de su área?.

 ¿Qué está usted tratando de lograr con estos objetivos?.
 ¿Cuáles de estos objetivos son su prioridad para alcanzar sus metas dentro de su
organización?.
 ¿Cuáles son los factores críticos de éxito?.
 ¿Cómo sabe usted que está haciendo bien?.
 ¿Qué tan ha menudo usted mide los factores de éxito importantes?.
 De los departamentos que funcionan dentro de su área. ¿Cuáles son cruciales para
asegurar que los factores de éxito importantes se logren?.
 ¿Qué roles cumplen estos departamentos?.
 ¿Cómo, ellos trabajan para asegurar el éxito juntos?.
 ¿Cuáles son los principales problemas que usted enfrenta hoy dentro de su
función?, y, ¿Cuál es el impacto en la organización?.
 ¿Cómo usted identifica sus problemas en su Área o sabe que usted se dirige hacia
ese problema?.
C. ANÁLISIS DE LOS REQUISITOS
 En el análisis de los datos ¿Qué papel juega las decisiones que usted y otros
gerentes toman en la ejecución del negocio?.
 ¿Qué información importante se exige a hacer o a apoyar las decisiones que usted
hace en el proceso de lograr sus metas y superar los obstáculos?, ¿Cómo usted
consigue esta información hoy?.
 ¿Está allí otra información que no está disponible a usted hoy y que usted cree
tendría el impacto significante en ayudar a encontrar sus metas?.
 ¿Están allí los cuellos de botella específicos para llegar a la información?.
 ¿Qué informes usted usa actualmente?.
 ¿Qué datos en el informe son importantes?.
 ¿Cómo usted usa la información?.
 ¿Qué problemas encuentra en estos informes?.
 ¿Cuánta información histórica se requiere?.
 ¿Si el informe fuera dinámico, en qué lo haría diferentemente?.
 ¿Qué capacidades analíticas le gustarían tener?.
 ¿Qué oportunidades existen para mejorar dramáticamente su negocio basándose
en el acceso mejorado de la información?.
 ¿Cuál es el impacto financiero que usted piensa que tendría?.
CUESTIONARIO PARA ENTREVISTA Nº 2: Sub Gerente de Campo
 Describe su organización y su relación con el resto de la compañía.
 ¿Cuáles son sus responsabilidades primarias?.

 ¿Cuáles son los objetivos en el desempeño de su función?.
función?.
 ¿Cuáles son sus factores críticos de éxito?.
función?.
 ¿Qué le impide cubrir sus objetivos?.
 ¿Cuál es el impacto de estos problemas en la organización?.
 ¿Cómo usted identifica sus problemas en su organización (o área) o sabe que
usted se dirige hacia ese problema?.
 ¿Cómo es la relación que tiene con el Gerente de Campo?.
C. ANÁLISIS DE LOS REQUISISTOS

 ¿Qué tipo de análisis rutinario usted realiza actualmente?, ¿Qué datos se usa?.
 ¿Cómo usted consigue los datos actualmente?.
 ¿Qué usted hace con la información una vez que la obtiene?.
 ¿Qué informes usa usted actualmente?.
CUESTIONARIO PARA ENTREVISTA Nº 3: Jefe de Zona

función?.
 ¿Qué tan ha menudo usted mide los factores de éxito en la empresa?.
función?.
 ¿Cómo usted identifica problemas en su Área o sabe que usted se dirige hacia ese
problema?.
 ¿Cómo es la relación que tiene con el Gerente de Campo?.

 ¿Qué tipo de análisis rutinario usted realiza actualmente?, ¿Qué datos se usa?.
 ¿Cómo usted consigue los datos actualmente?.
 ¿Qué usted hace con la información una vez que la obtiene?.
 ¿Qué informes usa usted actualmente?.
CUESTIONARIO PARA ENTREVISTA Nº 3: Jefe de Anexo

función?.
función?.
 ¿Cómo usted identifica sus problemas en su Área o sabe que usted se dirige hacia
ese problema?.
 ¿Cómo es la relación que tiene con la Junta de Accionitsas el Gerente de Campo?

 ¿Qué tipo de análisis rutinario usted realiza actualmente?, ¿Qué datos se usa?
 ¿Cómo usted consigue los datos actualmente?
 ¿Qué usted hace con la información una vez que la obtiene?
 ¿Qué informes usa usted actualmente?
 ¿Qué datos en el informe son importantes?
 ¿Cómo usted usa la información?
en el acceso mejorado de la información?
ANEXO B
DATA MART Y DATA WAREHOUSE
Data Mart
Un data Mart puede verse como una bodega entre un gran almacén de datos (Data
Warehouse) que almacena data para un propósito específico. El concepto DataMart
es una extensión natural de Data Warehouse. Cuando se habla de Data Mart, se está
refiriendo, en pocas palabras, a un Data Warehouse en pequeño y concentrado en una
sola unidad del negocio, en lugar de toda una corporación. Surge a partir de la
necesidad de abordar los proyectos de Data Warehouse por áreas temáticas de
análisis (esto es por la gran complejidad que alcanzan a tener los proyectos de un
Data Warehouse). En lugar de crear el “gran repositorio” de la empresa, se ha
recomendado el desarrollo de proyectos más pequeños, creando así cubos de
información que respondan a las necesidades de un área específica. Su función
principal es apoyar a otros sistemas para la toma de decisiones, además de disponer
de la información solicitada en el momento preciso, permitiendo así un mejor control
de la información que se está abarcando. Entre los diferentes tipos de Data Marts
prevalecen los Data Marts móviles. Al hablar de Data Marts móviles, se trata de
bodegas personales que pueden cargarse en una LapTop y llevarse a cualquier lugar.
Para el proceso de construcción del Data Mart existen dos enfoques: el primero es
construir un núcleo de la bodega de datos y luego hacer varios Data Marts sobre esta
bodega. La segunda es construir primero un Data Mart e ir expandiendo poco a poco
la bodega de datos y añadiendo nuevos Data Marts conforme sea necesario hacerlo.
También es posible mencionar que el uso de estructuras de datos multidimensionales
debería estar reservado para Data Marts. Este es, datos que están en el corazón de las
bodegas de datos, deberían almacenarse en forma relacional y luego ser extraídos en
una Data Mart multidimensional si es requerido. Hay diferentes estilos de usuarios
finales cada uno con su propio nivel de conocimiento y necesidades, para así proveer
de apropiados mecanismos de acceso para tipo de usuarios.
Diferencia con Bases de Datos Tradicionales:
La primera diferencia es que los primeros sistemas de bases de datos tenían un
propósito transaccional, en un Data Mart se manejan grandes cantidades de datos, y
se enfocan a contestar preguntas del tipo “Que pasaría si…”, por lo que requieren
mayor flexibilidad. Una base de datos tradicional se optimiza para transacciones y un
Data Mart se optimiza para queries con grandes volúmenes de datos.
[MOR-99]
Data Warehouse
Para desarrollar una estrategia de acercamiento al mercado se necesitan nuevos
sistemas de información. Tendrán como principal objetivo ofrecer los datos
informacionales generados en la propia actividad de la compañía, desde una
dimensión que permita una mayor capacidad de análisis e incremente la velocidad en
la toma de decisiones. Una de las tecnologías que mejor se integran y soportan el
nuevo modelo de negocio es el Data Warehouse.
Un Data Warehouse define un nuevo concepto para el almacenamiento de datos,
integra la información generada en todos los ámbitos de una actividad de negocio
(ventas, producción, finanzas, Marketing, etc.) y permite un acceso y explotación de
la información contenida en las bases de datos, facilitando un amplio abanico de
posibilidad de análisis multivariables que permitirán la toma de decisiones
estratégicas. El proceso integra toda la información de una compañía en un único
depósito. La información que se genera en una compañía proviene de diferentes
fuentes, formatos y tipos, que se consolidan, se transforman y se cargan en diferentes
sistemas de gestión de datos, normalmente en RDBMS (Relational Database
Management Systems).
Desde un Data Warehouse, la información se puede mostrar y representar de muchas
maneras. La forma más común de analizar la información, es utilizando un sistema
de proceso de análisis en línea (OLAP, On Line Analytical Precessing). Los
productos OLAP ofrecen un rango muy variado de capacidades de análisis
avanzando, como el multidimensional y el estadístico.
Conclusión
Un sistema Data Warehouse es una eficaz herramienta de organización y análisis de

los complejos volúmenes de información que las compañías generan, que
posteriormente permite el desarrollo de estrategias más efectivas y rentables. Pero la
definición del nuevo modelo de datos y el método de carga y mantenimiento de la
información, requiere un personal especializado que atienda las necesidades de cada
empresa.
[IDE-01]
ANEXO C
CONCEPTOS DE BASES DE DATOS MULTIDIMENSIONALES Y

ESQUEMAS DA TABLAS
Conceptos de Bases de Datos Multidimensionales
BDR
Base de Datos Relacional. Sistema de almacenamiento de datos basado en un
conjunto de tablas unidas mediante relaciones.
BDM
Base de Datos Multidimensional. Base de datos de estructura basada en
dimensiones orientada a consultas complejas y alto rendimiento. Puede utilizar un
SGBDR en estrella (Base de Datos Multidimensional a nivel lógico) o SGBDM
(Base de Datos Multidimensional a niveles lógico y físico o Base de Datos
Multidimensional Pura).
OLTP
On Line Transactional Processing. Procesamiento Transaccional en Línea, se trata
de los procesos clásicos de tratamiento automático de información que incluyen
Altas, Bajas, Modificaciones y Consultas.
OLAP
On Line Analytical Processing. Procesamiento Analítico en Línea, se trata de
procesos de análisis de información. Estos sistemas están orientados al acceso de
modo consulta.
EIS
Executive Information Systems. Sistemas de Información para Ejecutivos.
DSS
Decisión Support System. Sistema de ayuda a la Toma de Decisiones.
Data Mining
Proceso no trivial de análisis de grandes cantidades de datos con el objetivo de
extraer información útil. Por ejemplo, se trata de aplicar algoritmos de clasificación
de datos para realizar predicciones futuras, o estudios de correlación entre variables
aparentemente independientes. Para ello, es común la utilización de Redes
Neuronales o Algoritmos Evolutivos.
KDD
Knowdledge Discovery in Dtabases.
Rotación
Cambio de dimensiones en un informe.
Drill Down
Descomponer (visualmente) en detalle un dato según una jerarquía de una dimensión.
Drill Up
Agregar (visualmente) un dato según una jerarquía de una dimensión.
Roll Up
Proceso que calcula para un indicador y para una o más de las dimensiones por la que
ese indicador se mueve, los valores agregados o padres sucesivos a partir de la suma
de sus hijos, según las jerarquías especificadas, pudiendo poseer cada dimensión más
de una jerarquía. Por ejemplo, es el proceso que suma los ingresos por cada provincia
acumulándolos en los ingresos de la comunidad autónoma correspondiente. Se trata
de una función que relaciona los valores de dos niveles jerárquicos distintos y
adyacentes en una dimensión, transformando un grupo de datos de un nivel en un
único dato asignable a otro valor de nivel superior.
Spread
Proceso que produce dentro de una dimensión una progresión o algún tipo de reparto
proporcional de la cantidad asignada a un elemento entre otros de acuerdo algún
criterio.
Dimensión
Criterio de clasificación de información. Eje de análisis, lista de valores que
proporciona un índice a los datos. Por ejemplo: <Tiempo>,<Geografía>, <Producto>.
Indicador, Medida, Hipercubo, Variable, Fórmula

Objeto de estudio. Cada indicador tiene asociado una serie de dimensiones sobre las
que se puede clasificar sus valores, se dice que se mueve por un cierto número de
dimensiones. Por ejemplo, algunos indicadores son:
Ingresos (<Tiempo>, <Geografía>, <Producto>)
Número de empleados (<Tiempo>, <Geografía>)
Si el indicador contiene datos almacenados se habla de Variable Dimensión. Si, por
el contrario, lo que se almacena es la expresión para calcular esos datos a partir de
otros (que pueden ser una fórmula o un programa), se habla de Fórmula
Dimensional.
Elementos de una Dimensión

Posibles valores de un eje de análisis. Por ejemplo, “Enero de 1998”, “Trimestre 4 de
1998”, o “1996” para la dimensión <Tiempo> y “Bilbao”, Andalucía”, Para la
dimensión <Geografía>.
Jerarquía
Forma de agrupar todos o sólo algunos de los elementos de una dimensión con
relaciones padre-hijo. Casi siempre, pero no obligatoriamente, implica que el padre
se calcula como la suma de todos los hijos. Una dimensión puede tener cero, o varias
jerarquías.
Relaciones o Atributos
Definen vínculos entre valores de dos dimensiones, de forma que cada valor de la
dimensión puede estar relacionado con uno o más valores de otra dimensión.
Celda
Estructura mínima de almacenamiento formada por la intersección de un valor de
cada uno de las dimensiones que componen el cubo. Puede contener o no contener
datos.
SQL
Structured Query Language. Lenguaje de consultas estructurado. Lenguaje orientado
a la creación de consultas de bases de datos relacionales.
RDBMS
Sistema de gestión de bases de datos relacionales. Programa que sirve para crear,
diseñar y manipular base de datos relacionales.
OLTP to OLAP
Proceso de migración de datos desde un sistema OLTP a uno OLAP. Esta migración
es habitualmente el elemento crítico en el desarrollo OLAP
R-OLAP
Arquitectura de base de datos multidimensional en la que los datos se encuentran
almacenados en una base de datos relacional, normalmente en forma de estrella
(Copo de Nieve).
M-OLAP
Arquitectura de base de datos multidimensional en la que los datos se encuentran
almacenados en una base de datos multidimensional, que mejora los tiempos de
acceso a costa de mayores necesidades de almacenamiento y retardos en las
modificaciones.
H-OLAP
Arquitectura que combina las tecnologías ROLAP, MOLAP. En HOLAP, el soporte
de almacenamientos de datos y el motor de generación de vistas contiene elementos
de ambas tecnologías. Pretende combinar las ventajas de cada una sin sus
inconvenientes.
[REY-02]
ROLAP HOLAP MOLAP

Espacio Ocupado Bajo Medio Alta
Velocidad de consulta Bajo Medio Alta
Carga de los procesos
Bajo Medio Alta
Batch
Diseñar y generar la base de datos

El diseño y la generación de la base de datos es una parte crítica del proceso de
generación de un Data Mart. A menudo, este paso lo llevan a cabo Diseñadores de
base de datos expertos porque puede significar la recogida de datos de varios (en
ocasiones, heterogéneos) orígenes y combinarlos en un modelo lógico único.
A diferencia de los sistemas OLTP que almacenan los datos extremadamente
normalizados, los datos se almacenan casi sin normalizar para mejorar el rendimiento
de las consultas. Con frecuencia, los almacenes de datos utilizan el esquema de
estrella o copo de nieve y radial ramificado para proporcionar los tiempos de
respuesta más rápidos a las consultas complejas, y las herramientas OLAP constituye
el fundamento de la administración de los agregados.
Los componentes de diseño del esquema son las dimensiones, las claves y las tablas
de hechos y de dimensiones.
Tablas de Hechos
Contienen datos que describen un suceso específico del negocio, como una
transacción bancaria o la venta de un producto. Por otra parte, las tablas de hecho
también contienen agregados de datos, como las ventas por mes y por región.
Excepto en casos de reordenaciones de producto o territorio, los datos de una tabla
hecho no se actualizan, simplemente, se agregan datos nuevos. Debido a que las
tablas hechos contiene la mayor parte de los datos almacenados en el almacén de
datos, es importante que antes de cargar los datos, la estructura de las tablas sea la
correcta. Puede ser necesaria una costosa reestructuración de la tabla si los datos
requeridos por las consultas de ayuda a la toma de decisiones se pierden o son
incorrectos.
Las características de las tablas hecho son:
 Muchas filas, posiblemente Billones.
 Principalmente datos numéricos; raramente caracteres.
 Múltiples claves externas (en las tablas dimensionales).
 Datos estáticos.
Tablas Dimensiones
Contiene datos que se utilizan para hacer referencia a los datos almacenados en las
tablas hechos, como descripciones de productos, nombres y direcciones de clientes y
proveedores. La separación de esta información detallada (normalmente de tipo
carácter) de los sucesos específicos, como el valor de una venta en un momento
determinado, hace posible optimizar las consultas con las bases de datos al reducir el
conjunto de datos que se debe recorrer en la tabla de hechos.
Las tablas de dimensiones no contienen tantas filas como las tablas hecho y los datos
dimensionales están sujetos a cambios, como cambia la dirección y teléfonos de os
clientes. Las tablas dimensionales se estructuran para permitir cambios.
Las características de las tablas dimensionales son:
 Menos filas que las tablas hecho; posiblemente cientos de miles.
 Contienen, principalmente, datos de tipo carácter.
 Varias columnas que se utilizan para administrar las jerarquías de
Dimensiones.
 Una clave principal (la clave dimensional).
 Datos actualizables.
Dimensiones
Son categorías de información que organizan los datos del almacén, como el tiempo,
geografía, organización, etc. Normalmente, las dimensiones son jerárquicas en el
sentido de que un miembro puede ser un elemento secundario de otro miembro. Por
ejemplo, una dimensión geografía puede contener datos por país, estado y ciudad.
Una ciudad miembro es un elemento secundario para un estado miembro, que en si
mismo es un elemento secundario de un país miembro. De esta forma, una dimensión
se divide en tres capas jerárquicas: todos los países, todos los estados y todas las
ciudades en las tablas de dimensiones. Para admitir esto, la tabla dimensiones debería
incluir la relación de cada miembro con las capas superiores de la jerarquía.
Claves dimensionales
Son identificadores exclusivos que se utilizan para implementar un almacén de los
datos almacenados en la tabla de hechos principal. La clave dimensional, al igual que
una clave principal, enlaza una fila de datos en la tabla hecho con una tabla de
dimensiones. Esta estructura permite generar fácilmente consultas complejas y
admitir un traspaso de detalles en aplicaciones para ayudar en la toma de decisiones.
Una base de datos óptima de un almacén de datos contiene tablas de hecho largas y
estrechas, y tablas dimensionales pequeñas y anchas.
Esquema Estrella
La técnica de diseño más popular para implementar un almacén de datos (Data Mart)
es el esquema estrella. La estructura de este tipo de esquema aprovecha las consultas
típicas de ayuda a la toma de decisiones al utilizar una tabla de hecho central acerca
del área en estudio y muchas tablas dimensiones que contienen descripciones no
normalizadas de los hechos. Una vez creada las tablas de hechos, las herramientas
OLAP pueden usarse para agregar previamente información a la que se tiene acceso
frecuentemente. El diseño de estrella ayuda a aumentar el rendimiento de las
consultas al reducir el volumen de los datos que tienen que leerse del disco. Las
consultas analizan los datos en las tablas dimensiones más pequeñas para obtener las
claves de dimensión que indican la tabla de hechos central, rediciendo el número de
filas que se debe recorrer.
[TUT-98]
ANEXO D
PROCESAMIENTO ANALÍTICO EN LINEA
En muchas ocasiones, un almacén de datos se utiliza como base de los sistemas de ayuda
a la toma de decisiones (al que también se hace referencia, desde una perspectiva
analítica, como un sistema de inteligencia empresarial). Se diseña para superar algunos
problemas que una organización encuentra cuando intenta realizar un análisis estratégico
mediante la misma base de datos que utilizar el proceso de transacción con conexión.
(OLTP). Un sistema OLTP clásico se caracteriza por tener un número de usuarios
simultáneos que agregan y modifican datos de manera activa. La base de datos
representa el estado de una función particular del negocio en un momento específico,
como en un sistema de reserva de una línea aérea. Sin embargo, el gran volumen de
datos mantenido por muchos sistemas OLTP puede desbordar a una organización. Puesto
que el crecimiento de una base de datos se hace mayor cuando más complejos son los
datos, el tiempo de respuesta puede deteriorarse rápidamente debido a la lucha por los
recursos disponibles. Un sistema OLTP típico tiene usuarios que agregan datos nuevos a
la base de datos mientras unos pocos generan informes de la base de datos. A medida
que aumentan el volumen de datos, se tarda más en generar los informes.
Puesto que las organizaciones reúnen volúmenes cada vez mayores de datos al utilizar
sistemas de base de datos OLTP, la necesidad de analizar los datos es más acusada.
Normalmente, los sistemas OLTP están diseñados específicamente para administrar el
proceso de transacciones y minimizar los requerimientos de almacenamiento en disco
mediante una serie de tablas normalizadas y relacionadas. Sin embargo, cuando los
usuarios necesitan analizar datos, muchos problemas impiden a menudo su uso:
 Los usuarios no pueden entender las complejas relaciones entre las tablas y , en
consecuencia, no pueden generar consultas ad hoc.
 Las bases de datos de la aplicación pueden estar divididas entre varios servidores
y dificultan a los usuarios encontrar las tablas en la primera.
 Las restricciones de seguridad pueden impedir a los usuarios el acceso a los datos
detallados que necesitan.
 Los administradores del base de datos impiden las consultas ad hoc en sistemas
OLTP, para evitar que los usuarios que realizan el análisis ejecuten consultas que
podrían disminuir el rendimiento de la base de datos de producción de gran
importancia.
Al copiar un sistema OLTP a un servidor de informes sobre una base programada
regularmente, una organización puede mejorar el tiempo de respuesta para los informes y
las consultas. Aun así, a menudo, un esquema optimizado para OLTP no es lo
suficientemente para aplicaciones de ayuda a la toma de decisiones, fundamentalmente
debido al volumen de datos involucrados y a la complejidad de las tablas normalizadas.
Por ejemplo, cada jefe regional de ventas de una compañía puede desear un resumen
mensual de vetas por región. Debido a que el servidor de informes contiene datos tan
detallados como los de los sistemas OLTP, los datos del mes completo se resumen cada
vez que se genere el informe. El resultado son consultas con un mayor tiempo de
ejecución y una menor satisfacción del usuario.
Además, muchas organizaciones almacenan los datos en varios sistemas de base de datos
heterogéneos. Realizar informes es más difícil, no solo porque los datos están
almacenados en lugares distintos sino porque, además, los estás en diferentes formatos.
Algunas veces, las organizaciones desean mantener almacenes de datos más pequeños
más especializados en un tema, llamados puestos de datos. A diferencia de un almacén
de datos, que normalmente encapsula todos los datos de análisis de una empresa, un
puesto de datos es un subconjunto de datos de la empresa cuyo objetivo es constituir un
conjunto más pequeño de funciones de usuario o de negocio.
Si bien en un almacén o puesto de datos se almacenan los datos para su análisis, OLAP
es la tecnología que permite a las aplicaciones cliente el acceso eficiente a estos datos.
OLAP proporciona los siguientes beneficios a los usuarios que realizan análisis de los
datos:
 Agregación previa de los datos frecuentemente consultados, que permite que el
tiempo de respuesta de las consultas ad hoc sea muy pequeña.
 Un modelo intuitivo multidimensional de datos que facilita su selección,
recorrido y exploración.
 Una eficaz herramienta para crear nuevas vistas de datos basadas en una rica
matriz de funciones de cálculo ad hoc.
 Tecnología para administrar la seguridad, la administración de consultas cliente
servidos y el almacenamiento de los datos en la memoria caché y facilidades para
optimizar el rendimiento del sistema según las necesidades del usuario.
Los términos almacén de datos y OLAP se utilizan a menudo de manera intercambiable.
Sin embargo, es importante entender sus diferencias, porque cada uno representa un
conjunto único de tecnologías, temas administrativos e implicaciones para el usuario.
Modos de almacenamiento (MOLAP, ROLAP, HOLAP)

La explotación del Data Warehouse o del Data Mart mediante información de gestión, se
fundamenta básicamente en los niveles agrupados o calculados de información.
La información de gestión se compone de conceptos de información y coeficientes de
gestión, que los cuadros directivos de la empresa pueden consultar según las
dimensiones de negocio que se definan.
Dichas dimensiones de negocio se estructuran a su vez en distintos niveles de detalle
(por ejemplo, la dimensión geográfica puede constar de los niveles nacional, provincial,
ayuntamientos y sección censal).
Este tipo de sistemas ha existido desde hace tiempo, en el mundo de la informática bajo
distintas denominaciones: cuadros de mando, MIS, EIS, etc.
Su realización fuera del entorno del Data Warehouse, puede repercutir sobre estos
sistemas en una mayor rigidez, dificultad de actualización y mantenimiento, malos
tiempos de respuesta, incoherencias de la información, falta del dato agregado, etc.
Los sistemas de soporte a la decisión usando tecnologías de Data Warehouse, se llaman
sistemas OLAP (siglas de On Line Analytical Processing (OLAP). En general, estos
sistemas OLAP deben:
 Soportar requerimientos complejos de análisis
 Analizar datos desde diferentes perspectivas
 Soportar análisis complejos contra un volumen ingente de datos
La funcionalidad de los sistemas OLAP se caracteriza por ser un análisis
multidimensional de datos corporativos, que soportan los análisis del usuario y unas
posibilidades de navegación, seleccionando la información a obtener.
Normalmente este tipo de selecciones se ve reflejada en la visualización de la estructura
multidimensional, en unos campos de selección que nos permitan elegir el nivel de
agregación (jerarquía) de la dimensión, y/o la elección de un dato en concreto, la
visualización de los atributos del sujeto, frente a una(s) dimensiones en modo tabla,
pudiendo con ello realizar, entre otras las siguientes acciones:
Rotar (Swap): alterar las filas por columnas (permutar dos dimensiones de
análisis)
Bajar (Down): bajar el nivel de visualización en las filas a una jerarquía
inferior
Detallar (Drilldown): informar para una fila en concreto, de datos a un nivel
inferior
Expandir (Expand): id. anterior sin perder la información a nivel superior para éste
y el resto de los valores
Colapsar (Collapse): operación inversa de la anterior.
en donde se describen en torno a 50 términos relacionados con las posibilidades de

navegación que permiten este tipo de análisis.
Existen dos arquitecturas diferentes para los sistemas OLAP: OLAP multidimensional
(MOLAP) y OLAP relacionales (ROLAP).
Sistemas MOLAP
La arquitectura MOLAP usa unas bases de datos multidimensionales para proporcionar
el análisis, su principal premisa es que el OLAP está mejor implantado almacenando los
datos multidimensionalmente. Por el contrario, la arquitectura ROLAP cree que las
capacidades OLAP están perfectamente implantadas sobre bases de datos relacionales
Un sistema MOLAP usa una base de datos propietaria multidimensional, en la que la
información se almacena multidimensionalmente, para ser visualizada
multidimencionalmente.
El sistema MOLAP utiliza una arquitectura de dos niveles: Las bases de datos
multidimensionales y el motor analítico.
La base de datos multidimensional es la encargada del manejo, acceso y obtención del
dato.
El nivel de aplicación es el responsable de la ejecución de los requerimientos OLAP. El
nivel de presentación se integra con el de aplicación y proporciona un interfaz a través
del cual los usuarios finales visualizan los análisis OLAP. Una arquitectura
cliente/servidor permite a varios usuarios acceder a la misma base de datos
multidimensional.
La información procedente de los sistemas operacionales, se carga en el sistema
MOLAP, mediante una serie de rutinas batch. Una vez cargado el dato elemental en la
Base de Datos multidimensional (MDDB), se realizan una serie de cálculos en batch,
para calcular los datos agregados, a través de las dimensiones de negocio, rellenando la
estructura MDDB.
Tras rellenar esta estructura, se generan unos índices y algoritmos de tablas hash para
mejorar los tiempos de accesos a las consultas.
Una vez que el proceso de compilación se ha acabado, la MDDB está lista para su uso.
Los usuarios solicitan informes a través de la interface, y la lógica de aplicación de la
MDDB obtiene el dato.
La arquitectura MOLAP requiere unos cálculos intensivos de compilación. Lee de datos
precompilados, y tiene capacidades limitadas de crear agregaciones dinámicamente o de
hallar ratios que no se hayan pre calculados y almacenados previamente.
Sistemas ROLAP
La arquitectura ROLAP, accede a los datos almacenados en un Data Warehouse para
proporcionar los análisis OLAP. La premisa de los sistemas ROLAP es que las
capacidades OLAP se soportan mejor contra las bases de datos relacionales.
El sistema ROLAP utiliza una arquitectura de tres niveles. La base de datos relacional
maneja los requerimientos de almacenamiento de datos, y el motor ROLAP proporciona
la funcionalidad analítica. El nivel de base de datos usa bases de datos relacionales para
el manejo, acceso y obtención del dato. El nivel de aplicación es el motor que ejecuta las
consultas multidimensionales de los usuarios. El motor ROLAP se integra con niveles de
presentación, a través de los cuales los usuarios realizan los análisis OLAP. Después de
que el modelo de datos para el Data Warehouse se ha definido, los datos se cargan desde
el sistema operacional. Se ejecutan rutinas de bases de datos para agregar el dato, si así
es requerido por el modelo de datos.
Se crean entonces los índices para optimizar los tiempos de acceso a las consultas.
Los usuarios finales ejecutan sus análisis multidimensionales, a través del motor
ROLAP, que transforma dinámicamente sus consultas a consultas SQL. Se ejecutan estas
consultas SQL en las bases de datos relacionales, y sus resultados se relacionan mediante
tablas cruzadas y conjuntos multidimensionales para devolver los resultados a los
usuarios. La arquitectura ROLAP es capaz de usar datos precalculados si estos están
disponibles, o de generar dinámicamente los resultados desde los datos elementales si es
preciso. Esta arquitectura accede directamente a los datos del Data Warehouse, y soporta
técnicas de optimización de accesos para acelerar las consultas. Estas optimizaciones
son, entre otras, particionado de los datos a nivel de aplicación, soporte a la
desnormalización y joins múltiples.
ROLAP vs. MOLAP (Comparativa)

Cuando se comparan las dos arquitecturas, se pueden realizar las siguientes
observaciones:
El ROLAP delega la negociación entre tiempo de respuesta y el proceso batch al diseño
del sistema. Mientras, el MOLAP, suele requerir que sus bases de datos se precompilen
para conseguir un rendimiento aceptable en las consultas, incrementando, por tanto, los
requerimientos batch.
Los sistemas con alta volatilidad de los datos (aquellos en los que cambian las reglas de
agregación y consolidación), requieren una arquitectura que pueda realizar esta
consolidación ad-hoc. Los sistemas ROLAP soportan bien esta consolidación dinámica,
mientras que los MOLAP están más orientados hacia consolidaciones batch.
Los ROLAP pueden crecer hasta un gran número de dimensiones, mientras que los
MOLAP generalmente son adecuados para diez o menos dimensiones.
Los ROLAP soportan análisis OLAP contra grandes volúmenes de datos elementales,
mientras que los MOLAP se comportan razonablemente en volúmenes más reducidos
(menos de 5 Gb)
Por ello, y resumiendo, el ROLAP es una arquitectura flexible y general, que crece para
dar soporte a amplios requerimientos OLAP. El MOLAP es una solución particular,
adecuada para soluciones departamentales con unos volúmenes de información y número
de dimensiones más modestos.
ANEXO E
Uso del Diseñador DTS
El Diseñador DTS implementa de forma gráfica el modelo de objetos DTS,

posibilitando la creación gráfica de paquetes DTS. Puede utilizar el Diseñador
DTS para:
 Crear un paquete simple que contenga uno o más pasos.
 Crear un paquete que incluya flujos de trabajo complejos que comprendan
varios pasos utilizando la lógica condicional, el código controlado por
eventos o las conexiones múltiples a los orígenes de datos.
 Editar paquetes existentes.
La interfaz del Diseñador DTS consta de un área de trabajo para la creación de
paquetes, barras de herramientas que incluyen elementos del paquete y que se
pueden arrastrar a la hoja de diseño y, por último, menús que contienen los flujos
de trabajo y los comandos de administración de los paquetes.
Interfaz del Diseñador DTS

Al arrastrar las conexiones y tareas a la hoja de diseño y especificar el orden de
ejecución de los flujos de trabajo, se pueden desarrollar fácilmente eficaces paquetes
DTS utilizando el Diseñador DTS. Las secciones siguientes definen las tareas, los flujos
de trabajo, las conexiones y las transformaciones que tienen lugar e ilustran la facilidad
de utilización del Diseñador DTS para implementar una solución DTS.
Tareas: Definición de los pasos para la creación de paquetes

Un paquete DTS generalmente incluye una o varias tareas, cada una de las cuales define
un elemento de trabajo que se puede llevar a cabo durante la ejecución del paquete. Las
tareas se pueden emplear para:
Transformar datos
Tarea Permite mover datos entre el origen y el destino y, de manera

Transformar opcional, aplicar transformaciones a los datos a nivel de
datos columna.
Tarea de Permite llevar a cabo operaciones flexibles basadas en Transact-

consulta SQL con los datos, incluyendo procedimientos almacenados y
controlada las instrucciones INSERT, UPDATE o DELETE.
por datos
Tarea de Sólo disponible mediante programación, la tarea de bombeo

bombeo paralelo de datos realiza las mismas funciones que Transformar
paralelo de datos y la tarea de consulta controlada por datos, sin embargo,
datos1 admite conjuntos de filas divididos en segmentos tal como se
definen en OLE DB 2.5 y versiones posteriores.
Copiar y administrar datos
Tarea de Permite cargar rápidamente cantidades importantes de datos

inserción en una vista o una tabla de SQL Server.
masiva
Tarea Ejecutar Permite ejecutar instrucciones SQL durante la ejecución de los

SQL paquetes. La tarea Ejecutar SQL también puede almacenar los
datos que resulten de las consultas.
Tarea de copia Permite copiar objetos de SQL Server de una instalación o

de objetos de instancia de SQL Server a otra. Puede copiar tablas y datos,
SQL Server así como definiciones de objetos, por ejemplo, vistas y
procedimientos almacenados.
Tarea de Permite mover o copiar una base de datos SQL Server de una
transferencia instancia de la versión 7.0 de SQL Server o SQL Server 2000
de base de a una instancia de SQL Server 2000.
datos1
Tarea de Permite copiar mensajes de error especificados por el usuario,

transferencia creados por el procedimiento almacenado del sistema
de mensajes de sp_addmessage de una instancia de SQL Server 7.0 o SQL
error1 Server 2000 a otra de SQL Server 2000.
Tarea de Permite copiar inicios de sesión de una instancia de SQL

transferencia Server 7.0 o SQL Server 2000 a otra de SQL Server 2000.
de inicios de
sesión1
Tarea de Permite copiar trabajos de una instancia de SQL Server 7.0 o

transferencia SQL Server 2000 a otra de SQL Server 2000.
1
de trabajos
Tarea de Permite copiar procedimientos almacenados de una base de

transferencia datos maestra en una instancia de SQL Server 7.0 o SQL
de Server 2000 a la base de datos maestra en una instancia de
procedimientos SQL Server 2000.
almacenados
maestros1
Ejecutar tareas como trabajos dentro de un paquete
Tarea de Permite escribir código que lleve a cabo funciones no

secuencia de disponibles en las demás tareas de DTS.
comandos
ActiveX
Tarea Permite recuperar valores de orígenes fuera de un paquete DTS

Propiedades durante el tiempo de ejecución de éste último y asignarlos a
dinámicas1 propiedades de paquete seleccionadas.
Tarea Permite ejecutar otros paquetes DTS dentro de un paquete.

Ejecutar
paquete1
Tarea de Permite iniciar un programa ejecutable o un archivo de lotes.

ejecución de
proceso
Tarea Permite descargar archivos de datos de un servidor remoto o

Protocolo de una ubicación en Internet.
transferencia
de archivos
(FTP)1
Tarea Cola de Permite enviar y recibir mensajes de las colas de mensajes de

mensajes1 Microsoft.
Tarea Enviar Permite enviar mensajes de correo electrónico.

correo
Tarea de Permite llevar a cabo el procesamiento de uno o varios objetos

procesamiento definidos en los servicios de análisis de SQL Server 2000.
de servicios
de análisis2
Tarea de Permite crear una consulta de predicción y una tabla de salida a

extracción de partir de un objeto modelo de extracción de datos en los
datos1,2 servicios de análisis de SQL Server 2000.
También se pueden crear tareas personalizadas mediante programación y, a
continuación, integrarlas en el Diseñador DTS utilizando el comando Registrar tarea
personalizada.
Para ilustrar con mayor claridad el uso de las tareas se presenta a continuación un
paquete DTS simple con dos tareas: una tarea de secuencia de comandos de Microsoft
ActiveX® y una tarea Enviar correo:
Paquete DTS con dos Tareas
La tarea de secuencia de comandos ActiveX puede alojar cualquier motor de secuencia

de comandos ActiveX, incluyendo Microsoft Visual Basic Scripting Edition (VBScript),
Microsoft JScript® o ActiveState ActivePerl, pudiéndose descargar este último en
http://www.activestate.com. La tarea Enviar correo puede enviar un mensaje que indique
que el paquete se ha ejecutado. Tenga en cuenta que aún no existe un orden establecido
en la ejecución de las tareas; cuando se ejecuta el paquete, las tareas de secuencia de
comandos ActiveX y Enviar correo se ejecutan al mismo tiempo.
Flujos de trabajo: Establecimiento de la prioridad en las tareas

Cuando se define un grupo de tareas, existe por norma general un orden establecido en
su ejecución, en cuyo caso, cada una de las tareas constituye un paso en el proceso. En el
Diseñador DTS, se pueden manipular las tareas en la hoja de estilo y utilizar
restricciones de prioridad que controlen la secuencia en la que éstas se ejecutan.
Las restricciones de prioridad se vinculan de forma secuencial en un paquete. La tabla
siguiente muestra los tipos de restricciones de prioridad que se pueden utilizar en DTS.
Restricciones de prioridad Descripción
Si desea que la tarea 2 espere a que se ejecute la tarea

Al concluir 1, independientemente del resultado, vincule la tarea 1
(flecha azul) a la 2 con la restricción de prioridad Al concluir.
Si desea que la tarea 2 espere a que la tarea 1 se haya

En caso de éxito ejecutado con éxito, vincule la tarea 1 a la 2 con la
(flecha verde) restricción de prioridad En caso de éxito.
Si desea que la tarea 2 comience a ejecutarse sólo si

En caso de error se produce un error en la tarea 1, vincule la tarea 1 a
(flecha roja) la 2 con la restricción de prioridad En caso de error.
La siguiente ilustración muestra las tareas de secuencia de comandos ActiveX y Enviar

correo con una restricción de prioridad Al concluir. La tarea Enviar correo no se ejecuta
hasta que no ha terminado la ejecución de la tarea de secuencia de comandos Active X,
independientemente del éxito o del error de la primera.
Tareas de secuencia de comandos ActiveX y Enviar correo con una restricción de

prioridad Al concluir
Se puede configurar más de una tarea Enviar correo simultáneamente, una para la
restricción En caso de éxito y otra para En caso de error. Estas dos tareas podrán enviar
distintos mensajes en función del éxito o error de la secuencia de comandos ActiveX.
Tareas de Correo
También se pueden establecer varias restricciones en una tarea. Por ejemplo,

"Notificación del administrador" de la tarea Enviar correo podía haber contado con la
restricción En caso de éxito para la secuencia de comando nº 1 y En caso de error para la
nº 2. En estos casos, DTS asume una relación lógica "AND". Por tanto, la secuencia nº 1
deberá ejecutarse con éxito y la nº 2 deberá resultar en un error para que se pueda enviar
la mencionada notificación.
Ejemplo de varias restricciones de prioridad en una Tarea
Conexiones: Acceso y movimiento de los datos

Para poder ejecutar con éxito las tareas de DTS que permiten copiar y transformar datos,
un paquete DTS debe establecer las conexiones adecuadas a los datos de origen y destino
y a cualquier otro origen de datos adicional, por ejemplo, las tablas de consulta.
Cuando se crea un paquete, el usuario configura las conexiones seleccionando el tipo en
una lista de proveedores OLE DB y de controladores ODBC. Los tipos de conexiones
disponibles son los siguientes:
Controladores de Microsoft Data Access Components (MDAC)
Proveedor Microsoft OLE DB para SQL Server
Microsoft Data Link
Controlador ODBC para Oracle de Microsoft
Controladores Microsoft Jet
dBase 5
Microsoft Access
Archivo HTML (Origen)
Microsoft Excel 97-2000
Paradox 5.X
Otros controladores
Archivo de texto (Origen)
Archivo de texto (Destino)
Otras conexiones
DTS permite utilizar cualquier conexión OLE DB. Los iconos que aparecen en la barra
de herramientas de conexión proporcionan un rápido acceso a las conexiones más
comunes.
La siguiente ilustración muestra un paquete con dos conexiones. Los datos se copian de
una base de datos de Access (la conexión de origen) a una base de datos de SQL Server
Production (la conexión destino).
Ejemplo de paquete con dos Conexiones
El primero de los pasos de este paquete es una tarea Ejecutar SQL, que comprueba si la
tabla de destino existe. Si es así, la tabla se omite y se vuelve a crear. En la restricción En
caso de éxito de la tarea Ejecutar SQL, los datos se copian a la base de datos SQL Server
en el paso 2. Si esta operación resultara en un error se enviaría un mensaje de correo
electrónico en el paso 3.
Bombeo de datos: Transformación de los datos

El bombeo de datos de DTS es un objeto DTS que lleva a cabo la importación,
exportación y transformación de los datos. Se utiliza durante la ejecución de las tareas de
transformación de datos, de consulta controlada por datos y de bombeo paralelo de datos.
Dichas tareas crean conjuntos de filas en las conexiones de origen y destino y, a
continuación, una instancia de bombeo de datos que mueve las filas entre el origen y el
destino. A medida que se va copiando cada fila, se producen transformaciones en las
mismas.
En la siguiente ilustración, se utiliza una tarea Transformar datos entre la tarea de base
de datos de Access y la tarea de base de SQL Production en el paso 2. La tarea
Transformar datos es la representada por la flecha gris entre las conexiones.
Ejemplo de tarea Transformar Datos
Para definir los datos recopilados en la conexión de origen se puede crear una consulta
para las tareas de transformación. DTS admite consulta parametrizadas, lo que permite
definir los valores de las mismas cuando éstas se ejecutan.
Se puede escribir una consulta en el cuadro de diálogo de propiedades de la tarea, o
bien, utilizar el Diseñador de consultas de los Servicios de transformación de datos,
herramienta que permite la creación gráfica de consultas para las tareas de DTS. En la
siguiente ilustración, el Diseñador de consultas se emplea para crear una consulta que
une tres tablas en la base de datos pubs.
Interfaz del Diseñador de Consultas de los Servicios de Transformación de Datos
En las tareas de transformación, también se pueden definir los cambios que se van a
implementar en los datos. La siguiente tabla muestra las transformaciones integradas que
proporciona DTS.
Transformación Descripción
Copy Column Permite copiar datos directamente desde el origen a la columnas de

destino, sin que se aplique transformación alguna a los datos.
ActiveX Script Permite crear transformaciones personalizadas. Observe que puesto

que la transformación tiene lugar fila a fila, una secuencia de
comandos ActiveX puede afectar a la velocidad de ejecución del
paquete DTS.
DateTime String Permite convertir una fecha u hora en la columna de origen a un

formato diferente en la de destino.
Lowercase String Permite convertir una columna de origen a caracteres en minúsculas

y, si fuera necesario, al tipo de datos de destino.
Uppercase String Permite convertir una columna de origen a caracteres en mayúsculas

y, si fuera necesario, al tipo de datos de destino.
Middle of String Permite extraer una subcadena de la columna de origen,

transformarla y copiar el resultado a la columna de destino.
Trim String Permite eliminar los espacios en blanco iniciales, finales o

integrados de una cadena en la columna de origen y copiar el
resultado a la de destino.
Read File Permite abrir el contenido de un archivo, cuyo nombre se especifica

en la columna de origen, y copiar su contenido a la columna de
destino.
Write File Permite copiar el contenido de una columna de origen (columna de

datos) a un archivo cuya ruta la especifica una segunda columna de
origen (columna de nombre de archivo).
Asimismo, se pueden crear transformaciones personalizadas mediante programación. La
forma más rápida de realizarlo es utilizar la plantilla de transformaciones personalizadas
de Active Template Library (ATL), incluida en los programas de ejemplo de DTS de
SQL Server 2000.
Registro de errores del bombeo de datos

Un nuevo método para el registro de los errores en la transformación se encuentra
disponible en SQL Server 2000. Se pueden definir tres archivos de registro de
excepciones para su utilización durante la ejecución de los paquetes: un archivo de texto
de errores, un archivo de filas de error de origen y otro de filas de error de destino.
La información general se escribe en el archivo de texto de errores.
Si la transformación no se produce correctamente, la fila de origen presenta un error,
recopilándose entonces esta información en el archivo de filas de error de origen.
Si es una inserción la que resulta en error en este caso, entonces el error se produce en la
fila de destino y dicha fila se escribe en el archivo de filas de error de destino.
Los archivos de registro de excepciones se definen en las tareas que transforman datos;
cada una de las transformaciones dispone de sus propios archivos de registro.
Fases en el bombeo de datos

De forma predeterminada, el bombeo de datos tiene lugar en una única fase: la
transformación de filas. Dicha fase es la que se configura cuando se asignan las
transformaciones a nivel de columna en la tarea Transformar datos, de consulta
controlada por datos y de bombeo paralelo de datos, sin necesidad de seleccionar
ninguna fase.
SQL Server 2000 introduce múltiples fases como novedad. Seleccionando la opción de
bombeo de datos multifase en el Administrador corporativo de SQL Server, se puede
obtener acceso al bombeo de datos en distintos momentos durante el proceso y agregarle
una mayor funcionalidad.
Cuando se copia una fila de datos de un origen a un destino, el bombeo de datos sigue el
proceso básico que aparece en la siguiente ilustración.
Proceso de Bombeo de Datos
Una vez el bombeo de datos procesa la última fila de datos, la tarea y la operación de
bombeo de datos se dan por completadas.
Los usuarios avanzados que deseen agregar funcionalidad a un paquete para que éste
admita cualquier fase de bombeo de datos pueden llevarlo a cabo de la siguiente manera:
Escribiendo una función de fase de secuencia de comandos ActiveX para cada fase de
bombeo de datos que se va a personalizar. Si se utilizan funciones de secuencias de
comandos ActiveX para personalizar las fases de bombeo, no se requiere ningún código
adicional fuera del paquete.
Creando un objeto COM en Microsoft Visual C++® para personalizar las fases del
bombeo de datos seleccionado. Este programa se desarrolla de forma externa al paquete
y se llama en cada fase seleccionada de la transformación. A diferencia del método de
secuencia de comandos ActiveX para obtener acceso a las fases del bombeo de datos,
que emplea una función y un punto de entrada distintos para cada una de las fases
seleccionadas, este método proporciona un único punto de entrada al que llaman
múltiples fases mientras que se ejecuta la tarea de bombeo.
Opciones para el almacenamiento de paquetes DTS
Las siguientes son las opciones disponibles para el almacenamiento de paquetes DTS:
Microsoft SQL Server
Guarde el paquete DTS en Microsoft SQL Server si lo que desea es almacenarlos en una
única instancia de SQL Server de su red, mantener un inventario adecuado de los
mismos y agregar o eliminar sus versiones durante el proceso de desarrollo de los
paquetes.
Meta Data Services de SQL Server 2000
Guarde el paquete DTS en los Meta Data Services si desea realizar un seguimiento de la
versión, los metadatos y la información del linaje de los datos del paquete.
Archivo de almacenamiento estructurado
Guarde el paquete DTS en un archivo de almacenamiento estructurado si lo que desea es
copiar, mover y enviar un paquete a través de la red sin tener que almacenarlo en una
base de datos Microsoft SQL Server.
Microsoft Visual Basic
Guarde el paquete DTS creado por el Diseñador DTS o el Asistente para
importación/exportación con DTS en un archivo de Microsoft Visual Basic si lo que
desea es incorporarlo a los programas de Visual Basic o utilizarlo para el desarrollo de la
propia aplicación DTS.
DTS como plataforma de desarrollo de aplicaciones
El Diseñador DTS proporciona una amplia variedad de soluciones a las tareas de
movimiento de datos. DTS extiende las soluciones disponibles proporcionando acceso
mediante programación al modelo de objetos DTS. Con Microsoft Visual Basic,
Microsoft Visual C++ o cualquier otro sistema de desarrollo de aplicaciones que admita
COM, se puede desarrollar una solución DTS personalizada para un entorno con una
funcionalidad sin compatibilidad con las herramientas gráficas.
DTS ofrece al desarrollador compatibilidad de formas distintas:
Creación de paquetes
Se pueden desarrollar paquetes muy complejos y obtener acceso a una amplia
funcionalidad en el modelo de objetos sin necesidad de utilizar el Diseñador DTS o el
Asistente para importación/exportación con DTS.
Extensión de paquetes
Se puede agregar una nueva funcionalidad gracias a la creación de tareas y
transformaciones personalizadas para una empresa en concreto y que se pueden volver a
utilizar en DTS.
Ejecución de paquetes
La ejecución de los paquetes DTS no se debe realizar necesariamente desde las
herramientas proporcionadas, se puede llevar a cabo mediante programación, pudiéndose
visualizar su progreso a través de eventos COM y permitiendo de este modo la creación
de entornos de ejecución de DTS integrados o personalizados.
Existen programas DTS de ejemplo disponibles para facilitar la iniciación en la
programación de DTS y que se pueden instalar con SQL Server 2000.
Si se desea desarrollar una aplicación DTS, se pueden redistribuir los archivos DTS. Para
obtener más información consulte Redist.txt en el CD-ROM de SQL Server 2000.
ANEXO F
CUESTIONARIO DIRIGIDO AL GERENTE DE CAMPO DE LA EMPRESA AGROINDUSTRIAL CASA GRANDE S.A.A.
SISTEMA MANUAL SIE

CUESTIONARIO Media Muy
Insatisfecho Satisfecho Muy satisfecho Insatisfecho Media Satisfecho Satisfecho
Satisfecho Satisfecho
Cuál es la cantidad de hectáreas preparadas para
los diferentes tipos de caña producidas en una
determinada zona o anexo o campo en los
Cuál es la cantidad de hectáreas sembradas para
Cuál es la cantidad de hectáreas cosechadas para
Conocer la cantidad invertida para los tipos de
insumo usados en la preparación en los
diferentes campos de un anexo de una zona
insumo usados en la siembra en los diferentes
campos de un anexo de una zona determinada en
el año, trimestre o año vigente.
insumo usados en la cosecha en los diferentes
campos de un anexo de una zona determinada en
el año, trimestre o año vigente.
Cuál es el costo de la mano de obra por campo,
zona y anexo en un mes o trimestre de un año
específico para la preparación.
específico para la siembra.
específico para la cosecha.
Determine los niveles de inversión de transporte
para la preparación utilizado por zona, anexo y
campo en un período determinado.
para siembra utilizado por zona, anexo y campo
en un período determinado.

para la cosecha utilizado por zona, anexo y
campo en un período determinado.
Determinar el costo de transporte por tipo de caña

en la preparación por períodos determinados.
en la siembra por períodos determinados.
en la cosecha por períodos determinados.
Cuál es el costo de personal por hectárea en un
período de tiempo determinado, ya sea mensual,
trimestral o anual para la preparación.
trimestral o anual para la siembra.
trimestral o anual para la cosecha.
ANEXO G
Encuesta a los Usuarios finales
1. La forma como se accesa a la información del sistema mediante interfaces,

tabulaciones y reportes, a su criterio es:
1 = Malo 2 = Regular 3 = Bueno 4 = Excelente
2. La calidad de información que suministra el sistema a su criterio, es:
3. La variedad en la presentación de la forma de la información en el sistema es a su

parecer:
4. El tiempo de respuesta del sistema frente a una petición suya es:
5. Las conformidades de los datos suministrados por el sistema se ajustan a la

realidad, de manera:
6. Su adaptación al manejo del sistema fue:
7. Dentro de la fiabilidad de la información que suministra el sistema Ud. Confía

que la información sea:
8. El aprendizaje para el manejo del sistema fue muy:
9. El contar con un sistema de este tipo, considera que beneficia a la empresa frente
a la competencia, de manera:

10. Su moral como Gerente de Campo frente a la introducción de nuevas tecnologías
al área es:
11. Las pantallas de presentación a su criterio se encuentran personalizas:
1 = Si 2 = No
12. El sistema a su parecer a cumplido con los requerimientos que Ud. Propuso antes
de su construcción:
1 = Si 2 = No
Calificación
14 puntos a 21 puntos = El sistema es malo
22 puntos a 28 puntos = El sistema es regular
29 puntos a 37 puntos = El sistema es bueno
38 puntos a 42 puntos = El sistema es excelente
ANEXO H
En la tabulación de los datos para la Contrastación de la Hipótesis se tuvieron en cuenta

los siguientes aspectos:
1. La encuesta fue aplicada al Gerente de Campo de la Empresa Agroindustrial Casa

Grande SAA.
2. Los valores que el usuario dieron a las respuestas del cuestionario fueron
aplicados según el rango de satisfacción que a continuación se muestra:
3.
RANGO GRADO DE SATISFACCION
0 – 2.5 Insatisfecho
2.5 – 5.0 Medianamente Satisfecho
5.0 – 7.5 Satisfecho
7.5 – 10.0 Muy Satisfecho
4. A continuación, mostramos los valores conseguidos por cada respuesta y su

tabulación respectiva de la encuesta:
Muestra X i = Aplicada antes de desarrollar el Software
Muestra Yi = Aplicada después de desarrollar el Software

N Xi Yi di  X i  Yi di2
1 0 8.5 8.50 72.25
2 0 8 8.00 64.00
3 2.5 9 6.50 42.25
4 0 8.5 8.50 72.25
5 2.5 8 5.50 30.25
6 1 9 8.00 64.00
7 2 9 7.00 49.00
8 2.5 8.5 6.00 36.00
9 0 8.5 8.50 72.25
10 0 8.5 8.50 72.25
11 0 8 8.00 64.00
12 0 8.5 8.50 72.25
13 2 8 6.00 36.00
14 2.5 8.5 6.00 36.00
15 0 9 9.00 81.00
16 0 8.5 8.50 72.25
17 2.5 8.5 6.00 36.00
18 0 9 9.00 81.00
 17.50 153.50 136.00 1053.00
ANEXO I
COTIZACIÓN DE PRODUCTOS Y SOLUCIONES
Señores : EMPRESA AGROINDUSTRIAL CASAGRANDE S.A.A.

Atención : GERENTE DE CAMPO
ING. IGLESIAS LEON WILMER
Después de la evaluación de sus requerimientos, a continuación,

alcanzamos cotización de nuestro producto SOFOS/EIS®, a solicitud del
interesado.
 Desarrollo e implementación de Base de Datos
Multidimensional
(base de datos estratégica) $ 5,326.60
 Creación de los cubos OLAP $ 4,500.00
 Entrega de los ejecutables del Sistema $ 7,500.00
 Capacitación para el Personal $ 2,500.00
$19,826.60
Los precios incluyen pago al personal de desarrollo e
implementación.
Cotización válida por 4 meses, sujeto a revalorización.

Tesis - Sie Casagrande S.A.A PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis - Sie Casagrande S.A.A PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PRIVADA “ANTENOR ORREGO”

Trabajo de Investigación para Optar el Título Profesional de

Br. León Paredes Vladimir Ulianov

Ing. Elmer González Herrera.

Ing. Christian Araujo Gonsález.

Ing. Carlos Castillo Diestra.

Ing. Marko Raúl Alvarado Rodríguez.

Br. León Paredes Vladimir Ulianov.

Br. Portocarrero Regalado Luis Alberto.

A Dios, por darme su infinito amor,

El presente trabajo no hubiera llegado a su culminación sin la ayuda valiosa de

A la Gerencia de Campo de la Empresa Agroindustrial Casa Grande S.A.A., por

A nuestros amigos y compañeros quienes cada día nos dieron aliento,

Aprobado por: ...................................................................................................................................................................................... ii

“SISTEMA DE INFORMACIÓN EJECUTIVO DE PRODUCCIÓN

El presente proyecto se centra en el desarrollo de un Sistema de Información Ejecutivo

Para la construcción del Sistema de Información Ejecutivo, comenzaremos nuestro

El SIE, permite a la Gerencia de Campo desarrollar estrategias más efectivas y rentables

“EXECUTIVE INFORMATION SYSTEM PRODUCTION AREA

The present project is forused in the development of a Executive Information System

La inteligencia y el éxito de las organizaciones dependen fuertemente de las

La Empresa Agroindustrial Casa Grande S.A.A. está ubicado en el Valle

Zona 1: Casa Grande

Figura I.1 Distribución de las Zonas de Producción

En la Gerencia de Campo se cuenta con información valiosa, las cuales no son

Formulación del Problema:

El presente informe de tesis está organizado en cuatro capítulos con lo cual se

Capítulo 4. Conclusiones y Recomendaciones.

FUNDAMENTO TEÓRICO Y METODOLOGÍA

1.1. FUNDAMENTO TEÓRICO

1.1.1. INTRODUCCION A LOS SISTEMAS DE INFORMACIÓN

1.1.1.1. Definición de los Sistemas de Información

1.1.1.2. Tipos de información que suministra un sistema de información

Figura 1.1 Categoría de los Sistemas de Información

Sistemas Estratégicos, orientados a soportar la toma de decisiones, facilitan la

Sistemas Tácticos, diseñados para soportar las actividades de coordinación de

control de tareas (Work Flow) y tratamiento de documentos (Imagen, trámite y

Sistemas Táctico-Operativos, que cubren el núcleo de operaciones tradicionales de

Sistemas Interinstitucionales, este último nivel de sistemas de información recién

operacionales siempre han sido las primeras partes de la empresa a

Sistemas De Soporte De Decisiones (DSS)

Figura 1.2 Sistema de Soporte de Decisiones (DSS)

1.1.2. SISTEMAS DE INFORMACIÓN EJECUTIVO

1.1.2.1. ¿QUÉ ES UN SIE?

generación espontánea, su llegada obedece a una serie de causas,

Figura 1.3 Lo que debe contener un SIE

 Interfaz gráfica fácil de usar y ver

posible, de hecho, solo cuando alguna propiedad de una métrica

especialización tan amplio como uno lo quiera, por ejemplo,

 Administración De Una Sola Página

 Integración De Información Proveniente De Los Cubos

SIE debe permitir integrar información de cualquier aplicación y

1.1.2.3. CARACTERÍSTICAS DE UN SIE

1.1.2.4. EL PROCESO DE DESARROLLO DE UN EIS

1.1.2.5. IMPLANTACIÓN EXITOSA DE UN SIE

 QUE SE VEA BIEN. Para que un SIE se vea bien debe de

 QUE SEA RELEVANTE. Un SIE debe dar a los ejecutivos

 QUE SEA RÁPIDO. Se necesita tiempos de respuestas

 QUE LA INFORMACIÓN ESTÉ DISPONIBLE Y

1.1.3. INDICADORES DE GESTIÓN

1.1.4. DATA MART

Es un subconjunto lógico del Data Warehouse. Un Data Warehouse está

El Data Mart es una parte de un Data Warehouse para un uso