Resumen introduccion




descargar 96.71 Kb.
títuloResumen introduccion
página1/2
fecha de publicación28.02.2016
tamaño96.71 Kb.
tipoResumen
b.se-todo.com > Documentos > Resumen
  1   2



logo verde upsa texto

FACULTAD DE INGENIERÍA



Carrera Ingeniería de Sistemas



MODALIDAD DE GRADUACIÓN

Proyecto de Grado


Data Mart para la gestión 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

logo verde upsa texto


FACULTAD DE INGENIERÍA



Carrera Ingeniería de Sistemas



MODALIDAD DE GRADUACIÓN

Proyecto de Grado


Data Mart para la gestión 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 Ingeniería de Sistemas

Santa Cruz - Bolivia

2010
ABSTRACT



TITULO

Data Mart para la gestión de reportes y apoyo a la toma de decisiones del departamento de RR.HH. de la empresa de agua S.A.

AUTOR

: Oscar Marcos Amelunge Ruiz.

 

PROBLEMATICA

OBJETIVO

CONTENIDO

CARRERA

: Ingeniería de Sistemas

PROFESOR GUIA

:

DESCRIPTORES O TEMAS

: Data Warehouse, Data Mart, Analisis, Diseño, Modelo Dimensional.

E-MAIL

: oscar.amelunge@gmail.com

FECHA

: Julio de 2010.

AGRADECIMIENTO

En esta sección se realizara el agradecimiento correspondiente
RESUMEN

INTRODUCCION

Desde principios de la década de los 80 los sistemas de información empezaron a desarrollarse utilizando el modelo relacional y la información almacenada en las bases de datos generalmente ha sido orientada al registro de transacciones, lo que comúnmente se conoce como sistemas OLPT – “OLTP es la sigla en inglés de Procesamiento de Transacciones En Línea (Online Transaction Processing) es un tipo de sistemas que facilitan y administran aplicaciones transaccionales, usualmente para entrada de datos y recuperación y procesamiento de transacciones.” (WIKIPEDIA, 2010). Como su nombre lo dice este tipo de sistemas están orientados exclusivamente generar información a través de transacciones y no a la consulta y análisis de la información, ya que al aumentar el volumen de información en los sistemas transaccionales se dificulta la consulta de los datos generados. Como alternativa a esta situación surgió el concepto de Data Warehouse (D.W.) (almacén de datos) como lo define Ralph Kimball una copia de las transacciones de datos específicamente estructurada para la consulta y el análisis” o “la unión 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 extracción y consulta de los mismos sin importar el amplio volumen de información que pueda existir. Normalmente el alcance que tiene un D.W. llega a ser, toda la información generada empresa, la construcción de un D.W. requiere una inversión en tiempo y esfuerzo considerable. Una estrategia o concepto alternativo al D.W. que tiene el mismo fin pero con un alcance más limitado a un área o departamento de empresa es el Data mart. “Un Data mart es una versión especial de almacén de datos (Data Warehouse). Son subconjuntos de datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de los mismos de la forma más conveniente según 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 información fiables y oportunas, la cuales brinden a los empleados, jefes de sección, administrativos, ejecutivos y también 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 información que es procesada y almacenada por los Sistemas de Informatizados de la compañía 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 implementación de un Data Mart para una de las aéreas de empresa mayor estudiada y de mayor preocupación; los Recursos Humanos, eje principal del aparato productivo de toda organización. La cantidad de información generada por las actividades y procesos concernientes al control y gestión de recursos humanos en las empresas es substancial, y de la misma pueden derivarse una gran cantidad de información como ser control de asistencias y permisos, control de vacaciones, planillas de sueldos, pagos de beneficios, etc.
TABLA DE CONTENIDO

.PARTE I PLANIFICACIÓN Y PREPARACIÓN DEL PROYECTO

  1. PLANIFICACION DEL PROYECTO

    1. INTRODUCCION



    1. DEFINICION DEL PROBLEMA

El departamento de Recursos Humanos de la empresa de agua S.A. cuenta actualmente con un sistema de información con el cual se gestionan y almacena la información de más de 600 funcionarios.

