Resumen introduccion
descargar 96.71 Kb.
|
1 2
  FACULTAD DE INGENIERÍACarrera Ingeniería de SistemasMODALIDAD 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 FACULTAD DE INGENIERÍACarrera Ingeniería de SistemasMODALIDAD 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
PROBLEMATICA OBJETIVO CONTENIDO
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 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. No existe una disponibilidad inmediata de la información para la generación de reportes y consulta de datos de los empleados. 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. 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. 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.
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
Elaboración
Elaboración de las estructuras físicas. CAPITULO II DATA WAREHOUSE Y DATA MART
Este capitulo muestra los conceptos general de Data Warehouse y Data Mart, ademas de ser el marco teórico referencial.
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”.
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.
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.
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.
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.
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.
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:
Fuente http://download.oracle.com/docs/cd/E10352_01/doc/bi.1013/e10312/dm_concepts.htm
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).
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.
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.
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.
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.
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.
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 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:
 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).
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.
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
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
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).
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:
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.
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.
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:
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.
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).
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.
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.
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.
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:
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.
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.
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.
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
