1. UNIVERSIDAD CAPITAN GENERAL GERARDO BARRIOS<br />FACULTAD CIENCIAS Y TECNOLOGIA<br />DEPARTAMENTO COMPUTACIÓN<br />2158365104775<br />MISION<br />“Somos una institución de educación superior Universitaria que atravéz del conocimiento científico, el uso de las tecnologías y la práctica de valores, formamos profesionales comprometidos con el desarrollo social y las exigencias del mundo actual”<br />Carrera: Ingeniería en Sistemas y Redes Informáticas<br />Catedrático: Lic. Willian Isaith Flores Orellana <br />Cátedra: Administración de Bases de Datos II<br />Tema: Almacenes de Datos.<br />Integrantes del Equipo:<br />Carlos Ernesto Martínez PérezUSIS029408<br />Josué Neftalí Aguilar PalomoUSIS046908<br />Ricardo Alexander Araujo Baires USIS019608<br />Jorge Antonio Zavala Gómez USIS030808<br />Melvin Alexis Díaz Ganuza USIS047008<br />Nota: _______________________<br />Índice<br /> TOC quot;
1-3quot;
Introducción. PAGEREF _Toc274755228 ii<br />Almacenes de Datos. PAGEREF _Toc274755229 1<br />Evolución de los almacenes de datos. PAGEREF _Toc274755230 4<br />Ventajas y Problemas de los almacenes de datos. PAGEREF _Toc274755231 6<br />Beneficios de los almacenes de datos. PAGEREF _Toc274755232 6<br />Problemas de los almacenes de datos. PAGEREF _Toc274755233 7<br />Arquitectura de los almacenes de datos. PAGEREF _Toc274755234 8<br />1. Base de datos operacional y base de datos externa PAGEREF _Toc274755235 8<br />2. Nivel de acceso a la información PAGEREF _Toc274755236 8<br />3. Nivel de acceso a los datos PAGEREF _Toc274755237 9<br />4. Nivel de directorio de datos (metadatos) PAGEREF _Toc274755238 9<br />5. Nivel de gestión de procesos PAGEREF _Toc274755239 9<br />6. Nivel de mensaje de la aplicación PAGEREF _Toc274755240 9<br />7. Nivel Data Warehouse (físico) PAGEREF _Toc274755241 10<br />8. Nivel de organización de datos PAGEREF _Toc274755242 10<br />Estructura de un Data Warehouse PAGEREF _Toc274755243 10<br />1. Detalle de los datos actuales PAGEREF _Toc274755244 10<br />2. Detalle de datos antiguos PAGEREF _Toc274755245 10<br />3. Datos resumidos PAGEREF _Toc274755246 11<br />4. Metadatos PAGEREF _Toc274755247 11<br />Data Warehouse y las bases de datos operacionales. PAGEREF _Toc274755248 12<br />Herramientas y Tecnologías de almacenes de datos. PAGEREF _Toc274755249 13<br />OLAP PAGEREF _Toc274755250 13<br />ROLAP PAGEREF _Toc274755251 13<br />MOLAP PAGEREF _Toc274755252 14<br />HOLAP (Hybrid OLAP) PAGEREF _Toc274755253 14<br />Herramientas para el diseño de data warehouse PAGEREF _Toc274755254 15<br />Diseño de base de datos para un almacén de datos. PAGEREF _Toc274755255 16<br />Esquema en estrella. PAGEREF _Toc274755256 17<br />Esquema en copo de nieve PAGEREF _Toc274755257 18<br />Metodología de diseño de bases de datos para almacenes de datos. PAGEREF _Toc274755258 19<br />Metodología ascendente (Bottom-up): PAGEREF _Toc274755259 19<br />Metodología decendente (Top-down): PAGEREF _Toc274755260 20<br />Diseño híbrido: PAGEREF _Toc274755261 21<br />Conclusiones. PAGEREF _Toc274755262 22<br />Introducción.<br />A principios de los noventa, Inmon definió el término “almacén de datos” (Data Warehouse, DW): “Un almacén de datos es una colección de datos orientados por temas, integrados, variables en el tiempo y no volátiles para el apoyo de la toma de decisiones”. Un almacén de datos es “integrado” porque los datos que se introducen en el almacén de datos se obtienen de una variedad de fuentes de datos (sistemas heredados, bases de datos relacionales, ficheros COBOL, etc.). <br />Los procesos de extracción, transformación y carga (Extraction-Transformation-Loading, ETL) son los responsables de la extracción de los datos a partir de las diversas fuentes de datos heterogéneas, su transformación (conversión, limpieza, etc.) y su carga en el almacén de datos. <br />Por otro lado, es ampliamente aceptado que los almacenes de datos, las bases de datos multidimensionales y las aplicaciones de Procesamiento Analítico en Línea (On-Line Analytical Processing, OLAP) están basados en el modelado multidimensional. En estos últimos años, se han propuesto varias aproximaciones para acometer el diseño conceptual y lógico de los almacenes de datos y los sistemas multidimensionales, tales como [2, 5, 26, 33, 6, 32, 1], para representar las principales propiedades estructurales y dinámicas del modelado multidimensional. Sin embargo, ninguna de estas propuestas ha sido ampliamente aceptada como un modelo conceptual estándar para acometer el modelado multidimensional. Sin embargo, dada la gran variedad de modelos utilizados en las distintas fases del diseño de los almacenes de datos, se hace absolutamente necesario desarrollar un método lo más estándar posible que proporcione guías de diseño para crear y transformar estos modelos durante la fase de desarrollo de un almacén de datos. En la actualidad, existen algunos intentos de proporcionar un método para el desarrollo de almacenes de datos. Sin embargo, desde nuestro punto de vista, ninguno de ellos cubre to das las fases y transformaciones necesarias para disponer de un método global y estándar para el diseño de almacenes de datos.<br />Almacenes de Datos.<br />19570-5756Los sistemas Data Warehouse o sistemas Data Warehousing surgen como un mecanismo de apoyo para la ayuda de toma de decisiones, en el que los datos de una organización se transforman en información estratégica, a la que además se puede acceder de manera sencilla y en el momento que se necesita. Con esta tecnología, los datos operacionales son una herramienta competitiva para las organizaciones. Se permite a los usuarios finales examinar los datos, realizar análisis y detectar tendencias, llevar a cabo el seguimiento de medidas críticas, producir informes con rapidez y detectar tendencias. De esta forma obtenemos una mayor ventaja competitiva en la organización, pudiéndonos anticipar a diversas situaciones.<br />Los sistemas que contienen datos operacionales (son los datos que se generan en las transacciones diarias de la organización) contienen información que es útil para los analistas de negocio. Por ejemplo, los analistas pueden usar esta información para ver qué productos se vendieron más en cierta población durante una época del año.<br />Pero surgen varios problemas cuando los analistas de negocio intentan acceder directamente a estos datos:<br />Puede que los analistas no tengan el conocimiento suficiente para obtener los datos.<br />Los datos operacionales pueden no estar en el mejor formato para ser usados con propósito de análisis.<br />La ausencia de una visión histórica hace difícil el análisis de los datos.<br />Un proceso de Data Warehousing soluciona estos problemas creando almacenes de datos informacionales. Los datos informacionales son datos que han sido extraídos de los datos operacionales y transformados para la toma de decisiones. Por ejemplo, limpiar los datos, realizar cálculos sobre éstos, separarlos de los datos operacionales…<br />Data Warehousing es el proceso de extraer y filtrar los datos de las operaciones comunes a la organización, procedentes de los distintos sistemas de información y/o sistemas externos, para transformarlos, integrarlos y almacenarlos en un depósito o almacen de datos (Data Warehouse) con el fin de acceder a ellos para dar soporte en el proceso de toma de decisiones de una organización.<br />El objetivo es convertir los datos operacionales en información relacionada y estructurada, homogénea, de mayor calidad y que se mantenga en el tiempo, es decir, los datos más recientes no sustituyen a los precedentes, pero tampoco se acumulan de cualquier manera, sino que se suelen mantener con un mayor nivel de detalle los datos actuales y de manera más agregada los datos anteriores.<br />Un punto fuerte del Data Warehousing es la meta-información. Cada dato está identificado por una descripción, un origen, historial o forma inicial y sucesivas. Este conjunto de datos sobre los datos es lo que se denomina como metadatos. Un metadato proporciona el contenido semántico necesario para que los datos puedan ser interpretados.<br />¿Qué diferencia hay entre Data Warehousing y Data Warehouse?<br />Cuando queremos hacer referencia al proceso global en el que a partir de diferentes fuentes de datos (SGDB, ficheros planos, .csv, etc.) se crea y se mantiene un almacén central de datos y que puede ser consultado por herramientas con un propósito de análisis concreto y de ayuda a la toma de decisiones, se debe utilizar el término de Data Warehousing.<br />Para referirnos no al proceso en sí, sino al repositorio central de datos sobre el que se construye el sistema y que integra todos los datos de la organización desde el punto de vista del usuario y no de los procesos, nos estamos refiriendo a Data Warehouse.<br />Características de un Data Warehouse<br />Un Data Warehouse se caracteriza por ser un conjunto de datos orientados a temas, integrado, variante en el tiempo y no volátiles, que dan soporte al proceso de toma de decisiones. Vamos a analizar esto por partes.<br />1. Orientado a temas<br />Orientado a los temas principales de la organización. La información se clasifica en función de los aspectos que son de interés para la organización. Se organizan por temas para facilitar el acceso y el entendimiento por parte de los usuarios finales. Por ejemplo, tenemos información que proviene de los datos operacionales de distintas áreas como son: préstamos, ahorros, nóminas y créditos. Pues los temas que nos pueden interesar son: clientes, productos, vendedores y actividad.<br />2. Integrado<br />En un sistema operacional no hay integración, pero en un Data Warehouse todos los datos se encuentran integrados. Esta integración se muestra de diferentes maneras: consistencia en codificación de estructuras, en unidades de medida de las variables, en múltiples fuentes, en convenciones de nombres, en atributos físicos de los datos etc.<br />3. Variante en el tiempo<br />En los sistemas operacionales, los datos siempre reflejan el estado de la actividad del negocio en el momento presente, por el contrario, la información almacenada en el Data Warehouse refleja un histórico de los datos en un horizonte de tiempo mucho más amplio (del orden de años). De esta forma podemos detectar tendencias en el tiempo.<br />4. No volátil<br />El Data Warehouse existe para ser leído y no para ser modificado, la información es por tanto permanente, la actualización del Data Warehouse significa la incorporación de los últimos valores que tomaron las distintas variables contenidas en él, sin ningún tipo de acción sobre lo que ya existía. Los datos más recientes no sustituyen a los precedentes, sino que suelen mantenerse con un mayor nivel de detalle. Por ejemplo: en el año actual se guardarían las ventas diarias de los diferentes artículos, mientras que los datos anteriores se mantendrían accesibles de manera agregada.<br />Evolución de los almacenes de datos.<br />El concepto de almacenamiento de datos se remonta a finales de 1980, cuando los investigadores de IBM Barry Devlin y Paul Murphy desarrolló “el negocio de almacenamiento de dato “. En esencia, el concepto de almacenamiento de datos tenía por objeto proporcionar un modelo de arquitectura para el flujo de datos de los sistemas operativos para entornos de apoyo a la decisión. El concepto tratado de abordar los diversos problemas asociados con este flujo, principalmente los altos costos asociados con ella. <br />A falta de un depósito arquitectura de datos, una enorme cantidad de redundancia estaba obligada a soportar múltiples entornos de apoyo a la decisión. En las grandes empresas era típico para múltiples entornos de apoyo a la decisión de operar de forma independiente. Aunque cada entorno servido diferentes usuarios, que a menudo requiere gran parte de la misma los datos almacenados. El proceso de recolección, limpieza y la integración de datos de diversas fuentes, por lo general de largo plazo de los sistemas operativos existentes (normalmente se conoce como sistemas de legado), era típicamente en la parte replicada para cada entorno. Además, los sistemas operativos fueron reexaminados con frecuencia como los nuevos requisitos de apoyo a la decisión surgió. A menudo, los nuevos requisitos exigían la recolección, limpieza y la integración de los nuevos datos de quot;
data martsquot;
que fueron diseñados para un fácil acceso por los usuarios.<br />Principales acontecimientos en los primeros años de almacenamiento de datos fueron los siguientes:<br />1960 - General Mills y el Dartmouth College, en un proyecto conjunto de investigación, desarrollar los términos de dimensiones y hechos.<br />1970 -ACNielsen e IRI proporcionar data marts dimensionales para las ventas al por menor.<br />1983 -Teradata introduce un sistema de gestión de base de datos diseñada específicamente para apoyar las decisiones.<br />1988 - Barry Devlin y Paul Murphy publicar el artículo Una arquitectura de la información y los sistemas empresariales de IBM Systems Journal en el que introducir el término quot;
negocio de almacenamiento de datosquot;
.<br />1990 - Red Brick Systems lanza Red Brick Warehouse, un sistema de gestión de base de datos específicamente para el almacenamiento de datos.<br />1991 - Soluciones Prisma Prisma introduce Warehouse Manager, el software para el desarrollo de un almacén de datos.<br />1991 - Bill Inmon publica el libro Construyendo el almacén de datos.<br />1995 - El Data Warehousing Institute, una organización sin fines de lucro que promueve el almacenamiento de datos, es fundada.<br />1996 - Ralph Kimball publica el libro El kit de herramientas de Data Warehouse.<br />2000 - Daniel Linstedt libera el almacenamiento de datos, lo que permite en tiempo real auditable almacenes de datos.<br />El concepto del data warehouse ha evolucionado de sobre manera en estos últimos años de forma que el concepto original nos sirve de partida pero para nada representa toda la variedad y riqueza de opciones presentes. Actualmente existen diferentes enfoques/tecnologías que aúnan una visión de tecnología optimizada, de necesidades de negocio y de incluso software específico para desplegar soluciones de Inteligencia de negocio.<br />Listemos alguna de ellas:<br />Inclusión de mapreduce en el software del data warehouse, que permite procesar grandes cantidades de datos distribuidas en clústers. Por ejemplo, en este punto tenemos a fabricantes como Greenplum o Aster Data Systems. Y empresas como Google o Facebook como usuarios destacados.<br />Soluciones in-memory, que despliegan estructuradas de datos multidimensionales en memoria con el objetivo de minimizar el tamaño de estructuras MOLAP así como agilizar la velocidad de consulta. Entre estos ejemplos tenemos Qlikview y Panopticon.<br />Estructuras multidimensionales.<br />Estructuras federadas de data marts.<br />Integración a tiempo real.<br />Data marts específicos.<br />Active Data Warehouse.<br />Soluciones que conjunta software y hardware optimizado (con algunas de las características comentadas). Por ejemplo, estamos hablando de fabricantes como Teradata o Kickfire.<br />Bases de datos híbridas (columnas y filas) que permiten beneficiarse de las características singulares tanto de desarrollos por filas o por columnas.<br />Es decir, estamos hablando de elementos que pueden formar parte de la arquitectura de un data warehouse. Y es por lo tanto necesario, en el momento de su diseño, tener una visión a corto, medio y largo plazo para no estar limitados a posteriori en nuestras necesidades de análisis de información. Me reafirmo: por lo que es importante, primero identificar las necesidades, plasmar qué tipo de arquitectura es la adecuada para las mismas y posteriormente ir a buscar la tecnología que resuelva nuestras necesidades.<br />Ventajas y Problemas de los almacenes de datos.<br />Beneficios de los almacenes de datos.<br />Algunos de los beneficios que proporciona un almacén de datos son los siguientes:<br />Un almacén de datos proporciona un modelo de datos común para todos los datos de interés independientemente de la fuente de los datos. Esto hace que sea más fácil informar y analizar la información de lo que sería si los modelos de datos múltiples se utilizan para recuperar información, tales como facturas de venta, recibos de orden, los cargos del libro mayor, etc.<br />Antes de cargar datos en el almacén de datos, las inconsistencias se identifican y resuelven. Esto simplifica enormemente la presentación de informes y análisis.<br />Información en el almacén de datos está bajo el control de los usuarios de almacenamiento de datos para que, incluso si el origen de datos del sistema se purga a través del tiempo, la información en el almacén se puede almacenar de forma segura durante períodos prolongados de tiempo.<br />Debido a que son independientes de los sistemas operativos, los almacenes de datos ofrecen la recuperación de datos sin ralentizar los sistemas operativos.<br />Los almacenes de datos pueden trabajar en conjunto con y, por tanto, aumentar el valor de las aplicaciones de negocio operativos, en particular la gestión de relaciones con clientes (CRM).<br />Los almacenes de datos facilitan la toma aplicaciones del sistema de apoyo, como informes de tendencias (por ejemplo, los elementos con la mayoría de las ventas en un área en particular en los últimos dos años), informes de excepción, y los informes que muestran el rendimiento real en comparación con los objetivos.<br />Son sistemas relativamente sencillos de instalar si las fuentes de datos y los objetivos están claros.<br />Muy útiles para el almacenamiento de análisis y consultas de históricos.<br />Problemas de los almacenes de datos.<br />También hay desventajas en el uso de un almacén de datos. Algunos de ellos son:<br />Los almacenes de datos no son el ambiente óptimo para los datos no estructurados.<br />Dado que los datos se deben extraer, transformar y cargar en el almacén, hay un elemento de la latencia en los datos de almacén de datos.<br />A lo largo de su vida los almacenes de datos pueden suponer altos costos. El almacén de datos no suele ser estático. Los costos de mantenimiento son elevados.<br />Los almacenes de datos se pueden quedar obsoletos relativamente pronto.<br />A veces, ante una petición de información estos devuelven una información subóptima, que también supone una pérdida para la organización.<br />A menudo existe una delgada línea entre los almacenes de datos y los sistemas operacionales. Hay que determinar qué funcionalidades de estos se pueden aprovechar y cuáles se deben implementar en el data warehouse, resultaría costoso implementar operaciones no necesarias o dejar de implementar alguna que sí vaya a necesitarse.<br />Arquitectura de los almacenes de datos.<br />Una arquitectura de Data Warehouse es una forma de representar la estructura global de los datos, la comunicación, los procesos y la presentación al usuario final. La arquitectura está constituida por las siguientes partes interconectadas:<br />Elementos que constituyen la arquitectura de un Data Warehouse<br />Explicamos uno a uno la función de cada nivel.<br />1. Base de datos operacional y base de datos externa<br />Las organizaciones adquieren datos de bases de datos externas a la propia organización, que incluyen datos demográficos, económicos, datos sobre la competencia, etc.<br />Mediante el proceso de data warehousing se extrae la información que está en la bases de datos operacionales y se mezcla con otras fuentes de datos. Enriquecemos la información.<br />2. Nivel de acceso a la información<br />Es la capa con la que trata el usuario final. La información almacenada se convierte en información fácil y transparente para las herramientas que utlizan los usuarios. Se obtienen informes, gráficos, diagramas, etc.<br />3. Nivel de acceso a los datos<br />Comunica el nivel de acceso a la información con el nivel operacional, es el responsable de la interfaz entre las herramientas de acceso a la información y las bases de datos.<br />La clave de este nivel está en proveer al usuario de un acceso universal a los datos, es decir, que los usuarios sin tener en cuenta la ubicación de los datos o la herramienta de acceso a la información, deberían ser capaces de acceder a cualquier dato del data warehouse que les fuera necesario para realizar su trabajo.<br />4. Nivel de directorio de datos (metadatos)<br />Para proveer de un acceso universal, es absolutamente necesario mantener alguna clase de directorio de datos o repositorio de información de metadato que ayude a mantener un control sobre los datos. El metadato aporta información sobre los datos de la organización, de dónde proviene, qué formato tenía, cuál era su significado y si se trata de un agregado, cómo se ha calculado éste.<br />Para mantener un almacén completamente funcional, es necesario disponer de una amplia variedad de metadatos, información sobre las vistas de datos para los usuarios finales y sobre las bases de datos operacionales.<br />5. Nivel de gestión de procesos<br />Este nivel tiene que ver con la planificación de las tareas que se deben realizar, no sólo para construir, sino también para mantener el data warehouse y la información del directorio de datos. Es o el controlador de alto nivel de los procesos que se han de llevar a cabo para que el data warehouse permanezca actualizado.<br />6. Nivel de mensaje de la aplicación<br />Este nivel es el encargado del transporte de la información a lo largo del entorno, se puede pensar en él como un middleware.<br />7. Nivel Data Warehouse (físico)<br />Es el núcleo del sistema, el repositorio central de información donde los datos actuales usados principalmente con fines informacionales residen. En el data warehouse físico se almacenan copias de los datos operacionales y/o externos, en una estructura que optimiza su acceso para la consulta y que es muy flexible.<br />8. Nivel de organización de datos<br />Incluye todos los procesos necesarios para seleccionar, editar, resumir, combinar y cargar en el data warehouse y en la capa de acceso a la información los datos operacionales y/o externos.<br />Estructura de un Data Warehouse<br />La estructura de un data warehouse se caracteriza por los diferentes niveles de esquematización y detalle de los datos que se encuentran en él.<br />1. Detalle de los datos actuales<br />Reflejan los acontecimientos más recientes, las últimas informaciones generadas por los sistemas de producción de la organización. El nivel de detalle no tiene por qué ser el mismo que el de los sistemas de producción, ya que los datos pueden ser fruto de alguna agregación o de una simplificación de los datos originales.<br />Una agregación es una partición horizontal de una relación según los valores de los atributos, seguida de una agrupación mediante una función de cálculo (suma, media, producto, etc.)<br />2. Detalle de datos antiguos<br />Están almacenados en un nivel de detalle consistente con los datos detallados actuales, esto significa que si los datos actuales hacen referencia a ventas diarias en el año actual, los datos historiados contienen las ventas de años anteriores en el nivel de detalle de día también.<br />3. Datos resumidos<br />Son datos obtenidos como resultado de un proceso de síntesis de los datos actuales. Lo que se tiene entonces son datos agregados o resumidos. Por ejemplo, se entiende mejor la evolución de las ventas si se la presenta resumida por semanas que de manera diaria.<br />4. Metadatos<br />Ofrecen información descriptiva sobre el contexto, la calidad, la condición y las características de los datos. El metadato se sitúa en una dimensión diferente a la de los otros datos en el data warehouse, debido a que su contenido no es tomado directamente desde el ambiente operacional.<br />Data Warehouse y las bases de datos operacionales.<br />En un Data Warehouse se almacena toda la información de interés para una organización que luego queramos analizar, mientras que, en una base de datos operacional se almacenan todas las transacciones de la organización, tanto datos útiles como no útiles.<br />Vamos a ver en qué se diferencian una base de datos operacional de un Data Warehouse:<br />AspectosBD operacionalData WarehouseObjetivoDe tipo operativo (operaciones del día a día)Análisis y toma de decisionesProcesoDe transacciones. Repetitivo y conocido.De consultas masivas. Puntual y no conocido.ActividadPredomina la actualizaciónPredomina la consultaRendimientoImportancia del tiempo de respuesta de la transacción instantáneaImportancia de la respuesta masiva.ExplotaciónExplotación de la información relacionada con la operativa de cada aplicaciónExplotación de toda la información interna y externa relacionada con el negocioVolatilidadActualizableCarga, pero no actualizaciónUsuariosUsuarios de perfiles medios o bajosUsuarios de perfiles altosOrganizaciónEstructura normalmente relacionalVisión multidimensionalGranularidadDatos generales desagregados, al detalleDatos en distintos niveles de detalle y agregaciónHorizonte histórico30 a 90 días5 a 10 añosPerspectivaImportancia del dato actualImportancia del dato históricoVolumen de datosPequeño/medio. Del orden del Mb a Gb.Medio/grande. Del orden del Gb a Tb.<br />Herramientas y Tecnologías de almacenes de datos.<br />OLAP<br />3522345109855OLAP es el acrónimo en inglés de procesamiento analítico en línea (On-Line Analytical Processing). Es una solución utilizada en el campo de la llamada Inteligencia empresarial (o Business Intelligence) cuyo objetivo es agilizar la consulta de grandes cantidades de datos. Para ello utiliza estructuras multidimensionales (o Cubos OLAP) que contienen datos resumidos de grandes Bases de datos o Sistemas Transaccionales (OLTP). Se usa en informes de negocios de ventas, marketing, informes de dirección, minería de datos y áreas similares.<br />La razón de usar OLAP para las consultas es la velocidad de respuesta. Una base de datos relacional almacena entidades en tablas discretas si han sido normalizadas. Esta estructura es buena en un sistema OLTP pero para las complejas consultas multitabla es relativamente lenta. Un modelo mejor para búsquedas (aunque peor desde el punto de vista operativo) es una base de datos multidimensional.<br />La principal característica que potencia a OLAP, es que es lo más rápido a la hora de ejecutar sentencias SQL de tipo SELECT, en contraposición con OLTP que es la mejor opción para operaciones de tipo INSERT, UPDATE Y DELETE.<br />Tipos de sistemas OLAP<br />Tradicionalmente, los sistemas OLAP se clasifican según las siguientes categorías:<br />ROLAP<br />Implementación OLAP que almacena los datos en un motor relacional. Típicamente, los datos son detallados, evitando las agregaciones y las tablas se encuentran normalizadas. Los esquemas más comunes sobre los que se trabaja son estrella ó copo de nieve, aunque es posible trabajar sobre cualquier base de datos relacional. La arquitectura está compuesta por un servidor de banco de datos relacional y el motor OLAP se encuentra en un servidor dedicado. La principal ventaja de esta arquitectura es que permite el análisis de una enorme cantidad de datos.<br />MOLAP<br />Esta implementación OLAP almacena los datos en una base de datos multidimensional. Para optimizar los tiempos de respuesta, el resumen de la información es usualmente calculado por adelantado. Estos valores precalculados o agregaciones son la base de las ganancias de desempeño de este sistema. Algunos sistemas utilizan técnicas de compresión de datos para disminuir el espacio de almacenamiento en disco debido a los valores precalculados.<br />HOLAP (Hybrid OLAP)<br />Almacena algunos datos en un motor relacional y otros en una base de datos multidimensional.<br />Comparación<br />Cada sistema OLAP tiene ciertos beneficios (aunque existe desacuerdo acerca de las características específicas de los beneficios entre los proveedores).<br />Algunas implementaciones MOLAP son propensas a la quot;
explosiónquot;
de la base de datos; este fenómeno provoca la necesidad de grandes cantidades de espacio de almacenamiento para el uso de una base de datos MOLAP cuando se dan ciertas condiciones: elevado número de dimensiones, resultados precalculados y escasos datos multidimensionales. Las técnicas habituales de atenuación de la explosión de la base de datos no son todo lo eficientes que sería deseable.<br />Por lo general MOLAP ofrece mejor rendimiento debido a la especializada indexación y a las optimizaciones de almacenamiento. MOLAP también necesita menos espacio de almacenamiento en comparación con los especializados ROLAP porque su almacenamiento especializado normalmente incluye técnicas de compresión.<br />ROLAP es generalmente más escalable. Sin embargo, el gran volumen de preprocesamiento es difícil de implementar eficientemente por lo que con frecuencia se omite; por tanto, el rendimiento de una consulta ROLAP puede verse afectado.<br />Desde la aparición de ROLAP van apareciendo nuevas versiones de bases de datos preparadas para realizar cálculos, las funciones especializadas que se pueden utilizar tienen más limitaciones.<br />HOLAP (OLAP Híbrido) engloba un conjunto de técnicas que tratan de combinar MOLAP y ROLAP de la mejor forma posible. Generalmente puede pre-procesar rápidamente, escala bien, y proporciona una buena función de apoyo.<br />Herramientas para el diseño de data warehouse<br />Software Data Warehouse.<br />Red Brick Warehouse.<br />Essbase.<br />Pilot Decission Support Suite.<br />Microsoft SQL Server.<br />Diseño de base de datos para un almacén de datos.<br />Para construir un Data Warehouse se necesitan herramientas para ayudar a la migración y a la transformación de los datos hacia el almacén. Una vez construido, se requieren medios para manejar grandes volúmenes de información. Se diseña su arquitectura dependiendo de la estructura interna de los datos del almacén y especialmente del tipo de consultas a realizar. Con este criterio los datos deben ser repartidos entre numerosos data marts. Para abordar un proyecto de data warehouse es necesario hacer un estudio de algunos temas generales de la organización o empresa, los cuales se describen a continuación:<br />Situación actual de partida.- Cualquier solución propuesta de data warehouse debe estar muy orientada por las necesidades del negocio y debe ser compatible con la arquitectura técnica existente y planeada de la compañía.<br />Tipo y características del negocio.- Es indispensable tener el conocimiento exacto sobre el tipo de negocios de la organización y el soporte que representa la información dentro de todo su proceso de toma de decisiones.<br />Entorno técnico.- Se debe incluir tanto el aspecto del hardware (mainframes, servidores, redes,...) así como aplicaciones y herramientas. Se dará énfasis a los Sistemas de soporte a decisiones (DSS), si existen en la actualidad, cómo operan, etc.<br />Expectativas de los usuarios.- Un proyecto de data warehouse no es únicamente un proyecto tecnológico, es una forma de vida de las organizaciones y como tal, tiene que contar con el apoyo de todos los usuarios y su convencimiento sobre su bondad.<br />Etapas de desarrollo.- Con el conocimiento previo, ya se entra en el desarrollo de un modelo conceptual para la construcción del data warehouse.<br />Prototipo.- Un prototipo es un esfuerzo designado a simular tanto como sea posible el producto final que será entregado a los usuarios.<br />Piloto.- El piloto de un data warehouse es el primero, o cada uno de los primeros resultados generados de forma iterativa que se harán para llegar a la construcción del producto final deseado.<br />Prueba del concepto tecnológico.- Es un paso opcional que se puede necesitar para determinar si la arquitectura especificada del data warehouse funcionará finalmente como se espera.<br />Esquema en estrella.<br />En las bases de datos usadas para data warehousing, un esquema en estrella es un modelo de datos que tiene una tabla de hechos (o tabla fact) que contiene los datos para el análisis, rodeada de las tablas de dimensiones. Este aspecto, de tabla de hechos (o central) más grande rodeada de radios o tablas más pequeñas es lo que asemeja a una estrella, dándole nombre a este tipo de construcciones.<br />Las tablas de dimensiones tendrán siempre una clave primaria simple, mientras que en la tabla de hechos, la clave principal estará compuesta por las claves principales de las tablas dimensionales<br />Esquema en copo de nieve<br />El esquema en copo de nieve (snowflake schema) es un esquema de representación derivado del esquema en estrella, en el que las tablas de dimensión se normalizan en múltiples tablas. Por esta razón, la tabla de hechos deja de ser la única tabla del esquema que se relaciona con otras tablas, y aparecen nuevas joins gracias a que las dimensiones de análisis se representan ahora en tablas de dimensión normalizadas.<br /> En la estructura dimensional normalizada, la tabla que representa el nivel base de la dimensión es la que hace join directamente con la tabla de hechos. La diferencia entre ambos esquemas (star y snowflake) reside entonces en la estructura de las tablas de dimensión. Para conseguir un esquema en copo de nieve se ha de tomar un esquema en estrella y conservar la tabla de hechos, centrándose únicamente en el modelado de las tablas de dimensión, que si bien en el esquema en estrella se encontraban totalmente denormalizadas, ahora se dividen en subtablas tras un proceso de normalización.<br />23704559963150984885 Es posible distinguir dos tipos de esquemas en copo de nieve, un snowflake completo (en el que todas las tablas de dimensión en el esquema en estrella aparecen ahora normalizadas en el snowflake) o un snowflake parcial (sólo se lleva a cabo la normalización de algunas de ellas).<br />Metodología de diseño de bases de datos para almacenes de datos.<br />Metodología ascendente (Bottom-up):<br />Ralph Kimball, un conocido autor y el almacenamiento de datos, es un defensor de un enfoque para el diseño de almacenamiento de datos que describe como de abajo hacia arriba.<br />En la de abajo hacia arriba enfoque datos marts son creados para proporcionar información y capacidad analítica para determinados procesos de negocio. Aunque es importante señalar que en la metodología de Kimball, el proceso de abajo-arriba es el resultado de un negocio inicial orientada hacia abajo el análisis de álbumes de la empresa los procesos pertinentes para ser modelada.<br />marts de datos contienen, en primer lugar, las dimensiones y hechos. Los hechos pueden contener datos atómicos y, en su caso, los datos resumidos. El mercado de datos única a menudo modelos de una zona de negocios específicos tales como quot;
ventasquot;
o quot;
producciónquot;
. Estos puestos de datos puede ser finalmente integradas para crear un almacén de datos global. La integración de los mercados de datos se gestiona a través de la aplicación de lo Kimball llama quot;
un almacén de datos de arquitectura de busquot;
.[6]. El almacén de datos arquitectura de bus es principalmente una aplicación de quot;
el autobúsquot;
, una colección de dimensiones conformes, que son dimensiones que se comparten (de una manera específica) entre los hechos en dos o más puestos de datos.<br />La integración de los mercados de datos en el almacén de datos se centra en las dimensiones conformes (que residen en quot;
el autobúsquot;
) que definen la posible integración quot;
puntosquot;
entre los data marts. La integración real de dos o más centros comerciales de datos se realiza mediante un proceso conocido como quot;
taladro a través dequot;
. Un taladro, a través de obras de agrupación (resumen) los datos a lo largo de las claves de las dimensiones (compartido) conformado por cada hecho que participan en el quot;
taladro a través dequot;
, seguido de una combinación de las teclas de estos agrupados (resumen) hechos.<br />Para mantener el manejo estricto de la arquitectura de bus de datos de almacén es fundamental para mantener la integridad del almacén de datos. La tarea de gestión más importante es hacer que las dimensiones de los mercados de datos son coherentes. En palabras de Kimball, esto significa que las dimensiones quot;
conformequot;
.<br />Algunos lo consideran una ventaja del método Kimball, que el almacén de datos termina siendo quot;
segmentadoquot;
en una serie de lógica autónoma (hasta e incluyendo el autobús) y data marts coherente, en lugar de un modelo centralizado a menudo complejas y grandes. El valor de negocio pueden ser devueltos lo más rápidamente que la primera data marts se pueden crear, y el método se da así a un enfoque exploratorio e iterativo para la construcción de almacenes de datos. Por ejemplo, el almacenamiento de datos esfuerzo podría comenzar en la quot;
ventaquot;
del departamento, mediante la construcción de un data mart-venta. Una vez finalizado el-data mart de ventas, el negocio podría decidir ampliar las actividades de almacenamiento en el, digamos, quot;
el departamento de producciónquot;
que resulta en un data mart de producción. El requisito para el data mart de ventas y el mercado de datos de producción para ser integrable, es que comparten el mismo quot;
Busquot;
, que será, que el almacenamiento de datos del equipo ha hecho el esfuerzo por identificar e implementar las dimensiones conformado en el autobús, y que los datos individuales marts vínculos que la información del autobús. Tenga en cuenta que esto no requiere 100% de la conciencia desde el inicio del esfuerzo de almacenamiento de datos, sin plan maestro se requiere por adelantado. -El data mart de ventas es buena como lo es (asumiendo que el autobús está completo) y el data mart de producción se puede construir prácticamente independiente de la data mart de ventas (pero no es independiente de la de autobuses).<br />Si la integración a través del bus se logra, el almacén de datos, a través de sus dos mercados de datos, no sólo será capaz de entregar la información específica que los mercados de datos individuales están diseñados para hacer, en este ejemplo o quot;
Ventasquot;
o información quot;
de producción”, pero puede entregar información integrada de ventas, de producción, que, a menudo, tiene un valor de negocio críticos. Una integración (posiblemente) a cabo de manera flexible e iterativo.<br />Metodología decendente (Top-down):<br />Bill Inmon, uno de los primeros autores sobre el tema del almacenamiento de datos, ha definido un almacén de datos como un repositorio centralizado para toda la empresa. Inmon es uno de los principales proponentes de la de arriba hacia abajo enfoque para el diseño de almacenamiento de datos, en el que el almacén de datos está diseñada con una empresa normalizada modelo de datos. quot;
Atomicquot;
de datos, es decir, los datos en el nivel más bajo de detalle, se almacenan en el data warehouse. data marts dimensionales que contienen los datos necesarios para los procesos de negocio específicos o departamentos específicos se crean a partir del almacén de datos. En la visión Inmon el almacén de datos está en el centro de la quot;
Fábrica de Información Corporativaquot;
(CIF), que proporciona un marco lógico para la entrega de Business Intelligence (BI) y gestión de capacidades empresariales.<br />Inmon indica que el almacén de datos es:<br />Asunto orientada <br />Los datos en el almacén de datos está organizada de manera que todos los elementos de datos relativos al mismo evento en el mundo real o el objeto están unidos entre sí.<br />No volátil <br />Los datos en el almacén de datos nunca son sobre-escrito o eliminado - una vez cometidos, los datos son estáticos y de sólo lectura, y conservados para la presentación de informes en el futuro.<br />Integrado <br />El almacén de datos contiene datos de la mayoría o la totalidad de los sistemas operativos de una organización y estos datos se hacen compatibles.<br />Tiempo de la variante<br />El diseño de la metodología abajo-arriba dimensiones genera opiniones muy consistente de datos a través de mercados de datos ya que todos los puestos de datos se cargan desde el repositorio centralizado. Comienzo de la página hacia abajo diseño también ha demostrado ser robusto frente a los cambios del negocio. Generación de nuevos puestos de datos dimensional frente a los datos almacenados en el almacén de datos es una tarea relativamente sencilla. La desventaja principal de la metodología de arriba hacia abajo es que representa un proyecto muy grande con un alcance muy amplio. El costo inicial para la implementación de un almacén de datos utilizando la metodología de arriba hacia abajo es importante, y la duración de tiempo desde el inicio del proyecto hasta el punto de que los usuarios experimentar los beneficios iniciales pueden ser considerables. Además, la metodología de arriba hacia abajo puede ser inflexible y no responde a las cambiantes necesidades de los departamentos durante las fases de ejecución.<br />Diseño híbrido:<br />Con el tiempo se ha hecho evidente que los defensores del diseño de almacenamiento de datos de abajo arriba y de arriba hacia abajo que ambas metodologías tienen beneficios y riesgos. Metodologías híbridas han evolucionado para aprovechar el rápido tiempo de vuelta del diseño de abajo hacia arriba y la consistencia de los datos en toda la empresa de diseño de arriba hacia abajo.<br />Conclusiones.<br />Provee un esquema de organización – cuáles son los componentes que la forman, cómo ellos se interrelacionan, quién es el dueño de cada parte y cuáles son las prioridades.<br />Mejora la flexibilidad – permite que rápidamente se añadan nuevas fuentes de datos.<br />Desarrollo rápido y reusó – los desarrolladores de DWH son más capaces de comprender el proceso de DWH, los contenidos de las bases de datos y las reglas del negocio más rápidamente.<br />Herramientas de comunicaciones – define y comunica la dirección y el alcance de las expectativas, identifica los roles y responsabilidades y comunica los requerimientos al proveedor.<br />