Data-mart 1

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 REPRESENTACIONES GRAFICAS 7. EJEMPLOS DE APLICACIÓN 8. CONCLUSIONES Y RECOMENDACIONES RECOMENDACIONES 9. BIBLIOGRAFIA


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

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


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

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


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

4. OBJETIVOS ESPECIFICOS 

Brindar las definiciones y conceptos básicos sobre Data Mart. Ma rt.



Mencionar las características importantes del Data Mart.



Dar a conocer las ventajas y desventajas del Data Mart.



Indicar y describir las fases de construcción de un Data Mart.

5. DESARROLLO DEL TEMA DE INVESTIGACION MARCO TEORICO:

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


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

LÍNEA DE TIEMPO DEL BI -

En 1969: Se Crea el concepto de base de datos (Codd).- En 1970: Se Desarrolla las primeras bases de datos y las primeras aplicaciones empresariales (SAP, JDEdwards, Siebel, Peoplesoft). Estas aplicaciones permitieron realizar “Data Entry” en los sistemas,

aumentando la información disponible, pero no fueron

capaces de ofrecer un acceso rápido y fácil a dicha información, aparece los dispositivos de acceso directo(Dasd). -

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

-

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

-

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


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

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

El componente de inteligencia de negocios que ayuda a resolver los problemas actuales de las empresas son los DataWarehouse así como la construcción de los Data Marts. Con la ausencia de BI, existe de hecho un hueco: Cuando los usuarios toman decisiones y analizan riesgos y oportunidades basados en información anecdótica, incompleta o desactualizada, lo cual no es mejor que adivinar. No solo advierte de los problemas, sino también de las oportunidades. Inteligencia de Negocios es el conjunto de estrategias y herramientas enfocadas a la administración y creación de conocimiento mediante el análisis de datos existentes en una organización o empresa Según Peña (2006), el término Inteligencia de Negocios procura

caracterizar una

amplia variedad de tecnologías, plataformas de software, especificaciones de aplicaciones y procesos.

El objetivo primario de la a Inteligencia de Negocios es contribuir a tomar decisiones que mejoren el desempeño de la empresa y promover su ventaja competitiva en el mercado. En resumen, la Inteligencia de Negocios faculta a la organización a tomar mejores decisiones más rápidas. Este concepto se requiere analizar desde tres perspectivas: Hacer mejores decisiones más rápido, convertir datos en información, y usar una aplicación relacional para la administración.


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

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

-

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

-

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

LIDERES Y GURÚS DEL BI-DATAWAREHOUSE-DATAMARTS Son aquellas personas que han hecho historia en el campode BI ya que han aportado gran cantidad de ideas para luegoaplicarlo a las empresas. Por lo que vamos a mencionar aalgunos de ellos:

Ralph Kimball: Dimensional Data Warehouse Guru.Ralph Kimball Associat es autor de "The Data WarehouseToolkit". Mejora su libro y define múltiples bases de datos llamados DataMarts que son organizados por procesos de negocio, pero usan medios de datos estandarizados para la empresa.



Bill Inmon: Es reconocido por muchos como el “Padre del DataWarehouse”. Se trata definitivamente de un influyente hombre en el mundo de la informática, a lo largo de la historia.



Nigel Pendse: Lead author the OLAP report. Experto en OLAP. Es el principal analista de OLAP Survey Report, que proporcionan información en el mundo de BI, especialmente si se selecciona una herramienta en laque se basa un sistema de BI y para obtener un análisis profesional e independiente de los mejores productos disponibles en el mercado.



Douglas Hackney: Presidente de Enterprise Group Itd. Experto en data marts


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

III. 

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



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


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

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

V. VENTAJAS Y DESVENTAJAS BENEFICIOS 

Implementación rápida y sencilla.



Menor costo de implementación.



Cubre necesidades específicas del negocio.



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



Asegura la consistencia de los datos



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

UNIVERSIDAD SAN PEDRO ESCUELA DE INGENIERIA CIVIL 

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

DESVENTAJAS 

Inadvertidamente se puede usar datos no compatibles con otros DataMarts que luego alarguen el tiempo de unificación.



Si el Datawarehouse es construido primero, se requiere de hardware adicional para soportar DataMarts individuales.



Datos descentralizados debido a que cada DataMart corresponde a una base de datos individual por tema o por área.



No permite el manejo de grandes volúmenes de información por lo que muchas veces se debe recurrir a un conjunto de DataMarts para cubrir todas las necesidades de información de la empresa.

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




MOLAP:

La arquitectura MOLAP usa una base de datos multidimensionales para proporcionar el análisis, su principal premisa es que el OLAP esta mejor implantado almacenando los datos multidimensionalmente. 

ROLAP:

Relational OLAP. Tanto los datos pre calculados y agregados como los datos fuente residen en la misma base de datos relacional. Si el DataWarehouse es muy grande o se necesita rapidez por parte de los usuarios puede ser un problema. 

HOLAP:

Hybrid OLAP: es una combinación de los dos anteriores. Los datos agregados y pre calculados se almacenan en estructuras multidimensionales y los de menor nivel de detalle en el relacional. Requiere un buen trabajo de análisis para identificar cada tipo de dato.

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

Características: -

Son pobladas por usuarios finales.

-

Se optimizan en función a procesos transaccionales.




-

Se actualizan constantemente.

-

Contienen mucha información de detalle

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

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


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

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


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

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



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



Fuentes de datos y actualizar los datos de frecuencia

