1.

PLANEACIÓN Y ADMINISTRACIÓN DEL PROYECTO

a. DEFINICIÓN DEL PROYECTO

La Universidad Nacional Micaela Bastidas (UNAMBA), tiene interés de implementar

para el área de caja, una solución de Business Inteligent, que permita la creación
de informes, generación de cuadros y análisis de información.

La necesidad de análisis de información para la toma de decisiones en el área de

caja produce una creciente dedicación a tareas de elaboración manual de
informes, más allá de las funcionalidades proporcionadas por las aplicaciones
informáticas actualmente implantadas.

Para tener el éxito del proyecto proponemos las líneas básicas para la
implementación de la plataforma de inteligencia de negocios, la solución
presentada asegura la escalabilidad futura de área de caja de la Universidad
Nacional Micaela Bastidas (UNAMBA), nuevos indicadores, nuevos informes y
nuevos cuadro. Se propone una metodología de trabajo para el desarrollo de
proyecto que cubre todo el ciclo de proyecto de inteligencia de negocios
(BUSSINES INTELIGENT).

b. PLANTEAMIENTO DEL PROBLEMA

El área de caja cuenta con sistema transaccional, de caja que le permite obtener
datos de todos los ingresos que percibe por diferentes conceptos, sin embargo
esta gran cantidad de datos acumulados están guardados en la base datos.

Describiendo el sistema actual, la Universidad Nacional Micaela Bastidas

(UNAMBA), los Directivos conformados por el Rector, vice rector y la plana
administrativa, analizan el comportamiento administrativo y financiero del área de
caja en el tiempo. En el que se requiere se muestren información relacionada al
comportamiento de sus metas. Esto requiere de un largo y tedioso proceso para
consolidar información a partir de la generación, de múltiples informes
procedentes del sistema.

Una vez analizado las circunstancias en la que se encuentra área de caja –

UNAMBA, referente a su sistema transaccional, se percibe que presenta cierta
dificultad a la hora de obtener información de nivel gerencial ya que no se
cuenta con un proceso, automatizado que reduzca los tiempos de ejecución así
como los gastos que se incurren para llevar una buena gestión.
c. OBJETIVOS GENERAL

Implementar un datawarehouse para la información de ingresos del área de caja

de la Universidad Nacional Micaela Bastidas- UNAMBA, utilizando tecnologías y
metodologías de inteligencia de negocios, con el propósito de brindar información
necesaria de forma oportuna que soporte el proceso de toma de decisiones
gerenciales.

OBJETIVOS ESPECÍFICO

 Implementar una Data Warehouse utilizando la herramienta Pentaho.

 Utilizar la metodología de Ralph Kimball como guía para el desarrollo del

proyecto.

 Utilizar el sistema de gestor de base de datos Oracle.

 Realizar una herramienta que sirva d e apoyo a la toma de decisiones

y actividades de elaboración de informes Mysql, Oracle y Pentaho .

d. ALCANCE

Data Warehouse estará orientado a la captación de información histórica para la

elaboración de informes, reportes y otros para la toma de decisiones de los
gerentes de la Universidad Nacional Micaela Bastidas- UNAMBA,

e. JUSTIFICACIÓN DEL PROYECTO

Actualmente se desea obtener un reporte general y detallado de los ingresos en el

área de caja de la Universidad Nacional Micaela Bastidas- UNAMBA, pero existe un
inconveniente en el sistema transaccional, que solo muestra reporte estáticos

Para ello se aplicará una solución de inteligencia de negocios en la construcción de

un almacén de datos.

El objetivo fundamental de este proyecto es la implementación de un

datawarehouse en el área de caja Universidad Nacional Micaela Bastidas-
UNAMBA, que permita la flexibilidad en la manipulación y obtención de
información relevante, oportuna, periódica, confiable y veraz, así como acceso
fácil y rápido a la información.
2. DEFINICIÓN DE LOS REQUERIMIENTOS DEL PROYECTO – tabla hecho

2.1. Proceso caja

 Registro Ingresos

2.2. INDICADORES

 Importe total por tipo de cliente durante el año, trimestre y mensual.

