Avance 020

FACULTAD DE INGENIERA
Carrera Ingeniera de Sistemas
MODALIDAD DE GRADUACIN
Proyecto de Grado
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
Santa Cruz - Bolivia

2010
FACULTAD DE INGENIERA
Carrera Ingeniera de Sistemas
MODALIDAD DE GRADUACIN
Proyecto de Grado
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

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
: Ingeniera de Sistemas
: Ing. Germn Suarez
: Data Warehouse, Data Mart, Analisis,
Diseo, Modelo Dimensional.
E-MAIL
: oscar.amelunge@gmail.com
: Julio de 2010.
FECHA
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
CAPITULO I PLAIFICACION DEL PROYECTO

1. PLANIFICACION DEL PROYECTO
1.1. INTRODUCCION
1.2. DEFINICION DEL PROBLEMA

El departamento de Recursos Humanos de la empresa de agua S.A. cuenta actualmente
con un sistema de 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

1

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 a travs de una
herramienta de consulta, reduciendo la dependencia de personal tcnico (programadores
y/o administradores de base de datos).
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
reduciendo la dependencia 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 proceso de elaborar un
requerimiento, explicar este requerimiento al programador, esperar a que el programador
comprenda y programe el requerimiento, validar u observar el trabajo realizado por el
programador, etc.
Adems el departamento de RR. HH. podr manejar la informacin, examinarla desde

diferentes puntos de vista 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
2

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
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 Mart.
o Elaboracin del diagrama conceptual del Data Mart DMCS.
Elaboracin
Requerimientos
o Recoleccin y refinamiento de requerimientos.
o Identificacin de nuevas medidas agregaciones y dimensiones.
3

o Revisin de los casos de uso y elaboracin de nuevos casos de uso.
Anlisis
o Eleccin de fuentes de datos que alimenta el Data Mart.
o Actualizacin del diagrama lgico de las fuentes de datos SLS y el
diagrama fsico de las fuentes de datos SPS.
o Elaboracin del diagrama conceptual de las fuentes de datos SCS.
Diseo
o Definicin procesos a nivel conceptual de los ETL mas importantes
(mapeo de datos) desde la fuente de datos hacia el Data Mart.
o Actualizacin del diagrama conceptual del Data Mart DMCS.
o Elaboracin del diagrama mapeo de datos de integracin del Data Mart.
Implementacin
o Elaboracin de las estructuras fsicas del Data Mart.
o Elaboracin de los diagramas, Diagrama lgico del Data Mart, Diagrama
fsico del Data Mart, Diagramas de procesos ETL de integracin.
Pruebas
o Planeacin de pruebas.
o Diseo de los casos de prueba.
o Realizacin de las pruebas en base a los casos de pruebas.
o Resultados y correcciones.
Construccin
Anlisis
o Actualizacin de los diagramas: diagrama lgico de la fuente de datos,
diagrama fsico de la fuente de datos diagrama conceptual de la fuente de
datos.
Diseo
o Actualizacin y definicin de los nuevos procesos ETL a nivel conceptual
(mapeo de datos) desde las fuentes de datos hacia el Data Mart.
o Actualizacin de los diagramas conceptual del Data Mart (DMCS) mapeo
de datos de integracin.
Implementacin
4

o Implementacin final de las estructuras fsicas del Data Mart.
o Implementacin de las herramientas de consulta de los usuarios del Data
Mart.
Pruebas
o Diseo de los casos de prueba.
o Realizacin de las pruebas
o Resultados y correcciones.
CAPITULO II
DATA WAREHOUSE Y DATA MART
CAPITULO II - DATA WAREHOUSE Y DATA MART

2. INTRODUCCION
Este captulo muestra los conceptos general de Data Warehouse y Data Mart, adems 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
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
Fuente
De meses a aos
Meses
http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm
2.4. LOS PROCESOS ETL

Los procesos ETL son los que permiten a la 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:
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
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
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)
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.
13
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.
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
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.
16
Fuente wikipedia: http://es.wikipedia.org/wiki/Archivo:Esquema_en_copo_de_nieve.png
17
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 Ingeniera del Data Warehouse es una metodologa orientada a objetos
basada en el Proceso Unificado de Desarrollo de Software (UP por sus siglas en ingles)
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 para 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 diseo, implementacin y
pruebas del mismo.
Centrado en la arquitectura, la arquitectura del software engloba los aspectos estticos 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
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 ms interesantes, las dimensiones de anlisis, los reportes que utiliza
peridicamente para tomar decisiones, 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 Fsico 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
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
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 embargo, 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
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.
24
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 Generales de Empleados

