Sistemas de Información

Transcripción

1 Sistemas de Información Félix Gómez Mármol 5 o Ingeniería Informática Curso Profesor: José Samos Jiménez (jsamos@ugr.es) bdf/jsamos/ii/si/ Departamento de Lenguajes y Sistemas Informáticos

2 2

3 Índice general Índice general 3 Índice de figuras 5 2. El Modelo de Datos Multidimensional Fundamentos del modelo de datos multidimensional: Un modelo para consulta Principios de los sistemas operacionales o transaccionales Principios de los sistemas multidimensionales Funcionamiento de los sistemas multidimensionales El modelo de datos multidimensional a Nivel Conceptual Implementación de los sistemas multidimensionales: Nivel Lógico Diseño multidimensional Pasos para realizar un diseño multidimensional a nivel conceptual Pasos para realizar un diseño multidimensional a nivel lógico Caso de diseño según fotografía periódica Otros casos de diseño Diseño de sistemas OLTP vs OLAP Procesamiento de consultas y optimización Patrón de consulta y técnicas de indexación Partición de la tabla de hechos Definición de agregados La Fábrica de Información Corporativa Arquitectura del sistema de información: la FIC Arquitectura según Kimball Arquitectura según Inmon Construcción de la FIC ETL. Extracción, Transformación y Carga Desarrollo de ETL Estructura de los proyectos de desarrollo de la FIC Nuevos perfiles para el desarrollo de proyectos FIC Bibliografía 37 3

4 4 ÍNDICE GENERAL

5 Índice de figuras 2.1. Descripción de una organización Diagrama Entidad/Relación Diagrama relacional resultado de normalizar el diagrama de la figura Informe de ventas entre septiembre de 2004 y septiembre de Hechos con mediciones y dimensiones Ejemplo del diagrama multidimensional de una venta Ejemplo simplificado del diagrama multidimensional de una venta Representación de un dato en el espacio Representación en el espacio de todos los datos Roll-up en la dimensión producto Operación slice Sistemas OLTP Ejemplo de hecho con mediciones y dimensiones con descriptores Estructura de la descomposición de una dimensión por niveles Ejemplos de descomposición de una dimensión por niveles Diseño a nivel conceptual del modelo de datos multidimensional Implementación en Estrella Implementación en Copo de Nieve Dimensiones sin desdoblar Dimensiones de la figura 2.19 desdobladas Saldo de una cuenta de ahorros Diseño a nivel lógico Enfoque 1: Transacciones de almacén Enfoque 2: Fotografía periódica de almacén Constelación Data Warehouse Bus Architecture Foco de atención: Venta Foco de atención: Promoción Dimensión de mediciones Join entre cada dimensión y los hechos Join del producto cartesiano de las dimensiones y los hechos Procesamiento de consultas con índices de mapa de bits Cubos agregados Navegador de agregados Fallo en la dispersión de los agregados Fábrica de Información Corporativa según Kimball Fábrica de Información Corporativa según Inmon Data Warehouse Corporativo

6 6 ÍNDICE DE FIGURAS

7 Capítulo 2 El Modelo de Datos Multidimensional Figura 2.1: Descripción de una organización 2.1. Fundamentos del modelo de datos multidimensional: Un modelo para consulta A lo largo de todo el capítulo desarrollaremos el siguiente ejemplo: Tenemos una cadena de supermercados en la que hay, entre otros empleados: Un director general (en lo más alto de la pirámide) Un director del departamento de ventas (en algún nivel intermedio de la pirámide) Cajeros/as (en la base de la pirámide) Nosotros nos vamos a centrar en los intereses del director del departamento de ventas, el cual toma decisiones (entre otras muchas) sobre, por ejemplo: Qué productos vender A qué precio vender cada producto Bajo qué ofertas vender cada producto, etc. 7