Descripción: Este indicador representa el importe total de ingresos con el que conto la
Universidad durante el año, durante cada trimestre y mensual según el tipo de cliente.
 Ingresos por producto (definición) durante el año, trimestre y mensual.
Descripción: Este indicador representa el importe total de ingresos por cada tipo de
producto durante el año, durante cada trimestre y mensual.
 Cantidad de ventas de cada producto durante el año, trimestre y mensual.
Descripción: Este indicador representa las cantidades de cada producto vendidos durante
el año, durante cada trimestre y mensual.
 Cantidad de productos por tipo de cliente durante el año, trimestre y mensual.
Descripción: Este indicador representa el importe total de ingresos con el que conto la
Universidad durante el año, durante cada trimestre y mensual según el tipo de cliente.

3. DISEÑO TECNICO DE LA ARQUITECTURA

a. BACK ROOM

Los datos son extraídos de sistema Mysql, se realiza un proceso ETL y finalmente
se cargara en un gestor Oracle.

Origen de Datos

El origen de datos se encuentra en el sistema de gestor de base de datos

Mysql, en donde se encuentra la base de datos TESORERIA2009

ETL Y Metadatos

En cuanto al proceso ETL se realizará el Mapeo de los datos Origen, que serán
especificados posteriormente en el Modelamiento Dimensional, después se
desarrollará el proceso de extracción, seguido de la transformación de los datos
Origen, dependiendo de qué cambios se les debe adecuar, y finalmente se procederá
con la carga hacia el Data Warehouse.

Los metadatos son las especificaciones de transformaciones, mapeos, tareas

programadas, que se almacenarán en el Repositorio del Data Warehouse como
soporte al proceso ETL.

Se especificará con más detalle el Proceso ETL y los Metadatos del

Proyecto en la sección de Diseño y Desarrollo ETL.

 Destino de Datos

El destino que es el Almacén de datos en el sistema gestor de base de datos,

mantendrá el modelo dimensional que será especificado en la sección Diseño y
Modelamiento Dimensional.

La base de datos destino estará separado físicamente de las bases de datos

Origen, por motivo de rendimiento y para poder separar el ambiente operacional del
ambiente del DataWarehouse.

b. FRONT ROOM

En esta sección se especifica la Arquitectura de presentación del

DataWarehouse, mediante aplicaciones dirigidas al usuario final.

4. SELECCIÓN DEL PRODUCTO

a. Plataforma DBMS

La plataforma a utilizar es el motor de base de datos Oracle 11g Express Edition.

b. Herramienta ETL

En cuanto a la herramienta ETL se planteó 2 opciones:

 Pentaho Data Integration (Kettle).

 Oracle Warehouse Builder (OWB).

La primera opción es una herramienta open source, parte de la suite de BI de

Pentaho y la segunda es una herramienta privativa de Oracle.

Para poder seleccionar el producto adecuado se analizó 4

aspectos fundamentales:

Comparación OWB vs PDI

Característica Licencia Facilidad de Funcionalidad Estabilidad
Manejo (%
Herramienta Entendimiento)
Oracle Privativo con 70% 100% 100%
Warehouse costo de
Builder (OWB) licencia
Pentaho Data Open source 80% 100% 100%
Integration - con
(Kettle) costos de
licencia
 Licencia.- La licencia de Pentaho Data Integration no tiene costo alguno debido a que es
una herramienta Open Source, mientras que Warehouse Builder de Oracle tiene un
precio por costo de licencia al no contar con licencia de la base de datos Oracle 10g
Enterprise Edition, por lo que para versiones Standard y Express de la base de datos
Oracle se tiene que adquirir la licencia.
 Facilidad de Manejo.- Este parámetro dependió mucho del entendimiento del
desarrollador sobre la herramienta ya que ambas son herramientas visuales. La
diferencia marco en que la herramienta de Pentaho se presento más entendible para el
desarrollador con respecto a la herramienta de Oracle.
 Funcionalidad.- La funcionalidad de las 2 herramientas cumplieron con las
