Marta Millan

millan@eisc.univalle.edu.co
www.eisc.univalle.edu.co/materias
El diseo de la base de datos
de un Data Warehouse
Marta Millan
millan@eisc.univalle.edu.co
www.eisc.univalle.edu.co/materias
El modelo Multidimensional
Principios bsicos
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
Tabla Tabla de de hechos hechos
Ventas Ventas
Cliente Cliente
Dimensi Dimensi n n
Almacen Almacen
Dimensi Dimensi n n
Fecha Fecha
Dimensi Dimensi n n
Producto Producto
Dimensi Dimensi n n
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
VENTAS
VENTAS
Tiendas Regin
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
Marta Millan
millan@eisc.univalle.edu.co
www.eisc.univalle.edu.co/materias
Una metodologa de trabajo para
el diseo de la base de datos de
un Data Warehose
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 Data Mart se
complica
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 conformadas
Se 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 datos
data 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.
Marta Millan
millan@eisc.univalle.edu.co
www.eisc.univalle.edu.co/materias
Aspectos de diseo a tener en
cuenta en el diseo de las tablas
de un Data Mart
4 pasos para disear
tablas de hechos
Elegir el data mart
Empezar con data marts de una fuente
Decidir el grano de la tabla de hechos
Establece lo que significa cada registro de la tabla de
hechos
Decidir las dimensiones
Decidir los hechos de la tabla de hechos
Deben 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
Desnormalizar las entidades
consultadas muy a menudo para
acelerar el rendimiento de las
consultas (Esquemas estrella)
PRODUCTO
Nombre, color,
estilo, tamao
Seccin
Departamento
Negocio
PRODUCTO
Seccin, departamento,
negocio, nombre, color,
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
Ventas
Localizacin Tiempo
Localizacin
Localizacin
Tiempo
Semana Mes
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 Dimension
La 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 Dimension
En 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
Tiempo
Cuenta
Sucursal
Titular
Balance
Cuotas pagadas
Num_transacciones
Clave para unir con
fact personalizada
Tiempo
Sucursal
Clave Cuenta
Clave por tipo de cuenta
Clave por tipo de
cuenta
Atributos por tipo
Clave de fact1
Hechos
particulares
Clave de factn
Hechos
particulares
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
Persona
Establecimiento
Fecha
Producto
Establecimiento
Promocin
Fecha
Persona
Establecimiento
Producto
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
Operador
Larga distancia
Metropolitana o Local
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 hechos
Determinar 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