FACULTAD DE INGENIERA

Carrera Ingeniera de Sistemas

MODALIDAD DE GRADUACIN
Proyecto de Grado











Oscar Marcos Amelunge Ruiz









Santa Cruz - Bolivia
2010
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.





FACULTAD DE INGENIERA

Carrera Ingeniera de Sistemas




MODALIDAD DE GRADUACIN
Proyecto de Grado















Oscar Marcos Amelunge Ruiz
NR. 2003210474

Proyecto de Grado para optar al
grado de Licenciado en Ingeniera de Sistemas




Santa Cruz - Bolivia
2010
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.


ABSTRACT


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

PROBLEMATICA
OBJETIVO
CONTENIDO
CARRERA : Ingeniera de Sistemas
PROFESOR GUIA :
DESCRIPTORES O TEMAS : Data Warehouse, Data Mart, Analisis,
Diseo, Modelo Dimensional.
E-MAIL
: oscar.amelunge@gmail.com
FECHA : 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.

i

TABLA DE CONTENIDO

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



.PARTE I PLANIFICACIN Y
PREPARACIN DEL PROYECTO
CAPITULO I PLAIFICACION DEL PROYECTO
1

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
CAPITULO I PLAIFICACION DEL PROYECTO
2

No existe una disponibilidad inmediata de la informacin para la generacin de reportes y
consulta de datos de los empleados.
1.4. SITUACION DESEADA
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.
CAPITULO I PLAIFICACION DEL PROYECTO
3

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
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.
CAPITULO I PLAIFICACION DEL PROYECTO
4

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
CAPITULO II - DATA WAREHOUSE Y DATA MART
6
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.

CAPITULO II - DATA WAREHOUSE Y DATA MART
7
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
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
CAPITULO II - DATA WAREHOUSE Y DATA MART
8
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
CAPITULO II - DATA WAREHOUSE Y DATA MART
9
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:

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
CAPITULO II - DATA WAREHOUSE Y DATA MART
10
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.

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
CAPITULO II - DATA WAREHOUSE Y DATA MART
11
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
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)



CAPITULO II - DATA WAREHOUSE Y DATA MART
12
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
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.

CAPITULO II - DATA WAREHOUSE Y DATA MART
13

Origen : http://oracleolap.blogspot.com/2007/12/olap-workshop-1-basic-olap-
concepts.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.


CAPITULO II - DATA WAREHOUSE Y DATA MART
14

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
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

CAPITULO II - DATA WAREHOUSE Y DATA MART
15

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.
CAPITULO II - DATA WAREHOUSE Y DATA MART
16

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



CAPITULO III
PROCESO DE INGENIERIA DEL DATA WAREHOUSE
CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE
18
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)
CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE
19
(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:

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
CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE
20
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).

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
CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE
21
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
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
CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE
22
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
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
CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE
23
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.




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 y 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 los hechos y
dimensiones.

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.

Id. Clase Descripcin
H1 EntradaSalida Representa los hechos generados a consecuencia
de las asistencia diaria de los empleados al
trabajo: Fecha, Horas de Ingreso y horas de
salida
H2 Faltas Guarda los hechos por no asistencia de los
empleados al trabajo: Fecha de la falta.
H3 Atraso Almacena los datos por llegadas tarde o atrasos
de los empleados, se almacena la fecha y los
minutos de retraso de los empleados
H4 Permisos Representa los hechos relacionados con los
permisos por hora para salir de la fuente laboral
por cuestiones personale


H5 Suspensin Guarda los hechos que se generan a partir de la
suspensin temporal de un trabajador.
H6 Vacacin Representa todos los hechos asociados a la toma
de vacaciones por parte de los empleados de la
empresa.
H7 BajaMedica Almacena los hechos generados a partir de la
solicitud de una baja mdica autorizada por un
mdico para los empleados.
CL8 Descuento Se utiliza para almacenar los hechos generados
por descuentos realizados al sueldo de los
empleados.
H9 Anticipo Representa los hechos relacionados con anticipos
realizados a los empleados.
H10 Bono Representa los hechos relacionados con bonos a
los sueldos de los empleados.

ID Clase Descripcin
D1 Empleado Representa los empleados de la empresa, as
como los superiores de cada empelado
D2 Dependiente Almacena los dependientes de un empleado de
la empresa
D3 Tipo de Descuento Representa los tipos de descuento que se
realizan a los empleados
D4 Tipo de Bono Representa los tipos de bonos que se dan a los
empleados.


D5 NivelSalarial Representa el nivel salarial en que se encuentra
un empleado.
D6 Cargo Representa el cargo que ocupa un empleado
dentro de la empresa.
D7 rea Representa las reas que existen en la empresa
y las sub ares de cada una.
D8 TipoEntradaSalida Representa los tipos de Entradas y salidas que
se registran en la asistencia al trabajo del
empelado.
D9 TipoFalta Representa los tipos de falta de los empleados
D10 TipoPermiso Representa los tipos de permiso que se dan a
los empleados para ausentarse del trabajo.
D11 TipoAtraso Representa los tipos de atrasos que puede tener
un empleado al no llegar puntual.
D12 TipoSuspencin Representa el de suspensin aplicadas a un
trabajador.


