El diseo de la base de datos de un Data WarehouseMarta Millanmillan@eisc.univalle.edu.co

www.eisc.univalle.edu.co/materias

El modelo Multidimensional Principios bsicos

Marta Millanmillan@eisc.univalle.edu.co

www.eisc.univalle.edu.co/materias

Introduccin

Un data warehouse se construye de manera heurstica En un primer momento, no se conocen bien los requerimientos Proceso de construccin nuevos requerimietos

Motivaciones

Cmo disear una base de datos que permita ejecutar consultas desconocidas? Entender la forma usar informacin en el data warehouse

Motivaciones

La mayor parte de las consultas a un data warehouse sobre un hecho esencial, analizado de distintas formas:Nmero medio de ventas de micros por tienda el ltimo mes Los diez programas por cable ms vistos la semana pasada Ventas previstas de natilla en Navidad comparado con el stock actual

E/R vs. Multidimensional

Los modelos E/R intentan eliminar la redundancia en los datos La bsqueda de consistencia hace que los procesos de consulta sean difciles y costosos. Modelos dimensionales: meta comprensin y el rendimiento

Modelos Multidimensionales

Tcnica de diseo lgico para diseo de Data Warehouses Proporcionan los mejores resultados Diseos de acuerdo a un estndar que es intuitivo y fcil de entender Permite accesos de alto rendimiento

Modelos Multidimensionales

Formado por una tabla cuya clave es compuesta -Table Fact (tabla de hechos) y un conjunto de tablas ms pequeas denominadas Tablas de Dimensin. Su apariencia hace que se les denomine diagramas STAR

Diagramas en estrella

Dimensin Cliente Tabla de hechos

Dimensin Producto

Ventas Dimensin Dimensin Fecha

Almacen

Hechos Transacciones que han ocurrido. Poco probable que cambien en el futuro. Los hechos se pueden analizar de diferentes formas dependiendo de la informacin de referencia Los hechos suelen tener pocos atributos, puesto que no tiene datos operacionales

Dimensiones

Representa factores por los que se puede analizar un determinado rea de negocio. Son tablas ms pequeas A menudo se desnormalizan

Hechos y dimensiones

Tiendas

Regin

VENTAS

Producto

Diseo STAR: Etapas

Un diagrama E/R se divide en mltiples diagramas en estrella Separar en procesos discretos de negocio (hechos) y modelizar cada hecho separadamente Seleccionar relaciones n:m con atributos numricos Desnormalizar las tablas de dimensin El esquema final sern de 10- 25 STAR cada uno de ellos con 5-10 dimensiones

Una metodologa de trabajo para el diseo de la base de datos de un Data Warehose

Marta Millanmillan@eisc.univalle.edu.co

www.eisc.univalle.edu.co/materias

Mtodo de diseo: Enfoque 1

Disear la base de datos del Data Warehouse global:

Mucho esfuerzo Mucho tiempo Resultados tardan mucho tiempo en aparecer No es abordable en la mayora de los casos

Mtodo de Diseo Enfoque 2

Disear la base de datos de cada Data Mart por separado: Mucho ms sencillo Menos tiempo Menos recursos La integracin posterior de varios complica

Data Mart se

Mtodo de Diseo

SOLUCIN:Disear la Base de Datos de cada Data Mart sin perder de vista el objetivo final de integracin. Definir una estructura comn (bus del data warehouse) sobre la que se apoyen todos los data marts

Unin de los modelos STAR

Construir todo el DW desde el principio o hacer diseos separados para cada area de negocio?? Planifiquemos Data Marts separados pero que compartan aquellas definiciones comunes a la organizacin Data Marts con arquitectura de bus comn

La arquitectura del BUS comn del DW

Crear una arquitectura que defina todo el marco de la organizacin. Construir Data Marts dentro de ese marco comn Dimensiones conformadas Definicin estndar de hechos

Dimensiones conformadas (I)