8 8 Capítulo 2. El Modelo de Datos Multidimensional Qué aplicación seríamos capaces nosotros de hacer ahora mismo para gestionar las ventas en una cadena de supermercados? La figura 2.2 nos muestra un ejemplo de lo que sabríamos hacer. Figura 2.2: Diagrama Entidad/Relación En la figura 2.3 vemos el diagrama relacional correspondiente al E/R mostrado en la figura 2.2. Lo que se ha hecho para pasar de uno al otro no ha sido más que Normalizar, esto es, dejar solamente relaciones del tipo 1..N. A nivel intuitivo podríamos decir que al normalizar lo que se pretende es que cada dato sólo aparezca en un sitio (en una única tabla) con el objetivo de facilitar las modificaciones (evitar inconsistencias, etc.). Figura 2.3: Diagrama relacional resultado de normalizar el diagrama de la figura 2.2 En definitiva, tanto el modelo relacional como el E/R están orientados a optimizar las modificaciones de los datos almacenados. Pero este tipo de aplicación no le es útil al director del departamento de ventas. Supongamos que éste quiere saber las ventas realizadas entre septiembre de 2004 y septiembre de Para ello deberíamos crear una aplicación que le mostrara una tabla similar a la que aparece en la figura 2.4. Otro informe que le podría interesar podría ser el que mostrara las ventas por cada tienda, o por cada departamento, o por cada cajero, durante el último año, o el último trimestre, o el último mes, etc. En resumen, el director del departamento de ventas necesita informes distintos a los que produce la aplicación de las figuras 2.2 y 2.3.

9 2.1 Fundamentos del modelo de datos multidimensional: Un modelo para consulta 9 Producto Sept 2004 Sept 2005 % Figura 2.4: Informe de ventas entre septiembre de 2004 y septiembre de Principios de los sistemas operacionales o transaccionales El objetivo principal no es más que registrar transacciones, esto es, entrada y modificación de los datos; y están destinados a usuarios operacionales (en nuestro ejemplo, los cajeros). Pero como ya hemos visto, necesitamos informes. Cuáles? Muchos y de muy diversa índole: los que el usuario determine cuando analiza la información (en vez de a priori, durante el diseño de la base de datos). Obtener el informe de la figura 2.4 es sencillo pero no trivial. Muy probablemente el decisor no sabrá hacerlo. El trabajo del informático en ese caso es crear informes a medida Principios de los sistemas multidimensionales Los modelos relacionales y E/R se dicen que son homogéneos porque todas las relaciones tienen la misma importancia (recordemos que están orientados a transacciones y no tanto a consultas). El modelo multidimensional es no homogéneo (con unas relaciones más importantes que otras) y no orientado a transacciones, sino orientado a consultas. Los informes requeridos por el director del departamento de ventas serán del tipo cuánto de qué, quién, cuándo, cómo,.... En este caso, cuánto será lo importante (también llamado foco de atención) y el resto será lo adicional. Figura 2.5: Hechos con mediciones y dimensiones En nuestro ejemplo, como se observa en la figura 2.6, el foco de atención es una venta. Figura 2.6: Ejemplo del diagrama multidimensional de una venta

10 10 Capítulo 2. El Modelo de Datos Multidimensional Cómo se representa esto? (Lo subrayado es lo importante y el resto es lo adicional). Boli Azul, Promo: Ninguna, 10/10/ :22:18, Caja-3, La Chana, M a Carmen, Pepe, n o 318, 1, 0 60 Euros, 0 60 Euros, 0 20 Euros Simplificando el ejemplo de la figura 2.6 tendríamos algo como: Figura 2.7: Ejemplo simplificado del diagrama multidimensional de una venta Boli Azul, 10/10/2005, La Chana, 1, 0 60 Euros, 0 20 Euros Funcionamiento de los sistemas multidimensionales En el modelo multidimensional la representación de un dato es un punto en el espacio. La representación espacial de la entrada anterior se puede ver en la figura 2.8. Figura 2.8: Representación de un dato en el espacio Si por ejemplo los domingos la tienda de La Chana no abre, no existirá una línea de puntos en el espacio correspondiente a cada domingo en la tienda de La Chana (equivalentemente, si el 09/10/05 no se vendió ningún boli azul en la tienda de La Chana, no existirá ese punto). Por lo tanto, la representación en el espacio de todos los datos resulta ser un cubo no macizo como el que se ve en la figura 2.9. Con más de tres dimensiones lo correcto es hablar de hipercubo, aunque nosotros siempre utilizaremos el término cubo. Figura 2.9: Representación en el espacio de todos los datos