El objetivo principal para el proceso de gestión de metadatos es proporcionar un directorio de puntos de vista técnico y comercial de los metadatos DataMart. Los metadatos pueden ser categorizados como metadatos técnicos y los metadatos de negocio.

Los metadatos técnicos se componen de metadatos creados durante la creación del mercado de datos, así como metadatos para apoyar la gestión de la despensa de datos. Esto incluye las normas de adquisición de datos, la transformación de los datos fuente en el formato requerido por la meta data mart y horarios para realizar copias de seguridad y restauración de datos.

Metadatos de negocios permite a los usuarios finales para comprender qué tipo de información está disponible en el mercado de datos y la forma en que se puede acceder


7.4 HERRAMIENTAS DE EXPLOTACIÓN El DataMart está orientado a la toma de decisiones. Un buen diseño de la base de

datos favorece el análisis y la recuperación de datos para obtener una ventaja estratégica y para facilitar la toma de decisiones. El DataMart no está orientado a procesos relacionados con la operatividad del área determinada. El DataMart está preparado para ser explotado mediante herramientas específicas que permiten la extracción de información significativa y patrones de comportamiento que permanecen ocultos en un enorme repositorio de datos. Veamos las herramientas software que existen:  HERRAMIENTA

DE CONSULTA Y REPORTE

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


una base de datos, extrae los datos pertinentes, efectúa cálculos adicionales, manipula los datos si es necesario y presenta los resultados en un formato claro. Se puede almacenar las consultas y los pedidos de reporte para trabajos subsiguientes, como está o con modificaciones. El procesamiento estadístico se limita comúnmente a promedios, sumas, desviaciones estándar y otras funciones de análisis básicas. Aunque las capacidades varían de un producto a otro, las herramientas de consulta y reporte son más apropiadas cuando se necesita responder a la pregunta ¿"Qué sucedió"?.  HERRAMIENTAS

DE

BASE

DE

DATOS

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

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



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

 SISTEMAS DE

INFORMACIÓN EJECUTIVOS

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


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

muchas

de

las

herramientas

de

consulta/reporte

y

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

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


VIII. FASES DE CONSTRUCCION Para el proceso de construcción de datos existen dos enfoques: 1) Construir primero un núcleo de bodega de datos y luego hacer varios DataMarts. 2) Construir primero un DataMart e ir expandiendo poco a poco la bodega de datos y añadiendo nuevos DataMarts. La construcción del DataMart puede ser en forma total (completa}, o incremental. 

CONSTRUCCION TOTAL (COMPLETA). Cuando se ejecuta la construcción desde el 03 Designer, el DataMart generado corresponde al modelo activo actualmente en el 03 Designer.



CONSTRUCCION INCREMENTAL. Es utilizado para actualizar la información del DataMart, evitando la reconstrucción completa a los efectos de ahorrar tiempo y recursos del sistema.

ENTORNO DEL 03 DESIGNER


IX. PASOS PARA IMPLEMENTAR UN DATAMART PASO 1: IDENTIFICAR LOS TEMAS DE ANÁLISIS. Esta tarea consiste en definir los temas y sus respectivos indicadores que serán analizados y explotados por los usuarios, por ejemplo:

Tema: Ventas en una farmacia. Indicadores: Cantidad Vendida, Precio Unitario, Total, Descuento, IGV, etc. PASO 2: IDENTIFICAR LAS DIMENSIONES DE INFORMACIÓN. Las dimensiones de Información es la forma cómo el usuario podrá agrupar la Información .Las dimensiones siempre deben responder una de estas6 preguntas: A Quién, Dónde, Cuándo, Qué, Cómo y A quien .Recuerde que el usuario siempre necesitará que el DataMarts le responda cualquiera de estas preguntas con la finalidad de poder tomar dediciones más acertadas.

PASO 3: ELABORACIÓN DEL MODELO MULTIDIMENSIONAL BÁSICO Con ayuda de alguna herramienta CASE, deberá diseñar un modelo multidimensional capaz de soportar cualquiera de las consultas que los usuarios puedan hacer en un futuro al Data Marts. El esquema empleado como Copo de Nieve (Las normalizan en tablas más pequeñas) ,

tablas se

Estrella (Una tabla de hechos en el centro conectada

con un conjunto de tablas de dimensiones).

constelación de estrellas (Múltiples tablas de

hechos comparten tablas de dimensión que se visualizan como una colección de hechos)

,

tormenta de nieve, etc., dependerá de la herramienta de explotación que estén utilizando

PASO 4: ELABORACIÓN DEL MODELO MULTIDIMENSIONAL COMPLEJO En esta etapa se realiza el proceso de calificación a los indicadores y a los atributos.


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


PASO 5: ELABORACIÓN DE LAS ESPECIFICACIONES DE CARGA DE DATOS Este es el momento donde se trata de buscar la información en las diferentes fuentes de datos de la organización para cargar el modelo multidimensional creado.

PASO 6: CREACIÓN DE BASE DE DATOS. Se debe crear una base de datos que contendrá la información del DataMarts que será explotada. En el caso que no exista una metadata se deberá crear una base de datos en blanco con las características y especificaciones técnicas de la herramienta que será utilizada para la explotación de los datos.

PASO 7: CONSTRUCCIÓN DE LA ARQUITECTURA DEL DATA MARTS. Este es el momento donde se construyen la arquitectura del DATAMART, que en el caso de las herramientas MOLAP serían los cubos de información.