Mostrar los empleados por gerencia a la que pertenecen
Mostrar los empleados departamento al que pertenecen.
Mostrar empleados por seccin a la que pertenecen.
Los datos generales de los empleados incluyen: Cdigo de Empleado, Nombre, Apellido
Paterno, Apellido Materno, nmero de cuenta bancaria, direccin del domicilio, estado
civil, fecha de nacimiento, grupo sanguneo, libreta de servicio militar, nacionalidad,
sexo, nivel salarial , el supervisor del empleado.
La actualizacin de los datos de empleado deber tener frecuencia diaria, cada vez que se
actualice alguno de los datos que se incluyen para el Data Mart, deber registrarse un
histrico del cambio de los datos afectados.
Adicional a los datos de empleados el Data Mart debe permitir el almacenado y consulta
de los datos demogrficos del empleado, como ser seccin, departamento y gerencia
donde este trabaja y el histrico de donde trabajo durante sus aos de servicio en la
empresa, los datos demogrficos tienen una frecuencia de actualizacin por periodos
mensuales.
Entradas y salidas 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.
H1
Clase
EntradaSalida
Descripcin
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.
H7
BajaMedica
Almacena los hechos generados a partir de la

solicitud de una baja mdica autorizada por un
mdico para los empleados.
ID
D8
Clase
Empleado
Descripcin
Representa los empleados de la empresa, as
como los superiores de cada empelado
D10
NivelSalarial
Representa el nivel salarial en que se encuentra

un empleado.
D11
Cargo
Representa el cargo que ocupa un empleado

dentro de la empresa.
D12
rea
Representa las reas que existen en la empresa

y las sub ares de cada una.
D13
TipoEntradaSalida
Representa los tipos de Entradas y salidas que

se registran en la asistencia al trabajo del
empelado.
D14
TipoFalta
Representa los tipos de falta de los empleados
D15
TipoPermiso
Representa los tipos de permiso que se dan a

los empleados para ausentarse del trabajo.
D16
TipoAtraso
Representa los tipos de atrasos que puede tener

un empleado al no llegar puntual.
D17
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:
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.
Tcnico de Sistemas: es el encargado de administrar y mantener los procesos ETL que

alimentaran el Data Mart.
uc Actors
Tcnico de Sistemas
Auxiliar Control de
Personal
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

En esta seccin se identifican y codifican los casos de uso detectados.
Numero
CASO DE USO
CU001
CU002
Mostrar histrico de empleados

Mostrar histrico de empleados por gerencia
CU003
Mostrar histrico de empleados por departamento
CU004
Mostrar histrico de empleados por seccin
CU007
CU008
Mostrar Asistencia
Mostrar asistencia diaria
CU009
Mostrar asistencia diaria por gerencia
CU010
CU011
Mostrar Atrasos
Mostrar atrasos diarios
CU012
Mostrar atrasos diarios por gerencia
CU013
CU014
Mostrar Faltas
Mostrar faltas diarias
CU015
Mostrar faltas diarias por gerencia
CU016
CU017
Mostrar Permisos
Mostrar permisos por hora
CU018
Mostrar permisos por dia
CU019
CU020
Mostrar Baja Medica

Mostrar bajas medicas por dia
CU021
Mostrar bajas medicas por mes
CU022
Mostrar Suspenciones
CU023
Mostrar suspenciones por dia
CU024
CU025
CU026
CU027
Mostrar suspenciones por mes

Programar tareas de carta de datos del Data mart
Ejecutar tarea de carga de datos
Autenticar Solicitante
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 HISTORICO DE EMPLEADOS
Mostrar historico de empleados

por gerencia
<<extend>>
(from Seguridad)
<<include>>
<<extend>>
por departamento

<<extend>>
por seccion
Auxiliar de control de personal
(from Use Case Vi ew)
Caso de Uso
Mostrar histrico de empleados
Id
CU001
Actores
Precondicin
El auxiliar de control de personal debe tener permisos sobre los
datos de empleados.
Flujo Bsico
El caso de uso comienza cuando el actor Auxiliar de control de

personal ingresa al reporte de mostrar empleados.
El sistema despliega la pantalla de autenticacin.
El empleado introduce el usuario y contrasea correspondiente.
El sistema muestra la lista histrica de empleados y sus atributos
en una tabla dinmica, y las opciones de filtrado de gestin por
periodo (ao y mes).
El usuario utiliza las opciones presentadas por la tabla dinmica
para construir el reporte de su preferencia en base a los datos de
empleado mostrados.
Pos condicin
Ninguna
Puntos de
Extensin
Si el Auxiliar de control de personal elije ver los empleados por

gerencia se llamara al caso de uso "Mostrar empleados por
gerencia".
departamento se llamara al caso de uso "Mostrar empleados por
departamento".
seccin se llamara al caso de uso "Mostrar empleados por
seccin".
Diseo lgico de interface
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
*
+Tiene
+Presente
Periodo
-
Diseo fsico de interface
Ao
Mes
6.4.2.2. CU002 MOSTRAR HISTRICO DE EMPLEADOS POR GERENCIA

<<extend>>


por gerencia
(from Use Case View)
Caso de Uso
Mostrar histrico de empleados por gerencia
Id
CU003
Actores
Auxiliar Control de personal
Precondicin
Ejecucin del CU001
Flujo Bsico

