• Author / Uploaded
• Michael Saavedra

Citation preview

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

INDICE 1. TITULO 2. INTRODUCCION 3. OBJETIVO GENERAL 4. OBJETIVO ESPECIFICO 5. DESARROLLO DEL TEMA DE INVESTIGACION 5.1 DATA MART 5.1.1 HISTORIA 5.1.2 DEFINICIONES 5.1.3 TIPOS DE DATAMART 5.1.4 CARACTERISTICAS 5.1.5 VENTAJAS Y DESVENTAJAS 5.1.6 ARQUITECTURA ROLAP, MOLAP, HOLAP 5.1.7 COMPONENTES EN LA CREACION DE UN DATAMART 5.1.8 FACES DE CONSTRUCCION 5.1.9 PASOS PARA IMPLEMENTAR UN DATAMART

6. REPRESENTACIONES GRAFICAS 7. EJEMPLOS DE APLICACIÓN 8. CONCLUSIONES Y RECOMENDACIONES 9. BIBLIOGRAFIA

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

1. TITULO: “DATA MART Y SUS APLICACIONES A LA INGENIERIA CIVIL”

2. INTRODUCCION Actualmente, en cualquier entidad que procese información y que cuente con una base de datos, sabemos que es necesario que esta se actualice constantemente, y el propósito de ella es proveer información a la empresa con un adecuado manejo como transformaciones, búsqueda de patrones y consolidaciones. Es así como nace el término repositorio de datos o mercado de datos, que en el ámbito de ingeniera de sistemas es conocido como Data Mart.. La existencia de los Data Marts crea nuevas formas de pensar cuando se diseñan repositorios corporativos de datos. Algunas de ellas reemplazan definitivamente el concepto de DataWarehouse, por varios Data Marts que se van alimentar de los sistemas operacionales. Otras utilizan los Data Marts como complemento de los DataWarehouse, quiere decir que de estos mueven la información hacia varios Data Marts con el fin de permitir un análisis más eficiente. Y solo personal autorizado debe trabajar con las bases de datos y acceso a los Data Marts . En la mayoría de las empresas del Perú y del mundo se puede apreciar que muchas ya cuentan de una u otra manera con diferentes Data Marts, los cuales ayudan a la empresa a tomar decisiones, por que las empresas de hoy necesitan constantemente de consumir información para poder sobrevivir. Sin embargo muchos de estos Data Marts fueron creados enfocados en los datos y no en las necesidades de información de los usuarios.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

3. OBJETIVO GENERAL El presente trabajo tiene como objetivo brindar información y plantear las bases teóricas para el desarrollo del DataMart y explicar de manera detallada dos aplicaciones dentro de la carrera de Ingeniería Civil.

4. OBJETIVOS ESPECIFICOS  Brindar las definiciones y conceptos básicos sobre Data Mart.  Mencionar las características importantes del Data Mart.  Dar a conocer las ventajas y desventajas del Data Mart.  Indicar y describir las fases de construcción de un Data Mart.

5. DESARROLLO DEL TEMA DE INVESTIGACION MARCO TEORICO:

DATA MART I. HISTORIA Desde épocas remotas la humanidad se ha preocupado por la creación de bienes con el mínimo de recursos. Distintos pueblos y en distintos períodos se practicaban la previsión, planeación y organización de grupos para ejercitar diversas actividades (entre ellas la pesca, agricultura, el comercio, la guerra, etc.). En años más recientes durante la revolución industrial se pusieron en práctica ideas que sirvieron para la creación de la administración, ya que durante ese tiempo se pensó en la manera de producir más con menos recursos. A partir de ese momento precursores e idealistas fueron sentando las bases para la creación de la administración convirtiéndola en una ciencia. La humanidad ha utilizado varias formas para llevar a cabo transacciones de los bienes, tal es el caso de los antiguos pueblos al utilizar monedas de metal con

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

diferentes insignias, descripciones y denominaciones para el intercambio de artículos o servicios. Tal es así que nace el término de Business Intelligence que es bastante antiguo, hace miles de años los maya/ incas, fenicios, persas, egipcios y otros pueblos practicaban este principio cuando usaban información obtenida de la naturaleza, que luego usaban a la hora de tomar decisiones para mejoras en la vida de sus pueblos. Un claro ejemplo lo podemos ver en España, después de la conquista de América. El rey español creó la "Casa del Oro", en donde se registraban las transacciones de pago compulsorio de oro, ello permitió tener una visión general de la economía del país hispano. En los años 60's surgen las tarjetas perforadas, los transistores y el lenguaje estructurado COBOL. Este nuevo despliegue tecnológico, permitió al usuario facilitar el control de los sistemas y de la información.

LÍNEA DE TIEMPO DEL BI -

En 1969: Se Crea el concepto de base de datos (Codd).- En 1970: Se Desarrolla las primeras bases de datos y las primeras aplicaciones empresariales (SAP, JDEdwards, Siebel, Peoplesoft). Estas aplicaciones permitieron realizar “Data Entry” en los sistemas, aumentando la información disponible, pero no fueron capaces de ofrecer un acceso rápido y fácil a dicha información, aparece los dispositivos de acceso directo(Dasd).

-

En 1980: Creación del concepto data Warehouse (RalphKimball, Bill Inmon), y aparición de los primeros sistemas de reporting. A pesar de todo, seguía siendo complicado y funcionalmente pobre. Existían relativamente potentes sistemas de bases de datos pero no había aplicaciones que facilitasen su explotación.

-

En 1989: Introducción del término Business Intelligence(Howard Dresner)

-

En 1990: Business Intelligence 1.0. Proliferación de múltiples aplicaciones BI. Estos proveedores resultaban caros, pero facilitaron el acceso a la información, y en cierto modo agravaron el problema que pretendían resolver (¡Había aún más versiones dela verdad).

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

- Las empresas empezaron a interesarse en las soluciones de BI de una forma más decisiva, esto a finales de 1996, cuando el concepto se difundió como un proceso de evolución del Executive Information Systems (EIS) - un sistema creado a finales de la década del 70 en el MIT (Massachusets Institute ofTecnology-EUA). -

En 2000: Business Intelligence 2.0. Consolidación de las aplicaciones BI en unas pocas plataformas Business Intelligence (Oracle, SAP, IBM, Microsoft). A parte de la información estructurada, se empieza a considerar otro tipo de información y documentos no estructurados.

El componente de inteligencia de negocios que ayuda a resolver los problemas actuales de las empresas son los DataWarehouse así como la construcción de los Data Marts. Con la ausencia de BI, existe de hecho un hueco: Cuando los usuarios toman decisiones y analizan riesgos y oportunidades basados en información anecdótica, incompleta o desactualizada, lo cual no es mejor que adivinar. No solo advierte de los problemas, sino también de las oportunidades. Inteligencia de Negocios es el conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa Según Peña (2006), el término Inteligencia de Negocios procura caracterizar una amplia variedad de tecnologías, plataformas de software, especificaciones de aplicaciones y procesos. El objetivo primario de la a Inteligencia de Negocios es contribuir a tomar decisiones que mejoren el desempeño de la empresa y promover su ventaja competitiva en el mercado. En resumen, la Inteligencia de Negocios faculta a la organización a tomar mejores decisiones más rápidas. Este concepto se requiere analizar desde tres perspectivas: Hacer mejores decisiones más rápido, convertir datos en información, y usar una aplicación relacional para la administración.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Este conjunto de herramientas y metodologías tienen en común las siguientes características: -