PASO 8: ETL Consiste en extraer, transformar y cargar los datos de los sistemas fuentes hacia la base de datos del DataMarts. Los programas de ETL deben cumplir con las especificaciones que se desarrollaron en el paso 5, con la finalidad de llevar una correcta documentación del proyecto. Los programas de cargas deben verificar los errores de integridad referencial y limpiarla en el caso que se detecte alguna ocurrencia. Una mala planificación o construcción de los programas de ETL pueden ocasionar que los usuarios dejen de usar el DataMarts, por ejemplo: o

La información está inconsistente

o

Sólo se tiene cargado pocos periodos debido a la falta de espacio en el disco.

o

La carga se paralizó debido a que uno de los programas identificó que existe datos inconsistentes.

o

Los programas no se ejecutaron en el momento que se requerían.

o

No se puede reprocesar la información y se mantienen datos no certeros.


PASO 9: IMPLEMENTACIÓN Un motivo relevante por el cual los usuarios no utilizan los DataMarts es por falta de capacitación

PASO 10: CAPACITACIÓN AL USUARIO Otro de los principales motivos por el cual los usuarios no utilizan los DataMarts es por falta de capacitación. La capacitación que debe recibir el usuario debe estar enfocada en:

a. El Modelo Multidimensional.- Es importante que los usuarios conozcan los diferentes modelo multidimensionales de la empresa. b. La Herramienta de explotación:- Se dice que los usuarios solo utilizan el 20% de las opciones que cuentan las herramientas de explotación por falta de capacitación. c. Las herramientas de gestión:- Los usuarios deben ser constantemente capacitados en herramientas de gestión como creación de Dashboard, Scorecard, etc


6. REPRESENTACIONES GRAFICAS

DATAMART

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

DataMarts Dependientes


Funcionamiento de un DataMart con un DataWarehouse

Componentes en la Creación de un DataMart


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

EN SQL SERVER 2005 DE DATAMART PARA EL SOPORTE A LA TOMA DE DECISIONES EN LA CONSULTORÍA Y CONSTRUCCIÓN DE VIGAS DE HORMIGÓN ARMADO DE UNA EMPRESA CONSULTORA CONSTRUCTORA”

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

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


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

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

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


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

DESARROLLO PRÁCTICO 1. INFORMACIÓN NECESARIA PARA EL APOYO A LA TOMA DE DECISIONES  Indicadores 





de Rendimiento Claves o KPIs

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

 Medidas   









  



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

 Dimensiones    

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


2. INFORMACIÓN DISPONIBLE

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

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

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

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

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


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

acero está permisibles. FALLA Naturaleza de la falla del elemento RESMOM Resistencia a momento del elemento. COSTO Costo del elemento (Bs.) COTM Llave foránea; a la tabla TIEMPO. COFM Llave foránea; a la tabla FAMILIA

dentro

delos

límites


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

FALLA_C Naturaleza de falla del elemento. RESMOM_C Resistencia a momento del elemento COSTO_C Costo del elemento (Bs.) COTM_C Llave foránea; hace referencia a la tabla TIEMPO.COFM_C Llave foránea; hace referencia a la tabla FAMILIA


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

Diseño lógico del OLTP fuente


3. MODELO DE DATOS PARA EL DATAMART

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

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

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

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


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

Diferencia de Diferencia en el área

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

Diferencia en el costo (Bs.)

ELE_ERR

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

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


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

Medida

Fórmula Matemática

RES_HOR_ERR

SIGN(ABS(VICONS.RESHOR_CVIDIS.RESHOR))

RES_ACER_ERRSIGN

(ABS(VICONS.RESACER_CVIDIS.RESACER))

ANCHO_ERR

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

ALTO_ERR

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

LARGO_ERR

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

VOL_DIF

(VICONS.VOL_C-VIDIS.VOL)

A_ACERO_DIF

(VICONS.AACER_C-VIDIS.AACER)

RES_MOM_ERR SIGN

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

COSTO_DIF

(VICONS.COSTO_C-VIDIS.COSTO)

ELE_ERR

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


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


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:



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

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


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

Vista del origen de datos


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

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


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

El cubo o DataMart creado y reconocido correctamente


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

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


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.


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

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


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


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

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


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


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


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

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


Las asignaciones de campos para la tabla de hechos del cubo

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


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

Modo de almacenamiento MOLAP sin caché


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

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

Procesamiento de las dimensiones del cubo


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

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


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

Completado de las traducciones para una mejor legibilidad del cubo


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

Un primer uso real del cubo. En la anterior ilustración se puede apreciar que se está consultando la “diferencia de costo” (construido vs. presupuestado)

por obra por gestión por asignación y filtrado

por tipo de sección de viga. En este caso de estudio de ejemplo puede apreciarse que, en la gestión 2007, la construcción de todas las vigas involucradas en las obras mostradas, ha costado casi 70 bolivianos menos de lo presupuestado; todo esto, bajo responsabilidad del “ING. POEPSEL”.


EJEMPLO N°2: TEMA:

“DESARROLLO DE UN DATAMARTS DE INFORMACIÓN

ACADÉMICA DE ESTUDIANTES DE LA ESCUELA DE CIENCIAS Y SISTEMAS DE LA FACULTAD DE INGENIERÍA DE LA USAC”GUATEMALA, AGOSTO DE 2007

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

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


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

DISEÑO

E

IMPLEMENTACIÓN

DE

UN

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

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

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


8. CONCLUSIONES Y RECOMENDACIONES 