El sistema utiliza como repositorio de información una base de datos cuyo diseño relacional está orientado mas al almacenamiento que a la consulta y explotación 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 información de los funcionarios, con lo cual el modelo transaccional sobre la cual está construida la base de datos dificulta el estudio de la información 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 análisis de localización, formateo, presentación y procesamiento de los datos, como también asignación de recursos humanos del departamento de sistemas para poder responderlas, sin tener en cuenta la degradación de los sistemas transaccionales. Esta problemática se debe a que dichos sistemas transaccionales no fueron construidos con el fin de brindar síntesis, análisis, consolidación, búsquedas 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 variación de los mismos en el tiempo es poco significativa, la herramienta en la cual están 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. SITUACION PROBLEMÁTICA

No existe una disponibilidad inmediata de la información para la generación de reportes y consulta de datos de los empleados.

    1. SITUACION DESEADA

Contar con un Data Mart que almacene la información generada por el sistema de recursos humanos y que de la posibilidad de acceder dicha información de manera inmediata a través de una herramienta de consulta.

    1. JUSTIFICACIÓN

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 información sin tener que depender de personal técnico (programadores o analistas de sistemas) que genere los reportes o consultas ad hoc a través de un lenguaje y/o herramienta de programación, lo cual además conlleva en disminuir el tiempo de espera en la generación de reportes por parte del personal técnico.

Además el departamento de RR. HH. Podrá manejar la información, examinarla desde diferentes puntos de vista, de manera que puedan entenderla mejor e interpretarla de acuerdo a su criterio.

    1. OBJETIVOS

      1. OBJETIVO GENERAL

Construir un Data Mart para la gestión de reportes y apoyo a la toma de decisiones del departamento de RR.HH. de la empresa de agua S.A.

      1. OBJETIVOS ESPECIFICOS

  • Definir los requerimientos generales del área de RRHH para la construcción del Data Mart.

  • Analizar y definir las fuentes de datos que permitan alimentar el Data Mart.

  • Realizar el diseño de la base de datos del Data Mart

  • Definir los procesos de ETL para alimentar el Data Mart.

  • Construir una versión Beta de la base de datos y los procesos ETL del Data Mart.

    1. ALCANCE

