La tipicidad de los proyectos de Data Warehouse, en comparación con las aplicaciones tradicionales de gestión, también se refleja en una diferente técnica de modelado de datos. En un entorno decisional, los datos se organizan de manera que respondan directamente a las consultas típicas del usuario final. Para descargar el texto completo y obtener más información, haz clic AQUÍ
Supongamos, por ejemplo, que el objetivo del usuario sea monitorear a lo largo del tiempo la planificación y realización de proyectos de inversión que utilizan fondos públicos, localizados en diversas áreas del territorio nacional, vinculados a diferentes sectores de actividad. De manera simplificada, se puede imaginar representar esta actividad a través de un cubo, cuyos lados reproducen las variables tiempo, localización y clasificación de actividad, relativas a los proyectos. Cada punto dentro del cubo es la intersección de las coordenadas definidas por los lados del cubo y representa la medida del hecho de interés (el proyecto y su financiación correspondiente) para esa particular combinación de localización, sector de actividad, tiempo, que representan las dimensiones del análisis. En el ámbito de Data Warehouse, se habla entonces de modelado dimensional de datos. El modelo dimensional y el tradicional modelo entidad-relación son potencialmente capaces de almacenar la misma información. La diferencia está relacionada con la búsqueda de un rendimiento óptimo en los dos tipos de entornos. En los entornos operativos es fundamental adoptar técnicas de normalización que, eliminando redundancias, permiten a un elevado número de transacciones repetitivas consultar y actualizar la información en un solo punto de la base de datos. Los sistemas de soporte a la decisión, en cambio, se caracterizan por un reducido número de transacciones, que operan transversalmente sobre la base de datos, requiriendo acceso de solo lectura a un elevado número de datos para realizar uniones (joins). El uso de técnicas de normalización se muestra por lo tanto contraproducente en el diseño de un sistema de Data Warehouse. En un entorno de decisión, es más correcto diseñar la base de datos de modo que satisfaga de manera directa y simplificada las necesidades específicas de los usuarios finales, incluso mediante datos desnormalizados y agregados. Es importante dedicar mucha atención al análisis del modelo conceptual, previendo todas las dimensiones de análisis y para cada dimensión sus respectivos atributos. Los atributos de las tablas dimensionales se usan directamente como condiciones de búsqueda en las consultas al Data Warehouse y como encabezados de columnas en los informes de los usuarios finales. El uso de datos pre-agregados y de síntesis limita el número de operaciones necesarias para reconstruir la información solicitada. El esquema estrella, además de estar optimizado para las consultas, presenta la ventaja adicional de permitir una representación gráfica del negocio más comprensible para el usuario final. A diferencia del esquema entidad-relación, en el que todas las entidades se representan de la misma manera, el esquema estrella es asimétrico. En el centro del diagrama hay una tabla dominante de grandes dimensiones, que es la única que posee múltiples enlaces, que se concretan en campos clave contenidos en ella, con las otras tablas. Las otras tablas representan las dimensiones de análisis a través de las cuales se examina el «hecho» de interés. Técnicamente, se llaman «fact table» a la tabla central y «dimension table» a las otras. La fact table es la tabla donde se almacenan las medidas numéricas del hecho (en el ejemplo, el importe de la financiación del proyecto de inversión), cada una de las cuales representa la intersección de todas las dimensiones y cuantifica una o más variables. Normalmente es la única tabla normalizada. Las otras tablas representan las dimensiones de análisis mediante las cuales se examina el «hecho» y contienen atributos de tipo descriptivo. La cardinalidad de estas tablas, normalmente desnormalizadas, es limitada. Entre las tablas dimensionales, la tabla de la dimensión tiempo está siempre presente en los modelos dimensionales, sea cual sea el negocio que se represente. Esto deriva de la característica de los sistemas de Data Warehouse que gestionan también las informaciones históricas. A veces, para mejorar aún más la interpretabilidad del modelo, incluso las tablas dimensionales se normalizan, explicitando las jerarquías. Esto da lugar a un esquema denominado «copo de nieve» o Snowflake Schema. La navegación de datos a través del modelo snowflake es menos eficiente que en el esquema estrella porque aumenta el número de tablas sobre las que realizar las uniones (joins). Hay que considerar que, si bien la desnormalización garantiza mejores prestaciones en las operaciones de consulta, la misma hace más costosa la actualización y la carga de datos. Más en general, las operaciones de mantenimiento del modelo multidimensional, como la extensión a nuevas dimensiones de análisis, requieren la carga «ex novo» de la base de datos. Por esto, de vez en cuando, es necesario evaluar el trade-off entre estas dos necesidades y adoptar según los casos el esquema estrella o el snowflake schema. Además, se debe añadir que, para modelos muy complejos, con diversas fact tables que comparten numerosas dimensiones, se vuelve difícil adoptar la técnica dimensional, también porque no siempre está claro cuáles son las tablas de hechos y cuáles las de dimensiones. Para el diseño conceptual del Enterprise Data Warehouse parece preferible, por lo tanto, un modelo de datos Entity-Relationship apropiadamente desnormalizado. El modelado dimensional es, en cambio, sin duda más adecuado para la representación de los datos de los Data Mart. Los modelos dimensionales pueden implementarse tanto en DBMS relacionales como en DBMS multidimensionales específicos. REPRODUCCIÓN RESERVADA
Pubblicato in Negocios
Sé el primero en comentar