FACULTAD DE INGENIERA

Carrera Ingeniera de Sistemas

MODALIDAD DE GRADUACIN

Proyecto de Grado

DataMartparalagestindereportesyapoyoalatomade
decisionesdeldepartamentodeRR.HH.delaempresadeaguaS.A.

Oscar Marcos Amelunge Ruiz

Santa Cruz - Bolivia

2010

FACULTAD DE INGENIERA
Carrera Ingeniera de Sistemas

MODALIDAD DE GRADUACIN

Proyecto de Grado

DataMartparalagestindereportesyapoyoalatomade
decisionesdeldepartamentodeRR.HH.delaempresadeaguaS.A.

Oscar Marcos Amelunge Ruiz

NR. 2003210474
Proyecto de Grado para optar al
grado de Licenciado en Ingeniera de Sistemas

Santa Cruz - Bolivia

2010

ABSTRACT
TITULO
AUTOR

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.
: Oscar Marcos Amelunge Ruiz.

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)

como lo define Ralph Kimball una copia de las

transacciones de datos especficamente estructurada para la consulta y el anlisis o la

unin 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
extraccin y consulta de los mismos sin importar el amplio volumen de informacin que
pueda existir. Normalmente el alcance que tiene un D.W. llega a ser, toda la informacin
generada empresa, la construccin de un D.W. requiere una inversin en tiempo y
esfuerzo considerable. Una estrategia o concepto alternativo al D.W. que tiene el mismo
fin pero con un alcance ms limitado a un rea o departamento de empresa es el Data
mart. Un Data mart es una versin especial de almacn de datos (Data Warehouse). Son
subconjuntos de datos con el propsito de ayudar a que un rea especfica dentro del
negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden
ser agrupados, explorados y propagados de mltiples formas para que diversos grupos de
usuarios realicen la explotacin de los mismos de la forma ms conveniente segn 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 informacin fiables y oportunas, la cuales
brinden a los empleados, jefes de seccin, administrativos, ejecutivos y tambin 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 informacin que es procesada y almacenada por los Sistemas de
Informatizados de la compaa 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 implementacin de un Data Mart
para una de las areas de empresa mayor estudiada y de mayor preocupacin; los
Recursos Humanos, eje principal del aparato productivo de toda organizacin. La
cantidad de informacin generada por las actividades y procesos concernientes al control
y gestin de recursos humanos en las empresas es substancial, y de la misma pueden
derivarse una gran cantidad de informacin como ser control de asistencias y permisos,
control de vacaciones, planillas de sueldos, pagos de beneficios, etc.

TABLA DE CONTENIDO

.PARTE I PLANIFICACIN Y PREPARACIN DEL PROYECTO......................................................2

PARTE I PLANIFICACIN Y

PREPARACIN DEL PROYECTO

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

Drill Down y Roll Up

Son tcnicas analticas especificas por las cuales los usuarios navegan entre niveles de
detalle de informacin, desde las ms resumida hasta las ms detallada, en el caso del
Drill Down y del detalle a un resumida en el caso del Roll Up. Las jerarquas de la
dimensin son las que establecen los caminos por los cuales los usuarios podrn hacer
tanto un Drill Down como un roll-up, esto debido a que la jerarqua o jerarquas de la
dimensin contienen los niveles de la misma. Por ejemplo viendo la informacin de las
ventas de Norte Amrica, una operacin de Drill Down en la dimensin de regin
mostrara entonces a Canad, Los estados del este, y los estados del Oeste. Al realizar
otra operacin Drill Down en Canad, nos mostrara a Toronto, Vancouver, Montreal, etc.
(Alta Plana 1999).
2.8.3. Esquemas de Cubos
Un esquema es una coleccin de objetos de base de datos (tablas, vistas, ndices,
sinnimos, etc.) esisten dos tipos comunes de esquemas de cubo: en estrella y en copo de
nieve.
2.8.3.1. Estrella
Segun Oracle Corporation el esquema tipo estrella es llamado asi debido a que el diagram
entidad relacion que este forma se asemeja a una estrella con puntas que se originan

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

Fuente wikipedia: http://es.wikipedia.org/wiki/Archivo:Esquema_en_copo_de_nieve.png