6.3. IDENTIFICACION DE ACTORES
Un actores representa un rol que es jugado por una persona, un dispositivo de hardware
o incluso otro sistema al interactuar con nuestro sistema (Rumbaugh,1999).

Los actores que se identificaron para del Data Mart son los siguientes:

Jefe del Departamento de Recursos Humanos: Es el encargado de la gestin y
administracin del personal, ingresa al sistema con el fin de consultar informacin sobre
todo lo referente a los recursos humanos.


Jefe de la Seccin Control de Personal : es el encargado del control y gestin de
asistencia, permisos, suspensiones, vacaciones y bajas medicas de los empleados, ingresa
al sistema con el fin de consultar informacin analtica referente a dichos aspectos.

Jefe de la Seccin Remuneracin de Personal: es el encargado del control y gestin de
los sueldos, bonos, descuentos realizados a los empleados, ingresa al sistema con el fin de
consultar informacin analtica referente a dichos aspectos.

Auxiliar Control de Personal: encargado de asistir al jefe de la seccin Control de
Personal en las tareas que este cumple, ingresa al sistema con el fin de consultar
informacin analtica.

Auxiliar Remuneracin de Personal: encargado de asistir al jefe de la seccin
Remuneracin de Personal en las tareas que este cumple, ingresa al sistema con el fin de
consultar informacin analtica.

Tcnico de Sistemas: es el encargado de administrar y mantener los procesos ETL que
alimentaran el Data Mart.





En la figura anterior se puede observar la jerarqua y dependencias que existen entre los
actores del sistema.

6.4. CASOS DE USO

Cada caso de uso proporciona uno o ms escenarios que indican cmo debera
interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo
especfico. http://es.wikipedia.org/wiki/Caso_de_uso . En esta seccin se identifican los
casos de uso del Data Mart que vendra a ser la informacin que puntualmente ser
consultada por los usuarios del mismo, en otras palabras los reportes requeridos.

6.4.1. IDENTIFICACION DE LOS CASOS DE USO
Numero CASO DE USO
uc Actors
Jefe del
Departamento de
Recursos Humanos
Jefe de la Seccin
Control de Personal
Jefe de la Seccin
Remuneracin de
Personal
Auxiliar Control de
Personal
Auxiliar Remuneracin
de Personal
Tcnico de Sistemas


CU001 Mostrar Empleados
CU002 Mostrar Empleados y sus dependientes
CU003 Mostrar Empleados por gerencia
CU004 Mostrar Empleados por departamento
CU005 Mostrar Empleados por seccin
CU006 Mostrar Empleados por nivel salarial
CU007 Mostrar Empleados por aos de servicio
CU008 Mostrar Empleados por apellido paterno
CU009 Mostrar Empleados por cdigo de trabajador
CU010 Mostrar Empleado por fecha de nacimiento
CU011 Mostrar Empleados por edad
CU012 Mostrar Empleados por grupo sanguneo
CU013 Mostrar Asistencia
CU014 Mostrar Detalle diario de asistencia de Toda la empresa
CU015 Mostrar reporte diario de asistencia por gerencia
CU016 Mostrar reporte diario de asistencia por hora de llegada
CU017 Mostrar Atrasos
CU018 Mostrar Atrasos diarios
CU019 Mostrar Atrasos diarios por gerencia
CU020 Mostrar Atrasos mensuales
CU021 Mostrar Atrasos Mensuales por gerencia
CU022 Mostrar Atrasos Trimestrales por gerencia
CU023 Mostrar Histrico de atrasos de un empleado
CU024 Mostrar atrasos de los empleados por cantidad de atrasos
CU025 Mostrar Faltas
CU026 Mostrar Faltas Diarias
CU027 Mostrar Faltas Diarias por gerencia
CU028 Mostrar Faltas Mensuales
CU029 Mostrar Faltas Mensuales por gerencia
CU030 Mostrar Histrico de Faltas por empleado
CU031 Mostrar Permisos
CU032 Mostrar permisos por hora
CU033 Mostrar permisos por hora y por dia
CU034 Mostrar permisos por trimestre
CU035 Mostrar Vacaciones
CU036 Mostrar Empleados con vacaciones en el dia
CU037 Mostrar Empleados con vacaciones en la semana
CU038 Mostrar Empleados con vacaciones en el mes
CU039 Mostrar Histrico de vacaciones de un empleado
CU040 Mostrar Baja Medica
CU041 Mostrar detalle diario de bajas medicas


CU042 Mostrar detalle mensual de bajas medicas
CU043 Detalle detalle trimestral de bajas medicas
CU044 Mostrar historico de bajas medicas de un empleado
CU045 Mostrar Planilla Sueldos
CU046 Mostrar Anticipos
CU047 Mostrar Anticipos por empleado por mes
CU048 Mostrar Descuentos
CU049 Mostrar Bonos