La metodología a utilizar será El Proceso de Ingeniería para el Data Warehouse (DWEP por sus siglas en ingles) planteado en la tesis doctoral de Luján-Mora (Luján 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

    • Requerimientos funcionales y no funcionales.

    • Identificación de las medidas y dimensiones más importantes.

    • Análisis de los reportes periódicos que se utilizan actualmente.

    • Elaboración del modelo del dominio

    • Elaboración de los casos de uso más importantes

  • Análisis

    • Determinación de las posibles fuentes de datos

    • Elaboración de los diagramas lógico de la fuente de datos SLS, diagrama físico de las fuentes de datos SPS.

  • Diseño

    • Diseño definición de la estructura del data Warehouse

    • Elaboración del diagrama conceptual del data Warehouse DWCS.

Elaboración

  • Requerimientos

    • Recolección y refinamiento de requerimientos.

    • Identificación de nuevas medidas agregaciones y dimensiones.

  • Análisis

    • Elección de fuentes de datos que alimenta el DM.

    • Actualización de los diagramas SLS, SPS.

    • Elaboración de los diagramas diagrama conceptual SCS.

  • Diseño

    • Definición procesos ETL a nivel conceptual.

    • Actualización del diagrama DWCS.

    • Elaboración del diagrama mapeo de datos de integración DM.



  • Implementación

Elaboración de las estructuras físicas.

CAPITULO II

DATA WAREHOUSE Y DATA MART

  1. INTRODUCCION

Este capitulo muestra los conceptos general de Data Warehouse y Data Mart, ademas de ser el marco teórico referencial.

    1. DATA WAREHOUSE

Segun Bill Immon (1994) se puede definir a un Data Warehouse como “una colección de datos orientada a un determinado ámbito (empresa, organización, etc.), integrado, no volátil y variable en el tiempo, que ayuda a la toma de decisiones en la entidad en la que se utiliza”.

      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 integración de los diferentes temas en una estructura única es necesaria para que la información común a varios temas no se repita.

      1. 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 descripción y una codificación. Las diferencias que existen en los datos de las fuentes dependen de la visión deseada por el usuario, de la utilización que se hace, o de los programadores. La integración de datos constituye una gran parte de la labor de construir un Data Warehouse y se realiza mediante los proceso de extracción, transformación y carga o procesos ETL.

      1. DATOS HISTÓRICOS

U Data Warehouse almacena el histórico de datos de la empresa y los datos actuales con los que cuenta. Suponiendo que cada día se obtienen los datos, cada dato de un día sobre algo constituye un dato diferente al de otro día sobre lo mismo. Una vez ingresada la información al Data Warehouse, ésta no se actualiza, a no ser por casos excepcionales.

      1. DANOS NO VOLÁTILES

La no volatilidad es, de cierta forma una consecuencia de que los datos sean históricos. Al no actualizarse los datos, una consulta sobre determinados datos será siempre la misma.

    1. DATA MART

Según la definición 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.

    1. DIFERENCIA ENTRE UN DATA MART Y UN DATA WAREHOUSE

Un Data Warehouse maneja información de distintas areas típicamente es implementado como el repositorio central de información de toda una organización, mientras que que un Data Mart maneja información de un departamento en particular. La tabla siguiente muestra una comparación de las principales diferencias entre el Data Mart y el Data Warehouse:

Categoría

Data Warehouse

Data Mart

Alcance

Corporativo

Área de Negocios

Temas

Multiples

Simples

Fuentes de Datos

Muchas

Pocas

Tamaños

100 GB-TB+

< 100 GB

Tiempo de implementación

De meses a años

Meses

Fuente http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm

    1. LOS PROCESOS ETL

Los procesos ETL son los que permiten a la organización 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 diseño y mantenimiento de estos procesos ETL es un factor clave de éxito en los proyectos de Data Warehouse. Debido a la dificultad de diseñar y mantener este tipo de procesos, existen muy poca proliferación de herramientas de este tipo e igualmente respecto al modelado de estos procesos (Lujan,2005).

    1. BASES DE DATOS OPERACIONALES VS. DATA WAREHOSE

Existen muchas características 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 están pensadas para soportar procesos transaccionales de almacenamiento de información, los Data Warehouse están orientados a la consulta y explotación de datos, sin embargo es importante mencionar que ambos no son mutuamente excluyentes si no más 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.

    1. 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 recuperación 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 informática distribuida. La tecnología OLTP se utiliza en innumerables aplicaciones, como en banca electrónica, procesamiento de pedidos, comercio electrónico, supermercados o industria.

    1. OLAP

De acuerdo a Wikipedia(2010) OLAP es el acrónimo en ingles de procesamiento analítico en línea. Es una solución 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 dirección, minería de datos y aéreas similares.

De acuerdo con Wikipedia(2010) existen distintos tipos de OLAP:

ROLAP

Implementación OLAP que almacena los datos en un motor relacional. Típicamente, los datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas. Los esquemas más 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 análisis de una enorme cantidad de datos.

MOLAP

Esta implementación OLAP almacena los datos en una base de datos multidimensional. Para optimizar los tiempos de respuesta, el resumen de la información es usualmente calculado por adelantado. Estos valores precalculados o agregaciones son la base de las ganancias de desempeño de este sistema. Algunos sistemas utilizan técnicas de compresión 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.

    1. CUBO OLAP

Existen distintos concepto de acuerdo al punto de vista de los que es un cubo olap:

Según Wikipedia(2010) es una base de datos multidimensional, en la cual el almacenamiento físico de los datos se realiza en un vector multidimensional. Los cubos OLAP se pueden considerar como una ampliación de las dos dimensiones de una hoja de cálculo.

Según (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 rápido 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.

      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 típico de medidas son las ventas, los costos, ganancias márgenes, etc. Las medidas se organizan en una o más dimensiones. Las medidas están 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 cálculos matemáticos estándar en base a métricas simples. Por ejemplo el precio promedio de venta, que se calcula dividiendo la sumatoria total en dólares de las ventas entre unidades vendidas.

Hechos

Los hechos contienen información sobre cuantificaciones o datos sobre hechos relevantes del negocio que quieren ser consultados. Esta información a menudo está compuesta por valores numéricos 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 clásicos 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.

      1. 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 satélites que están unidas a las tablas de hechos(Poe, 2007)



Las tablas de dimensiones almacenan toda la información asociada con cada dimensión particular, esto incluye:

  • Las relaciones de jerarquías de cada dimensión.

  • Los atributos que describen cada dimensión.

Las dimensiones están formadas por tres componentes claves:

Jerarquías

Las jerarquías son estructuras lógicas que agrupan datos pertenecientes a una dimensión con el propósito de analizarlos por ejemplo: si se considera una escala (o dimensión) temporal "Mayo de 2005" se puede incluir en "Segundo Trimestre de 2005", que a su vez se incluye en "Año 2005".



Niveles

Los niveles representan una posision en una jerarquia. El nivel superiror contiene una agregación de valores para el nivel inferior. Cada nivel tienen una relación uno a muchos o maestro detalle con su nivel inferior. Por ejemplo una medida de ventas puede encontrarse en la jerarquía de productos y en un nivel superior en categoría de productos o sub categorías, etc.



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

Atributos

Los atributos proveen información descriptiva hacerca de los datos y son de utilidad cundo se seleccionan datos para el análisis por ejemplo:

  • Selección de productos cuyo color (atributo) es “Azul”.

  • Selección de clientes que tienen dos hijos.

  • Selección de promociones que son de tipo “Multipack”.



Drill Down y Roll Up

Son técnicas analíticas especificas por las cuales los usuarios navegan entre niveles de detalle de información, desde las más resumida hasta las más detallada, en el caso del Drill Down y del detalle a un resumida en el caso del Roll Up. Las jerarquías de la dimensión son las que establecen los caminos por los cuales los usuarios podrán hacer tanto un Drill Down como un roll-up, esto debido a que la jerarquía o jerarquías de la dimensión contienen los niveles de la misma. Por ejemplo viendo la información de las ventas de Norte América, una operación de Drill Down en la dimensión de región mostraría entonces a Canadá, Los estados del este, y los estados del Oeste. Al realizar otra operación Drill Down en Canadá, nos mostraría a Toronto, Vancouver, Montreal, etc. (Alta Plana 1999).

      1. Esquemas de Cubos

Un esquema es una colección de objetos de base de datos (tablas, vistas, índices, sinónimos, etc.) esisten dos tipos comunes de esquemas de cubo: en estrella y en copo de nieve.

        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



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

        1. Copo de Nieve

Segun Oracle Corporation el esquema de copo de nieve es mas complejo que el modelo de estrella y es una extensión del mismo. Es llamado copo de nieve por que el diagrama entidad relación se asemeja a un copo de nieve.

La característica 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 pequeñas en vez de una tabla grande como se lo haría en una estrella como se muestra en la figura.



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

PROCESO DE INGENIERIA DEL DATA WAREHOUSE

  1. INTRODUCCION

Este capítulo hace referencia a la metodología de “El proceso de ingeniería para la construcción de un Data Warehouse” y la extensiones a UML de “Diagramas del Data Warehouse” propuesto en la tesis doctoral “Diseño de Data Warehouse con UML” (Lujan,2005).

    1. DESARROLLO DEL DATA WAREHOUSE.

Según (Lujan, 2005) el objetivo de este método o metodología de trabajo es optimizar el proceso de desarrollo del Data Warehouse más eficiente considerando las siguientes premisas:

  • Basar el método en un lenguaje de modelado estándar.

  • Un método claro y robusto para el desarrollo de un Data Warehouse.

  • Un método que abarque todos las fases del desarrollo de un Data Warehouse desde la definición de los requerimientos hasta la implementación final.

Para alcanzar estas premisas se Lujan plantea la extensión 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.



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

      1. ETAPAS.



    1. PROCESO DE INGENIERIA DEL DATA WAREHOUSE

El proceso de Ingenieria del Data Warehouse es una metodología 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 estándar en la industria de desarrollo de software junto con UML (Unified Modeling Language).

El proceso de ingeniería dpara el data warehouse, al ser una instancia del UP(Proceso Unificado), hereda las siguientes características del mismo:

  • Dirigido por casos de Uso, es decir que los casos de uso son utilizados para especificar los requerimientos de un sistema, pero además, estos dirigen el disenio, implementación y pruebas del mismo.

  • Centrado en la arquitectura, la arquitectura del software engloba los aspectos estaticos y dinámicos 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 pequeñas llamadas iteraciones que resultan en un incremento en el crecimiento del producto, por otra parte los diagramas no permanecerán 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,
Elaboración, construcción y Transición) y cinco flujos de trabajo fundamentales (Requerimientos, Análisis, Diseño, Implementación y Pruebas), los flujos de trabajo de Mantenimiento y Revisión Pot-Desarrollo son añadidos por el Proceso de Ingeniería 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 través del tiempo. A continuación se muestras los detalles principales de cada flujo de trabajo y los diagramas con los que se trabaja en cada flujo.

      1. REQUERIMIENTOS

Durante este flujo de trabajo se captura lo que los usuarios finales esperan poder hacer con el Data Warehouse, los usuarios finales deberían especificar las medidas y agregaciones mas interesantes, las dimensiones de análisis, los reportes que utiliza periódicamente para tomar deciciones, la frecuencia de actualización 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).

      1. ANALISIS