Es una dimensin que significa lo mismo para cada posible tabla fact Ejemplos: cliente, producto, tiempo, localizacin Es responsabilidad del equipo diseador establecer, publicar y mantener las dimensiones conformadas

Dimensiones conformadas (II)

Sin un uso estricto de dimensiones conformadas el datawarehouse nunca funcionar como un todo. Hacen posible: Una nica tabla de dimensin se puede usar contra mltiples tablas de hechos en el mismo espacio de bases de datos Las interfaces de usuario y el contenido de los datos son consistentes dondequiera que se use Hay una interpretacin consistente de atributos

Dimensiones conformadas (III)

Puede llevar mucho tiempo la identificarlas Se disean al nivel de granilaridad ms bajo que sea posible Deben tener una clave no significativa para poder permitir cambios en el futuro La creacin de las mismas es tan decisin tcnica como poltica

Definiciones de hechos conformadasSe realiza al mismo tiempo que las dimensiones conformadas Ejemplos: costos, precios, beneficio, ... Mismas unidades de medida Mismos periodos Mismas localizaciones Si es imposible conformar un hecho nico asegurarse de dar a las distintas interpretaciones diferentes nombres

Data Marts con mltiples fuentes de datosdata mart con una nica fuente de datos son los ms fciles de construir.Ej: sistema de pedidos disponible y diseo del data mart de pedidos.

Es recomendable empezar con estos data marts porque minimiza el riesgo de implementaciones demasiado ambiciosas. Una implementacin de data marts sencillos permitir al equipo de desarrollo seguir trabajando mientras los usuarios ya van realizando sus consultas.

Data Marts con mltiples fuentes de datos (II) Cuando se hayan implementado suficientes data marts de una nica fuente es razonable combinarlos para conseguir un data mart de ms de una fuente.Ej: Conseguir el data mart de beneficios combinado distintos componentes de costos y ganancias

La arquitectura comn del DW Las dimensiones conformadas y las definiciones estndar de los hechos configuran la arquitectura del bus del data warehouse. La definicin del bus en un determinado entorno permite aadir un nuevo data mart que puede coexistir con los ya existentes.

Aspectos de diseo a tener en cuenta en el diseo de las tablas de un Data Mart

Marta Millanmillan@eisc.univalle.edu.co

www.eisc.univalle.edu.co/materias

4 pasos para disear tablas de hechos

Elegir el data martEmpezar con data marts de una fuente

Decidir el grano de la tabla de hechosEstablece lo que significa cada registro de la tabla de hechos

Decidir las dimensiones Decidir los hechos de la tabla de hechosDeben ser especficos para el grano elegido para la tabla de hechos

Buscar las transacciones en el proceso del negocio

Transacciones que describen sucesos fundamentales para el negocio Para cada hecho potencial, preguntar: se usa de verdad esta transaccin en el proceso de negocio?

Determinar dimensiones principales

En modelo lgico que entidades estn asociadas con la entidad que representa la tabla hecho No todas las dimensiones principales estn asociadas directamente a la tabla hecho en el modelo lgico Preguntarse cul va a ser el enfoque en el anlisis del negocio

Comprobar si un hecho es una dimensin

Buscar dimensiones no normalizadas en las tablas candidatas a hechos. Se puede dar el caso de que un candidato a hecho sea una dimensin que contenga grupos repetidos de atributos hechos

Comprobar si un hecho es una dimensin

Disear tablas hecho para almacenar filas que no varen en el tiempo. Si la entidad parece que vara en el tiempo, considerar el crear una tabla hecho que represente eventos que cambien el estado de esa entidad

Comprobar si una dimensin es un hecho

Puedo ver esta entidad en otra dimensin?. En cuntas? Si la respuesta es ms de tres, la entidad no es una dimensin, sino un hecho

Disear las tablas de hechos

Cmo puede ser una tabla de grande? Existen una serie de tcnicas para reducir el tamao de las tablas de hechos.

Reducir el tamao de la tabla de hechos