6.4.2. ESPECIFICACION DE LOS CASOS DE USO
En esta seccin se describen los casos de uso agrupados de acuerdo a los principales
hechos.

6.4.2.1. CU001 MOSTRAR EMPLEADOS

uc Primary Use Cases
Mostrar Empleado
Mostrar empleados por
numero de dependientes
Mostrar Empleados
por gerencia
Mostrar empleados
por departamento
Mostrar Empleados
por seccion
Mostrar Empleados
por nivel salarial
Mostrar Empleados
por aos de servicio Mostrar empleados
por apellido paterno
Mostrar empleados
por codigo de
trabaj ador
Mostrar empleados
por fecha de
nacimiento
Mostrar empleados
por edad
Mostrar Empleados
por grupo sanguineo
Autenticar Solicitante
Auxiliar Control de
Personal
i ncl ude
extend
extend
extend
extend
extend
extend
extend
extend
extend
extend
extend


Caso de Uso Mostrar Empleado
Id CU001
Actores Auxiliar de control de personal
Precondicin El auxiliar de control de personal debe tener permisos sobre el
cubo de empleados.
Flujo Bsico El caso de uso empieza cuando el usuario elige visualizar el
reporte de Empleados.

El sistema despliega la lista de todos los empleados de la
organizacin con todos sus atributos(Nombre, Apellido Paterno
,etc. )
Pos condicin Ninguna
Puntos de
Extensin
Si el Auxiliar de control de personal elije ver los empleados
por edad se llamara al caso de uso "Mostrar Empleado Por
Edad".
Si el Auxiliar de control de personal elije ver los empleados
por Fecha de Nacimiento se llamara al caso de uso
"Mostrar Empleado por fecha de nacimiento".
Si el Auxiliar de control de personal elije ver los empleados
por cdigo de trabajador se llamara al caso de uso "Mostrar
Empleado por cdigo de trabajador".
Si el Auxiliar de control de personal elije ver los empleados
por Apellido Paterno se llamara al caso de uso "Mostrar
Empleado por apellido paterno".
Si el Auxiliar de control de personal elije ver los empleados
por nivel salarial se llamara al caso de uso "Mostrar
Empleado por nivel salarial".
Si el Auxiliar de control de personal elije ver los empleados
por aos de servicio se llamara al caso de uso "Mostrar
Empleado por aos de servicio".
Si el Auxiliar de control de personal elije ver los empleados
por Seccin se llamara al caso de uso "Mostrar Empleado
por seccin".
Si el Auxiliar de control de personal elije ver los empleados
por Departamento se llamara al caso de uso "Mostrar
Empleado por Departamento".
Si el Auxiliar de control de personal elije ver los empleados


por Gerencia se llamara al caso de uso "Mostrar Empleado
por Gerencia".
Si el Auxiliar de control de personal elije ver los empleados
por numero de Dependientes se llamara al caso de uso
"Mostrar Empleado por seccin".
Si el Auxiliar de control de personal elije ver los empleados
Seccin se llamara al caso de uso "Mostrar Empleado por
seccin".


Diseo lgico de interface


7. ANALISIS
sd Interaction
Empl eado
Nombre
Apel l i doMaterno
Apel l i doPaterno
CuentaBancari a
Di recci onDomi ci l i o
DocumentoIdenti dad
EstadoCi vi l
FechaNaci mi ento
GrupoSangui neo
Li bretaMi l i tar
Naci onal i dad
Sexo
Supervi sor
Mostrar empl eados por numero de dependi entes
Mostrar Empl eados por gerenci a
Mostrar empl eados por departamento
Mostrar Empl eados por secci on
Mostrar Empl eados por ni vel sal ari al
Mostrar Empl eados por aos de servi ci o
Mostrar empl eados por apel l i do paterno
Mostrar empl eados por codi go de trabaj ador
Mostrar empl eados por fecha de naci mi ento
Mostrar empl eados por edad
Mostrar Empl eados por grupo sangui neo
Datos
Opci ones
Empl eado
Nombre
Apel l i doMaterno
Apel l i doPaterno
CuentaBancari a
Di recci onDomi ci l i o
DocumentoIdenti dad
EstadoCi vi l
FechaNaci mi ento
GrupoSangui neo
Li bretaMi l i tar
Naci onal i dad
Sexo
Supervi sor
Mostrar empl eados por numero de dependi entes
Mostrar Empl eados por gerenci a
Mostrar empl eados por departamento
Mostrar Empl eados por secci on
Mostrar Empl eados por ni vel sal ari al
Mostrar Empl eados por aos de servi ci o
Mostrar empl eados por apel l i do paterno
Mostrar empl eados por codi go de trabaj ador
Mostrar empl eados por fecha de naci mi ento
Mostrar empl eados por edad
Mostrar Empl eados por grupo sangui neo
Datos
Opci ones


8. DISEO
9. CONSTRUCCION DEL DATA MART
10. 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