Trabajo final de grado

REFERENCIAS BIBLIOGRAFICAS

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

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 RuizNR. 2003210474

Proyecto de Grado para optar algrado de Licenciado en Ingeniera de Sistemas

Santa Cruz - Bolivia2010

56

ABSTRACT

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

PROBLEMATICAOBJETIVOCONTENIDOCARRERA: 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.

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

i

.PARTE I PLANIFICACIN Y PREPARACIN DEL PROYECTO

1. PLANIFICACION DEL PROYECTO1.1. INTRODUCCION

1.2. DEFINICION DEL PROBLEMAEl 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 PROBLEMTICANo existe una disponibilidad inmediata de la informacin para la generacin de reportes y consulta de datos de los empleados.1.4. SITUACION DESEADAContar 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. JUSTIFICACINLa 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. OBJETIVOS1.6.1. OBJETIVO GENERALConstruir un Data Mart para la gestin de reportes y apoyo a la toma de decisiones del departamento de RR.HH. de la empresa de agua S.A.

1.6.2. OBJETIVOS ESPECIFICOS Definir los requerimientos generales del rea de RRHH para la construccin del Data Mart. Analizar y definir las fuentes de datos que permitan alimentar el Data Mart. Realizar el diseo de la base de datos del Data Mart Definir los procesos de ETL para alimentar el Data Mart. Construir una versin Beta de la base de datos y los procesos ETL del Data Mart.1.7. ALCANCELa 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.

FasesInicio Requerimientos Requerimientos funcionales y no funcionales. Identificacin de las medidas y dimensiones ms importantes. Anlisis de los reportes peridicos que se utilizan actualmente. Elaboracin del modelo del dominio Elaboracin de los casos de uso ms importantes Anlisis Determinacin de las posibles fuentes de datos Elaboracin de los diagramas lgico de la fuente de datos SLS, diagrama fsico de las fuentes de datos SPS. Diseo Diseo definicin de la estructura del data Warehouse Elaboracin del diagrama conceptual del data Warehouse DWCS.

Elaboracin Requerimientos Recoleccin y refinamiento de requerimientos. Identificacin de nuevas medidas agregaciones y dimensiones. Anlisis Eleccin de fuentes de datos que alimenta el DM. Actualizacin de los diagramas SLS, SPS. Elaboracin de los diagramas diagrama conceptual SCS. Diseo Definicin procesos ETL a nivel conceptual. Actualizacin del diagrama DWCS. Elaboracin del diagrama mapeo de datos de integracin DM.

ImplementacinCAPITULO I PLAIFICACION DEL PROYECTOElaboracin de las estructuras fsicas.4

CAPITULO II

DATA WAREHOUSE Y DATA MART

2. INTRODUCCIONEste capitulo muestra los conceptos general de Data Warehouse y Data Mart, ademas de ser el marco terico referencial.

2.1. DATA WAREHOUSESegun 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 TEMAEl 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 INTEGRADOSAntes 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 HISTRICOSU 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 VOLTILESLa 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 WAREHOUSEUn 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:CategoraData WarehouseData Mart

AlcanceCorporativorea de Negocios

TemasMultiplesSimples

Fuentes de DatosMuchasPocas

Tamaos100 GB-TB+< 100 GB

Tiempo de implementacinDe meses a aosMeses

Fuente http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm2.4. LOS PROCESOS ETLLos 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 WAREHOSEExisten 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. OLPTDe 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. OLAPDe 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:

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

MOLAPEsta 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 OLAPExisten distintos concepto de acuerdo al punto de vista de los que es un cubo olap:

Segn Wikipedia(2010) es una base de datos multidimensional, en la cual el almacenamiento fsico de los datos se realiza en un vector multidimensional. Los cubos OLAP se pueden considerar como una ampliacin de las dos dimensiones de una hoja de clculo.

Segn (PradoLand,2000) un cubo es un subconjunto de datos de un Data Warehouse, organizado y sumariado dentro de una estructura multidimensional. Los datos se sumarizan de acuerdo a factores de negocio seleccionados, proveyendo el mecanismo para un rpido y uniforme tiempo de respuesta de las complejas consultas.

Las estructuras multidimensionales que se mencionan en el enunciado anterior y que forman un cubo son las dimensiones y las medidas.

2.8.1. MEDIDASEl 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.

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

GranularidadLa 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. DIMENSIONESLas dimensiones identifican y categoriza los datos del negocio. Ejemplos de dimensiones pueden ser product, geografia, tiempo, canal de distribucion, etc. Las dimensiones son almacenadas en tablas satlites que estn unidas a las tablas de hechos(Poe, 2007)

Las tablas de dimensiones almacenan toda la informacin asociada con cada dimensin particular, esto incluye:

Las relaciones de jerarquas de cada dimensin. Los atributos que describen cada dimensin.

Las dimensiones estn formadas por tres componentes claves:

JerarquasLas 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".

NivelesLos niveles representan una posision en una jerarquia. El nivel superiror contiene una agregacin de valores para el nivel inferior. Cada nivel tienen una relacin uno a muchos o maestro detalle con su nivel inferior. Por ejemplo una medida de ventas puede encontrarse en la jerarqua de productos y en un nivel superior en categora de productos o sub categoras, etc.

Origen : http://oracleolap.blogspot.com/2007/12/olap-workshop-1-basic-olap-concepts.html

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

Drill Down y Roll UpSon 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 CubosUn 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. EstrellaSegun 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

Origen: http://es.wikipedia.org/wiki/Archivo:Esquema_en_estrella.png

2.8.3.2. Copo de NieveSegun 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.

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

CAPITULO II - DATA WAREHOUSE Y DATA MART2.8.3.3. 16CAPITULO III