1. Identificar el periodo histrico significativo para los distintos procesos, y el grado de detalle requerido. 2. Si los requisitos del negocio no necesitan todos los datos hecho detallados, se puede considerar almacenar algunos ejemplos y agregar el resto 3. Eliminar todas las columnas de la entidad hecho que no sean requeridas para responder a preguntas de toma de decisiones

Reducir el tamao de la tabla de hechos (II)

4. Asegurarse de que cada byte de cada columna se necesita 5. No usar claves automticas en las tablas hecho, a menos que se tenga la certeza de que los identificadores no cambian durante la vida del dw 6. Usar fechas en la tabla de hechos, y no construir una tabla especial para el tiempo

Disear las tablas dimensin

PRODUCTONombre, color, estilo, tamao

Desnormalizar las entidades consultadas muy a menudo para acelerar el rendimiento de las consultas (Esquemas estrella)

Seccin

PRODUCTODepartamento Seccin, departamento, negocio, nombre, color, Negocio estilo, tamao

Jerarquas

A veces no es posible desnormalizar todas las entidades en esquemas en estrella. Entidades que se relacionan entre si con relaciones muchos-a-muchos no se deberan desnormalizar en un esquema en estrella

Jerarquas

Las jerarquas son muy usadas para representar diferentes vistas. En estos casos, es ms efectivo determinar cul es la jerarqua que va a ser ms consultada. sta ser desnormalizada, y el resto permanecern como estn

Esquemas starflake

En el diseo de un data warehouse, se usa una combinacin de esquemas normalizados (esquemas snowflake) y desnormalizados (esquemas estrella) La combinacin de ambos recibe el nombre de esquemas starflake

Localizacin

Ventas

Tiempo

Localizacin

Tiempo

Localizacin

Mes

Semana

Drill up, Drill down

Drilling down:ms detalle de los datos por ejemplo aadiendo una nueva restriccin. No es slo cuestin de navegar en las jerarquas Drill up es la operacin contraria esto es eliminar cabeceras de los informes

Snowflaking

Una dimensin est snowflaked cuando los atributos de baja cardinalidad se llevan a tablas separadas. Generalmente no se recomienda en DW A veces se usa para ahorrar espacio de almacenamiento No permite hacer uso de los ndices bitmap Sin embargo existen situaciones (datos demogrficos) en las que son aconsejables.

Claves primarias y forneas

Todas las claves que se utilicen en tablas del data warehouse deben ser claves sin significado. Nunca se deben usar claves de produccin Nunca se deben usar claves con significado Facilitan los cambios

La importancia de los atributos

La calidad del Data warehouse se mide por la calidad de los atributos:Descriptivos Completos (sin valores nulos) Indexados Palabras enteras Documentados (metadata) Calidad asegurada

Degenerate DimensionLa mayora de los diseos multidimensionales estn alrededor de un documento de control: n de pedido, factura, ticket, ... Generalmente son contenedores con ms de un producto Generalmente en estos casos el grano de la tabla es producto Qu se hace con los nmeros? Se ponen en las tablas pero no tienen una dimensin con la que hacer join

Junk DimensionEn ocasiones se tienen atributos textuales y flags de distinta naturaleza que no parecen organizarse de manera coherente. La solucin no parece sencilla:Dejar los atributos en la tabla fact Hacer dimensiones separadas para cada atributo Quitar directamente estos atributos

La mejor solucin es compactarlos todos en lo que se denomina una junk dimension

Aditividad

Siempre que sea posible, los hechos de la tabla fact deberan elegirse para que sean perfectamente aditivos. Esto significa que se pueden sumar por cualquier dimensin. Las medidas de actividad (ventas) son generalmente aditivas

Aditividad

Las medidas de intensidad no siempre lo son (niveles de inventario, balance de cuentas...). Estas medidas generalmente son aditivas por todas las dimensiones menos por el tiempo. Existen otras medidas que no se pueden sumar por ninguna dimensin (temperaturas).

Familias de tablas de hechos (I)

Hay negocios con un flujo lgico con un principio y un fin (value chain):Ciclo de vida de un producto Ciclo de vida de un cliente Seguros