Accesibilidad a la información: Los datos son la fuente principal de este concepto. Lo primero que deben garantizar este tipo de herramientas y técnicas será el acceso de los usuarios a los datos con independencia de la procedencia de estos.

-

Apoyo en la toma de decisiones: Se busca ir más allá en la presentación de la información, de manera que los usuarios tengan acceso a herramientas de análisis que les permitan seleccionar y manipular sólo aquellos datos que les interesen.

-

Orientación al usuario final: Se busca independencia entre los conocimientos técnicos de los usuarios y su capacidad para utilizar estas herramientas

LIDERES Y GURÚS DEL BI-DATAWAREHOUSE-DATAMARTS Son aquellas personas que han hecho historia en el campode BI ya que han aportado gran cantidad de ideas para luegoaplicarlo a las empresas. Por lo que vamos a mencionar aalgunos de ellos: Ralph Kimball: Dimensional Data Warehouse Guru.Ralph Kimball Associat es autor de "The Data WarehouseToolkit". Mejora su libro y define múltiples bases de datos llamados DataMarts que son organizados por procesos de negocio, pero usan medios de datos estandarizados para la empresa.  Bill Inmon: Es reconocido por muchos como el “Padre del DataWarehouse”. Se trata definitivamente de un influyente hombre en el mundo de la informática, a lo largo de la historia.  Nigel Pendse: Lead author the OLAP report. Experto en OLAP. Es el principal analista de OLAP Survey Report, que proporcionan información en el mundo de BI, especialmente si se selecciona una herramienta en laque se basa un sistema de BI y para obtener un análisis profesional e independiente de los mejores productos disponibles en el mercado.  Douglas Hackney: Presidente de Enterprise Group Itd. Experto en data marts

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

II. DEFINICIONES Es un pequeño DataWarehouse, para un determinado número de usuarios, para un área funcional, especifica de la compañía. También podemos definir que un Data Marts es un subconjunto de una bodega de datos para un propósito específico. .Es una base de datos orientada a un tema específico. En otras palabras es un subconjunto del DataWarehouse Corporativo. Un Datamart es una base de datos departamental, especializada en el almacenamiento de los datos de un área de negocio específica. Se caracteriza por disponer la estructura óptima de datos para analizar la información al detalle desde todas las perspectivas que afecten a los procesos de dicho departamento. Un datamart puede ser alimentado desde los datos de un DataWareHouse, o integrar por si mismo un compendio de distintas fuentes de información.

III.

TIPOS DE DATAMART

 DATAMART OLAP Se basan en los populares cubos OLAP, que se construyen agregando, según los requisitos de cada área o departamento, las dimensiones y los indicadores necesarios de cada cubo relacional. El modo de creación, explotación y mantenimiento de los cubos OLAP es muy heterogéneo, en función de la herramienta final que se utilice.

 DATAMART OLTP Pueden basarse en un simple extracto del datawarehouse, no obstante, lo común es introducir mejoras en su rendimiento (las agregaciones y los filtrados suelen ser las operaciones más usuales) aprovechando las características particulares de cada área de la empresa.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Las estructuras más comunes en este sentido son las tablas report, que vienen a ser fact-tables reducidas (que agregan las dimensiones oportunas), y las vistas materializadas, que se construyen con la misma estructura que las anteriores, pero con el objetivo de explotar la reescritura de consultas.

IV. CARACTERISTICAS DE LOS DATAMART Algunas características de los DataMarts, son: - Son pobladas por usuarios finales. - Se optimizan en función a procesos transaccionales. - Se actualizan constantemente. - Contienen mucha información de detalle. - Orientado al tema. - Integrado - De tiempo variante. - No volátil. - Escalable.

V. VENTAJAS Y DESVENTAJAS BENEFICIOS 

Implementación rápida y sencilla.



Menor costo de implementación.



Cubre necesidades específicas del negocio.



Respuestas rápidas por el menor volumen de información.



Asegura la consistencia de los datos

 Permite al acceso de los datos por medio de un gran número de herramientas del mercado, logrando independencia de estas.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL



Dado que un DataMart soporta menos usuarios que un DataWarehouse se puede optimizar para recuperar más rápidamente los datos que necesitan los usuarios.

DESVENTAJAS  Inadvertidamente se puede usar datos no compatibles con otros DataMarts que luego alarguen el tiempo de unificación.  Si el Datawarehouse es construido primero, se requiere de hardware adicional para soportar DataMarts individuales.  Datos descentralizados debido a que cada DataMart corresponde a una base de datos individual por tema o por área.  No permite el manejo de grandes volúmenes de información por lo que muchas veces se debe recurrir a un conjunto de DataMarts para cubrir todas las necesidades de información de la empresa.

VI. ARQUITECTURAS ROLAP, MOLAP, HOLAP Los cubos, las dimensiones y las jerarquías son la esencia de la navegación multidimensional del OLAP. Al describir y representar la información de esta forma, los usuarios pueden navegar intuitivamente en un conjunto complejo de datos. Sin embargo, el solo describir el modelo de datos en una forma más intuitiva, hace muy poco para ayudar a entregar la información al usuario más rápidamente. Estos vendedores llamaron a esta tecnología OLAP relacional (ROLAP). Las primeras compañías adoptaron entonces el término OLAP multidimensional (MOLAP), estos conceptos, MOLAP y ROLAP, se explican con más detalle en los siguientes párrafos. Las implementaciones MOLAP normalmente se desempeñan mejor que la tecnología ROLAP, pero tienen problemas de escalabilidad. Por otro lado, las implementaciones ROLAP son más escalables y son frecuentemente atractivas a los clientes debido a que aprovechan las inversiones en tecnologías de bases de datos relacionales preexistentes:

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

 MOLAP: La arquitectura MOLAP usa una base de datos multidimensionales para proporcionar el análisis, su principal premisa es que el OLAP esta mejor implantado almacenando los datos multidimensionalmente.  ROLAP: Relational OLAP. Tanto los datos pre calculados y agregados como los datos fuente residen en la misma base de datos relacional. Si el DataWarehouse es muy grande o se necesita rapidez por parte de los usuarios puede ser un problema.  HOLAP: Hybrid OLAP: es una combinación de los dos anteriores. Los datos agregados y pre calculados se almacenan en estructuras multidimensionales y los de menor nivel de detalle en el relacional. Requiere un buen trabajo de análisis para identificar cada tipo de dato.

VII. COMPONENTES EN LA CREACIÓN DE UN DATAMART 5.1 FUENTES DE DATOS Son las que alimentan de información al DataWarehouse, están diseñadas para registrar grandes cantidades de transacciones. Entre ella tenemos la base de datos OLTP (Una base de datos para soportar procesos transaccionales).

Características: -

Son pobladas por usuarios finales.

-

Se optimizan en función a procesos transaccionales.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

-

Se actualizan constantemente.

-