11 2.1 Fundamentos del modelo de datos multidimensional: Un modelo para consulta 11 En nuestro ejemplo de la cadena de supermercados, los productos tienen varios atributos, como descripción, tipo, marca, provincia de fabricación, etc. También puede resultar interesante agrupar el eje de los productos según alguno o algunos de estos atributos. Esta operación de agrupar los datos de una determinada dimensión según alguno o algunos de sus atributos recibe el nombre de roll-up (véase la figura 2.10), mientras que la operación inversa se conoce como drill-down. El extremo de roll-up consistiría en agrupar todos los puntos de una dimensión en un solo punto. Por otra parte, una vez que se ha hecho roll-up, para poder hacer drill-down se plantea un problema irresoluble si no se almacenaran los datos de más bajo nivel (en nuestro ejemplo, las ventas de productos individuales). Por lo tanto, para hacer drill-down lo que en realidad se hace es un roll-up a partir del cubo base (cubo con todos los datos al menor nivel de detalle posible) para conseguir el cubo que se desea obtener. Figura 2.10: Roll-up en la dimensión producto Tomar una capa del cubo se le dice slice. Por ejemplo, ver solamente los datos referidos a bolígrafos (o ver solamente los productos fabricados en Murcia). Por contra, dice consiste en hacer cubiletes más pequeños a partir del cubo total. Por ejemplo, ver todas las ventas de bolígrafos en el mes de enero. Con slice se dice que se pierde una dimensión (véase la figura 2.11), mientras que con dice esto no ocurre. Vistas estas operaciones podemos afirmar que: un modelo de datos multidimensional es más potente cuantos más atributos tenga cada dimensión, puesto que esto nos permitirá hacer roll-up (equivalentemente, drill-down) de muchas más formas distintas. Dicho de otro modo, a mayor número de atributos en cada dimensión, mayor número de posibles informes.

12 12 Capítulo 2. El Modelo de Datos Multidimensional Figura 2.11: Operación slice El modelo de datos multidimensional a Nivel Conceptual Los sistemas OLTP (On Line Transactional Processing, véase la figura 2.12) son los que hemos aprendido en cursos anteriores. Ahora estudiaremos los sistemas OLAP (On Line Analytical Processing). Figura 2.12: Sistemas OLTP En el modelo de datos multidimensional, a diferencia del E/R o el ODL, existe el problema de que no hay un único modelo de datos multidimensional aceptado por todo el mundo. Lo que sí hay, sin embargo, es un consenso acerca de los elementos generales. Los elementos generales en los que existe consenso son los siguientes: Hechos Nombre Mediciones, que pueden ser derivadas o no derivadas Dimensiones Nombre Niveles Nombre Descriptores Figura 2.13: Ejemplo de hecho con mediciones y dimensiones con descriptores

13 2.1 Fundamentos del modelo de datos multidimensional: Un modelo para consulta 13 En el ejemplo mostrado en la figura 2.13 la medición Beneficio es derivada, ya que puede ser calculada a partir de las mediciones PVP y Coste siguiendo la siguiente fórmula: Beneficio = PVP - Coste. No todos los atributos de una entidad en el modelo E/R serán niveles en el modelo de datos multidimensional; unos sí serán niveles, pero otros serán descriptores de niveles. Toda descomposición correcta de una dimensión en sus correspondientes niveles debe tener una estructura similar a la mostrada en la figura Figura 2.14: Estructura de la descomposición de una dimensión por niveles La figura 2.15 muestra dos ejemplos de descomposición de dimensiones en niveles. Figura 2.15: Ejemplos de descomposición de una dimensión por niveles Implementación de los sistemas multidimensionales: Nivel Lógico Existen varias posibilidades: 1. SGDBMD. Consiste en usar estructuras de datos a medida tales como árboles, índices, matrices, etc. Se les conoce como MOLAP (Multidimensional OLAP). 2. ROLAP (Relational OLAP). Se crea un modelo de datos multidimensional a partir de una BBDD relacional que puede estar normalizada o no. 3. O3LAP (Object Oriented OLAP) 4. HOLAP (Hybrid OLAP). Estructuras de datos a medida junto con BBDD.

