Trabajo final de grado

FACULTAD DE INGENIERÍA
Carrera Ingeniería de Sistemas
MODALIDAD DE GRADUACIÓN
Proyecto de Grado
“Data Mart para la gestión de reportes y apoyo a la toma de
decisiones del departamento de RR.HH. de la empresa de agua S.A.”
Oscar Marcos Amelunge Ruiz
Santa Cruz - Bolivia
2010
FACULTAD DE INGENIERÍA
Carrera Ingeniería de Sistemas
MODALIDAD DE GRADUACIÓN
Proyecto de Grado
“Data Mart para la gestión de reportes y apoyo a la toma de
decisiones del departamento de RR.HH. de la empresa de agua S.A.”
Oscar Marcos Amelunge Ruiz
NR. 2003210474
Proyecto de Grado para optar al
grado de Licenciado en Ingeniería de Sistemas
Santa Cruz - Bolivia
2010
ABSTRACT
TITULO
AUTOR
Data Mart para la gestión de reportes y apoyo a la
toma de decisiones del departamento de RR.HH. de
la empresa de agua S.A.
: Oscar Marcos Amelunge Ruiz.
PROBLEMATICA
OBJETIVO
CONTENIDO
CARRERA
PROFESOR GUIA
DESCRIPTORES O TEMAS
: Ingeniería de Sistemas
:
: Data Warehouse, Data Mart, Analisis,
Diseño, Modelo Dimensional.
E-MAIL
: [email protected]
: Julio de 2010.
FECHA
AGRADECIMIENTO
En esta sección se realizara el agradecimiento correspondiente
RESUMEN
INTRODUCCION
Desde principios de la década de los 80 los sistemas de información empezaron a
desarrollarse utilizando el modelo relacional y la información almacenada en las bases de
datos generalmente ha sido orientada al registro de transacciones, lo que comúnmente se
conoce como sistemas OLPT – “OLTP es la sigla en inglés de Procesamiento de
Transacciones En Línea (Online Transaction Processing) es un tipo de sistemas que
facilitan y administran aplicaciones transaccionales, usualmente para entrada de datos y
recuperación y procesamiento de transacciones.” (WIKIPEDIA, 2010). Como su nombre
lo dice este tipo de sistemas están orientados exclusivamente generar información a
través de transacciones y no a la consulta y análisis de la información, ya que al aumentar
el volumen de información en los sistemas transaccionales se dificulta la consulta de los
datos generados. Como alternativa a esta situación surgió el concepto de Data Warehouse
(D.W.)
(almacén de datos)
como lo define Ralph Kimball “una copia de las
transacciones de datos específicamente estructurada para la consulta y el análisis” o “la
unión de todos los Data Marts de una entidad” (Kimball, 2002)(Ralph Kimball 2002).
El objetivo primordial de un D.W.es almacenar los datos de tal manera que se facilita la
extracción y consulta de los mismos sin importar el amplio volumen de información que
pueda existir. Normalmente el alcance que tiene un D.W. llega a ser, toda la información
generada empresa, la construcción de un D.W. requiere una inversión en tiempo y
esfuerzo considerable. Una estrategia o concepto alternativo al D.W. que tiene el mismo
fin pero con un alcance más limitado a un área o departamento de empresa es el Data
mart. “Un Data mart es una versión especial de almacén de datos (Data Warehouse). Son
subconjuntos de datos con el propósito de ayudar a que un área específica dentro del
negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden
ser agrupados, explorados y propagados de múltiples formas para que diversos grupos de
usuarios realicen la explotación de los mismos de la forma más conveniente según sus
necesidades.” (WIKIPEDIA, 2010).
En los tiempos actuales las empresas necesitan depositar toda su confianza en la toma de
decisiones, para lo cual se requieren fuentes de información fiables y oportunas, la cuales
brinden a los empleados, jefes de sección, administrativos, ejecutivos y también entes
externos
a la empresa como ser: organismos gubernamentales, bancos, fondos
financieros, etc. la facilidad de compartir, gestionar, procesar y utilizar los datos
generados, sobre todo la información que es procesada y almacenada por los Sistemas de
Informatizados de la compañía como fuente principal de apoyo a la toma de decisiones,
marco del estado actual e indicador de los posibles estados futuros;
para esto las
empresas pueden valerse de los D.W..
El presente trabajo de grado pretende enfocarse en la implementación de un Data Mart
para una de las aéreas de empresa mayor estudiada y de mayor preocupación; los
Recursos Humanos, eje principal del aparato productivo de toda organización. La
cantidad de información generada por las actividades y procesos concernientes al control
y gestión de recursos humanos en las empresas es substancial, y de la misma pueden
derivarse una gran cantidad de información como ser control de asistencias y permisos,
control de vacaciones, planillas de sueldos, pagos de beneficios, etc.
TABLA DE CONTENIDO
.PARTE I PLANIFICACIÓN Y PREPARACIÓN DEL PROYECTO ................................................... 2
i
PARTE I PLANIFICACIÓN Y
.
PREPARACIÓN DEL PROYECTO
CAPITULO I PLAIFICACION DEL PROYECTO
1. PLANIFICACION DEL PROYECTO
1.1. INTRODUCCION
1.2. DEFINICION DEL PROBLEMA
El departamento de Recursos Humanos de la empresa de agua S.A. cuenta actualmente
con un sistema de información con el cual se gestionan y almacena la información de más
de 600 funcionarios.
El sistema utiliza como repositorio de información una base de datos cuyo diseño
relacional está orientado mas al almacenamiento que a la consulta y explotación de los
mismo, con el paso del tiempo los usuarios de dicho sistema han ido requiriendo cada
vez mayor cantidad de reportes y necesidad de poder analizar la información de los
funcionarios, con lo cual el modelo transaccional sobre la cual está construida la base de
datos dificulta el estudio de la información almacenada en la misma.
Con los sistemas tradicionales se preparan reportes ad-hoc para encontrar las respuestas a
algunas de las preguntas del negocio, pero se necesita dedicar mucho del tiempo al
análisis de localización, formateo, presentación y procesamiento de los datos, como
también asignación de recursos humanos del departamento de sistemas para poder
responderlas, sin tener en cuenta la degradación de los sistemas transaccionales. Esta
problemática se debe a que dichos sistemas transaccionales no fueron construidos con el
fin de brindar síntesis, análisis, consolidación, búsquedas y proyecciones.
Existe una gran cantidad de reportes ad-hoc asociados a los datos que se registran en el
sistema de recursos humanos y la variación de los mismos en el tiempo es poco
significativa, la herramienta en la cual están construidos y publicados estos reportes exige
que cada vez que se requiera un cambio menor en el mismo, tenga que contactarse a los
desarrolladores para que el reporte ad-hoc sea modificado, lo cual implica un retraso para
la persona o área de empresa que necesita el reporte.
1.3. SITUACION PROBLEMÁTICA
CAPITULO I PLAIFICACION DEL PROYECTO
No existe una disponibilidad inmediata de la información para la generación de reportes y
consulta de datos de los empleados.
1.4. SITUACION DESEADA
Contar con un Data Mart que almacene la información generada por el sistema de
recursos humanos y que de la posibilidad de acceder dicha información de manera
inmediata a través de una herramienta de consulta.
1.5. JUSTIFICACIÓN
La ventaja de utilizar un Data Mart como herramienta al soporte de decisiones son
muchas por ejemplo: que el departamento de RR. HH. pueda consultar la información sin
tener que depender de personal técnico (programadores o analistas de sistemas) que
genere los reportes o consultas ad hoc a través de un lenguaje y/o herramienta de
programación, lo cual además conlleva en disminuir el tiempo de espera en la generación
de reportes por parte del personal técnico.
Además el departamento de RR. HH. Podrá manejar la información, examinarla desde
diferentes puntos de vista, de manera que puedan entenderla mejor e interpretarla de
acuerdo a su criterio.
1.6. OBJETIVOS
1.6.1. OBJETIVO GENERAL
Construir un Data Mart para la gestión de reportes y apoyo a la toma de decisiones del
departamento de RR.HH. de la empresa de agua S.A.
1.6.2. OBJETIVOS ESPECIFICOS
 Definir los requerimientos generales del área de RRHH para la construcción del Data