Contienen mucha información de detalle

 OLTP: (On-Line Transaction Processing) Sistemas de procesamiento de transacciones en línea o sistemas transaccionales, en los cuales residen las operaciones del día a día de cada negocio y que son la fuente prioritaria de datos para cada DataMart o el DataWarehouse corporativo.

5.2 PROCESOS DE EXTRACCIÓN, TRANSFORMACIÓN Y CARGA DE DATOS (ETL) Los datos se encuentran almacenados en base de datos destinados al registro de transacciones. Es necesario extraer y transformar los datos antes de cargar los resultados en el DataMart. Los mismos elementos de datos, si son usados por aplicaciones diferentes o administrados por diferentes software DBMS, pueden definirse al usar nombres de elementos inconsistentes, que tienen formatos inconsistentes y/o ser codificados de

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

manera diferente. Todas estas inconsistencias deben resolverse antes que los elementos de datos sean almacenados en el DataMart. Uno de los desafíos de cualquier implementación de DataWarehouse o DataMart, es el problema de transformar los datos. La transformación se encarga de las inconsistencias en los formatos de datos y la codificación, que pueden existir dentro de una base de datos única y que casi siempre existen cuando múltiples bases de datos contribuyen al DataMart. La transformación de datos también se encarga de las inconsistencias en el contenido de datos. Una vez que se toma la decisión sobre que reglas de transformación serán establecidas, deben crearse e incluirse las definiciones en las rutinas de transformación.

5.3 DATAWAREHOUSE Un DataWarehouse contiene la información de toda la empresa. Cualquier departamento puede acceder a la información de cualquier otro departamento mediante un único medio, así como obligar a que los mismos términos tengan el mismo significado para todos. Un Datamart almacena la información de un área o departamento específico y un conjunto de Datamarts forman un DataWarehouse.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Un Datamart es una solución que, compartiendo tecnología con el DataWarehouse (pero con contenidos específicos, volumen de datos más limitado y un alcance histórico menor), permita dar soporte a una empresa pequeña, un departamento o área de negocio de una empresa grande. El DataMart cubre de manera óptima las necesidades de informes. No es conveniente efectuar consultas sobre los sistemas transaccionales, debido a que hay que integrar datos de diversas OLTP. Los MetaDatos son información sobre los datos. Para un mercado de datos, metadatos incluyen: 

Una descripción de los datos en términos de negocio



Formato y definición de los datos en términos del sistema



Fuentes de datos y actualizar los datos de frecuencia

El objetivo principal para el proceso de gestión de metadatos es proporcionar un directorio de puntos de vista técnico y comercial de los metadatos DataMart. Los metadatos pueden ser categorizados como metadatos técnicos y los metadatos de negocio. Los metadatos técnicos se componen de metadatos creados durante la creación del mercado de datos, así como metadatos para apoyar la gestión de la despensa de datos. Esto incluye las normas de adquisición de datos, la transformación de los datos fuente en el formato requerido por la meta data mart y horarios para realizar copias de seguridad y restauración de datos. Metadatos de negocios permite a los usuarios finales para comprender qué tipo de información está disponible en el mercado de datos y la forma en que se puede acceder

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

7.4 HERRAMIENTAS DE EXPLOTACIÓN El DataMart está orientado a la toma de decisiones. Un buen diseño de la base de datos favorece el análisis y la recuperación de datos para obtener una ventaja estratégica y para facilitar la toma de decisiones.

El DataMart no está orientado a procesos relacionados con la operatividad del área determinada. El DataMart está preparado para ser explotado mediante herramientas específicas que permiten la extracción de información significativa y patrones de comportamiento que permanecen ocultos en un enorme repositorio de datos. Veamos las herramientas software que existen:

 HERRAMIENTA DE CONSULTA Y REPORTE Las herramientas de consulta al igual que la mayoría de herramientas visuales, permiten apuntar y dar un click a los menús y botones para especificar los elementos de datos, condiciones, criterios de agrupación y otros atributos de una solicitud de información. La herramienta de consulta genera entonces un llamado a

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

una base de datos, extrae los datos pertinentes, efectúa cálculos adicionales, manipula los datos si es necesario y presenta los resultados en un formato claro.

Se puede almacenar las consultas y los pedidos de reporte para trabajos subsiguientes, como está o con modificaciones. El procesamiento estadístico se limita comúnmente a promedios, sumas, desviaciones estándar y otras funciones de análisis básicas. Aunque las capacidades varían de un producto a otro, las herramientas de consulta y reporte son más apropiadas cuando se necesita responder a la pregunta ¿"Qué sucedió"?.

 HERRAMIENTAS

DE

BASE

DE

DATOS

MULTIDIMENSIONALES / OLAP Las primeras soluciones OLAP (On Line Analytical Processing), estuvieron basadas en bases de datos multidimensionales (MDDBS). Un cubo estructural (dos veces un hipercubo o un arreglo multidimensional) almacenaba los datos para que se puedan manipular intuitivamente y claramente ver las asociaciones a través de dimensiones múltiples Pero este enfoque tiene varias limitaciones: 

Las nuevas estructuras de almacenamiento de datos requieren bases de datos propietarias. No hay realmente estándares disponibles para acceder a los datos multidimensionales.



La segunda limitación de un MDDB concierne al desarrollo de una estructura de datos. Las compañías generalmente almacenan los datos de la empresa en bases de datos relacionales, lo que significa que alguien tiene que extraer, transformar y cargar estos datos en el hipercubo.

 SISTEMAS DE INFORMACIÓN EJECUTIVOS Las herramientas de sistemas de información ejecutivos (Executive Information Systems - EIS), proporcionan medios sumamente fáciles de usar para consulta y análisis de la información confiable. Generalmente se diseñan para el usuario que necesita conseguir los datos rápidamente, pero quiere utilizar el menor tiempo

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

posible para comprender el uso de la herramienta. El precio de esta facilidad de uso es que por lo general existen algunas limitaciones sobre las capacidades analíticas disponibles con el sistema de información ejecutivo. Además,

muchas

de

las

herramientas

de

consulta/reporte

y

OLAP/multidimensional, pueden usarse para desarrollar sistemas de información ejecutivos. El concepto de sistema de información ejecutivo es simple: los ejecutivos no tienen mucho tiempo, ni la habilidad en muchos casos, para efectuar el análisis de grandes volúmenes de datos. El EIS presenta vistas de los datos simplificados, altamente consolidados y mayormente estáticas.

 HERRAMIENTAS DE DATA MINING Data Mining es una categoría de herramientas de análisis open-end. En lugar de hacer preguntas, se toma estas herramientas y se pregunta algo "interesante", una tendencia o una agrupación peculiar, por ejemplo. El proceso de Data Mining extrae los conocimientos guardados o información predictiva desde el DataMart sin requerir pedidos o preguntas específicas. Las herramientas Mining usan algunas de las técnicas de computación más avanzadas para generar modelos y asociaciones como redes neuronales, detección de desviación, modelamiento predictivo y programación genética. Data Mining es un dato-conducido, no una aplicación-conducida.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