La implementación de un proceso de inteligencia de negocio en una organización, permite que la información fluya de una forma natural y controlada desde donde se producen las transacciones del día a día de la organización, hasta convertirlas en información y conocimiento que permiten a los usuarios finales tomar mejores y efectivas decisiones.



El DataMart es específico para una necesidad de datos seleccionados, enfatizando el fácil acceso a una información relevante.



La diferencia principal entre los mercados de datos independientes y dependientes es la forma de llenar la despensa de datos, es decir, cómo obtener datos de las fuentes y en la despensa de datos.



El SQL es un lenguaje muy extendido entre los programadores, pero no tanto entre los usuarios finales. Aunque estas herramientas escondan en cierta forma los comandos del SQL, sigue siendo necesario tener claro el modelo relacional en cuanto se quiere hacer algún informe complejo, por lo que su utilización directa no está recomendada a usuarios finales.



Del ejemplo aplicativo N°1.La implementación en SQL Server 2005

de

DataMart tendrá grandes beneficios ya que brindara un soporte en la toma de decisiones que se realizará en la consultoría y construcción de vigas de hormigón armado de la empresa consultora constructora. 

Del ejemplo aplicativo N°2. En la escuela de ciencias y sistemas se obtendrán grandes beneficios al utilizarse el DataMart académico, puesto que se podrá analizar el comportamiento de los estudiantes de la escuela y por ende se podrá tomar mejores decisiones en cuanto al uso de los recursos y el enfoque de la carrera de sistemas de la Facultad de Ingeniería.



Todas las empresas que manipulen información de mucha importancia debe implementar los Data Mart para poder darle un mejor manejo a toda esa


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

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




Data mart Un Data mart es una versión especial de almacén de datos (data warehouse). Son subconjuntos de datos con el propósito de ayudar a que un área específica dentro del negocio pueda tomar mejores decisiones. Los datos existentes en este contexto pueden ser agrupados, explorados y propagados de múltiples formas para que diversos grupos de usuarios realicen la explotación de los mismos de la forma más conveniente según sus necesidades. El Data mart es un sistema orientado a la consulta, en el que se producen procesos batch de carga de datos (altas) con una frecuencia baja y conocida. Es consultado mediante herramientas OLAP (On line Analytical Processing - Procesamiento Analítico en Línea) que ofrecen una visión multidimensional de la información. Sobre estas bases de datos se pueden construir EIS (Executive Information Systems, Sistemas de Información para Directivos) y DSS (Decision Support Systems, Sistemas de Ayuda a la toma de Decisiones). Por otra parte, se conoce como Data Mining al proceso no trivial de análisis de grandes cantidades de datos con el objetivo de extraer información útil, por ejemplo para realizar clasificaciones o predicciones. En síntesis, se puede decir que los data marts son pequeños data warehouse centrados en un tema o un área de negocio específico dentro de una organización.

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





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










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

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

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







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


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

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

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

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

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


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

Categoría Alcance Sujeto Fuentes de datos Tamaño (típico) Tiempo de Implementación

Data Warehouse Corporativo Múltiple Muchos 100 GB-TB + Meses o años

Data Mart Línea de negocio (LOB) Sujeto individual Pocos <100 GB Meses

A.3 dependientes e independientes de datos Marts Hay dos tipos básicos de data marts: dependientes e independientes. La clasificación se basa principalmente en el origen de datos que alimenta el mercado de datos. Mercados de datos dependientes extraer datos de un almacén 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, cómo obtener datos de las fuentes y en la despensa de datos. Esta etapa, denominada de extracción-transformación 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 almacén 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 almacén de datos central. El número de


fuentes es probable que sea menos y la cantidad de datos asociados con el mercado de datos es menor que el almacén, dado su enfoque en un solo tema. Las motivaciones detrás de la creación de estos dos tipos de data marts son también típicamente 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 específico. La creación de mercados de datos independientes a menudo es impulsada por la necesidad de disponer de una solución en un tiempo más corto.

A.4 ¿Cuáles son los pasos en la implementación de un Data Mart? En pocas palabras, los pasos más importantes en la implementación de un data mart son diseñar el esquema, la construcción del almacenamiento físico, 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 sección contiene los siguientes temas:     

Sección A.4.1, "Diseño" Sección A.4.2, "La construcción" Sección A.4.3, "Cómo llenar" Sección A.4.4, "Acceso" Sección A.4.5, "Gestión"

A.4.1 Diseño La etapa de diseño 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 través de la recopilación de información acerca de los requisitos, y el desarrollo del diseño lógico y físico del data mart. La etapa de diseño comprende las siguientes tareas:    

Reunir los requisitos técnicos y de negocio Identificar las fuentes de datos Seleccionar el subconjunto apropiado de los datos Diseño de la estructura lógica y física del data mart

A.4.2 Construcción Este paso incluye la creación de la base de datos físico y las estructuras lógicas asociadas con el mercado de datos para proporcionar acceso rápido y eficiente a los datos. Este paso implica las siguientes tareas:




 

La creación de la base de datos físico 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 diseño 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 obtención de los datos de la fuente, la limpieza para arriba, modificándolo al formato adecuado y el nivel de detalle, y que se incorpore al mercado de datos. Más formalmente declarado, el paso consiste en rellenar las siguientes tareas:     

Cartografía de las fuentes de datos para orientar las estructuras de datos Extracción de los datos La limpieza y la transformación de los datos Cargando datos en el data mart Creación 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 análisis, la creación de informes, tablas y gráficos, y la publicación de los mismos. Típicamente, el usuario final utiliza una interfaz gráfica 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 términos de negocio, por lo que el usuario final puede interactuar con el mercado de datos utilizando términos que se relacionan con la función 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 través de la herramienta de front-end ejecutar de forma rápida y eficiente.

