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 APLICACIN 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 informacin y que cuente con una base de datos, sabemos que es necesario que esta se actualice constantemente, y el propsito de ella es proveer informacin a la empresa con un adecuado manejo como transformaciones, bsqueda de patrones y consolidaciones. Es as como nace el trmino 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 disean 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 informacin hacia varios Data Marts con el fin de permitir un anlisis ms eficiente. Y solo personal autorizado debe trabajar con las bases de datos y acceso a los Data Marts . En la mayora 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 informacin para poder sobrevivir. Sin embargo muchos de estos Data Marts fueron creados enfocados en los datos y no en las necesidades de informacin de los usuarios.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

3. OBJETIVO GENERAL
El presente trabajo tiene como objetivo brindar informacin y plantear las bases tericas para el desarrollo del DataMart y explicar de manera detallada dos aplicaciones dentro de la carrera de Ingeniera Civil.

4. OBJETIVOS ESPECIFICOS
Brindar las definiciones y conceptos bsicos sobre Data Mart. Mencionar las caractersticas importantes del Data Mart. Dar a conocer las ventajas y desventajas del Data Mart. Indicar y describir las fases de construccin 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 creacin de bienes con el mnimo de recursos. Distintos pueblos y en distintos perodos se practicaban la previsin, planeacin y organizacin de grupos para ejercitar diversas actividades (entre ellas la pesca, agricultura, el comercio, la guerra, etc.). En aos ms recientes durante la revolucin industrial se pusieron en prctica ideas que sirvieron para la creacin de la administracin, ya que durante ese tiempo se pens en la manera de producir ms con menos recursos. A partir de ese momento precursores e idealistas fueron sentando las bases para la creacin de la administracin convirtindola 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 artculos o servicios. Tal es as que nace el trmino de Business Intelligence que es bastante antiguo, hace miles de aos los maya/ incas, fenicios, persas, egipcios y otros pueblos practicaban este principio cuando usaban informacin 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 Espaa, despus de la conquista de Amrica. El rey espaol cre la "Casa del Oro", en donde se registraban las transacciones de pago compulsorio de oro, ello permiti tener una visin general de la economa del pas hispano. En los aos 60's surgen las tarjetas perforadas, los transistores y el lenguaje estructurado COBOL. Este nuevo despliegue tecnolgico, permiti al usuario facilitar el control de los sistemas y de la informacin.

LNEA 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 informacin disponible, pero no fueron capaces de ofrecer un acceso rpido y fcil a dicha informacin, aparece los dispositivos de acceso directo(Dasd). En 1980: Creacin del concepto data Warehouse (RalphKimball, Bill Inmon), y aparicin de los primeros sistemas de reporting. A pesar de todo, segua siendo complicado y funcionalmente pobre. Existan relativamente potentes sistemas de bases de datos pero no haba aplicaciones que facilitasen su explotacin. En 1989: Introduccin del trmino Business Intelligence(Howard Dresner) En 1990: Business Intelligence 1.0. Proliferacin de mltiples aplicaciones BI. Estos proveedores resultaban caros, pero facilitaron el acceso a la informacin, y en cierto modo agravaron el problema que pretendan resolver (Haba an ms versiones dela verdad).

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

- Las empresas empezaron a interesarse en las soluciones de BI de una forma ms

decisiva, esto a finales de 1996, cuando el concepto se difundi como un proceso de evolucin del Executive Information Systems (EIS) - un sistema creado a finales de la dcada del 70 en el MIT (Massachusets Institute ofTecnology-EUA). En 2000: Business Intelligence 2.0. Consolidacin de las aplicaciones BI en unas pocas plataformas Business Intelligence (Oracle, SAP, IBM, Microsoft). A parte de la informacin estructurada, se empieza a considerar otro tipo de informacin 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 construccin 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 informacin anecdtica, incompleta o desactualizada, lo cual no es mejor que adivinar. No solo advierte de los problemas, sino tambin de las oportunidades. Inteligencia de Negocios es el conjunto de estrategias y herramientas enfocadas a la administracin y creacin de conocimiento mediante el anlisis de datos existentes en una organizacin o empresa Segn Pea (2006), el trmino Inteligencia de Negocios procura caracterizar una amplia variedad de tecnologas, 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 desempeo de la empresa y promover su ventaja competitiva en el mercado. En resumen, la Inteligencia de Negocios faculta a la organizacin a tomar mejores decisiones ms rpidas. Este concepto se requiere analizar desde tres perspectivas: Hacer mejores decisiones ms rpido, convertir datos en informacin, y usar una aplicacin relacional para la administracin.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Este conjunto de herramientas y metodologas tienen en comn las siguientes caractersticas: Accesibilidad a la informacin: Los datos son la fuente principal de este concepto. Lo primero que deben garantizar este tipo de herramientas y tcnicas 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 ms all en la presentacin de la informacin, de manera que los usuarios tengan acceso a herramientas de anlisis que les permitan seleccionar y manipular slo aquellos datos que les interesen. Orientacin al usuario final: Se busca independencia entre los conocimientos tcnicos de los usuarios y su capacidad para utilizar estas herramientas

LIDERES Y GURS 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 [Link] Kimball Associat es autor de "The Data WarehouseToolkit". Mejora su libro y define mltiples 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 informtica, 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 informacin en el mundo de BI, especialmente si se selecciona una herramienta en laque se basa un sistema de BI y para obtener un anlisis 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 pequeo DataWarehouse, para un determinado nmero de usuarios, para un rea funcional, especifica de la compaa. Tambin podemos definir que un Data Marts es un subconjunto de una bodega de datos para un propsito especfico. .Es una base de datos orientada a un tema especfico. 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 especfica. Se caracteriza por disponer la estructura ptima de datos para analizar la informacin 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 informacin.

III.

TIPOS DE DATAMART
Se basan en los populares cubos OLAP, que se construyen agregando, segn los requisitos de cada rea o departamento, las dimensiones y los indicadores necesarios de cada cubo relacional. El modo de creacin, explotacin y mantenimiento de los cubos OLAP es muy heterogneo, en funcin de la herramienta final que se utilice.

DATAMART OLAP

DATAMART OLTP
Pueden basarse en un simple extracto del datawarehouse, no obstante, lo comn es introducir mejoras en su rendimiento (las agregaciones y los filtrados suelen ser las operaciones ms usuales) aprovechando las caractersticas particulares de cada rea de la empresa.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Las estructuras ms 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 caractersticas de los DataMarts, son: - Son pobladas por usuarios finales. - Se optimizan en funcin a procesos transaccionales. - Se actualizan constantemente. - Contienen mucha informacin de detalle. - Orientado al tema. - Integrado - De tiempo variante. - No voltil. - Escalable.

V. VENTAJAS Y DESVENTAJAS
BENEFICIOS
Implementacin rpida y sencilla. Menor costo de implementacin. Cubre necesidades especficas del negocio. Respuestas rpidas por el menor volumen de informacin. Asegura la consistencia de los datos

Permite al acceso de los datos por medio de un gran nmero 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 ms rpidamente los datos que necesitan los usuarios.

DESVENTAJAS
Inadvertidamente se puede usar datos no compatibles con otros DataMarts que luego alarguen el tiempo de unificacin. 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 volmenes de informacin por lo que muchas veces se debe recurrir a un conjunto de DataMarts para cubrir todas las necesidades de informacin de la empresa.

VI. ARQUITECTURAS ROLAP, MOLAP, HOLAP

Los cubos, las dimensiones y las jerarquas son la esencia de la navegacin multidimensional del OLAP. Al describir y representar la informacin 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 ms intuitiva, hace muy poco para ayudar a entregar la informacin al usuario ms rpidamente. Estos vendedores llamaron a esta tecnologa OLAP relacional (ROLAP). Las primeras compaas adoptaron entonces el trmino OLAP multidimensional (MOLAP), estos conceptos, MOLAP y ROLAP, se explican con ms detalle en los siguientes prrafos. Las implementaciones MOLAP normalmente se desempean mejor que la tecnologa ROLAP, pero tienen problemas de escalabilidad. Por otro lado, las implementaciones ROLAP son ms escalables y son frecuentemente atractivas a los clientes debido a que aprovechan las inversiones en tecnologas 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 anlisis, 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 combinacin 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 anlisis para identificar cada tipo de dato.

VII. COMPONENTES EN LA CREACIN DE UN DATAMART

5.1 FUENTES DE DATOS
Son las que alimentan de informacin al DataWarehouse, estn diseadas para registrar grandes cantidades de transacciones. Entre ella tenemos la base de datos OLTP (Una base de datos para soportar procesos transaccionales).

Caractersticas:
Son pobladas por usuarios finales. Se optimizan en funcin a procesos transaccionales.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Se actualizan constantemente. Contienen mucha informacin de detalle

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

5.2 PROCESOS DE EXTRACCIN, TRANSFORMACIN 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 desafos de cualquier implementacin de DataWarehouse o DataMart, es el problema de transformar los datos. La transformacin se encarga de las inconsistencias en los formatos de datos y la codificacin, que pueden existir dentro de una base de datos nica y que casi siempre existen cuando mltiples bases de datos contribuyen al DataMart. La transformacin de datos tambin se encarga de las inconsistencias en el contenido de datos. Una vez que se toma la decisin sobre que reglas de transformacin sern establecidas, deben crearse e incluirse las definiciones en las rutinas de transformacin.