14 14 Capítulo 2. El Modelo de Datos Multidimensional Nosotros trabajaremos con ROLAP, no obstante a continuación se presentan las ventajas e inconvenientes entre ROLAP y MOLAP: MOLAP ROLAP Más rápido Rápido (y aumentando) SGBD nuevo SGBD Relacional - No hay especialistas - Hay especialistas - Gestión adicional - Deben aprender lo nuevo Límite (muy alto en el n o de dimensiones) Sin límite en el n o de dimensiones Tras esta comparativa y sabiendo que hoy por hoy en el mercado imperan los sistemas ROLAP vamos a ver cómo se implementan éstos. Recordamos que el diseño a nivel conceptual del modelo de datos multidimensional de nuestro ejemplo de la cadena de supermercados tenía un aspecto similar al mostrado en la figura Figura 2.16: Diseño a nivel conceptual del modelo de datos multidimensional Para implementar este diseño sobre una base de datos relacional comenzaremos creando las tablas que consideremos necesarias. Éstas son las mostradas en la figura Figura 2.17: Implementación en Estrella Como vemos hemos creado una tabla para cada dimensión y otra para los hechos. A este tipo de implementación se le conoce como implementación en estrella.

15 2.1 Fundamentos del modelo de datos multidimensional: Un modelo para consulta 15 Así los atributos que podría tener, por ejemplo, la tabla Producto son: Marca Producto-nombre Fabricante Código barras Provincia fabricación Color Tipo emvase { Familia Peso Nombre Sección Nombre Responsable Departamento Nombre Responsable Algunas entradas (o registros) de la tabla Producto podrían ser, por ejemplo: Agua Lanjarón 0 5L, XXX, NA, PVC, 0 5K, Lanjarón, Aguas Lanjarón, Granada, Aguas, Bebidas no Alcohólicas,... Agua Lanjarón 1 5L, XXX, NA, PVC, 1 5K, Lanjarón, Aguas Lanjarón, Granada, Aguas, Bebidas no Alcohólicas,... Agua Lanjarón 5L, XXX, NA, PVC, 5K, Lanjarón, Aguas Lanjarón, Granada, Aguas, Bebidas no Alcohólicas,... Otros ejemplos de registros para la tabla Tiempo podrían ser: 24/10/2005, lunes, no fin de semana, laborable, oto~no, 43, octubre, 10, /10/2005, martes, no fin de semana, laborable, oto~no, 43, octubre, 10, 2005 Como vemos, con esta implementación aparece claramente el problema de la información replicada. Por lo tanto, la solución pasa por normalizar nuestro diseño. Y así obtenemos el conjunto de tablas que aparecen en la figura Figura 2.18: Implementación en Copo de Nieve A este tipo de implementación se le conoce como implementación en copo de nieve y en ella se tiene una tabla por cada nivel de cada dimensión. La principal diferencia con una implementación en estrella es que ésta última no está normalizada, mientras que con copo de nieve sí que lo está. Por otra parte, las consultas en una implementación en estrella son mucho más fáciles y rápidas ya que implican muchas menos tablas con muchas menos referencias a otras tablas. En copo de nieve, sin embargo, se está más cercano al nivel conceptual, aunque también sería posible presentar una implementación en estrella según un diseño de nivel conceptual (bastaría con indicar qué atributos de las dimensiones son niveles y cuáles son descriptores).

16 16 Capítulo 2. El Modelo de Datos Multidimensional Otra diferencia que podríamos pensar que existe entre ambas implementaciones es la del espacio ocupado por cada una de ellas. Para analizar esto recordemos lo que decíamos sobre la normalización: cuando ésta se aplica conseguimos evitar anomalías en las modificaciones, ya que se coloca cada dato en un sólo sitio, con el consecuente ahorro de espacio. Vamos a estimar el tamaño ocupado por una implementación en estrella suponiendo que tenemos los siguientes valores: productos, 1825 días, 20 tiendas y 500 promociones. Parece evidente que las tablas de cada una de las dimensiones serán más grandes que con una implementación de copo de nieve. Ahora bien, en cuanto a la tabla de los hechos (la ventas), qué significan cada uno de sus registros? Venta en un día, de un producto, en una tienda, bajo una promoción 24/10/2005, Botella Agua 0 5L, Mercadona Parque Almunia, sin promoción, 25 u, 0 5 Euros, 0 3 Euros Por otra parte debemos plantearnos cuántos registros puede tener la tabla de los hechos. Pues como máximo tendrá el producto = , lo cual daría lugar a un cubo totalmente macizo que, como ya vimos, no es nada probable. Pensemos que lo que estaríamos diciendo con ello es que cada día se han vendido cada uno de los productos, en cada una de las tiendas, bajo cada una de las promociones. Un estimación aproximada del número real de registros podría ser: 1825 días 20 tiendas 10 % de productos 1 5 promociones = registros Así, la tabla realmente grande es la de los hechos y es ahí donde debemos esforzarnos por ahorrar espacio. Un cálculo del espacio ocupado por cada registro de dicha tabla podría ser: Mediciones Llaves externas Cantidad 2 bytes Fecha: dd/mm/aaaa 8 bytes PVP 4 bytes Producto: código barras 10 bytes Coste 4 bytes Tienda: nombre 15 bytes 10 bytes Promoción: nombre 25 bytes 58 bytes Si convenimos que cada entrada ocupa 68 bytes, el tamaño total de la tabla será de GB. Moviéndonos en estos órdenes de espacio podemos afirmar que el espacio ocupado por las tablas de las dimensiones es despreciable con respecto al ocupado por la tabla de los hechos. Y puesto que dicha tabla tiene el mismo tamaño en una implementación en estrella que en una en copo de nieve, concluimos que el espacio ocupado no es un factor determinante o decisivo para decantarse por una implementación u otra. No obstante siempre interesa ahorrar todo el espacio posible. Para conseguir este objetivo podríamos pensar en reducir el número de dimensiones o eliminar mediciones de la tabla de hechos, pero esto será, en la mayoría de los casos, una solución incorrecta. Lo que sí que se puede hacer es convertir las llaves externas antes vistas en llaves generadas, que consisten básicamente en asignar un número a cada registro distinto en las tablas de las dimensiones (numerarlos, en definitiva). Con esta transformación tendríamos que: Mediciones Llaves generadas Cantidad 2 bytes Fecha 2 bytes PVP 4 bytes Producto 4 bytes Coste 4 bytes Tienda 2 bytes 10 bytes Promoción 2 bytes 10 bytes Es decir ( ) 20 bytes por cada registro, ocupando así la tabla completa un total de = 6 57 GB. No olvidemos que ahorrando espacio también estamos mejorando el rendimiento global del sistema, reduciendo, por ejemplo, el tiempo de respuesta ante una consulta.

17 2.2 Diseño multidimensional Diseño multidimensional En esta sección vamos a estudiar cómo realizar un diseño tanto a nivel conceptual como a nivel lógico de un sistema OLAP. Sería el equivalente a aprender el modelo E/R y el modelo relacional en sistemas OLTP Pasos para realizar un diseño multidimensional a nivel conceptual 1. Seleccionar el área de negocio En este primer paso debemos determinar quién será el usuario dentro de la pirámide de la organización (figura 2.1) que usará la aplicación. Es más, debemos determinar el área, el usuario y los objetivos del mismo (es decir, las decisiones a las que se va a dar soporte). En nuestro ejemplo el área es el departamento de ventas, el usuario es el director del departamento de ventas y los objetivos son permitirle tomar decisiones sobre precios de productos, promociones, etc. 2. Definir los hechos a) Ventas de un producto en una tienda, en una fecha, bajo una promoción. b) Ventas de un producto en una línea de ticket, una tienda, en una fecha, bajo una promoción. 3. Definir las dimensiones. Bases Identificamos todas las dimensiones que se nos ocurran con todos los atributos que pensemos (siempre que podamos obtener los datos de alguna fuente), ya que cuanto mayor sea el número de dimensiones con sus respectivos descriptores, mayor es el número de combinaciones posibles para hacer roll-up, es decir, mayor es el número de posibles informes que se pueden crear. En ese momento definimos las bases, que no son más que el conjunto de dimensiones que identifican unívocamente a cada registro de los hechos. En nuestro ejemplo la base la forman las dimensiones Producto, Tienda, Fecha y Promoción, aunque podrían haber sido otras, como por ejemplo LineaTicket de un Ticket, o bien Fecha, Hora, Caja y Tienda. En ocasiones puede ocurrir que nos encontremos con una dimensión con muchísimos registros y con mucha información repetida, como ocurre en la figura Figura 2.19: Dimensiones sin desdoblar