VIII. FASES DE CONSTRUCCION Para el proceso de construcción de datos existen dos enfoques: 1) Construir primero un núcleo de bodega de datos y luego hacer varios DataMarts. 2) Construir primero un DataMart e ir expandiendo poco a poco la bodega de datos y añadiendo nuevos DataMarts. La construcción del DataMart puede ser en forma total (completa}, o incremental.  CONSTRUCCION TOTAL (COMPLETA). Cuando se ejecuta la construcción desde el 03 Designer, el DataMart generado corresponde al modelo activo actualmente en el 03 Designer.  CONSTRUCCION INCREMENTAL. Es utilizado para actualizar la información del DataMart, evitando la reconstrucción completa a los efectos de ahorrar tiempo y recursos del sistema. ENTORNO DEL 03 DESIGNER

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

IX. PASOS PARA IMPLEMENTAR UN DATAMART PASO 1: IDENTIFICAR LOS TEMAS DE ANÁLISIS. Esta tarea consiste en definir los temas y sus respectivos indicadores que serán analizados y explotados por los usuarios, por ejemplo: Tema: Ventas en una farmacia. Indicadores: Cantidad Vendida, Precio Unitario, Total, Descuento, IGV, etc. PASO 2: IDENTIFICAR LAS DIMENSIONES DE INFORMACIÓN. Las dimensiones de Información es la forma cómo el usuario podrá agrupar la Información .Las dimensiones siempre deben responder una de estas6 preguntas: A Quién, Dónde, Cuándo, Qué, Cómo y A quien .Recuerde que el usuario siempre necesitará que el DataMarts le responda cualquiera de estas preguntas con la finalidad de poder tomar dediciones más acertadas. PASO 3: ELABORACIÓN DEL MODELO MULTIDIMENSIONAL BÁSICO Con ayuda de alguna herramienta CASE, deberá diseñar un modelo multidimensional capaz de soportar cualquiera de las consultas que los usuarios puedan hacer en un futuro al Data Marts. El esquema empleado como Copo de Nieve (Las tablas se normalizan en tablas más pequeñas), Estrella (Una tabla de hechos en el centro conectada con un conjunto de tablas de dimensiones). constelación de estrellas (Múltiples tablas de hechos comparten tablas de dimensión que se visualizan como una colección de hechos) ,

tormenta de nieve, etc., dependerá de la herramienta de explotación que estén utilizando PASO 4: ELABORACIÓN DEL MODELO MULTIDIMENSIONAL COMPLEJO En esta etapa se realiza el proceso de calificación a los indicadores y a los atributos.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

En un modelo multidimensional complejo los usuarios podrán segmentar a los clientes, productos o cualquier otro atributo en forma fácil y sencilla, pudiendo diferenciarlos según cuanto consumen y/o como consumen. Por ejemplo: Si queremos segmentar a productos según la rotación delos últimos 6 meses, se puede crear un grupo personalizado llamado: Calificación de productos en el que se especifica si tiene alta, mediana o baja rotación.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

PASO 5: ELABORACIÓN DE LAS ESPECIFICACIONES DE CARGA DE DATOS Este es el momento donde se trata de buscar la información en las diferentes fuentes de datos de la organización para cargar el modelo multidimensional creado. PASO 6: CREACIÓN DE BASE DE DATOS. Se debe crear una base de datos que contendrá la información del DataMarts que será explotada. En el caso que no exista una metadata se deberá crear una base de datos en blanco con las características y especificaciones técnicas de la herramienta que será utilizada para la explotación de los datos. PASO 7: CONSTRUCCIÓN DE LA ARQUITECTURA DEL DATA MARTS. Este es el momento donde se construyen la arquitectura del DATAMART, que en el caso de las herramientas MOLAP serían los cubos de información. PASO 8: ETL Consiste en extraer, transformar y cargar los datos de los sistemas fuentes hacia la base de datos del DataMarts. Los programas de ETL deben cumplir con las especificaciones que se desarrollaron en el paso 5, con la finalidad de llevar una correcta documentación del proyecto. Los programas de cargas deben verificar los errores de integridad referencial y limpiarla en el caso que se detecte alguna ocurrencia. Una mala planificación o construcción de los programas de ETL pueden ocasionar que los usuarios dejen de usar el DataMarts, por ejemplo: o La información está inconsistente o Sólo se tiene cargado pocos periodos debido a la falta de espacio en el disco. o La carga se paralizó debido a que uno de los programas identificó que existe datos inconsistentes. o Los programas no se ejecutaron en el momento que se requerían. o No se puede reprocesar la información y se mantienen datos no certeros.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

PASO 9: IMPLEMENTACIÓN Un motivo relevante por el cual los usuarios no utilizan los DataMarts es por falta de capacitación PASO 10: CAPACITACIÓN AL USUARIO Otro de los principales motivos por el cual los usuarios no utilizan los DataMarts es por falta de capacitación. La capacitación que debe recibir el usuario debe estar enfocada en: a. El Modelo Multidimensional.- Es importante que los usuarios conozcan los diferentes modelo multidimensionales de la empresa. b. La Herramienta de explotación:- Se dice que los usuarios solo utilizan el 20% de las opciones que cuentan las herramientas de explotación por falta de capacitación. c. Las herramientas de gestión:- Los usuarios deben ser constantemente capacitados en herramientas de gestión como creación de Dashboard, Scorecard, etc

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

6. REPRESENTACIONES GRAFICAS

DATAMART

Almacenamiento de los datos de un área de negocio específica

DataMarts Dependientes

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Funcionamiento de un DataMart con un DataWarehouse

Componentes en la Creación de un DataMart

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

7. EJEMPLO DE APLICACION EJEMPLO N° 1: TEMA: “IMPLEMENTACIÓN

EN SQL SERVER 2005 DE DATAMART PARA EL S O P O R T E A L A T O M A D E D E C I S I O N E S EN LA CONSULTORÍA Y CONSTRUCCIÓN DE VIGAS DE HORMIGÓN ARMADO DE UNA E MPRESA CONSULTORA CONSTRUCTORA”

CAMPO DE APLICACIÓN: HORMIGÓN ARMADO - RAMA DE LA INGENIERÍA CIVIL El hormigón es un material semejante a la piedra obtenido mediante una mezcla de cemento, arena, grava yagua; mezcla que se endurece en encofrados con la forma y dimensiones del elemento deseado. La mayor parte consta de agregado fino y grueso. El refuerzo conformado usualmente por barras circulares de acero con deformaciones superficiales apropiadas para proporcionar anclaje, se coloca en los moldes antes de vaciar la mezcla. VIGAS SIMPLEMENTE REFORZADAS

Las vigas de solo hormigón son ineficientes como elementos sometidos a flexión debido a que la resistencia a flexión es muy limitada. En consecuencia, estas fallan por tensión a cargas bajas. Por esta razón, se colocan barras de acero de refuerzo en el lado sometido a tensión y tan cerca como sea posible de la cara inferior.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

ESCENARIO Este proyecto de investigación se extiende en el área del Data Warehouse y Data Mart (almacén de datos) de las bases de datos profesionales de las ciencias de la computación con campo de aplicación en la tecnología del hormigón armado de la ingeniería civil; específicamente, en el diseño y construcción del elemento horizontal denominado viga