A.4.5 Gestión Este paso implica la gestión del mercado de datos sobre su vida. En este paso, va a realizar las tareas de gestión, tales como los siguientes:    

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


B Diseñar el Data Mart Este capítulo se centra en las cuestiones relacionadas con el diseño de un data mart. Piense en este capítulo como una colección de consejos sobre cómo organizar su data mart ejecución 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 técnicos). El factor empresarial motriz para la despensa de datos es la la necesidad de información, y la mejor manera de empezar el proceso de diseño es mediante la identificación de las necesidades del negocio. Usted debe incluir a aquellos que tienen una inversión en el mercado de datos, tales como el promotor de negocios y el usuario final, lo más temprano posible en el proceso de diseño. Juntos, ustedes deberían ponerse de acuerdo sobre los requisitos de información que el mercado de datos deben cumplir, las fuentes de datos, los requisitos técnicos (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 diseño de un mercado de datos son los siguientes: 1. Realización de un estudio para definir el alcance del proyecto 2. Definición de los requerimientos de negocio y técnicos para el mercado de datos 3. Desarrollo del diseño lógico y físico del data mart En este capítulo se incluyen los temas siguientes:   

Sección B.1, "Definición del Alcance del Proyecto Data Mart" Sección B.2, "Definición de los requisitos para el Data Mart" Sección B.3, "Data Mart Diseño"

B.1 Definición del Alcance del Proyecto Data Mart Antes de empezar a poner en práctica el mercado de datos, es necesario desarrollar un plan para su entrega. Insumos críticos a este plan son las necesidades de información y prioridades de los usuarios. Después de esta información 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 límites del proyecto y se expresa típicamente en una combinación de las funciones de la geografía, la organización y la aplicación, o de negocios. Definición 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 finalización prevista y las capacidades que se comprometió a entregar. Definir el alcance y dejando claro a todos los involucrados es importante porque:


   

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

B.2 Definición de los requisitos para el Data Mart Para iniciar la aplicación de la despensa de datos, es necesario definir los requisitos empresariales y técnicos. Sin embargo, usted debe esperar que los requisitos para cambiar a medida que los usuarios utilizan la aplicación inicial y son más 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 retroalimentación de los usuarios. Esta sección contiene los siguientes temas:   

Sección B.2.1, "Definición de Requerimientos del Negocio" Sección B.2.2, "Identificación de los requisitos técnicos" Sección B.2.3, "¿Cómo saber si lo ha hecho bien?"

B.2.1 Definición de Requerimientos del Negocio El propósito de la despensa de datos es proporcionar acceso a los datos que sea específico de un departamento o área funcional. Los datos deben ser de un nivel apropiado de detalle para el tipo de análisis que los usuarios finales desean realizar, y debe ser presentada en los términos del negocio que ellos entienden. La expectativa es que el análisis de los datos en un data mart llevará a tomar decisiones de negocio más informadas. Por lo tanto, es necesario comprender cómo 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 través 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 reúnen los requisitos para el puesto de datos, debe centrar sus esfuerzos en las necesidades de información de un tema único. Recuerde que ningún documento de requisitos será lo suficientemente completa como para obtener toda la información desde el principio, y lo que necesita para diseñar el data mart para adaptarse a las necesidades cambiantes. Sin embargo, si usted introducir nuevos temas o se desvíe de su tema principal, perderá su foco y horario. A pesar de que el mercado de datos aborda un área temática, 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 comercialización, entrevista a varias personas involucradas en diversos aspectos de la función de marketing (por ejemplo, un


analista de marketing, especialista en canal, gerente de marketing directo, y el gerente de promoción). Utilice un conjunto coherente de preguntas o una plantilla de entrevista para cada entrevista. Las preguntas deben centrarse en las necesidades de información de los usuarios, como el contenido, la frecuencia de actualización, las prioridades y el nivel de detalle. Por último, establecer un límite de tiempo definido en la entrevista y los requisitos de recopilación de fase, de lo contrario, podría continuar indefinidamente mientras trata de perfeccionar cada requisito. Usted no puede obtener todos los requisitos de este marco de tiempo, pero conseguirás lo suficiente para crear una hoja de ruta. Las necesidades cambian durante el período de ejecución, 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 Identificación de los requisitos técnicos Usted debe identificar los requisitos técnicos. 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 día a día. Por lo general, estos sistemas operativos son de procesamiento de transacciones en línea (OLTP). Su mercado de datos puede ser alimentado desde más 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 cómo limpiar los datos operativos y la cantidad de formateo o la traducción es necesaria para integrarla con otras fuentes. Además, es necesario determinar con qué frecuencia debe actualizar o actualizar los datos. Por ejemplo, si utiliza los datos para relativamente planificación a largo plazo y horizontes de análisis, es posible que necesite una alimentación semanal o mensual en lugar de una alimentación diaria. Tenga en cuenta que la frecuencia de actualización no necesariamente determinar el nivel de detalle en el mercado de datos. Usted puede tener una alimentación mensual de los datos resumidos por semana. En esta fase inicial de los datos de diseño 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 ¿Cómo saber si lo ha hecho bien? Cuando termine de hacer las entrevistas, se tiene un conjunto de requisitos de información 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, hágase las siguientes preguntas:    

¿El desempeño de la principal preocupación? ¿Está limitada por la configuración de los sistemas? ¿Con qué frecuencia desea actualizar o añadir 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?




¿Es su alcance consistente con la arquitectura de TI, o se puede desarrollar de manera autónoma?

Tenga en cuenta las respuestas a estas preguntas a medida que desarrollan sus prioridades y factores críticos de éxito. En resumen, aquí están algunas pautas para facilitar el proceso de definición de requisitos:  



Implicar a los usuarios finales de todo el proceso. Clasificar el marco de análisis 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 Diseño Al principio de la fase de diseño, los requisitos comerciales ya están definidos, el alcance de su aplicación data mart se ha acordado, y tiene un diseño conceptual. Ahora, es necesario traducir sus necesidades en un sistema de entrega. En este paso, creará el diseño lógico y físico para el mercado de datos y, en el proceso, definir el contenido específico 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 refreshed.The diseño lógico es más conceptual y abstracto que el diseño físico. En el diseño lógico, nos fijamos en las relaciones lógicas entre los objetos. En el diseño físico, nos fijamos en la forma más eficaz de almacenar y recuperar los objetos. El diseño de su puesto de datos debe orientarse hacia las necesidades de sus usuarios finales. Los usuarios finales normalmente se desea llevar a cabo el análisis y examinar los datos agregados, y no en transacciones individuales. Su diseño está impulsado principalmente por la utilidad del usuario final, pero los usuarios finales no saben lo que tienen hasta que lo ven. Un diseño bien planificado permite el crecimiento y cambia a medida que las necesidades de los usuarios cambian y evolucionan. La calidad de su diseño 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 utilización óptima de los recursos está determinada principalmente por su diseño. Al comenzar con el diseño lógico, que se centran en las necesidades de información sin enredarse inmediatamente con detalle de implementación. Tenga en cuenta que no se ven obligados a trabajar de una manera de arriba hacia abajo. Usted puede realizar ingeniería inversa de un esquema de datos existente y utilizar esto como punto de partida para su diseño. 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 diseño físico y luego pasar directamente a la implementación física. En la práctica, se necesitan varias iteraciones antes de lograr el diseño adecuado.


Esta sección contiene los siguientes temas:      

Sección B.3.1, "Creación de un diseño lógico" Sección B.3.2, "Creación de una lista de deseos de los datos" Sección B.3.3, "Fuentes" Identificación de Sección B.3.4, "Clasificación de datos para el esquema Data Mart" Sección B.3.5, "Diseño del esquema de las Galaxias" Sección B.3.6, "Pasar de la lógica de diseño físico"

B.3.1 Creación de un diseño lógico Un diseño lógico es un diseño conceptual, abstracto. Usted no se ocupan de los detalles de implementación física todavía, tiene que tratar sólo con la definición de los tipos de información que usted necesita. El proceso de diseño lógico consiste en organizar los datos en una serie de relaciones lógicas llamadas entidades y atributos. Una entidad representa un pedazo de información. 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 carácter único de la entidad. En bases de datos relacionales, un atributo se asigna a una columna. Mientras diagramas de entidad-relación se ha asociado tradicionalmente con modelos altamente normalizados, como las aplicaciones OLTP, la técnica 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 atómicas de la información y todas las relaciones entre ellos, se intenta identificar qué información le pertenece a una tabla de hechos central y que la información pertenece a sus tablas de dimensiones asociadas. Atención al diseño es crítico. Mantenga sus requerimientos de negocio en la mano durante todo el proceso de diseño. Nada es más importante! Como parte del proceso de diseño, se asignan los datos operacionales desde su origen en asignaturas y tiene información 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 código de modelo empresarial de su empresa y los datos de ingeniería inversa del modelo de datos lógico para el data mart de esto. La implementación física del modelo de datos lógicos mart puede requerir algunos cambios debido a su sistema de parámetros de tamaño de ordenador, número de usuarios, capacidad de almacenamiento, tipo de red y software. Usted tendrá que tomar decisiones a medida que desarrolle el diseño lógico:   

Hechos y dimensiones Granularidad de los hechos Relación entre las entidades




Duración histórica de los datos

B.3.2 Creación 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 más allá de los requerimientos específicos de los usuarios y anticiparse a las necesidades futuras. Comience con los parámetros de negocio que son importantes para su área temática. Durante Ventas y Mercadeo mart datos, los parámetros pueden ser clientes, Geografía, Producto, Ventas y Promociones. Recuerde Time-¿quieres ver las cifras mensuales, diarias o semanales? A continuación, 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 numéricos Agrupaciones razonable de los datos, como las regiones geográficas de los elementos del país, condado, ciudad Una idea de la relación entre los datos, como "una ciudad dentro de un condado"

Campos de datos típicos de interés en las Ventas y Marketing de ejemplo podrían ser las ventas en dólares, las ventas de unidades, nombres de productos, paquetes, las características de la promoción, regiones y países. Identificar el crítico campos: los que llevó a la creación del mercado de datos. Los datos tales como las ventas en dólares o ventas unitarias son críticos 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 gustaría ver. Los informes son un buen vehículo para llegar a los usuarios a expresar sus necesidades. En este punto, puede separar los datos en datos numéricos (los hechos) y los datos textuales o descriptivos (las dimensiones). Durante el proceso iterativo de interacción con el usuario final, pregunte por qué ciertos datos es importante, qué decisiones están impulsadas por estos datos? Una idea de los procesos de negocio le ayudará a anticiparse a las necesidades futuras de datos.

B.3.3 Identificación 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


datos pueden variar desde sistemas operativos, tales como sistemas de procesamiento de pedidos, hasta hojas de cálculo. Es necesario asignar los elementos individuales de su lista de deseos a las fuentes. Usted debe comenzar con el más grande, más completa fuente y buscar otras fuentes cuando sea necesario. Típicamente, un gran porcentaje de los datos provienen de una o dos fuentes. Las dimensiones por lo general se pueden asignar a tablas de búsqueda en su sistema operativo. En su forma pura, los hechos que se pueden asignar a las tablas de transacción. Para el uso en el mercado de datos, los datos de transacción generalmente necesita ser agregados, basado en el nivel de granularidad especificada. Granularidad es el más bajo nivel de información 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 fácilmente por el código de área. Sin embargo, el mercado de datos necesita datos por código postal. Debido a que un código de área contiene varios códigos postales y un código postal puede abarcar múltiples códigos de área, es difícil para mapear estas dimensiones. Es posible que algunos datos son muy costosos de adquirir. Por ejemplo, los datos de promoción que los usuarios solicitados no se pueden obtener fácilmente debido a que la información no es coherente a través del tiempo o la promoción. Para traducir a un formato de sistema común sería muy costoso.

B.3.4 Clasificación de datos para el esquema de Data Mart En este punto, se ha empezado a pensar en la clasificación de los datos como hechos y dimensiones. Una representación común de los hechos, las dimensiones y las relaciones entre ellos en aplicaciones de datos Mart es el esquema en estrella. Típicamente, contiene una dimensión de tiempo y está optimizado para el acceso y el análisis. Se llama un esquema en estrella porque la representación gráfica se ve como una estrella con una tabla de hechos grande en el centro y las tablas de dimensiones más pequeñas dispuestas alrededor de ella. Diseño avanzado de modelado puede incluir esquemas, llamados esquemas de copo de nieve o constelación, que son más complejas que las simples mostrados esquema en estrella. En las secciones siguientes se proporciona más información sobre las dimensiones, los hechos, y el nivel de granularidad. Esta sección contiene los siguientes temas:   

La sección B.3.4.1, "Dimensiones" La sección B.3.4.2, "Hechos" La sección B.3.4.3, "granularidad"

B.3.4.1 Dimensiones


En el ejercicio de clasificación, muchos de los campos del origen de OLTP va a terminar como dimensiones. El problema de diseño importante es decidir si un campo es más que otro elemento de una dimensión existente, o cuando debe tener su propia dimensión. La dimensión del tiempo se genera de forma independiente usando las fechas discretas en la fuente OLTP. Esto ofrece flexibilidad para realizar cualquier análisis de series de tiempo. Para un esquema en estrella verdadera, el orden de creación 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, asegúrese de crear todas las tablas de dimensiones en primer lugar.

B.3.4.2 Datos Los hechos son los indicadores numéricos de la empresa. Apoyan cálculos matemáticos utilizados para informar y analizar el negocio. Algunos datos numéricos son dimensiones disfrazados, incluso si parecen ser hechos. Si usted no está interesado en un resumen de un artículo en particular, el artículo puede ser en realidad una dimensión. Tamaño de base de datos y el rendimiento general mejorará si se realiza una clasificación campos limítrofes como dimensiones. Por ejemplo, suponga que tiene una base de datos de membresía 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 dimensión? Que sea una dimensión.

B.3.4.3 Granularidad Después 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 información dentro de una dimensión. 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 Diseñar 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 más 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 sintéticas), en lugar de teclas naturales, para vincular los hechos y las dimensiones. Esto proporciona el administrador del


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 sintética generada de números enteros. Se incluyen las teclas sintéticos en la tabla de dimensiones, además de la clave natural. A continuación, utiliza la clave sintética en la tabla de hechos como la columna que se une a la tabla de hechos a la tabla de dimensiones. Aunque la creación de claves sintéticas requiere una planificación adicional y trabajo, las claves pueden proporcionar beneficios de llaves naturales: 