periodo (ao y mes).
El usuario arrastra selecciona la dimensin de area y con esta filtar
los empleados por gerencia.
empleado mostrados.
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
+Esta Compuesta
*
+Trabaja
Periodo
Ao
Mes
+Existe
*
Diseo Fsico de Interface
CodificacionGerencia
NombreGerencia
+Tiene
+Tiene
+Presente
Gerencia
6.4.2.3. CU003 MOSTRAR HISTORICO DE EMPLEDOS POR

DEPARTAMENTO
<<extend>>

por departamento

Caso de Uso
Mostrar histrico de empleados por departamento
Id
CU003
Actores
Auxiliar de Control de Personal
Precondicin
Flujo Bsico

periodo (ao y mes).
El usuario arrastra selecciona la dimensin de rea y con esta
filtrar los empleados por gerencia.
El usuario filtra dentro de la gerencia los empleados por
departamento.
empleado mostrados.
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
+Esta Compuesta
*
+Trabaja
Periodo
Ao
Mes
+Existe
*
Diseo fsico de interface
CodificacionDepartamento
NombreDepartamento
+Tiene
+Tiene
+Presente
Departamento
6.4.2.4. CU004 MOSTRAR HISTORICO DE EMPLEADOS POR SECCION

<<extend>>


por seccion
Caso de Uso
Mostrar histrico de empleados por seccin
Id
CU004
Actores
Precondicin
Flujo Bsico

periodo (ao y mes).
El usuario arrastra selecciona la dimensin de rea y con esta
filtrar los empleados por gerencia.
El usuario filtra dentro de la gerencia los empleados por
departamento.
El usuario filtra dentro de los departamentos los empleados por
seccin.
empleado mostrados.
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
sd Interaction
Empleado
-
Nombre
ApellidoMaterno
ApellidoPaterno
CuentaBancaria
DireccionDomicilio
DocumentoIdentidad
EstadoCivil
FechaNacimiento
GrupoSanguineo
LibretaMilitar
Nacionalidad
Sexo
+Esta Compuesta
*
+Trabaja
Periodo
Ao
Mes
+Existe
*
Diseo Fsico de interface
CodificacionSeccion
NombreSeccion
+Tiene
+Tiene
+Presente
Seccion
6.4.2.5. MOSTRAR ASISTENCIA

uc Asistencia
Mostrar asistencia
diaria
extend
Mostrar Asistencia
extend
Mostrar asistencia
diaria por gerencia
Caso de Uso
Mostrar Asistencia
Auxiliar Control de
Personal
(from Actors)
Id
CU007
Actores
Precondicin
Flujo Bsico
El caso de uso comienza cuando el Auxiliar de control de

personal selecciona la dimensin de Asistencia de la lista de las
dimensiones y medidas, haciendo doble clic o arrastrando a
cualquiera de las reas permitidas para dimensiones de la tabla
dinmica.
La tabla dinmica se actualiza mostrando los datos de asistencia
de empleados.
Pos condicin
Ninguna
Puntos de
Extensin
Mostrar Asistencia Diaria

Mostrar Asistencia por Gerencia
6.4.2.6. MOSTRAR ASISTENCIA DIARIA

uc Asistencia
Mostrar asistencia
diaria
extend
Mostrar Asistencia
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar Asistencia diaria
Id
CU008
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin de tiempo de la lista de las
dinmica.
Luego selecciona el periodo diarios con los datos de asistencia
que desea visualizar.

de empleados para la fecha seleccionada.
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
6.4.2.7. MOSTRAR ASISTENCIA DIARIA POR GERENCIA

uc Asistencia
Mostrar asistencia
diaria por gerencia
extend
Mostrar Asistencia
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar Asistencia por gerencia
Id
CU009
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin reas de la lista de las
dinmica.
Luego selecciona la jerarqua gerencias y posteriormente la
gerencia que desea visualizar.
de empleados de la gerencia seleccionada.
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
6.4.2.8. MOSTRAR ATRASOS
uc Atrasos
Mostrar atrasos
diarios
extend
Mostrar Atrasos
Mostrar atrasos
diarios por gerencia
Auxiliar Control de
Personal
(from Actors)
extend
Caso de Uso
Mostrar Atrasos
Id
CU010
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin de Atrasos de la lista de las
dinmica.
La tabla dinmica se actualiza mostrando los datos de atrasos de
empleados.
Pos condicin
Ninguna
Puntos de
Extensin
Mostrar atrasos diarios.

Mostrar atrasos por gerencia.
6.4.2.9. MOSTRAR ATRASOS DIARIOS

uc Atrasos
Mostrar atrasos
diarios
extend
Mostrar Atrasos
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU011
Actores
Auxiliar de Control de Personal.
Precondicin
Flujo Bsico

personal selecciona la dimensin de Tiempo de la lista de las
dinmica.
Luego selecciona el periodo diarios con los datos de atrasos que
desea visualizar.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.10. MOSTRAR ATRASOS DIARIOS POR GERENCIA

uc Atrasos
Mostrar atrasos
diarios por gerencia
extend
Mostrar Atrasos
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar Atrasos por gerencia
Id
CU012
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin reas de la lista de las
dinmica.
Luego selecciona la jerarqua gerencias y posteriormente la
gerencia que desea visualizar.

