Gestión de Soluciones - II PDF

GESTIÓN DE SOLUCIONES - II IES Antonio Sequeros. Departamento de Informática. C.E. Inteligencia Artificial y Big Data. Big Data Aplicado. Curso 24/25. Bibliografía Aunque cada unidad de trabajo cuenta con su bibliografía específica, se han tomado como base los documentos distribuidos en el módulo de Big Data Aplicado, incluidos en la formación para el profesorado que imparte el curso de especialización “Inteligencia Artificial y Big Data” en Castilla - La Mancha, creado por la Escuela Superior de Informática de Ciudad Real de la Universidad de Castilla - La Mancha. I.E.S. Antonio Sequeros Telf.: 966 926 770 / 966 926 774 C/ Comunidad Valenciana, 57 Correo Electrónico: 03002445 @edu.gva.es 03160 Almoradí (Alicante) https://portal.edu.gva.es/iesantoniosequeros/ Gestión de Soluciones - II Capítulo 2 Julio Alberto López Gómez En este capítulo se profundizará en los almacenes de datos o Data Warehouses (DW) como solución propia de la inteligencia de negocio o Business Intelligence (BI). Esta solución aparece como respuesta al crecimiento de datos digitales alma- cenados por las empresas y la necesidad de extraer información y generar conoci- miento a partir de ellos para optimizar el proceso de toma de decisiones en cada uno de los departamentos o divisiones de la empresa. Para ello, en este capítulo se aborda el concepto de almacén de datos, su arquitectura así como su diseño e implementación. 2.1. Sistemas de ayuda a la decisión En una empresa u organización, los datos generados a diario son, principal- mente, aquellos derivados de las operaciones rutinarias de la empresa. Estos datos, tradicionalmente, se almacenaban en bases de datos relacionales y su manipu- lación se correspondía con transacciones realizadas sobre la base de datos. Sin embargo, el objetivo de cualquier organización es seleccionar esos datos para rea- lizar estudios y análisis que permitan generar informes que, a su vez, permitan a la empresa extraer información para tomar decisiones estratégicas que conduzcan a la organización al éxito. El crecimiento exponencial de los datos manejados por una organización ha he- cho que los computadores sean las únicas herramientas capaces de procesar estos datos para obtener información y ofrecer ayuda en la toma de decisiones. En este contexto, aparecen los sistemas de ayuda a la decisión o Decision Support Sys- tems (DSS) que ayudan a quienes ocupan puestos de gestión a tomar decisiones o elegir entre diferentes alternativas (ver [GR09]). 17 Capítulo 2 :: Gestión de Soluciones - II Sistema de ayuda a la decisión: Conjunto de técnicas y herramientas tecno- lógicas desarrolladas para procesar y analizar datos para ofrecer soporte en la toma decisiones a quienes ocupan puestos de gestión o dirección en una orga- nización. Para ello, el sistema combina los recursos de los gestores junto con los recursos computacionales para optimizar el proceso de toma de decisiones. Mientras que las bases de datos relacionales han sido tradicionalmente el com- ponente del back-end en el diseño de sistemas de ayuda a la decisión, los almacenes de datos se han convertido en una opción mucho más competitiva como elemento back-end al mejorar el rendimiento de éstas. Los campos de aplicación de los almacenes de datos no se reducen únicamen- te al ámbito empresarial, sino que cubren multitud de dominios como las ciencias naturales, demografía, epidemiología o educación, entre otros muchos. La pro- piedad común a todos estos campos y que hace de los almacenes de datos una adecuada solución en estos ámbitos es la necesidad de almacenamiento y he- rramientas de análisis que permitan obtener en tiempos razonables informa- ción y conocimiento útiles para mejorar el proceso de toma de decisiones (ver [GR09]). 2.2. Almacenes de datos: Concepto La aparición de los almacenes de datos está ligada, principalmente, a una serie de retos que es necesario abordar para convertir los datos transaccionales con los que trabaja una base de datos relacional en información para generar conoci- miento y dar soporte al proceso de toma de decisiones (ver [GR09]). Accesibilidad: Desde cualquier dispositivo, a cualquier tipo de usuario y a gran cantidad de información que no puede ser almacenada de forma centra- lizada. La accesibilidad, en este sentido, debe hacer frente al problema de la escalabilidad del sistema y de los datos que este maneja. Integración: Referente a la gestión de datos heterogéneos, con distintos for- matos, y provenientes de distintos ámbitos de la organización. Una correcta integración debe garantizar a su vez la corrección y completitud de los datos integrados. Consultas mejoradas: Permitiendo incluir operadores avanzados y dar so- porte a herramientas y procedimientos que posibiliten obtener el máximo partido de los datos existentes. De este modo, será posible obtener informa- ción precisa para realizar un análisis eﬁciente. Representación multidimensional: Proporciona herramientas para analizar de forma multi-dimensional los datos del sistema, incluyendo datos de di- ferentes unidades de la organización con el objetivo de proporcionar he- rramientas de análisis y visualización multi-dimensional para mejorar el proceso de toma de decisiones. 2.2. Almacenes de datos: Concepto A continuación, se muestra una deﬁnición de almacén de datos muy exten- dida, dada por W. Inmon, quien es conocido por ser el “padre” del concepto de almacén de datos. Almacén de datos (Data Warehouse): Colección de datos orientados a temas, integrados, variante en el tiempo y no volátil que da soporte al proceso de toma de decisiones de la dirección (ver [Inm02]). Para entender correctamente esta deﬁnición, es necesario ahondar en las carac- terísticas que incluye la misma (ver [PVMCV06]). Orientados a temas: Es decir, no orientado a procesos (transacciones), sino a entidades de mayor nivel de abstracción como “artículo” o “pedido”. Integrados: Almacenados en un formato uniforme y consistente, lo que implica depurar o limpiar los datos para poder integrarlos. Variante en el tiempo: Asociados a un instante de tiempo (mes, trimestre, año...) No volátiles: Se trata de datos persistentes que no cambian una vez se in- cluyen en el almacén de datos. El diseño y funcionamiento de los almacenes de datos se basa en el sistema de pro- cesamiento analítico en-línea, OLAP. Este sistema se encarga del análisis, inter- pretación y toma de decisiones acerca del negocio, en contraposición a los sistemas de procesamiento de transacciones en línea, OLTP. Este sistema es encarnado por las bases de datos operacionales, las cuales ejecutan las transacciones de procesos operacionales del día a día. Así pues, los sistemas OLTP están dirigidos por la tecnología y orientados a automatizar las operaciones del día a día de la organización, mientras que los sistemas OLAP están dirigidos por el negocio y proporcionan herramientas para tomar decisiones a largo plazo, mejorando la estrategia y la competitividad de la organización (ver [PVMCV06]). La tabla 2.1 muestra una comparativa entre las principales características de las bases de datos operacionales (OLTP) y los almacenes de datos (OLAP). Capítulo 2 :: Gestión de Soluciones - II Tabla 2.1: Diferencias entre BBDD Operacionales y Almacenes de Datos (ver [GR09]). Característica BBDD Operacionales Almacén Datos Depende de Objetivo Toma de decisiones la aplicación Usuarios Miles Cientos Transacciones Consultas y análisis Trabaja con... predeﬁnidas especíﬁcos Lectura y escritura Principalmente lecutra. Acceso a cientos de registros Miles de registros Detallados, numéricos Agregados, Datos y alfanuméricos principalmente numéricos En función de la Basados en temas, con Integración aplicación mayor nivel de abstracción Medida en términos Medida en términos Calidad de integridad de consistencia Temporalidad Solo datos Datos actuales e Datos actuales históricos Actualizaciones Continuas Periódicas Desnormalizado, Modelo Normalizado multidimensional Para acceso OLTP a Para acceso OLAP a Optimización parte de la BBDD gran parte de la BBDD 2.3. Almacenes de datos: Arquitectura Las arquitecturas disponibles para el diseño de almacenes de datos se basan, principalmente, en garantizar que el sistema cumpla una serie de propiedades esen- ciales para su óptimo funcionamiento (ver [JVVL03] y [GR09]). Separación: De los datos transaccionales y los datos estratégicos que sirven como punto de partida a la toma de de decisiones. Escalabilidad: A nivel hardware y software, para actualizarse y garantizar el correcto funcionamiento del sistema a medida que el número de datos y usuarios aumenta. Extensiones: Permitiendo integrar e incluir nuevas aplicaciones sin necesi- dad de rediseñar el sistema completo. Seguridad: Monitorizando el acceso a los datos estratégicos guardados en el almacén de datos. Las arquitecturas de almacenes de datos se clasiﬁcan, fundamentalmente, en dos tipos: arquitecturas orientadas a la estructura y arquitecturas orientadas a la empresa. 2.3. Almacenes de datos: Arquitectura 2.3.1. Arquitecturas orientadas a la estructura Las arquitecturas orientadas a la estructura reciben su nombre debido a que están diseñadas poniendo especial énfasis en el número de capas y elementos que componen la arquitectura del sistema de almacén de datos. De acuerdo con este criterio, es posible distinguir las siguientes arquitecturas (ver [JVVL03],[MTK06], [GR09]). Arquitectura de una capa El objetivo principal de esta arquitectura, poco utilizada en la práctica, es mi- nimizar la cantidad de datos almacenados eliminando para ello los datos re- dundantes. La ﬁgura 2.1 muestra un esquema de este tipo de arquitectura. En ella, el almacén de datos creado es virtual, existiendo un middleware que interpreta los datos operacionales y ofrece una vista multidimensional de ellos. El principal inconveniente de esta arquitectura es que su simplicidad hace que el sistema no cumpla la propiedad de separación, ya que los procesos de análisis se realizan sobre los datos operacionales. Figura 2.1: Almacén de datos. Arquitectura de una capa. Capítulo 2 :: Gestión de Soluciones - II Arquitectura de dos capas Fue diseñada con el objetivo de solucionar el problema de la separación que presentaba la arquitectura de una capa. Este esquema consigue subrayar la sepa- ración entre los datos disponibles y el almacén de datos a través de los siguientes componentes (ver ﬁgura 2.2): Capa de origen (fuente): Se corresponde con los orígenes y fuentes de los datos heterogéneos que se pretenden incorporar al almacén de datos. Puesta a punto: Proceso por el cual se utilizan herramientas de Extracción, Transformación y Carga (ETL) para extraer, limpiar, ﬁltrar, validar y cargar datos en el almacén de datos. Capa de almacén de datos: Almacenamiento centralizado de la información en el almacén de datos, el cual puede ser utilizado para crear data marts o repositorios de metadatos. Análisis:. Conjunto de procesos a partir de los cuales los datos son eﬁciente- mente y ﬂexiblemente analizados, generando informes y simulando escena- rios hipotéticos para dar soporte a la toma de decisiones. Un Data mart es un subconjunto o agregación de los datos almacenados en un almacén de datos primario que incluye información relevante sobre un área especíﬁca del negocio (ver [PVMCV06], [GR09]). Arquitectura de tres capas Este tercer tipo de arquitectura incluye una capa llamada de datos reconcilia- dos o almacén de datos operativos. Con esta capa, los datos operativos obtenidos tras la limpieza y depuración son integrados y validados, proporcionando un mo- delo de datos de referencia para toda la organización. De este modo, el almacén de datos no se nutre de los datos de origen directamente, sino de los datos re- conciliados generados, los cuales también son utilizados para realizar de forma más eﬁciente tareas operativas, como la realización de informes o la alimentación de datos a procesos operativos. La ﬁgura 2.3 muestra de forma gráﬁca este tipo de arquitectura. Esta capa de datos reconciliados también puede implementarse de forma virtual en una arquitectura de dos capas, ya que se deﬁne como una vista integrada y coherente de los datos de origen. 2.3.2. Arquitecturas orientadas a la empresa Esta clasiﬁcación distingue cinco tipos de arquitecturas que combinan las capas mencionadas en la primera clasiﬁcación para diseñar almacenes de datos (ver [JVVL03], [GR09]). 2.3. Almacenes de datos: Arquitectura Figura 2.2: Almacén de datos. Arquitectura de dos capas. Arquitectura de data marts independientes Arquitectura preliminar en la que los distintos data marts son diseñados de forma independiente y construidos de forma no integrada. Suele utilizarse en los inicios de implementación de proyectos de almacenes de datos y reemplazada a medida que el proyecto va creciendo. Arquitectura en bus Similar a la anterior, asegura la integración lógica de los data marts creados, ofreciendo una visión amplia de los datos de la empresa y permitiendo realizar análisis rigurosos de los procesos que en ella se llevan a cabo. Capítulo 2 :: Gestión de Soluciones - II Figura 2.3: Almacén de datos. Arquitectura de tres capas. Arquitectura hub-and-spoke (centro y radio) Esta arquitectura es muy utilizada en almacenes de datos de tamaños medio y grande. Su diseño pone especial énfasis en garantizar la escalabilidad del siste- ma y permitir añadir extensiones al mismo. Para ello, los datos se almacenan de forma atómica y normalizada en una capa de datos reconciliados que alimenta a los data marts construidos que contienen, a su vez, los datos agregados de for- ma multidimensional. Los usuarios acceden a los data marts, si bien es cierto que también pueden hacer consultas directamente sobre los datos reconciliados. Arquitectura centralizada Se trata de un caso particular de la arquitectura hub-and-spoke. En ella, la capa de datos reconciliados y los data marts se almacenan en un único repositorio físico. 2.4. Almacenes de datos: Diseño e implementación Arquitectura federada Se trata de un tipo de arquitectura muy utilizada en entornos dinámicos, cuando se pretende integrar almacenes de datos o data marts existentes con otros para ofrecer un entorno único e integrado de soporte a la toma de deci- siones. De esta forma, cada almacén de datos y cada data mart es integrado virtual o físicamente con lo demás. Para ello, se utilizan una serie de técnicas y herramien- tas avanzadas como son las ontologías, consultas distribuidas e interoperabilidad de metadatos, entre otras. 2.4. Almacenes de datos: Diseño e implementación En esta sección se profundizará en cada una de las etapas necesarias para diseñar e implementar un almacén de datos. Para ello, en primer lugar se des- cribirá el proceso de Extracción, Transformación y Carga (ETL), fundamental para construir y alimentar un almacén de datos. Después, se desarrollarán dos de los diseños más extendidos de almacén de datos: el diseño en estrella y el diseño en copo de nieve. 2.4.1. El proceso de Extracción, Transformación y Carga (ETL) El proceso ETL es el encargado de extraer, limpiar e integrar los datos pro- venientes de las fuentes de datos para alimentar el almacén de datos. Este pro- ceso también es el encargado de de alimentar la capa de datos reconciliados en la arquitectura de tres capas. El proceso ETL tiene lugar cuando se puebla el alma- cén de datos y se lleva a cabo cada vez que el almacén de datos se actualiza. A continuación, se describen detalladamente cada una de las fases de las que consta este proceso (ver [KR02],[MTK06] ,[GR09]). Extracción Etapa que consiste en la lectura de los datos de las distintas fuentes de las que provienen. Cuando un almacén de datos se rellena por primera vez, se suele utilizar la técnica de extracción estática, la cual consiste en extraer una instantánea de los datos operacionales. A partir de entonces, se utiliza la extracción incremental para actualizar periódicamente los datos del almacén de datos, recogiendo los cambios aplicados desde la última extracción. Para ello, se utiliza el registro mantenido por el SGBD que, por ejemplo, asocia una marca de tiempo (timestamp) a los datos operacionales para registrar cuando fueron modiﬁcados y agilizar el proceso de extracción. En la actualidad, existe una gran cantidad de conjuntos de datos o data sets públicos, conocidos bajo el nombre de Open Data, que abarcan una gran cantidad de dominios y con los que es posible trabajar para construir soluciones big data. Capítulo 2 :: Gestión de Soluciones - II Open Data: Se trata de datos que han sido generados por una fuente en parti- cular, que abarcan un dominio temático o disciplinar y tienen atributos, dentro de los cuales está la frecuencia de actualización. Además, cuentan con una licencia especíﬁca que indica las condiciones de reutilización de los mismos. La fuente de los datos es en muchos de los casos el estado nacional, pro- vincial, municipal u organizaciones comerciales. En otras ocasiones, la fuente de los datos es fruto del estudio o medición por parte de particulares. Los atribu- tos de los conjuntos de datos deben especiﬁcar cómo fueron obtenidos, incluyendo fechas de obtención, actualización y validez, así como el público involucrado, la metodología de recogida o muestreo, etc. Algunas de las fuentes más utilizadas en la actualidad para la obtención de datos abiertos provienen de los centros nacionales e internacionales de estadís- ticas, como son el Instituto Nacional de Estadística de España (INE)1 , eurostat2 , la oﬁcina europea de estadísticas, la Organización Mundial de la Salud (OMS)3... Por otra parte, existen repositorios públicos de datos abiertos y a disposición de los usuarios como UCI4 o Kaggle5 , que es una comunidad de cientíﬁcos de datos donde empresas y organizaciones suben sus datos y plantean problemas que son resueltos por los miembros de la comunidad. La ﬁgura 2.4 muestra las fuentes de datos que se acaban de mencionar. Figura 2.4: Fuentes para la obtención de datos abiertos. 1 https://www.ine.es 2 https://ec.europa.eu/eurostat 3 https://www.who.int/es/data/gho/publications/world-health-statistics 4 https://archive.ics.uci.edu/ml/index.php 5 https://www.kaggle.com 2.4. Almacenes de datos: Diseño e implementación Transformación La etapa de transformación es la fase clave para transformar los datos opera- tivos en datos con un formato especíﬁco para alimentar un almacén de datos. En esta etapa, los datos se limpian y se transforman, añadiéndoles contexto y signiﬁcado. En caso de implementar un almacén de datos siguiendo una arquitec- tura de tres capas, el proceso de transformación es el encargado de obtener la capa de datos reconciliados. Si bien es cierto que algunos autores separan la lim- pieza y la transformación de los datos en dos etapas distintas, en este capítulo se considerarán ambas dentro de la fase de transformación. La etapa de transformación engloba todos los procesos de limpieza y manipu- lación de los datos, con el objetivo de transformar los datos operativos propios de sistemas relacionales (OLTP) en datos preparados para ser incluidos dentro del almacén de datos (OLAP). La limpieza de los datos o data cleaning engloba todos aquellos procedimien- tos necesarios para detectar y resolver situaciones problemáticas con los datos de partida que pudieran suponer problemas potenciales a la hora de analizarlos. Así pues, los datos de partida pueden ser incompletos, es decir, pueden contener atri- butos sin valor o valores agregados, incorrectos que incluyan errores o valores sin ningún signiﬁcado, lo cual es común cuando los datos se introducen manualmente en el sistema, o inconsistentes cuando los cambios no son propagados a todos los módulos del sistema, los rangos de un determinado atributo son cambiantes, existen datos duplicados... Otra tarea muy importante que se debe abordar en la fase de limpieza es la gestión de los datos perdidos. Se trata de datos que no están disponibles para algunas de las variables en alguna instancia. Esto puede ser debido, por ejemplo, a que no se registraran las modiﬁcaciones sufridas por los datos, se produjera un mal funcionamiento del equipo, los datos nunca fueron rellenados o no existían en el momento en que fueron completados, se eliminaron por ser inconsistentes con la información registrada... En general, se distinguen dos tipos de situaciones cuando existen valores perdidos: datos perdidos completamente aleatorios y datos perdidos de forma no completamente aleatoria. En el segundo caso, puede ser interesante intentar analizar la razón de la pérdida de los datos, la cual puede ser indicativa. En muchas ocasiones, los valores perdidos tienen relación con un subconjunto de variables predictoras y no se encuentran aleatoriamente distribuidos por todas ellas. Por todo ello, las aproximaciones más comunes a la hora de gestionar datos perdidos son: Capítulo 2 :: Gestión de Soluciones - II Eliminación de instancias que contengan valores perdidos: consiste en establecer un porcentaje umbral de tal forma que, si una instancia contiene un número de valores perdidos que supera este porcentaje, la instancia se descarta. Se trata de una técnica útil cuando el conjunto de datos es grande y el número de instancias con valores perdidos no es muy elevado. No obstante, esta estrategia se debe utilizar con precaución, ya que puede suponer una excesiva pérdida de información si el conjunto de datos no es muy grande, el número de instancias con valores perdidos es alto o el porcentaje umbral es muy pequeño. Asignación de valores ﬁjos: consiste en asignar un valor ﬁjo a todos los valores perdidos de todas las variables. Este valor puede ser el número 0 o incluso un valor desconocido Unknown o no numérico (NaN, Not a Number) en función del lenguaje de programación utilizado. Asignación de valores de referencia: asigna un valor de referencia a los valores perdidos para cada variable. Estos valores de referencia suelen ser medidas de centralización como la media o la mediana de los valores de cada variable. Imputación de valores perdidos: consiste en la aplicación de técnicas más soﬁsticadas, como pueden ser técnicas estadísticas o de aprendizaje automá- tico para predecir o averiguar los valores que se han perdido. Finalmente, la etapa de limpieza de datos también se encarga de la detección de valores anómalos o outliers. Se trata de valores que se han introducido de forma errónea o bien a una deformación en la distribución de valores. El proceso de de- tección de anomalías consiste, fundamentalmente, en dos etapas: en primer lugar, asumir que existe un modelo generador de datos, como podría ser una distribu- ción de probabilidad. En segundo lugar, considerar que las anomalías representan un modelo generador distinto, que no coincide con el original. Existen multitud de técnicas para detectar y descartar o imputar valores anómalos, como lo son téc- nicas estadísticas basadas en la desviación y el rango intercuartílico o técnicas de aprendizaje automático. Después de la etapa de limpieza, comienza la etapa de transformación. En ella, los datos se preparan para su carga en el almacén de datos. Para ello, se transforma- rán los datos provenientes de sistemas transaccionales OLTP en datos preparados para su análisis OLAP. A continuación, se muestran algunos de los procesos de transformación más comunes: Estandarización de códigos y formatos de representación: incluye tareas como transformar la información EBCDIC a formato ASCII o Unicode, con- vertir números cardinales en ordinales o viceversa, homogeneización y tra- tamiento de fechas, expandir codiﬁcaciones añadiendo textos descriptivos, uniﬁcación de códigos (sexo, estado civil, etc) y estándares (medidas, mone- das, etc). 2.4. Almacenes de datos: Diseño e implementación Conversiones y combinaciones de campos: realización de agregaciones y cálculos simples (importe neto, beneﬁcio, realización de cuentas y prome- dios), cálculos derivados con valores numéricos y textuales... Correcciones: en caso de que no se pudiera hacer en el origen o en la eta- pa de limpieza, se deben corregir errores tipográﬁcos, datos sin sentido ni signiﬁcado, resolver conﬂictos de dominio de variables, aclaración de datos ambiguos y asignación de valores a datos nulos. Integración de varias fuentes: implica la resolución de claves y utilización de diccionarios de datos y repositorios de metadatos para el diseño del alma- cén de datos. Eliminación de datos y/o registros duplicados: frecuente cuando se trabaja con distintas fuentes de datos provenientes de diferentes dimensiones o de- partamentos de la organización. Para ello, es muy útil el uso de funciones de búsqueda y agrupamiento aproximado. Escalado y centrado: para reducir los efectos adversos de contar con datos dispersos, es muy útil utilizar técnicas para escalar y centrar los datos. Una posible transformación consiste en restar a cada valor de cada instancia el valor medio de la variable correspondiente y después dividir los valores por la desviación estándar. De esta forma, los valores se escalan y se centran en- torno al cero. Esta transformación también puede hacerse entorno al valor de la media o la mediana. También es posible escalar los valores en el intervalo [0−1] o aplicar el logaritmo, para reducir la dispersión de los datos y mejorar la visualización. Discretización: la aplicación de muchas técnicas de aprendizaje automático requiere que los valores de las variables sean discreto, en lugar de continuos. La discretización es el proceso por el cual se divide un intervalo de valores continuos en tantos fragmentos como etiquetas o valores discretos se quieran asignar, sustituyendo los valores originales por la etiqueta o valor discreto correspondiente. Selección de características: permite reducir el coste computacional de tra- bajar con todas las variables del conjunto de datos cuando, en muchas ocasio- nes, existen variables que no aportan información para el aprendizaje. Ade- más de reducir el coste computacional, se reduce el número de dimensiones del conjunto de datos, mejorando la visualización y mejorando el rendimien- to de los modelos no solo en términos de tiempo, sino también de rendi- miento, puesto que existen métodos de aprendizaje cuyo rendimiento es peor cuando se ejecutan utilizando variables no signiﬁcativas. Capítulo 2 :: Gestión de Soluciones - II Carga Se trata de la última fase de cara a incluir datos en el almacén de datos. La carga inicial de los datos puede requerir bastante tiempo al cargar de forma progresiva todos los datos históricos, por lo que es normal realizarla en horas de baja carga de los sistemas. Una vez que el almacén de datos ha sido inicial- mente cargado, las sucesivas cargas de datos se pueden realizar de dos formas (ver [GR09]): Refresco: El almacén de datos se reescribe completamente, de forma que se reemplazan los datos antiguos. El refresco es utilizado habitualmente junto con la extracción estática y suele ser una estrategia muy utilizada para la carga inicial del almacén de datos, aunque puede también realizarse a posteriori. Actualización: Se añaden al almacén de datos solamente aquellos datos nuevos que se pretenden incluir, sin eliminar ni modiﬁcar los datos ya existentes. Esta técnica es utilizada frecuentemente junto con la extrac- ción incremental para actualizar regularmente el almacén de datos. Se trata de una estrategia de carga compleja de diseñar, ya que requiere que sea eﬁ- ciente computacionalmente. Para ello, se requieren mecanismos de detección del cambio como aquellos basados en la marca de tiempo (timestamp) o la utilización de tablas de log, entre otros. Frameworks ETL Recientemente, han aparecido múltiples frameworks que ofrecen herramientas tecnológicas para dar un soporte integrado al proceso ETL. A continuación, se des- criben algunos de los más utilizados: Bubbles (http://bubbles.databrewery.org): Se trata de un framework ETL escrito en Python, aunque es posible utilizarlo desde otros lenguajes. Ofre- ce un marco de trabajo sencillo, donde el proceso ETL se describe como una secuencia de nodos conectados que representan los datos y las distintas operaciones que se pueden realizar con ellos. De esta forma, es posible cons- truir un grafo que implemente el proceso ETL completo para un conjunto de datos. Apache Camel (https://camel.apache.org): Este framework escrito en len- guaje Java y de acceso abierto se enfoca en facilitar la integración entre dis- tintas fuentes de datos, haciendo el proceso más accesible a los desarrollado- res, ofreciendo disitntas herramientas para dar soporte al proceso ETL. Keetle (https://community.hitachivantara.com/s/article/data-integration-kettle): Es el framework de Pentaho para dar soporte al proceso ETL. Pentaho es una suite o conjunto de programas para construir soluciones de inteligencia de negocio y Keetle es su entorno de trabajo ETL. Similar a Bubbles, ofrece un entorno de trabajo sencillo para implementar un proceso ETL a través de nodos y conexiones entre ellos. Además, Keetle es de acceso abierto. 2.4. Almacenes de datos: Diseño e implementación 2.4.2. Diseño en Estrella A la hora de diseñar un almacén de datos, existen dos alternativas ampliamente utilizadas: el diseño en estrella, que promueve el diseño directo de estructuras lógicas sobre el modelo relacional, y el diseño en copo de nieve, como variante del diseño en estrella. El proceso de desarrollo de un almacén de datos siguiendo el diseño en estrella puede estructurarse según las siguientes fases (ver [KR02],[PVMCV06]): 1. Elegir un proceso de negocio a modelar: cualquier proceso de negocio puede ser modelado como un almacén de datos. No obstante, serán de espe- cial interés aquellos procesos necesarios para la toma de decisiones y que involucran a diferentes unidades de la organización. 2. Escoger la granularidad del proceso de negocio: Los datos almacenados en el almacén de datos deben expresarse siempre al mismo nivel de deta- lle. Por este motivo es necesario escoger un nivel de granularidad al comien- zo del diseño del almacén de datos. En caso de que se pretenda almacenar información relevante con distintos niveles de granularidad, esta información deberá almacenarse de forma separada. 3. Selección de medidas/hechos: indican qué se necesita medir o evaluar en el proceso de negocio con el ﬁn de dar respuesta a las necesidades de infor- mación y toma de decisiones por las cuales se pretende diseñar el almacén de datos. Por tanto, constituyen qué se quiere analizar. Las medidas/hechos son numéricas y es posible agregarlas a distintos niveles de detalle. Por ejem- plo, en el ámbito logístico las medidas podrían ser las unidades aceptadas o devueltas, mientras que en el ámbito del control de calidad podrían ser las unidades producidas, defectuosas, costo de la producción. 4. Elegir las dimensiones que se aplicarán a cada medida o hecho: las di- mensiones especiﬁcan las distintas propiedades de las medidas o hechos que se pretenden almacenar e integrar dentro del almacén de datos. Por ejemplo, si las medidas seleccionadas están relacionadas con las ventas de una determinada empresa, las dimensiones podrían ser: fecha de la venta, vendedor ,cliente, producto... A la hora de diseñar el almacén de datos siguiendo el diseño en estrella, se crea una tabla central, también llamada tabla de hechos, tabla factual o fact table. Esta tabla es la que posee los datos (medidas o hechos) sobre las diferentes combinaciones de las dimensiones. En algunas ocasiones, un diseño en estrella pre- senta más de una tabla de hechos. Los hechos introducidos pueden ser de distintos tipos: completamente aditivos (total de ventas de un departamento), no aditivos (márgen de beneﬁcios expresado como porcentaje) o semiaditivos (como datos in- termedios que pueden agregarse con datos de otras dimensiones). Capítulo 2 :: Gestión de Soluciones - II Rodeando a la tabla de hechos, se encuentra una tabla por cada una de las di- mensiones deﬁnidas. La clave primaria de la tabla de hechos se crea combinando las claves primarias de sus dimensiones relacionadas, de forma que está compuesta por las claves ajenas de las tablas de dimensiones que relaciona. De esta forma, la tabla de hechos presenta una relación del tipo “muchos a muchos” entre todas las tablas de dimensiones que relaciona, a la vez que una relación “muchos a uno” con cada tabla de dimensión por separado. Este esquema con forma de estrella da nombre a este tipo de diseño (ver [KR02],[MTK06]). Sea un almacén de datos en el que se pretende almacenar las ventas llevadas a cabo en una organización. La tabla central de hechos representa los datos de cada venta, mientras que las dimensiones que rodean a la tabla central recogen datos sobre los productos vendidos, la fecha de la venta, el canal de distribución y el lugar de entrega. La ﬁgura 2.5 muestra un ejemplo de este esquema de almacén de datos. DIMENSIÓN TEMPORAL Clave Tiempo Nivel Tiempo Semana Mes Año DIMENSIÓN TABLA HECHOS DIMENSIÓN GEOGRÁFICA (VENTAS) PRODUCTO Clave Geográﬁca Clave Producto Clave Producto Nivel Geográﬁco Clave Geográﬁca Nivel Producto Desc. Geográﬁca Clave Canal Desc. Producto Tamaño Geográﬁca Clave Temporal Tamaño Producto Tamaño Área Color Ventas Demografía Almacén Clase Inventario Distrito Departamento Región Coste División DIMENSIÓN CANAL Clave Canal Nivel Canal Descripción Canal Figura 2.5: Ejemplo de almacén de datos diseñado en estrella. Entre las ventajas del diseño en estrella, destaca ser un diseño fácil de modiﬁ- car que proporciona tiempos rápidos de respuesta, simpliﬁcando la navegación de los medatadatos. Además, este diseño permite simular vistas de los datos que obtendrán los usuarios ﬁnales y facilita la interacción con otras herramientas. 2.4. Almacenes de datos: Diseño e implementación Sin embargo, el diseño en estrella presenta algunos inconvenientes que surgen, por ejemplo, cuando se combinan dimensiones con distintos niveles de detalle. Además, cuando se pretende limitar los niveles de una dimensión se debe añadir un campo de nivel o utilizar un modelo de tipo constelación, donde se incluyen diferentes estrellas que almacenan tablas de hechos agregadas, lo cual añade com- plejidad al esquema. El diseño en estrella permite crear un almacén de datos con una estructura centralizada. El diseño se compone de una tabla de hechos central, que recoge los valores de las medidas del proceso de negocio que se pretende modelar. Rodeando a la tabla de hechos, se incluyen tantas tablas como dimensiones se hayan especiﬁcado en el modelo, las cuales se relacionan entre sí a través de la tabla de hechos. 2.4.3. Diseño en Copo de Nieve Otro de los diseños más extendidos a la hora de implementar un almacén de datos es el diseño en copo de nieve. De hecho, el diseño de copo de nieve es consi- derado una variante o derivado del diseño en estrella y, por tanto, puede construirse a partir de este siguiendo las mismas etapas que se describieron en la sección ante- rior. Este diseño es muy utilizado cuando se dispone de tablas de dimensión con una gran cantidad de atributos. En esta circunstancia, el diseño de copo de nie- ve permite normalizar las tablas de dimensión, ofreciendo un mejor rendimiento cuando las consultas realizadas sobre el almacén de datos requieren del uso de ope- radores de agregación. De esta forma, la tabla de hechos deja de ser la única tabla que presenta relaciones con las demás, apareciendo nuevas relaciones que se dan entre las tablas normalizadas que componen las tablas de dimensiones. Este es- quema, que incluye ramiﬁcaciones en cada dimensión que se corresponden con las tablas necesarias para su normalización, guarda un gran parecido con la estructura de un copo de nieve, lo cual da nombre a este diseño (ver [KR02], [MTK06]). La diferencia entre los diseños en estrella y copo de nieve radica funda- mentalmente en la modelización de las tablas de dimensiones. Para obtener un diseño en copo de nieve, basta con partir de un diseño en estrella en el que, tras un proceso de normalización, se obtienen varias tablas de dimensión a partir de una ta- bla desnormalizada. Dentro del diseño de copo de nieve, es posible distinguir entre copo de nieve parcial, en el que solo algunas de las dimensiones son normalizadas y copo de nieve completo, en el que todas las dimensiones del esquema son nor- malizadas (ver [JVVL03],[PVMCV06]). Capítulo 2 :: Gestión de Soluciones - II Siguiendo con el ejemplo anterior, en el que se mostraba un almacén de datos para representar las ventas realizadas por una organización, la ﬁgura 2.6 muestra un diseño para un almacén de datos siguiendo un esquema de copo de nieve parcial, en el que las dimensiones geográﬁca y producto han sido normalizadas. DIMENSIÓN TEMPORAL Clave Tiempo Nivel Tiempo Semana Mes Año DIMENSIÓN TABLA HECHOS DIMENSIÓN GEOGRÁFICA (VENTAS) PRODUCTO DIMENSIÓN DIMENSIÓN Clave Geográﬁca Clave Producto Clave Producto DEPARTAMENTO ALMACÉN Nivel Geográﬁco Clave Geográﬁca Nivel Producto Clave_Dpto Clave Almacén Desc. Geográﬁca Clave Canal Desc. Producto División Demog_Almacén Tamaño Geográﬁca Clave Temporal Tamaño Producto Dec_Dpto Distrito Tamaño Área Ventas Color Región Almacén Inventario Clase Coste Departamento DIMENSIÓN CANAL Clave Canal Nivel Canal Descripción Canal Figura 2.6: Ejemplo de almacén de datos diseñado en copo de nieve. La normalización de las tablas de dimensiones proporciona al diseño de copo de nieve la mejora de la eﬁciencia en la realización de consultas complejas que requieren el uso de operadores de agregación. Sin embargo, este diseño es con- ceptualmente más difícil de implementar, ya que incluye un mayor número de tablas y requiere de realizar muchos joins entre ellas, lo que incrementa los tiem- pos de consulta. En ocasiones, se requiere diseñar un almacén de datos que contenga más de una tabla de hechos. Para ello, el esquema o diseño en constelación permite crear un almacén de datos de forma similar al diseño en estrella, con la diferencia de que es- te modelo incluye más de una tabla de hechos. Además, cada tabla de hechos puede vincularse con todas o solo algunas tablas de dimensiones. Este esquema contribu- ye a la reutilización de las tablas de dimensiones, las cuales se pueden relacionar con más de una tabla de hechos. El diseño en copo de nieve permite crear un almacén de datos a partir de un diseño en estrella. Para ello, las tablas de dimensiones se normalizan, generan- do más de una tabla para cada una de las dimensiones, mejorando la eﬁciencia de consultas complejas que requieren el uso de operadores avanzados. Bibliografía [AN95] Agnar Aamodt and Mads Nygård. Different roles and mutual depen- dencies of data, information, and knowledge — an ai perspective on their integration. Data & Knowledge Engineering, 16(3):191–222, 1995. [BELP13] Ulrik Brandes, Markus Eiglsperger, Jürgen Lerner, and Christian Pich. Graph markup language (graphml). In Roberto Tamassia, edi- tor, Handbook on Graph Drawing and Visualization, pages 517–541. Chapman and Hall/CRC, 2013. [BNCD16] Rajkumar Buyya, Rodrigo N. Calheiros, and Amir Vahid Dastjerdi. Big Data : Principles and Paradigms. Elsevier Science & Techno- logy, 50 Hampshire Street, 5th Floor, Cambridge. USA, 2016. [dMP99] Adoración de Miguel and Mario Piattini. Fundamentos y Modelos de Bases de Datos. Alfaomega, 1999. [FPSS96] Usama Fayyad, Gregory Piatetsky-Shapiro, and Padhraic Smyth. From data mining to knowledge discovery in databases. AI maga- zine, 17(3):37, 1996. [Fri19] J. Friesen. Java XML and JSON: Document Processing for Java SE. Apress, 2019. [GR09] Matteo Golfarelli and Stefano Rizzi. Data Warehouse Design: Mo- dern Principles and Methodologies. Mcgraw-hill, 2009. [HT14] Francisco Herrera Triguero. Inteligencia Artiﬁcial, Inteligencia Computacional y Big Data. Servicio de publicaciones. Universidad de Jaén, Jaén, 2014.

Gestión de Soluciones - II PDF

Document Details

Tags

Related

Summary

Full Transcript