18 18 Capítulo 2. El Modelo de Datos Multidimensional La solución pasa entonces por desdoblar la dimensión, que no es otra cosa que tomar una dimensión y dividirla en dos, consiguiendo así tener mucha menos información replicada, con el consecuente ahorro de espacio. La figura 2.20 muestra el desdoblamiento de las dimensiones que veíamos en la figura Figura 2.20: Dimensiones de la figura 2.19 desdobladas 4. Identificar las mediciones. Aditividad Ya conocemos lo que son las mediciones; por otra parte, la aditividad es una característica de éstas que nos indica cómo agregarlas (es decir, cómo hacer roll-up con ellas). Existen tres tipos de mediciones atendiendo a su aditividad: Aditivas. Se puede aplicar la SUMA por todas las dimensiones. Es el caso de las mediciones N o artículos, N o clientes o Beneficio. No aditivas. No se puede aplicar la SUMA por ninguna dimensión. Por ejemplo el PVP o el Coste. Semi-aditivas. Se puede aplicar la SUMA por algunas dimensiones. Como ocurre, por ejemplo, con el Saldo de la figura 2.21, que se puede sumar por las dimensiones Cliente y Cuenta, pero no por la dimensión Fecha. 1 Figura 2.21: Saldo de una cuenta de ahorros Las mediciones derivadas habitualmente serán aditivas, mientras que las no derivadas pueden ser de cualquier tipo. Generalmente son preferibles las mediciones aditivas frente a las no aditivas y las semi-aditivas.entre la opción (a) y la (b), es preferible la opción (b). 5.Validación U. Vendidas U. Vendidas PVP ImporteVenta CosteUnitario CosteVenta BeneficioUnitario BeneficioVenta (a) (b) 1. Comprobar que hay fuentes de datos (generalmente aplicaciones OLTP). 2. Estimar el número de registros de los hechos y de alguna dimensión, si ésta es especialmente grande. 1 Aunque esto estaría bastante bien ;-)