empleados de la gerencia seleccionada.
Pos condicin
Ninguna
Puntos de
Extensin
Ninguno
6.4.2.11. MOSTRAR FALTAS

uc Faltas
extend
Mostrar Faltas
por gerencia
extend
Caso de Uso
Mostrar Atrasos
Id
CU013
Actores
Auxiliar Control de
Personal
(from Actors)
Precondicin
Flujo Bsico

personal selecciona la dimensin de Faltas de la lista de las
dinmica.
La tabla dinmica se actualiza mostrando los datos de faltas de
empleados.
Pos condicin
Ninguna
Puntos de
Extensin

6.4.2.12. MOSTRAR FALTAS DIARIAS
uc Faltas

extend
Mostrar Faltas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU014
Actores
Precondicin
Flujo Bsico

dinmica.
Luego selecciona el periodo diario con los datos de atrasos que
desea visualizar.
empleados para la fecha seleccionada.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.13. MOSTRAR FALTAS DIARIAS POR GERENCIA

uc Faltas

por gerencia
extend
Mostrar Faltas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU015
Actores
Precondicin
Flujo Bsico

dinmica.
desea visualizar.
La tabla dinmica se actualiza mostrando los datos de faltas de
empleados para la fecha seleccionada.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.14. MOSTRAR PERMISOS

uc Permisos
Mostrar permisos por

dia
extend
Mostrar Permisos
extend
Auxiliar Control de
Personal
(from Actors)

hora
Caso de Uso
Mostrar Premisos
Id
CU016
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin de Permisos de la lista de las

dinmica.
La tabla dinmica se actualiza mostrando los datos de permisos
de empleados.
Pos condicin
Ninguna
Puntos de
Extensin

6.4.2.15. MOSTRAR PERMISOS POR HORA

uc Permisos

hora
extend
Mostrar Permisos
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar permiso por hora.
Id
CU017
Actores
Precondicin
Flujo Bsico

dinmica.
Luego selecciona el periodo diario y horario con los datos de
atrasos que desea visualizar.
por hora de empleados para la fecha seleccionada.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.16. MOSTRAR PERMISOS POR DIA
uc Permisos

dia
Mostrar Permisos
extend
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar permiso por da.
Id
CU018
Actores
Precondicin
Flujo Bsico

dinmica.
desea visualizar.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.17. MOSTRAR BAJAS MEDICAS
uc Baj a Medica
Mostrar Baj as
medicas por dia
extend
Mostrar Baj as
Medicas
Auxiliar Control de
Personal
(from Actors)
extend
Mostrar Baj as
medicas por mes
Caso de Uso
Mostrar Bajas Medicas
Id
CU019
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin de Bajas Medicas de la lista de
las dimensiones y medidas, haciendo doble clic o arrastrando a
dinmica.
La tabla dinmica se actualiza mostrando los datos de Bajas
Medicasde empleados.
Pos condicin
Ninguna
Puntos de
Extensin
Mostrar bajas mdicas por da.

Mostrar bajas mdicas por mes.
6.4.2.18. MOSTRAR BAJAS MEDICAS POR DIA

uc Baj a Medica
Mostrar Baj as
medicas por dia
extend
Mostrar Baj as
Medicas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU020
Actores
Precondicin
Flujo Bsico

dinmica.
Luego selecciona el periodo diario con los datos de bajas
medicas que desea visualizar.
La tabla dinmica se actualiza mostrando los datos de bajas
medicas de empleados para el periodo seleccionada.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.19. MOSTRAR BAJAS MEDICAS POR MES

uc Baj a Medica
Mostrar Baj as
medicas por mes
extend
Mostrar Baj as
Medicas
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Id
CU021
Actores
Precondicin
Flujo Bsico

dinmica.
Luego selecciona el periodo mensual con los datos de bajas

medicas que desea visualizar.
La tabla dinmica se actualiza mostrando los datos de bajas
mdicas de empleados para el periodo seleccionado.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.20. MOSTRAR SUSPENCIONES

uc Suspenciones
Mostrar suspenciones
por dia
extend
Mostrar
Suspenciones
extend
Auxiliar Control de
Personal
(from Actors)
Mostrar
suspenciones por
mes
Caso de Uso
Mostrar Suspensiones
Id
CU022
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin de Suspensiones de la lista de las
dinmica.
La tabla dinmica se actualiza mostrando los datos de
suspensiones de empleados.
Pos condicin
Ninguna
Puntos de
Extensin

6.4.2.21. MOSTRAR SUSPENCIONES POR DIA

uc Suspenciones
Mostrar suspenciones
por dia
extend
Mostrar
Suspenciones
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar bajas suspensiones por da.
Id
CU023
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin de Suspensiones de la lista de las
dinmica.
Luego selecciona el periodo diario con los datos de suspensiones
que desea visualizar.
suspensiones de empleados para el periodo seleccionada.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.22. MOSTRAR SUSPENCIONES POR MES