5.3 DATAWAREHOUSE
Un DataWarehouse contiene la informacin de toda la empresa. Cualquier departamento puede acceder a la informacin de cualquier otro departamento mediante un nico medio, as como obligar a que los mismos trminos tengan el mismo significado para todos. Un Datamart almacena la informacin de un rea o departamento especfico y un conjunto de Datamarts forman un DataWarehouse.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Un Datamart es una solucin que, compartiendo tecnologa con el DataWarehouse (pero con contenidos especficos, volumen de datos ms limitado y un alcance histrico menor), permita dar soporte a una empresa pequea, 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 informacin sobre los datos. Para un mercado de datos, metadatos incluyen:

Una descripcin de los datos en trminos de negocio Formato y definicin de los datos en trminos del sistema Fuentes de datos y actualizar los datos de frecuencia

El objetivo principal para el proceso de gestin de metadatos es proporcionar un directorio de puntos de vista tcnico y comercial de los metadatos DataMart. Los metadatos pueden ser categorizados como metadatos tcnicos y los metadatos de negocio. Los metadatos tcnicos se componen de metadatos creados durante la creacin del mercado de datos, as como metadatos para apoyar la gestin de la despensa de datos. Esto incluye las normas de adquisicin de datos, la transformacin de los datos fuente en el formato requerido por la meta data mart y horarios para realizar copias de seguridad y restauracin de datos. Metadatos de negocios permite a los usuarios finales para comprender qu tipo de informacin 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 EXPLOTACIN

El DataMart est orientado a la toma de decisiones. Un buen diseo de la base de datos favorece el anlisis y la recuperacin de datos para obtener una ventaja estratgica 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 especficas que permiten la extraccin de informacin 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 mayora de herramientas visuales, permiten apuntar y dar un click a los mens y botones para especificar los elementos de datos, condiciones, criterios de agrupacin y otros atributos de una solicitud de informacin. La herramienta de consulta genera entonces un llamado a

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

una base de datos, extrae los datos pertinentes, efecta clculos 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 estadstico se limita comnmente a promedios, sumas, desviaciones estndar y otras funciones de anlisis bsicas. Aunque las capacidades varan de un producto a otro, las herramientas de consulta y reporte son ms 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 travs de dimensiones mltiples Pero este enfoque tiene varias limitaciones: Las nuevas estructuras de almacenamiento de datos requieren bases de datos propietarias. No hay realmente estndares disponibles para acceder a los datos multidimensionales. La segunda limitacin de un MDDB concierne al desarrollo de una estructura de datos. Las compaas 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 INFORMACIN EJECUTIVOS

Las herramientas de sistemas de informacin ejecutivos (Executive Information Systems - EIS), proporcionan medios sumamente fciles de usar para consulta y anlisis de la informacin confiable. Generalmente se disean para el usuario que necesita conseguir los datos rpidamente, 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 analticas disponibles con el sistema de informacin ejecutivo. Adems, muchas de las herramientas de consulta/reporte y

OLAP/multidimensional, pueden usarse para desarrollar sistemas de informacin ejecutivos. El concepto de sistema de informacin ejecutivo es simple: los ejecutivos no tienen mucho tiempo, ni la habilidad en muchos casos, para efectuar el anlisis de grandes volmenes de datos. El EIS presenta vistas de los datos simplificados, altamente consolidados y mayormente estticas.

HERRAMIENTAS DE DATA MINING

Data Mining es una categora de herramientas de anlisis open-end. En lugar de hacer preguntas, se toma estas herramientas y se pregunta algo "interesante", una tendencia o una agrupacin peculiar, por ejemplo. El proceso de Data Mining extrae los conocimientos guardados o informacin predictiva desde el DataMart sin requerir pedidos o preguntas especficas. Las herramientas Mining usan algunas de las tcnicas de computacin ms avanzadas para generar modelos y asociaciones como redes neuronales, deteccin de desviacin, modelamiento predictivo y programacin gentica. Data Mining es un dato-conducido, no una aplicacin-conducida.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

VIII. FASES DE CONSTRUCCION

Para el proceso de construccin de datos existen dos enfoques: 1) Construir primero un ncleo 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 aadiendo nuevos DataMarts. La construccin del DataMart puede ser en forma total (completa}, o incremental. CONSTRUCCION TOTAL (COMPLETA). Cuando se ejecuta la construccin desde el 03 Designer, el DataMart generado corresponde al modelo activo actualmente en el 03 Designer. CONSTRUCCION INCREMENTAL. Es utilizado para actualizar la informacin del DataMart, evitando la reconstruccin 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 ANLISIS. Esta tarea consiste en definir los temas y sus respectivos indicadores que sern 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 INFORMACIN. Las dimensiones de Informacin es la forma cmo el usuario podr agrupar la Informacin .Las dimensiones siempre deben responder una de estas6 preguntas: A Quin, Dnde, Cundo, Qu, Cmo 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 ms acertadas. PASO 3: ELABORACIN DEL MODELO MULTIDIMENSIONAL BSICO Con ayuda de alguna herramienta CASE, deber disear 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 ms pequeas), Estrella (Una tabla de hechos en el centro conectada con un conjunto de tablas de dimensiones). constelacin de estrellas (Mltiples tablas de hechos comparten tablas de dimensin que se visualizan como una coleccin de hechos) ,

tormenta de nieve, etc., depender de la herramienta de explotacin que estn utilizando PASO 4: ELABORACIN DEL MODELO MULTIDIMENSIONAL COMPLEJO En esta etapa se realiza el proceso de calificacin a los indicadores y a los atributos.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

En un modelo multidimensional complejo los usuarios podrn segmentar a los clientes, productos o cualquier otro atributo en forma fcil y sencilla, pudiendo diferenciarlos segn cuanto consumen y/o como consumen. Por ejemplo: Si queremos segmentar a productos segn la rotacin delos ltimos 6 meses, se puede crear un grupo personalizado llamado: Calificacin de productos en el que se especifica si tiene alta, mediana o baja rotacin.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

PASO 5: ELABORACIN DE LAS ESPECIFICACIONES DE CARGA DE DATOS Este es el momento donde se trata de buscar la informacin en las diferentes fuentes de datos de la organizacin para cargar el modelo multidimensional creado. PASO 6: CREACIN DE BASE DE DATOS. Se debe crear una base de datos que contendr la informacin del DataMarts que ser explotada. En el caso que no exista una metadata se deber crear una base de datos en blanco con las caractersticas y especificaciones tcnicas de la herramienta que ser utilizada para la explotacin de los datos. PASO 7: CONSTRUCCIN 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 seran los cubos de informacin. 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 documentacin 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 planificacin o construccin de los programas de ETL pueden ocasionar que los usuarios dejen de usar el DataMarts, por ejemplo: o La informacin est inconsistente o Slo 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 requeran. o No se puede reprocesar la informacin y se mantienen datos no certeros.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

PASO 9: IMPLEMENTACIN Un motivo relevante por el cual los usuarios no utilizan los DataMarts es por falta de capacitacin PASO 10: CAPACITACIN AL USUARIO Otro de los principales motivos por el cual los usuarios no utilizan los DataMarts es por falta de capacitacin. La capacitacin 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 explotacin:- Se dice que los usuarios solo utilizan el 20% de las opciones que cuentan las herramientas de explotacin por falta de capacitacin. c. Las herramientas de gestin:- Los usuarios deben ser constantemente capacitados en herramientas de gestin como creacin de Dashboard, Scorecard, etc

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

6. REPRESENTACIONES GRAFICAS

DATAMART

Almacenamiento de los datos de un rea de negocio especfica

DataMarts Dependientes

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Funcionamiento de un DataMart con un DataWarehouse

Componentes en la Creacin de un DataMart

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

7. EJEMPLO DE APLICACION
EJEMPLO N 1: TEMA: IMPLEMENTACIN
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 CONSULTORA Y CONSTRUCCIN DE VIGAS DE HORMIGN ARMADO DE UNA E MPRESA CONSULTORA CONSTRUCTORA

CAMPO DE APLICACIN: HORMIGN ARMADO - RAMA DE LA INGENIERA CIVIL

El hormign 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 hormign son ineficientes como elementos sometidos a flexin debido a que la resistencia a flexin es muy limitada. En consecuencia, estas fallan por tensin a cargas bajas. Por esta razn, se colocan barras de acero de refuerzo en el lado sometido a tensin y tan cerca como sea posible de la cara inferior.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

ESCENARIO
Este proyecto de investigacin se extiende en el rea del Data Warehouse y Data Mart (almacn de datos) de las bases de datos profesionales de las ciencias de la computacin con campo de aplicacin en la tecnologa del hormign armado de la ingeniera civil; especficamente, en el diseo y construccin del elemento horizontal denominado viga

PROBLEMA IDENTIFICADO
Un problema identificado en el proceso de diseo/construccin de elementos de hormign armado es la carencia de informacin compilada, precisa y de respaldo que permita soportar la toma de decisiones con relacin a dicho proceso. Los elementos de hormign armado como vigas, columnas, losas y otros, muy pocas veces se construyen exactamente conforme el clculo proyectado en los planos; ms bien, las desviaciones durante la construccin, ocurren frecuentemente y se van acumulando en dependencia de la cantidad de elementos que componen una edificacin u otra obra civil. Estas desviaciones en la construccin a la larga ocasionan prdidas econmicas o reflejan una mala administracin de fondos; pero sobre todo podran lograr atentar contra el factor de seguridad funcional que debera ofrecer una obra de servicio. Es importante aclarar que, las desviaciones en la construccin de un elemento se deben muchas veces a un inadecuado manejo y conocimiento de la precisin que ofrecen los medios de construccin o bien se deben a fallas humanas de direccin y/o ejecucin.