19 2.2 Diseño multidimensional Pasos para realizar un diseño multidimensional a nivel lógico Como ya vimos anteriormente, con un diseño multidimensional en estrella, los hechos se corresponden con una tabla, así como cada una de las dimensiones. En la figura 2.22 se muestra una estimación del número de registros para cada dimensión. Figura 2.22: Diseño a nivel lógico Dimensiones degeneradas Un registro de LineaTicket tendrá el siguiente aspecto: Línea Ticket Por lo tanto, consideramos que el atributo Línea de la tabla LineaTicket no es relevante para el decisor y lo eliminamos. Pero si vamos un poco más lejos y nos damos cuenta de que el atributo Ticket tampoco tiene importancia, entonces eliminamos la dimensión LineaTicket entera. A este tipo de dimensión se le llama dimensión degenerada, la cual tiene una llave externa en la tabla de hechos pero no tiene una tabla de dimensión asociada porque no aporta información adicional. Otro ejemplo viene con los registros de la tabla Hora, los cuales tendrían un aspecto similar al siguiente: ID hora Subparte día Parte día 00:00:00 Noche Noche... 10:00:00 Media ma~nana Ma~nana... 16:00:00 1 a hora de la tarde Tarde... 23:59:59 Noche Noche Para empezar podríamos quedarnos sólo con aquellos registros de las horas en las que permanecieran abiertas las tiendas. Pero si fuéramos más allá y decidiéramos prescindir de los atributos subparte del día y parte del día, nos encontraríamos nuevamente con una dimensión degenerada.

20 20 Capítulo 2. El Modelo de Datos Multidimensional Dimensiones cambiantes Hasta ahora hemos considerado que las dimensiones eran fijas, estáticas, mientras que a los hechos se le están añadiendo nuevos registros continuamente. Pero la realidad no es del todo así, puesto que existen las llamadas dimensiones cambiantes. Y estos cambios en los datos de las dimensiones deben quedar reflejados de alguna manera. Existen cuatro posibilidades: Tipo 1 Sobreescribir los valores antiguos con los nuevos. Antes de los cambios, tendríamos, por ejemplo: Y después de los cambios, tendríamos: Nombre Teléfono Félix Gómez Nombre Teléfono Félix Gómez Esta solución no siempre será aceptable, puesto que no podemos perder de vista que estamos cambiando la historia. Tipo 2 Crear un nuevo registro con el nuevo valor del registro correspondiente. Antes de los cambios, tendríamos, por ejemplo: ID CodBarras Descripción Sección 34 1X73F624J Agua Lanjarón 5L Alimentación Y después de los cambios, tendríamos: ID CodBarras Descripción Sección 34 1X73F624J Agua Lanjarón 5L Alimentación 90 1X73F624J Agua Lanjarón 5L Aguas Esta solución, adecuada en algunos casos, tiene el inconveniente del incremento en el número de registros de la dimensión cambiante. Tipo 3 Añadir nuevos campos a los registros ya existentes. Antes de los cambios, tendríamos, por ejemplo: ID CodBarras Descripción Sección 34 1X73F624J Agua Lanjarón 5L A Y después de los cambios, tendríamos: ID CodBarras Descripción Sección NuevaSección 34 1X73F624J Agua Lanjarón 5L A B 34 1X73F624J Agua Lanjarón 5L B C Aunque otra opción podría ser: ID CodBarras Descripción Sección NuevaSección ÚltimaSección 34 1X73F624J Agua Lanjarón 5L A B C A este tipo también se le conoce como realidad alternativa, puesto que permite ver la información almacenada, desde distintas perspectivas.