PROBLEMA IDENTIFICADO Un problema identificado en el proceso de diseño/construcción de elementos de hormigón armado es la carencia de información compilada, precisa y de respaldo que permita soportar la toma de decisiones con relación a dicho proceso. Los elementos de hormigón armado como vigas, columnas, losas y otros, muy pocas veces se construyen exactamente conforme el cálculo proyectado en los planos; más bien, las desviaciones durante la construcción, ocurren frecuentemente y se van acumulando en dependencia de la cantidad de elementos que componen una edificación u otra obra civil. Estas desviaciones en la construcción a la larga ocasionan pérdidas económicas o reflejan una mala administración de fondos; pero sobre todo podrían lograr atentar contra el factor de seguridad funcional que debería ofrecer una obra de servicio. Es importante aclarar que, las desviaciones en la construcción de un elemento se deben muchas veces a un inadecuado manejo y conocimiento de la precisión que ofrecen los medios de construcción o bien se deben a fallas humanas de dirección y/o ejecución.

ABORDAJE DEL PROBLEMA Se pretende abordar el problema mediante el diseño e implementación de una inteligencia de negocio basada en un Data Warehouse soportado por un cubo o Data Mart multidimensional poblado a partir de una base de datos transaccional del proceso diseño/construcción; todo esto, para conformar el monitoreo de un conjunto de indicadores de rendimiento clave así como la obtención de información global en función de cualquier dimensión o variable y así obtener un sistema de soporte para la

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

toma de decisiones de la empresa. Se empleará la herramienta Microsoft SQL Server 2005 – Business Intelligence Development Studio.

DESARROLLO PRÁCTICO 1. INFORMACIÓN NECESARIA PARA EL APOYO A LA TOMA DE DECISIONES  Indicadores de Rendimiento Claves o KPIs   

Porcentaje de vigas construidas con algún desvío o defecto en su construcción. Porcentaje de vigas construidas con desvíos o defectos en la resistencia del hormigón. Porcentaje de vigas construidas con desvíos o defectos en la resistencia del acero

 Medidas           

Cantidad de vigas construidas. Cantidad de vigas construidas con algún desvío en su construcción. Cantidad de vigas con desvíos en su construcción con relación a la resistencia del hormigón. Cantidad de vigas con desvíos en su construcción con relación a la resistencia del acero. Cantidad de vigas con desvíos en su construcción con relación al ancho de la sección. Cantidad de vigas con desvíos en su construcción con relación al alto de la sección. Cantidad de vigas con desvíos en su construcción con relación a su largo o vano. Cantidad de vigas con desvíos en el área del acero de refuerzo. Cantidad de vigas con desvíos en la resistencia (momento) de diseño. Diferencia de volumen del elemento construido respecto al volumen de diseño. Diferencia de costo del elemento construido respecto al costo de diseño

 Dimensiones    

Acero de refuerzo: código y diámetro Asignaciones: obra e ingeniero ejecutor Familia: tipo de sección de la viga y naturaleza de la falla Tiempo: gestión y mes

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

2. INFORMACIÓN DISPONIBLE La empresa cuenta con una fuente OLTP base de datos relacional SQL Server conformada a partir de las siguientes tablas: En esta tabla denominada INGE se almacenan los nombres de los ingenieros ejecutores o constructores delos elementos de hormigón armado. En la tabla PROY se almacenan las descripciones de las obras o proyectos encargados a la empresa.

En la tabla ASIGN se relacionan los ingenieros constructores y los proyectos a su cargo mediante llaves foráneas que hacen referencia a las llaves primarias delas dos tablas anteriores.

En la tabla BARRA se almacenan los diámetros de los distintos tamaños de barras de acero usados en la construcción.

En la tabla TIEMPO se almacenan la gestión y el mes para ser usados en el historial de obras proyectadas y ejecutadas por la empresa.

En la tabla FAMILIA se almacenan las posibles familias de vigas de hormigón armado según el tipo de sección y según la naturaleza de la falla (véase más abajo).

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

En la tabla VIDIS se almacenan las distintas variables involucradas en la etapa de DISEÑO de una viga de hormigón armado COAS Llave foránea; hace referencia a la tabla de asignaciones ingeniero-obra. RESHOR Resistencia del hormigón en Kg/cm². RESACER Resistencia del acero en Kg/cm². ANCHO Ancho de la sección (cm). ALTO Alto de la sección (cm).LONG Largo del elemento (m). VOL Volumen del elemento (m3).TSECC Tipo de sección (cuadrada o rectangular).COBA Llave foránea; referencia a la tabla de acero. CANTBA Cantidad de barras de acero. AACER Área del acero de refuerzo (cm²). CUANTOK “Sí” cuando la cuantía de acero está dentro delos límites permisibles. FALLA Naturaleza de la falla del elemento RESMOM Resistencia a momento del elemento. COSTO Costo del elemento (Bs.) COTM Llave foránea; a la tabla TIEMPO. COFM Llave foránea; a la tabla FAMILIA

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

En la tabla VICONS se almacenan las variables involucradas en la etapa de CONSTRUCCION de una viga de hormigón armado. COVI Llave foránea; a la viga en la tabla de diseño. COAS_C Llave foránea; a la tabla asignaciones ingeniero-obra. RESHOR_C Resistencia del hormigón armado en Kg/cm². RESACER_C Resistencia del acero en Kg/cm². ANCHO_C Ancho de la sección (cm).ALTO_C Alto de la sección (cm). LONG_C Largo del elemento (m). VOL_C Volumen del elemento (m3). TSECC_C Tipo de sección (cuadrada o rectangular) COBA_C Llave foránea; a la tabla barras de acero. CANTBA_C Cantidad de barras de acero. AACER_C Área del acero de refuerzo (cm²). CUANTOK_C “Sí” cuando la cuantía de acero está dentro de límites. FALLA_C Naturaleza de falla del elemento. RESMOM_C Resistencia a momento del elemento COSTO_C Costo del elemento (Bs.) COTM_C Llave foránea; hace referencia a la tabla TIEMPO.COFM_C Llave foránea; hace referencia a la tabla FAMILIA

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Todas estas tablas se relacionan según la lógica del proceso diseño/construcción de vigas de hormigón armado. Como puede apreciarse en el diseño lógico de a continuación, las tablas principales son las tablas de diseño VIDIS y de construcción VICONS del elemento viga

Diseño lógico del OLTP fuente

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

3. MODELO DE DATOS PARA EL DATAMART Conforme las exigencias de la empresa con relación a la información requerida para la toma de decisiones, se ha estructurado el Data Mart o cubo de la siguiente manera: En la tabla DIMASIGN se almacena la dimensión de asignaciones; útil para visualizar el análisis en función de la obra o bien en función del ingeniero ejecutor del elemento viga.

En la tabla DIMBARRA se almacena la dimensión del acero; útil para visualizar el análisis en función de la denominación o bien del diámetro de la barra del acero de refuerzo. En la tabla DIMFAMILIA se almacena la dimensión dela familia de vigas; útil para visualizar el análisis en función del tipo de la sección o en función de la naturaleza de falla del elemento.

En la tabla DIMTIEMPO se almacena la dimensión del tiempo; útil para visualizar el análisis por gestión o bien por mes.