ABORDAJE DEL PROBLEMA

Se pretende abordar el problema mediante el diseo e implementacin 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 diseo/construccin; todo esto, para conformar el monitoreo de un conjunto de indicadores de rendimiento clave as como la obtencin de informacin global en funcin de cualquier dimensin 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 PRCTICO 1. INFORMACIN NECESARIA PARA EL APOYO A LA TOMA DE DECISIONES

Indicadores de Rendimiento Claves o KPIs
Porcentaje de vigas construidas con algn desvo o defecto en su construccin. Porcentaje de vigas construidas con desvos o defectos en la resistencia del hormign. Porcentaje de vigas construidas con desvos o defectos en la resistencia del acero

Medidas
Cantidad de vigas construidas. Cantidad de vigas construidas con algn desvo en su construccin. Cantidad de vigas con desvos en su construccin con relacin a la resistencia del hormign. Cantidad de vigas con desvos en su construccin con relacin a la resistencia del acero. Cantidad de vigas con desvos en su construccin con relacin al ancho de la seccin. Cantidad de vigas con desvos en su construccin con relacin al alto de la seccin. Cantidad de vigas con desvos en su construccin con relacin a su largo o vano. Cantidad de vigas con desvos en el rea del acero de refuerzo. Cantidad de vigas con desvos en la resistencia (momento) de diseo. Diferencia de volumen del elemento construido respecto al volumen de diseo. Diferencia de costo del elemento construido respecto al costo de diseo

Dimensiones
Acero de refuerzo: cdigo y dimetro Asignaciones: obra e ingeniero ejecutor Familia: tipo de seccin de la viga y naturaleza de la falla Tiempo: gestin y mes

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

2. INFORMACIN 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 hormign 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 forneas que hacen referencia a las llaves primarias delas dos tablas anteriores.

En la tabla BARRA se almacenan los dimetros de los distintos tamaos de barras de acero usados en la construccin.

En la tabla TIEMPO se almacenan la gestin 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 hormign armado segn el tipo de seccin y segn la naturaleza de la falla (vase ms abajo).

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

En la tabla VIDIS se almacenan las distintas variables involucradas en la etapa de DISEO de una viga de hormign armado COAS Llave fornea; hace referencia a la tabla de asignaciones ingeniero-obra. RESHOR Resistencia del hormign en Kg/cm. RESACER Resistencia del acero en Kg/cm. ANCHO Ancho de la seccin (cm). ALTO Alto de la seccin (cm).LONG Largo del elemento (m). VOL Volumen del elemento (m3).TSECC Tipo de seccin (cuadrada o rectangular).COBA Llave fornea; referencia a la tabla de acero. CANTBA Cantidad de barras de acero. AACER rea del acero de refuerzo (cm). CUANTOK S cuando la cuanta de acero est dentro delos lmites permisibles. FALLA Naturaleza de la falla del elemento RESMOM Resistencia a momento del elemento. COSTO Costo del elemento (Bs.) COTM Llave fornea; a la tabla TIEMPO. COFM Llave fornea; 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 hormign armado. COVI Llave fornea; a la viga en la tabla de diseo. COAS_C Llave fornea; a la tabla asignaciones ingeniero-obra. RESHOR_C Resistencia del hormign armado en Kg/cm. RESACER_C Resistencia del acero en Kg/cm. ANCHO_C Ancho de la seccin (cm).ALTO_C Alto de la seccin (cm). LONG_C Largo del elemento (m). VOL_C Volumen del elemento (m3). TSECC_C Tipo de seccin (cuadrada o rectangular) COBA_C Llave fornea; 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 cuanta de acero est dentro de lmites. FALLA_C Naturaleza de falla del elemento. RESMOM_C Resistencia a momento del elemento COSTO_C Costo del elemento (Bs.) COTM_C Llave fornea; hace referencia a la tabla TIEMPO.COFM_C Llave fornea; hace referencia a la tabla FAMILIA

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Todas estas tablas se relacionan segn la lgica del proceso diseo/construccin de vigas de hormign armado. Como puede apreciarse en el diseo lgico de a continuacin, las tablas principales son las tablas de diseo VIDIS y de construccin VICONS del elemento viga

Diseo lgico del OLTP fuente

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

3. MODELO DE DATOS PARA EL DATAMART

Conforme las exigencias de la empresa con relacin a la informacin 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 dimensin de asignaciones; til para visualizar el anlisis en funcin de la obra o bien en funcin del ingeniero ejecutor del elemento viga.

En la tabla DIMBARRA se almacena la dimensin del acero; til para visualizar el anlisis en funcin de la denominacin o bien del dimetro de la barra del acero de refuerzo. En la tabla DIMFAMILIA se almacena la dimensin dela familia de vigas; til para visualizar el anlisis en funcin del tipo de la seccin o en funcin de la naturaleza de falla del elemento.

En la tabla DIMTIEMPO se almacena la dimensin del tiempo; til para visualizar el anlisis por gestin o bien por mes.

Aunque la herramienta Business Intelligence de Microsoft SQL Server permite poblar la dimensin tiempo de manera automatizada, en el presente trabajo se ha preferido administrarla manualmente para tener un mejor control sobre la dimensin misma; incluso para poder disponer de una correcta ordenacin (cronolgica en vez de alfabtica).

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

RES_HOR_ERR # de vigas con desvos en la resistencia del hormign. RES_ACER_ERR # de vigas con desvos en la resistencia del acero. ANCHO_ERR # de vigas con desvos en el ancho de la seccin. ALTO_ERR # de vigas con desvos en el alto dela seccin. LARGO_ERR # de vigas con desvos 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 desvos en la resistencia a momento. COSTO_DIF ELE_ERR Diferencia en el costo (Bs.) # de vigas con algn desvo en su construccin.

Las medidas y las llaves forneas de las dimensiones se ensamblan en la tabla de hechos VIGAFACT.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

El formulario de expresiones matemticas que permiten el clculo de las diversas medidas de la tabla de hechos, se describe a continuacin. Es importante adelantar que, todas estas frmulas han sido implementadas en una vista diseada sobre el OLTP para efectos de la etapa ETL (EXTRACTIONTRANSFER LOADING), como se ver un poco ms adelante. Medida RES_HOR_ERR RES_ACER_ERRSIGN ANCHO_ERR ALTO_ERR LARGO_ERR VOL_DIF A_ACERO_DIF RES_MOM_ERR SIGN COSTO_DIF ELE_ERR Frmula Matemtica SIGN(ABS(VICONS.RESHOR_CVIDIS.RESHOR)) (ABS(VICONS.RESACER_CVIDIS.RESACER)) SIGN(ABS(VICONS.ANCHO_C-[Link])) SIGN(ABS(VICONS.ALTO_C-[Link])) SIGN(ABS(VICONS.LONG_C-[Link])) (VICONS.VOL_C-[Link]) (VICONS.AACER_C-[Link]) (ABS(VICONS.RESMOM_C-[Link])) (VICONS.COSTO_C-[Link]) 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 [Link], se crean los orgenes 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:

Orgenes de datos para la implementacin 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 pgina

Vista del origen de datos

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

A continuacin se va implementando el cubo. Durante la implementacin del cubo, se deben identificar las tablas de hechos y las tablas de dimensiones conforme se muestra a continuacin

Identificacin de las tablas y de dimensiones

Cuando el diseo fsico del cubo est correctamente realizado, el software hace un reconocimiento automtico de las tablas de hechos y dimensiones segn se puede apreciar en la ilustracin anterior..

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Enseguida, se muestra el DataMart implementado conforme el diseo expuesto con anterioridad. Puede distinguirse rpidamente un esquema tipo estrella. Vase la ilustracin 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 jerarquas o niveles pero a partir de la vista de datos; esto, conforme se muestra a continuacin.

Debe editarse la estructura de cada dimensin del cubo

Antes de continuar con las dems etapas de conformacin del cubo como el diseo de las agregaciones, sedebe poblar el DataMart a partir de las fuentes OLTP mediante la herramienta Integration Services de Business Intelligence disponible tambin en la suite Microsoft SQL Server 2005. Entonces, una vez creado un nuevo proyecto del tipo Integration Services, se disea un paquete de flujo de control para organizar y comandar las diversas tareas de integracin de informacin 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 segn 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 informacin desde las tablas y vistas de la fuente OLTP hacia las tablas de dimensiones del Data Mart. Los orgenes 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 continuacin:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

La segunda tarea de flujo de datos

Es importante sealar que, para poblar la dimensin de asignaciones o DIMASIGN, se ha diseado una vista (consulta) especfica en la fuente OLTP de acuerdo a la siguiente secuencia SQL:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