uc Suspenciones
Mostrar
suspenciones por
mes
extend
Mostrar
Suspenciones
Auxiliar Control de
Personal
(from Actors)
Caso de Uso
Mostrar bajas suspenciones por mes.
Id
CU024
Actores
Precondicin
Flujo Bsico

personal selecciona la dimensin de Suspenciones de la lista de las
dinmica.
Luego selecciona el periodo mensual con los datos de
suspensiones que desea visualizar.
suspensiones de empleados para el periodo seleccionado.
Pos condicin
Ninguna.
Puntos de
Extensin
Ninguno.
6.4.2.23. PROGRAMAR TAREAS DE CARGA DEL DATA MART

uc Carga de Datos
Programar tareas de
carga del Data Mart
Tcnico de Sistemas
(from Actors)
6.4.2.24. EJECUTAR TAREAS DE CARGA DE DATOS

uc Carga de Datos
Ej ecutar tareas de
carga del Data Mart
Tcnico de Sistemas
(from Actors)
6.4.2.25. AUTENTICAR SOLICITANTE
uc Seguridad
7. ANALISIS
En este captulo se realiza el anlisis de la arquitectura del del Data Mart y se define las
fuentes de datos a un nivel conceptual, lgico y fsico.
7.1. ANLISIS DE LA ARQUITECTURA

El propsito del anlisis e la arquitectura es esbozar el Modelo del Anlisis y la
arquitectura mediante la identificacin de paquetes del anlisis y clases del
anlisis(Rumbaugh,1999).
7.1.1. IDENTIFICACION DE PAQUETES DEL ANLISIS A PARTIR DE LOS
CASOS DE USO.
Los paquetes se utilizan para organizar los elementos de modelado en partes mayores
que se pueden manipular como un grupo. Tambin se pueden emplear los paquetes para
representar diferentes vistas de la arquitectura el sistema (Rumbaugh,1999).
7.1.1.1. PAQUETE CARGA DE DATOS

A partir de los casos de uso CU0026 Ejecutar tareas de carga del Data Mart y el caso
de uso CU025 Programar tareas de carga del Data Mart, se puede identificar el paquete
Cargar Datos.
Cargar Datos
Ejecutar tareas de carga del Data

Mart
Programar tareas de carga del

Data Mart
(from Cargar Datos)
(from Cargar Datos)
7.1.1.2. PAQUETE SEGURIDAD

El caso de uso CU0027 Autenticar Solicitante da origen al caso de uso seguridad.
Seguridad
(from Seguridad)
7.1.1.3. PAQUETE EMPLEADO

A partir del CU001 Mostrar Empleado y sus extensiones CU002 Mostrar empleados
por gerencia, CU003 Mostrar empleados por departamento, CU004 Mostrar
empleados por seccin, CU005 Mostrar empleados por nivel salarial y CU006
Mostrar subalternos de empleados se puede identificar el paquete Empleado.
Empleado

por gerencia
(from Empl eado)
<<extend>>
por departamento
(from Empl eado)
<<extend>>
(from Empl eado)
<<extend>>
por seccion
(from Empl eado)
7.1.1.4. PAQUETE CONTROL DE PERSONAL
7.1.1.4.1. SUB-PAQUETE ASISTENCIA

El caso de uso CU007 Mostrar Asistencia y sus extensiones, CU008 Mostrar
asistencia diaria, CU009 Mostrar asistencia diaria por gerencia, dan origen al suppaquete Asistencia.
7.1.1.4.2. SUB-PAQUETE ATRASOS

El caso de uso CU010 Mostrar Atrasos y sus extensiones, CU011 Mostrar atrasos
diarios, CU012 Mostrar atrasos diarios por gerencia, dan origen al sup-paquete
Asistencia.
7.1.1.4.3. SUB-PAQUETE FALTAS

El caso de uso CU013 Mostrar Faltas y sus extensiones, CU014 Mostrar faltas
diarias, CU015 Mostrar faltas diarias por gerencia, dan origen al sup-paquete Faltas.
7.1.1.4.4. SUB-PAQUETE PERMISOS

El caso de uso CU016 Mostrar Permisos y sus extensiones, CU017 Mostrar permisos
por hora, CU018 Mostrar permisos por das, dan origen al sub-paquete Permisos.
7.1.1.4.5. SUB-PAQUETE BAJAS MEDICAS

A partir del caso de uso CU019 Mostrar Bajas Medicas y sus extenciones CU020
Mostrar bajas medicas por da y CU0021 Mostrar majas medicas por mes se
identifica al sub-paquete bajas medicas.
7.1.1.4.6. SUB-PAQUETE SUSPENCIONES

A partir del caso de uso CU022 Mostrar Suspensiones y sus extensiones CU023
Mostrar suspensiones por da y CU0024 Mostrar suspensiones por mes se identifica
al sub-paquete bajas medicas.
7.1.2. MODELO DE ANALISIS

