GRADO EN INGENIERÍA

INFORMÁTICA DE GESTIÓN Y
SISTEMAS DE INFORMACIÓN

Desarrollo de un sistema
de BI con Pentaho

TRABAJO FIN DE GRADO

DOCUMENTO 1- MEMORIA

Alumno: Bahillo Gil, Xabier

Directora: Blanco Jauregui, Begoña

Curso 2020-2021
1. Resumen
Durante este proyecto se ha implementado un sistema de Business Intelligen-
ce haciendo uso de la plataforma Pentaho, con el objetivo de explotar los datos
obtenidos principalmente de un sistema de gestión de almacenes y extender las
funcionalidades ofrecidas en este.

Este documento corresponde con la memoria del Trabajo de Fin De Grado de

Xabier Bahillo, desarrollado para la titulación Ingenieria Informática de Gestión
y Sistemas de Información en la Escuela de Ingenierı́a de Bilbao de la UPV.

1
Índice
1. Resumen 1

2. Introducción 9
2.1. Descripción del Proyecto . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Definiciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Planteamiento inicial 11
3.1. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Objetivos personales . . . . . . . . . . . . . . . . . . . . . 11
3.2. Marco del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1. Fases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4. Herramientas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.2. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5. Planificación Temporal . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1. EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.2. Listado de Tareas . . . . . . . . . . . . . . . . . . . . . . 16
3.5.3. Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.6. Gestión de Riesgos . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.7. Planificación Económica . . . . . . . . . . . . . . . . . . . . . . . 27
3.7.1. Gastos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7.2. Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4. Antecedentes 29
4.1. Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2. Definición de Business Intelligence . . . . . . . . . . . . . . . . . 29
4.3. Componentes de un Business Intelligence . . . . . . . . . . . . . 30
4.3.1. Datawarehouse . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.2. Cubos OLAP . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.3. Cuadros de mando . . . . . . . . . . . . . . . . . . . . . . 32
4.4. Análisis de Herramientas . . . . . . . . . . . . . . . . . . . . . . . 32
4.4.1. Pentaho CE . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5. Captura de requisitos 35
5.1. Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2. Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . 35
5.3. Jerarquı́a de actores . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.4. Casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

6. Análisis y diseño 39
6.1. Análisis de la base de datos origen . . . . . . . . . . . . . . . . . 39
6.2. Diseño del Datawarehouse . . . . . . . . . . . . . . . . . . . . . . 42
6.3. Diseño de los cubos OLAP . . . . . . . . . . . . . . . . . . . . . . 50
6.4. Diseño de los informes predefinidos . . . . . . . . . . . . . . . . . 58

2
7. Desarrollo 62
7.1. Creación del esquema de base de datos . . . . . . . . . . . . . . . 62
7.2. Implementación del proceso ETL . . . . . . . . . . . . . . . . . . 64
7.3. Implementación de los cubos OLAP . . . . . . . . . . . . . . . . 80
7.4. Implementación de informes predefinidos . . . . . . . . . . . . . . 84
7.5. Despliegue de la aplicación web . . . . . . . . . . . . . . . . . . . 87
7.5.1. Conexión de la aplicación con el Datawarehouse . . . . . 88
7.5.2. Despliegue de los cubos OLAP . . . . . . . . . . . . . . . 89
7.5.3. Despliegue de la herramienta para consultas ad-hoc . . . 91
7.5.4. Creación de metadatos para consultas ad-hoc . . . . . . . 96
7.5.5. Despliegue de informe predefinidos . . . . . . . . . . . . . 100
7.5.6. Instalación de la aplicación BI . . . . . . . . . . . . . . . 101

8. Evaluación 104
8.1. Evaluación del proceso ETL . . . . . . . . . . . . . . . . . . . . . 104
8.2. Evaluación medidas cubos OLAP . . . . . . . . . . . . . . . . . . 106
8.3. Evaluación consultas ad-hoc . . . . . . . . . . . . . . . . . . . . . 113

9. Conclusiones y trabajo futuro 117

9.1. Planificación final . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
9.2. Reflexiones personales . . . . . . . . . . . . . . . . . . . . . . . . 119
9.3. Trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

10. Referencias 120

[Link] I: Casos de uso extendidos 123

[Link] II: Definición de metadatos 143

12.1. Compras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12.2. Ventas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
12.3. Maestros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
12.4. Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

[Link] III: Pruebas unitarias del proceso ETL 149

[Link] IV: Manual de usuario 153

14.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
14.2. Acceso a la aplicación . . . . . . . . . . . . . . . . . . . . . . . . 153
14.3. Consola de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . 154
14.4. Menú ficheros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
14.5. Menú programaciones . . . . . . . . . . . . . . . . . . . . . . . . 158
14.6. Menú administración . . . . . . . . . . . . . . . . . . . . . . . . . 159
14.7. Consultas ad-hoc . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
14.7.1. Diseñar consulta . . . . . . . . . . . . . . . . . . . . . . . 162
14.7.2. Aplicar filtro . . . . . . . . . . . . . . . . . . . . . . . . . 162
14.8. Consultas OLAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
14.9. Informes predefinidos . . . . . . . . . . . . . . . . . . . . . . . . . 166

3
Índice de figuras
1. Logotipo InLOG Consultorı́a y Soluciones . . . . . . . . . . . . . 11
2. Ciclo de vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3. EDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Diagrama Gantt . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5. Proceso ETL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6. Estructura Cubo OLAP . . . . . . . . . . . . . . . . . . . . . . . 31
7. Diagrama Arquitectura Pentaho . . . . . . . . . . . . . . . . . . 34
8. Jerarquia de actores . . . . . . . . . . . . . . . . . . . . . . . . . 36
9. Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
10. Esquema de estrella . . . . . . . . . . . . . . . . . . . . . . . . . 42
11. Esquema copo de nieve . . . . . . . . . . . . . . . . . . . . . . . . 42
12. Esquema en copo de nieve de la tabla Movimientos . . . . . . . . 43
13. Esquema en copo de nieve de la tabla Paletas . . . . . . . . . . . 44
14. Esquema en copo de nieve de la tabla Cabecera de Pedido de
Compra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
15. Esquema en copo de nieve de la tabla Lineas de Pedidos de Compra 44
16. Esquema en copo de nieve de la tabla Cabecera de Pedido de Venta 45
17. Esquema en copo de nieve de la tabla Lineas de Pedidos de Venta 45
18. Esquema en copo de nieve de la tabla Cabecera Devolución Cliente 46
19. Esquema en copo de nieve de la tabla Lineas Devolución Cliente 46
20. Esquema en copo de nieve de la tabla Cabecera Devolución Pro-
veedor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
21. Esquema en copo de nieve de la tabla Lineas Devolución Proveedor 47
22. Esquema en copo de nieve de la tabla Ordenes de Palet Completo 48
23. Esquema en copo de nieve de la tabla Ordenes de Picking . . . . 48
24. Esquema en copo de nieve de la tabla Lineas de Picking . . . . . 49
25. Esquema en copo de nieve de la tabla Ubicación de Picking . . . 49
26. Esquema en copo de nieve de la tabla Ubicación de Almacenaje . 50
27. Esquema tabla Festivos y pseudocódigo procedimiento almacenado 52
28. Diseño informe paletas caducadas . . . . . . . . . . . . . . . . . . 58
29. Diseño informe pedidos de compra . . . . . . . . . . . . . . . . . 59
30. Diseño informe pedidos de venta . . . . . . . . . . . . . . . . . . 60
31. Diseño informe productividad operarios . . . . . . . . . . . . . . 61
32. Vista esquema DWH desde PL/SQL Developer . . . . . . . . . . 63
33. Transformación de la tabla de dimensiones Artı́culos . . . . . . . 64
34. Transformación de las tablas de dimensiones Área descarga y
Pasillos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
35. Transformación de la tabla de hechos Movimientos . . . . . . . . 65
36. Transformación de la tabla de hechos Paletas . . . . . . . . . . . 66
37. Transformación de las tablas de hechos Pedidos de Compra . . . 67
38. Transformación de las tablas de hechos Pedidos de Venta,Ordenes
de Palet Completo y Picking . . . . . . . . . . . . . . . . . . . . 69
39. Transformación de las tablas de hechos Devoluciones Cliente . . . 71
40. Transformación de las tablas de hechos Devoluciones Proveedor . 72
41. Transformación de las tablas de hechos Ubicación Picking . . . . 73
42. Transformación de las tablas de hechos Ubicación de Almacenaje 73
43. Transformación de las tablas de dimensiones Almacenes . . . . . 74

4
44. Transformación de las tablas de dimensiones Clientes y Provee-
dores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
45. Transformación de la tabla de dimensiones Operarios . . . . . . . 75
46. Transformación de las tablas de dimensiones propietarios . . . . 76
47. Transformación de las tablas de dimensiones tipos movimiento y
pedido . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
48. Transformación de las tablas de dimensiones tipos pedido provee-
dor y paleta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
49. Job para la carga de datos . . . . . . . . . . . . . . . . . . . . . . 77
50. Ejecución del job principal mediante Kitchen . . . . . . . . . . . 78
51. Script ejecución proceso ETL . . . . . . . . . . . . . . . . . . . . 79
52. Fichero Crontab . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
53. Consulta Vista Tiempo . . . . . . . . . . . . . . . . . . . . . . . 80
54. Operaciones sobre un schema . . . . . . . . . . . . . . . . . . . . 81
55. Operaciones sobre jerarquı́a de una dimensión . . . . . . . . . . . 81
56. Operaciones sobre un cubo . . . . . . . . . . . . . . . . . . . . . 82
57. Atributos de una dimensión . . . . . . . . . . . . . . . . . . . . . 82
58. Schema con los cubos y dimensiones compartidas . . . . . . . . . 83
59. Añadir fuente de datos en Report Designer . . . . . . . . . . . . 84
60. Creación de sentencia del informe . . . . . . . . . . . . . . . . . . 84
61. Workspace diseño de informe . . . . . . . . . . . . . . . . . . . . 85
62. Panel de datos en Report Designer . . . . . . . . . . . . . . . . . 86
63. Organización del proyecto en Eclipse . . . . . . . . . . . . . . . . 87
64. Pantalla administración de fuentes de datos . . . . . . . . . . . . 88
65. Asistente creación de conexión a base de datos . . . . . . . . . . 88
66. Asistente publicación cubos OLAP . . . . . . . . . . . . . . . . . 89
67. Fuente de datos cubos OLAP . . . . . . . . . . . . . . . . . . . . 89
68. Clonación del proyecto Pivot4J . . . . . . . . . . . . . . . . . . . 90
69. Vista Menú Crear nuevo . . . . . . . . . . . . . . . . . . . . . . . 90
70. Consulta contra cubo Cabecera Pedido Compra . . . . . . . . . . 91
71. Herramienta para el desarrollo de Plugins . . . . . . . . . . . . . 92
72. Componentes de un cuadro de mando . . . . . . . . . . . . . . . 92
73. Código HTML del popup para aplicar filtros . . . . . . . . . . . . 93
74. Implementación de la función [Link] . . . . . . . . . . . . . . 94
75. Implementación de la función [Link] . . . . . . . . . . 94
76. Implementación de la función [Link] . . . . . . . . . . 95
77. Popup selector de filtros . . . . . . . . . . . . . . . . . . . . . . . 95
78. Opciones sobre conexión en la herramienta PME . . . . . . . . . 96
79. Busqueda de tablas a importar en la herramienta PME . . . . . 97
80. Modificación de tabla ARTICULOS en la herramienta PME . . . 97
81. Asistente para la definición de relaciones entre tablas . . . . . . . 98
82. Asistente publicación dominio de metadatos . . . . . . . . . . . . 99
83. Fuente de datos dominio de metadatos . . . . . . . . . . . . . . . 99
84. Ejemplo de consulta sobre pedidos de compra . . . . . . . . . . . 99
85. Asistente publicación de informe . . . . . . . . . . . . . . . . . . 100
86. Selección ruta para publicación de informe . . . . . . . . . . . . . 100
87. Búsqueda informes en la aplicación web . . . . . . . . . . . . . . 101
88. Ejemplo informe paletas caducadas . . . . . . . . . . . . . . . . . 101
89. Subida de la aplicación web al servidor . . . . . . . . . . . . . . . 102
90. Comprobación subida de la aplicación web al servidor . . . . . . 102

5
91. Configuración puerto de la aplicación web Pentaho . . . . . . . . 103
92. Pantalla login aplicación web Pentaho . . . . . . . . . . . . . . . 103
93. Resultado pruebas unitarias primera carga de datos . . . . . . . 105
94. Resultado pruebas unitarias carga de datos incremental . . . . . 105
95. Resultado medidas cubo movimientos mediante consulta SQL . . 106
96. Resultado medidas cubo movimientos mediante consulta MDX . 106
97. Resultado consulta ad-hoc pedidos de compra . . . . . . . . . . 113
98. Resultado consulta SQL pedidos de compra . . . . . . . . . . . . 114
99. Resultado consulta ad-hoc pedidos de venta . . . . . . . . . . . 114
100. Resultado consulta SQL pedidos de venta . . . . . . . . . . . . . 115
101. Resultado consulta ad-hoc maestros . . . . . . . . . . . . . . . . 115
102. Resultado consulta SQL maestros . . . . . . . . . . . . . . . . . 115
103. Resultado consulta ad-hoc control . . . . . . . . . . . . . . . . . 116
104. Resultado consulta SQL control . . . . . . . . . . . . . . . . . . 116
105. Gráfica comparación horas estimadas y reales . . . . . . . . . . . 117
106. Diagrama metadato de compras . . . . . . . . . . . . . . . . . . . 143
107. Diagrama metadato de ventas . . . . . . . . . . . . . . . . . . . . 144
108. Diagrama metadato de maestros . . . . . . . . . . . . . . . . . . 146
109. Diagrama metadato de control . . . . . . . . . . . . . . . . . . . 147
110. Diagrama de clases JUnits proceso ETL . . . . . . . . . . . . . . 149
111. Estructura proyecto JUnits del proceso ETL . . . . . . . . . . . . 152
112. Pantalla de login de la aplicación web . . . . . . . . . . . . . . . 153
113. Mensaje de carga de la consola de usuario . . . . . . . . . . . . . 153
114. Interfaz consola de usuario . . . . . . . . . . . . . . . . . . . . . . 154
115. Pestaña de navegación entre perspectivas . . . . . . . . . . . . . 154
116. Desplegable Crear Nuevo . . . . . . . . . . . . . . . . . . . . . . 155
117. Interfaz menú ficheros con acciones sobre carpeta . . . . . . . . . 156
118. Interfaz menú ficheros con acciones sobre fichero . . . . . . . . . 157
119. Interfaz menú programaciones . . . . . . . . . . . . . . . . . . . . 158
120. Popup asistente configuración de tiempo de interrupción . . . . . 158
121. Interfaz opciones menú administración . . . . . . . . . . . . . . . 159
122. Interfaz gestión usuarios y roles del menú administración . . . . 159
123. Interfaz gestión servidor correo del menú administración . . . . . 160
124. Interfaz configuración en menú administración . . . . . . . . . . 160
125. Interfaz pantalla consultas ad-hoc . . . . . . . . . . . . . . . . . . 161
126. Diseño de consultas ad-hoc . . . . . . . . . . . . . . . . . . . . . 162
127. Resultado de consulta ad-hoc . . . . . . . . . . . . . . . . . . . . 162
128. Popup selección de filtros sobre un campo . . . . . . . . . . . . . 163
129. Filtros aplicados en una consulta ad-hoc . . . . . . . . . . . . . . 163
130. Pantalla selección de cubo OLAP . . . . . . . . . . . . . . . . . . 164
131. Pantalla visor OLAP . . . . . . . . . . . . . . . . . . . . . . . . . 164
132. Ejemplo de consulta con el visor OLAP . . . . . . . . . . . . . . 165
133. Configuración parámetros de informe predefinido . . . . . . . . . 166
134. Valores tipo de salida de informe predefinido . . . . . . . . . . . 166
135. Ejemplo de informe predefinido . . . . . . . . . . . . . . . . . . . 167