PROCESO DE INGENIERIA DEL DATA WAREHOUSE

3. INTRODUCCIONEste 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 WAREHOUSELa 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 WAREHOUSEEl proceso de Ingenieria del Data Warehouse es una metodologa orientada a objetos basada en el Proceso Unificado de Desarrollo de Software (UP por sus siglas en ingles) (Jacobson,2000). El Proceso unificado es el estndar en la industria de desarrollo de software junto con UML (Unified Modeling Language).

El proceso de ingeniera dpara el data warehouse, al ser una instancia del UP(Proceso Unificado), hereda las siguientes caractersticas del mismo:

Dirigido por casos de Uso, es decir que los casos de uso son utilizados para especificar los requerimientos de un sistema, pero adems, estos dirigen el disenio, implementacin y pruebas del mismo. Centrado en la arquitectura, la arquitectura del software engloba los aspectos estaticos y dinmicos mas significativos del sistema, y es descrita como diferentes vistas del sistema que se est construyendo. Iterativo e incremental, el desarrollo de los productos de software es difidido en partes mas pequeas llamadas iteraciones que resultan en un incremento en el crecimiento del producto, por otra parte los diagramas no permanecern intactos, deben evolucionar a medida que pasa el tiempo, y vayan apareciendo nuevos requerimientos.

De acuerdo con el Proceso Unificado el proyecto esta dividido en cuatro fases (Inicio, Elaboracin, construccin y Transicin) y cinco flujos de trabajo fundamentales (Requerimientos, Anlisis, Diseo, Implementacin y Pruebas), los flujos de trabajo de Mantenimiento y Revisin Pot-Desarrollo son aadidos por el Proceso de Ingeniera del Data Warehouse.En la figura siguiente se muestra como los 7 flujos de trabajo toman lugar en las cuatro fases, para cada flujo de trabajo la curva presenta aproximadamente el grado en el cual el flujo de trabajo es realizado en cada fase.(Insertar figura del proceso unificado).

Por cada uno de los flujos de trabajo se utiliza diferentes diagramas UML para modelar y documentar el proceso de desarrollo, pero un modelo puede ser modificado en diferentes fases porque los modelos evolucionan a travs del tiempo. A continuacin se muestras los detalles principales de cada flujo de trabajo y los diagramas con los que se trabaja en cada flujo.

3.3.1. REQUERIMIENTOSDurante 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. ANALISISEn 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. DISENIOAl finalizar este flujo de trabajo la estructura del Data Warehouse es definida. El resultado principal de este flujo de trabajo es el modelo conceptual del Data Warehouse, adems del mapeo de datos desde las fuentes de datos ya definidas hacia el Data Warehouse y del Data Warehouse hacia las estructuras del cliente.

En este flujo de trabajo se construyen los siguientes diagramas: Diagrama conceptual del Data Warehouse, Mapeo de Datos de la etapa de Integracin, Diagrama Conceptual del cliente y Mapeo de Datos de la etapa de personalizacin, (DWCS, DM, CCS y DM). Los dos ltimos diagramas son aplicados en el caso de que existan Data Marts coo clientes en una estrategia top-down y en el caso de que exista un data Warehouse como cliente en una estrategia bottom-up.

3.3.4. IMPLEMENTACIONEn 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. PRUEBASEl 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. MANTENIMIENTOA diferencia de muchos sistemas, el Data Warehouse nunca est terminado. El objetivo principal de este flujo de trabajo es el de mantener los proceso de carga y actualizacin necesarios para que la informacin del Data Warehose este actualizada, este flujo de trabajo comienza cuando el Data Warehouse ha sido construido y entregado a los usuarios finales, pero no tiene una fecha fin, ya que dura mientras se encuentre en vigencia el Data Warehouse.

Durante este flujo de trabajo puede ocurrir que los usuarios generen nuevos requerimientos como nuevas consultas, lo cual genera una nueva iteracin.

3.3.7. REVISION POST-DESARROLLOEsta 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 WAREHOUSEExisten 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 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.

CAPITULO III - PROCESO DE INGENIERIA DEL DATA WAREHOUSE

23PARTE IIANALISIS Y DISEO DEL DATA MART

CAPITULO 6REQUERIMIENTOS6. INTRODUCCIONEn 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 FUNCIONALESLos 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 FUNCIONALES6.1.2.1. ACCESIBILIDADLas 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. RENDIMIENTOEl rendimiento del Data Mart debe ser superior a las herramientas utilizadas para la consulta en los sistemas transaccionales.

6.1.2.3. HERRAMIENTASEL 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 DOMINIOUn modelo del dominio captura los tipos ms importantes de objetos en el contexto del sistema. Los objetos del dominio representa la cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema (Jacobson,2000).

En la figura siguiente se muestra el modelo del dominio el cual contiene los principales objetos y sus atributos identificados a partir de los requerimientos funcionales. En el contexto del modelo del Data Warehouse las clases del dominio representan dimensiones y hechos.

NroClaseDescripcin

1EntradaSalida

2Faltas

3Atraso

4Permisos

5Suspensin

6Vacacin

7BajaMedica

8Descuento

9Anticipo

10Bono

6.2.2. DESCRIPCIN DE LAS CLASES DEL DOMINIOUna clase es una descripcin de un conjunto de objetos que comparten los mismos atributos como operaciones, relaciones y semntica(Rumbaugh, 1999). En el cuadro siguiente se describen los hechos y en la tabla posterior se describen las dimensiones.7. ANALISIS8. DISEO9. CONSTRUCCION DEL DATA MART 10. CONCLUCIONES Y RECOMENDACIONESPARTE IIICOSTRUCCION Y PRUEBAS DEL DATA MARTPARTE IVCONCLUSIONES Y RECOMENDACIONES(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