Segn Jacobson (2000) el Modelo de Anlisis es una jerarqua de paquetes de anlisis
que organiza y divide el sistema en partes ms manejables. Como se puede ver en la
figura siguiente se crearon 4 paquetes de anlisis donde el paquete Carga de Datos se
encarga de las funciones de programacin y carga del Data Mart, el paquete Seguridad
se encarga de las validaciones de acceso al Data Mart y los dems paquetes y subpaquetes representan cada uno un tema de anlisis.
7.2. DEFINICIN DE FUENTES DE DATOS

Segn la publicacin de oracle corporation Oracle datamar.pdf Las fuentes de datos son
el origen o los orgenes de donde se toma la informacin para alimentar el Data Mart. Por
lo general estas fuentes de datos estn conformadas por los registros de los sistemas
operacionales con los que cuenta la empresa, archivos de texto, hojas de calculo,
documentos, etc.
7.2.1. NIVEL CONCEPTUAL

En el nivel conceptual de la definicin de las fuentes de datos la meta principal es
conocer que datos se encuentran disponibles para el Data Mart (Lujan,2005). Para lograr
esete objetivo se utiliza el Diagrama Conceptual de la Fuente de Datos (SCS) por sus
siglas en ingles, el cual es un simple diagrama de clases que representa solamente las
clases persistentes de los sistemas operacionales de donde se obtienen los datos.
En la figura siguiente se muestra el diagrama conceptual de la fuente de datos del Data

mart. Esta fuente de datos esta constituida por el esquema RRHH de la base de datos
Oracle de la empresa de agua S.A., la cual almacena la informacin operacional del
departamento de RR.HH. En este diagrama se muestran las clases y atributos que
intervienen el el proceso de carga del Data Mart.
7.2.2. NIVEL LOGICO

La definicin de las fuentes en el nivel lgico se realiza mapeando las fuentes desde el
diagrama de nivel conceptual. El disenio lgico se enfoca en bases de datos relacionales,
por lo que se utiliza un perfil llamado UML profile for database desing creado por
Rational Software para modelar bases de datos con uml.
En la figura siguiente se muestra como se encuentra actualmente implementadas las

estructuras de datos del sistema operacional del departamento de RRHH, las cuales se
utilizan para alimentar el Data Mart. En este diagrama se muestran caractersticas
propias de la base de datos, como ser llaves primarias, forneas, tipos de datos propios,
tablas, vistas, etc.
RHX_PRM_ORG
RHX_TRN_AST
COD_EMP : SMALLINT
PRD_AST : VARCHAR(7)
TUR_AST : SMALLINT
HRA_REF_AST : VARCHAR(5)
FCH_AST : DATE
PER_AST : VARCHAR(5)
HRA_INI_PER_AST : VARCHAR(5)
HRA_FIN_PER_AST : VARCHAR(5)
ATR_AST : VARCHAR(5)
HRA_INI_ATR_AST : VARCHAR(5)
FCL_AST : DECIMAL(4, 2)
FSL_AST : DECIMAL(4, 2)
BJA_MED_AST : DECIMAL(4, 2)
SPS_AST : DECIMAL(4, 2)
OPC_AST : VARCHAR(15)
PERID_AST : INTEGER
ASTID : INTEGER
0..*
RHX_DIC_CARGO
COD_CAR : SMALLINT
DSC_CAR : VARCHAR(30)
EST_CAR : VARCHAR(10)
CARGOID : INTEGER
RHX_TRN_VAC
GST_ORG : SMALLINT
COD_ORG : VARCHAR(10)
DSC_ORG : VARCHAR(40)
EST_ORG : VARCHAR(10)
ORGID : INTEGER
COD_EMP_TRN_VAC : SMALLINT
NRO_TRN_VAC : SMALLINT
GST_TRN_VAC : VARCHAR(10)
0..*
FCH_VNC_TRN_VAC : DATE
FCH_TRN_TRN_VAC : DATE
FCH_INI_TRN_VAC : DATE
GLS_INI_TRN_VAC : VARCHAR(20)
FCH_FIN_TRN_VAC : DATE
GLS_FIN_TRN_VAC : VARCHAR(25)
DIA_MAD_TRN_VAC : SMALLINT
DIA_REAL_TRN_VAC : DECIMAL(4, 2)
DIA_CTA_TRN_VAC : DECIMAL(4, 2)
DIA_SLD_TRN_VAC : DECIMAL(4, 2)
DIA_VAC_TRN_VAC : DECIMAL(4, 2)
COD_REM_TRN_VAC : SMALLINT
OBS_TRN_VAC : VARCHAR(150)
TRNVACID : INTEGER
SLD_ANT_TRN_VAC : DECIMAL(4, 2)
1..*
0..1
0..1
RHX_MAE_EMP
COD_EMP : SMALLINT
PATERNO : VARCHAR(20)
MATERNO : VARCHAR(20)
NOMBRE : VARCHAR(20)
0..* SEX_EMP : VARCHAR(2)
FCH_NAC_EMP : DATE
EST_CIV_EMP : VARCHAR(15)
NRO_DOC_EMP : VARCHAR(15)
EXP_DOC_EMP : VARCHAR(2)
DIR_EMP : VARCHAR(40)
TEL_EMP : VARCHAR(50)
NAC_EMP : VARCHAR(15)
COD_PRF : SMALLINT
FRM_EMP : VARCHAR(35)
LIB_MIL_EMP : VARCHAR(10)
LIC_CND_EMP : VARCHAR(15)
GRP_SNG_EMP : VARCHAR(15)
FCH_ING_EMP : DATE
COD_ORG_EMP : VARCHAR(10)
COR_EMP : SMALLINT
COD_CAR_EMP : SMALLINT
CAR_EMP : VARCHAR(45)
NIV_SAL_EMP : SMALLINT
NRO_CRD_EMP : INTEGER
CLAVE : VARCHAR(20)
0..*
RHX_TRD_RELOJ
RELOJID : INTEGER
COD_EMP : SMALLINT
FCH_TRN : DATE
HRA_TRN : DATE
CRL_TRN : INTEGER
TIP_TRN : VARCHAR(50)
7.2.2.1. DESCRIPCION DE LAS CLASES DE LA FUENTE
Cdigo
Nombre
Descripcin
SCS001
RHX_MAE_EMP
Clase que almacena informacin de los datos

