Академический Документы
Профессиональный Документы
Культура Документы
MODALIDAD DE GRADUACIN
Proyecto de Grado
DataMartparalagestindereportesyapoyoalatomade
decisionesdeldepartamentodeRR.HH.delaempresadeaguaS.A.
FACULTAD DE INGENIERA
Carrera Ingeniera de Sistemas
MODALIDAD DE GRADUACIN
Proyecto de Grado
DataMartparalagestindereportesyapoyoalatomade
decisionesdeldepartamentodeRR.HH.delaempresadeaguaS.A.
ABSTRACT
TITULO
AUTOR
PROBLEMATICA
OBJETIVO
CONTENIDO
CARRERA
PROFESOR GUIA
DESCRIPTORES O TEMAS
E-MAIL
FECHA
: Ingeniera de Sistemas
:
: Data Warehouse, Data Mart, Analisis,
Diseo, Modelo Dimensional.
: oscar.amelunge@gmail.com
: Julio de 2010.
AGRADECIMIENTO
En esta seccin se realizara el agradecimiento correspondiente
RESUMEN
INTRODUCCION
Desde principios de la dcada de los 80 los sistemas de informacin empezaron a
desarrollarse utilizando el modelo relacional y la informacin almacenada en las bases de
datos generalmente ha sido orientada al registro de transacciones, lo que comnmente se
conoce como sistemas OLPT OLTP es la sigla en ingls de Procesamiento de
Transacciones En Lnea (Online Transaction Processing) es un tipo de sistemas que
facilitan y administran aplicaciones transaccionales, usualmente para entrada de datos y
recuperacin y procesamiento de transacciones. (WIKIPEDIA, 2010). Como su nombre
lo dice este tipo de sistemas estn orientados exclusivamente generar informacin a
travs de transacciones y no a la consulta y anlisis de la informacin, ya que al aumentar
el volumen de informacin en los sistemas transaccionales se dificulta la consulta de los
datos generados. Como alternativa a esta situacin surgi el concepto de Data Warehouse
(D.W.)
(almacn de datos)
En los tiempos actuales las empresas necesitan depositar toda su confianza en la toma de
decisiones, para lo cual se requieren fuentes de informacin fiables y oportunas, la cuales
brinden a los empleados, jefes de seccin, administrativos, ejecutivos y tambin entes
externos
TABLA DE CONTENIDO
PARTE I PLANIFICACIN Y
CAPITULOIPLAIFICACIONDELPROYECTO
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 informacin con el cual se gestionan y almacena la informacin de ms
de 600 funcionarios.
El sistema utiliza como repositorio de informacin una base de datos cuyo diseo
relacional est orientado mas al almacenamiento que a la consulta y explotacin 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 informacin de los
funcionarios, con lo cual el modelo transaccional sobre la cual est construida la base de
datos dificulta el estudio de la informacin 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
anlisis de localizacin, formateo, presentacin y procesamiento de los datos, como
tambin asignacin de recursos humanos del departamento de sistemas para poder
responderlas, sin tener en cuenta la degradacin de los sistemas transaccionales. Esta
problemtica se debe a que dichos sistemas transaccionales no fueron construidos con el
fin de brindar sntesis, anlisis, consolidacin, bsquedas 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 variacin de los mismos en el tiempo es poco
significativa, la herramienta en la cual estn 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 PROBLEMTICA
No existe una disponibilidad inmediata de la informacin para la generacin de reportes y
consulta de datos de los empleados.
1.4. SITUACION DESEADA
CAPITULOIPLAIFICACIONDELPROYECTO
Contar con un Data Mart que almacene la informacin generada por el sistema de
recursos humanos y que de la posibilidad de acceder dicha informacin de manera
inmediata a travs de una herramienta de consulta.
1.5. JUSTIFICACIN
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 informacin sin
tener que depender de personal tcnico (programadores o analistas de sistemas) que
genere los reportes o consultas ad hoc a travs de un lenguaje y/o herramienta de
programacin, lo cual adems conlleva en disminuir el tiempo de espera en la generacin
de reportes por parte del personal tcnico.
Adems el departamento de RR. HH. Podr manejar la informacin, 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 gestin 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 construccin del Data
Mart.
Analizar y definir las fuentes de datos que permitan alimentar el Data Mart.
Realizar el diseo de la base de datos del Data Mart
Definir los procesos de ETL para alimentar el Data Mart.
Construir una versin Beta de la base de datos y los procesos ETL del Data Mart.
1.7. ALCANCE
La metodologa a utilizar ser El Proceso de Ingeniera para el Data Warehouse (DWEP
por sus siglas en ingles) planteado en la tesis doctoral de Lujn-Mora (Lujn 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
2
CAPITULOIPLAIFICACIONDELPROYECTO
Requerimientos
o Requerimientos funcionales y no funcionales.
o Identificacin de las medidas y dimensiones ms importantes.
o Anlisis de los reportes peridicos que se utilizan actualmente.
o Elaboracin del modelo del dominio
o Elaboracin de los casos de uso ms importantes
Anlisis
o Determinacin de las posibles fuentes de datos
o Elaboracin de los diagramas lgico de la fuente de datos SLS, diagrama
fsico de las fuentes de datos SPS.
Diseo
o Diseo definicin de la estructura del data Warehouse
o Elaboracin del diagrama conceptual del data Warehouse DWCS.
Elaboracin
Requerimientos
o Recoleccin y refinamiento de requerimientos.
o Identificacin de nuevas medidas agregaciones y dimensiones.
Anlisis
o Eleccin de fuentes de datos que alimenta el DM.
o Actualizacin de los diagramas SLS, SPS.
o Elaboracin de los diagramas diagrama conceptual SCS.
Diseo
o Definicin procesos ETL a nivel conceptual.
o Actualizacin del diagrama DWCS.
o Elaboracin del diagrama mapeo de datos de integracin DM.
Implementacin
Elaboracin de las estructuras fsicas.
CAPITULO II
DATA WAREHOUSE Y DATA MART
CAPITULOIIDATAWAREHOUSEYDATAMART
2. INTRODUCCION
Este capitulo muestra los conceptos general de Data Warehouse y Data Mart, ademas de
ser el marco terico referencial.
2.1. DATA WAREHOUSE
Segun Bill Immon (1994) se puede definir a un Data Warehouse como una coleccin de
datos orientada a un determinado mbito (empresa, organizacin, etc.), integrado, no
voltil 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 integracin de los diferentes
temas en una estructura nica es necesaria para que la informacin comn 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 descripcin y una codificacin.
Las diferencias que existen en los datos de las fuentes dependen de la visin deseada por
el usuario, de la utilizacin que se hace, o de los programadores. La integracin de datos
constituye una gran parte de la labor de construir un Data Warehouse y se realiza
mediante los proceso de extraccin, transformacin y carga o procesos ETL.
2.1.3. DATOS HISTRICOS
U Data Warehouse almacena el histrico de datos de la empresa y los datos actuales con
los que cuenta. Suponiendo que cada da se obtienen los datos, cada dato de un da sobre
algo constituye un dato diferente al de otro da sobre lo mismo. Una vez ingresada la
informacin al Data Warehouse, sta no se actualiza, a no ser por casos excepcionales.
2.1.4. DANOS NO VOLTILES
La no volatilidad es, de cierta forma una consecuencia de que los datos sean histricos.
Al no actualizarse los datos, una consulta sobre determinados datos ser siempre la
misma.
2.2. DATA MART
CAPITULOIIDATAWAREHOUSEYDATAMART
Segn la definicin 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 informacin de distintas areas tpicamente es implementado
como el repositorio central de informacin de toda una organizacin, mientras que que un
Data Mart maneja informacin de un departamento en particular. La tabla siguiente
muestra una comparacin de las principales diferencias entre el Data Mart y el Data
Warehouse:
Categora
Data Warehouse
Data Mart
Alcance
Corporativo
rea de Negocios
Temas
Multiples
Simples
Fuentes de Datos
Muchas
Pocas
Tamaos
100 GB-TB+
< 100 GB
Tiempo de implementacin
De meses a aos
Meses
Fuente
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm
2.4. LOS PROCESOS ETL
CAPITULOIIDATAWAREHOUSEYDATAMART
Los procesos ETL son los que permiten a la organizacin mover datos desde distintas
fuentes de datos, formatearlos, purgarlos y cargarlos en otra base de datos, Data Mart o
Data Warehouse (wikipedia 2010).
Es ampliamente reconocido que el diseo y mantenimiento de estos procesos ETL es un
factor clave de xito en los proyectos de Data Warehouse. Debido a la dificultad de
disear y mantener este tipo de procesos, existen muy poca proliferacin 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 caractersticas 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 estn pensadas para soportar procesos transaccionales de
almacenamiento de informacin, los Data Warehouse estn orientados a la consulta y
explotacin de datos, sin embargo es importante mencionar que ambos no son
mutuamente excluyentes si no ms 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 recuperacin 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 informtica distribuida. La tecnologa
OLTP se utiliza en innumerables aplicaciones, como en banca electrnica, procesamiento
de pedidos, comercio electrnico, supermercados o industria.
2.7. OLAP
De acuerdo a Wikipedia(2010) OLAP es el acrnimo en ingles de procesamiento analtico
en lnea. Es una solucin 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 direccin, minera de datos y areas similares.
De acuerdo con Wikipedia(2010) existen distintos tipos de OLAP:
CAPITULOIIDATAWAREHOUSEYDATAMART
ROLAP
Implementacin OLAP que almacena los datos en un motor relacional. Tpicamente, los
datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas.
Los esquemas ms 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 anlisis
de una enorme cantidad de datos.
MOLAP
Esta implementacin OLAP almacena los datos en una base de datos multidimensional.
Para optimizar los tiempos de respuesta, el resumen de la informacin es usualmente
calculado por adelantado. Estos valores precalculados o agregaciones son la base de las
ganancias de desempeo de este sistema. Algunos sistemas utilizan tcnicas de
compresin 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:
Segn Wikipedia(2010) es una base de datos multidimensional, en la cual el
almacenamiento fsico de los datos se realiza en un vector multidimensional. Los cubos
OLAP se pueden considerar como una ampliacin de las dos dimensiones de una hoja de
clculo.
Segn (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 rpido 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.
CAPITULOIIDATAWAREHOUSEYDATAMART
2.8.1. MEDIDAS
El blog oficial para Olap Oracle Corp. En el articulo Olap Workshop 1: Basic OLAP
concepts (2007) nos dice que las medidas representan los datos objetivos, muchas veces
llamadas hechos. Un ejemplo tpico de medidas son las ventas, los costos, ganancias
mrgenes, etc. Las medidas se organizan en una o ms dimensiones. Las medidas estn
por lo general representadas por la forma de un cubo en donde los bordes o aristas del
cubo son las dimensiones y el contenido del cubo son los valores de medida.
http://oracleolap.blogspot.com/2007/12/olap-workshop-1-basic-olap-concepts.html
Existen dos tipos de medidas:
Medidas Almacenadas: son datos cargados, agregados y almacenados directamente en
el Data Warehouse o Data Mart. Un ejemplo de esas puede ser ingresos por ventas,
unidades vendidas, horas trabajadas, etc.
Medidas Calculadas: son el resultado de realizar clculos matemticos estndar en base
a mtricas simples. Por ejemplo el precio promedio de venta, que se calcula dividiendo la
sumatoria total en dlares de las ventas entre unidades vendidas.
Hechos
Los hechos contienen informacin sobre cuantificaciones o datos sobre hechos relevantes
del negocio que quieren ser consultados. Esta informacin a menudo est compuesta por
valores numricos que cuantifican las transacciones o son datos detallados acerca de las
transacciones del negocio en un momento datos. Estos datos son almacenados en una
simple tabla central llamada tabla de hechos. Esta tabla centra o tabla de hechos puede
estar compuesta por muchas columnas y millones de registros, llegando a ocupar espacios
muy considerables en almacenamiento. Ejemplos clsicos de datos almacenados en tablas
de hechos son: registros de ventas, inventarios, movimientos de cuentas, suscripciones,
revistas, etc.
Granularidad
La granularidad es el nivel de detalle de los hechos en un Data Warehouse (Peterson,
1995) . Por ejemplo se determina que el mayor nivel de detalle de un cubo de ventas, es
la cantidad de ventas realizadas por mes, o sea, no llega al detalle de ventas diarias.
2.8.2. DIMENSIONES
CAPITULOIIDATAWAREHOUSEYDATAMART
Las dimensiones identifican y categoriza los datos del negocio. Ejemplos de dimensiones
pueden ser product, geografia, tiempo, canal de distribucion, etc. Las dimensiones son
almacenadas en tablas satlites que estn unidas a las tablas de hechos(Poe, 2007)
Las tablas de dimensiones almacenan toda la informacin asociada con cada dimensin
particular, esto incluye:
Las relaciones de jerarquas de cada dimensin.
Los atributos que describen cada dimensin.
Las dimensiones estn formadas por tres componentes claves:
Jerarquas
Las jerarquas son estructuras lgicas que agrupan datos pertenecientes a una dimensin
con el propsito de analizarlos por ejemplo: si se considera una escala (o dimensin)
temporal "Mayo de 2005" se puede incluir en "Segundo Trimestre de 2005", que a su vez
se incluye en "Ao 2005".
Niveles
10
CAPITULOIIDATAWAREHOUSEYDATAMART
Los niveles representan una posision en una jerarquia. El nivel superiror contiene una
agregacin de valores para el nivel inferior. Cada nivel tienen una relacin uno a muchos
o maestro detalle con su nivel inferior. Por ejemplo una medida de ventas puede
encontrarse en la jerarqua de productos y en un nivel superior en categora de productos
o sub categoras, etc.
Origen : http://oracleolap.blogspot.com/2007/12/olap-workshop-1-basic-olapconcepts.html
Atributos
Los atributos proveen informacin descriptiva hacerca de los datos y son de utilidad
cundo se seleccionan datos para el anlisis por ejemplo:
Seleccin de productos cuyo color (atributo) es Azul.
Seleccin de clientes que tienen dos hijos.
Seleccin de promociones que son de tipo Multipack.
11
CAPITULOIIDATAWAREHOUSEYDATAMART
12
CAPITULOIIDATAWAREHOUSEYDATAMART
desde el centro. El centro de la estrella consiste en una tabla de hechos y las puntas de la
estrella son las tablas de dimensiones como se muestra en la figura siguiente.
http://download.oracle.com/docs/cd/B19306_01/server.102/b14223/schemas.htm
Origen: http://es.wikipedia.org/wiki/Archivo:Esquema_en_estrella.png
2.8.3.2. Copo de Nieve
Segun Oracle Corporation el esquema de copo de nieve es mas complejo que el modelo
de estrella y es una extensin del mismo. Es llamado copo de nieve por que el diagrama
entidad relacin se asemeja a un copo de nieve.
La caracterstica del esquema copo de nieve es que normaliza las dimensiones para
eliminar redundancia. Esto quiere decir que la tabla de dimensiones es distribuida en
distintas tablas pequeas en vez de una tabla grande como se lo hara en una estrella
como se muestra en la figura.
13
CAPITULOIIDATAWAREHOUSEYDATAMART
14
16
17
18
20
PARTE II
ANALISIS Y DISEO DEL DATA MART
CAPITULO 6
REQUERIMIENTOS
6. INTRODUCCION
En este captulo se describen los requerimientos funcionales y no funcionales del Data
Mart.
6.1. REQUERIMIENTOS
Los requerimientos determinan que datos van a estar disponibles en el Data warehouse,
como
estos
datos
estarn
organizado
con
que
frecuencia
estos
sern
actualizados.(Kimbal,1998).
A diferencia del Data Warehouse el Data Mart se centra en proveer informacin 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 informacin de esta rea de la empresa.
6.1.1. REQUERIMIENTOS FUNCIONALES
Los requerimientos del negocio para el departamento de RRHH de la empresa de agua
S.A. son los siguientes:
Datos de Empleados
Mostrar empleados agrupados por su dependencia, o jefe inmediato superior.
Mostrar los empleados departamento al que pertenecen.
Mostrar empleados por seccin a la que pertenecen.
Mostrar empleados por aos de servicio a la empresa.
Mostrar empleados por nivel salarial.
Empleado por Cargo.
Dependientes de un empleado.
Mostrar empleados por apellido paterno y/o materno.
Mostrar empleados por cdigo de trabajador.
Mostrar empleados por fecha de nacimiento.
Mostrar empleados por edad.
Mostrar empleados por grupo sanguneo.
Control de Asistencia y permisos de Empleados
Mostrar asistencia diaria por empleado.
Mostrar atrasos por da de los empleados.
Mostrar permisos a empleados por da.
Mostrar permisos a empleados en la empresa por horas.
Mostrar tipos de permisos por da.
Mostrar atrasos de los empleados por mes.
Mostrar atrasos de los empleados por gerencia por mes.
Mostrar atrasos de los empleados por seccin por mes.
EL Data Mart se construir sobre una Base de Datos Oracle 10g R2, utilizando la
herramienta Oracle Warehouse Builder para el desarrollo y construccin del modelo
dimensional.
6.2. CONTEXTO DEL SISTEMA.
Existen dos aproximaciones para expresar el contexto del sistema en una forma
utilizable para desarrolladores de software: El Modelo del Doinio y el Modelo del
Negocio(Jacobson,2000).
Para el presento proyecto se analizara el modelo del dominio, representado por el
diagrama entidad relacin existente en el actual sistema transaccional de recursos
humanos; por ser la fuente de informacin principal que alimentara el Data Mart.
6.2.1. MODELO DEL DOMINIO
Un modelo del dominio captura los tipos ms importantes de objetos en el contexto del
sistema. Los objetos del dominio representa la cosas que existen o los eventos que
suceden en el entorno en el que trabaja el sistema (Jacobson,2000).
En la figura siguiente se muestra el modelo del dominio el cual contiene los principales
objetos y sus atributos identificados a partir de los requerimientos funcionales. En el
contexto del modelo del Data Warehouse las clases del dominio representan dimensiones
y hechos.
Nro
Clase
EntradaSalida
Faltas
Atraso
Permisos
Suspensin
Vacacin
BajaMedica
Descuento
Descripcin
Anticipo
10
Bono
REFERENCIASBIBLIOGRAFICAS
(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