Aunque la herramienta Business Intelligence de Microsoft SQL Server permite poblar la dimensión tiempo de manera automatizada, en el presente trabajo se ha preferido administrarla manualmente para tener un mejor control sobre la dimensión misma; incluso para poder disponer de una correcta ordenación (cronológica en vez de alfabética).

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

RES_HOR_ERR # de vigas con desvíos en la resistencia del hormigón. RES_ACER_ERR # de vigas con desvíos en la resistencia del acero. ANCHO_ERR # de vigas con desvíos en el ancho de la sección. ALTO_ERR # de vigas con desvíos en el alto dela sección. LARGO_ERR # de vigas con desvíos en el largo o vano. VOL_DIF volumen (m3). A_ACERO_DIF de acero(cm²).

Diferencia de

Diferencia en el área

RES_MOM_ERR # de vigas con desvíos en la resistencia a momento. COSTO_DIF

Diferencia en el costo (Bs.)

ELE_ERR

# de vigas con algún desvío en su construcción.

Las medidas y las llaves foráneas de las dimensiones se ensamblan en la tabla de hechos VIGAFACT.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

El formulario de expresiones matemáticas que permiten el cálculo de las diversas medidas de la tabla de hechos, se describe a continuación. Es importante adelantar que, todas estas fórmulas han sido implementadas en una vista diseñada sobre el OLTP para efectos de la etapa ETL (EXTRACTIONTRANSFER LOADING), como se verá un poco más adelante. Medida

Fórmula Matemática

RES_HOR_ERR

SIGN(ABS(VICONS.RESHOR_CVIDIS.RESHOR))

RES_ACER_ERRSIGN

(ABS(VICONS.RESACER_CVIDIS.RESACER))

ANCHO_ERR

SIGN(ABS(VICONS.ANCHO_C-VIDIS.ANCHO))

ALTO_ERR

SIGN(ABS(VICONS.ALTO_C-VIDIS.ALTO))

LARGO_ERR

SIGN(ABS(VICONS.LONG_C-VIDIS.LONG))

VOL_DIF

(VICONS.VOL_C-VIDIS.VOL)

A_ACERO_DIF

(VICONS.AACER_C-VIDIS.AACER)

RES_MOM_ERR SIGN

(ABS(VICONS.RESMOM_C-VIDIS.RESMOM))

COSTO_DIF

(VICONS.COSTO_C-VIDIS.COSTO)

ELE_ERR