14

2.8.3.3. CAPITULO III

PROCESO DE INGENIERIA DEL DATA WAREHOUSE

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE

3. INTRODUCCION
Este captulo hace referencia a la metodologa de El proceso de ingeniera para la
construccin de un Data Warehouse y la extensiones a UML de Diagramas del Data
Warehouse propuesto en la tesis doctoral Diseo de Data Warehouse con UML
(Lujan,2005).
3.1. DESARROLLO DEL DATA WAREHOUSE.
Segn (Lujan, 2005) el objetivo de este mtodo o metodologa de trabajo es optimizar el
proceso de desarrollo del Data Warehouse ms eficiente considerando las siguientes
premisas:
Basar el mtodo en un lenguaje de modelado estndar.
Un mtodo claro y robusto para el desarrollo de un Data Warehouse.
Un mtodo que abarque todos las fases del desarrollo de un Data Warehouse desde la
definicin de los requerimientos hasta la implementacin final.
Para alcanzar estas premisas se Lujan plantea la extensin de el Lenguaje Unificado de
Modelado (UML), para representar las diferentes niveles de detalle por los que pasa el
Data Warehouse durante el ciclo de desarrollo.
3.2. MODELADO DEL DATA WAREHOUSE
La arquitectura del Data Warehouse es usualmente representada con varias capas de
datos en las cuales los datos de una capa son derivados de los datos de la capa anterior. El
desarrollo de un Data Warehouse puede ser estructurado en un framework de cico etapas
y tres niveles que definen diferentes diagramas para el modelado del Data Warehouse
como se muestra en la figura siguiente.
3.2.1. ETAPAS.
3.3. PROCESO DE INGENIERIA DEL DATA WAREHOUSE
El proceso de Ingenieria del Data Warehouse es una metodologa orientada a objetos
basada en el Proceso Unificado de Desarrollo de Software (UP por sus siglas en ingles)
(Jacobson,2000). El Proceso unificado es el estndar en la industria de desarrollo de
software junto con UML (Unified Modeling Language).
El proceso de ingeniera dpara el data warehouse, al ser una instancia del UP(Proceso
Unificado), hereda las siguientes caractersticas del mismo:

16

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE

Dirigido por casos de Uso, es decir que los casos de uso son utilizados para especificar
los requerimientos de un sistema, pero adems, estos dirigen el disenio, implementacin
y pruebas del mismo.
Centrado en la arquitectura, la arquitectura del software engloba los aspectos estaticos y
dinmicos mas significativos del sistema, y es descrita como diferentes vistas del sistema
que se est construyendo.
Iterativo e incremental, el desarrollo de los productos de software es difidido en partes
mas pequeas llamadas iteraciones que resultan en un incremento en el crecimiento del
producto, por otra parte los diagramas no permanecern intactos, deben evolucionar a
medida que pasa el tiempo, y vayan apareciendo nuevos requerimientos.
De acuerdo con el Proceso Unificado el proyecto esta dividido en cuatro fases (Inicio,
Elaboracin, construccin y Transicin) y cinco flujos de trabajo fundamentales
(Requerimientos, Anlisis, Diseo, Implementacin y Pruebas), los flujos de trabajo de
Mantenimiento y Revisin Pot-Desarrollo son aadidos por el Proceso de Ingeniera del
Data Warehouse.
En la figura siguiente se muestra como los 7 flujos de trabajo toman lugar en las cuatro
fases, para cada flujo de trabajo la curva presenta aproximadamente el grado en el cual el
flujo de trabajo es realizado en cada fase.
(Insertar figura del proceso unificado).
Por cada uno de los flujos de trabajo se utiliza diferentes diagramas UML para modelar y
documentar el proceso de desarrollo, pero un modelo puede ser modificado en diferentes
fases porque los modelos evolucionan a travs del tiempo. A continuacin se muestras los
detalles principales de cada flujo de trabajo y los diagramas con los que se trabaja en cada
flujo.
3.3.1. REQUERIMIENTOS
Durante este flujo de trabajo se captura lo que los usuarios finales esperan poder hacer
con el Data Warehouse, los usuarios finales deberan especificar las medidas y
agregaciones mas interesantes, las dimensiones de anlisis, los reportes que utiliza
peridicamente para tomar deciciones, la frecuencia de actualizacin de los datos, etc.
Los requerimientos son modelados utilizando casos de uso como se propone en el libro
developing requeriments for Data Warehouse System with Use Cases (Brukner, 2001).