características necesarias para la integración de datos, así como para transformaciones,
extracción y carga. Existe un funcionalidad que difiere de gran manera a las 2
herramientas y es que la herramienta de Oracle solo puede interactuar con un Motor
de Base de datos exclusivamente de su misma firma es Oracle, en cambio la
herramienta de Pentaho puede actuar con varias Bases de Datos.
 Estabilidad.- En cuanto a la estabilidad la herramienta de Oracle en teoría se puede
considerar estable debido a que es una versión Empresarial con soporte por parte de
los técnicos de Oracle, mientras que la herramienta open source, no cuenta con
soporte al menos que se costee el mismo. Se realizó pruebas con ambas herramientas y
ninguna manifestó inestabilidad.

Tomando en cuenta estos aspectos y el del objetivo se concluyó en utilizar la herramienta

Open Source, Pentaho Data Integration 3.2 (Kettle) la misma que fue considerada a fin de
no ocasionar mayores gastos a la institución.

Herramienta de Pentaho: Pentaho Data Integration

La Arquitectura de PDI se encuentra representada de la Siguiente manera:

Figura #: Arquitectura - Pentaho Data Integration

Uso de tecnologías estándar: Java, XML, JavaScript.

  Fácil de instalar y configurar.
 Multiplataforma: Windows, Macintosh, Linux.
 Basado en dos tipos de objetos: Transformaciones (colección de pasos en un proceso
ETL) y trabajos (colección de transformaciones).
 Incluye cuatro herramientas:
o Spoon: para diseñar transformaciones o trabajos ETL usando el entorno gráfico.
o PAN: para ejecutar transformaciones diseñadas con spoon mediante líneas de
comando.
o CHEF: para crear trabajos mediante líneas de comando.
o Kitchen: para ejecutar trabajos mediante líneas de comando.

a. Herramienta de BI.
o Oracle Warehouse Builder (OWB)
o Pentaho Data Integration (Kettle)
o ETL
o OLAP (Procesamiento Analítico en línea) (incluido HOLAP, ROLAP and MOLAP)-
Es la capacidad de algunos sistemas
o Aplicaciones de Informes
o Minería de datos

5. ESTANDARES DE TABLA

a. Estándares de Tabla

 HECHO_CAJA

Descripción: pertenece a la tabla de HECHOS CAJA

 DIM_TIEMPO

Descripción: pertenece a la tabla DIMENSIÓN TIEMPO

 DIM_CLIENTE

Descripción: Pertenece a la tabla DIMENSIÓN CLIENTE

 DIM_PRODUCTO

Descripción: Pertenece a la tabla DIMENSIÓN PRODUCTO

b. Estándares de Campos

Campos de tabla HECHO_CAJA

 CANTIDAD

 IMPORTE

Campos de tabla DIM_TIEMPO

 ANIO
  TRIMESTRE

 MES

 DIA

Campos de tabla DIM_CLIENTE

 ID_CLIENTE

 NOMBRE_CLIENTE

 TIPO_CLIENTE

Campos de tabla DIM_PRODUCTO

 ID_PRODUCTO

 NOMBRE_PRODUCTO

c. Estándares de Índices

 Tabla HECHO_CAJA

CAJA_KEY

 Tabla DIM_TIEMPO

TIEMPO_KEY

 Tabla DIM_CLIENTE

CLIENTE_KEY

 Tabla DIM_PRODUCTO

PRODUCTO_KEY

6. MODELAMIENTO DIMENSIONAL

a. PASO 1: SELECCIÓN DEL PROCESO DE NEGOCIO

El proceso de negocio seleccionado es el área de caja donde se desea obtener un

reporte de los ingresos por producto.

b. PASO 2: DEFINICIÓN DE LA GRANURALIDAD

 En cuanto a la granularidad se seleccionó lo más baja o granular posible. La
granularidad de área de caja corresponde al registro ingreso por transacción y/o
registro.

c. PASO 3: IDENTIFICAR LAS DIMENSIONES Y MAPEAR LOS DATOS ORIGEN.

Nombre de Tabla: DIM_CLIENTE

Tipo de Tabla: DIMENSION Esquema

Origen: TESORERIA2009

Tablas Origen: CLIENTE