Mart.
 Analizar y definir las fuentes de datos que permitan alimentar el Data Mart.
 Realizar el diseño de la base de datos del Data Mart
 Definir los procesos de ETL para alimentar el Data Mart.
 Construir una versión Beta de la base de datos y los procesos ETL del Data Mart.
CAPITULO I PLAIFICACION DEL PROYECTO
1.7. ALCANCE
La metodología a utilizar será El Proceso de Ingeniería para el Data Warehouse (DWEP
por sus siglas en ingles) planteado en la tesis doctoral de Luján-Mora (Luján Mora,
2005) utilizando como herramientas de modelado al Lenguaje Unificado de Modelado
(UML) y las extensiones multidimensional profile, data mapping profile, ETL profile,
UML profile database desing y database deployment profile planteadas en la citada tesis
doctoral.
Fases
Inicio

Requerimientos
o Requerimientos funcionales y no funcionales.
o Identificación de las medidas y dimensiones más importantes.
o Análisis de los reportes periódicos que se utilizan actualmente.
o Elaboración del modelo del dominio
o Elaboración de los casos de uso más importantes

Análisis
o Determinación de las posibles fuentes de datos
o Elaboración de los diagramas lógico de la fuente de datos SLS, diagrama
físico de las fuentes de datos SPS.