17

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE

3.3.2. ANALISIS
En este flujo de trabajo se refinan y estructuran los requerimientos que se capturaron en
el anterior flujo de trabajo, adems de identificar y documentar las posibles fuentes de
datos que alimentaran el Data Warehouse.
Se utilizan el Diagrama Conceptual de Fuentes de Datos, Diagrama Logico de las fuentes
de datos y el Diagrama Fisico de las Fuentes de Datos. Para el modelado de las fuentes de
datos que alimentaran el Data Warehouse.
3.3.3. DISENIO
Al finalizar este flujo de trabajo la estructura del Data Warehouse es definida. El
resultado principal de este flujo de trabajo es el modelo conceptual del Data Warehouse,
adems del mapeo de datos desde las fuentes de datos ya definidas hacia el Data
Warehouse y del Data Warehouse hacia las estructuras del cliente.
En este flujo de trabajo se construyen los siguientes diagramas: Diagrama conceptual del
Data Warehouse, Mapeo de Datos de la etapa de Integracin, Diagrama Conceptual del
cliente y Mapeo de Datos de la etapa de personalizacin, (DWCS, DM, CCS y DM). Los
dos ltimos diagramas son aplicados en el caso de que existan Data Marts coo clientes en
una estrategia top-down y en el caso de que exista un data Warehouse como cliente en
una estrategia bottom-up.
3.3.4. IMPLEMENTACION
En este flujo de trabajo se construye el Data Warehouse, se construyen las estructuras
fsicas del Data Warehouse, el Data Warehouse es llenado y ajustado para un rendimiento
ptimo. Para esto se pueden utilizar diferentes diagramas, a continuacin se mencionan
los principales: diagrama lgico del Data Warehouse (DWLS), diagrama Fsico del Data
Warehouse (DWPS), Diagrama Lgico del cliente (CLS), Diagrama Fsico del cliente
(CPS), Diagrama de Procesos ETL, Procesos de Exportacin y diagramas de transporte.
Los diagramas: Diagrama Lgico del Cliente (CLS), Proceso de Exportacion y Diagrama
Fsico del Cliente (CPS) son utilizados en el caso de que existan Data Marts como
clientes en una estrategia top-down y en el caso de que exista un data Warehouse como
cliente en una estrategia bottom-up punto 3.3.8.
3.3.5. PRUEBAS

18

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE

El objetivo de este flujo de trabajo es verificar que la implementacin funcione de
acuerdo a lo deseado. Mas espeficicamente el propsito de las pruebas es:
Planear las pruebas requeridas.
Diseara y realizar la pruebas a travs de los casos de prueba requeridos.
Ejecutar las pruebas y analizar los resultados de las mismas.
Ningn diagrama nuevo es creado, pero los diagramas existentes son modificados de
acuerdo a las acciones correlativas tomadas y cambios realizados por motivo de las
pruebas.
3.3.6. MANTENIMIENTO
A diferencia de muchos sistemas, el Data Warehouse nunca est terminado. El objetivo
principal de este flujo de trabajo es el de mantener los proceso de carga y actualizacin
necesarios para que la informacin del Data Warehose este actualizada, este flujo de
trabajo comienza cuando el Data Warehouse ha sido construido y entregado a los usuarios
finales, pero no tiene una fecha fin, ya que dura mientras se encuentre en vigencia el Data
Warehouse.
Durante este flujo de trabajo puede ocurrir que los usuarios generen nuevos
requerimientos como nuevas consultas, lo cual genera una nueva iteracin.
3.3.7. REVISION POST-DESARROLLO
Esta tarea no forma parte del flujo de trabajo en el desarrollo del Data Warehouse, pero es
una revisin de los procesos para realizar mejoras en futuros proyectos. Se debe mirar y
revisar el Data Warehouse, la documentacin creada, y tratar de identificar oportunidades
de mejora y xito para tomar en cuenta. Si durante el proceso se realizo un registro de los
tiempos y esfuerzo utilizado, esta informacin puede ser una fuente de informacin muy
til para futuros proyectos.
3.3.8. ESTRATEGIAS DE CONSTRUCCION PARA UN DATA WAREHOUSE
Existen dos estrategias para la construccin de un data Warehouse, estas son: Top-Dwon
y Bottom-UP. La estrategia Top-Down establece que el Data Warehouse se construya
primero y posteriormente se construyan los data Marts del Data Warehouse padre. La
estrategia de Bottom-Up usa una seriae de Data Marts incrementales que son finalmente
integrados para construir el Data Warhouse. Cada estrategia tiene sus propias fortalezas y
sus propias debilidades. Sin embarto, en la mayora de los proyectos, los Data Marts son
19

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE

construidos de manera independiente, es decir, sin la construccin de un data warehouse
integrado, lo cual ocasiona que el Datawarehouse no se vea como un repositorio
monoltico sino mas bien simplemente como una coleccin de Data Marts.
El proceso de Ingenieria del Data Warehouse premite la utilizacin de cualquiera de las
dos estrategias, el data Warehouse es construido primero y las fuentes de datos son los
sistemas transaccionales: luego cada Data Mart es construido independientemente
utilizando la misma metodologa, con la diferencia de que cada data Mart tiene como
fuente de datos al Data Warehouse, en el caso de la estrategia Botton-up $poner figura$ ,
los data Marts son construidos primero, y estos se alimenta de los sistemas
transaccionales; luego el data Warehouse es construido y utiliza como fuentes de datos
los Data Marts.

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.

Mostrar histrico de atrasos de un empleado.

Mostrar histrico de permisos de un empleado.
Mostrar detalle trimestral de permisos por hora.
Mostrar detalle trimestral de permisos por hora de un empleado.
Mostrar detalle trimestral de atrasos.
Mostrar detalle mensual de bajas mdicas.
Mostrar detalle trimestral de bajas mdicas.
Mostrar faltas de un empleado.
Mostrar bajas mdicas de un empleado.
Mostrar atrasos de los empleados ordenados por la cantidad de atrasos.
Mostrar permisos de los empleados a cuenta de vacacion.
Mostrar detalle mensual de empleados con vacacin.
Mostrar detalle de vacaciones pendientes.
Planilla de sueldos
Mostrar reporte de sueldos por mes.
Mostrar reporte de sueldos por mes por empleado.
Mostrar reporte de sueldos trimestral.
Mostrar reporte de sueldo trimestral por mes por empleado.
Mostrar anticipos de sueldo.
Mostrar descuentos por empleados.
Mostrar sobregiros de los empleados.
Mostrar reporte de formularios RC-IVA presentados por los empleados.
Mostrar descuentos por RC-IVA de los empleados.
Mostrar detalles de planilla de transporte.
Mostrar detalles de planilla de subsidios.
Mostrar reporte de aguinaldos.
Mostrar reporte de aportes AFP.
6.1.2. REQUERIMIENTOS NO FUNCIONALES
6.1.2.1. ACCESIBILIDAD
Las funcionalidades del Data Mart solo deben ser accesibles para los usuarios del rea de
Recurso Humanos as como tambin la carga de datos.
6.1.2.2. RENDIMIENTO
El rendimiento del Data Mart debe ser superior a las herramientas utilizadas para la
consulta en los sistemas transaccionales.
6.1.2.3. HERRAMIENTAS

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

6.2.2. DESCRIPCIN DE LAS CLASES DEL DOMINIO

Una clase es una descripcin de un conjunto de objetos que comparten los mismos
atributos como operaciones, relaciones y semntica(Rumbaugh, 1999). En el cuadro
siguiente se describen los hechos y en la tabla posterior se describen las dimensiones.
7. ANALISIS
8. DISEO
9. CONSTRUCCION DEL DATA MART
10. CONCLUCIONES Y RECOMENDACIONES
PARTE III
COSTRUCCION Y PRUEBAS DEL DATA MART
PARTE IV
CONCLUSIONES Y RECOMENDACIONES

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