El mapeo de campos entre los orgenes y destinos de datos prcticamente resulta automtico cuando se disea 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 opcin de direccionamiento en caso de error por las siguientes razones: porque se han diseado vistas especficas libres de error, porque se tiene una fuente previamente limpiada y porque se prefiere una excepcin en caso de error. La ltima tarea del paquete del flujo de control consiste en el poblado de la tabla de hechos del cubo. Adems de usar controles tipo OLE para el origen y destino de datos, se ha incluido un control transformador para efectuar algunos clculos 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 ilustracin anterior ha sido diseada sobre la fuente OLTP exclusivamente para ste proceso ETL y segn la siguiente secuencia SQL:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Importante comentar que, la aplicacin de la funcin matemtica 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 informacin de anlisis. Por otra parte, el control de transformacin CALCULOS (ilustracin 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 hormign ha sufrido algn defecto durante su construccin, y contiene 0 (cero) si ha sido construido estrictamente segn el diseo. Como se vio anteriormente, su frmula es la siguiente:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Y el detalle de su implementacin se aprecia en el cuadro de dilogo de la ilustracin siguiente:

Implementacin del control tipo transformador

Con relacin a las asignaciones para la tabla de hechos, stas resultan casi del todo automticas 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 continuacin

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 ilustracin siguiente:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Ejecucin satisfactoria del paquete de flujo de control

Finalizada la etapa ETL, se vuelve al servicio de anlisis para concluir de implementar el cubo. Se disean las agregaciones para el modelo multidimensional MOLAP de actualizacin manual:

Modo de almacenamiento MOLAP sin cach

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Inmediatamente, se ejecuta el diseo de la agregacin eligiendo el factor almacenamiento estimado:

Diseo de la agregacin
Con el diseo de la agregacin concluido, se procesan dichas agregaciones para las dimensiones del cubo conforme se muestra en la ilustracin 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 ilustracin anterior, el cubo se ve implementado con xito.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Ante de manipular el cubo para efectos prcticos y con el fin de obtener una mejor legibilidad de las dimensiones y medidas del mismo, se procede con el completado de las traducciones segn 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 prctico del cubo como se muestra en la ilustracin siguiente:

Un primer uso real del cubo.

En la anterior ilustracin se puede apreciar que se est consultando la diferencia de costo (construido vs. presupuestado) por obra por gestin por asignacin y filtrado por tipo de seccin de viga. En este caso de estudio de ejemplo puede apreciarse que, en la gestin 2007, la construccin 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 N2: TEMA:

DESARROLLO DE UN DATAMARTS DE INFORMACIN

ACADMICA DE ESTUDIANTES DE LA ESCUELA DE CIENCIAS Y SISTEMAS DE LA FACULTAD DE INGENIERA 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 Ingeniera, de la Universidad de San Carlos de Guatemala, con el fin de disear y desarrollar una herramienta de inteligencia de negocio que permita el anlisis de informacin acadmica, y a la vez apoye en la toma de decisiones a las autoridades de la Escuela.

RESULTADOS:
- La creacin del presente DataMart permitir que las diferentes reas o unidades de la facultad cuenten con informacin acadmica de una forma autnoma, sin que exista la dependencia de centro de clculo, siempre guardando los debidos controles de seguridad y acceso a la informacin. - Contar con una herramienta de inteligencia de negocio en la Escuela de Ciencias y Sistemas, facilitar la informacin que muchas empresas requieren sobre referencias de los estudiantes que solicitan empleos. As tambin, permitir que la asignacin de carga de estudiantes sea mejor distribuida entre los catedrticos, incluso entre otros recursos tales como los salones

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

EJEMPLO N3: TEMA: ANLISIS,

DISEO E IMPLEMENTACIN DE UN

DATAMART PARA EL REA DE SISMOLOGA DEL DEPARTAMENTO DE GEOFSICA DE LA ESCUELA POLITCNICA NACIONAL. - QUITO MARZO 2006

POR: Michael Vizuete y Carlos Yela RESUMEN:

Este trabajo dio un breve recuento del desarrollo de una solucin DataMart, para el departamento de sismologa de la escuela politcnica nacional con el fin de mejorar el manejo de la informacin de dicha rea para prevenir sismos que han producido un gran impacto en muchas comunidades causando grandes perdidas tanto humanas como econmicas.

RESULTADOS.
El horizonte de tiempo de los datos es muy diferente de un ambiente al otro. La informacin en el ambiente operacional es ms reciente con respecto a la del Data mart. Desde la perspectiva de los horizontes de tiempo nicos, hay poca superposicin entre los ambientes operaciones y de DataMart. El DataMart contiene un resumen de la informacin que no se encuentra en el ambiente operacional. Los datos experimentan una transformacin fundamental cuando pasan al DataMart.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

8. CONCLUSIONES Y RECOMENDACIONES
La implementacin de un proceso de inteligencia de negocio en una organizacin, permite que la informacin fluya de una forma natural y controlada desde donde se producen las transacciones del da a da de la organizacin, hasta convertirlas en informacin y conocimiento que permiten a los usuarios finales tomar mejores y efectivas decisiones. El DataMart es especfico para una necesidad de datos seleccionados, enfatizando el fcil acceso a una informacin relevante. La diferencia principal entre los mercados de datos independientes y dependientes es la forma de llenar la despensa de datos, es decir, cmo 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 algn informe complejo, por lo que su utilizacin directa no est recomendada a usuarios finales. Del ejemplo aplicativo [Link] implementacin en SQL Server 2005 de

DataMart tendr grandes beneficios ya que brindara un soporte en la toma de decisiones que se realizar en la consultora y construccin de vigas de hormign armado de la empresa consultora constructora. Del ejemplo aplicativo N2. En la escuela de ciencias y sistemas se obtendrn grandes beneficios al utilizarse el DataMart acadmico, 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 Ingeniera. Todas las empresas que manipulen informacin de mucha importancia debe implementar los Data Mart para poder darle un mejor manejo a toda esa

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

informacin y de esta manera realizar la toma de decisin adecuada dentro de cada rea especfica..

9. BIBLIOGRAFIA
[Link] [Link] ta+Mart%29. [Link] [Link] [Link] [Link] [Link] [Link] [Link] [Link]

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 versin especial de almacn de datos (data warehouse). Son subconjuntos de datos con el propsito de ayudar a que un rea especfica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y propagados de mltiples formas para que diversos grupos de usuarios realicen la explotacin de los mismos de la forma ms conveniente segn sus necesidades. 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 Analtico en Lnea) que ofrecen una visin multidimensional de la informacin. Sobre estas bases de datos se pueden construir EIS (Executive Information Systems, Sistemas de Informacin 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 anlisis de grandes cantidades de datos con el objetivo de extraer informacin til, por ejemplo para realizar clasificaciones o predicciones. En sntesis, se puede decir que los data marts son pequeos data warehouse centrados en un tema o un rea de negocio especfico dentro de una organizacin.

Dependencia de un data mart

Segn la tendencia marcada por Inmon sobre los data warehouse, un data mart dependiente es un subconjunto lgico (vista) o un subconjunto fsico (extracto) de un almacn de datos ms 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 aplicacin en el Data Warehouse principal de la Empresa. Demostracin sobre el terreno: para demostrar la viabilidad y el potencial de una aplicacin antes de migrarla al Data Warehouse de la Empresa. Poltica: Cuando se decide una estrategia para las TI (Tecnologas de la informacin) en situaciones en las que un grupo de usuarios tiene ms influencia, para determinar si se financia dicha estrategia o descubrir si sta no sera buena para el almacn de datos centralizado. Poltica: Estrategia para los consumidores de los datos en situaciones en las que un equipo de almacn de datos no est en condiciones de crear un almacn de datos utilizable.

Segn la escuela Inmon de data warehouse, entre las prdidas inherentes al uso de data marts estn la escalabilidad limitada, la duplicacin de datos, la inconsistencia de los datos con respecto a otros almacenes de informacin y la incapacidad para aprovechar las fuentes de datos de la empresa. As y todo estas herramientas son de gran importancia.

Conceptos errneos de los Data Marts

Al hablar de los data marts, es inevitable la comparacin con los data warehouse y al final se acaba diciendo (o entendiendo) que son como estos, pero en pequeo, y en cierto modo esto es as, pero esta idea suele hacer caer en los siguientes errores sobre la implementacin y funcionamiento de los data marts:

Son ms simples de implementar que un Data Warehouse: FALSO, la implementacin es muy similar, ya que debe proporcionar las mismas funcionalidades. Son pequeos conjuntos de datos y, en consecuencia, tienen menor necesidad de recursos: FALSO, una aplicacin corriendo sobre un data mart necesita los mismos recursos que si corriera sobre un data warehouse. Las consultas son ms rpidas, 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 aade tiempo al proceso de actualizacin: FALSO, actualizar el data mart desde el data warehouse cuesta menos (ya que los formatos de los datos son o suelen ser idnticos) que actualizar el data warehouse desde sus fuentes de datos primarias, donde es necesario realizar operaciones de transformacin (ver ETL).

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Un mercado de datos Conceptos

En este captulo se revisan algunos conceptos bsicos 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 terminologa, no han alcanzado todava un consenso total. Si usted habla con una docena de personas, es probable que or hablar de una media docena de respuestas similares pero ligeramente diferentes, incluso para algo tan bsico como "Qu es un mercado de datos?" En este captulo se da un vistazo rpido a algunas definiciones y explica lo que es un mercado de datos es (y no es).

En este captulo se incluyen los temas siguientes:

Seccin A.1, "Qu es un Data Mart?" Seccin A.2, "Cmo es diferente de un almacn de datos?" Seccin A.3, "Data Marts dependientes e independientes" Seccin A.4, "Cules son los pasos en la implementacin de un Data Mart?"

A.1 Qu es un Data Mart?

Un data mart es una forma simple de un almacn 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 organizacin. Dada su sola materia en el enfoque, mercados de datos por lo general obtener datos de slo unas pocas fuentes. Las fuentes pueden ser los sistemas internos de funcionamiento, un centro de almacenamiento de datos o de datos externos.

A.2 Cmo es diferente de un Data Warehouse?

Un almacn de datos, a diferencia de un mercado de datos, se ocupa de temas mltiples y es tpicamente implementado y controlado por una unidad central de organizacin, tales como

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

la tecnologa de la informacin corporativa (IT) del grupo. Con frecuencia, se llama un depsito central de datos o de la empresa. Por lo general, un almacn de datos rene datos de los sistemas de mltiples fuentes. Nada en estas definiciones bsicas limita el tamao de un mercado de datos o la complejidad de los datos de soporte de decisiones que contiene. Sin embargo, los data marts son tpicamente ms pequeos y menos complejos que los almacenes de datos, por lo que por lo general son ms fciles de construir y mantener. Tabla A-1 se resumen las diferencias bsicas entre un almacn de datos y un data mart. Tabla A-1 Diferencias entre un Data Warehouse y un Data Mart Categora Alcance Sujeto Fuentes de datos Tamao (tpico) Tiempo de Implementacin Data Warehouse Corporativo Mltiple Muchos 100 GB-TB + Meses o aos Data Mart Lnea de negocio (LOB) Sujeto individual Pocos <100 GB Meses

A.3 dependientes e independientes de datos Marts

Hay dos tipos bsicos de data marts: dependientes e independientes. La clasificacin se basa principalmente en el origen de datos que alimenta el mercado de datos. Mercados de datos dependientes extraer datos de un almacn central de datos que ya ha sido creado. Mercados de datos independientes, en contraste, son sistemas independientes construy tomando datos directamente de fuentes operativa o externa de datos, o ambos. La diferencia principal entre los mercados de datos independientes y dependientes es la forma de llenar la despensa de datos, es decir, cmo obtener datos de las fuentes y en la despensa de datos. Esta etapa, denominada de extraccin-transformacin y carga (ETL), consiste en mover datos de sistemas operacionales, filtrado, y cargarlo en la despensa de datos. Con mercados de datos dependientes, este proceso se simplifica, ya que algo formato y resumido (limpia) los datos que ya se ha cargado en el almacn central de datos. El proceso ETL para los data marts dependientes es sobre todo un proceso de identificar el subconjunto correcto de los datos pertinentes al tema data mart elegido y mover una copia de la misma, tal vez en una forma resumida. Con mercados de datos independientes, sin embargo, debe ocuparse de todos los aspectos del proceso de ETL, tanto como lo hace con un almacn de datos central. El nmero de

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

fuentes es probable que sea menos y la cantidad de datos asociados con el mercado de datos es menor que el almacn, dado su enfoque en un solo tema. Las motivaciones detrs de la creacin de estos dos tipos de data marts son tambin tpicamente diferente. Mercados de datos dependientes se construyen generalmente para lograr un mejor rendimiento y disponibilidad, un mejor control y reducir los costes de las telecomunicaciones como consecuencia del acceso local de los datos relacionados con un departamento especfico. La creacin de mercados de datos independientes a menudo es impulsada por la necesidad de disponer de una solucin en un tiempo ms corto.

A.4 Cules son los pasos en la implementacin de un Data Mart?

En pocas palabras, los pasos ms importantes en la implementacin de un data mart son disear el esquema, la construccin del almacenamiento fsico, llenar la despensa de datos con los datos de los sistemas de origen, el acceso a la toma de decisiones informadas, y manejarlo con el tiempo. Esta seccin contiene los siguientes temas:

Seccin A.4.1, "Diseo" Seccin A.4.2, "La construccin" Seccin A.4.3, "Cmo llenar" Seccin A.4.4, "Acceso" Seccin A.4.5, "Gestin"

A.4.1 Diseo
La etapa de diseo es el primero en el proceso de data mart. Esta etapa cubre todas las tareas de iniciar la solicitud de un puesto de datos a travs de la recopilacin de informacin acerca de los requisitos, y el desarrollo del diseo lgico y fsico del data mart. La etapa de diseo comprende las siguientes tareas:

Reunir los requisitos tcnicos y de negocio Identificar las fuentes de datos Seleccionar el subconjunto apropiado de los datos Diseo de la estructura lgica y fsica del data mart

A.4.2 Construccin
Este paso incluye la creacin de la base de datos fsico y las estructuras lgicas asociadas con el mercado de datos para proporcionar acceso rpido y eficiente a los datos. Este paso implica las siguientes tareas:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

La creacin de la base de datos fsico y las estructuras de almacenamiento, tales como espacios de tabla, asociado con el puesto de datos Crear los objetos de esquema, como tablas e ndices definidos en la etapa de diseo Determinar la mejor forma de configurar las tablas y las estructuras de acceso

A.4.3 Poblando
El paso poblar cubre todas las tareas relacionadas con la obtencin de los datos de la fuente, la limpieza para arriba, modificndolo al formato adecuado y el nivel de detalle, y que se incorpore al mercado de datos. Ms formalmente declarado, el paso consiste en rellenar las siguientes tareas:

Cartografa de las fuentes de datos para orientar las estructuras de datos Extraccin de los datos La limpieza y la transformacin de los datos Cargando datos en el data mart Creacin y almacenamiento de los metadatos

A.4.4 Acceso
El paso de acceso consiste en colocar los datos a utilizar: la consulta de los datos, su anlisis, la creacin de informes, tablas y grficos, y la publicacin de los mismos. Tpicamente, el usuario final utiliza una interfaz grfica herramienta para enviar consultas a la base de datos y visualizar los resultados de las consultas. El paso de acceder requiere que realice las siguientes tareas:

Crear una capa intermedia para la herramienta de front-end para su uso. Esta capa, la metalayer, traduce las estructuras de bases de datos y nombres de objeto en trminos de negocio, por lo que el usuario final puede interactuar con el mercado de datos utilizando trminos que se relacionan con la funcin empresarial. Mantener y gestionar estas interfaces de negocio. Configurar y administrar estructuras de bases de datos, como tablas resumen, que las consultas de ayuda presentadas a travs de la herramienta de front-end ejecutar de forma rpida y eficiente.

A.4.5 Gestin
Este paso implica la gestin del mercado de datos sobre su vida. En este paso, va a realizar las tareas de gestin, tales como los siguientes:

Proporcionar acceso seguro a los datos Gestionar el crecimiento de los datos La optimizacin del sistema para un mejor rendimiento Asegurar la disponibilidad de los datos incluso con fallos del sistema

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

B Disear el Data Mart

Este captulo se centra en las cuestiones relacionadas con el diseo de un data mart. Piense en este captulo como una coleccin de consejos sobre cmo organizar su data mart ejecucin del proyecto. Tan importante como aprender lo que debe hacer es aprender lo que debe tener en cuenta: las cosas que pueden tropezar en un proyecto como este (y stos no siempre pueden surgir problemas tcnicos). El factor empresarial motriz para la despensa de datos es la la necesidad de informacin, y la mejor manera de empezar el proceso de diseo es mediante la identificacin de las necesidades del negocio. Usted debe incluir a aquellos que tienen una inversin en el mercado de datos, tales como el promotor de negocios y el usuario final, lo ms temprano posible en el proceso de diseo. Juntos, ustedes deberan ponerse de acuerdo sobre los requisitos de informacin que el mercado de datos deben cumplir, las fuentes de datos, los requisitos tcnicos (como la frecuencia con la que los datos se debe actualizar desde la fuente), y los criterios de xito del proyecto. Los pasos en el diseo de un mercado de datos son los siguientes: 1. Realizacin de un estudio para definir el alcance del proyecto 2. Definicin de los requerimientos de negocio y tcnicos para el mercado de datos 3. Desarrollo del diseo lgico y fsico del data mart En este captulo se incluyen los temas siguientes:

Seccin B.1, "Definicin del Alcance del Proyecto Data Mart" Seccin B.2, "Definicin de los requisitos para el Data Mart" Seccin B.3, "Data Mart Diseo"

B.1 Definicin del Alcance del Proyecto Data Mart

Antes de empezar a poner en prctica el mercado de datos, es necesario desarrollar un plan para su entrega. Insumos crticos a este plan son las necesidades de informacin y prioridades de los usuarios. Despus de esta informacin se ha definido y aprobado por el patrocinador de su negocio, usted puede desarrollar su lista de productos clave y asignar responsabilidades a su equipo. Su primera tarea es definir el alcance del proyecto. El alcance del mercado de datos define los lmites del proyecto y se expresa tpicamente en una combinacin de las funciones de la geografa, la organizacin y la aplicacin, o de negocios. Definicin de alcance general requiere hacer compromisos a medida que tratan de equilibrar los recursos (como las personas, los sistemas y del presupuesto) con la fecha de finalizacin prevista y las capacidades que se comprometi a entregar. Definir el alcance y dejando claro a todos los involucrados es importante porque:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Establece las expectativas correctas Prioriza el desarrollo incremental Riesgos y problemas destacados Le permite calcular los costos

B.2 Definicin de los requisitos para el Data Mart

Para iniciar la aplicacin de la despensa de datos, es necesario definir los requisitos empresariales y tcnicos. Sin embargo, usted debe esperar que los requisitos para cambiar a medida que los usuarios utilizan la aplicacin inicial y son ms capaces de comunicar sus necesidades. El desarrollo del mercado de datos es un proceso iterativo, ya que el mercado de datos evoluciona en respuesta a la retroalimentacin de los usuarios. Esta seccin contiene los siguientes temas:

Seccin B.2.1, "Definicin de Requerimientos del Negocio" Seccin B.2.2, "Identificacin de los requisitos tcnicos" Seccin B.2.3, "Cmo saber si lo ha hecho bien?"

B.2.1 Definicin de Requerimientos del Negocio

El propsito de la despensa de datos es proporcionar acceso a los datos que sea especfico de un departamento o rea funcional. Los datos deben ser de un nivel apropiado de detalle para el tipo de anlisis que los usuarios finales desean realizar, y debe ser presentada en los trminos del negocio que ellos entienden. La expectativa es que el anlisis de los datos en un data mart llevar a tomar decisiones de negocio ms informadas. Por lo tanto, es necesario comprender cmo el empresario toma decisiones-lo que cuestiona los usuarios piden en el proceso de toma de decisiones, y qu datos son necesarios para responder a estas preguntas. La mejor manera de entender los procesos de negocio es a travs de entrevistas con los hombres de negocios. Los requisitos identificados como resultado de estas entrevistas comprenden los requisitos de negocio para su despensa de datos. A medida que se renen los requisitos para el puesto de datos, debe centrar sus esfuerzos en las necesidades de informacin de un tema nico. Recuerde que ningn documento de requisitos ser lo suficientemente completa como para obtener toda la informacin desde el principio, y lo que necesita para disear el data mart para adaptarse a las necesidades cambiantes. Sin embargo, si usted introducir nuevos temas o se desve de su tema principal, perder su foco y horario. A pesar de que el mercado de datos aborda un rea temtica, por lo general tiene muchos usuarios de negocios, cada una con diferentes necesidades y expectativas. Trate de identificar al menos un representante de cada rea de la empresa para sus entrevistas. Por ejemplo, si usted est construyendo un data mart comercializacin, entrevista a varias personas involucradas en diversos aspectos de la funcin de marketing (por ejemplo, un

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

analista de marketing, especialista en canal, gerente de marketing directo, y el gerente de promocin). Utilice un conjunto coherente de preguntas o una plantilla de entrevista para cada entrevista. Las preguntas deben centrarse en las necesidades de informacin de los usuarios, como el contenido, la frecuencia de actualizacin, las prioridades y el nivel de detalle. Por ltimo, establecer un lmite de tiempo definido en la entrevista y los requisitos de recopilacin de fase, de lo contrario, podra continuar indefinidamente mientras trata de perfeccionar cada requisito. Usted no puede obtener todos los requisitos de este marco de tiempo, pero conseguirs lo suficiente para crear una hoja de ruta. Las necesidades cambian durante el perodo de ejecucin, y se necesita una manera de evaluar y atender las solicitudes de cambios o de rechazar y considerarlos para una etapa futura.

B.2.2 Identificacin de los requisitos tcnicos

Usted debe identificar los requisitos tcnicos. En ellos se especifican en el que obtener los datos que alimentan el mercado de datos. Las principales fuentes de datos para data marts son los sistemas operativos que se encargan de las actividades transaccionales del da a da. Por lo general, estos sistemas operativos son de procesamiento de transacciones en lnea (OLTP). Su mercado de datos puede ser alimentado desde ms de una fuente operativa tal. Sin embargo, normalmente no puede transferir los datos desde el sistema operativo en el mercado de datos sin tratamiento intermedio. Es necesario comprender cmo limpiar los datos operativos y la cantidad de formateo o la traduccin es necesaria para integrarla con otras fuentes. Adems, es necesario determinar con qu frecuencia debe actualizar o actualizar los datos. Por ejemplo, si utiliza los datos para relativamente planificacin a largo plazo y horizontes de anlisis, es posible que necesite una alimentacin semanal o mensual en lugar de una alimentacin diaria. Tenga en cuenta que la frecuencia de actualizacin no necesariamente determinar el nivel de detalle en el mercado de datos. Usted puede tener una alimentacin mensual de los datos resumidos por semana. En esta fase inicial de los datos de diseo mart, es necesario identificar las fuentes de datos, el tipo de limpieza de datos necesarios, y la frecuencia con la que los datos se deben actualizar.

B.2.3 Cmo saber si lo ha hecho bien?

Cuando termine de hacer las entrevistas, se tiene un conjunto de requisitos de informacin y rendimiento que su solicitud mercado de datos deben cumplir. Usted debe ser realista y dar prioridad a las necesidades y elaborar una lista de criterios de xito. Para dar prioridad a su lista, hgase las siguientes preguntas:

El desempeo de la principal preocupacin? Est limitada por la configuracin de los sistemas? Con qu frecuencia desea actualizar o aadir a los datos? Los usuarios esperan que el mercado de datos a ser una fuente completa de datos departamentales, o es el mercado de datos de alcance limitado a un tema en particular dentro de ese departamento?

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Es su alcance consistente con la arquitectura de TI, o se puede desarrollar de manera autnoma?

Tenga en cuenta las respuestas a estas preguntas a medida que desarrollan sus prioridades y factores crticos de xito. En resumen, aqu estn algunas pautas para facilitar el proceso de definicin de requisitos:

Implicar a los usuarios finales de todo el proceso. Clasificar el marco de anlisis de requisitos: definir los requisitos para el patrocinador del negocio, el arquitecto de TI, el desarrollador mercado de datos, y los usuarios finales. Gestionar las expectativas de los usuarios finales.

B.3 Data Mart Diseo

Al principio de la fase de diseo, los requisitos comerciales ya estn definidos, el alcance de su aplicacin data mart se ha acordado, y tiene un diseo conceptual. Ahora, es necesario traducir sus necesidades en un sistema de entrega. En este paso, crear el diseo lgico y fsico para el mercado de datos y, en el proceso, definir el contenido especfico de datos, las relaciones dentro y entre grupos de datos, el entorno del sistema de apoyo a su puesto de datos, las transformaciones de los datos necesarios, y el frecuencia con la que los datos se [Link] diseo lgico es ms conceptual y abstracto que el diseo fsico. En el diseo lgico, nos fijamos en las relaciones lgicas entre los objetos. En el diseo fsico, nos fijamos en la forma ms eficaz de almacenar y recuperar los objetos. El diseo de su puesto de datos debe orientarse hacia las necesidades de sus usuarios finales. Los usuarios finales normalmente se desea llevar a cabo el anlisis y examinar los datos agregados, y no en transacciones individuales. Su diseo est impulsado principalmente por la utilidad del usuario final, pero los usuarios finales no saben lo que tienen hasta que lo ven. Un diseo bien planificado permite el crecimiento y cambia a medida que las necesidades de los usuarios cambian y evolucionan. La calidad de su diseo determina su xito en el cumplimiento de los requisitos iniciales. Debido a que no pueden darse el lujo de sistema ilimitado y recursos de la red, la utilizacin ptima de los recursos est determinada principalmente por su diseo. Al comenzar con el diseo lgico, que se centran en las necesidades de informacin sin enredarse inmediatamente con detalle de implementacin. Tenga en cuenta que no se ven obligados a trabajar de una manera de arriba hacia abajo. Usted puede realizar ingeniera inversa de un esquema de datos existente y utilizar esto como punto de partida para su diseo. Si sus necesidades de datos son muy claros y que est familiarizado con los datos de origen, es posible que pueda comenzar en el nivel de diseo fsico y luego pasar directamente a la implementacin fsica. En la prctica, se necesitan varias iteraciones antes de lograr el diseo adecuado.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Esta seccin contiene los siguientes temas:

Seccin B.3.1, "Creacin de un diseo lgico" Seccin B.3.2, "Creacin de una lista de deseos de los datos" Seccin B.3.3, "Fuentes" Identificacin de Seccin B.3.4, "Clasificacin de datos para el esquema Data Mart" Seccin B.3.5, "Diseo del esquema de las Galaxias" Seccin B.3.6, "Pasar de la lgica de diseo fsico"

B.3.1 Creacin de un diseo lgico

Un diseo lgico es un diseo conceptual, abstracto. Usted no se ocupan de los detalles de implementacin fsica todava, tiene que tratar slo con la definicin de los tipos de informacin que usted necesita. El proceso de diseo lgico consiste en organizar los datos en una serie de relaciones lgicas llamadas entidades y atributos. Una entidad representa un pedazo de informacin. En bases de datos relacionales, las entidades a menudo se asigna a una tabla. Un atributo es un componente de una entidad y ayuda a definir el carcter nico de la entidad. En bases de datos relacionales, un atributo se asigna a una columna. Mientras diagramas de entidad-relacin se ha asociado tradicionalmente con modelos altamente normalizados, como las aplicaciones OLTP, la tcnica sigue siendo til en el modelado dimensional. Usted acaba de abordarlo de forma diferente. En el modelado dimensional, en lugar de tratar de descubrir unidades atmicas de la informacin y todas las relaciones entre ellos, se intenta identificar qu informacin le pertenece a una tabla de hechos central y que la informacin pertenece a sus tablas de dimensiones asociadas. Atencin al diseo es crtico. Mantenga sus requerimientos de negocio en la mano durante todo el proceso de diseo. Nada es ms importante! Como parte del proceso de diseo, se asignan los datos operacionales desde su origen en asignaturas y tiene informacin en su esquema de destino data mart. Usted identifica temas de negocios o campos de datos, definir las relaciones entre los sujetos de negocio, y el nombre de los atributos de cada tema. Los elementos que ayudan a determinar el esquema de data mart son el modelo de datos de origen y los requisitos de los usuarios. A veces, se puede obtener el modelo de cdigo de modelo empresarial de su empresa y los datos de ingeniera inversa del modelo de datos lgico para el data mart de esto. La implementacin fsica del modelo de datos lgicos mart puede requerir algunos cambios debido a su sistema de parmetros de tamao de ordenador, nmero de usuarios, capacidad de almacenamiento, tipo de red y software. Usted tendr que tomar decisiones a medida que desarrolle el diseo lgico:

Hechos y dimensiones Granularidad de los hechos Relacin entre las entidades

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Duracin histrica de los datos

B.3.2 Creacin de una lista de deseos de los Datos

Usted genera la lista de deseos de los elementos de datos de los requerimientos de negocio de los usuarios. Se asume que el alcance de la despensa de datos est completamente especificado por los usuarios. A menudo, usted debe mirar ms all de los requerimientos especficos de los usuarios y anticiparse a las necesidades futuras. Comience con los parmetros de negocio que son importantes para su rea temtica. Durante Ventas y Mercadeo mart datos, los parmetros pueden ser clientes, Geografa, Producto, Ventas y Promociones. Recuerde Time-quieres ver las cifras mensuales, diarias o semanales? A continuacin, cree una lista de elementos de datos que desee, ya sea de los requisitos exigidos por los usuarios, o por una lluvia de ideas con ellos. Al final de este ejercicio, usted debe tener lo siguiente:

Una lista de elementos de datos, tanto en crudo y se calcula Los atributos de los datos, tales como caracteres o tipos de datos numricos Agrupaciones razonable de los datos, como las regiones geogrficas de los elementos del pas, condado, ciudad Una idea de la relacin entre los datos, como "una ciudad dentro de un condado"

Campos de datos tpicos de inters en las Ventas y Marketing de ejemplo podran ser las ventas en dlares, las ventas de unidades, nombres de productos, paquetes, las caractersticas de la promocin, regiones y pases. Identificar el crtico campos: los que llev a la creacin del mercado de datos. Los datos tales como las ventas en dlares o ventas unitarias son crticos para un mercado de datos de ventas. Los usuarios pueden proporcionarle informes para darle una idea de sus necesidades de datos. Estos informes pueden ser informes existentes, o el tipo de informes que les gustara ver. Los informes son un buen vehculo para llegar a los usuarios a expresar sus necesidades. En este punto, puede separar los datos en datos numricos (los hechos) y los datos textuales o descriptivos (las dimensiones). Durante el proceso iterativo de interaccin con el usuario final, pregunte por qu ciertos datos es importante, qu decisiones estn impulsadas por estos datos? Una idea de los procesos de negocio le ayudar a anticiparse a las necesidades futuras de datos.

B.3.3 Identificacin de Fuentes

Ahora, usted tiene una lista de dimensiones y hechos que usted desea para su despensa de datos. La pregunta es, puede obtener los datos? Y si es as, a qu precio? Las fuentes de

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

datos pueden variar desde sistemas operativos, tales como sistemas de procesamiento de pedidos, hasta hojas de clculo. Es necesario asignar los elementos individuales de su lista de deseos a las fuentes. Usted debe comenzar con el ms grande, ms completa fuente y buscar otras fuentes cuando sea necesario. Tpicamente, un gran porcentaje de los datos provienen de una o dos fuentes. Las dimensiones por lo general se pueden asignar a tablas de bsqueda en su sistema operativo. En su forma pura, los hechos que se pueden asignar a las tablas de transaccin. Para el uso en el mercado de datos, los datos de transaccin generalmente necesita ser agregados, basado en el nivel de granularidad especificada. Granularidad es el ms bajo nivel de informacin que el usuario desee. Es posible que algunos de los datos solicitados no se puede asignar. Esto suele suceder cuando las agrupaciones en el sistema de origen no son consistentes con los grupos deseados dentro del mercado de datos. Por ejemplo, en una empresa de telecomunicaciones, las llamadas pueden ser agregados fcilmente por el cdigo de rea. Sin embargo, el mercado de datos necesita datos por cdigo postal. Debido a que un cdigo de rea contiene varios cdigos postales y un cdigo postal puede abarcar mltiples cdigos de rea, es difcil para mapear estas dimensiones. Es posible que algunos datos son muy costosos de adquirir. Por ejemplo, los datos de promocin que los usuarios solicitados no se pueden obtener fcilmente debido a que la informacin no es coherente a travs del tiempo o la promocin. Para traducir a un formato de sistema comn sera muy costoso.

B.3.4 Clasificacin de datos para el esquema de Data Mart

En este punto, se ha empezado a pensar en la clasificacin de los datos como hechos y dimensiones. Una representacin comn de los hechos, las dimensiones y las relaciones entre ellos en aplicaciones de datos Mart es el esquema en estrella. Tpicamente, contiene una dimensin de tiempo y est optimizado para el acceso y el anlisis. Se llama un esquema en estrella porque la representacin grfica se ve como una estrella con una tabla de hechos grande en el centro y las tablas de dimensiones ms pequeas dispuestas alrededor de ella. Diseo avanzado de modelado puede incluir esquemas, llamados esquemas de copo de nieve o constelacin, que son ms complejas que las simples mostrados esquema en estrella. En las secciones siguientes se proporciona ms informacin sobre las dimensiones, los hechos, y el nivel de granularidad. Esta seccin contiene los siguientes temas:

La seccin B.3.4.1, "Dimensiones" La seccin B.3.4.2, "Hechos" La seccin B.3.4.3, "granularidad"

B.3.4.1 Dimensiones

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

En el ejercicio de clasificacin, muchos de los campos del origen de OLTP va a terminar como dimensiones. El problema de diseo importante es decidir si un campo es ms que otro elemento de una dimensin existente, o cuando debe tener su propia dimensin. La dimensin del tiempo se genera de forma independiente usando las fechas discretas en la fuente OLTP. Esto ofrece flexibilidad para realizar cualquier anlisis de series de tiempo. Para un esquema en estrella verdadera, el orden de creacin de las tablas de dimensiones no importa el tiempo que se crean antes de la tabla de hechos. Por lo general, una tabla debe ser creado antes de otras tablas puede hacer referencia a ella. Por lo tanto, asegrese de crear todas las tablas de dimensiones en primer lugar. B.3.4.2 Datos Los hechos son los indicadores numricos de la empresa. Apoyan clculos matemticos utilizados para informar y analizar el negocio. Algunos datos numricos son dimensiones disfrazados, incluso si parecen ser hechos. Si usted no est interesado en un resumen de un artculo en particular, el artculo puede ser en realidad una dimensin. Tamao de base de datos y el rendimiento general mejorar si se realiza una clasificacin campos limtrofes como dimensiones. Por ejemplo, suponga que tiene una base de datos de membresa para un club de salud y quiere saber qu parte de las vitaminas del club de marca a los miembros comprar. En su lista de deseos, tienes varias preguntas como: "Dame el uso por edad ..." y "Dame la edad promedio de los miembros de ..." La edad es un hecho o una dimensin? Que sea una dimensin. B.3.4.3 Granularidad Despus de definir los hechos y dimensiones, a determinar el nivel de detalle apropiado para los datos en el data mart. En este punto, usted sabe por qu los usuarios han solicitado un determinado nivel de informacin dentro de una dimensin. Es necesario estimar los recursos necesarios para proporcionar el nivel requerido de granularidad y, con base en los costos, si es o no puede soportar este nivel de granularidad.

B.3.5 Disear el esquema de estrella

Una vez que tenga una lista de todos los hechos, dimensiones, y el nivel de granularidad deseada, estar listo para crear el esquema en estrella. El paso siguiente es definir las relaciones entre los hechos y las tablas de dimensiones utilizando las teclas. Una clave principal es una o ms columnas que forman la fila dentro de una tabla nica. La clave principal de la tabla de hechos puede constar de varias columnas. Esta clave se denomina clave compuesta o concatenada. Es una buena idea usar generados por el sistema (teclas sintticas), en lugar de teclas naturales, para vincular los hechos y las dimensiones. Esto proporciona el administrador del

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

mercado de datos con el control de las teclas en el entorno de mercado de datos, incluso si el cambio de claves en el sistema operativo. Una clave es una secuencia sinttica generada de nmeros enteros. Se incluyen las teclas sintticos en la tabla de dimensiones, adems de la clave natural. A continuacin, utiliza la clave sinttica en la tabla de hechos como la columna que se une a la tabla de hechos a la tabla de dimensiones. Aunque la creacin de claves sintticas requiere una planificacin adicional y trabajo, las claves pueden proporcionar beneficios de llaves naturales:

Teclas naturales a menudo son largas cadenas de caracteres, como en un cdigo de producto. Dado que las claves sintticas son enteros, el tiempo de respuesta a las consultas se mejora. El administrador del mercado de datos tiene el control sobre la clave sinttica. Si un grupo de fabricacin cambia el cdigo del producto de las convenciones de nomenclatura, los cambios no afectan a la estructura del mercado de datos. Considere el uso de claves sintticas para la mayora de las tablas de dimensiones. (En el resto de este tutorial, nos referimos a las claves sintticas como claves del almacn.)

El proceso de traducir los datos de la base de datos OLTP y cargar el esquema en estrella de destino requiere mapeo entre los esquemas. El mapeo puede requerir agregaciones u otras transformadas.

B.3.6 Pasar de la lgica de diseo fsico

Durante el proceso de diseo fsico, convertir los datos recogidos durante la fase de diseo lgico en una descripcin de la base de datos fsica, incluyendo tablas y restricciones. Esta descripcin optimiza la colocacin de las estructuras de base de datos fsicos para lograr el mejor rendimiento. Debido a que los usuarios de datos mart ejecutar ciertos tipos de consultas, desea optimizar la base de datos data mart para un buen desempeo para ese tipo de consultas. Decisiones de diseo fsico, tales como el tipo de ndice o particin, tendr un gran impacto en el rendimiento de la consulta. A medida que el mercado de datos se convierte en xito y se utiliza ms ampliamente, ms y ms usuarios tengan acceso a ella. Con el tiempo, el volumen de datos tambin crecer. Escalabilidad, la capacidad de aumentar el volumen de los datos y el nmero de usuarios, es una consideracin importante cuando se mueve de su diseo lgico para una representacin fsica. Para adaptarse a la necesidad de escalabilidad, se debe minimizar las limitaciones de factores tales como la capacidad de hardware, software, y anchos de banda de red. Esta seccin contiene los siguientes temas:

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

La seccin B.3.6.1, "Estimar el tamao del Data Mart" La seccin B.3.6.2, "Qu son los metadatos?"

B.3.6.1 Estimar el tamao del Data Mart Al estimar el tamao de su mercado de datos, es necesario desarrollar un mtodo que se acomoda a su crecimiento futuro. Hay varios mtodos para estimar el tamao de la base de datos. He aqu una aproximacin: 1. Utilice una muestra representativa de los datos de origen para determinar el nmero de filas de la tabla de hechos. 2. Estimar el tamao de una fila en la tabla de hechos. 3. Estimar el tamao de la tabla de hechos multiplicando el nmero de filas por el tamao de una fila. 4. Estimar el tamao del mercado de datos. En general, el tamao total del mercado de datos es de tres a cinco veces el tamao de la tabla de hechos. Este proceso es generalmente iterativo. Cada vez que los cambios de diseo, se debe estimar el tamao nuevo. Incluso si usted piensa que el esquema en estrella es pequea, usted debe hacer este clculo una vez. Despus de calcular el tamao, puede validar su hiptesis de la siguiente manera: 1. 2. 3. 4. Extraer archivos de ejemplo. Carga los datos en la base de datos. Calcular exacto esperado longitudes de fila. Aadir sobrecarga de indexacin, rollback, y los espacios de tablas temporales, y un sistema de archivos de rea de almacenamiento para los archivos planos.

Para planificar el crecimiento futuro, puede utilizar la relacin entre el tamao estimado del mayor tamao posible de la tabla de hechos para calcular el tamao futuro del mercado de datos: 1. Para cada dimensin, comprobar el nivel de detalle que desea y estimar el nmero de entradas en el mejor nivel. 2. Multiplique el nmero de entradas de todas las dimensiones para obtener las filas mximos posibles. 3. Calcular la relacin entre las filas reales de datos representativos a filas posibles. 4. Estimar el crecimiento de cada tabla de dimensiones durante un periodo de tiempo. 5. Multiplique el nmero de filas de todas las tablas de dimensiones. 6. Ajuste el nmero, usando la escala calculada en el paso 3. 7. Multiplique el resultado por el hecho de tamao de fila de tabla. Es posible que deba programar un trabajo de proceso por lotes regulares para refrescar la despensa de datos de sus fuentes. En funcin de los volmenes de datos y la carga del

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

sistema, este trabajo puede durar varias horas. Planifique su mercado de datos de actualizacin a fin de que, en circunstancias normales, puede realizarse dentro del tiempo permitido para el procesamiento por lotes, por lo general en la noche. En su proceso de planificacin, tambin se debe estimar el volumen de datos que se actualiza. Desarrollar una estrategia para purgar los datos ms all del perodo de retencin especificado. B.3.6.2 Qu son los metadatos? Los metadatos son informacin sobre los datos. Para un mercado de datos, metadatos incluyen:

Una descripcin de los datos en trminos de negocio Formato y definicin de los datos en trminos del sistema Fuentes de datos y actualizar los datos de frecuencia de

El objetivo principal para el proceso de gestin de metadatos es proporcionar un directorio de puntos de vista tcnico y comercial de los metadatos data mart. Los metadatos pueden ser categorizados como metadatos tcnicos y los metadatos de negocio. Los metadatos tcnicos se compone de metadatos creados durante la creacin del mercado de datos, as como metadatos para apoyar la gestin de la despensa de datos. Esto incluye las normas de adquisicin de datos, la transformacin de los datos fuente en el formato requerido por la meta data mart y horarios para realizar copias de seguridad y restauracin de datos. Metadatos de negocios permite a los usuarios finales para comprender qu tipo de informacin est disponible en el mercado de datos y la forma en que se puede acceder. Usted utiliza los metadatos tcnicos para determinar las reglas de extraccin de datos y programas de actualizacin para el componente de Oracle Warehouse Builder. Del mismo modo, se utilizan los metadatos de negocio para definir la capa de negocio utilizado por la herramienta Oracle BI Answers.

Data Mart
DATA MART Un Data Mart es una version especial almacn de datos (data warehouse). Como los almacenes de datos, los data marts contienen una visin de datos operacionales que ayudan a decidir sobre estrategias de negocio basadas en el anlisis de tendencias y experiencias pasadas. La diferencia principal es que la creacin de un data mart es especifica para una necesidad de datos seleccionados, enfatizando el fcil acceso a una informacin relevante.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Introduccion de data Mart Los productos Data Warehouse han nacido para resolver problemas de anlisis de grandes masas de informacin, en empresas donde una pequea diferencia en el valor de una variable, puede afectar la cuenta de resultado con unas diferencias de millones de dlares. Data Mart se destaca por una definicin de requerimientos ms fcil y rpida. Tambin se simplifica el desarrollo de todo el mecanismo de su base de datos y con ello baja substancialmente todo el coste del proyecto, as como su duracin. Normalmente, Data Mart resuelve aplicaciones a nivel departamental, aunque en ocasiones se desarrolla una aplicacin que integre todas ellas y proporciona las funciones de un EIS (Executive Information System) El conocimiento de los meta datos es tan esencial como el conocimiento de los datos del Data Warehouse. Deben incluir dominio, reglas de validacin, derivacin y transformacin de los datos extrados. Tambin describen las bases de datos del Warehouse, incluyendo reglas de distribucin y control de la migracin hacia los Data Marts. Los procesos que monitorean los procesos del Warehouse (como extraccin, carga, y uso) crean meta datos que son usados para determinar que tan bien se comporta el sistema. Los meta datos, deberan estar disponibles para los usuarios, para ser usados en sus anlisis. Los administradores pueden manejar y proveer el acceso a travs de los servicios del repositorio. El uso efectivo de los Data Marts en un ambiente de Data Warehousing, es un factor importante para la efectividad del Warehouse. Los Data Marts son diseados para satisfacer las necesidades especficas de grupos comunes de usuarios (divisiones geogrficas, divisiones organizacionales, etc.). Los Data Marts son generalmente, subconjuntos del Data Warehouse, pero pueden tambin integrar un nmero de fuentes heterogneas, e inclusive ser ms grandes, en volumen de datos, que el propio Warehouse central. El concepto DataMart es una extensin natural del Data Warehouse, y est enfocado a un departamento o rea especifica, como por ejemplo los departamentos de Finanzas o Marketing. Permitiendo as un mejor control de la informacin que se est abarcando. QU ES DATA MART? Es un pequeos Data Warehouse, para un determinado numero de usuarios, para un area funcional, especifica de la compaa. Tambin podemos definir que un Data Marts es un subconjunto de una bodega de datos para un propsito especifico. Su funcin es apoyar a otros sistemas para la toma de decisiones. Los procesos que conforma el datawarehouse son: 1-Extraccin. 2- Elaboracin. 3-Carga. 4-Explotacin.

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Datamart
es un subconjunto de una bodega de datos para unpropsito especfico (e.g., un datamart financiero, uno de marketing,etc.).Se puede ver como una vista de la bodega de datos orientada a un aspecto de un negocio, con un tiempo de vida reducido (e.g., 3aos).Su funcin es apoyar a otros sistemas para la toma de decisiones. Un datamart debe de permitir queries de muchas formas usando herramientas OLAP. Para el proceso de construccin de bodegas de datos existen dosenfoques: Construir primero un ncleo de la bodega de datos y luego hacer varios datamarts Construir primero un datamart e ir expandiendo poco a poco labodega de datos y aadiendo nuevos datamarts

Esta herramienta esta dividida en 2 tipo fundamentalmente: Datamart OLAP Basados en lo populares cubos OLAP, que se construyen agregando las dimensiones que sean necesarias para el medio donde se implante la solucin y los indicadores necesarios de cada cubo relacional. El modo de creacin, explotacin y mantenimiento de los cubos OLAP es similar, sin importar la herramienta final que se utilice. Datamart OLTP

UNIVERSIDAD SAN PEDRO

ESCUELA DE INGENIERIA CIVIL

Estas son un simple extracto del datawarehouse, no obstante, lo comn es que sean agregadas mejoras en su rendimiento, aprovechando las caractersticas particulares de cada rea de la empresa. Caracteristicas de los datamarts:

Poco volumen de datos Mayor rapidez de consulta Consultas SQL y/o MDX sencillas Validacin directa de la informacin Facilidad para la historizacin de los datos