DESTINO ORIGEN
Nombre Columna Descripción Tipo de Clav SC Sistema/Esquema Tabla Campo Tipo de Dato
Dato/Tamaño e D Origen Origen
cliente_key Correspond Integer Sistema ETL
e a la llave
subrrogada
id_cliente Es el id del integer PK 1 Tesoreria2009/clien idcliente integer
cliente en te
la base de
datos
origen
Nombre_clien Es el Varchar(8 1 Tesoreria2009/clien nombresc Varchar(8
te nombre 0) te li 0)
completo
del cliente
Tipo_cliente Es el tipo Varchar(1 1 Tesoreria2009/clien tipocli Varchar(1
de cliente 2) te 2)

Nombre de Tabla: DIM_PRODUCTO

Tipo de Tabla: DIMENSION
Esquema Origen: TESORERIA2009
Tablas Origen: denominacion

DESTINO ORIGEN
Nombre Columna Descripción Tipo de Clav SC Sistema/Esquema Tabla Campo Origen Tipo de
Dato/Tamañ e D Dato Origen
o
producto_key Correspo integer PK Sistema ETL
nde a la
llave
subrroga
da
id_producto Es el id Varchar 1 Tesoreria2009/denomi iddenomina Varchar
del (20) nacion cion (20)
producto
en la base
de datos
origen

Nombre_prod Es el Varchar( 1 Tesoreria2009/denomi dconcepto Varchar(

ucto concepto 80) nacion 80)
del
producto

Nombre de Tabla: DIM_TIEMPO

Tipo de Tabla: DIMENSION

Nombre Columna Descripción Tipo de Clave

Dato/Tamaño
Tiempo_key Corresponde a la clave integer PK
sobrogada de dim_tiempo
Dia_semana Corresponde al dia en el que Varchar(10)
realizo los ingresos respectivos
Mes Corresponde al mes en el que Varchar(12)
realizo los ingresos respectivos
Trimestre Corresponde al trimestre en el Varchar(15)
que realizo los ingresos
respectivos
Anio Corresponde al año en el que Integer
realizo los ingresos respectivos
Fecha Corresponde a las fechas en la Date
que se realizo los ingresos

c. PASO 4: IDENTIFICAR LOS HECHOS Y MAPEAR LOS DATOS ORIGEN.

Nombre de Tabla: HECH_CAJA

Tipo de Tabla: HECHO
Esquema Origen: TESORERIA2009
Tablas Origen: boleta

DESTINO ORIGEN
Nombre Descripción Tipo de Clav SC Sistema/Esque Campo Tipo de
Columna Dato/Tamañ e D ma Tabla Origen Dato
o Origen
Caja_key llave Integer PK Sistema ETL Caja_key Integer
subrogada
Tiempo_key llave Integer FK 1 DIM_TIEMPO Tiempo_ Integer
subrogada key
producto_ke llave Integer FK 1 DIM_PRODUCT product Integer
y subrogada O o_key
cliente_key llave Integer FK 1 DIM_CLIENTE cliente_ Integer
subrogada key
Cantidad Correspond Integer 1 Tesoreria2009 Cantidad Integer
e a la /Detalle Bol
cantidad de eta
un producto
Importe Correspond Decimal 1 Tesoreria2009 Importe Decima
e al total de (10,2) /Detalle Bol l (10,2)
pago por la eta
cantidad de
producto

d. DISEÑO DEL MODELO DIMENSIONAL

 DIM_TIEMPO

 DIM_CLIENTE

 DIM_PRODUCTO
 e. DATA WAREHOUSE BUS MATRIX
(Formato a utilizar)

PROCESO TABLAS GRANULARIDAD DIMENSIÓN DIMENSIÓN DIMENSIÓ

DE DE cliente tiempo producto
NEGOCIO HECHO
Sistema caja Transacción
de caja por
transacción en X X X
el nivel más
bajo

2. DISEÑO FÍSICO
a. BASE DE DATOS ORIGEN
ESPACIO DE TABLA (TABLESPACE)
ESQUEMA
Se creará un Esquema o Usuario en la Base de Datos Origen que permita
administrar los recursos que serán agregados en ella, así como también a través
del cual permita leer los datos para la extracción en el proceso ETL. Los privilegios
o permisos asignados para la Base son:
 Lectura de Datos.
 Creación de Tablas (Para su Esquema).