En este flujo de trabajo se refinan y estructuran los requerimientos que se capturaron en el anterior flujo de trabajo, además 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.

      1. 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, además 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 Integración, Diagrama Conceptual del cliente y Mapeo de Datos de la etapa de personalización, (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.

      1. IMPLEMENTACION

En este flujo de trabajo se construye el Data Warehouse, se construyen las estructuras físicas del Data Warehouse, el Data Warehouse es llenado y ajustado para un rendimiento óptimo. Para esto se pueden utilizar diferentes diagramas, a continuación se mencionan los principales: diagrama lógico del Data Warehouse (DWLS), diagrama Físico del Data Warehouse (DWPS), Diagrama Lógico del cliente (CLS), Diagrama Físico del cliente (CPS), Diagrama de Procesos ETL, Procesos de Exportación y diagramas de transporte.

Los diagramas: Diagrama Lógico del Cliente (CLS), Proceso de Exportacion y Diagrama Físico 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.

      1. PRUEBAS

El objetivo de este flujo de trabajo es verificar que la implementación funcione de acuerdo a lo deseado. Mas espeficicamente el propósito de las pruebas es:

  • Planear las pruebas requeridas.

  • Diseñara y realizar la pruebas a través de los casos de prueba requeridos.

  • Ejecutar las pruebas y analizar los resultados de las mismas.

Ningún 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.

      1. 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 actualización necesarios para que la información 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 iteración.

      1. REVISION POST-DESARROLLO

Esta tarea no forma parte del flujo de trabajo en el desarrollo del Data Warehouse, pero es una revisión de los procesos para realizar mejoras en futuros proyectos. Se debe mirar y revisar el Data Warehouse, la documentación 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 información puede ser una fuente de información muy útil para futuros proyectos.

      1. ESTRATEGIAS DE CONSTRUCCION PARA UN DATA WAREHOUSE

Existen dos estrategias para la construcción 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 mayoría de los proyectos, los Data Marts son construidos de manera independiente, es decir, sin la construcción de un data warehouse integrado, lo cual ocasiona que el Datawarehouse no se vea como un repositorio monolítico sino mas bien simplemente como una colección de Data Marts.

El proceso de Ingenieria del Data Warehouse premite la utilización 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 metodología, 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.
  1   2

similar:

Resumen introduccion iconResumen introducción

Resumen introduccion iconResumen Introducción

Resumen introduccion iconResumen introduccióN

Resumen introduccion iconResumen I. Introducción 4

Resumen introduccion iconResumen Introducción

Resumen introduccion iconResumen Introducción

Resumen introduccion iconResumen Introducción y objetivos

Resumen introduccion iconResumen (cosas a realizar e introducción)

Resumen introduccion iconResumen introducción: Actualmente existe un incremento de la incidencia...

Resumen introduccion iconTaller com/manual-java/introduccion-java php >Introducción a Java...




Todos los derechos reservados. Copyright © 2019
contactos
b.se-todo.com