Familias de tablas de hechos (I) Todos estos casos se pueden enfocar de la misma manera:Se define una tabla fact y un conjunto de dimensiones asociadas para cada paso de la cadena Se deciden las dimensiones conformadas y se utilizan para cada paso de la cadena

Familias de tablas de hechos (II)

Otros negocios se organizan como crculos. En estos casos todas las entidades miden la misma transaccin:Organizaciones de salud

Ejemplo

Clave Cuenta Clave por tipo de cuenta

Tiempo Cuenta Sucursal Titular Balance Sucursal Clave de fact1 Hechos particulares Clave de factn Hechos particulares Tiempo

Clave por tipo de cuenta Atributos por tipo

Cuotas pagadas Num_transacciones Clave para unir con fact personalizada

Agregados Las tablas de agregados son resmenes que se construyen y almacenan para mejorar el rendimiento de las consultas Se genera una familia de tablas que se derivan de la tabla de hechos a nivel detallado Cada miembro de la familia representa un grado determinado de resumen en relacin a una o ms dimensiones

Tablas fact sin hechos

diseo final una tabla fact sin hechos, solo interesa el suceso en s:Afluencia de pblico Coberturas

Tablas fact sin hechos (II)

Fecha Fecha Persona Establecimiento Persona

Fecha Producto Establecimiento Promocin

Producto

Establecimiento

Promocin

Relaciones n:m relaciones n:m desde la table fact a las tablas de dimensin (titulares de cuentas bancarias,....) El problema se soluciona aadiendo una tabla puente

Roles Dimensiones comunes requiere la creacin de vistas sobre las tablas de dimensin Fin: identificar cada uno de los posibles roles de la dimensin Ciudad:

Ciudad de destino Ciudad de origen

Roles Fecha:

Fecha de entrega Fecha de venta Fecha de devolucin Larga distancia Metropolitana o Local

Operador

Agregaciones

Aceleran las consultas ms comunes costo de crear y de gestionar las agregaciones vs. beneficios

Qu es una agregacin?

La mayora de las consultas sobre un subconjunto o una agregacin de los datos detallados Ejemplo: se desea conocer las ventas de un determinado producto en un dpto. En Colombia: uso de tablas resumen

Diseando tablas resumen

Proceso similar al de las tablas de hechosDeterminar las dimensiones por las cuales agregar Determinar la agregacin de mltiples valores Agregar varios hechos en la tabla resumen Determinar el nivel de agregacin Disear el tiempo en la tabla resumen Hacer un ndice de la tabla resumen

Determinar las dimensiones por las que agregar

Dos tcnicas:Incorporar la dimensin: consultar con frecuencia datos agregados, se crea una tabla con los datos resumidos y se prescinde de la dimensin Agregar la dimensin: consultas se hacen sobre datos agregados, con lo que se pueden crear tablas resumen en los que se prescinde de la dimensin agregada

Determinar la agregacin de mltiples valores

Si existen muchas consultas que usan ms de un valor agregado sobre la misma dimensin, se puede agregar los valores requeridos en un conjunto de columnas dentro de las misma tabla resumen

Determinar el nivel de agregacin Cuando se hacen agregaciones de un nivel, se pierden datos sobre el nivel inferior Se puede considerar agregar los datos a un nivel inferior al deseado para no perder datos Ejemplo: Si se quieren datos mensuales, considerar agregar datos a nivel de semana. De este modo, no se pierde este detalle, y siempre se pueden tener los datos mensuales

Disear el tiempo en la tabla resumen

Para acelerar las consultas, se puede almacenar el tiempo de varias formas:Como una fecha fsica: lo ms recomendable Como un desplazamiento: no es apropiado. Se tarda mucho en calcular el desplazamiento Como un rango: nada recomendado

Hacer un ndice de la tabla resumen

Maximizar la velocidad de las consultas sobre las tablas resumen indexando todos los posibles accesos, es decir, considerar usar un nivel de indexacin muy alto sobre las tablas resumen