TABLAS
Se utilizará las tablas como se muestra en imagen siguiente

Figura. Modelo de base de datos origen de TESORERIA2009

INDICES

Se asignará un índice único de las tablas como se muestra en la figura.

RESTRICCIONES (CONSTRAINTS)
Las tablas contaran con una restricción que es la clave primaria.

SECUENCIA

Se utilizará una secuencia incremental para el campo de la clave primaria de las

Tablas.
b. BASE DE DATOS DESTINO
(DATAWAREHOUSE) ESPACIO DE TABLA
(TABLESPACE)

Se crearán 5 Tablespace que se mencionan a continuación:

Hecho_caja, dim_tiempo, dim_cliente, dim_producto.
REPOSITORIO_WAREHOUSE

En este espacio de tablas se alojarán todos los Metadatos

utilizados por la herramienta ETL para todo el Proceso de
integración de datos.

DATA_WAREHOUSE

En este espacio de tablas se alojarán los datos propios del

almacén, es decir todas las dimensiones, hechos, métricas, índices, etc.

TABLAS
Se crearán las Tablas del DataWarehouse, tanto lo que serán las
Dimensiones así como también los Hechos.
INDICES
Se definirán los índices para cada tabla de Dimensión y Hecho .
RESTRICCIONES (CONSTRAINTS)
Se creará las restrincciones, lo que son las claves primarias y foráneas,
tanto para las Tablas de Dimensiones como para los Hechos y para el Log
de Errores.
SECUENCIA
Se utilizara una secuencia incremental para el campo de la clave primaria
de las tablas.
 3. DISEÑO Y DESARROLLO DEL PROCESO ETL
a. TRAZA UN PLAN DE ALTO NIVEL

DIM_CLIENTE

Tabla Extraer Genera Transf Selecci Carga DIM_CLI

cliente datos r clave ormar onar de ENTE
subrrog campo campos datos
ada s nulos DESTINO
ORIGEN

TRANSFORMACION

DIM_PRODUCTO

Tabla Extraer Genera Transf Selecci Carga DIM_PR

denomi datos r clave ormar onar de ODUCT
nacion subrrog campo campos datos O
ada s nulos
DESTINO
ORIGEN

TRANSFORMACION
DIM_tiempo

Generar Calculo Genera Agrega Agrega Selecci DIM_tie

registro de clave r dia r onar mpo
sa campos subrrog de la trimest campo
partir numeri ada seman re s DESTINO
de una cos del a
fecha dia, Cargar
mes y datos
año
ORIGEN
TRANSFORMACION

HEC_caja

DESTINO
Tabla Extraer Genera Transf Transfo Extrae
Cliente, datos r clave ormar rmar r daos
Boleta, subrrog campo fecha Din_F
detbole ada s nulos echa
ta y
denomi
nacion
Extraer Extraer Selecci Carga HEC_CA
datos datos onar de JA
Dim_Pro Dim_clie Datos datos
ORIGEN
ducto nte

TRANSFORMACION
b. PROFUNDIZAR TABLA DESTINO
Se especificará de manera detallada los niveles y jerarquía por cada dimensión.
Tiempo

Año

Anio

Trimenstre

Nombre_trimestre

Mes

Mes_nombre

c. POBLAR LAS TABLAS DE DIMENSIONES CON LOS DATOS HISTÓRICOS

Extracción de Datos
La extracción de los datos se lo realizará mediante sentencias SQL a las tablas de la
Base Origen. Como resultado devolverá todos los registros de acuerdo a la tabla
consultada debido a que es el Proceso de carga Inicial.
Transformaciones
Los datos antes de ser cargados en el almacén serán transformados según lo
requieran.
Valores Nulos
(Formato)
Tabla Origen Campo Origen Valor a Campo Destino
Reemplazar
cliente Nombrecli Sin Nombre Nombre_cliente
boleta Fecha Sin fecha Fecha_boleta
Denominación Dconcepto Sin concepto Nombre_producto

Decodificación de datos Origen

Campo Origen Valor Campo Destino Valor
Codificado decodificado
… … … …
4. DESPLIEGUE BI