21 2.2 Diseño multidimensional 21 Tipo 6 (3+2+1) Antes de los cambios, tendríamos, por ejemplo: ID CodBarras Descripción Sección NuevaSección Último 34 1X73F624J Agua Lanjarón 5L A A Sí Y después de los cambios, tendríamos: ID CodBarras Descripción Sección NuevaSección Último 34 1X73F624J Agua Lanjarón 5L A B No 96 1X73F624J Agua Lanjarón 5L B B Sí Si hubiera un cambio más, entonces tendríamos: ID CodBarras Descripción Sección NuevaSección Último 34 1X73F624J Agua Lanjarón 5L A C No 96 1X73F624J Agua Lanjarón 5L B C No 132 1X73F624J Agua Lanjarón 5L C C Sí A este problema se le conoce como el problema de las dimensiones lentamente cambiantes o SCD (Slowly Changing Dimension). Sin embargo, también existen otro tipo de dimensiones con campos rápidamente cambiantes. Es el caso del campo PVP en la dimensión Producto. Si el PVP de un producto lo ponemos en la dimensión Producto, podríamos adoptar una solución de tipo 1. Otra opción sería poner el PVP en la tabla de los hechos. Y una tercera alternativa pasaría por desdoblar la dimensión Producto en función de la estabilidad de sus campos, dejando de un lado los atributos lentamente cambiantes y del otro lado los atributos rápidamente cambiantes Caso de diseño según fotografía periódica Hasta ahora hemos visto que en los hechos se registraban transacciones (de ventas, por ejemplo). Ahora vamos a tomar como ejemplo uno en el que el foco de atención es el inventario de un almacén. El enfoque 1 que se muestra en la figura 2.23 es equivalente al ya hecho para las ventas. Figura 2.23: Enfoque 1: Transacciones de almacén En el enfoque 2 mostrado en la figura 2.24 los hechos registran el inventario de cada producto en cada fecha y en cada almacén, con lo que se tiene un cubo sólido, sin huecos. A1, P1, F1. 30u, 50 Euros, 70 Euros A1, P2, F1. 10u, 20 Euros, 30 Euros A1, P2, F2. 20u, 15 Euros, 20 Euros Lo importante de esto es ver que para un usuario podría valer cualquiera de los dos enfoques dependiendo de sus necesidades a la hora de generar informes. De hecho, es posible que necesite ambos enfoques.

22 22 Capítulo 2. El Modelo de Datos Multidimensional Figura 2.24: Enfoque 2: Fotografía periódica de almacén Para ello es necesario poder crear informes combinados a partir de distintos esquemas. A esta operación multidimensional de crear informes combinados se le conoce como drillacross, y consiste en llevar las condiciones definidas en un informe sobre un esquema (slice & dice) a otro esquema. Nivel de ventas Drill-across Nivel de almacenamiento (en un lugar y periodo) (en un lugar y periodo) La condición necesaria que se debe cumplir para poder aplicar drill-across es que ambos esquemas compartan, al menos, las dimensiones sobre las que se definen las condiciones. A esta combinación de dimensiones procedentes de distintos esquemas se le llama constelación (ver figura 2.25), aunque cada base de datos multidimensional individual no tiene por qué ser necesariamente en estrella. Figura 2.25: Constelación Otra representación de las constelaciones es la Data Warehouse Bus Architecture, como se puede observar en la figura Figura 2.26: Data Warehouse Bus Architecture Según la herramienta que se use puede ser suficiente incluso con que se compartan solamente aquellas partes de las dimensiones sobre las que se definen las restricciones.