6
Índice de tablas
1. Plantilla Definición Paquetes de Trabajo . . . . . . . . . . . . . . 16
2. Tarea Definición de Objetivos y Alcance del proyecto . . . . . . . 16
3. Tarea Planificación Temporal del proyecto . . . . . . . . . . . . . 16
4. Tarea Gestión de Riesgos . . . . . . . . . . . . . . . . . . . . . . 17
5. Tarea Planificación Económica . . . . . . . . . . . . . . . . . . . 17
6. Tarea Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Tarea Aprender conceptos básicos de Business Intelligence . . . . 18
8. Tarea Aprender funcionamiento de la plataforma Pentaho . . . . 18
9. Tarea Aprender funcionamiento de la plataforma Pentaho . . . . 18
10. Tarea Identificación de funcionalidades . . . . . . . . . . . . . . . 19
11. Tarea Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12. Tarea Diseño del Datawarehouse . . . . . . . . . . . . . . . . . . 19
13. Tarea Diseño de los cubos OLAP . . . . . . . . . . . . . . . . . . 20
14. Tarea Diseño de informes . . . . . . . . . . . . . . . . . . . . . . 20
15. Tarea Implementación e integración del Datawarehouse . . . . . 20
16. Tarea Implementación de cubos OLAP y visor . . . . . . . . . . 21
17. Implementación e integración del Datawarehouse . . . . . . . . . 21
18. Tarea Despliegue del servidor web . . . . . . . . . . . . . . . . . 21
19. Tarea Despliegue del servidor web . . . . . . . . . . . . . . . . . 22
20. Tarea Realización de la memoria . . . . . . . . . . . . . . . . . . 22
21. Tarea Pruebas de implementación . . . . . . . . . . . . . . . . . . 22
22. Riesgo Perdida del proyecto . . . . . . . . . . . . . . . . . . . . . 24
23. Retraso en el desarrollo del proyecto . . . . . . . . . . . . . . . . 24
24. Riesgo Desarrollo diferente al pedido . . . . . . . . . . . . . . . . 24
25. Riesgo Mala planificación temporal . . . . . . . . . . . . . . . . . 25
26. Riesgo Ordenador defectuoso . . . . . . . . . . . . . . . . . . . . 25
27. Riesgo Problemas en la implementación . . . . . . . . . . . . . . 25
28. Diseño inadecuado . . . . . . . . . . . . . . . . . . . . . . . . . . 26
29. Problemas en reunión con el cliente . . . . . . . . . . . . . . . . . 26
30. Gastos en personal . . . . . . . . . . . . . . . . . . . . . . . . . . 27
31. Gastos en personal . . . . . . . . . . . . . . . . . . . . . . . . . . 27
32. Gastos software . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
33. Gastos indirectos . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
34. Gastos totales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
35. Comparativa entre Datawarehouse y base de datos operacional
[6] [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
36. Comparativa entre herramientas de BI [13] [14] [15] [16] [17] [18] 33
37. Estructura Vista Dimensión Tiempo . . . . . . . . . . . . . . . . 52
38. Resultado pruebas medidas del cubo movimientos . . . . . . . . . 107
39. Resultado pruebas medidas del cubo paletas . . . . . . . . . . . . 107
40. Resultado pruebas medidas del cubo cabecera pedido de compra 108
41. Resultado pruebas medidas del cubo lineas pedido de compra . . 108
42. Resultado pruebas medidas del cubo cabecera pedido de venta . 109
43. Resultado pruebas medidas del cubo lı́neas pedido de venta . . . 109
44. Resultado pruebas medidas del cubo cabecera devolución clien-
te/proveedor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
45. Resultado pruebas medidas del cubo lı́neas devolución cliente . . 110

7
46. Resultado pruebas medidas del cubo lı́neas devolución proveedor 111
47. Resultado pruebas medidas del cubo ordenes de paleta completa 111
48. Resultado pruebas medidas del cubo ordenes de picking . . . . . 112
49. Resultado pruebas medidas del cubo lı́neas de picking . . . . . . 112
50. Resultado pruebas medidas cubos ubicación de picking y alma-
cenaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
51. Comparación horas estimadas y reales . . . . . . . . . . . . . . . 118
52. Caso de Uso: Iniciar Sesión . . . . . . . . . . . . . . . . . . . . . 124
53. Caso de Uso: Programar Tareas . . . . . . . . . . . . . . . . . . . 126
54. Caso de Uso: Realizar consulta . . . . . . . . . . . . . . . . . . . 127
55. Caso de Uso: Crear cuadro de mando . . . . . . . . . . . . . . . . 128
56. Caso de Uso: Visualizar cubos OLAP . . . . . . . . . . . . . . . . 129
57. Caso de Uso: Abrir cuadros de mando . . . . . . . . . . . . . . . 130
58. Caso de Uso: Abrir informes . . . . . . . . . . . . . . . . . . . . . 132
59. Caso de Uso: Administrar fuentes de datos . . . . . . . . . . . . 133
60. Caso de Uso: Administrar usuarios . . . . . . . . . . . . . . . . . 134
61. Caso de Uso: Administrar Roles de usuario . . . . . . . . . . . . 136
62. Caso de Uso: Crear cubo OLAP . . . . . . . . . . . . . . . . . . . 137
63. Caso de Uso: Desplegar cubo OLAP . . . . . . . . . . . . . . . . 138
64. Caso de Uso: Definir transformaciones . . . . . . . . . . . . . . . 139
65. Caso de Uso: Definir jobs . . . . . . . . . . . . . . . . . . . . . . 140
66. Caso de Uso: Diseñar informe . . . . . . . . . . . . . . . . . . . . 141
67. Caso de Uso: Publicar informe . . . . . . . . . . . . . . . . . . . 142
68. Relaciones metadato de compras . . . . . . . . . . . . . . . . . . 144
69. Relaciones metadato de ventas . . . . . . . . . . . . . . . . . . . 145
70. Relaciones metadato de maestros . . . . . . . . . . . . . . . . . . 146
71. Relaciones metadato de control . . . . . . . . . . . . . . . . . . . 148

8
2. Introducción
2.1. Descripción del Proyecto
El proyecto que se desarrolla consiste en crear, desarrollar y desplegar una
aplicación de Business Intelligence (BI) para la empresa InLOG Consultorı́a y
Soluciones, con el objetivo de poder aportar a las empresas clientes de InLOG
una visión del estado actual de su negocio, y poder generar información útil
para tomas de decisiones en el futuro. Para el desarrollo se aplicarán distintas
herramientas de Business Intelligence de código abierto de la plataforma Pen-
taho.

Para lograr este objetivo, es necesario, por un lado generar un almacén de

datos, el cual contendrá datos previamente tratados de los distintos sistemas de
gestión que los clientes poseen, entre ellos el sistema InLOG WMS, un sistema
de gestión de almacenes propio de la empresa, siendo este el sistema de infor-
mación preferente a la hora de tratar los datos al ser el propio de la empresa, y
al ser el BI un producto que se ofrecerá junto al sistema.

Una vez generado el almacén de datos, se procederá a explotar los datos de

la siguiente manera:
Generar informes predefinidos parametrizables sobre distintos datos útiles
para el usuario.
Ofrecer la posibilidad de realizar informes-adhoc con los datos obtenidos
en el almacén de datos, con el objetivo de que el cliente pueda realizar
consultas de una forma sencilla sin conocer la estructura del almacén de
datos.
Desarrollo de cubos OLAP e integración de un visor para poder realizar
consultas de una forma sencilla y óptima utilizando las posibilidades de
los cubos generados.

Integración del servidor web proporcionado por Pentaho, para ofrecer al

cliente una forma sencilla de acceder a todas las caracterı́sticas implemen-
tadas.
Para el desarrollo, se aplicara todos los conocimientos adquiridos durante
el recorrido académico. Como sistema de gestión de base de datos se utilizará
Oracle, al ser el sistema con el que trabaja InLOG WMS, y estar familiarizado
con el desarrollo en ese entorno. Se realizará una formación sobre Pentaho, al
desconocer su funcionamiento.

2.2. Motivación
Hoy en dı́a, muchas de las empresas clientes de InLOG WMS, solicitan la
posibilidad de explotar los datos generados por el sistema utilizando un Busi-
ness Intelligence, al ser una buena oportunidad para explotar los múltiples datos
generados por el sistema de gestión de almacenes.

9
 Esto ha provocado el interés en la empresa por implementar una solución
de Business Intelligence para ofrecer a los clientes, y además, atraer a nuevos
clientes.

2.3. Definiciones
Se van a definir algunos conceptos que se utilizarán a lo largo del proyecto,
para facilitar la lectura de este:

ERP:Enterprise Resource Planning, son programas para gestionar distin-

tas operaciones de una empresa.
WMS:Warehouse Management System, es un programa para gestionar
almacenes.

Datawarehouse: Sistema para almacenar datos que se pueden analizar

para toma de decisiones mediante herramientas de Bussiness Intelligence.
Cubo OLAP: Estructura de datos que proporciona un acceso y análisis
rápido de los datos.
Informe ad-hoc: Permite a los usuarios realizar consultas sobre la base
de datos de una forma sencilla

10
3. Planteamiento inicial
3.1. Objetivos
3.1.1. Objetivos del proyecto
A continuación, se definen los siguientes objetivos a lograr con el proyecto,
los cuales serán desarrollados a lo largo de la memoria:
Definición del proceso de extracción y transformación de los datos proce-
dentes del WMS, ERP y sistema de recursos humanos.
Desarrollo del Datawarehouse en Oracle
Integración del Datawarehouse con el servidor web de Pentaho
Desarrollo de informes predefinidos parametrizables
Integración de informes ad-hoc en el servidor web de Pentaho
Desarrollo de cubos OLAP e integración de un visor para dichos cubos en
el servidor web de Pentaho
Despliegue del servidor web de Pentaho

3.1.2. Objetivos personales

En este proyecto, se pondrán en practica todos los conocimientos adquiridos
durante el recorrido académico, lo cual es una buena oportunidad para reforzar
estos conocimientos con un proyecto real en una empresa.

Además, la posibilidad de aprender a implementar una solución de Bussiness

Intelligence con Pentaho es una gran oportunidad para entrar en un ámbito que
cada vez mas empresas están interesadas, lo cual es muy útil para mi futuro
profesional.

3.2. Marco del proyecto

InLOG Consultorı́a y Soluciones es una empresa de desarrollo de software,
cuya principal actividad consiste en el diseño e implementación de soluciones en
la industria, retail, transporte y sectores de servicios.

Figura 1: Logotipo InLOG Consultorı́a y Soluciones

Posee un software propio para la gestión de almacenes llamado InLOG WMS,

el cual permite automatizar la gestión de las operaciones del almacen, gestio-
nar de forma inteligente las prioridades, optimizar recorridos, reducir los errores
operativos... logrando ası́ aumentar y optimizar la productividad de los almace-
nes en los que se implanta el software.

11
 Este software, al ser el propietario de la empresa, y generar una gran fuente
de datos sobre todo lo relacionado con el almacén, será la principal fuente de
extracción de datos para la implementación de este proyecto.

3.3. Alcance
3.3.1. Fases
El proyecto será dividido en diferentes fases, las cuales a su vez contaran con
un listado de tareas a realizar, mostradas más adelante mediante un diagrama
EDT (estructura de desglose del trabajo). Las fases son las siguientes:
Planificación y Gestión Inicial: Fase inicial del proyecto, donde se definirán
los objetivos del proyecto, las tareas necesarias para llevarlo a cabo y
una planificación temporal estimada del proyecto, mediante el uso del
diagramas EDT y Gantt.
Formación: Fase donde se adquirirán los conocimientos necesarios para
desarrollar el proyecto.
Captura de Requisitos: Fase donde se definirán las distintas funcionalida-
des a implementar realizando reuniones con la empresa.
Análisis y Diseño: Fase donde se identificaran las diferentes herramien-
tas para implementar las funcionalidades, y se realizara el diseño de las
funcionalidades.

Implementación e Integración: Fase donde se desarrollaran e integraran en

la plataforma las distintas funcionalidades definidas.
Despliegue: Fase donde se instalara y verificará que la aplicación funcione
correctamente y se adecue a las necesidades establecidas por la empresa
Documentación: Fase donde se realizará la documentación correspondien-
te. Esta fase se realizara a lo largo de todo el proyecto.

3.3.2. Ciclo de Vida

Para la realización del proyecto se ha empleado un ciclo de vida clasico
llamado ciclo de vida en cascada. En este, se ejecuta cada fase una tras otra
de forma lineal, no pudiendo empezar con la segunda fase hasta no terminar la
primera, y ası́ sucesivamente. En caso de encontrar algún fallo, es posible volver
a una fase anterior para corregirlo.

12
 Figura 2: Ciclo de vida

3.4. Herramientas
Las herramientas hardware y software a emplear son las siguientes:

3.4.1. Hardware
Ordenador portatil con Windows 10

3.4.2. Software
Pentaho BI Suite Community Edition: Conjunto de software libre para
generar Business Intelligence. Se utilizarán los siguientes programas:
ˆ BI Server 7.0: Aplicación web desarrollada en Java2EE en la que
podremos gestionar todas las funcionalidades como informes y vista
OLAP implementadas de Pentaho creando un cuadro de mando
ˆ Pentaho Data Integration (PDI): Aplicación para transformar datos
desde diferentes fuentes y unificarlos en datawarehouse
ˆ Pentaho Report Designer: Aplicación para diseñar informes
ˆ Pentaho Schema Workbench: Aplicación para diseñar cubos OLAP
ˆ Pentaho Metadata Editor: Aplicación para definir los metadatos del
Datawarehouse
Texmaker: Editor de textos multiplataforma de código abierto para desa-
rrollar documentos con LaTeX, con el cual se desarrollará la memoria del
proyecto

13
GanttProject: Software de código abierto empleado para la gestión de
proyectos usando el diagrama de Gantt.

PL/SQL Developer: Software para administrar bases de datos de Oracle.

PuTTY: Software de código abierto para poder usar el protocolo SSH.
Google Drive: Servicio de alojamiento de archivos en la nube.
Google Drawings: Software para realizar diagramas, con el cual se reali-
zarán las figuras de la memoria.
Microsoft 365: Conjunto de software ofimatico. Se utilizarán los siguientes
programas:
ˆ Microsoft Access: Software de gestión de base de datos
ˆ Microsoft PowerPoint: Software para realizar presentaciones

Visual Paradigm: Herramienta para modelado UML, con el cual se repre-

sentaran los casos de uso del sistema.
TortoiseGit: Software cliente para el control de versiones Git de código
abierto.

Eclipse IDE for Enterprise Java and Web Developers: Plataforma de código
abierto para el desarrollo de aplicaciones Java EE y web.

14
3.5. Planificación Temporal
3.5.1. EDT
A continuación se muestra el diagrama EDT con el desglose del trabajo:

Figura 3: EDT

15
3.5.2. Listado de Tareas
A continuación se van a definir el listado de tareas de los cuales están com-
puesta cada fase. Para ello, utilizaremos como plantilla la siguiente tabla:

NOMBRE TAREA
Descripción Breve explicación de la tarea.
Esfuerzo Duración estimada en horas de la tarea.
Listado con las herramientas a utilizar
Recursos necesarios
en la tarea.
Listado de tareas que deben estar com-
Precedente
pletadas para poder comenzar.
Explicación de los hitos obtenidos con
Salidas:
la tarea.

Tabla 1: Plantilla Definición Paquetes de Trabajo

Teniendo en cuenta las tareas definidas en el EDT:

1. Planificación y Gestión Inicial

Definición de Objetivos y Alcance del proyecto

Fijar los objetivos a lograr con el pro-
Descripción
yecto y establecer el alcance de este.
Esfuerzo 16 horas.
Recursos necesarios Texmaker.
Precedente -
Objetivos del proyecto y Alcance del
Salidas:
proyecto.

Tabla 2: Tarea Definición de Objetivos y Alcance del proyecto

Planificación Temporal del proyecto

Identificar fases y tareas del proyecto, y
Descripción estar el tiempo a emplear para realizar
cada una de ella.
Esfuerzo 6 horas.
Recursos necesarios Texmaker y GanttProject.
Definición de Objetivos y Alcance del
Precedente
proyecto.
Diagrama EDT y listado de tareas jun-
Salidas: to con el tiempo estimado y fechas
máximas de inicio y fin.

Tabla 3: Tarea Planificación Temporal del proyecto

16
 Gestión de Riesgos
Identificar aquellos riesgos que pueden
Descripción ocurrir a lo largo del desarrollo del pro-
yecto.
Esfuerzo 3 horas.
Recursos necesarios Texmaker.
Definición de Objetivos y Alcance del
Precedente
proyecto.
Salidas: Gestión de riesgos.

Tabla 4: Tarea Gestión de Riesgos

Planificación Económica
Estimación de costes y beneficios que
Descripción
supone el desarrollo del proyecto.
Esfuerzo 3 horas.
Recursos necesarios Texmaker.
Definición de Objetivos y Alcance del
Precedente
proyecto.
Salidas: Planificación Económica.

Tabla 5: Tarea Planificación Económica

Estudio de Antecedentes
Análisis de la situación antes de realizar
Descripción
el proyecto y técnicas para realizarlo.
Esfuerzo 14 horas.
Recursos necesarios Internet y Texmaker.
Definición de Objetivos y Alcance del
Precedente
proyecto.
Salidas: Antecedentes.

Tabla 6: Tarea Antecedentes

17
2. Formación

Aprender conceptos básicos de Business Intelligence

Adquirir conocimientos y conocer las
Descripción herramientas que se utilizan en los pro-
yectos de Business Intelligence.
Esfuerzo 14 horas.
Recursos necesarios Internet
Precedente Estudio de Antecedentes.
Salidas: -

Tabla 7: Tarea Aprender conceptos básicos de Business Intelligence

Aprender funcionamiento de la plataforma Pentaho

Conocer el funcionamiento de las herra-
Descripción
mientas de la suite de Pentaho.
Esfuerzo 28 horas.
Recursos necesarios Internet
Aprender conceptos básicos de Business
Precedente
Intelligence.
Salidas: -

Tabla 8: Tarea Aprender funcionamiento de la plataforma Pentaho

Aprender LaTeX
Aprender el uso de LaTeX para poder
Descripción
realizar la memoria del proyecto.
Esfuerzo 10 horas.
Recursos necesarios Internet
Precedente -
Salidas: -

Tabla 9: Tarea Aprender funcionamiento de la plataforma Pentaho

18
3. Captura de Requisitos

Identificación de funcionalidades
Identificación de las funcionalidades a
Descripción
implementar.
Esfuerzo 10 horas.
Recursos necesarios Texmaker.
Precedente Formación.
Salidas: Listado con las funcionalidades

Tabla 10: Tarea Identificación de funcionalidades

Casos de Uso
Descripción Definir los casos de uso.
Esfuerzo 40 horas.
Recursos necesarios Visual Paradigm.
Precedente Identificación de funcionalidades.
Salidas: Casos de Uso

Tabla 11: Tarea Casos de Uso

4. Análisis y Diseño

Diseño del Datawarehouse

Diseño del proceso de extracción, trans-
formación de datos, estructura de las
Descripción
tablas del Datawarehouse y carga de
datos.
Esfuerzo 40 horas.
Recursos necesarios Texmaker y Pentaho Data Integration.
Precedente Captura de Requisitos.
Salidas: Diagramas y tablas de base de datos

Tabla 12: Tarea Diseño del Datawarehouse

19
 Diseño de los cubos OLAP
Descripción Diseño de la estructura de los cubos.
Esfuerzo 30 horas.
Recursos necesarios Google Drawing.
Precedente Diseño del Datawarehouse.
Salidas: Diagramas de cubos

Tabla 13: Tarea Diseño de los cubos OLAP

Diseño de informes
Descripción Diseño de informes parametrizables.
Esfuerzo 28 horas.
Recursos necesarios Pentaho Report Designer.
Precedente Diseño del Datawarehouse.
Salidas: Informes parametrizables

Tabla 14: Tarea Diseño de informes

5. Implementación e Integración

Implementación e integración del Datawarehouse

Implementación del datawarehouse en
Oracle, implementación del proceso
Descripción
ETL e integración con el servidor web
de Pentaho
Esfuerzo 15 horas.
Pentaho Data Integration, Oracle
Recursos necesarios
PLSQL y BI Server 7.0
Precedente Análisis y Diseño.
Salidas: Datawarehouse

Tabla 15: Tarea Implementación e integración del Datawarehouse

20
 Implementación de cubos OLAP y visor
Descripción Implementación de los cubos OLAP
Esfuerzo 10 horas.
Pentaho Schema Workbench y BI Ser-
Recursos necesarios
ver 7.0
Implementación e integración del Data-
Precedente
warehouse.
Salidas: Cubos y visor OLAP

Tabla 16: Tarea Implementación de cubos OLAP y visor

Integración de informes ad- hoc

Instalación, modificación de plugins e integración
Descripción de los datos para poder realizar informes ad-hoc
desde el servidor web
Esfuerzo 8 horas.
Recursos necesarios BI Server 7.0
Precedente Implementación e integración del Datawarehouse.
Salidas: Informes ad-hoc desde el servidor web

Tabla 17: Implementación e integración del Datawarehouse

6. Despliegue

Despliegue del servidor web

Despliegue del servidor web de Pentaho para po-
Descripción der ser utilizado y publicación de informes prede-
finidos.
Esfuerzo 15 horas.
Recursos necesarios BI Server 7.0
Precedente Implementación e integración.
Salidas: Servidor Web Pentaho

Tabla 18: Tarea Despliegue del servidor web

21
 Pruebas de implementación
Prueba del correcto funcionamiento de
Descripción
las funcionalidades implementadas
Esfuerzo 20 horas.
Recursos necesarios BI Server 7.0
Precedente Despliegue del servidor web.
Salidas: -

Tabla 19: Tarea Despliegue del servidor web

7. Documentación

Realización de la memoria
Descripción Realizar la memoria del proyecto
Esfuerzo 80 horas.
Recursos necesarios Texmaker
Precedente Aprender LaTeX
Salidas: Memoria del proyecto

Tabla 20: Tarea Realización de la memoria

Preparación de la defensa
Realizar la presentación para la defensa
Descripción
del proyecto
Esfuerzo 10 horas.
Recursos necesarios Microsoft PowerPoint
Precedente Realización de la memoria
Salidas: Presentación de la defensa

Tabla 21: Tarea Pruebas de implementación

3.5.3. Gantt
Para gestionar las fechas en las que tienen que completar las tareas defi-
nidas anteriormente se utilizará el diagrama Gantt. Se ha estimado que para
la realización del proyecto se empleara aproximadamente 15 horas semanales,
trabajando en el proyecto 3 horas al dı́a de lunes a viernes. En caso de no ser
suficiente, se aumentará la cantidad de horas semanales trabajando los fines de
semana en el proyecto.

Se han tenido en cuenta un periodo de vacaciones por navidad entre el

22/12/2020 y 6/12/2021, y vacaciones por semana santa entre el 28/03/2021
y 4/04/2021.

22
Figura 4: Diagrama Gantt

23
3.6. Gestión de Riesgos
A la hora de definir un proyecto es importante tener en cuenta los distintos
riesgos que pueden surgir a lo largo del proyecto, los cuales si no los tenemos en
cuenta pueden afectar a la planificación temporal.
Cada riesgo se expondrá de la siguiente manera: una breve descripción del riesgo,
medidas que se emplearan para prevenir el riesgo, plan de contingencia a aplicar
en caso de que el riesgo ocurra, la probabilidad de que ocurra y el impacto que
puede suponer en el proyecto. Estas dos últimas medidas se medirán en cinco
rasgos: muy bajo, bajo, medio, alto y muy alto.

Riesgo: Perdida del proyecto

Se pierden los datos del proyecto por
Descripción algún fallo en el disco duro del ordena-
dor
Realizar copias de seguridad periódica-
Medidas de Prevención mente de todo el proyecto en un servicio
en la nube (Google Drive)
Plan de Contingencia Recuperar la copia de seguridad
Probabilidad Baja
Impacto Muy alto

Tabla 22: Riesgo Perdida del proyecto

Riesgo: Retraso en el desarrollo del proyecto

Debido a una enfermedad, confinamien-
Descripción to o motivos familiares se produce un
retraso en el desarrollo del proyecto
Tener en cuenta un margen de tiempo
Medidas de Prevención por motivos personales en la planifica-
ción temporal
Plan de Contingencia Realizar horas extra
Probabilidad Media
Impacto En función del tiempo perdido

Tabla 23: Retraso en el desarrollo del proyecto

Riesgo: Desarrollo diferente al pedido

El desarrollo realizado es diferente al
Descripción
que la empresa esperaba
Realizar reuniones periódicas mostran-
Medidas de Prevención
do los avances del proyecto
Realizar una reunión para aclarar las
Plan de Contingencia diferencias con lo esperado e invertir
tiempo extra para ponerse al dı́a
Probabilidad Baja
Impacto Muy alto

Tabla 24: Riesgo Desarrollo diferente al pedido

24
 Riesgo: Mala planificación temporal
Se tarda mas tiempo en realizar una ta-
Descripción
rea del estimado
Tener en cuenta un margen de tiempo
Medidas de Prevención
en la planificación temporal
Plan de Contingencia Realizar horas extra
Probabilidad Media
Impacto En función del tiempo perdido

Tabla 25: Riesgo Mala planificación temporal

Riesgo: Ordenador defectuoso

Se estropea el ordenador con el que se
Descripción
está desarrollando el proyecto
Tener un ordenador alternativo dispo-
Medidas de Prevención
nible
Continuar el desarrollo desde el otro or-
Plan de Contingencia
denador
Probabilidad Baja
Impacto Alto

Tabla 26: Riesgo Ordenador defectuoso

Riesgo: Problemas en la implementación

A la hora de implementar una determi-
Descripción nada parte se encuentran problemas de
los que no se conoce la solución
Medidas de Prevención -
Plan de Contingencia Buscar la solución en internet
Probabilidad Alta
Impacto Medio

Tabla 27: Riesgo Problemas en la implementación

25
 Riesgo: Diseño inadecuado
El diseño realizado es insuficiente para
Descripción
implementar el proyecto
Realizar la captura de requisitos de la
Medidas de Prevención mejor manera posible para poder reali-
zar el diseño mas ajustado posible
Volver a realizar el diseño en horas ex-
Plan de Contingencia
tra
Probabilidad Baja
Impacto Alto

Tabla 28: Diseño inadecuado

Riesgo: Problemas en reunión con el cliente
Debido al trabajo no se pueda realizar
Descripción la reunión con el cliente y esta es can-
celada
Medidas de Prevención -
Continuar desarrollando otro apartado
Plan de Contingencia
evitando paralizar el proyecto
Probabilidad Media
Impacto Alto

Tabla 29: Problemas en reunión con el cliente

26
3.7. Planificación Económica
En este apartado se va a hacer un cálculo de los gastos y beneficios que
otorgará el proyecto, para poder ası́ analizar su viabilidad.

3.7.1. Gastos
Tenemos los siguientes gastos:
a. Gasto en personal: Al ser un proyecto realizado aprovechando la beca en
la empresa, se ha estimado que un becario trabajando 3h al dı́a cobra
aproximadamente 330¿ al mes.

Coste mensual Meses trabajados Total

Becario 330¿ 6 meses 1980¿
Gasto total 1980¿

Tabla 30: Gastos en personal

b. Gasto en hardware: Para realizar el proyecto se ha utilizado un ordenador

portátil Asus valorado aproximadamente en 650¿, y puntualmente un
ordenador sobremesa personal valorado en aproximadamente 1000¿.

Precio Vida media Tiempo de uso Amortización

Ordenador portatil 650¿ 5 años 6 meses 64,99¿
Ordenador sobre-
1000¿ 6 años 1 mes 13,88¿
mesa
Gasto total 78,87¿

Tabla 31: Gastos en personal

c. Gasto en software: Para realizar el proyecto, la mayorı́a del software uti-

lizado es gratuito, excepto Microsoft Access, el cual está incluido en el
Microsoft Office, el cual tiene un coste de 7¿ al mes.

Coste mes Meses trabajados Total

Microsoft 365 Per-
7¿/mes 6 meses 63¿
sonal
Gasto total 63¿

Tabla 32: Gastos software

d. Gastos indirectos: Son gastos que no tienen influencia directa en el desa-

rrollo del proyecto, pero que son esenciales para poder realizarlo, como los
gastos de luz e Internet.

27
 En este caso, al ser un trabajo que se realizará en su mayor medida en la
oficina de la empresa, no tendremos en cuenta los gastos de Internet, al
ser un gasto independiente de la realización de este proyecto.

Coste mes Meses trabajados Total

Luz 10¿/mes 6 meses 60¿
Gasto total 60¿

Tabla 33: Gastos indirectos

e. Gasto total: Agrupando todos los costes, los costes totales en el proyecto
quedan de la siguiente manera:

Gasto
Personal 1980¿
Hardware 78,87¿
Software 63¿
Indirectos 60¿
Total 2181,87 ¿
Tabla 34: Gastos totales

3.7.2. Beneficios
En cuanto a los beneficios que puede otorgar el desarrollo del proyecto, este
es un producto que se espera ofrecer integrado junto al sistema actual de gestión
de almacenes InLOG WMS, y no se va a ofrecer como servicio independiente,
sino que irá integrado en las nuevas versiones del sistema para aumentar la com-
petitividad de este producto en el mercado.

Con el desarrollo del proyecto se espera aumentar el abanico funcional del

producto, logrando una expansión del sistema. Como los indicadores de cada
empresa cliente de InLOG WMS son diferentes, al contar cada cliente con una
versión personalizada de este adaptada a sus necesidades, se abre la posibilidad
de realizar nuevos proyectos para adaptar el producto a cada cliente.

Además, desde el punto de vista comercial, con la expansión del sistema

aumenta la posibilidad de venta de este, al ser una opción mas llamativa para
posibles nuevos clientes, y por tanto podemos considerarlo como un proyecto
generador de nuevas oportunidades.

Con lo cual, se espera recuperar la inversión realizada con los nuevos pro-
yectos tanto de adaptación como de posibles nuevos clientes que se puedan
concretar a partir de la implantación de este producto en las nuevas versiones
del sistema.

28
4. Antecedentes
4.1. Situación actual
Actualmente, los clientes de InLOG WMS no disponen de ningún Datawa-
rehouse que unifique los datos de sus diferentes sistemas. Las únicas conexiones
que existen entre los sistemas ERP y WMS es mediante procedimientos de carga
de datos implementados en InLOG WMS para la carga de pedidos, devolucio-
nes... procedentes del ERP utilizando ficheros con una estructura concreta.

Lo máximo que actualmente el cliente puede hacer es imprimir los informes

ya establecidos en la aplicación y hacer consultas contra la base de datos ope-
rativa mediante ODBC, perjudicando al rendimiento del sistema de gestión de
almacenes en caso de hacer consultas muy pesadas, al realizar las operaciones
contra la misma base de datos.

Al implementar un Datawarehouse, no solo lograremos que el cliente pueda

realizar consultas e informes de datos procedentes de distintos sistemas de una
manera sencilla, sino que al separar la base de datos operativa del Datawarehou-
se, el cliente podrá realizar consultas muy pesadas sin ralentizar el sistema.

4.2. Definición de Business Intelligence

Se define Business Intelligence como el conjunto de estrategias que realizan
el análisis de los datos de una empresa para poder comprender el funcionamien-
to de los distintos procesos de la empresa y en base a esto, poder obtener los
conocimientos suficientes para facilitar la toma de decisiones, acciones a tomar
y lograr un incremento en el rendimiento y competitividad de la empresa. [1]

Para ello, las herramientas de business intelligence utilizan datos extraı́dos

de los distintos sistemas de información que la empresa posee, generalmente .
Estos datos son transformados mediante el proceso conocido como ETL (Ex-
traer, Transformar y Cargar) para que puedan generar información útil para la
toma de decisiones. [1]

El proceso de ETL consiste en obtener datos de múltiples fuentes, transfor-

marlos y centralizarlos en un único repositorio, normalmente en un almacén de
datos o Datawarehouse: [2]
1. Proceso de extracción: Se extraen los datos en bruto de fuentes diversas
2. Proceso de transformación: Se modifican los datos en bruto mediante una
serie de normas para garantizar datos de calidad y prepararlos para poder
utilizarlos
3. Proceso de carga: Se cargan los datos extraı́dos y transformados en el
nuevo destino.

29
 Figura 5: Proceso ETL

Una vez integrados los datos, se procede a trabajar sobre estos datos utili-
zando herramientas propias de la tecnologı́a Business Intelligence mediante la
creación de cuadros de mando, gráficos, indicadores e informes. Estas herra-
mientas permitirán al usuario explorar los datos de una forma sencilla. [3]

Con la implementación de un Business Intelligence podemos destacar los

siguientes beneficios: [4]
Proporciona herramientas de análisis para la toma de decisiones
Los usuarios pueden realizar consultas contra sus datos de una manera
sencilla
Reduce el tiempo necesario para realizar consultas contra datos proceden-
tes de diferentes sistemas al estar estos unificados en una misma base de
datos
Posibilita realizar consultas pesadas sin ralentizar los sistemas de la em-
presa al ser una base de datos aislada al sistema
Se pueden identificar aquellos factores que inciden en el funcionamiento
de la empresa

4.3. Componentes de un Business Intelligence

4.3.1. Datawarehouse
Un Datawarehouse, traducido literalmente como “almacén de datos“ es una
base de datos que se caracteriza por ser: [5]

Integrado: Datos de una o múltiples fuentes distintas en una misma base

de datos.
Organizado por temas: Los datos están clasificados en temas para fa-
cilitar su acceso y entendimiento por parte de los usuarios.

30
 Histórico: Guarda los distintos variables que toma una variable en el
tiempo para poder ver evoluciones, comparaciones y buscar patrones.

No volátil: La información es permanente y solo de lectura.

Otra caracterı́stica interesante de los datawarehouse es que contiene me-
tadatos. Los metadatos son datos que describen y dan contexto otros datos.
Contienen información como por ejemplo la procedencia, estructura de datos,
formato, etc. La gestión de metadatos puede ser de gran ayuda para mejorar la
gestión de los datos, facilitando las búsquedas y análisis de datos. [5] [12]

En la siguiente tabla se puede ver una comparativa entre un Datawarehouse

y una base de datos operacional:

Datawarehouse Base de datos Operacional

Objetivo Análisis de datos Operaciones del dı́a a dı́a
Datos De todo el negocio Relacionada con la aplicación
Valor Importancia de los valores historicos Importancia de los valores actuales
Actividad Consultas grandes y masivas Actualizaciones y pequeñas consultas
Volatilidad Solo carga y lectura Actualizable
Organización Esquema en estrella o copo de nieve Relacional
Rendimiento Importancia a la respuesta masiva Importancia a una respuesta instantánea

Tabla 35: Comparativa entre Datawarehouse y base de datos operacional [6] [7]

Se define como Data Mart al conjunto de datos que representa un único

proceso o área de negocios especifica. Un Datawarehouse puede verse como el
conjunto de los Data Marts de una organización [19]

4.3.2. Cubos OLAP

Un cubo OLAP es una estructura de datos multidimensional, ampliando las
posibilidades y limitaciones que se ofrecı́an en las bases de datos relacionales,
donde los datos son vistos como cubos. Las distintas dimensiones de este cubo
consisten en las diferentes categorı́as en las que interesa estructurar los datos.
Con esta estructura, logramos realizar consultas complejas con gran rapidez, y
poder procesar grandes cantidades de información, los cuales serı́a imposible de
procesar con una base de datos tradicional. [8] [9]

Figura 6: Estructura Cubo OLAP

31
 Para realizar consultas contra los cubos, se utilizan consultas MDX, las cua-
les son unas consultas similares a las utilizadas en el lenguaje SQL, pero adap-
tadas para trabajar con estructuras de datos multidimensionales. [22]

Como principal desventaja es importante destacar la imposibilidad de rea-

lizar cambios en su estructura debido a su forma de almacenamiento de la in-
formación, teniendo que rediseñar el cubo OLAP en caso de querer realizar
modificaciones. [9]

4.3.3. Cuadros de mando

Un cuadro de mando es la herramienta que muestra los indicadores clave de
una forma visual con el objetivo de facilitar la toma de decisiones. Se distinguen
dos tipos de cuadro de mando: [10]
Cuadro de Mando Operativo: Enfocado al control de indicadores per-
tenecientes a los procesos de un área o departamento concreto de la em-
presa. [10] [11]
Cuadro de Mando Integral: Muestra los datos desde cuatro perspec-
tivas diferentes, financiera, cliente interna y aprendizaje/crecimiento. [10]
[11]

4.4. Análisis de Herramientas

Al existir una gran cantidad de herramientas para el desarrollo de proyec-
tos BI es importante realizar un análisis de las distintas herramientas existentes.

El estudio se ha basado principalmente en las herramientas Power BI, Pen-

taho CE, QlikView y SAP Business Intelligence, por ser de las principales he-
rramientas en el mercado:

Power BI: Servicio de Business Intelligence propietario de Microsoft.

Permite realizar los procesos BI de una forma muy visual y simple. [13]

Pentaho CE: Conjunto de programas de Business Intelligence de código

abierto. Ofrece una amplia gama de herramientas para realizar los distintos
procesos, y estás cuenta con complementos de código abierto para distintos
objetivos. [16]
QlikView: Herramienta para visualizar y generar cuadros de mando de
una forma rápida. [14]
SAP Business Intelligence: Herramienta de Business Intelligence de
pago propietaria de SAP. El precio varı́a en función de las necesidades,
siendo necesario establecer contacto con la empresa para estimar el precio.
[15]

En la siguiente tabla se puede ver una comparativa entre las herramientas,

teniendo en cuenta aquellos puntos indispensables para realizar el proyecto.

32
 Power BI Pentaho CE QlikView SAP BI
Procesos ETL SI SI NO SI
Cuadros de mando SI SI SI SI
Informes SI SI SI SI
Cubos OLAP NO SI NO SI
Open Source NO SI NO NO
Precio Gratuito Gratuito Gratuito Pago

Tabla 36: Comparativa entre herramientas de BI [13] [14] [15] [16] [17] [18]

Como se puede ver, entre todas las herramientas analizadas, las únicas con
las que se podrı́a implementar el proyecto son Pentaho CE y SAP Business
Intelligence. Teniendo en cuenta que la herramienta de SAP es de pago, no es
de código abierto, y que con Pentaho podemos implementar prácticamente las
mismas funcionalidades, y al ser código abierto podemos realizar modificaciones
en caso de verlo necesario, la herramienta utilizada para implementar el proyecto
será Pentaho CE. La única diferencia que podemos encontrar entre ellas es
que al ser SAP Business Intelligence una aplicación de pago, el soporte y la
documentación será mucho mayor que el de Pentaho, pero al ser esta última
una solución BI muy popular, existe una comunidad muy activa donde poder
adquirir una buena formación.

4.4.1. Pentaho CE
La herramienta BI escogida para implementar este proyecto es Pentaho BI,
en concreto, Community Edition (CE) 7.0, pues esta es una de las versiones
Open Source con mayor estabilidad, mayor soporte y comunidad activa.

Pentaho BI CE consiste en conjunto de herramientas programadas en su gran

mayorı́a en Java, independientes entre si, y que permiten la implementación de
todos los procesos de Business Intelligence. Las herramientas que se utilizaran
para el desarrollo del proyecto son las siguientes:
Pentaho Data Integration (PDI): Es una aplicación de escritorio para di-
señar y crear los procesos ETL. Permite realizar transformaciones, que
son los procesos que permiten extraer, transformar y cargar los datos al
Datawarehouse, y ejecutar trabajos, los cuales se utilizan para ejecutar los
procesos ETL periodicamente. [21]
PDI permite trabajar tanto con archivos, como mediante el uso de un
repositorio proporcionado por Pentaho, el cual es interesante para man-
tener un control de versiones del proceso, y además poder realizar un uso
colaborativo de la herramienta. [22]
Pentaho Report Designer (PRD) : Es una aplicación de escritorio que pro-
porciona un entorno de diseño visual para crear informes tanto estáticos
como con datos dinámicos a partir de filtros. Una vez creados los infor-
mes, permite publicarlos en el servidor web de Pentaho para que el usuario
pueda visualizarlos desde alli. [23]
Los reportes generados tienen el formato .prpt (Pentaho Reporting Archi-
ve) [27]

33
 Pentaho Schema Workbench (PSW): Es una aplicación de escritorio que
proporciona una interfaz gráfica para diseñar y crear los cubos OLAP, ge-
nerando un fichero XML donde se define la estructura de la base de datos
multidimensional. Proporciona un servidor OLAP en el que permite rea-
lizar consultas MDX contra los cubos creados, y permite una vez creados
los cubos, publicar estos en el servidor web de Pentaho. [24]
Pentaho Metadata Editor: Es una aplicación de escritorio que permite
diseñar un modelo de metadatos a partir del Datawarehouse. [25]

Pentaho BI Server: Es una aplicación web programada con el framework

Spring. Esta es el núcleo de Pentaho, donde se alojan todos los recursos
generados para poder ser utilizados de una manera sencilla por el usuario.
Permite entre otros crear cuadros de mando, visualizar informes, gestionar
los usuarios y roles de usuario. La suite proporciona un servidor Tomcat
para poder desplegar la aplicación de una forma sencilla. [26]
Podemos ver la arquitectura de Pentaho resumida en el siguiente diagrama:

Figura 7: Diagrama Arquitectura Pentaho

34
5. Captura de requisitos
En este apartado se detallaran los requisitos funcionales y casos de uso que
deberá cumplir el proyecto, para poder alcanzar las necesidades y objetivos del
proyecto definidos anteriormente.

5.1. Requisitos funcionales

Los requisitos funcionales definen las funcionalidades del sistema:
La aplicación solo debe poder usarse con un usuario registrado.

Permitir carga de datos en el Datawarehouse desde distintas fuentes.

Realizar el proceso ETL para la carga de datos en el Datawarehouse pe-
riódicamente.
Generar una serie de indicadores que sirva para el control directo mediante
la consulta de estos indicadores.
Realizar consultas contra el Datawarehouse de una forma sencilla.
Generación de distintos informes para la alta gerencia con el objetivo de
dar una visión general de lo que ocurre en su empresa.

Gestión de roles de usuario.

Ofrecer la posibilidad de exportar las consultas e informes realizados a
otras herramientas ofimáticas como Excel.
Ofrecer la posibilidad de programar tareas.

Ofrecer la posibilidad de crear y visualizar cuadros de mando.

Flexibilidad del sistema para que el usuario final pueda formatear la in-
formación a visualizar en los cuadros de mando.

5.2. Requisitos no funcionales

Los requisitos funcionales son aquellos requisitos que el sistema debe cumplir
independientemente de las funcionalidades a implementar:
El sistema debe ser estable y fácil de utilizar para personas sin conoci-
mientos técnicos de informática.

La aplicación debe mantener los datos utilizados seguros y protegidos.

La aplicación debe ser multiplataforma.
La aplicación no debe penalizar el rendimiento de los sistemas operacio-
nales.

35
5.3. Jerarquı́a de actores
Los tipos de usuarios del sistema son los siguientes: Por un lado, en la aplica-
ción web, el ”Usuario sin registrar” es aquel que accede a la aplicación y aún no
ha iniciado sesión. Una vez que decide iniciar sesión pasa a ser ”Usuario” o ”Ad-
ministrador” en función de su condición. Ambos tienen opción de hacer uso de
las funcionalidades del sistema, pero el ”Administrador” además podrá gestio-
nar los ajustes del sistema, dar de alta nuevos usuarios y gestionar sus permisos.

Por otro lado, se define el actor ”AdministradorCubos”, quien accede a la

aplicación Pentaho Cube Designer y puede crear nuevos cubos OLAP y desple-
garlos en la aplicación web, ”AdministradorETL”, el cual es el actor que accede
a la aplicación Pentaho Data Integration y puede definir y modificar el proceso
de carga de datos ETL al Datawarehouse, y el actor ”AdministradorReport”, el
cual accede a la aplicación Pentaho Report Designer y puede crear y modificar
informes y subirlos a la aplicación web.

Figura 8: Jerarquia de actores

36
5.4. Casos de uso

Figura 9: Casos de Uso

En el diagrama se observan las siguientes funcionalidades:

Iniciar sesión: La función es identificarse en la aplicación web.
Realizar consulta: Permite realizar consultas contra el Datawarehouse.

Crear cuadro de mando: Permite diseñar un cuadro de mando.

Visualizar cubos OLAP: Permite visualizar cubos OLAP desplegados
en el servidor utilizando un visor OLAP.
Abrir cuadros de mando: Permite abrir cuadros de mando diseñados
anteriormente.
Abrir informes: Permite abrir y exportar a diferentes herramientas ofimáti-
cas informes predefinidos y publicados en el servidor web.

37
 Programar tareas: Permite programar tareas a ejecutar en el servidor
web.

Administrar fuentes de datos: Permite añadir y modificar las diferen-

tes fuentes de datos con las que funciona la aplicación, y formatear los
datos utilizados para las consultas.
Administrar usuarios: Permite crear y eliminar los usuarios que pueden
acceder a la aplicación.

Administrar Roles de usuario: Permite modificar los permisos de los

distintos usuarios de la aplicación.
Crear cubos OLAP: Permite diseñar cubos OLAP a partir del Datawa-
rehouse.

Desplegar cubos OLAP: Permite desplegar los cubos OLAP diseñados

en el servidor web para poder visualizarlos desde el visor OLAP.
Definir transformaciones: Permite definir y modificar las diferentes
transformaciones de datos que conforma el proceso de ETL.
Definir jobs: Permite definir tareas para carga de datos en el Datawa-
rehouse de forma periódica.
Diseñar informe: Permite diseñar informes predefinidos y parametriza-
bles a partir de los datos del Datawarehouse.
Publicar informe: Permite publicar los informes diseñados en el servidor
web para poder utilizarlos.

Podemos ver los casos de uso extendidos definidos en el Anexo I: Casos de

uso extendidos

38
6. Análisis y diseño
6.1. Análisis de la base de datos origen
El primer paso del desarrollo de un proyecto BI es construir el Datawarehou-
se. Para ello, es importante analizar la información de los orı́genes de datos, para
ası́ poder determinar aquella información relevante a exportar para poder rea-
lizar unos informes y cuadros de mando útiles para el cliente.

En este caso, el origen de datos principal es el de InLOG WMS el cual tra-

baja con una base de datos de tipo objeto-relacional Oracle. Al haber estado
trabajando durante aproximadamente medio año con el sistema InLOG WMS
y disponer de ayuda de expertos, el análisis y selección de las tablas relevantes
se convierte en una tarea bastante sencilla.

Las tablas que se van a extraer van a ser tablas de hechos (tablas que alma-
cena los datos de los movimientos que se actualizan continuamente) y tablas de
dimensiones (tablas maestras por las cual se va a poder filtrar o navegar dentro
de la información almacenada en las tablas de hechos).

A continuación, se listan todas las tablas de InLOG WMS relevantes para

el desarrollo del Datawarehouse, junto con la forma de carga de estas al Data-
warehouse:
1. Tablas de hechos:
MOVIMIENTOS: Tabla de los movimientos realizados en el siste-
ma. Al tener fecha y hora fin del movimiento, se extraera toda la
información de la tabla que esté comprendida en el rango de fechas
marcado por el histórico que se quiera tener en las tablas historicas
del Datawarehouse.
PALETAS: Tabla de paletas existentes con mercancı́a. Se extraerán
todos los campos de la tabla. Para mantener un histórico del alta de
las paletas, se realizará un cruce con la tabla movimientos.
CABECERA DE PEDIDO DE COMPRA: Tabla de cabeceras de
pedidos de compra. Se extraerá toda la información de la tabla que
esté comprendida en el rango de fechas marcado por el histórico que
se quiera tener en las tablas históricas del Datawarehouse, teniendo
en cuenta la fecha de alta del pedido en el sistema.
LINEAS DE PEDIDOS DE COMPRA: Tabla de lineas de pedidos
de compra. Se extraerán todas las lineas de pedidos correspondientes
a las cabeceras extraidas.
CABECERA DE PEDIDO DE VENTA: Tabla de cabeceras de pe-
didos de ventas. Se extraerá toda la información de la tabla que esté
comprendida en el rango de fechas marcado por el histórico que se
quiera tener en las tablas históricas del Datawarehouse, teniendo en
cuenta la fecha de alta del pedido en el sistema.
LINEAS DE PEDIDOS DE VENTA: Tabla de lineas de Pedidos de
Venta. Se extraerán todas las lineas de pedidos correspondientes a
las cabeceras extraidas.

39
 CABECERA DEVOLUCIÓN CLIENTE: Tabla de cabeceras de de-
voluciones de clientes. Se extraerá toda la información de la tabla que
esté comprendida en el rango de fechas marcado por el histórico que
se quiera tener en las tablas históricas del Datawarehouse, teniendo
en cuenta la fecha de alta de la devolución en el sistema.
LINEAS DEVOLUCIÓN CLIENTE: Tabla de lineas de devoluciones
de clientes. Se extraerán todas las lineas de devoluciones correspon-
dientes a las cabeceras extraı́das.
CABECERA DEVOLUCIÓN PROVEEDOR: Tabla de cabeceras de
devoluciones de proveedores. Se extraerá toda la información de la
tabla que esté comprendida en el rango de fechas marcado por el
histórico que se quiera tener en las tablas históricas del Datawa-
rehouse, teniendo en cuenta la fecha de alta de la devolución en el
sistema.
LINEAS DEVOLUCIÓN PROVEEDOR: Tabla de lineas de devolu-
ciones de proveedores. Se extraerán todas las lineas de devoluciones
correspondientes a las cabeceras extraı́das.
ORDENES DE PALET COMPLETO: Tabla de Ordenes Paleta Com-
pleta. Se extraerán los registros de los pedidos de venta extraı́dos.
ORDENES DE PICKING: Tabla de cabecera de órdenes de Picking.
Se extraerán los registros de los pedidos de venta extraı́dos.
LINEAS DE PICKING: Tabla de lineas de picking. Se extraerán
todas las lineas correspondientes a las cabeceras cargadas en ORDE-
NES DE PICKING.
UBICACIÓN DE PICKING: Tabla de ubicaciones de picking. Se
extraerá toda la tabla, al no disponer de ningún histórico del alta de
ubicaciones.
UBICACIÓN DE ALMACENAJE: Tabla de ubicaciones de almace-
naje. Se extraerá toda la tabla, al no disponer de ningún histórico
del alta de ubicaciones.
2. Tablas de dimensiones:
ALMACENES: Tabla de almacenes. Se extraerá toda la información
de la tabla.
ÁREA DESCARGA: Tabla de área descarga. Se extraerá toda la
información de la tabla.
ARTÍCULOS: Tabla de artı́culos. Se extraerá toda la información de
la tabla.
CLIENTES: Tabla de clientes. Se extraerá toda la información de la
tabla.
OPERARIOS: Tabla de operarios. Se extraerá toda la información
de la tabla.
PASILLOS: Tabla de pasillos. Se extraerá toda la información de la
tabla.
PROPIETARIOS: Tabla de propietarios. Se extraerá toda la infor-
mación de la tabla.

40
 PROVEEDORES: Tabla de proveedores. Se extraerá toda la infor-
mación de la tabla.
TIPOS MOVIMIENTO: Tabla de tipos de movimientos. Se extraerá
toda la información de la tabla.
TIPOS PEDIDO PROVEEDOR: Tabla de tipos de pedidos de pro-
veedor. Se extraerá toda la información de la tabla.
TIPOS PEDIDO: Tabla de tipos de pedidos de venta. Se extraerá
toda la información de la tabla.
TIPOS PALETA: Tabla de tipos de paleta. Se extraerá toda la in-
formación de la tabla.
Las tablas de dimensiones no tienen fecha por la que se controlará cuan-
do se ha dado de alta un registro. El criterio que deben de seguir todas
las tablas de dimensiones es que sus datos no serán borrados en ningún
momento y serán mantenidos en las tablas históricas del Datawarehouse.
Como fuentes de datos secundarias, tenemos una base de datos procedente
de un ERP, y otra procedente de un sistema de recursos humanos.
La base de datos del ERP es una base de datos relacional MySQL, de la cual
extraeremos los datos de facturación de los pedidos de compra y venta. A con-
tinuación, se listan las modificaciones en las tablas de hechos y dimensiones
definidas anteriormente:
CABECERA DE PEDIDO DE COMPRA: Se añade un nuevo campo
correspondiente al coste del pedido. Se extraerá la información de aquellos
pedidos extraı́dos en InLOG WMS.

CABECERA DE PEDIDO DE VENTA: Se añade un nuevo campo co-

rrespondiente al precio del pedido. Se extraerá la información de aquellos
pedidos extraı́dos en InLOG WMS.
ARTICULOS. Se añade un nuevo campo correspondiente al precio y coste
del artı́culo. Se extraerá la información de aquellos artı́culos extraı́dos en
InLOG WMS
La base de datos del sistema de recursos humanos es una base de datos
relacional MySQL, de la cual extraeremos el coste/hora de los operarios. Mo-
dificaremos la tabla de dimensiones OPERARIOS, añadiendo un nuevo campo
correspondiente al coste/hora.

41
6.2. Diseño del Datawarehouse
Una vez analizadas las distintas fuentes de datos que van a formar los datos
almacenados en el Datawarehouse, el siguiente paso es realizar un diseño del
modelo dimensional y el modo de carga de datos.

Existen dos modos diferentes de esquemas de base de datos para llevar a

cabo el modelado dimensional del Datawarehouse: [19]
Esquema en estrella: Está formado por una tabla de hechos, la cual con-
tiene datos para el análisis, rodeada de tablas de dimensiones. [19]

Figura 10: Esquema de estrella

Es el esquema utilizado habitualmente para modelar la base de datos. [20]

Esquema en copo de nieve: Es una estructura mas compleja que el esquema
estrella. Está formado por una tabla de hechos conectada con dimensiones
anidadas. [19]

Figura 11: Esquema copo de nieve

42
 Es utilizado cuando alguna de las dimensiones se implementa con más de
una tabla de datos, normalizando ası́ estas tablas y eliminando la redun-
dancia entre los datos. [19]

En este caso, el Datawarehouse será diseñado con esquemas en copo de nie-

ve, pues varias de las dimensiones están relacionadas entre si, y por ello, no
puede utilizarse el esquema en estrella. Al crearse los esquemas en copo de nieve
entorno a las tablas de hechos, necesitamos realizar un esquema diferente por
cada una de las tablas de hechos.

Hasta las últimas versiones de Mondrian, el servidor OLAP de Pentaho, solo

se permitı́a establecer la relación entre las tablas en función de un único campo,
y debido a que Pentaho aun sigue trabajando con una versión mas antigua de
este, necesitamos que todas las claves primarias de las tablas de dimensiones
estén formadas por un solo campo, con lo cual, añadiremos un campo numérico
de identificación en las siguientes tablas de dimensiones:
ARTÍCULOS: Hasta ahora identificado por almacén, propietario, articulo
y variables del articulo. Se añade un campo numérico ART IDENTI para
identificar el articulo.
ÁREA DESCARGA: Hasta ahora identificado por almacén y código de
área descarga. Se añade un campo numérico ADE IDENTI para identificar
el área de descarga.
PASILLOS: Hasta ahora identificado por almacén y código de pasillo. Se
añade un nuevo campo númerico PAS IDENTI para identificar el pasillo.

Para simplificar los esquemas, únicamente mostramos los campos correspon-

diente a la clave primaria de la tabla, antiguas claves primarias de aquellas tablas
de dimensiones de las cuales se ha añadido un campo de identificación, claves
extranjeras y campos nuevos obtenidos en la carga de datos desde diferentes
fuentes:

Figura 12: Esquema en copo de nieve de la tabla Movimientos

43
 Figura 13: Esquema en copo de nieve de la tabla Paletas

Figura 14: Esquema en copo de nieve de la tabla Cabecera de Pedido de Compra

Figura 15: Esquema en copo de nieve de la tabla Lineas de Pedidos de Compra

44
Figura 16: Esquema en copo de nieve de la tabla Cabecera de Pedido de Venta

Figura 17: Esquema en copo de nieve de la tabla Lineas de Pedidos de Venta

45
Figura 18: Esquema en copo de nieve de la tabla Cabecera Devolución Cliente

Figura 19: Esquema en copo de nieve de la tabla Lineas Devolución Cliente

46
Figura 20: Esquema en copo de nieve de la tabla Cabecera Devolución Proveedor

Figura 21: Esquema en copo de nieve de la tabla Lineas Devolución Proveedor

47
Figura 22: Esquema en copo de nieve de la tabla Ordenes de Palet Completo

Figura 23: Esquema en copo de nieve de la tabla Ordenes de Picking

48
 Figura 24: Esquema en copo de nieve de la tabla Lineas de Picking

Figura 25: Esquema en copo de nieve de la tabla Ubicación de Picking

49
 Figura 26: Esquema en copo de nieve de la tabla Ubicación de Almacenaje

6.3. Diseño de los cubos OLAP

Tras diseñar el Datawarehouse, se dispone en este de toda la información
necesaria para diseñar los cubos OLAP, los cuales permitirán acceder a la infor-
mación del Datawarehouse de una forma más rápida, permitiendo ası́ realizar
consultas complejas contra este.

Al igual que en el paso anterior, se realiza un cubo por cada una de las tablas
de hechos. Para cada cubo se define las dimensiones que lo componen, ya sean
compartidas o propias, y las medidas. Las dimensiones compartidas son aquellas
dimensiones que son utilizadas por más de un cubo, y las dimensiones propias
son aquellas dimensiones únicamente utilizadas en el cubo donde se definen.

En primer lugar, definimos las dimensiones compartidas. Por cada dimensión

se definen las jerarquı́as con sus respectivos niveles:
Dimensión Artı́culos
ˆ Jerarquı́a Articulos
◦ Nivel Almacén
◦ Nivel Propietario
◦ Nivel Nombre
Dimensión Operarios
ˆ Jerarquı́a Operarios
◦ Nivel Nombre
◦ Nivel Almacén

50
 ◦ Nivel Código
Dimensión Propietarios

ˆ Jerarquı́a Propietarios
◦ Nivel Nombre
◦ Nivel Código
◦ Nivel Localidad
◦ Nivel Provincia
◦ Nivel Paı́s
◦ Nivel Código Postal

Dimensión Proveedor
ˆ Jerarquı́a Proveedor
◦ Nivel Nombre
◦ Nivel Código
◦ Nivel Localidad
◦ Nivel Provincia
◦ Nivel Paı́s
◦ Nivel Código Postal
Dimensión Cliente
ˆ Jerarquı́a Cliente
◦ Nivel Nombre
◦ Nivel Código
◦ Nivel Localidad
◦ Nivel Provincia
◦ Nivel Paı́s
◦ Nivel Código Postal
Dimensión Almacenes
ˆ Jerarquı́a Almacenes
◦ Nivel Código
◦ Nivel Denominación
◦ Nivel Localidad
◦ Nivel Provincia
◦ Nivel Paı́s
◦ Nivel Código Postal
Dimensión Pasillos

ˆ Jerarquı́a Pasillos
◦ Nivel Almacén
◦ Nivel Código
◦ Nivel Denominación

51
 ◦ Nivel Sección
Una dimensión muy importante que debe estar en todo Datawarehouse es la
dimensión tiempo, pues casi todos los análisis necesitan poder hacerse desde una
perspectiva temporal. Esta dimensión suele estar relacionada con la mayorı́a de
sus tablas de hechos, siendo frecuente que lo haga por mas de una columna. [29]

En este caso, en lugar de implementar la dimensión tiempo mediante el uso

de una tabla fı́sica, se ha decidido implementarlo mediante una vista que calcu-
le los distintos atributos correspondientes al tiempo. El rango de fechas que se
calculará en la vista será desde el 1 de enero de 2020, hasta un mes después de
la fecha del sistema en el momento de hacer la consulta.

La estructura de la vista es la siguiente:

V DIM TIEMPO
CAMPO FORMATO DESCRIPCIÓN
Fecha con formato
FECHA DATE
DD/MM/YYYY
AÑO NUMBER Año de la fecha
MES VARCHAR Nombre del mes
DIA VARCHAR Nombre del dia
SEMANA NUMBER Número de la semana
SEMESTRE NUMBER Número de semestre
TRIMESTRE NUMBER Número de trimestre
DIAJULIANO NUMBER Fecha juliana
Indica si es dı́a festivo
FESTIVO VARCHAR
o no

Tabla 37: Estructura Vista Dimensión Tiempo

Para poder determinar si un dı́a es festivo o no, se creará la tabla FESTIVOS,

en la que cada cliente podrá introducir sus dı́as que habitualmente son declara-
dos festivos, y mediante un procedimiento almacenado se determinará si el dı́a
es festivo o no, teniendo en cuenta esta tabla y el dı́a de la semana no laborable.

Figura 27: Esquema tabla Festivos y pseudocódigo procedimiento almacenado

52
 A continuación, definimos la dimensión tiempo:
Dimensión Tiempo
ˆ Jerarquı́a Tiempo
◦ Nivel Año
◦ Nivel Semestre
◦ Nivel Trimestre
◦ Nivel Mes
◦ Nivel Semana
◦ Nivel Dı́a
◦ Nivel Dı́a Juliano
◦ Nivel Festivo
Una vez definidas las dimensiones compartidas, ya podemos definir los cubos:
Cubo Movimientos
ˆ Dimensión Artı́culos
ˆ Dimensión Operarios
ˆ Dimensión Tipo de Movimiento
◦ Jerarquı́a Tipo de Movimiento
 Nivel Código Movimiento
 Nivel Nombre Movimiento
ˆ Dimensión Tiempo: Fecha Inicio
ˆ Dimensión Tiempo: Fecha fin
ˆ Medida Cantidad
ˆ Medida Número artı́culos diferentes
ˆ Medida Operarios diferentes
ˆ Medida Número movimientos
Cubo Paletas
ˆ Dimensión Artı́culos
ˆ Dimensión Tipos de Paleta
◦ Jerarquı́a Tipos de Paleta
 Nivel Código
 Nivel Nombre
 Nivel Propietario
ˆ Medida Número paletas
ˆ Medida Número artı́culos diferentes
ˆ Medida Stock paleta
ˆ Medida Número movimientos de paleta
ˆ Medida Stock mı́nimo paleta
ˆ Medida Stock máximo paleta

53
Cubo Cabecera de Pedido de Compra
ˆ Dimensión Propietarios
ˆ Dimensión Proveedor
ˆ Dimensión Tipos Pedido Proveedor
◦ Jerarquı́a Tipos Pedido Proveedor
 Nivel Código
 Nivel Nombre
 Nivel Propietario
ˆ Dimensión Área Descarga
◦ Jerarquı́a Área Descarga
 Nivel Código
 Nivel Denominación
 Nivel Almacén
ˆ Dimensión Tiempo: Fecha asignada a pedido
ˆ Medida Coste
ˆ Medida Media Coste
ˆ Medida Número de proveedores diferentes
ˆ Medida Número de paletas
ˆ Medida Operarios diferentes
ˆ Medida Número de pedidos
Cubo Lineas de Pedido de Compra
ˆ Dimensión Artı́culos
ˆ Medida Cantidad pedida
ˆ Medida Cantidad recibida
ˆ Medida Número de paletas
ˆ Medida Número de lineas
ˆ Medida Número de pedidos
ˆ Medida Artı́culos diferentes
Cubo Cabecera de Pedido de Venta
ˆ Dimensión Almacenes
ˆ Dimensión Propietarios
ˆ Dimensión Clientes
ˆ Dimensión Tipos Pedido
◦ Jerarquı́a Tipos Pedido
 Nivel Código
 Nivel Denominación
 Nivel Procesamiento automático
 Nivel Agrupación automática

54
 ˆ Dimensión Tiempo: Fecha de transmisión
ˆ Dimensión Tiempo: Fecha de servicio
ˆ Medida Coste
ˆ Medida Media coste
ˆ Medida Número de paletas
ˆ Medida Número de pedidos
ˆ Medida Clientes diferentes
ˆ Medida Peso paletas completas
ˆ Medida Peso picking
ˆ Medida Volumen paleta completa
ˆ Medida Volumen picking

Cubo Lineas de Pedido de Venta

ˆ Dimensión Artı́culos
ˆ Medida Cantidad pedida
ˆ Medida Cantidad servida
ˆ Medida Número de pedidos
ˆ Medida Artı́culos diferentes

Cubo Cabecera Devolución Cliente

ˆ Dimensión Almacenes
ˆ Dimensión Propietarios
ˆ Dimensión Clientes
ˆ Dimensión Operarios
ˆ Dimensión Tiempo: Fecha devolución
ˆ Medida Clientes diferentes
ˆ Medida Operarios diferentes
ˆ Medida Muelles
ˆ Medida Número devoluciones

Cubo Lineas Devolución Cliente

ˆ Dimensión Artı́culos
ˆ Dimensión Operarios
ˆ Medida Cantidad total
ˆ Medida Cantidad apta
ˆ Medida Cantidad no apta
ˆ Medida Número operarios
ˆ Medida Artı́culos diferentes

55
Cubo Cabecera Devolución Proveedor
ˆ Dimensión Almacenes
ˆ Dimensión Propietarios
ˆ Dimensión Clientes
ˆ Dimensión Operarios
ˆ Dimensión Tiempo: Fecha devolución
ˆ Medida Proveedores diferentes
ˆ Medida Operarios diferentes
ˆ Medida Muelles
ˆ Medida Número devoluciones

Cubo Lineas Devolución Proveedor

ˆ Dimensión Artı́culos
ˆ Dimensión Operarios
ˆ Medida Cantidad
ˆ Medida Número paletas
ˆ Medida Número operarios
ˆ Medida Artı́culos diferentes

Cubo Ordenes de paleta completa

ˆ Dimensión Operarios
ˆ Dimensión Artı́culos
ˆ Medida Artı́culos diferentes
ˆ Medida Cantidad paletas pedidas
ˆ Medida Cantidad recibida
ˆ Medida Operarios diferentes

Cubo Ordenes de Picking

ˆ Dimensión Operarios
ˆ Dimensión Almacenes
ˆ Medida Número pedidos
ˆ Medida Operarios diferentes
ˆ Medida Número de lineas
ˆ Medida Número de contenedores
ˆ Medida Volumen contenedores
ˆ Medida Peso contenedores

56
Cubo Lineas de Picking
ˆ Dimensión Artı́culos
ˆ Medida Cantidad pedida
ˆ Medida cantidad servida
ˆ Medida Artı́culos diferentes

Cubo Ubicación de Picking

ˆ Dimensión Pasillos
ˆ Dimensión Artı́culos
ˆ Medida Número paletas ubicadas
ˆ Medida Artı́culos diferentes

Cubo Ubicación de Almacenaje

ˆ Dimensión Pasillos
ˆ Dimensión Artı́culos
ˆ Medida Número paletas ubicadas
ˆ Medida Artı́culos diferentes

57
6.4. Diseño de los informes predefinidos
Una vez construido el Datawarehouse, un paso para poder realizar un análisis
sobre los datos extraı́dos a este es mediante los informes predefinidos:
1. INFORME PALETAS CADUCADAS:

Muestra los datos sobre aquellas paletas que han caducado en un periodo
determinado.

Parámetros:
Fecha inicio periodo (Obligatoria)
Fecha fin periodo (Obligatoria)
Código de propietario (Opcional)
Se mostrará el código de paleta, nombre de propietario, código de articulo,
nombre de artı́culo, stock de paleta e importe de la paleta (multiplicación
stock de paleta por precio del artı́culo). Los datos se obtendrán de las
tablas de H PALETAS, DIM ARTÍCULOS Y DIM PROPIETARIOS.

Se mostrará una fila de totales, calculando el total de las columnas stock

de paleta e importe de la paleta.

Figura 28: Diseño informe paletas caducadas

58
2. INFORME PEDIDOS DE COMPRA:

Muestra los datos de un pedido de compra.

Parámetros:
Pedido (Obligatorio)
Se mostrará por un lado, en la cabecera del informe el código de pedido,
tipo de pedido, fecha asignada del pedido al sistema, nombre de almacén,
nombre de propietario, nombre de proveedor, número de paletas, núme-
ro de lineas y situación del pedido. Los datos se obtendrán de las tablas
H CABEC PEDCOM, DIM TIPOS PEDPROV, DIM ALMACENES, DIM PROPIETARIOS
y DIM PROVEEDOR.

En las lineas del pedido, se mostrará el número de linea, código de artı́cu-

lo, nombre de artı́culo, cantidad teórica a recibir, cantidad real recibi-
da, situación de la linea y coste. Los datos se obtendrán de las tablas
H LINEAS PEDCOM y DIM ARTICULOS.

Se mostrará una fila de totales, calculando el total del coste del pedido.

Figura 29: Diseño informe pedidos de compra

59
3. INFORME PEDIDOS DE VENTA:

Muestra los datos de un pedido de venta.

Parámetros:
Pedido (Obligatorio)
División (Obligatorio)

Se mostrará por un lado, en la cabecera del informe el código de pedi-

do, tipo de pedido, fecha de transmisión del pedido al sistema, nombre
de almacén, nombre de propietario, nombre del cliente, nombre de opera-
rio y situación. Los datos se obtendrán de las tablas H CABEC PEDVEN,
DIM TIPOS PEDIDO, DIM ALMACENES, DIM PROPIETARIOS, DIM CLIENTES
y DIM OPERARIOS.

En las lineas del pedido, se mostrará el número de linea, código de artı́cu-

lo, nombre de artı́culo, cantidad pedida, formato de la cantidad pedi-
da, cantidad servida (siempre en unidades), situación de la linea, coste
de compra del artı́culo, coste de la preparación de la linea y precio. Los
datos se obtendrán de las tablas H LINEAS PEDVEN, H LINEAS PK,
DIM ARTICULOS y DIM OPERARIOS.

Se mostrará una fila de totales, calculando el total del coste de compra de

los artı́culos, coste de la preparación de las lineas y precios. Además, se
mostrará una fila indicando los beneficios obtenidos con el pedido.

Figura 30: Diseño informe pedidos de venta

60
4. INFORME PRODUCTIVIDAD OPERARIOS:

Muestra los datos de productividad sobre los operarios del almacén en un

periodo determinado

Parámetros:
Fecha inicio periodo (Obligatoria)
Fecha fin periodo (Obligatoria)
Código de operario (Opcional)
Se mostrará el nombre de operario, número de movimientos realizados,
total de tiempo empleado en formato (HH:MI:SS) y coste de operario. Los
datos se obtendrán de las tablas de H MOVIMIENTOS Y DIM OPERARIOS.

Figura 31: Diseño informe productividad operarios

61
7. Desarrollo
Para el desarrollo del proyecto, se ha utilizado una maquina con el sistema
operativo CentOS y el cliente Oracle Database 11g instalado.

La administración de la maquina se realizará utilizando el protocolo SSH,

con el cual se podrá acceder de forma remota al servidor y además realizar trans-
ferencias de archivos a este, mientras que la administración de la base de datos
instalada en la maquina se realizará mediante el entorno PL/SQL Developer.
Para diferenciar el acceso las diferentes funcionalidades instaladas en la maqui-
na, tenemos los siguientes usuarios:
ORACLE: Permite gestionar la base de datos Oracle.
ETL: Permite gestionar el proceso de carga de datos al Datawarehouse.
SERVER: Permite gestionar el servidor web de Pentaho.

7.1. Creación del esquema de base de datos

El primer paso en el desarrollo es crear el esquema de base de datos corres-
pondiente al Datawarehouse.

En Oracle, un schema contiene todos los objetos creados por un usuario

especı́fico de la base de datos. Esos objetos pueden incluir tablas, vistas, sinóni-
mos, triggers. . . [28]

Para crear el schema, nos conectamos a la maquina mediante SSH con el

usuario Oracle, y accedemos a la base de datos en modo administrador ejecu-
tando el siguiente comando:
s q l p l u s ” / a s sysdba ”
En este caso, el Datawarehouse se creará en un schema que llamaremos
pentaho. Para ello, ejecutaremos el siguiente comando:
CREATE USER pentaho IDENTIFIED BY pentaho ;
El siguiente paso es asignar permisos de conexión a base de datos, utilizando
los siguientes comandos:
GRANT ”CONNECT” TO pentaho ;
GRANT ”RESOURCE” TO pentaho ;
Finalmente, asignamos permisos especı́ficos para permitir realizar todas las
operaciones necesarias sobre objetos:
GRANT ALTER ANY INDEX TO pentaho ;
GRANT ALTER ANY SEQUENCE TO pentaho ;
GRANT ALTER ANY TABLE TO pentaho ;
GRANT ALTER ANY TRIGGER TO pentaho ;
GRANT CREATE ANY INDEX TO pentaho ;
GRANT CREATE ANY SEQUENCE TO pentaho ;
GRANT CREATE ANY TABLE TO pentaho ;
GRANT CREATE ANY TRIGGER TO pentaho ;

62
 GRANT CREATE ANY VIEW TO pentaho ;
GRANT CREATE PROCEDURE TO pentaho ;
GRANT CREATE TRIGGER TO pentaho ;
GRANT CREATE VIEW TO pentaho ;
GRANT DELETE ANY TABLE TO pentaho ;
GRANT DROP ANY INDEX TO pentaho ;
GRANT DROP ANY SEQUENCE TO pentaho ;
GRANT DROP ANY TABLE TO pentaho ;
GRANT DROP ANY TRIGGER TO pentaho ;
GRANT DROP ANY VIEW TO pentaho ;
GRANT INSERT ANY TABLE TO pentaho ;
GRANT QUERY REWRITE TO pentaho ;
GRANT SELECT ANY TABLE TO pentaho ;
Una vez creado el schema, ya podemos acceder a este mediante PL/SQL
Developer.

El siguiente paso es crear la estructura de tablas de hechos y dimensiones.

Para facilitar una posible futura implementación en otros clientes, realizaremos
un script de instalación de base de datos, donde guardaremos todas las instruc-
ciones necesarias para crear la estructura del datawarehouse.

Utilizando la instrucción CREATE TABLE, creamos todas las tablas ne-

cesarias para formar el Datwarehouse, añadiendo el prefijo H a las tablas de
hechos, y añadiendo el prefijo DIM a las tablas de dimensiones.

Una vez creado el script de instalación, lo ejecutamos en la base de datos

utilizando PL/SQL Developer.

Figura 32: Vista esquema DWH desde PL/SQL Developer

63
7.2. Implementación del proceso ETL
El proceso ETL se realizará mediante la herramienta Pentaho Data Integra-
tion (PDI), incluida en la suite de Pentaho CE.

Esta herramienta proporciona una interfaz gráfica en la que se pueden di-

señar transformaciones (conjunto de pasos para realizar la transformación desde
el origen de datos hasta el Datawarehouse) y jobs (definir la ejecución de trans-
formaciones)

A continuación, se muestran las transformaciones implementadas teniendo

en cuenta las condiciones de carga de datos definidas anteriormente para cada
una de las tablas:

1. TABLA DIMENSIONES ARTÍCULOS

Figura 33: Transformación de la tabla de dimensiones Artı́culos

La transformación de la tabla ARTÍCULOS consiste en unir las tablas

procedentes del ERP y WMS, y además insertar un código numérico se-
cuencial que servirá para identificar al articulo, al estar este originalmente
identificado por varios campos.

Se definen los siguientes pasos:

ARTÍCULOS ERP: Extrae la información de la tabla ARTÍCULOS
del ERP.
ARTÍCULOS WMS: Extrae la información de la tabla ARTÍCULOS
de InLOG WMS.
Unir: Une la información de la tabla ARTÍCULOS extraı́da del ERP
y ARTÍCULOS extraı́da de InLOG WMS.
Selecciono valores: Selecciona aquellos campos a insertar, eliminando
aquellos campos del ERP que no son necesarios.
Inserto secuencia: Añade el campo numérico secuencial para identi-
ficar cada articulo.
Insertar / Actualizar Artı́culos: Inserta los datos a la tabla histórica
de ARTÍCULOS del Datawarehouse.

64
 2. TABLA DIMENSIONES ÁREA DESCARGA Y PASILLOS

Figura 34: Transformación de las tablas de dimensiones Área descarga y Pasillos

Se definen los siguientes pasos:

ÁREA DESCARGA: Extrae la información de la tabla ÁREA DES-
CARGA de InLOG WMS.
Inserto Secuencia 2: Añade el campo numérico secuencial para iden-
tificar cada área de descarga.
Insertar / Actualizar Área Descarga: Inserta los datos a la tabla de
dimensión ÁREA DESCARGA del Datawarehouse.
PASILLOS: Extrae la información de la tabla PASILLOS de InLOG
WMS.
Inserto Secuencia 3: Añade el campo numérico secuencial para iden-
tificar cada pasillo.
Insertar / Actualizar Almacenes: Inserta los datos a la tabla de di-
mensión PASILLOS del Datawarehouse.
3. TABLA HECHOS MOVIMIENTOS:

Figura 35: Transformación de la tabla de hechos Movimientos

La transformación de la tabla MOVIMIENTOS consiste en cargar aquellos

movimientos cuya fecha fin de movimiento es superior a la fecha estipula-
da. Debido a que el movimiento contiene información sobre artı́culos, es
necesario obtener el código de identificación de este desde la nueva tabla
de ARTICULOS en el Datawarehouse.

Se definen los siguientes pasos:

65
 MOVIMIENTOS: Extrae la información de la tabla movimientos de
InLOG WMS
ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse
Unir: Une los datos de los movimientos con los artı́culos del DWH
para obtener el código de identificación del artı́culo.
Filtrar por fecha: Filtra aquellas filas en las que la fecha fin del mo-
vimiento es superior al 1/01/2021
Selecciono valores: Selecciona aquellos valores a insertar, eliminando
los campos de referencia al artı́culo antiguos y añadiendo el código
numérico de identificación del articulo como referencia.
Insertar/Actualizar MOVIMIENTOS: Inserta los datos a la tabla
histórica de MOVIMIENTOS del Datawarehouse
4. TABLA HECHOS PALETAS:

Figura 36: Transformación de la tabla de hechos Paletas

Por un lado, insertamos el valor actual de la tabla PALETAS, sin realizar

ningún cambio (1), y por otro lado, obtendremos los cambios de stock que
ha sufrido la paleta, realizando un cruce con la tabla movimientos (2)

Se definen los siguientes pasos:

ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse.
PALETAS: Extrae la información de la tabla paletas de InLOG WMS.
Unir 2: Une los datos de las paletas con los artı́culos del DWH para
obtener el código de identificación del artı́culo.
Ordenar por código paleta: Ordena los datos por código de paleta.
Selecciono valores: Selecciona aquellos valores a insertar, eliminando
los campos de referencia al artı́culo antiguos y añadiendo el código
numérico de identificación del articulo como referencia.
Insertar / Actualizar Paletas: Inserta los datos a la tabla histórica de
PALETAS del Datawarehouse.

66
 MOVIMIENTOS DE PALETAS: Extrae la información de aquellos
movimientos relacionado con paletas de InLOG WMS
Unir 2: Une los datos de las paletas con los movimientos realizados
sobre estas.
Formateo stock: Calcula el nuevo stock de la paleta y formatea el
tipo de datos para hacerlo compatible con el campo STOCK DE
PALETA.
Modifico stock: Actualiza el campo STOCK DE PALETA introdu-
ciendo el nuevo stock calculado.
Formateo valores: Selecciona únicamente aquellos campos correspon-
dientes a la tabla PALETAS, eliminando la información de los movi-
mientos.
Insertar/Actualizar HISTORICO PALETAS: Inserta los datos a la
tabla histórica de PALETAS del Datawarehouse.
5. TABLAS HECHOS PEDIDOS DE COMPRA

Figura 37: Transformación de las tablas de hechos Pedidos de Compra

La transformación consiste en, por un lado cargar aquellos pedidos de

compra uniendo las tablas procedentes del ERP y WMS cuya fecha de al-
ta de pedido sea superior a la fecha estipulada. Debido a que las cabeceras
contienen información del área de descarga, es necesario obtener el código
secuencial que las identifica.

Por otro lado, en el caso de las lineas de compra, se cargarán aquellas

correspondientes a los pedidos cargados en las cabeceras, por ello será ne-
cesario aplicar un filtro consultando las cabeceras. Debido a que las lineas
contienen información de los artı́culos, es necesario obtener el código se-
cuencial que los identifica.

Se definen los siguientes pasos:

67
AREA DESCARGA DWH: Extrae la información de la tabla ÁREA
DESCARGA del Datawarehouse.
PEDIDOS DE COMPRA ERP: Extrae la información de la tabla
PEDIDOS COMPRA del ERP.
CABECERA DE PEDIDO DE COMPRA: Extrae la información de
la tabla CABECERA DE PEDIDO DE COMPRA de InLOG WMS.
Unir 4: Une los datos de las cabeceras de pedido de compra con
las áreas de descarga del Datawarehouse para obtener el código de
identificación del área de descarga.
Unir 5: Une la información de la tabla PEDIDOS COMPRA extraı́da
del ERP y CABECERA DE PEDIDO DE COMPRA extraı́da de
InLOG WMS.
Ordenar por área descarga: Ordena los campos en función del área
de descarga para poder unir con ÁREA DESCARGA DWH
Filtrar por fecha 2: Filtra aquellas filas en las que la fecha de alta del
pedido en InLOG WMS es superior al 1/01/2021.
Selecciono valores: Selecciona aquellos campos a insertar, eliminando
aquellos campos del ERP que no son necesarios.
Insertar / Actualizar Cabecera PedCom. Inserta los datos a la tabla
histórica de CABECERA DE PEDIDO DE COMPRA del Datawa-
rehouse.
LINEAS DE PEDIDOS DE COMPRA: Extrae la información de la
tab la LINEAS DE PEDIDOS DE COMPRA de InLOG WMS.
ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse.
Unir 6: Une los datos de las lineas de pedido de compra con los
artı́culos del Datawarehouse para obtener el código de identificación
del articulo.
Ordenar por pedido: Ordena los campos en función del pedido.
Filtro por cabeceras insertadas: Filtra aquellas lı́neas de pedidos de
las cuales se han extraı́do las cabeceras.
Selecciono valores 2: Selecciona aquellos campos a insertar.
Insertar / Actualizar Lineas PedCom: Inserta los datos a la tabla
histórica de LINEAS DE PEDIDO DE COMPRA del Datawarehou-
se.

68
 6. TABLAS HECHOS PEDIDOS DE VENTA, ORDENES DE PALET COM-
PLETO Y PICKING

Figura 38: Transformación de las tablas de hechos Pedidos de Venta,Ordenes de

Palet Completo y Picking

Se definen los siguientes pasos:

ORDENES DE PALET COMPLETO: Extrae la información de la
tabla ORDENES DE PALET COMPLETO de InLOG WMS.
ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse.
Unir 7: Une las ordenes de palet completo con los artı́culos del Da-
tawarehouse para obtener el código de identificación del articulo.
Ordenar por pedido: Ordena los campos en función del pedido.
Filtro por cabeceras insertadas 2: Filtra aquellas ordenes de picking
de las cuales se han extraı́do los pedidos de venta asociados.
Selecciono valores 3: Selecciona aquellos campos a insertar.
Insertar / Actualizar Ordenes PC: Inserta los datos a la tabla históri-
ca de ORDENES DE PALET COMPLETO del Datawarehouse.
PEDIDOS DE VENTA ERP: Extrae la información de la tabla PE-
DIDOS VENTA del ERP.
CABECERA DE PEDIDO DE VENTA: Extrae la información de la
tabla CABECERA DE PEDIDO DE VENTA de InLOG WMS.
Unir 3: Une la información de la tabla PEDIDOS VENTA extraı́da
del ERP y CABECERA DE PEDIDO DE VENTA extraı́da de In-
LOG WMS
Filtrar por fecha 3: Filtra aquellas filas en las que la fecha de alta del
pedido en InLOG WMS es superior al 1/01/2021.

69
Selecciono valores 4: Selecciona aquellos campos a insertar, eliminan-
do aquellos campos del ERP que no son necesarios.
Insertar / Actualizar Cabecera Pedven Inserta los datos a la tabla
histórica de CABECERA DE PEDIDO DE VENTA del Datawa-
rehouse.
LINEAS DE PEDIDOS DE VENTA: Extrae la información de la
tabla LINEAS DE PEDIDO DE VENTA de InLOG WMS.
Unir 8: Une las lineas de pedidos de venta con los artı́culos del Da-
tawarehouse para obtener el código de identificación del articulo.
Ordenar por pedido 2: Ordena los campos en función del pedido.
Filtro por cabeceras insertadas 3: Filtra aquellas lı́neas de pedidos de
las cuales se han extraı́do las cabeceras.
Selecciono valores 5: Selecciona aquellos campos a insertar.
Insertar / Actualizar Lineas Pedven Inserta los datos a la tabla
histórica de LINEAS DE PEDIDO DE VENTA del Datawarehou-
se.
ORDENES DE PICKING: Extrae la información de la tabla ORDE-
NES DE PICKING de InLOG WMS.
Filtro por cabeceras insertadas 4: Filtra aquellas ordenes de picking
de las cuales se han extraı́do las cabeceras.
Selecciono valores 6: Selecciona aquellos campos a insertar.
Insertar / Actualizar Ordenes PK Inserta los datos a la tabla histórica
de ORDENES DE PICKING del Datawarehouse.
LINEAS DE PICKING: Extrae la información de la tabla LINEAS
DE PICKING de InLOG WMS.
Unir 9: Une las lineas de picking con los artı́culos del Datawarehouse
para obtener el código de identificación del articulo.
Ordenar por pedido 3: Ordena los campos en función del pedido.
Filtro por cabeceras insertadas 5: Filtra aquellas lı́neas de picking de
las cuales se han extraı́do las ordenes de picking.
Selecciono valores 7: Selecciona aquellos campos a insertar.
Insertar / Actualizar Lineas PK Inserta los datos a la tabla histórica
de LINEAS DE PICKING del Datawarehouse.

70
7. TABLAS HECHOS DEVOLUCIONES CLIENTE

Figura 39: Transformación de las tablas de hechos Devoluciones Cliente

Se definen los siguientes pasos:

CABECERA DEVOLUCIÓN CLIENTE: Extrae la información de
la tabla CABECERA DEVOLUCIÓN CLIENTE de InLOG WMS.
Filtrar por fecha 4: Filtra aquellas filas en las que la fecha de alta de
la devolución en InLOG WMS es superior al 1/01/2021.
Insertar / Actualizar Cabecera DevCli Inserta los datos a la tabla
histórica de CABECERA DEVOLUCIÓN CLIENTE del Datawa-
rehouse.
LINEAS DEVOLUCIÓN CLIENTE: Extrae la información de la ta-
bla LINEAS DEVOLUCION CLIENTE de InLOG WMS.
ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse.
Unir 11: Une las lineas de devolución cliente con los artı́culos del
Datawarehouse para obtener el código de identificación del articulo.
Ordenar por código: Ordena los campos en función del código de
devolución.
Filtro por cabeceras insertadas 6: Filtra aquellas lı́neas de devolución
de cliente de las cuales se han extraı́do las cabeceras.
Selecciono valores 8: Selecciona aquellos campos a insertar.
Insertar / Actualizar Lineas DevCli Inserta los datos a la tabla históri-
ca de LINEAS DEVOLUCIÓN CLIENTE del Datawarehouse.

71
8. TABLAS HECHOS DEVOLUCIONES PROVEEDOR

Figura 40: Transformación de las tablas de hechos Devoluciones Proveedor

Se definen los siguientes pasos:

CABECERA DEVOLUCIÓN PROVEEDOR: Extrae la información
de la tabla CABECERA DEVOLUCIÓN PROVEEDOR de InLOG
WMS.
Filtrar por fecha 5: Filtra aquellas filas en las que la fecha de alta de
la devolución en InLOG WMS es superior al 1/01/2021.
Insertar / Actualizar Cabecera DevPro Inserta los datos a la tabla
histórica de CABECERA DEVOLUCIÓN PROVEEDOR del Data-
warehouse.
LINEAS DEVOLUCIÓN PROVEEDOR: Extrae la información de
la tabla LINEAS DEVOLUCIÓN PROVEEDOR de InLOG WMS.
ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse.
Unir 12: Une las lineas de devolución proveedor con los artı́culos del
Datawarehouse para obtener el código de identificación del articulo.
Ordenar por código: Ordena los campos en función del código de
devolución.
Filtro por cabeceras insertadas 7: Filtra aquellas lı́neas de devolución
de proveedor de las cuales se han extraı́do las cabeceras.
Selecciono valores 9: Selecciona aquellos campos a insertar. Se elimi-
nan las referencias antiguas a los artı́culos y se añade el nuevo código
de identificación del artı́culo.
Insertar / Actualizar Lineas DevPro Inserta los datos a la tabla
histórica de LINEAS DEVOLUCIÓN PROVEEDOR del Datawa-
rehouse.

72
 9. TABLA HECHOS UBICACIONES DE PICKING

Figura 41: Transformación de las tablas de hechos Ubicación Picking

Se definen los siguientes pasos:

UBICACIÓN DE PICKING: Extrae la información de la tabla UBI-
CACIÓN DE PICKING de InLOG WMS.
ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse.
Unir 13: Une las ubicaciones de picking con los artı́culos del Datawa-
rehouse para obtener el código de identificación del articulo.
Ordenar por pasillo: Ordena las ubicaciones de picking en función del
pasillo para poder unir con la tabla pasillos.
Unir 14: Une las ubicaciones de picking con los pasillos del Datawa-
rehouse para obtener el código de identificación del articulo.
Selecciono valores: Selecciona aquellos campos a insertar. Se eliminan
las referencias antiguas a los artı́culos y pasillos y se añaden los nuevos
códigos de identificación del artı́culo y pasillo.
Insertar / Actualizar Ubicación de picking: Inserta los datos a la tabla
histórica de UBICACIÓN DE PICKING del Datawarehouse.
10. TABLA HECHOS UBICACIONES DE ALMACENAJE

Figura 42: Transformación de las tablas de hechos Ubicación de Almacenaje

Se definen los siguientes pasos:

73
 UBICACIÓN DE ALMACENAJE: Extrae la información de la tabla
UBICACIÓN DE ALMACENAJE de InLOG WMS.
ARTICULOS DWH: Extrae la información de la tabla ARTÍCULOS
del Datawarehouse.
Unir 15: Une las ubicaciones de almacenaje con los artı́culos del Da-
tawarehouse para obtener el código de identificación del articulo.
Ordenar por pasillo: Ordena las ubicaciones de almacenaje en función
del pasillo para poder unir con la tabla pasillos.
Unir 16: Une las ubicaciones de almacenaje con los pasillos del Da-
tawarehouse para obtener el código de identificación del articulo.
Selecciono valores: Selecciona aquellos campos a insertar. Se eliminan
las referencias antiguas a los artı́culos y pasillos y se añaden los nuevos
códigos de identificación del artı́culo y pasillo.
Insertar / Actualizar Ubicación de almacenaje: Inserta los datos a
la tabla histórica de UBICACIÓN DE ALMACENAJE del Datawa-
rehouse.
11. TABLA DIMENSIONES ALMACENES

Figura 43: Transformación de las tablas de dimensiones Almacenes

En esta tabla no es necesario realizar ninguna operación sobre los datos,

al cargarse toda la tabla en el Datawarehouse. Se definen los siguientes
pasos:

ALMACENES: Extrae la información de la tabla ALMACENES de

InLOG WMS.
Insertar / Actualizar Almacenes: Inserta los datos a la tabla de di-
mensión ALMACENES del Datawarehouse.

74
 12. TABLA DIMENSIONES CLIENTES Y PROVEEDORES

Figura 44: Transformación de las tablas de dimensiones Clientes y Proveedores

En estas tablas no es necesario realizar ninguna operación sobre los datos,

al cargarse toda la tabla en el Datawarehouse. Se definen los siguientes
pasos:
CLIENTES: Extrae la información de la tabla CLIENTES de InLOG
WMS.
Insertar / Actualizar Clientes: Inserta los datos a la tabla de dimen-
sión CLIENTES del Datawarehouse.
PROVEEDORES: Extrae la información de la tabla PROVEEDO-
RES de InLOG WMS.
Insertar / Actualizar Proveedores: Inserta los datos a la tabla de
dimensión PROVEEDORES del Datawarehouse.
13. TABLA DIMENSIONES OPERARIOS

Figura 45: Transformación de la tabla de dimensiones Operarios

Se definen los siguientes pasos:

OPERARIOS WMS: Extrae la información de la tabla OPERARIOS
de InLOG WMS.
OPERARIOS RRHH: Extrae la información de la tabla OPERA-
RIOS del sistema de recursos humanos.
Unir 5: Une la información de la tabla OPERARIOS extraı́da de
InLOG WMS y OPERARIOS extraı́da del sistema de recursos hu-
manos.
Selecciono valores 11: Selecciona aquellos campos a insertar, elimi-
nando aquellos campos del sistema de recursos humanos que no son
necesarios.
Insertar / Actualizar Operarios: Inserta los datos a la tabla de di-
mensión OPERARIOS del Datawarehouse.

75
 14. TABLAS DIMENSIONES PROPIETARIOS

Figura 46: Transformación de las tablas de dimensiones propietarios

En esta tabla no es necesario realizar ninguna operación sobre los datos,

al cargarse toda la tabla en el Datawarehouse. Se definen los siguientes
pasos:

PROPIETARIOS: Extrae la información de la tabla PROPIETA-

RIOS de InLOG WMS.
Insertar / Actualizar Propietarios: Inserta los datos a la tabla de
dimensión PROPIETARIOS del Datawarehouse.
15. TABLAS DIMENSIONES TIPOS MOVIMIENTO Y PEDIDO

Figura 47: Transformación de las tablas de dimensiones tipos movimiento y

pedido

En estas tablas no es necesario realizar ninguna operación sobre los datos,

al cargarse toda la tabla en el Datawarehouse. Se definen los siguientes
pasos:

TIPOS MOVIMIENTO: Extrae la información de la tabla TIPOS

MOVIMIENTO de InLOG WMS.
Insertar / Actualizar Tipos Movimiento: Inserta los datos a la tabla
de dimensión TIPOS MOVIMIENTO del Datawarehouse.
TIPOS PEDIDO: Extrae la información de la tabla TIPOS PEDIDO
de InLOG WMS.
Insertar / Actualizar Tipos Pedido: Inserta los datos a la tabla de
dimensión TIPOS PEDIDO del Datawarehouse.

76
 16. TABLAS DIMENSIONES TIPOS PEDIDO PROVEEDOR Y PALETA

Figura 48: Transformación de las tablas de dimensiones tipos pedido proveedor

y paleta

En estas tablas no es necesario realizar ninguna operación sobre los datos,

al cargarse toda la tabla en el Datawarehouse. Se definen los siguientes
pasos:
TIPOS PEDIDO PROVEEDOR: Extrae la información de la tabla
TIPOS PEDIDO PROVEEDOR de InLOG WMS.
Insertar / Actualizar Tipos Pedido Proveedor: Inserta los datos a
la tabla de dimensión TIPOS PEDIDO PROVEEDOR del Datawa-
rehouse.
TIPOS PALETA: Extrae la información de la tabla TIPOS PALETA
de InLOG WMS.
Insertar / Actualizar Tipos Paleta: Inserta los datos a la tabla de
dimensión TIPOS PALETA del Datawarehouse.

Una vez creadas las transformaciones, definimos los jobs para ejecutar el
proceso ETL.

En este caso, el job será muy sencillo, primero ejecutará transformación en

la que se cargaran los datos de todas las tablas de dimensiones de las cuales se
calcula un nuevo campo numérico de identificación, y después se ejecutará la
transformación en la que se cargarán los datos del resto de tablas de hechos y y
dimensiones al datawarehouse. Se enviará un correo electrónico informando del
resultado del proceso.

Figura 49: Job para la carga de datos

77
 Para lanzar los jobs, se ofrece junto a la aplicación Pentaho Data Integra-
tion utilizada para crear tanto las transformaciones como los jobs un módulo
llamado Kitchen.

Kitchen permite ejecutar jobs diseñados por Pentaho en formato .kjb, o alma-
cenados en un repositorio desde la consola de comandos. Para ello, es necesario
que todos los scripts de la aplicación Pentaho Data Integration tengan permi-
sos de ejecución. Para otorgar los permisos, ejecutamos el siguiente comando
estando situados en la carpeta de la aplicación: [30]
chmod +x * . sh
Ejecutando el script [Link] desde la consola de comandos podemos lanzar
los jobs:
sh k i t c h e n . sh [ o p t i o n s ]
Las opciones interesantes para este comando son las siguientes:
/file:[Link]
Lanza el job definido en [Link]
/logfile:archivoLog
Especifica un archivo donde guardar los logs de la ejecución. Si no se
especifica, se muestran en la consola de comandos.
/level:LogginLevel
Especifica el nivel de log.
En este caso, hemos situado tanto el fichero del job como de las transfor-
maciones en la carpeta de Pentaho Data Integration, y ejecutamos la carga de
datos con el siguiente comando:
sh k i t c h e n . sh / f i l e : ” I n l o g J o b . k j b ”

Figura 50: Ejecución del job principal mediante Kitchen

Para definir una carga de datos al Datawarehouse de manera periodica, ha-

remos uso del demonio de programación de tareas Cron y el comando ejecutado
anteriormente.

78
 Cron es un demonio que se encuentra de forma nativa en gran parte de las
distribuciones de Linux, el cual permite ejecutar comandos o scripts en función
la programación personalizada que le dé el usuario, con lo cual lo hace un de-
monio muy útil para automatizar tareas. [31]

Cron se configura mediante el fichero de texto crontab, donde se especifica

que procesos que deben ejecutarse y la hora a la que deben hacerlo. Para modi-
ficar el archivo crontab del usuario actual, ejecutamos el siguiente comando en
la consola de comandos: [32]
c r o n t a b =e
La sintaxis para determinar la tarea programada es la siguiente:
” minuto ” ” hora ” ” diames ” ” diasemana ” ”comando”
Disponemos además del carácter especial *, el cual representa el valor todo.
[32]

Para facilitar el proceso, crearemos el script run etl, el cual se encargará de

lanzar el job utilizando el comando Kitchen, y guardar los resultados en un log
cuyo nombre será la fecha actual y estará guardado en la carpeta logs situada
en la carpeta personal del usuario etl.

Figura 51: Script ejecución proceso ETL

En este caso, se ha decidió hacer la carga de datos todos los domingos a las
00:00, al ser un dı́a festivo en el que no suele haber movimientos en la base de
datos operativa. Con lo cual, el valor introducido en el archivo crontab será el
siguiente:
00 00 * * SUN sh /home/ e t l / r u n e t l . sh

Figura 52: Fichero Crontab

Con esto, se realizará la carga de datos al Datawarehouse todos los domingos,

logrando ası́ una carga periódica de los datos.

79
7.3. Implementación de los cubos OLAP
El primer paso para implementar los cubos es desarrollar la vista para la
dimensión tiempo.

Para obtener todas las fechas desde el 1 de enero de 2020 hasta un mes
después de la fecha del sistema en el momento de hacer la consulta haremos uso
de la siguiente función:
SELECT TO DATE( ’ 01/01/2020 ’ )+rownum=1 FECHA
FROM d u a l
CONNECT BY LEVEL <= (SELECT TRUNC(SYSDATE+30=TO DATE( ’ 01/01/2020 ’ ) )
FROM DUAL)
El siguiente paso será definir una consulta que calcule los distintos atributos
de las fechas obtenidas con la función anterior utilizando la función EXTRACT
definida en PLSQL, la cual permite extraer los valores de diferentes elementos
de un dato de tipo DATE (YEAR, MONTH, DAY...), y el procedimiento al-
macenado CALCULA FESTIVO, el cual determina si una fecha es festivo o no
haciendo uso de la tabla auxiliar FESTIVOS, tabla en la que el cliente puede
insertar los dı́as que considera como festivos, y teniendo en cuenta sábados y
domingos como festivos.

Una vez creada la consulta, creamos una vista sobre esta utilizando la función
CREATE OR REPLACE VIEW.

Figura 53: Consulta Vista Tiempo

80
 La implementación de los cubos se realizará mediante la herramienta Pen-
taho Schema Workbench (PSW) incluida en la suite de Pentaho.

Esta herramienta permite implementar y probar los cubos OLAP de una

manera gráfica, generando un fichero .xml donde se define la estructura de los
cubos y las conexiones a la base de datos, ofreciendo además la posibilidad de
publicarlos en la aplicación web directamente desde la aplicación

En Schema Workbench, todos los cubos y dimensiones compartidas forman

parte de un Schema, con lo cual, el primer paso es generar un schema nuevo.
Las operaciones que ofrece sobre un schema son las siguientes:

Figura 54: Operaciones sobre un schema

El primer paso es generar las dimensiones compartidas. Para ello, tenemos la

opción “Add Dimension”. Las dimensiones pueden ser de dos tipos, Standard-
Dimension, TimeDimension, siendo este último tipo utilizado para la dimensión
tiempo.

Una vez creada la dimensión, es necesario crear las jerarquı́as de la dimensión

utilizando la opción Add “Hierarchi”, ofrecida para la dimensión, y dentro de
esta definir la tabla que forma la dimensión “Add Table”, y los distintos niveles
de la dimensión utilizando la opción “Add Level”

Figura 55: Operaciones sobre jerarquı́a de una dimensión

Una vez creadas las dimensiones compartidas, creamos los cubos utilizando
la opción “Add cube”. Las opciones que sobre un cubo son las siguientes:

81
 Figura 56: Operaciones sobre un cubo

Para cada cubo, definimos las dimensiones utilizando “Add Dimensión”, o

en caso de ser una dimensión compartida, utilizando “Add Dimension Usage.
Se definen las tabla de hechos del cubo utilizando “Add Table”, y se añaden las
medidas utilizando “Add Measure”.

Para cada dimensión del cubo es necesario indicar en sus atributos cual es
el campo de la tabla de hechos que se relaciona con la dimensión.

Figura 57: Atributos de una dimensión

82
El schema queda definido de la siguiente manera:

Figura 58: Schema con los cubos y dimensiones compartidas

83
7.4. Implementación de informes predefinidos
La implementación de los informes se realizará mediante la herramienta Pen-
taho Report Designer (PRD) incluida en la suite de Pentaho.

Esta herramienta permite diseñar los informes de una forma gráfica y ejecu-
tarlos directamente desde la propia herramienta en múltiples formatos (PDF,
HTML, XLS y CSV) o publicarlos en la aplicación web para poder lanzarlos
desde esta. [33]

El primer paso es definir la fuente de datos de la cual se obtendrán los datos

a mostrar en el informe. Para ello, se utiliza la opción “Data / Add Datasource
/ JDBC”.

Figura 59: Añadir fuente de datos en Report Designer

Se mostrará una ventana en la que se permitirá establecer la conexión con la

base de datos y definir la sentencia SQL con la que se obtendrán los diferentes
datos. En caso de tener una condición definida por un parámetro, esta se incluirá
en la clausula WHERE de la forma ${PARAMETRO}

Figura 60: Creación de sentencia del informe

84
 Una vez definida la fuente de datos, comenzamos a diseñar el informe. Para
ello, disponemos de un workspace de diseño, en el cuál, podremos añadir aquellos
elementos necesarios para diseñar el informe.

Figura 61: Workspace diseño de informe

Este workspace está dividido en varias categorı́as. [34]

Page Header: Representa la cabecera de cada una de las páginas del in-
forme. [34]
Report Header: Representa la cabecera del informe, mostrándose única-
mente en la primera página del informe. [34]

Group Header: Representa la cabera de los grupos de información definidos

en el informe, en caso de trabajar con estos. [34]
Details: Formada por Details Header, Details y Details Footer, representa
los datos del informe. Contiene la información fila por fila recuperada de
la base de datos. [34]
Group Footer: Representa el pie de los grupos de información definidos en
el informe, en caso de trabajar con estos. [34]
Report Footer: Representa el pie del informe, mostrándose únicamente en
la última página del informe. [34]

Page Footer: Representa el pie de cada página del informe. [34]

85
 Disponemos además de un panel de datos, en el cual podremos definir campos
calculados a partir de una fórmula, y los parámetros del informe:

Para definir un parámetro, hacemos clic sobre “Parameters / Add Para-

meter”. Se abrirá una ventana para definir la estructura del parámetro.
Para definir un campo calculado, hacemos clic sobre “Functions / Add
Function”, y se abrirá una ventana para definir el tipo y la fórmula a
aplicar.

Figura 62: Panel de datos en Report Designer

86
7.5. Despliegue de la aplicación web
El corazón de Pentaho es la aplicación web, la cual será la forma en la que
los clientes podrán utilizar los distintos recursos desarrollados de una forma sen-
cilla. Está desarrollada en Java EE con el framework Spring. Al ser open source,
podemos modificar y personalizar todas las caracterı́sticas de esta. [26]

Para realizar las modificaciones sobre la aplicación, importaremos el proyecto

de la aplicación web a un IDE para poder trabajar de forma local sobre él. En
este caso, utilizaremos Eclipse IDE for Enterprise Java and Web Developers.

Figura 63: Organización del proyecto en Eclipse

La mayorı́a de los componentes de Pentaho, como el visor de informes pre-

definidos, motor OLAP, herramienta de edición y visor de cuadros de mandos se
encuentran en pentaho-solutions, mientras que los elementos web se encuentran
en tomcat/webapps.

La pantalla de login está definida en tomcat/webapps/pentaho/jsp/PUCLo-

[Link], y la pantalla de la consola principal está definida en tomcat/webapps/-
pentaho/mantle/home/content/welcome/[Link]. Modificaremos ambas pan-
tallas para obtener la apariencia deseada.

Además, por defecto Pentaho solo está disponible en inglés, por lo que modi-
ficaremos todos los textos de los distintos elementos web a utilizar para traducir
la aplicación a castellano. En la mayorı́a de los componentes de Pentaho tene-
mos una carpeta messages en la que se encuentran los textos y en el caso de los
elementos web modificaremos los jsp y html para traducir la aplicación.

87
7.5.1. Conexión de la aplicación con el Datawarehouse
Para poder hacer uso de los cubos e informes predefinidos es necesario co-
nectar la aplicación web con el Datawarehouse.

Para ello, crearemos una nueva conexión desde la consola principal de la

aplicación haciendo clic sobre el la opción “Gestionar Fuente de Datos”. Se
mostrará la pantalla para la administración de fuentes de datos.

Figura 64: Pantalla administración de fuentes de datos

En esta pantalla se podrán crear y gestionar las diferentes fuentes de datos

con las que trabajará la aplicación, pudiendo crear nuevas conexiones a base de
datos, importar los schemas de los cubos o crear/importar metadatos para los
informes ad-hoc.

Para crear la conexión con el Datawarehouse, hacemos clic sobre Nueva

conexión y se abrirá un asistente para realizar la configuración. Definiremos una
nueva conexión llamada DWH.

Figura 65: Asistente creación de conexión a base de datos

88
7.5.2. Despliegue de los cubos OLAP
Para desplegar el cubo OLAP en el servidor web, podemos realizarlo di-
rectamente desde la aplicación Schema Workbench en la que se definieron los
[Link] ello, teniendo el schema de los cubos abiertos, hacemos clic en File
/ Publish

Figura 66: Asistente publicación cubos OLAP

Introducimos la dirección del servidor Pentaho, usuario y contraseña del

usuario administrador, el nombre de la conexión a la base de datos definida (en
este caso, hemos definido la conexión DWH en el punto anterior) y pulsamos en
el botón “Publish” para publicar el schema de los cubos en el servidor.

Una vez publicados, podremos ver una nueva fuente de datos del tipo Analy-
sis definida en la pantalla de gestión de fuentes de datos correspondiente al
schema de los cubos.

Figura 67: Fuente de datos cubos OLAP

Para poder realizar consultas contra los cubos de una forma visual, se inclu-
ye con Pentaho el visor JPivot. JPivot es una librerı́a de componentes JSP que
se utiliza para generar tablas OLAP de una forma gráfica. [35]

Al quedar JPivot descontinuado, surgió una nueva librerı́a llamada Pivot4j,

basado en JPivot, la cual es una herramienta bastante más amigable a la hora
de generar las tablas OLAP. [36]

Pivot4j está disponible tanto como una aplicación web independiente, como
un plugin para instalar en Pentaho, el cual se integra con la aplicación web.
Este plugin se puede descargar desde el Github del desarrollador, o empleando
el Marketplace incluido en el servidor de Pentaho.

89
 Para instalar el plugin, clonamos el proyecto git en la carpeta pentaho-
solutions/system y reiniciamos el servidor. Para ello, haremos un git-clone del
proyecto empleando la herramienta TortoiseGit.

Figura 68: Clonación del proyecto Pivot4J

Una vez reiniciado el servidor, aparecerá una opción correspondiente a Pi-

vot4J View en el menú Crear Nuevo. Modificamos el fichero de propiedades
[Link] ubicando en la carpeta del plugin para cambiar el nombre del menú
por Visor OLAP.

La generación del menú Crear Nuevo se realiza dinámicamente en el fi-

chero pentaho-server/tomcat/webapps/pentaho/mantle/home/js/[Link].
Modificaremos este fichero para dejar de mostrar la opción correspondiente a el
antiguo visor OLAP JPivot.

Figura 69: Vista Menú Crear nuevo

90
 Con este visor, podemos crear las consultas MDX contra los cubos definidos
anteriormente de una forma gráfica.

Figura 70: Consulta contra cubo Cabecera Pedido Compra

7.5.3. Despliegue de la herramienta para consultas ad-hoc

La versión Community de Pentaho no ofrece ninguna caracterı́stica para ex-
plotar los metadatos del Datawarehouse realizando consultas ad-hoc, es por ello
que es necesario realizar un plugin que permita hacer estas consultas contra el
Datawarehouse de una forma sencilla.

Para realizar este plugin, nos hemos basado en el plugin WAQE (Web Adhoc
Query Executor) desarrollado por Jortilles, el cual estuvo disponible hasta la
versión 7 de Pentaho. Este plugin tiene una licencia open source que permite
tratar el software sin restricciones y todo el código está disponible para ser mo-
dificado en el Github del creador.

Este plugin está desarrollado mediante la herramienta Sparkl, incluida en la

aplicación web de Pentaho, la cual permite desarrollar plugins de una manera
similar a como se desarrolları́a un cuadro de mando, siendo los plugins realiza-
dos con Sparkl un conjunto de cuadros de mando.

Para instalar el plugin, haremos al igual que con el visor OLAP, un git-clone
del proyecto Github en la carpeta pentaho-solutions/system y reiniciaremos el
servidor.

91
 WAQE está formado por un único cuadro de mando basado en el frame-
work Bootstrap. La parte visual de este plugin está diseñada principalmente
utilizando componentes HTML, Javascript y CSS, mientras que la lógica de ge-
neración de las consultas SQL y su guardado / exportación está implementada
en Javascript y Java respectivamente.

Figura 71: Herramienta para el desarrollo de Plugins

Para el desarrollo de los cuadros de mando utilizaremos la herramienta Com-

munity Dashboard Editor incluida en la aplicación web de Pentaho. Esta herra-
mienta se abrirá automáticamente al comenzar a modificar el cuadro de mando
del plugin.

El desarrollo de un cuadro de mando se divide en tres componentes Layout,

Components y Datasources. [37]
Layout: Es la representación gráfica de los datos. Se define el diseño y
la estructura del cuadro de mando, haciendo uso de estilos css, código
javascript y html
Components: Se definen los componentes con los que se mostrarán los
datos obtenidos por base de datos (checkbox, cuadros de selección, gráfi-
cas...)
Datasources: Se definen las consultas a realizar contra la base de datos

Figura 72: Componentes de un cuadro de mando

El primer paso, será modificar el layout para obtener la vista deseada. En

cuanto a este, tenemos los siguientes componentes:
Fila cabecera: Se encuentran los botones Exportar a Excel y Guardar
Consulta
Fila principal: Compuesta por dos columnas: columna de selección de da-
tos, en la que se permite al usuario seleccionar los datos a consultar y
resultados de consulta, en la que se muestra la consulta realizada.

92
 Popup filtros: Al pulsar sobre una columna en la selección de datos, se
abre un popup permitiendo al usuario introducir unos filtros sobre esa
columna
Gran parte del contenido de la fila principal y del popup es generado dinámi-
cante mediante el fuente [Link] ubicado en waqe/static/cus-
tom/js.

Además de modificar la parte visual, al tener clientes con un gran volumen

de datos en sus bases de datos, es necesario limitar las consultas a un número
máximo de registros, para evitar que consultas sin filtros puedan colapsar la apli-
cación durante un gran tiempo, por ello, modificaremos la lógica de generación
de SQL implementada en el fuente [Link] ubicado en waqe/static/custom/js,
añadiendo un lı́mite de 1000 registros por consulta.

Para aplicar filtros sobre un campo, se abre un popup al hacer clic sobre
el campo a filtrar. En este popup, se muestra una columna con los valores del
campo disponibles y se va seleccionando en esta columna los valores deseados
haciendo clic sobre estos. A la hora de aplicar filtros sobre campos con una gran
cantidad de datos este método no es práctico, pues deberı́an buscar manualmen-
te entre miles de datos. Para ello, modificaremos el popup de filtros añadiendo
un campo de texto con el que se permitirá añadir un valor manualmente.

El primer paso será modificar el HTML que compone el popup para añadir
un campo de texto donde se introducirá manualmente el valor, y un botón para
añadir el filtro.

Figura 73: Código HTML del popup para aplicar filtros

Una vez modificada la parte visual, es necesario modificar la lógica corres-

pondiente al popup para gestionar la nueva funcionalidad. Esta se encuentra en
waqe/static/custom/js/[Link].

93
Realizaremos los siguientes cambios:
Crearemos un array llamado [Link] donde guardaremos los fil-
tros introducidos manualmente
Modificaremos la función [Link], la cual se ejecuta al abrir el popup de
los filtros. Vaciaremos el cuadro de texto y añadiremos un evento onclick
sobre el botón Añadir para añadir el filtro introducido.

Figura 74: Implementación de la función [Link]

Modificaremos la función [Link], la cual se ejecuta tras añadir /

borrar un filtro, y se encarga de añadir los filtros seleccionados a la consulta
SQL a generar. Trataremos también los filtros introducidos manualmente
en la lista [Link].

Figura 75: Implementación de la función [Link]

94
 Modificaremos la función [Link], la cual se ejecuta para borrar
un filtro. Consultaremos si el filtro a borrar está en la lista de filtros
añadidos manualmente, para eliminarlo en ese caso.

Figura 76: Implementación de la función [Link]

El resultado final es el siguiente:

Figura 77: Popup selector de filtros

95
7.5.4. Creación de metadatos para consultas ad-hoc
Una vez implementada la herramienta que nos permitirá realizar las con-
sultas ad-hoc, el siguiente paso es definir los metadatos sobre los que haremos
la consultas. Para ello, utilizaremos la herramienta Pentaho Metadata Editor
(PME) incluida en la suite de Pentaho.

Pentaho Metadata Editor es una herramienta de escritorio que permite de-

sarrollar de forma gráfica los dominios y modelos de metadatos. Un dominio, el
cual se genera como un fichero .xmi, representa todos los modelos de metadatos
que tienen alguna entidad común. [38]

El primer paso es definir la conexión a la base de datos, para ello, haremos

clic en File / New / Connection e introduciremos los datos de conexión a el
Datawarehouse, de una manera similar a la definición de la conexión realizada
en las herramientas Pentaho Report Designer, Schema Workbench y Pentaho
Data Integration.

Una vez creada la conexión al Datawarehouse, el siguiente paso es importar

las tablas necesarias para formar los distintos modelos de datos. Para ello, desde
la conexión creada haremos clic en la opción “Import From Explorer”

Figura 78: Opciones sobre conexión en la herramienta PME

Se mostrará el esquema de base de datos, permitiendo seleccionar aquellas

tablas que formarán los diferentes modelo de datos a definir.

96
 Figura 79: Busqueda de tablas a importar en la herramienta PME

Una vez importadas las tablas, podremos modificar sus caracterı́sticas pa-
ra añadir un nombre personalizado a los campos que se mostrarán desde la
aplicación de consultas, crear campos calculados . . .

Figura 80: Modificación de tabla ARTICULOS en la herramienta PME

Una vez modificadas todas las tablas importadas, creamos un nuevo modelo
de datos haciendo clic en Business Models / New Business Model. Crearemos
los siguientes modelos de datos: Compras, Ventas, Maestros y Control.

Una vez creado el modelo de datos, arrastraremos todas las tablas necesarias
para crear el modelo de datos a el área grafica. Definimos las relaciones entre
las tablas haciendo clic en New Relationship. . .

97
 Figura 81: Asistente para la definición de relaciones entre tablas

Por cada relación será necesario definir:

Tablas que forman la relación

Campos relacionados (en caso de ser una unión compuesta por varios
campos, se realiza declarando la fórmula en Complex Join)
Cardinalidad de la relación: 1:N, N:1, 1:1 ...

Tipo de relación: Inner (intersección entre ambas tablas) u outer (unión

entre ambas tablas).
Una vez definidos los modelos de metadatos, la aplicación ofrece una opción
para subir directamente el dominio a la aplicación web, haciendo clic en File
/ Publish To Server. Introduciendo los datos de acceso al servidor, subimos el
fichero .xmi a la aplicación.

98
 Figura 82: Asistente publicación dominio de metadatos

Una vez importado, podremos ver una nueva fuente de datos del tipo me-
tadata definida en la pantalla de gestión de fuentes de datos correspondiente al
dominio de metadatos.

Figura 83: Fuente de datos dominio de metadatos

Utilizando la herramienta de consultas ad-hoc desplegada anteriormente y los

metadatos desarrollados, podemos realizar consultas contra el Datawarehouse
de una forma sencilla.

Figura 84: Ejemplo de consulta sobre pedidos de compra

99
7.5.5. Despliegue de informe predefinidos
Para desplegar los informes predefinidos en el servidor web, podemos reali-
zarlo directamente desde la aplicación Pentaho Report Designer, haciendo clic
en File / Publish por cada uno de los informes a desplegar.

Figura 85: Asistente publicación de informe

Será necesario introducir la dirección del servidor pentaho, usuario y contra-

seña del usuario administrador para subir el informe a la aplicación web. Tras
introducir los datos, se abrirá un asistente para seleccionar la ruta del servidor
donde se guardará el informe.

Figura 86: Selección ruta para publicación de informe

El informe será accesible desde la web haciendo clic en Ficheros y buscando

el informe en la carpeta donde se ha guardado anteriormente.

100
 Figura 87: Búsqueda informes en la aplicación web

Seleccionando el informe deseado se abre mediante el componente Pentaho

Reporting incluido en la aplicación web, en el cual se podrá seleccionar los
parámetros para generar el informe y lanzarlo en múltiples fuentes de datos,
como HTML (visualizado en la propia herramienta), PDF y CSV.

Figura 88: Ejemplo informe paletas caducadas

7.5.6. Instalación de la aplicación BI

Una vez desarrolladas todas las caracteristicas de la aplicación web, subire-
mos esta al servidor.

101
 Para ello, copiaremos mediante el comando SCP el contenido de la carpeta
pentaho-server en nuestro servidor. Para poder utilizar el comando SCP en
Windows, utilizaremos el bash de Linux incluido en las últimas versiones de
Windows 10. Situándonos en la carpeta pentaho-server, ejecutamos el siguiente
comando:
s c p = r $PWD u s u a r i o @ s e r v i d o r : / r u t a D e s t i n o
En este caso, instalaremos la aplicación web en la carpeta home del usuario
SERVER.

Figura 89: Subida de la aplicación web al servidor

Accediendo desde ssh a la maquina con el usuario server, podemos comprobar

que se ha subido la aplicación web correctamente:

Figura 90: Comprobación subida de la aplicación web al servidor

Antes de lanzar el servidor, es necesario modificar el puerto en el que se

lanzará el servidor, ya que por defecto Pentaho se lanza en el servidor 8080, y
en el caso de esta máquina, este puerto lo tiene ocupado por otra aplicación
por lo que será necesario lanzarlo en otro puerto, en este caso el puerto 5000.
Para ello, tenemos que modificar el fichero de configuración del servidor Tomcat
ubicado en pentaho-server/tomcat/conf

102
 Figura 91: Configuración puerto de la aplicación web Pentaho

Para lanzar el servidor, ubicándonos en la carpeta pentaho-server ejecutamos

el siguiente comando:
. / s t a r t =pentaho . sh
Tras ejecutar el comando, se lanzará el servidor Tomcat de la aplicación
web. Una vez lanzado el servidor, accedemos desde el navegador a la dirección
ipServidor:5000/pentaho. Se mostrará la pantalla de login de Pentaho

Figura 92: Pantalla login aplicación web Pentaho

Para parar el servidor, ubicándonos en la carpeta pentaho-server ejecutamos

el siguiente comando:
. / stop =pentaho . sh

103
8. Evaluación
Durante el desarrollo del proyecto, se han sometido las diferentes funciona-
lidades a una serie de pruebas para comprobar el buen funcionamiento de la
solución.

Las funcionalidades a probar son las siguientes:

Proceso ETL
Medidas de los cubos OLAP

Informes ad-hoc
Para realizar las pruebas, se ha utilizado un entorno de desarrollo, el cual es
un reflejo del entorno de producción pero con un número pequeño y limitado de
datos para facilitar las pruebas. Esto es necesario ya que en caso de realizar las
pruebas contra el entorno de producción en un periodo de trabajo, los datos se
modificarı́an constantemente haciendo imposible realizar pruebas contra estos.

8.1. Evaluación del proceso ETL

El proceso de carga de datos al Datawarehouse es uno de los procesos más
importantes del proyecto, ya que una mala carga de datos puede suponer que
se muestren datos erróneos en el resto de funcionalidades.

Por un lado, comprobaremos que el número de registros cargados a cada

tabla de hechos y dimensiones sea correcto, comparándolo con el número de
registros en la base de datos operacional.

Por otro lado, al haberse realizado cambios sobre las claves primarias de
ARTICULOS, AREA DESCARGA y PASILLO, añadiendo un campo numéri-
co secuencial como clave, será necesario comprobar que las referencias a estas
entidades realizadas en las tablas de hechos sean correctas y correspondan a la
entidad original.

Debido a la gran importancia del proceso y para facilitar futuras imple-

mentaciones en distintos clientes en los que se pueda modificar ligeramente el
proceso de carga de datos para añadir otras entidades, se han implementado
unas pruebas unitarias automáticas haciendo uso de JUnit para poder compro-
bar rápidamente si el proceso de carga de datos funciona correctamente.

Se realizarán las siguientes pruebas:

1. Primera carga de datos completa, teniendo todas las tablas del Datawa-
rehouse vacias.
Ejecutando las pruebas unitarias, comprobamos que la primera carga de
datos al Datawarehouse se ha realizado correctamente. Por cada prueba
ejecutada, se observa el resultado obtenido y el tiempo que ha tardado en
ejecutarse:

104
 Figura 93: Resultado pruebas unitarias primera carga de datos

2. Carga de datos incremental, dando de alta en el sistema al menos un nuevo

artı́culo, área de descarga y pasillo. Crearemos un pedido de compra cuyo
área de descarga sea la nueva creada, y que entre sus lineas tenga al menos
una referencia al nuevo articulo. Además, crearemos al menos una nueva
ubicación de picking con el nuevo pasillo y volveremos a realizar la carga
de datos.
Ejecutando las pruebas unitarias, podemos ver que la carga de datos se
ha realizado correctamente, tratando correctamente los nuevos datos in-
troducidos.

Figura 94: Resultado pruebas unitarias carga de datos incremental

105
8.2. Evaluación medidas cubos OLAP
Una vez comprobada que la carga de datos al Datawarehouse es correcta, el
siguiente paso es comprobar que el cálculo de las medidas por cada uno de los
cubos OLAP es correcto.

Para realizar las comprobaciones, se calculará por un lado los valores de las
medidas de los cubos manualmente contra el Datawarehouse haciendo uso de
consultas SQL desde PLSQL Developer, y se compararán estos valores con los
obtenidos por las consultas MDX contra los cubos generadas en el visor OLAP.

Los resultados obtenidos son los siguientes:

1. CUBO MOVIMIENTOS

La consulta SQL a realizar para obtener el cálculo de las medidas es la

siguiente:
SELECT COUNT( 1 ) NUMEROS MOVIMIENTOS
,COUNT(DISTINCT MVM OPERAR) OPERARIOS DIFERENTES
,COUNT(DISTINCT MVM ARTIDE) ARTICULOS DIFERENTES
,SUM(MVM CANTID) CANTIDAD
FROM H MOVIMIENTOS;

Figura 95: Resultado medidas cubo movimientos mediante consulta SQL

Realizando la consulta MDX desde el visor OLAP obtenemos el siguiente

resultado:

Figura 96: Resultado medidas cubo movimientos mediante consulta MDX

Comparando los resultados obtenidos mediante ambas consultas, obtene-

mos los siguientes resultados:

106
 Consulta SQL Consulta MDX Resultado
Número movimientos 1945 1945 Correcto
Operarios diferentes 4 4 Correcto
Artı́culos diferentes 380 380 Correcto
Cantidad 4.248.495 4.248.495 Correcto
Tabla 38: Resultado pruebas medidas del cubo movimientos

2. CUBO PALETAS

La consulta SQL a realizar para obtener el cálculo de las medidas es la

siguiente:
SELECT COUNT( 1 ) NUMERO PALETAS
,COUNT(DISTINCT PAL ARTIDE) ARTICULOS DIFERENTES
,SUM(PAL STOCPA) STOCK PALETA
,COUNT(PAL MOVFEC) NUM MOVIMIENTOS
,MIN(PAL STOCPA) STOCK MINIMO
,MAX(PAL STOCPA) STOCK MAXIMO
FROM H PALETAS ;

Consulta SQL Consulta MDX Resultado

Número paletas 6345 6345 Correcto
Artı́culos diferentes 3419 3419 Correcto
Stock paleta 4.714.587 4.714.587 Correcto
Número movimientos 1 1 Correcto
Stock mı́nimo 0 0 Correcto
Stock máximo 1.246.600 1.246.600 Correcto
Tabla 39: Resultado pruebas medidas del cubo paletas

3. CUBO CABECERA PEDIDO DE COMPRA

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT SUM(CPC COSTE) COSTE
,COUNT(DISTINCT CPC PROVEE) NUM PROVEEDORES
,AVG(CPC COSTE) MEDIA COSTE
,SUM(CPC NUMPAL) NUMERO PALETAS
,COUNT(DISTINCT CPC USUARI) NUM OPERARIOS
,COUNT( 1 ) NUMERO PEDIDOS
FROM H CABEC PEDCOM;

107
 Consulta SQL Consulta MDX Resultado
Coste 510 510 Correcto
Proveedores diferentes 3 3 Correcto
Media coste 3 3 Correcto
Número paletas 1383 1383 Correcto
Operarios diferentes 5 5 Correcto
Número pedidos 170 170 Correcto
Tabla 40: Resultado pruebas medidas del cubo cabecera pedido de
compra

4. CUBO LINEAS PEDIDO DE COMPRA

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT SUM(LPC CANTEO) CANT PEDIDA
,SUM(LPC CANREA) CANT RECIBIDA
,SUM(LPC NUMPAL) NUM PALETAS
,COUNT( 1 ) NUM LINEAS
,COUNT(DISTINCT LPC PEDIDO) NUM PEDIDOS
,COUNT(DISTINCT LPC ARTIDE) NUM ARTICULOS
FROM H LINEAS PEDCOM ;

Consulta SQL Consulta MDX Resultado

Cantidad pedida 1.717.381 1.717.381 Correcto
Cantidad recibida 1.206.898 1.206.898 Correcto
Número paletas 1383 1383 Correcto
Número lineas 355 355 Correcto
Número pedidos 170 170 Correcto
Artı́culos diferentes 48 48 Correcto
Tabla 41: Resultado pruebas medidas del cubo lineas pedido de
compra

5. CUBO CABECERA PEDIDO DE VENTA

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT SUM(CPV PRECIO) COSTE
,AVG(CPV PRECIO) MEDIA COSTE
,SUM(CPV NUMPAL) NUM PALETAS
,COUNT( 1 ) NUM PEDIDOS
,COUNT(DISTINCT CPV CLIENT) NUM CLIENTES
,SUM(CPV PESOPC) PESO PC
,SUM(CPV PESOPK) PESO PK
,SUM(CPV VOLUPC) VOL PC
,SUM(CPV VOLUPK) VOL PK
FROM H CABEC PEDVEN;

108
 Consulta SQL Consulta MDX Resultado
Coste 605 605 Correcto
Media coste 5 5 Correcto
Número paletas 22 22 Correcto
Número pedidos 121 121 Correcto
Clientes diferentes 5 5 Correcto
Peso paletas completas 105.950 105.950 Correcto
Peso picking 6.604.230 6.604.230 Correcto
Volumen paletas com-
186.680 186.680 Correcto
pletas
Volumen picking 21.894.048 21.894.048 Correcto
Tabla 42: Resultado pruebas medidas del cubo cabecera pedido de
venta

6. CUBO LINEAS PEDIDO DE VENTA

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT SUM(LPV CANPED) CANT PEDIDA
,SUM(LPV CANSER) CANT SERVIDA
,COUNT (DISTINCT LPV ARTIDE) NUM ARTICULOS
,COUNT (DISTINCT LPV PEDIDO | | LPV DIVPED) NUM PEDIDOS
FROM H LINEAS PEDVEN ;

Consulta SQL Consulta MDX Resultado

Cantidad pedida 28.179 28.179 Correcto
Cantidad servida 29.614 29.614 Correcto
Artı́culos diferentes 28 28 Correcto
Número pedidos 121 121 Correcto
Tabla 43: Resultado pruebas medidas del cubo lı́neas pedido de
venta

7. CUBOS CABECERA DEVOLUCIÓN CLIENTE/PROVEEDOR

La consulta SQL a realizar para obtener el cálculo de las medidas del cubo
cabecera devolución cliente es la siguiente:
SELECT COUNT(DISTINCT CDC CLIENT) NUM CLIENTES
,COUNT(DISTINCT CDC OPEAUT) NUM OPERARIOS
,COUNT(DISTINCT CDC MUELLE) NUM MUELLES
,COUNT( 1 ) NUM DEVOLUCIONES
FROM H CABEC DEVCLI ;

109
 La consulta SQL a realizar para obtener el cálculo de las medidas del cubo
cabecera devolución proveedor es la siguiente:
SELECT COUNT(DISTINCT CDP PROVEE) NUM PROVEEDORES
,COUNT(DISTINCT CDP OPEDEV) NUM OPERARIOS
,COUNT(DISTINCT CDP MUELLE) NUM MUELLES
,COUNT( 1 ) NUM DEVOLUCIONES
FROM H CABEC DEVPRO;

Consulta Consulta Consulta

Consulta
MDX SQL Pro- MDX Resultado
SQL Cliente
Cliente veedor Proveedor
Cli/Prov diferentes 1 1 2 2 Correcto
Operarios diferen-
3 3 3 3 Correcto
tes
Muelles 2 2 3 3 Correcto
Número devolucio-
4 4 3 3 Correcto
nes
Tabla 44: Resultado pruebas medidas del cubo cabecera devolución
cliente/proveedor

8. CUBO LINEAS DEVOLUCIÓN CLIENTE

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT SUM(LDC CANTOT) CANT TOTAL
,SUM(LDC CANTAP) CANT APTA
,SUM(LDC CANTNA)
,COUNT(DISTINCT LDC OPERAR) NUM OPERARIOS
,COUNT(DISTINCT LDC ARTIDE) NUM ARTICULOS
FROM H LINEAS DEVCLI ;

Consulta SQL Consulta MDX Resultado

Cantidad total 333 333 Correcto
Cantidad apta 293 293 Correcto
Cantidad no apta 40 40 Correcto
Número operarios 2 2 Correcto
Artı́culos diferentes 3 3 Correcto
Tabla 45: Resultado pruebas medidas del cubo lı́neas devolución
cliente

110
9. CUBO LINEAS DEVOLUCIÓN PROVEEDOR
La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT SUM(LDP CANTID) CANTID
,COUNT(DISTINCT LDP PALETA) NUM PAL
,COUNT(DISTINCT LDP ARTIDE) NUM ARTICULOS
,COUNT(DISTINCT LDP OPERAR) NUM OPERARIOS
FROM H LINEAS DEVPRO ;

Consulta SQL Consulta MDX Resultado

Cantidad 25 25 Correcto
Número paletas 5 5 Correcto
Artı́culos diferentes 3 3 Correcto
Número operarios 2 2 Correcto
Tabla 46: Resultado pruebas medidas del cubo lı́neas devolución
proveedor

10. CUBO ORDENES DE PALETA COMPLETA

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT COUNT(DISTINCT OPC ARTIDE) NUM ARTICULOS
,SUM(OPC CANPAL) CANT PALPED
,SUM(OPC CANREC) CANT RECIBIDA
,COUNT(DISTINCT OPC OPERAR) NUM OPERARIOS
FROM H ORDENES PC ;

Consulta SQL Consulta MDX Resultado

Artı́culos diferentes 7 7 Correcto
Cantidad paletas pedi-
1059 1059 Correcto
das
Cantidad recibida 245 245 Correcto
Número operarios 2 2 Correcto
Tabla 47: Resultado pruebas medidas del cubo ordenes de paleta
completa

11. CUBO ORDENES DE PICKING

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT COUNT(DISTINCT OPK PEDIDO | | OPK DIVPED) NUM PEDIDOS
,COUNT(DISTINCT OPK OPERAR) NUM OPERARIOS
,SUM(OPK TOTLIN) NUM LINEAS
,SUM(OPK NUMCON) NUM CONTEN
,SUM(OPK VOLCON) VOL CONTEN, SUM(OPK PESCON) PES CONTEN
FROM H ORDENES PK ;

111
 Consulta SQL Consulta MDX Resultado
Número pedidos 80 80 Correcto
Operarios diferentes 3 3 Correcto
Número de lı́neas 408 408 Correcto
Número de contenedo-
820 820 Correcto
res
Volumen contenedores [Link] [Link] Correcto
Peso contenedores 662.295.000 662.295.000 Correcto
Tabla 48: Resultado pruebas medidas del cubo ordenes de picking

12. CUBO LÍNEAS DE PICKING

La consulta SQL a realizar para obtener el cálculo de las medidas es la
siguiente:
SELECT SUM(LPK CANTID) CANT PEDIDA
,SUM(LPK CANREC) CANT SERVIDA
,COUNT(DISTINCT LPK ARTIDE) NUM ARTICULOS
FROM H LINEAS PK ;

Consulta SQL Consulta MDX Resultado

Cantidad pedida 23.179 23.179 Correcto
Cantidad servida 15.010 15.010 Correcto
Artı́culos diferentes 25 25 Correcto
Tabla 49: Resultado pruebas medidas del cubo lı́neas de picking

13. CUBOS UBICACIÓN DE PICKING/ALMACENAJE

La consulta SQL a realizar para obtener el cálculo de las medidas del cubo
ubicación de picking es la siguiente:
SELECT SUM( UPI PALUBI ) NUM PALUBI
,COUNT(DISTINCT UPI ARTIDE) NUM ARTICULOS
FROM H UBIC PICKING ;

La consulta SQL a realizar para obtener el cálculo de las medidas del cubo
ubicación de almacenaje es la siguiente:
SELECT SUM(UAL PALUBI) NUM PALUBI
,COUNT(DISTINCT UAL ARTIDE) NUM ARTICULOS
FROM H UBIC ALMAC ;

112
 Consulta Consulta Consulta
Consulta
MDX SQL Al- MDX Resultado
SQL Picking
Picking macenaje Almacenaje
Número paletas
2352 2352 3218 3218 Correcto
ubicadas
Artı́culos diferentes 3262 3262 3 3 Correcto
Tabla 50: Resultado pruebas medidas cubos ubicación de picking
y almacenaje

8.3. Evaluación consultas ad-hoc

Para verificar que los datos mostrados en las consultas ad-hoc son correctos,
se definirá por cada modelo de metadatos una consulta que obtenga informa-
ción de varias tablas, y se obtendrán los datos tanto realizando directamente
una consulta SQL contra el Datawarehouse utilizando PLSQL Developer, como
realizando la consulta ad-hoc mediante Pentaho, comparando que los resultados
obtenidos mediante ambas consultas sean iguales.

Debido al limite de 1000 registros añadido en las consultas ad-hoc, añadi-

remos filtros suficientes para mostrar resultados con un número de registros
inferior a este número.

Los resultados obtenidos son los siguientes:

1. PEDIDOS DE COMPRA
Mostraremos el código de pedido, código lı́nea, nombre propietario, de-
nominación artı́culo de cada lı́nea y cantidad teórica a recepcionar de los
pedidos de compra confirmados del propietario con nombre Xabier. Orde-
naremos los resultados obtenidos según la cantidad teórica a recepcionar
de forma descendente.

Figura 97: Resultado consulta ad-hoc pedidos de compra

Realizaremos la misma consulta mediante SQL para comprobar si los datos

obtenidos son los mismos:

113
 Figura 98: Resultado consulta SQL pedidos de compra

El número registro y datos mostrados coinciden entre la consulta realizada

manualmente por SQL y la consulta realizada mediante la herramienta de
consultas ad-hoc.
2. PEDIDOS DE VENTA
Mostraremos pedido, división, denominación del almacén del pedido, nom-
bre de propietario, número de orden de picking, denominación articulo de
la orden, cantidad a servir y cantidad recogida del pedido 106/Z. Ordena-
remos los resultados obtenidos según el número de orden.

Figura 99: Resultado consulta ad-hoc pedidos de venta

Realizaremos la misma consulta mediante SQL para comprobar si los datos

obtenidos son los mismos:

114
 Figura 100: Resultado consulta SQL pedidos de venta

Los datos mostrados coinciden entre la consulta realizada manualmente

por SQL y la consulta realizada mediante la herramienta de consultas
adhoc.
3. MAESTROS
Mostraremos código articulo, denominación articulo, denominación del
almacén del articulo y nombre del propietario del articulo con código
BIC 001.

Figura 101: Resultado consulta ad-hoc maestros

Realizaremos la misma consulta mediante SQL para comprobar si los datos

obtenidos son los mismos:

Figura 102: Resultado consulta SQL maestros

Los datos mostrados coinciden entre la consulta realizada manualmente

por SQL y la consulta realizada mediante la herramienta de consultas
adhoc.

115
4. CONTROL
Mostraremos código movimiento, denominación del tipo movimiento, nom-
bre propietario y denominación de articulo de aquellos movimientos de
tipo picking y artı́culo con código 0000001. Ordenaremos los resultados
obtenidos según el código de movimiento.

Figura 103: Resultado consulta ad-hoc control

Realizaremos la misma consulta mediante SQL para comprobar si los datos

obtenidos son los mismos:

Figura 104: Resultado consulta SQL control

Los datos mostrados coinciden entre la consulta realizada manualmente

por SQL y la consulta realizada mediante la herramienta de consultas
adhoc.

116
9. Conclusiones y trabajo futuro
9.1. Planificación final
En primer lugar, se ha logrado alcanzar todos los objetivos definidos en el
planteamiento del proyecto.

A continuación, se muestra un gráfico comparativo en el que se puede ver la

desviación temporal que ha sufrido la planificación del proyecto por cada uno
de los apartados definidos:

Figura 105: Gráfica comparación horas estimadas y reales

En la siguiente tabla podemos ver desglosado el tiempo total dedicado a cada

tarea:

DURACIÓN DURACIÓN
TAREA
ESTIMADA REAL
Definición de Objetivos y
16 horas 12 horas
Alcance del Proyecto
Planificación temporal del
6 horas 4,5 horas
proyecto
Gestión de riesgos 3 horas 3,5 horas
Planificación económica 3 horas 3 horas
Estudio de antecedentes 14 horas 12 horas
Aprender conceptos bási-
cos de Business Intelligen- 14 horas 14 horas
ce

117
 Aprender funcionamiento
28 horas 28 horas
de la plataforma Pentaho
Aprender LaTeX 10 horas 10 horas
Identificación de funciona-
10 horas 8 horas
lidades
Casos de Uso 40 horas 25 horas
Diseño del Datawarehouse 40 horas 36 horas
Diseño de los cubos OLAP 30 horas 28 horas
Diseño de los informes 28 horas 18 horas
Implementación e integra-
15 horas 28 horas
ción del Datawarehouse
Implementación de cubos
10 horas 18,5 horas
OLAP y visor
Integración de informes
8 horas 30 horas
ad-hoc
Despliegue del servidor
15 horas 25 horas
web
Pruebas de implementa-
20 horas 22,5 horas
ción
Realización de la memoria 80 horas 70 horas
Preparación de la defensa 10 horas 8 horas
TOTAL 400 horas 404 horas
Tabla 51: Comparación horas estimadas y reales

Como se puede observar tanto en la gráfica como en la tabla, se ha sobres-

timado el tiempo necesario para realizar las tareas de planificación, análisis y
diseño del proyecto, siendo necesario un tiempo menor al estimado en la mayorı́a
de las tareas.

Sin embargo, debido en gran parte al desconocimiento del funcionamiento

de Pentaho durante las fases de planificación del proyecto, ha sido necesario
emplear mucho mas tiempo del estimado en las fases de desarrollo, despliegue
y evaluación de la aplicación, al ser necesario modificar y añadir nuevas funcio-
nalidades al sistema no incluidas por defecto en Pentaho.

Pese a esto, el número de horas totales empleadas para realizar el proyec-

to es similar al estimado, y además se ha logrado terminar el proyecto en el
plazo establecido, con lo cual, no hay ninguna modificación en la planificación
económica, y pese a haber surgido el riesgo de una mala planificación estimada,
finalmente el impacto en el proyecto ha sido pequeño.

118
9.2. Reflexiones personales
Tras finalizar el proyecto, la sensación general hacia el resultado obtenido es
satisfactoria.

Por un lado, pese a contar con los consejos de personas con años de expe-
riencia en puestos de gerencia, me he dado cuenta lo difı́cil que es planificar y
llevar adelante un proyecto de esta magnitud, siendo necesario ser constante en
la realización de los distintos puntos del proyecto para poder llevarlo a cabo.

Además, el trabajar implementando un sistema de Business Intelligence, una

tecnologı́a cada vez más demandada por las empresas, creo que ha sido muy en-
riquecedor para mi formación como profesional, y además, al realizar el proyecto
sobre un entorno real proporcionado por la empresa en la que estoy trabajando
como becario, he podido aprender con un proyecto que va mas allá del entorno
académico en el cual habı́a trabajado hasta ahora, viendo los resultados de mi
proyectos aplicados a un cliente real.

Al ser Pentaho una plataforma open source, no solo he implementado la

solución de Business Intelligence, sino que haciendo uso de la documentación
oficial de Pentaho, consultando la documentación publicada por la comunidad
en foros y mis conocimientos de programación adquiridos durante mi periodo
académico y laboral, poder añadir modificar las caracterı́sticas de este para
ajustarlo a mis necesidades, aprendiendo ası́ a trabajar con software de código
abierto.

9.3. Trabajo futuro

Los datos cargados al Datawarehouse y utilizados en el sistema, son aquellas
entidades más importantes y comunes en el sistema InLOG WMS, pero estas
son una pequeña parte del conjunto de entidades pertenecientes al sistema, con
lo que, quedarı́a como trabajo futuro ir incorporando las distintas entidades al
proyecto.

En cuanto a la herramienta para realizar consultas ad-hoc, serı́a interesante

extender las funcionalidades que esta ofrece, añadiendo la posibilidad de reali-
zar agrupaciones, introducir campos calculados (sumatorios, medias...) y poder
añadir filtros más complejos (menor que, contiene, empieza por...) para poder
realizar consultas de un nivel mayor al ofrecido actualmente.

Pese a haber traducido la aplicación web directamente a Español, al ser el

idioma hablado por la mayorı́a de los clientes de InLOG actualmente, serı́a in-
teresante desarrollar la aplicación en varios idiomas, como Castellano, Euskera
e Inglés, y ofrecer la posibilidad de permitir al cliente elegir el idioma desde la
propia aplicación.

Por último, queda como trabajo futuro realizar un proyecto de formación

tanto al resto de desarrolladores, como a los clientes de InLOG WMS para que
puedan usar correctamente la aplicación.

119
10. Referencias
[1] Inteligencia empresarial: transformación de da-
tos en decisiones. [Link]
inteligencia-empresarial-la-transformacion-de-los-datos-en-decisiones-optimas
(Accedido el 12/02/2021)
[2] ¿En qué consiste un proceso de ETL (Extraer, Transformar y Cargar)?
[Link] (Accedido el
12/02/2021)
[3] Proceso de BI — Dataprix TI
[Link]
13-proceso-bi (Accedido el 12/02/2021)
[4] Beneficios — Dataprix TI
[Link]
14-beneficios (Accedido el 12/02/2021)

[5] Datawarehouse
[Link]
aspx (Accedido el 12/02/2021)
[6] Data base y Data warehouse ¿En qué se diferencian?
[Link]
(Accedido el 12/02/2021)
[7] La base de datos analı́tica (el Datawarehouse o Almacén de Datos)
[Link]
3-la-base-de-datos-analitica-el-datawarehouse-o-almacen-de-datos/
(Accedido el 12/02/2021)

[8] Uso de cubos OLAP para análisis

[Link]
olap-cubes-overview?view=sc-sm-2019 (Accedido el 12/02/2021)
[9] Cubos OLAP - EcuRed
[Link] (Accedido el 12/02/2021)
[10] Cuadro de Mando Integral
[Link]
[Link] (Accedido el 12/02/2021)
[11] El cuadro de mando en Business Intelligence — EAE
[Link]
el-cuadro-de-mando-como-herramienta-de-business-intelligence/
(Accedido el 12/02/2021)
[12] ¿Qué son los metadatos y cuál es su utilidad?
[Link]
que-son-los-metadatos-y-cual-es-su-utilidad
Accedido el (12/02/2021)

120
[13] ¿Qué es Power BI? — Deloitte España
[Link]
[Link] (Accedido el 13/02/2021)
[14] ¿Qué es QlikView?
[Link]
HelpSites/[Link] (Accedido el 13/02/2021)
[15] SAP Business Intelligence - Cibernetica
[Link] (Accedi-
do el 13/02/2021)
[16] Pentaho Big Data - Business Intelligence España - Stratebi
[Link] (Accedido el 12402/2021)
[17] Caracterı́sticas y diferencias entre Pentaho y Power BI
[Link]
(Accedido el 14/02/2021)
[18] Comparativa Qlikview vs Pentaho
[Link] (Accedido
el 14/02/2021)
[19] Modelo Dimensional - BI Geek Blog
[Link] (Accedido el
24/03/2021)
[20] Data Warehouse y Data Marts - Conoce las diferencias
[Link]
data-warehouse-y-data-marts-esquema-en-estrella-11/ (Acce-
dido el 25/03/2021)
[21] Pentaho Data Integration - Pentaho Documentation
[Link]
Integration (Accedido el 29/03/2021)
[22] Informes parametrizados con report designer en
Pentaho CE [Link]
informes-parametrizados-con-report-designer-en-pentaho-ce
(Accedido el 29/03/2021)
[23] Aspectos básicos de las consultas MDX [Link]
com/es-es/analysis-services/multidimensional-models/mdx/
mdx-query-fundamentals-analysis-services (Accedido el 29/03/2021)
[24] Pentaho Schema Workbench - Pentaho Documentation
[Link]
Workbench (Accedido el 29/03/2021)
[25] Pentaho Metadata Editor
[Link]
Editor (Accedido el 29/03/2021)
[26] Qué es Pentaho BI Server [Link]
que-es-pentaho-bi-server/ (Accedido el 29/03/2021)

121
[27] Archivo PRPT
[Link] (Accedido el
02/04/2021)

[28] Qué es un esquema de base de datos

[Link]
(Accedido el 03/04/2021)
[29] La Guı́a Definitiva Sobre La Dimension Tiempo En Un Data Warehouse
[Link]
(Accedido el 05/04/2021)
[30] Kitchen User Documentation
[Link]
Documentation (Accedido el 17/04/2021)

[31] Cron – Configuración básica para programar ta-

reas mediante crontab [Link]
cron-configuracion-basica-para-programar-tareas-mediante-crontab/
(Accedido el 18/04/2021)
[32] Cómo usar Cron para automatizar tareas en CentOS 8
[Link]
how-to-use-cron-to-automate-tasks-centos-8-es (Accedido el
18/04/2021)
[33] Pentaho Report Designer
[Link]
Designer (Accedido el 24/04/2021)
[34] Pentaho Report Designer User Guide
[Link]
8/report_designer_user_guide.pdf (Accedido el 24/04/2021)
[35] JPivot
[Link] (Accedido el 29/04/2021)
[36] Pivot4J para visualizar cubos OLAP en Java
[Link] (Accedido
el 29/04/2021)

[37] CDE Dashboard Overview

[Link]
Dashboard_Overview (Accedido el 30/04/2021)
[38] [Link]
Editor (Accedido el 01/05/2021)

122
 .

11. Anexo I: Casos de uso extendidos

Iniciar Sesión

El usuario se identifica en el sistema mediante

Descripción
una cuenta dada de alta en el sistema
Precondiciones Ninguna

1. El usuario introduce el usuario y contra-

seña
2. El usuario pulsa el botón identificarse:

3. [Si el registro es correcto:]

Flujo de eventos
3.1 Se accede al sistema.
[Si algo falla]
3.2 Se muestra un mensaje indicando
el error.

Postcondiciones -

Interfaz gráfica

123
 Tabla 52: Caso de Uso: Iniciar Sesión

Programar Tareas

Permite al usuario programar tareas a ejecutar

Descripción
desde la aplicación web.
Precondiciones Ninguna

1. El usuario, desde el menú Ficheros, se-

lecciona el recurso del cual programar
una tarea.
2. Pulsa en Programar tarea y se abre una
ventana para programar la tarea.

3. El usuario introduce un nombre para la

tarea programada y la ruta donde se
Flujo de eventos guardara el resultado y pulsa en Con-
tinuar.

4. El usuario introduce la periodicidad de

repetición de la tarea y la fecha-hora en
la que se ejecutará y pulsa en Siguiente.
5. El usuario escoge el formato de la salida
y pulsa en Finalizar.

El usuario puede consultar las tareas progra-

madas desde la opción Programaciones.
Se programa la ejecución de una tarea en el
Postcondiciones sistema en la fecha seleccionada durante el pe-
riodo especificado.

124
Interfaz gráfica

125
Tabla 53: Caso de Uso: Programar Tareas

126
 Realizar consulta

Permite realizar al usuario consultas contra el

Descripción
Datawarehouse
Precondiciones Ninguna

1. El usuario pulsa en Crear / Consulta

2. El usuario selecciona los datos a consul-

Flujo de eventos tar.
3. Se muestran los datos correspondientes
a la consulta introducida.

Postcondiciones -

Interfaz gráfica

Tabla 54: Caso de Uso: Realizar consulta

127
 Crear cuadro de mando

Permite diseñar y crear cuadros de mando per-

Descripción
sonalizados
Precondiciones Ninguna

1. El usuario pulsa en Crear / Cuadro de

mando
Flujo de eventos
2. Se muestra un dashboard para diseñar
el cuadro de mando

Postcondiciones Se crea un nuevo cuadro de mando

Interfaz gráfica

Tabla 55: Caso de Uso: Crear cuadro de mando

128
 Visualizar cubos OLAP

Permite visualizar los cubos OLAP diseñados

Descripción
y desplegados.
Debe haber algún cubo desplegado en la apli-
Precondiciones
cación.

1. El usuario pulsa en Crear / Visor OLAP.

2. El usuario selecciona el cubo a visualizar
Flujo de eventos y pulsa el botón Aprobar.
3. Se muestra la interfaz en la que se visua-
liza el cubo OLAP, permitiendo al usua-
rio realizar consultas sobre el.

Postcondiciones -

Interfaz gráfica

Tabla 56: Caso de Uso: Visualizar cubos OLAP

129
 Abrir cuadros de mando

Permite abrir y visualizar los cuadros de man-

Descripción
do creados anteriormente.
Precondiciones Debe haber algún cuadro de mando creado.

1. El usuario pulsa en Ficheros .

Flujo de eventos 2. El usuario selecciona y abre el cuadro de

mando a visualizar.
3. Se visualiza el cuadro de mando.

Postcondiciones -

Interfaz gráfica

Tabla 57: Caso de Uso: Abrir cuadros de mando

130
 Abrir informes

Permite abrir y visualizar los informes creados

Descripción
y desplegados anteriormente.
Debe haber algún informe desplegado en la
Precondiciones
aplicación.

1. El usuario pulsa en Ficheros.

2. El usuario selecciona y abre el informe a
Flujo de eventos visualizar.
3. Se visualiza el informe, permitiendo al
usuario modificar los diferentes paráme-
tros para el informe.

Postcondiciones -

Interfaz gráfica

131
 Tabla 58: Caso de Uso: Abrir informes

Administrar fuentes de datos

Permite crear y modificar las fuentes de datos

Descripción
con las que se trabaja desde la aplicación web.
Precondiciones Ninguna

1. El usuario pulsa en Administrar fuentes

de datos.
Flujo de eventos
2. Se despliega una ventana para crear o
modificar las diferentes fuentes de datos
con las que trabaja la aplicación web.

Postcondiciones -

Interfaz gráfica

132
Tabla 59: Caso de Uso: Administrar fuentes de datos

133
 Administrar usuarios

Permite crear y modificar los usuarios de la

Descripción
aplicación web.
Precondiciones Ninguna

1. El administrador pulsa en Administra-

ción
2. Se muestra el menú para administrar el
sistema.
Flujo de eventos
3. El administrador pulsa en Usuarios /
Roles
4. Se muestra el menú para administrar los
usuarios de la aplicación web.

Postcondiciones -

Interfaz gráfica

Tabla 60: Caso de Uso: Administrar usuarios

134
 Administrar Roles de usuario

Permite modificar los permisos de cada usua-

Descripción
rio de la aplicación web.
Precondiciones Ninguna

1. El administrador pulsa en Administra-

ción
2. Se muestra el menú para administrar el
sistema.
3. El administrador pulsa en Usuarios /
Flujo de eventos Roles
4. El administrador pulsa en Administrar
roles o Funciones del sistema
5. Se muestra el menú para administrar los
distintos roles y asignárselos a los distin-
tos usuarios del sistema.

Postcondiciones -

Interfaz gráfica

135
Tabla 61: Caso de Uso: Administrar Roles de usuario

136
 Crear cubo OLAP

Descripción Permite crear y diseñar cubos OLAP.

Precondiciones Debe estar creado el Datawarehouse

1. Abrir la aplicación de escritorio Pentaho

Schema Workbench
Flujo de eventos
2. Abrir un schema existente o crear uno
nuevo

Se crea un fichero .xml con los datos del sche-

Postcondiciones
ma creado

Interfaz gráfica

Tabla 62: Caso de Uso: Crear cubo OLAP

137
 Desplegar cubo OLAP

Permite desplegar un cubo OLAP en la apli-

Descripción
cación web.
Debe haberse creado un schema con los datos
Precondiciones
de los cubos a desplegar

1. Abrir la aplicación de escritorio Pentaho

Schema Workbench
Flujo de eventos 2. Abrir el schema con los datos de los cu-
bos

3. Pulsar File/Publish

Se publican los cubos definidos en la aplicación

Postcondiciones
web Pentaho

Interfaz gráfica

Tabla 63: Caso de Uso: Desplegar cubo OLAP

138
 Definir transformaciones

Permite definir y modificar el proceso de carga

Descripción de datos al Datawarehouse desde las diferentes
fuentes
Precondiciones Ninguna

1. Abrir la aplicación de escritorio Pentaho

Data Integration
Flujo de eventos
2. En la pestaña View, seleccionar la op-
ción Transformations o abrir una trans-
formación desde File / Open

Se crea un fichero de extensión .ktr con la

Postcondiciones
transformación definida

Interfaz gráfica

Tabla 64: Caso de Uso: Definir transformaciones

139
 Definir jobs

Permite modificar la forma y la periodicidad

Descripción
de carga de datos al Datawarehouse
Precondiciones Ninguna

1. Abrir la aplicación de escritorio Pentaho

Data Integration
Flujo de eventos
2. En la pestaña View, seleccionar la op-
ción Jobs o abrir un job ya definido des-
de File / Open

Se crea un fichero de extensión .kjb con la

Postcondiciones
transformación definida

Interfaz gráfica

Tabla 65: Caso de Uso: Definir jobs

140
 Diseñar informe

Permite diseñar informes predefinidos para-

Descripción
metrizables
Precondiciones Debe estar creado el Datawarehouse

1. Abrir la aplicación de escritorio Pentaho

Report Designer
Flujo de eventos
2. En la pestaña View, seleccionar la op-
ción Jobs o abrir un job ya definido des-
de File / Open

Se genera un fichero de extensión .prpt con el

Postcondiciones
report diseñado

Interfaz gráfica

Tabla 66: Caso de Uso: Diseñar informe

141
 Publicar informe

Permite desplegar informes creados anterior-

Descripción
mente en la aplicación web
Precondiciones Debe haber un informe creado

1. Abrir la aplicación de escritorio Pentaho

Report Designer
Flujo de eventos
2. Abrir el informe a publicar
3. Pulsar File/Publish

Postcondiciones El informe es accesible desde la aplicación web

Interfaz gráfica

Tabla 67: Caso de Uso: Publicar informe

142
12. Anexo II: Definición de metadatos
12.1. Compras
Metadato correspondiente a los pedidos de compra del sistema.

Figura 106: Diagrama metadato de compras

Está formado por las siguientes tablas:

Cabecera de pedido de compra (H CABEC PEDCOM)

Lı́neas de pedido de compra (H LINEAS PEDCOM)
Almacenes (DIM ALMACENES)

Propietarios (DIM PROPIETARIOS)

Proveedores (DIM PROVEEDOR)
Artı́culos (DIM ARTICULOS)
Se definen las siguientes relaciones:

Campos relacio-
Tabla desde Tabla hasta Tipo Cardinalidad
nados
CPC PEDIDO
H CABEC PEDCOM H LINEAS PEDCOM = Inner 1:N
LPC PEDIDO
CPC ALMACE
H CABEC PEDCOM DIM ALMACENES = Inner N:1
ALM CODIGO
CPC PROPIE
H CABEC PEDCOM DIM PROPIETARIOS = Inner N:1
PPR CODIGO

143
 CPC PROVEE
H CABEC PEDCOM DIM PROVEEDOR = Inner N:1
PRO CODIGO
LPC ARTIDE
H LINEAS PEDCOM DIM ARTICULOS = Inner N:1
ART IDENTI
Tabla 68: Relaciones metadato de compras

12.2. Ventas
Metadato correspondiente a los pedidos de venta del sistema.

Figura 107: Diagrama metadato de ventas

Está formado por las siguientes tablas:

Cabecera de pedido de venta (H CABEC PEDVEN)
Lı́neas de pedido de venta (H LINEAS PEDVEN)
Almacenes (DIM ALMACENES)
Propietarios (DIM PROPIETARIOS)
Clientes (DIM CLIENTES)
Artı́culos (DIM ARTICULOS)
Ordenes de paleta completa (H ORDENES PC)
Ordenes de picking (H ORDENES PK)
Lı́neas de picking (H LINEAS PK)

144
 Se definen las siguientes relaciones:

Campos relacio-
Tabla desde Tabla hasta Tipo Cardinalidad
nados
CPV PEDIDO
=
LPV PEDIDO,
H CABEC PEDVEN H LINEAS PEDVEN Inner 1:N
CPV DIVPED
=
LPV DIVPED
CPV ALMACE
H CABEC PEDVEN DIM ALMACENES = Inner N:1
ALM CODIGO
CPV PROPIE
H CABEC PEDVEN DIM PROPIETARIOS = Inner N:1
PPR CODIGO
CPV CLIENT =
H CABEC PEDVEN DIM CLIENTES Inner N:1
CLI CODIGO
LPV ARTIDE =
H LINEAS PEDVEN DIM ARTICULOS Inner N:1
ART IDENTI
OPC PEDIDO
=
LPV PEDIDO,
OPC DIVPED
H ORDENES PC H LINEAS PEDVEN = Inner N:1
LPV DIVPED,
OPC CODLIN
=
LPV CODLIN
OPK PEDIDO
=
LPK PEDIDO,
OPK DIVPED
H ORDENES PK H LINEAS PK = Inner 1:N
LPK DIVPED,
OPK NUMORD
=
LPK NUMORD
LPK PEDIDO
=
LPV PEDIDO,
LPK DIVPED
H LINEAS PK H LINEAS PEDVEN Inner N:1
=
LPV DIVPED,
LPK LINPED =
LPV CODLIN
Tabla 69: Relaciones metadato de ventas

145
12.3. Maestros
Metadato correspondiente a los maestros de las entidades del sistema.

Figura 108: Diagrama metadato de maestros

Está formado por las siguientes tablas:

Proveedores (DIM PROVEEDOR)
Almacenes (DIM ALMACENES)

Propietarios (DIM PROPIETARIOS)

Clientes (DIM CLIENTES)
Artı́culos (DIM ARTICULOS)

Operarios (DIM OPERARIOS)

Se definen las siguientes relaciones:

Campos relacio-
Tabla desde Tabla hasta Tipo Cardinalidad
nados
ART ALMACE
DIM ARTICULOS DIM ALMACENES = Inner N:1
ALM CODIGO
ART PROPIE
DIM ARTICULOS DIM PROPIETARIOS = Inner N:1
PPR CODIGO
Tabla 70: Relaciones metadato de maestros

146
12.4. Control
Metadato correspondiente al control de los movimientos en el almacén. Está

Figura 109: Diagrama metadato de control

formado por las siguientes tablas:

Movimientos (H MOVIMIENTOS)
Tipos Movimiento (H TIPOS MOVIMIENTO)

Paletas (H PALETAS)
Proveedores (DIM PROVEEDOR)
Almacenes (DIM ALMACENES)
Propietarios (DIM PROPIETARIOS)

Clientes (DIM CLIENTES)

Artı́culos (DIM ARTICULOS)
Se definen las siguientes relaciones:

Campos relacio-
Tabla desde Tabla hasta Tipo Cardinalidad
nados
MVM TIPMOV
H MOVIMIENTOS H TIPOS MOVIMIENTO = Inner N:1
TMV CODIGO
PAL CODIGO
H PALETAS H MOVIMIENTOS = Inner 1:N
MVM PALETA

147
 MVM ARTIDE
H MOVIMIENTOS DIM ARTICULOS = Inner N:1
ART IDENTI
ART IDENTI
DIM ARTICULOS H PALETAS = Inner N:1
PAL ARTIDE
ART ALMACE
DIM ARTICULOS DIM ALMACENES = Inner N:1
ALM CODIGO
ART PROPIE
DIM ARTICULOS DIM PROPIETARIOS = Inner N:1
PPR CODIGO
Tabla 71: Relaciones metadato de control

148
13. Anexo III: Pruebas unitarias del proceso ETL
Para la implementación de las pruebas del proceso ETL, se utilizará la he-
rramienta de testing automatico en Java JUnit 4.

Figura 110: Diagrama de clases JUnits proceso ETL

La clase Articulo contendrá los datos de un artı́culo del sistema. Se reimple-

mentará el método equals para comprobar si dos artı́culos son iguales.

La clase AreaDescarga contendrá los datos de un área de descarga del sis-

tema. Se reimplementará el método equals para comprobar si dos artı́culos son
iguales.

149
 La clase ConexionBD, es una clase abstracta la cual contendrá los métodos
comunes necesarios para trabajar con ambas bases de datos.

Constructor. Recibe como parámetros los datos de conexión a la base de

datos, se encarga de recogerlos y llamar al método connect para iniciar la
conexión.
Conectar: Conecta con la base de datos.
ejecutarSQL: Ejecuta y devuelve el resultado de la sentencia SQL recibida
como parámetro.
obtenerNumeroFilas: Devuelve el número de registros en la tabla recibida
como parámetro.
cerrarConexion: Cierra la conexión una vez finalizada las operaciones con-
tra la base de datos para evitar fugas de memoria.
La clase ConexionDWH, es una clase que hereda de ConexionBD, la cual
contendrá los métodos necesarios para trabajar contra el Datawarehouse.
Constructor: Llama al constructor de la clase padre pasándole como paráme-
tro los datos de conexión al Datawarehouse.

obtenerNumPaletas: Obtiene el número de registros en la tabla paletas sin

contar históricos.
obtenerArticuloMovimiento: Devuelve un objeto del tipo Artı́culo con la
referencia al artı́culo del movimiento pasado como parámetro.

obtenerArticuloPaleta: Devuelve un objeto del tipo Artı́culo con la refe-

rencia al artı́culo de la paleta pasada como parámetro.
obtenerArticuloPedcom: Devuelve un objeto del tipo Artı́culo con la refe-
rencia al artı́culo de la linea de pedido de compra pasada como parámetro.

obtenerArticuloPedven: Devuelve un objeto del tipo Artı́culo con la refe-

rencia al artı́culo de la linea de pedido de venta pasada como parámetro.
obtenerArticuloDevcli: Devuelve un objeto del tipo Artı́culo con la referen-
cia al artı́culo de la linea de devolución de cliente pasada como parámetro.
obtenerArticuloDevpro: Devuelve un objeto del tipo Artı́culo con la re-
ferencia al artı́culo de la lı́nea de devolución de proveedor pasada como
parámetro.
mismoPasilloUbicPicking: Devuelve el número de filas de las ubicaciones
de picking cuyo pasillo es el mismo al pasillo referenciado.
mismoPasilloUbicAlmac: Devuelve el número de filas de las ubicaciones
de almacenaje cuyo pasillo es el mismo al pasillo referenciado.

150
 La clase ConexionBDOPeracional es una clase que hereda de ConexionBD,
la cual contendrá un atributo que indica la fecha de carga de datos al Da-
tawarehouse y los métodos necesarios para trabajar contra la base de datos
operacional.
Constructor: Llama al constructor de la clase padre pasándole como paráme-
tro los datos de conexión a la base de datos operacional.
obtenerNumMovimientos: Devuelve el número de registros en la tabla MO-
VIMIENTOS cuya fecha es superior a la fecha de carga de datos al Data-
warehouse establecida.
obtenerNumCabecPedcom: Devuelve el número de registros en la tabla
CABEC PEDCOM cuya fecha asignada es superior a la fecha de carga de
datos al Datawarehouse establecida.
obtenerNumLineasPedcom: Devuelve el número de registros de la tabla
LINEAS PEDCOM cuya fecha de cabeceras es superior a la fecha de carga
de datos al Datawarehouse establecida.
obtenerNumCabecPedven: Devuelve el número de registros en la tabla
CABEC PEDVEN cuya fecha de transmisión es superior a la fecha de
carga de datos al Datawarehouse establecido.
obtenerNumLineasPedven: Devuelve el número de registros de la tabla
LINEAS PEDVEN cuya fecha de cabeceras es superior a la fecha de carga
de datos al Datawarehouse establecida.
obtenerNumCabecDevcli: Devuelve el número de registros en la tabla CA-
BEC DEVCLI cuya fecha de devolución es superior a la fecha de carga de
datos al Datawarehouse establecida.
obtenerNumLineasDevcli: Devuelve el número de registros de la tabla LI-
NEAS DEVCLI cuya fecha de cabeceras es superior a la fecha de carga de
datos al Datawarehouse establecida.
obtenerNumCabecDevpro: Devuelve el número de registros en la tabla
CABEC DEVPRO cuya fecha de devolución es superior a la fecha de
carga de datos al Datawarehouse establecida.
obtenerNumLineasDevpro: Devuelve el número de registros de la tabla
LINEAS DEVPRO cuya fecha de cabeceras es superior a la fecha de carga
de datos al Datawarehouse establecida.
obtenerOrdenesPC: Devuelve el número de registros de la tabla ORDE-
NES PC cuyos pedidos han sido cargados al Datawarehouse.
obtenerOrdenesPK: Devuelve el número de registros de la tabla ORDE-
NES PK cuyos pedidos han sido cargados al Datawarehouse.
obtenerLineasPK: Devuelve el número de registros de la tabla LINEAS PC
cuyas ordenes han sido cargadas al Datawarehouse.
obtenerArticuloMovimiento: Devuelve un objeto del tipo Artı́culo con la
referencia al artı́culo del movimiento pasado como parámetro.

151
 obtenerArticuloPaleta: Devuelve un objeto del tipo Artı́culo con la refe-
rencia al artı́culo de la paleta pasada como parámetro.
obtenerArticuloPedcom: Devuelve un objeto del tipo Artı́culo con la refe-
rencia al artı́culo de la linea de pedido de compra pasada como parámetro.
obtenerArticuloPedven: Devuelve un objeto del tipo Artı́culo con la refe-
rencia al artı́culo de la linea de pedido de venta pasada como parámetro.
obtenerArticuloDevcli: Devuelve un objeto del tipo Artı́culo con la referen-
cia al artı́culo de la linea de devolución de cliente pasada como parámetro.
obtenerArticuloDevpro: Devuelve un objeto del tipo Artı́culo con la re-
ferencia al artı́culo de la lı́nea de devolución de proveedor pasada como
parámetro.
Se implementarán los distintos test automáticos en el fichero [Link].
Los métodos implementados son los siguientes:
numeroFilasTablasHechos y numeroFilasTablasDimensiones comprobarán
que el número de filas insertadas al Datawarehouse de las diferentes tablas
de hechos y dimensiones sea correcto.
comprobarArticuloMovimientos, comprobarArticuloPaletas, comprobarAr-
ticuloPedcom, comprobarArticuloPedven, comprobarArticuloDevcli, com-
probarArticuloDevpro comprobarán que la nueva referencia al artı́culo ba-
sada en un campo numérico sea correcta.
comprobarAreDesPedcom comprobará que la nueva referencia a el área de
descarga basada en un campo numérico sea correcta.
comprobarPasilloUbicPicking y comprobarPasilloUbicAlmac comprobarán
que la nueva referencia a el pasillo basada en un campo numérico sea co-
rrecta.
Para obtener los datos necesarios en estos métodos se utilizarán las clases
definidas anteriormente.

Figura 111: Estructura proyecto JUnits del proceso ETL

152
14. Anexo IV: Manual de usuario
14.1. Introducción
En este manual se procede a explicar cómo hacer uso de la aplicación web
de Pentaho.

14.2. Acceso a la aplicación

Acceda a la dirección web de la aplicación Pentaho proporcionada. Se mos-
trará la siguiente pantalla:

Figura 112: Pantalla de login de la aplicación web

Introduzca un usuario y contraseña válidos y pulse en el botón “Iniciar

sesión”.

Figura 113: Mensaje de carga de la consola de usuario

Se iniciará sesión en la aplicación y se mostrará la consola de usuario.

153
14.3. Consola de usuario
La interfaz desde la perspectiva “Inicio” de la consola de usuario es la si-
guiente:

Figura 114: Interfaz consola de usuario

Las posibles opciones para realizar desde la consola de usuario son las si-
guientes:

1. Pestaña de navegación. Permite navegar entre las diferentes perspectivas

de la aplicación.

Haciendo clic se despliega el menú de navegación:

Figura 115: Pestaña de navegación entre perspectivas

154
 Inicio: Muestra la interfaz de inicio de la aplicación
Abierto: Muestra los recursos abiertos (consultas ad-hoc, visores olap,
informes...)
Examinar: Se muestra la pantalla menú ficheros. Permite navegar
entre los directorios de archivos de la aplicación.
Marketplace: Permite acceder al marketplace de Pentaho para insta-
lar plugins desarrollados y publicados por la comunidad.
Programaciones: Se muestra la pantalla programaciones. Permite ges-
tionar las tareas programadas en la aplicación.
Administración: Se muestra la pantalla administración. Permite ad-
ministrar las opciones de la aplicación.
2. Muestra el nombre de usuario identificado en la aplicación. Tras pulsar
sobre él se abre un menú desplegable que permite cerrar la sesión.
3. Menú de recursos de la aplicación:
Ficheros. Se muestra la pantalla menú ficheros. Permite navegar entre
los ficheros de la aplicación.
Crear nuevo. Permite crear una nueva consulta contra el Datawa-
rehouse, cubo OLAP o crear un cuadro de mando. Tras situar el
cursor sobre “Crear nuevo” se abre un desplegable mostrando las
opciones posibles:

Figura 116: Desplegable Crear Nuevo

ˆ Consultas: Se muestra la pantalla de consultas ad-hoc.

ˆ Visor OLAP: Se muestra la pantalla de consultas olap.
ˆ Tablero CDE: Permite crear un cuadro de mando.
Gestionar Fuentes de Datos: Permite gestionar las fuentes de datos
con las que trabaja la aplicación.
Documentación: Descarga este manual.
4. Muestra los recursos abiertos recientemente.
5. Muestra los recursos marcados como favoritos.

155
14.4. Menú ficheros
Permite navegar entre las carpetas y ficheros alojados en el servidor, como
consultas ad-hoc guardadas, cuadros de mando creados e informes predefinidos.

La interfaz del menú ficheros es la siguiente:

Figura 117: Interfaz menú ficheros con acciones sobre carpeta

Las acciones sobre una carpeta son las siguientes:

Nueva Carpeta: Crea una nueva carpeta en la ubicación actual
Mover a la papelera: envı́a la carpeta a la papelera
Renombrar: Cambia el nombre de la carpeta

Pegar: Pega un fichero cortado o copiado en la carpeta actual

Cargar: Sube un fichero desde el equipo al servidor
Descargar: Descarga la carpeta al equipo

Propiedades: Consulta de propiedades de la carpeta

En caso de seleccionar un fichero, las posibles acciones son las siguientes:

156
 Figura 118: Interfaz menú ficheros con acciones sobre fichero

Abrir: Abre el fichero seleccionado

Abrir en una nueva ventana: Abre una nueva ventana con el fichero selec-
cionado

Cortar: Traslada el fichero a otro lugar

Copiar: Duplica el fichero seleccionado en otro lugar
Mover a la papelera: envı́a el fichero a la papelera

Renombrar: Cambia el nombre del fichero

Descargar: Descarga el fichero seleccionado al equipo
Compartir: Permite gestionar el acceso al fichero a otros usuarios
Programar tarea: Permite programar una tarea a realizar con el fichero
seleccionado
Añadir a favoritos: Añade el fichero a la lista de favoritos
Propiedades: Consulta de propiedades del fichero

157
14.5. Menú programaciones
Permite administrar las tareas programadas en la aplicación.

La interfaz del menú programaciones es la siguiente:

Figura 119: Interfaz menú programaciones

Administrar programaciones: Muestra las programaciones en la aplicación,

permitiendo editar y modificarlas.

Tiempo de interrupción: Muestra los tiempos de interrupción establecidos

en la aplicación, durante el cual no se ejecutará ninguna programación.

Para crear un nuevo tiempo de interrupción, tras pulsar sobre el botón

“Crear tiempo de interrupción”, se mostrará un asistente para configurarlo de
una forma sencilla.

Figura 120: Popup asistente configuración de tiempo de interrupción

158
14.6. Menú administración
Permite administrar las diferentes opciones de administrador de la aplica-
ción:
Gestión de usuarios.
Gestión de roles.
Configuración del servidor de correo electrónico.

La interfaz del menú administración es la siguiente:

Figura 121: Interfaz opciones menú administración

Las opciones son las siguientes:

Usuarios & Roles: Permite administrar los usuarios, los roles y permisos
de usuarios.

Figura 122: Interfaz gestión usuarios y roles del menú administración

159
Servidor de correo: Permite configurar un servidor de correo electrónico
para enviar correos automáticamente.

Figura 123: Interfaz gestión servidor correo del menú administración

Configuración: Permite eliminar archivos generados sin utilizar para op-

timizar el consumo de recursos de la aplicación, o configurar una progra-
mación para eliminarlos automáticamente en función de un periodo.

Figura 124: Interfaz configuración en menú administración

160
14.7. Consultas ad-hoc
Pantalla accesible desde Crear Nuevo / Consultas o Herramientas / Consul-
tas.

Permite realizar consultas de una manera sencilla contra el Datawarehouse,

siguiendo una filosofı́a drag & drop (arrastrar los elementos que forman las con-
sultas) para formar las consultas de una forma visual.

La interfaz de la pantalla de consultas ad-hoc es la siguiente:

Figura 125: Interfaz pantalla consultas ad-hoc

Las opciones sobre la pantalla son las siguientes:

Seleccionar modelo de datos: Muestra los diferentes modelos de metadatos
creados.

Seleccionar categorı́a: Muestra las tablas definidas en el modelo de meta-

datos seleccionado
Seleccionar columna: Muestra las columnas de la tabla seleccionada
Filtros: Muestra los filtros aplicados

Exportar a Excel: Permite exportar la consulta actual a un fichero .xls

Guardar consulta: Guarda la consulta realizada en un fichero .waqe para
poder abrirla posteriormente desde el menú ficheros

161
14.7.1. Diseñar consulta
Para realizar una consulta, es necesario seleccionar el modelo de datos sobre
el que se realizará la consulta, no siendo posible realizar consultas contra mas
de un modelo de datos a la vez.

Es necesario ir arrastrando las columnas de las diferentes tablas que formarán

la consulta a la pestaña “Arrastra aquı́ los elementos”.

Figura 126: Diseño de consultas ad-hoc

El resultado de la consulta realizada se mostrará en una tabla en la parte

derecha de la pantalla:

Figura 127: Resultado de consulta ad-hoc

Es posible modificar el número de registros mostrados por tabla, hacer

búsquedas sobre la tabla y ordenar en función de un campo haciendo clic sobre
la cabecera en la tabla de este.

14.7.2. Aplicar filtro

Para aplicar un filtro sobre un campo, es necesario hacer clic sobre este,
abriéndose un popup para definir los filtros.

162
 Figura 128: Popup selección de filtros sobre un campo

Disponible: Muestra los valores posibles. Haciendo clic sobre un valor se

aplicará un filtro sobre este.

Seleccionado: Muestra los valores sobre los cuales se aplicará el filtro.

Haciendo clic sobre un valor se dejará de aplicar un filtro sobre este.
Es posible añadir un valor manualmente, escribiendo el valor en el cuadro
de texto debajo de la columna “Disponible”. Una vez escrito el valor,
pulsar el botón “Añadir” para aplicar el filtro sobre este valor.

Cerrar: Cierra el popup de filtros.

Tras aplicar un filtro sobre algún campo, este aparecerá en el apartado filtros
de la pantalla consultas ad-hoc. Los filtros se mostrarán de la forma CÓDIGO
CAMPO: VALORES:

Figura 129: Filtros aplicados en una consulta ad-hoc

Es posible eliminar un filtro haciendo clic sobre el valor a eliminar.

163
14.8. Consultas OLAP
Pantalla accesible desde Crear Nuevo / Visor OLAP o Archivo / Nuevo /
Consulta OLAP.

Tras acceder al visor OLAP se muestra la siguiente pantalla:

Figura 130: Pantalla selección de cubo OLAP

Seleccionar catalogo y cubo contra el que se realizarán las consultas y pulsar

el botón “Aprobar”.

Tras pulsar el botón, se muestra la pantalla para realizar la consulta contra

el cubo seleccionado:

Figura 131: Pantalla visor OLAP

164
 Tenemos las siguientes pestañas:
Navegador OLAP: Muestra los cubos contra los que realizar una consulta.

Estructura de cubo: Muestra la estructura (medida y dimensiones) del

cubo seleccionado.
Estructura pivote: Muestra la estructura de la consulta a realizar.
Resultado de la consulta: Muestra la consulta realizada.

Consulta MDX: Muestra la sentencia MDX realizada para realizar la con-

sulta OLAP.
Para realizar una consulta contra el cubo seleccionado es necesario mostrar
al menos una medida y dimensión, y al menos mostrar un elemento del cubo
en filas y columnas. Para mostrar un elemento del cubo, seleccionar el elemento
desde “Estructura de cubo” y arrastrar a Columnas o Filas de “Estructura
pivote”.

Figura 132: Ejemplo de consulta con el visor OLAP

165
14.9. Informes predefinidos
Para abrir un informe predefinido, es necesario abrir un fichero .prpt desple-
gado en el servidor desde el menú ficheros.

Una vez abierto el fichero, se muestra la pestaña para configurar los paráme-
tros del informe:

Figura 133: Configuración parámetros de informe predefinido

Se muestran:
Campos obligatorios para poder lanzar un informe.
Campos opcionales.
Tipo de Salida: Indica el formato en el que se mostrará el informe (HTML,
Excel, PDF. . . ). En caso de seleccionar la opción HTML se mostrará en
la misma página debajo de la pestaña de configuración de informe.

Figura 134: Valores tipo de salida de informe predefinido

166
 Una vez seleccionados los parámetros, pulsar el botón “Ver informe” para
lanzar el informe.

En el caso de seleccionar la opción “Auto-Enviar”, al cambiar algún paráme-

tro, se lanzará el informe con las nuevas opciones automáticamente

Figura 135: Ejemplo de informe predefinido

167