SIGN(ABS(RES_HOR_ERR + RES_ACER_ERR + ANCHO_ERR + ALTO_ERR + LARGO_ERR + A_ACER_DIF)

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

El modelo del cubo o Data Mart está centrado en la tabla de hechos VIGAFACT a partir de la cual se “desprenden” todas las dimensiones. Se trata de un modelo tipo estrella (star ):

Modelo del cubo; un esquema tipo estrella

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

4. IMPLEMENTACION DEL CUBO EN MICROSOFT SQL SERVER 2005 Primero, el cubo o Data Mart debe ser creado en Microsoft SQL Server 2005 de acuerdo a la siguiente secuencia SQL:

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Luego, el cubo debe ser implementado mediante un proyecto Analysis Services de Business Intelligence de Microsoft SQL Server 2005.Primero, se crean los orígenes de datos mediante conexiones a la base de datos de la fuente OLTP y almodelo del cubo anteriormente creado; esto, se aprecia en la siguiente captura:

Orígenes de datos para la implementación del cubo.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Luego, se crea una vista del origen de datos a partir del modelo ya existente en la base de datos. La captura correspondiente se aprecia en la siguiente página

Vista del origen de datos

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

A continuación se va implementando el cubo. Durante la implementación del cubo, se deben identificar las tablas de hechos y las tablas de dimensiones conforme se muestra a continuación

Identificación de las tablas y de dimensiones Cuando el diseño físico del cubo está correctamente realizado, el software hace un reconocimiento automático de las tablas de hechos y dimensiones según se puede apreciar en la ilustración anterior..

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Enseguida, se muestra el DataMart implementado conforme el diseño expuesto con anterioridad. Puede distinguirse rápidamente un esquema tipo estrella. Véase la ilustración siguiente.

El cubo o DataMart creado y reconocido correctamente

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Una vez realizado el cubo, se configuran las estructuras de las dimensiones del mismo por medio del reconocimiento de jerarquías o niveles pero a partir de la vista de datos; esto, conforme se muestra a continuación.

Debe editarse la estructura de cada dimensión del cubo Antes de continuar con las demás etapas de conformación del cubo como el diseño de las agregaciones, sedebe poblar el DataMart a partir de las fuentes OLTP mediante la herramienta Integration Services de Business Intelligence disponible también en la suite Microsoft SQL Server 2005. Entonces, una vez creado un nuevo proyecto del tipo Integration Services, se diseña un paquete de flujo de control para organizar y comandar las diversas tareas de integración de información o flujo de datos. El paquete de flujo de control para éste

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

proyecto incluye tres tareas principales: una tarea para el borrado de contenidos de las tablas del DataMart, otra tarea para el poblado de las dimensiones del cubo y una última tarea para el poblado de la tabla de hechos. Nota: El poblado de las dimensiones del cubo debe ir siempre antes que la tabla de hechos porque contiene las llaves primarias.

El paquete de flujo de control para éste proyecto.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

El paquete de flujo de control para éste proyecto. En este paquete de flujo de control, la primera tarea de borrado de las tablas del cubo ha sido programada según el siguiente conjunto de instrucciones SQL:

La secuencia SQL para la primera tarea. La segunda tarea de flujo de datos contiene una serie de transferencias de información desde las tablas y vistas de la fuente OLTP hacia las tablas de dimensiones del Data Mart. Los orígenes de datos son accesos a la fuente OLTP del tipo OLE (Object Linked Embedded) DB Source. Y los destinos son accesos al DataMart del tipo OLE DB Target. Esto puede apreciarse a continuación:

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

La segunda tarea de flujo de datos Es importante señalar que, para poblar la dimensión de asignaciones o DIMASIGN, se ha diseñado una vista (consulta) específica en la fuente OLTP de acuerdo a la siguiente secuencia SQL:

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

El mapeo de campos entre los orígenes y destinos de datos prácticamente resulta automático cuando se diseña el DataMart procurando mantener los nombres de los campos originales.

Ejemplo de las asignaciones entre el origen y el destino de datos para el ETL Para poblar las dimensiones del cubo no se ha usado la opción de direccionamiento en caso de error por las siguientes razones: porque se han diseñado vistas específicas libres de error, porque se tiene una fuente previamente limpiada y porque se prefiere una excepción en caso de error. La última tarea del paquete del flujo de control consiste en el poblado de la tabla de hechos del cubo. Además de usar controles tipo OLE para el origen y destino de datos, se ha incluido un control transformador para efectuar algunos cálculos importantes a partir de la fuente OLTP

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

La tarea de flujo de datos para poblar la tabla de hechos incluye un control transformador La VISTA01 mostrada en la ilustración anterior ha sido diseñada sobre la fuente OLTP exclusivamente para éste proceso ETL y según la siguiente secuencia SQL:

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Importante comentar que, la aplicación de la función matemática del signo SIGN al valor absoluto ABS dela diferencia entre un valor final con respecto a uno inicial, da 1 si hay alguna diferencia y 0 si no hay ninguna. Esto para que en el cubo pueda tenerse medidas acumulativas y sumatorias con respecto a la información de análisis. Por otra parte, el control de transformación CALCULOS (ilustración 18) ha sido empleado para obtener la columna derivada ELE_ERR a partir del OLTP fuente. Esta columna ELE_ERR contiene 1 si el elemento viga de hormigón ha sufrido algún defecto durante su construcción, y contiene 0 (cero) si ha sido construido estrictamente según el diseño. Como se vio anteriormente, su fórmula es la siguiente:

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Y el detalle de su implementación se aprecia en el cuadro de diálogo de la ilustración siguiente:

Implementación del control tipo transformador Con relación a las asignaciones para la tabla de hechos, éstas resultan casi del todo automáticas cuando se han mantenido en lo posible los nombres de los campos iguales a los de la fuente origen OLTP. Esto se aprecia en la captura de pantalla de a continuación

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Las asignaciones de campos para la tabla de hechos del cubo

Una vez preparadas todas las tareas descritas anteriormente, se ejecuta el paquete de flujo de control obteniendo resultados satisfactorios (color verde) como se aprecia en la ilustración siguiente:

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Ejecución satisfactoria del paquete de flujo de control Finalizada la etapa ETL, se vuelve al servicio de análisis para concluir de implementar el cubo. Se diseñan las agregaciones para el modelo multidimensional MOLAP de actualización manual:

Modo de almacenamiento MOLAP sin caché

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Inmediatamente, se ejecuta el diseño de la agregación eligiendo el factor “almacenamiento estimado”:

Diseño de la agregación Con el diseño de la agregación concluido, se procesan dichas agregaciones para las dimensiones del cubo conforme se muestra en la ilustración siguiente:

Procesamiento de las dimensiones del cubo

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Una vez preparadas las agregaciones, ya se puede examinar preliminarmente el cubo:

Examinar el cubo. Conforme se puede apreciar en la ilustración anterior, el cubo se ve implementado con éxito.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Ante de manipular el cubo para efectos prácticos y con el fin de obtener una mejor legibilidad de las dimensiones y medidas del mismo, se procede con el completado de las traducciones según lo siguiente:

Completado de las traducciones para una mejor legibilidad del cubo

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

De ésta manera, puede hacerse un primer uso práctico del cubo como se muestra en la ilustración siguiente:

Un primer uso real del cubo. En la anterior ilustración se puede apreciar que se está consultando la “diferencia de costo” (construido vs. presupuestado) por obra por gestión por asignación y filtrado por tipo de sección de viga. En este caso de estudio de ejemplo puede apreciarse que, en la gestión 2007, la construcción de todas las vigas involucradas en las obras mostradas, ha costado casi 70 bolivianos menos de lo presupuestado; todo esto, bajo responsabilidad del “ING. POEPSEL”.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

EJEMPLO N°2: TEMA:

“DESARROLLO DE UN DATAMARTS DE INFORMACIÓN

ACADÉMICA DE ESTUDIANTES DE LA ESCUELA DE CIENCIAS Y SISTEMAS DE LA

FACULTAD DE INGENIERÍA DE LA USAC”-

GUATEMALA, AGOSTO DE 2007

POR: Mario Reyes y Pablo Rosales RESUMEN: El presente informe final enumera y describe cada uno de los aspectos realizados dentro del programa de Ejercicio Profesional Supervisado, que se llevó a cabo en la Escuela de Ciencias y Sistemas de la Facultad de Ingeniería, de la Universidad de San Carlos de Guatemala, con el fin de diseñar y desarrollar una herramienta de inteligencia de negocio que permita el análisis de información académica, y a la vez apoye en la toma de decisiones a las autoridades de la Escuela.

RESULTADOS: - La creación del presente DataMart permitirá que las diferentes áreas o unidades de la facultad cuenten con información académica de una forma autónoma, sin que exista la dependencia de centro de cálculo, siempre guardando los debidos controles de seguridad y acceso a la información. - Contar con una herramienta de inteligencia de negocio en la Escuela de Ciencias y Sistemas, facilitará la información que muchas empresas requieren sobre referencias de los estudiantes que solicitan empleos. Así también, permitirá que la asignación de carga de estudiantes sea mejor distribuida entre los catedráticos, incluso entre otros recursos tales como los salones

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

EJEMPLO N°3: TEMA: “ANÁLISIS,

DISEÑO

E

IMPLEMENTACIÓN

DE

UN

DATAMART PARA EL ÁREA DE SISMOLOGÍA DEL DEPARTAMENTO DE GEOFÍSICA DE LA ESCUELA POLITÉCNICA NACIONAL”. - QUITO MARZO 2006

POR: Michael Vizuete y Carlos Yela RESUMEN: Este trabajo dio un breve recuento del desarrollo de una solución DataMart, para el departamento de sismología de la escuela politécnica nacional con el fin de mejorar el manejo de la información de dicha área para prevenir sismos que han producido un gran impacto en muchas comunidades causando grandes perdidas tanto humanas como económicas.

RESULTADOS. El horizonte de tiempo de los datos es muy diferente de un ambiente al otro. La información en el ambiente operacional es más reciente con respecto a la del Data mart. Desde la perspectiva de los horizontes de tiempo únicos, hay poca superposición entre los ambientes operaciones y de DataMart. El DataMart contiene un resumen de la información que no se encuentra en el ambiente operacional. Los datos experimentan una transformación fundamental cuando pasan al DataMart.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

8. CONCLUSIONES Y RECOMENDACIONES  La implementación de un proceso de inteligencia de negocio en una organización, permite que la información fluya de una forma natural y controlada desde donde se producen las transacciones del día a día de la organización, hasta convertirlas en información y conocimiento que permiten a los usuarios finales tomar mejores y efectivas decisiones.  El DataMart es específico para una necesidad de datos seleccionados, enfatizando el fácil acceso a una información relevante.  La diferencia principal entre los mercados de datos independientes y dependientes es la forma de llenar la despensa de datos, es decir, cómo obtener datos de las fuentes y en la despensa de datos.  El SQL es un lenguaje muy extendido entre los programadores, pero no tanto entre los usuarios finales. Aunque estas herramientas escondan en cierta forma los comandos del SQL, sigue siendo necesario tener claro el modelo relacional en cuanto se quiere hacer algún informe complejo, por lo que su utilización directa no está recomendada a usuarios finales.  Del ejemplo aplicativo N°1.La implementación en SQL Server 2005

de

DataMart tendrá grandes beneficios ya que brindara un soporte en la toma de decisiones que se realizará en la consultoría y construcción de vigas de hormigón armado de la empresa consultora constructora.  Del ejemplo aplicativo N°2. En la escuela de ciencias y sistemas se obtendrán grandes beneficios al utilizarse el DataMart académico, puesto que se podrá analizar el comportamiento de los estudiantes de la escuela y por ende se podrá tomar mejores decisiones en cuanto al uso de los recursos y el enfoque de la carrera de sistemas de la Facultad de Ingeniería.  Todas las empresas que manipulen información de mucha importancia debe implementar los Data Mart para poder darle un mejor manejo a toda esa

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

información y de esta manera realizar la toma de decisión adecuada dentro de cada área específica..

9. BIBLIOGRAFIA http://es.wikipedia.org/wiki/Data_mart http://santacruzramos.wikispaces.com/3.3+Mercados+de+datos+%28Da ta+Mart%29. http://www.cavsi.com/preguntasrespuestas/que-es-data-mart/ http://www.synerplus.es/Informacion-Tecnica/Data-Mart/309.html http://todotecnology.blogspot.com/2009/09/datamart.html http://marketing-intelligence.axesor.es/glosario/datamart http://es.scribd.com/doc/56869235/TESIS-DATAMART http://es.scribd.com/doc/101049355/Implementacion-en-SQL-Serverde-un-Data-Warehouse-en-la-Construccion-de-Hormigon-Armado http://www.slideshare.net/GustavoHernandez10/data-mart http://www.raynerhd.com/wp-content/uploads/rayner-datamart.pdf

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

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. El Data mart es un sistema orientado a la consulta, en el que se producen procesos batch de carga de datos (altas) con una frecuencia baja y conocida. Es consultado mediante herramientas OLAP (On line Analytical Processing - Procesamiento Analítico en Línea) que ofrecen una visión multidimensional de la información. Sobre estas bases de datos se pueden construir EIS (Executive Information Systems, Sistemas de Información para Directivos) y DSS (Decision Support Systems, Sistemas de Ayuda a la toma de Decisiones). Por otra parte, se conoce como Data Mining al proceso no trivial de análisis de grandes cantidades de datos con el objetivo de extraer información útil, por ejemplo para realizar clasificaciones o predicciones. En síntesis, se puede decir que los data marts son pequeños data warehouse centrados en un tema o un área de negocio específico dentro de una organización.

Dependencia de un data mart Según la tendencia marcada por Inmon sobre los data warehouse, un data mart dependiente es un subconjunto lógico (vista) o un subconjunto físico (extracto) de un almacén de datos más grande, que se ha aislado por alguna de las siguientes razones:  



Se necesita para un esquema o modelo de datos espacial (por ejemplo, para reestructurar los datos para alguna herramienta OLAP). Prestaciones: Para descargar el data mart a un ordenador independiente para mejorar la eficiencia o para obviar las necesidades de gestionar todo el volumen del data warehouse centralizado. Seguridad: Para separar un subconjunto de datos de forma selectiva a los que queremos permitir o restringir el acceso.

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL 

 



Conveniencia: la de poder pasar por alto las autorizaciones y requerimientos necesarios para poder incorporar una nueva aplicación en el Data Warehouse principal de la Empresa. Demostración sobre el terreno: para demostrar la viabilidad y el potencial de una aplicación antes de migrarla al Data Warehouse de la Empresa. Política: Cuando se decide una estrategia para las TI (Tecnologías de la información) en situaciones en las que un grupo de usuarios tiene más influencia, para determinar si se financia dicha estrategia o descubrir si ésta no sería buena para el almacén de datos centralizado. Política: Estrategia para los consumidores de los datos en situaciones en las que un equipo de almacén de datos no está en condiciones de crear un almacén de datos utilizable.

Según la escuela Inmon de data warehouse, entre las pérdidas inherentes al uso de data marts están la escalabilidad limitada, la duplicación de datos, la inconsistencia de los datos con respecto a otros almacenes de información y la incapacidad para aprovechar las fuentes de datos de la empresa. Así y todo estas herramientas son de gran importancia.

Conceptos erróneos de los Data Marts Al hablar de los data marts, es inevitable la comparación con los data warehouse y al final se acaba diciendo (o entendiendo) que son como estos, pero en pequeño, y en cierto modo esto es así, pero esta idea suele hacer caer en los siguientes errores sobre la implementación y funcionamiento de los data marts: 







Son más simples de implementar que un Data Warehouse: FALSO, la implementación es muy similar, ya que debe proporcionar las mismas funcionalidades. Son pequeños conjuntos de datos y, en consecuencia, tienen menor necesidad de recursos: FALSO, una aplicación corriendo sobre un data mart necesita los mismos recursos que si corriera sobre un data warehouse. Las consultas son más rápidas, dado el menor volumen de datos: FALSO, el menor volumen de datos se debe a que no se tienen todos los datos de toda la empresa, pero sí se tienen todos los datos de un determinado sector de la empresa, por lo que una consulta sobre dicho sector tarda lo mismo si se hace sobre el data mart que si se hace sobre el data warehouse. En algunos casos añade tiempo al proceso de actualización: FALSO, actualizar el data mart desde el data warehouse cuesta menos (ya que los formatos de los datos son o suelen ser idénticos) que actualizar el data warehouse desde sus fuentes de datos primarias, donde es necesario realizar operaciones de transformación (ver ETL).

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

Un mercado de datos Conceptos En este capítulo se revisan algunos conceptos básicos relacionados con los mercados de datos y establece algunas definiciones para su uso en el resto de este libro. Aunque hay una gran cantidad de acuerdos entre usuarios y proveedores sobre las definiciones y terminología, no han alcanzado todavía un consenso total. Si usted habla con una docena de personas, es probable que oír hablar de una media docena de respuestas similares pero ligeramente diferentes, incluso para algo tan básico como "¿Qué es un mercado de datos?" En este capítulo se da un vistazo rápido a algunas definiciones y explica lo que es un mercado de datos es (y no es).

En este capítulo se incluyen los temas siguientes:    

Sección A.1, "¿Qué es un Data Mart?" Sección A.2, "¿Cómo es diferente de un almacén de datos?" Sección A.3, "Data Marts dependientes e independientes" Sección A.4, "¿Cuáles son los pasos en la implementación de un Data Mart?"

A.1 ¿Qué es un Data Mart? Un data mart es una forma simple de un almacén de datos que se centra en un solo tema (o área funcional), como Ventas, Finanzas o Marketing. Mercados de datos son a menudo construida y controlada por un único departamento dentro de una organización. Dada su sola materia en el enfoque, mercados de datos por lo general obtener datos de sólo unas pocas fuentes. Las fuentes pueden ser los sistemas internos de funcionamiento, un centro de almacenamiento de datos o de datos externos.

A.2 ¿Cómo es diferente de un Data Warehouse? Un almacén de datos, a diferencia de un mercado de datos, se ocupa de temas múltiples y es típicamente implementado y controlado por una unidad central de organización, tales como

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL

la tecnología de la información corporativa (IT) del grupo. Con frecuencia, se llama un depósito central de datos o de la empresa. Por lo general, un almacén de datos reúne datos de los sistemas de múltiples fuentes. Nada en estas definiciones básicas limita el tamaño de un mercado de datos o la complejidad de los datos de soporte de decisiones que contiene. Sin embargo, los data marts son típicamente más pequeños y menos complejos que los almacenes de datos, por lo que por lo general son más fáciles de construir y mantener. Tabla A-1 se resumen las diferencias básicas entre un almacén de datos y un data mart. Tabla A-1 Diferencias entre un Data Warehouse y un Data Mart Categoría

Data Warehouse

Data Mart

Alcance

Corporativo

Línea de negocio (LOB)

Sujeto

Múltiple

Sujeto individual

Fuentes de datos

Muchos

Pocos

Tamaño (típico)

100 GB-TB +