Teclas naturales a menudo son largas cadenas de caracteres, como en un código de producto. Dado que las claves sintéticas son enteros, el tiempo de respuesta a las consultas se mejora. El administrador del mercado de datos tiene el control sobre la clave sintética. Si un grupo de fabricación cambia el código del producto de las convenciones de nomenclatura, los cambios no afectan a la estructura del mercado de datos. Considere el uso de claves sintéticas para la mayoría de las tablas de dimensiones. (En el resto de este tutorial, nos referimos a las claves sintéticas como claves del almacén.)

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 lógica de diseño físico Durante el proceso de diseño físico, convertir los datos recogidos durante la fase de diseño lógico en una descripción de la base de datos física, incluyendo tablas y restricciones. Esta descripción optimiza la colocación de las estructuras de base de datos físicos 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 desempeño para ese tipo de consultas. Decisiones de diseño físico, tales como el tipo de índice o partición, tendrá un gran impacto en el rendimiento de la consulta. A medida que el mercado de datos se convierte en éxito y se utiliza más ampliamente, más y más usuarios tengan acceso a ella. Con el tiempo, el volumen de datos también crecerá. Escalabilidad, la capacidad de aumentar el volumen de los datos y el número de usuarios, es una consideración importante cuando se mueve de su diseño lógico para una representación física. 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 sección contiene los siguientes temas:


 