Diseño
o Diseño definición de la estructura del data Warehouse
o Elaboración del diagrama conceptual del data Warehouse DWCS.
Elaboración

Requerimientos
o Recolección y refinamiento de requerimientos.
o Identificación de nuevas medidas agregaciones y dimensiones.

Análisis
o Elección de fuentes de datos que alimenta el DM.
o Actualización de los diagramas SLS, SPS.
CAPITULO I PLAIFICACION DEL PROYECTO
o Elaboración de los diagramas diagrama conceptual SCS.

Diseño
o Definición procesos ETL a nivel conceptual.
o Actualización del diagrama DWCS.
o Elaboración del diagrama mapeo de datos de integración DM.

Implementación
Elaboración de las estructuras físicas.
CAPITULO I PLAIFICACION DEL PROYECTO
CAPITULO II
DATA WAREHOUSE Y DATA MART
CAPITULO I PLAIFICACION DEL PROYECTO
2. INTRODUCCION
2.1. DATA WAREHOUSE
Segun Bill Immon (1994) se puede definir a un Data Warehouse como “una colección de
datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no
volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que
se utiliza”.
2.1.1. ORIENTACION AL TEMA
El Data Warehouse ser organiza alrededor de los temas principales de la empresa. Asi los
datos se estructuran por temas, contrariamente a los datos de los sistemas transaccionales,
organizados generalmente por procesos funcionales. La integración de los diferentes
temas en una estructura única es necesaria para que la información común a varios temas
no se repita.
2.1.2. DATOS INTEGRADOS
Antes de llegar al Data Warehouse, los datos deben formatearse y unificarse para llegar a
un estado coherente. Un dato debe tener únicamente una descripción y una codificación.
Las diferencias que existen en los datos de las fuentes dependen de la visión deseada por
el usuario, de la utilización que se hace, o de los programadores. La integración de datos
constituye una gran parte de la labor de construir un Data Warehouse y se realiza
mediante los proceso de extracción, transformación y carga o procesos ETL.
2.1.3. DATOS HISTÓRICOS
U Data Warehouse almacena el histórico de datos de la empresa y los datos actuales con
los que cuenta. Suponiendo que cada día se obtienen los datos, cada dato de un día sobre
algo constituye un dato diferente al de otro día sobre lo mismo. Una vez ingresada la
información al Data Warehouse, ésta no se actualiza, a no ser por casos excepcionales.
2.1.4. DANOS NO VOLÁTILES
CAPITULO I PLAIFICACION DEL PROYECTO
La no volatilidad es, de cierta forma una consecuencia de que los datos sean históricos.
Al no actualizarse los datos, una consulta sobre determinados datos será siempre la
misma.
2.2. DATA MART
Según la definición de Oracle Corporation “Un Data Mart es una forma simple de un
Data Warehouse que esta enfocada en una área funcional de empresa como ser Ventas,
finanzas, marketing, etc.”
De acuerdo a Immon (1999) existen dos tipos de ata Mart: dependientes e independientes.
Un Data Mart dependiente es aquel cuya fuente de datos es un Data Warehouse, Un Data
Mart independiente es aquel cuya fuente de datos son los sistemas transaccionales, el
Data Mart a construir en el presente trabajo de grado.
2.3. DIFERENCIA ENTRE UN DATA MART Y UN DATA WAREHOUSE
Un Data Warehouse maneja información de distintas areas típicamente es implementado
como el repositorio central de información de toda una organización, mientras que que un
Data Mart maneja información de un departamento en particular. La tabla siguiente
muestra una comparación de las principales diferencias entre el Data Mart y el Data
Warehouse:
Categoría
Data Warehouse
Data Mart
Alcance
Corporativo
Área de Negocios
Temas
Multiples
Simples
Fuentes de Datos
Muchas
Pocas
Tamaños
100 GB-TB+
< 100 GB
Tiempo de implementación
Fuente
De meses a años
Meses
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm
2.4. LOS PROCESOS ETL
Los procesos ETL son los que permiten a la organización mover datos desde distintas
fuentes de datos, formatearlos, purgarlos y cargarlos en otra base de datos, Data Mart o
Data Warehouse (wikipedia 2010).
CAPITULO I PLAIFICACION DEL PROYECTO
Es ampliamente reconocido que el diseño y mantenimiento de estos procesos ETL es un
factor clave de éxito en los proyectos de Data Warehouse. Debido a la dificultad de
diseñar y mantener este tipo de procesos, existen muy poca proliferación de herramientas
de este tipo e igualmente respecto al modelado de estos procesos (Lujan,2005).
2.5. BASES DE DATOS OPERACIONALES VS. DATA WAREHOSE
Existen muchas características que diferencian a las bases de datos convencionales de los
Data Warehouse, una de las principales es el fin que tienen estas, mientras que las base de
datos convencionales están pensadas para soportar procesos transaccionales de
almacenamiento de información, los Data Warehouse están orientados a la consulta y
explotación de datos, sin embargo es importante mencionar que ambos no son
mutuamente excluyentes si no más bien complementarios.
Las bases de datos operacionales trabajan con un tipo de procesamiento OLPT mientras
que un Data Warehouse trabaja bajo un procesamiento de tipo OLAP.
2.6. OLPT
De acuerdo a Wikipedia (2010) Online transaction processing por sus siglas es un tipo de
sistemas que facilitan y administran aplicaciones transaccionales, usualmente para
entrada de datos y recuperación y procesamiento de transacciones (gestor transaccional).
Los paquetes de software para OLTP se basan en la arquitectura cliente-servidor ya que
suelen ser utilizados por empresas con una red informática distribuida. La tecnología
OLTP se utiliza en innumerables aplicaciones, como en banca electrónica, procesamiento
de pedidos, comercio electrónico, supermercados o industria.
2.7. OLAP
De acuerdo a Wikipedia(2010) OLAP es el acrónimo en ingles de procesamiento
analítico en línea. Es una solución que consiste en consultas a estructuras
multidimensionales (cubos OLAP) que conienen datos resumidos de grandes Bases de
Datos o Sistemas Transaccionales (OLPT). Se usa en informes de negocios de ventas,
marketing, informes de dirección, minería de datos y aéreas similares.
CAPITULO I PLAIFICACION DEL PROYECTO
De acuerdo con Wikipedia(2010) existen distintos tipos de OLAP:
ROLAP
Implementación OLAP que almacena los datos en un motor relacional. Típicamente, los
datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas.
Los esquemas más comunes sobre los que se trabaja son estrella ó copo de nieve, aunque
es posible trabajar sobre cualquier base de datos relacional. La arquitectura está
compuesta por un servidor de banco de datos relacional y el motor OLAP se encuentra en
un servidor dedicado. La principal ventaja de esta arquitectura es que permite el análisis
de una enorme cantidad de datos.
MOLAP
Esta implementación OLAP almacena los datos en una base de datos multidimensional.
Para optimizar los tiempos de respuesta, el resumen de la información es usualmente
calculado por adelantado. Estos valores precalculados o agregaciones son la base de las
ganancias de desempeño de este sistema. Algunos sistemas utilizan técnicas de
compresión de datos para disminuir el espacio de almacenamiento en disco debido a los
valores precalculados.
HOLAP (Hybrid OLAP)
Almacena algunos datos en un motor relacional y otros en una base de datos
multidimensional.
2.8. CUBO OLAP
Existen distintos concepto de acuerdo al punto de vista de los que es un cubo olap:
Según Wikipedia(2010) es una base de datos multidimensional, en la cual el
almacenamiento físico de los datos se realiza en un vector multidimensional. Los cubos
OLAP se pueden considerar como una ampliación de las dos dimensiones de una hoja de
cálculo.
CAPITULO I PLAIFICACION DEL PROYECTO
Según (PradoLand,2000) “un cubo es un subconjunto de datos de un Data Warehouse,
organizado y sumariado dentro de una estructura multidimensional. Los datos se
sumarizan de acuerdo a factores de negocio seleccionados, proveyendo el mecanismo
para un rápido y uniforme tiempo de respuesta de las complejas consultas”.
Las estructuras multidimensionales que se mencionan en el enunciado anterior y que
forman un cubo son las dimensiones y las medidas.
2.8.1. MEDIDAS
Según Oracle Corp. (2000) “Las medidas contienen los datos que se desean analizar
como Ventas o Costos. Las medidas son las columnas normalmente”
Measures contain the data that you wish to analyze, such as Sales or Cost. OLAP Catalog
metadata requires that a column have a numerical or a date data type to be identified as a
measure. Most frequently, a measure is numerical and additive.
http://download.oracle.com/docs/cd/B10500_01/olap.920/a95295/designd6.htm
PARTE II
ANALISIS Y DISEÑO DEL DATA MART
CAPITULO 2
REQUERIMIENTOS
2. REQUERIMIENTOS
“Los requerimientos determinan que datos van a estar disponibles en el Data warehouse,
como
estos
datos
estarán
organizado
y
con
que
frecuencia
estos
serán
actualizados.”(Kimbal,1998).
A diferencia del Data Warehouse el Data Mart se centra en proveer información
particular sobre un departamento de la empresa o area funcional, en este caso el
Departamento de RRHH de la empresa de agua S.A. por tanto los requerimientos deben
determinar las necesitadas de información de esta área de la empresa.
La publicación de Oracle Corporation “The Oracle Data Mart Suite Cookbook”
recomienda clasificar los requerimientos en dos grupos: Requerimientos del Negocio y
Requerimientos Técnicos.
2.1. REQUERIMIENTOS FUNCIONALES
Los requerimientos del negocios para el departamento de RRHH de la empresa de agua
S.A. son los siguientes:
CASOS DE USO
2.2. REQUERIMIENTOS NO FUNCIONALES
3. ANALISIS
4. DISEÑO
5. CONSTRUCCION DEL DATA MART
6. CONCLUCIONES Y RECOMENDACIONES
PARTE III
COSTRUCCION Y PRUEBAS DEL DATA MART
PARTE IV
CONCLUSIONES Y RECOMENDACIONES
REFERENCIAS BIBLIOGRAFICAS
(Kimbal,1998) Kimball, Ralph. The Data Warehouse Lifecycle Toolkit. Impreso en
Estados Unidos:Wiley, 1998.
ORACLE.
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm
Consultado 19 de agosto del 2010
Wikipedia etl http://es.wikipedia.org/wiki/Extract,_transform_and_load