personales de los empleados de la empresa, as
como tambin el nivel salarial de los mismos.
SCS002
RHX_DIC_CARGO
Almacena la informacin descriptiva de los cargos
que pueden tener los empleados.

SCS003
RHX_PRM_ORG
Almacena la informacin descriptiva de la

estructura organizacional en la que se encuentra
dividida la empresa.
SCS004
RHX_TRN_AST
Almacena la informacin historica referente a

permisos, faltas, bajas medicas, suspensiones y
atrasos generados por el personal de la empresa.
SCS005
RHX_TRD_RELOJ
Almacena la informacin histrica concerniente a la

hora y fecha de entradas y salidas de los empleados
en la empresa.
SCS006
RHX_TRN_VAC
Almacena informacin histrica referente a las

vacaciones tomadas por los empleados de la
empresa.
7.2.3. NIVEL FISICO

En este nivel se define la configuracin fsica de las fuentes de datos que alimentan el
Data Mart (Lujan, 2005) . Es importante conocer esta configuracin para definir el tipo
de conexin a utilizar para la extraccin de los datos (lo que se ve reflejado ms
adelante en el diagrama de transporte en la fase de integracin)
deployment Nodes
Linux Red Hat 5 {4Gb RAM, 2.0

Ghz CPU}
Oracle 10g
Arreglo de Discos
Serv idor de Almacenamiento
{RAID 5}
table space
RHX_DATOS
deployment Artifacts
table
RHX_TRN_VAC
table
RHX_MAE_EMP
table
RHX_DIC_CARGO
table space
RHX_DATOS
table
RHX_TRN_AST
table
RHX_PRM_ORG
table
RHX_TRD_RELOJ
8. DISEO
En este captulo se realiza el diseo conceptual del Data Mart y la etapa de integracin
con las fuentes de datos. En el diseo conceptual del Data Mart se utiliza el modelo
multidimensional en el diseo conceptual de Integracin se utilizan los mapeos de datos.
8.1. DISEO CONCEPTUAL DEL DATA MART

Segn Lujan(2005) el modelo multidimensional es la base del Data Warehouse (Data
Mart), base de datos Multidimensionales y aplicaciones OLAP. El modelo
multidimensional estruturada la informacin en hechos y dimensiones. Un hecho
contiene medidas interesantes de un proceso del negocio (ventas, entregas de pedidos,
etc.), mientras que una dimensin representa el contexto para analizar un hecho
(producto, ciente, tiempo, etc.).
En la fase de anlisis se empaquetaron los casos de uso de acurdo a los temas del
negocio que se analizan con el Data Mart, adems de otros aaspectos como la gestin de
ingreso y la carga de datos.
8.1.1. DEFINICIN DEL MODELO (NIVEL 1)

En el modelado multidimensional se comienza desde un alto nivel de abstraccin y luego
en los siguientes niveles se incrementa el nivel de detalle. En el primer nivel, como se
observa en la figura siguiente se definen los esquemas estrella/copo de nieve identificada
en el Data Mart. Cada paquete estereotipado en este nivel representa un esquema
estrella/copo de nieve, como el esquema Control Personal, y las dependencias entre
ellos significan que comparten dimensiones, por ejemplo el esquema Control Personal
utiliza dimensiones que han sido definidas en Empleado.
Control de Asistencia
8.1.1.1. DEFINICION DEL ESQUEMA CONTROL DE ASISTENCIA (NIVEL 2).
Area
Empleado
Nivel Salarial
HechosEmpleado
8.1.1.1.1. DEFINICION DE HECHOS Y DIMENSIONES DEL CONTROL DE

PERSONAL (NIVEL 3)
8.1.1.1.1.1.
DIMENSIN EMPLEADO
class DimensionEmpleado
Empleado
Descripcion
Empleado
8.1.1.1.1.2.
DIMENSION NIVEL SALARIAL
class Niv elSalar...
Niv el Salarial
Descripcio del Niv el