La sección B.3.6.1, "Estimar el tamaño del Data Mart" La sección B.3.6.2, "¿Qué son los metadatos?"

B.3.6.1 Estimar el tamaño del Data Mart Al estimar el tamaño de su mercado de datos, es necesario desarrollar un método que se acomoda a su crecimiento futuro. Hay varios métodos para estimar el tamaño de la base de datos. He aquí una aproximación: 1. Utilice una muestra representativa de los datos de origen para determinar el número de filas de la tabla de hechos. 2. Estimar el tamaño de una fila en la tabla de hechos. 3. Estimar el tamaño de la tabla de hechos multiplicando el número de filas por el tamaño de una fila. 4. Estimar el tamaño del mercado de datos. En general, el tamaño total del mercado de datos es de tres a cinco veces el tamaño de la tabla de hechos. Este proceso es generalmente iterativo. Cada vez que los cambios de diseño, se debe estimar el tamaño nuevo. Incluso si usted piensa que el esquema en estrella es pequeña, usted debe hacer este cálculo una vez. Después de calcular el tamaño, puede validar su hipótesis 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. Añadir sobrecarga de indexación, 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 relación entre el tamaño estimado del mayor tamaño posible de la tabla de hechos para calcular el tamaño futuro del mercado de datos: 1. Para cada dimensión, comprobar el nivel de detalle que desea y estimar el número de entradas en el mejor nivel. 2. Multiplique el número de entradas de todas las dimensiones para obtener las filas máximos posibles. 3. Calcular la relación 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 número de filas de todas las tablas de dimensiones. 6. Ajuste el número, usando la escala calculada en el paso 3. 7. Multiplique el resultado por el hecho de tamaño 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 función de los volúmenes de datos y la carga del


sistema, este trabajo puede durar varias horas. Planifique su mercado de datos de actualización 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 planificación, también se debe estimar el volumen de datos que se actualiza. Desarrollar una estrategia para purgar los datos más allá del período de retención especificado.

B.3.6.2 ¿Qué son los metadatos? Los metadatos son información sobre los datos. Para un mercado de datos, metadatos incluyen:   

Una descripción de los datos en términos de negocio Formato y definición de los datos en términos del sistema Fuentes de datos y actualizar los datos de frecuencia de

El objetivo principal para el proceso de gestión de metadatos es proporcionar un directorio de puntos de vista técnico y comercial de los metadatos data mart. Los metadatos pueden ser categorizados como metadatos técnicos y los metadatos de negocio. Los metadatos técnicos se compone de metadatos creados durante la creación del mercado de datos, así como metadatos para apoyar la gestión de la despensa de datos. Esto incluye las normas de adquisición de datos, la transformación de los datos fuente en el formato requerido por la meta data mart y horarios para realizar copias de seguridad y restauración de datos. Metadatos de negocios permite a los usuarios finales para comprender qué tipo de información está disponible en el mercado de datos y la forma en que se puede acceder. Usted utiliza los metadatos técnicos para determinar las reglas de extracción de datos y programas de actualización 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 almacén de datos (data warehouse). Como los almacenes de datos, los data marts contienen una visión de datos operacionales que ayudan a decidir sobre estrategias de negocio basadas en el análisis de tendencias y experiencias pasadas. La diferencia principal es que la creación de un data mart es especifica para una necesidad de datos seleccionados, enfatizando el fácil acceso a una información relevante.


Introduccion de data Mart Los productos Data Warehouse han nacido para resolver problemas de análisis de grandes masas de información, en empresas donde una pequeña diferencia en el valor de una variable, puede afectar la cuenta de resultado con unas diferencias de millones de dólares. Data Mart se destaca por una definición de requerimientos más fácil y rápida. También 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 duración. Normalmente, Data Mart resuelve aplicaciones a nivel departamental, aunque en ocasiones se desarrolla una aplicación 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 validación, derivación y transformación de los datos extraídos. También describen las bases de datos del Warehouse, incluyendo reglas de distribución y control de la migración hacia los Data Marts. Los procesos que monitorean los procesos del Warehouse (como extracción, carga, y uso) crean meta datos que son usados para determinar que tan bien se comporta el sistema. Los meta datos, deberían estar disponibles para los usuarios, para ser usados en sus análisis. Los administradores pueden manejar y proveer el acceso a través 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 diseñados para satisfacer las necesidades específicas de grupos comunes de usuarios (divisiones geográficas, divisiones organizacionales, etc.). Los Data Marts son generalmente, subconjuntos del Data Warehouse, pero pueden también integrar un número de fuentes heterogéneas, e inclusive ser más grandes, en volumen de datos, que el propio Warehouse central. El concepto DataMart es una extensión 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 información que se está abarcando. ¿QUÈ ES DATA MART? Es un pequeños Data Warehouse, para un determinado numero de usuarios, para un area funcional, especifica de la compañía. También podemos definir que un Data Marts es un subconjunto de una bodega de datos para un propósito especifico. Su función es apoyar a otros sistemas para la toma de decisiones. Los procesos que conforma el datawarehouse son: 1-Extracción. 2- Elaboración. 3-Carga. 4-Explotación.


Datamart es un subconjunto de una bodega de datos para unpropósito específico (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., 3años).Su función 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 construcción de bodegas de datos e xisten dosenfoques: • Construir primero un núcleo de la bodega de datos y luego hacer varios datamarts •Construir primero un datamart e ir expandiendo poco a poco labodega de datos y añadiendo

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 solución y los indicadores necesarios de cada cubo relacional. El modo de creación, explotación y mantenimiento de los cubos OLAP es similar, sin importar la herramienta final que se utilice. Datamart OLTP

Data-mart 1

Recommend Documents