Salarial
8.1.1.1.1.3.
DIMENSION AREA
class Area
Area
Descripcion del
Area
Gerencia
Departamento
Seccion
8.1.1.1.1.4.
DIMENSION PERIODO
class Periodo
Periodo
Descripcion del
Periodo
8.1.1.1.2. EMPLEADO (NIVEL 3)

8.1.1.1.3. DIMENSION ASISTENCIA
class Asistencia
Asistencia
Descripcion
Asistencia
Tipo de Asistencia
8.1.1.1.4. DIMENSION ATRASO

class Atraso
Atraso
Descripcion Atraso
Tipo Atraso
8.1.1.1.5. DIMENSION BAJA MEDICA

class Baj a Medi...
Baj a Medica
Descripcion Baj a
Medica
8.1.1.1.6. DIMENSION FALTA
class Falta
Falta
Descripcion de Falta
Tipo de Falta
8.1.1.1.7. DIMENSION PERMISO

class Permiso
Permiso
Descripcion
Permiso
Tipo de Permiso
8.1.1.1.8. DIMENSION SUSPENSIN
class Suspencion
Suspencion
Descripcion
Suspencion
Tipo de
Suspencion
8.1.1.1.9. DIMENSION TIEMPO

class Tiempo
Tiempo
Hora
Dia
Anio
Mes
9. DESARROLLO 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

Avance 020

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Avance 020

Uploaded by

Copyright:

Available Formats

FACULTAD DE INGENIERA

Carrera Ingeniera de Sistemas

Data Mart para la gestin de reportes y apoyo a la toma de

Oscar Marcos Amelunge Ruiz

Santa Cruz - Bolivia

Data Mart para la gestin de reportes y apoyo a la toma de

Oscar Marcos Amelunge Ruiz

Santa Cruz - Bolivia

Data Mart para la gestin de reportes y apoyo a la

Desde principios de la dcada de los 80 los sistemas de informacin empezaron a

como lo define Ralph Kimball una copia de las

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

a la empresa como ser: organismos gubernamentales, bancos, fondos

financieros, etc. la facilidad de compartir, gestionar, procesar y utilizar los datos

para esto las

empresas pueden valerse de los D.W..

El presente trabajo de grado pretende enfocarse en la implementacin de un Data Mart

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

PREPARACIN DEL PROYECTO

CAPITULO I PLAIFICACION DEL PROYECTO

1.2. DEFINICION DEL PROBLEMA

1.3. SITUACION PROBLEMTICA

CAPITULO I PLAIFICACION DEL PROYECTO

Adems el departamento de RR. HH. podr manejar la informacin, examinarla desde

1.6.2. OBJETIVOS ESPECIFICOS

CAPITULO I PLAIFICACION DEL PROYECTO

CAPITULO I PLAIFICACION DEL PROYECTO

CAPITULO I PLAIFICACION DEL PROYECTO

CAPITULO II - DATA WAREHOUSE Y DATA MART

2.1. DATA WAREHOUSE

2.1.1. ORIENTACION AL TEMA

2.1.2. DATOS INTEGRADOS

2.1.3. DATOS HISTRICOS

CAPITULO II - DATA WAREHOUSE Y DATA MART

2.3. DIFERENCIA ENTRE UN DATA MART Y UN DATA WAREHOUSE

CAPITULO II - DATA WAREHOUSE Y DATA MART

2.5. BASES DE DATOS OPERACIONALES VS. DATA WAREHOSE

CAPITULO II - DATA WAREHOUSE Y DATA MART

HOLAP (Hybrid OLAP)

2.8. CUBO OLAP

Segn Wikipedia(2010) es una base de datos multidimensional, en la cual el

CAPITULO II - DATA WAREHOUSE Y DATA MART

Las estructuras multidimensionales que se mencionan en el enunciado anterior y que

Existen dos tipos de medidas:

Medidas Almacenadas: son datos cargados, agregados y almacenados directamente en

Medidas Calculadas: son el resultado de realizar clculos matemticos estndar en base

CAPITULO II - DATA WAREHOUSE Y DATA MART

CAPITULO II - DATA WAREHOUSE Y DATA MART

Las dimensiones estn formadas por tres componentes claves:

CAPITULO II - DATA WAREHOUSE Y DATA MART

CAPITULO II - DATA WAREHOUSE Y DATA MART

Drill Down y Roll Up

2.8.3. Esquemas de Cubos

CAPITULO II - DATA WAREHOUSE Y DATA MART

2.8.3.2. Copo de Nieve

CAPITULO II - DATA WAREHOUSE Y DATA MART

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

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE

3.1. DESARROLLO DEL DATA WAREHOUSE.

Para alcanzar estas premisas se Lujan plantea la extensin de el Lenguaje Unificado de

3.2. MODELADO DEL DATA WAREHOUSE

3.3. PROCESO DE INGENIERIA DEL DATA WAREHOUSE

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE