1. Miguel Orquera
Basado en el libro: The Data Warehouse Toolkit
Second Edition. The Complete Guide to Dimensional
Modeling. Ralph Kimball. Margy Ross. 2002
2. CONCEPTOS Y TERMINOLOGIA DEL
MODELAMIENTO DIMENSIONAL
Hay un amplio acuerdo entre los usuarios de DW de que el
modelamiento dimensional es la mejor forma de presentar
la información porque es la mejor manera de reunir las
principales metas de diseño:
Presentar la información a los usuarios en la forma más
simple posible.
Retornar los resultados a los usuarios lo más rápido
posible.
Proveer información relevante que guarde pistas de los
procesos subyacentes.
3. CONCEPTOS Y TERMINOLOGIA DEL
MODELAMIENTO DIMENSIONAL
Albert Einstein capturó la principal razón por la que se
usa un modelo dimensional cuando dijo: “Hacer las
cosas tan simples como sea posible, pero no demasiado
simples”. Entonces, la simplicidad es relativa. El
modelo dimensional es mucho más fácil de entender
para los usuarios que un sistema basado en un modelo
normalizado de un sistema fuente típico, aunque un
modelo dimensional típicamente contiene exactamente
la misma información que un modelo normalizado.
4. La información se agrupa
en categorías
Un modelo dimensional tiene mucho menos tablas y
la información es agrupada en categorías de negocio
coherentes que tienen sentido para los usuarios.
Estas categorías ayudan a los usuarios a navegar por
el modelo ya que categorías enteras pueden ser
pasadas por alto si no son útiles para un
determinado análisis.
5. No es tan simple
Desafortunadamente, “tan simple como sea posible”
no quiere decir que el modelo dimensional
necesariamente es simple. El modelo debe reflejar el
negocio, y los negocios son típicamente complejos. Si
se simplifica demasiado, para presentar solo datos
agregados, el modelo pierde información que es
crítica para entender el negocio. No importa como se
modelen los datos, la complejidad intrínseca de los
datos contenidos es en último término la razón por la
que muchas personas utilizan reportes estructurados
y aplicaciones analíticas para acceder al DW.
6. Las consultas son más
rápidas
En el ambiente relacional, el modelo dimensional ayuda al
rendimiento en las consultas a causa de la desnormalización
involucrada en la creación de dimensiones. Pre juntando varias
jerarquías y tablas de consulta, el optimizador debe consideran
muchas menos junturas y crear muy pocas tablas temporales
intermedias. Las consultas utilizando el SQL Server relacional
funcionan mucho mejor sobre una estructura dimensional que
sobre una estructura completamente normalizada.
En un ambiente de Análisis Services OLAP, el motor está
específicamente diseñado para soportar modelos
dimensionales. El rendimiento se logra en gran parte pre
juntando datos relacionados en las dimensiones.
7. ¿Qué es un modelo
dimensional?
Un modelo dimensional consta de una (o varias)
tablas de hechos central y sus dimensiones asociadas.
El modelo dimensional es también llamado modelo
en estrella porque es similar a una estrella, con la
tabla de hechos en el medio y las dimensiones
formando las puntas de la estrella.
Desde la perspectiva de un modelo de datos
relacional, el modelo dimensional consiste en una
tabla de hechos normalizada, con tablas
dimensionales desnormalizadas.
8. TABLA DE HECHOS
La tabla de hechos es la principal de un modelo
dimensional; es allí donde están almacenadas las
mediciones numéricas de rendimiento del negocio.
Se llama hecho a una medida del negocio. Por
ejemplo, en una cadena de supermercados, una tabla
de hechos registra cómo se venden los productos,
anotando la cantidad de cada producto que se vende
y la cantidad de dinero que se obtiene por las ventas,
cada día, para cada producto en cada tienda.
9. Tabla de hechos de
Ventas Diarias
FactVentasDiarias
FechaCodigo (FK)
ProductoCodigo (FK)
TiendaCodigo (FK)
CantidadVendida
ValorEnDolares
10. Medidas del negocio
Una medida es tomada en la intersección de todas las
dimensiones (día, producto y tienda). Esta lista de
dimensiones define la granularidad de la tabla de
hechos y nos dice cuál es el alcance de las
mediciones.
Una fila en una tabla de hechos corresponde a una medida.
Todas las medidas en la tabla de hechos deben tener la
misma granularidad.
11. Los hechos son numéricos
y sumables
Los hechos más usados son numéricos y sumables,
tales como la cantidad en dólares de cada venta. El
que sean sumables es muy importante porque en las
aplicaciones de DW casi nunca se recupera una sola
fila de la tabla de hechos, más bien se recuperan
cientos, miles o millones de filas de hechos a la vez, y
lo mejor que se puede hacer con tantas filas es
sumarlas o resumirlas.
En el ejemplo, no importa qué porción de la base de
datos el usuario elija, podemos sumar las cantidades
y dólares y obtener un total válido.
12. Hechos semisumables y no
sumables
También hay hechos semisumables y aún otros que
no son sumables. Los semisumables pueden sumarse
solo en ciertas dimensiones, mientras los no
sumables no lo son en ninguna circunstancia. Con
los no sumables se deben usar contadores y
promedios si se quiere hacer un resumen de las filas
o se reduce a imprimir las filas de hechos de una en
una. Esto sería un ejercicio aburrido en una tabla de
hechos con un billón de filas.
13. Medidas tipo texto
Es posible que la medida de un hecho sea textual, pero es
muy raro. Cuando esto sucede, el texto es una medida de
algo, y son textos que provienen de una lista predefinida.
Es preferible poner medidas textuales en las dimensiones
porque pueden ser correlacionados con otros atributos
textuales dimensionales y ahorran mucho espacio. No se
debe almacenar texto redundante en las tablas de hechos.
A menos que cada fila de la tabla de hechos tenga texto
único, permanece en la tabla de dimensiones. Un hecho
con datos en texto libre no es posible en un DW porque es
imposible de analizar.
14. Las tablas de hechos son
muy grandes
Si no hay ventas un determinado día, en una
determinada tienda para un determinado producto,
esa fila no se registra en la tabla de hechos. No se
debe llenar la tabla de hechos con ceros, pues no
sirven para el análisis. A pesar de esto, la tabla de
hechos consume normalmente más del 90% del
espacio de la BD dimensional. Las tablas de hechos
tienden a ser profundas en términos del número de
filas, pero estrechas en el número de columnas.
15. Granularidad de las tablas
de hechos
La granularidad de las tablas de hechos cae en una
de las tres categorías: transacción, imágenes
periódicas y acumulación de esas imágenes. Las
tablas de hechos con granularidad a nivel de
transacción son las más comunes.
16. Claves en las tablas de
hechos
Todas las tablas de hechos tienen dos a más claves foráneas que
conectan a las claves primarias de las tablas dimensionales. Por
ejemplo, la clave de producto en la tabla de hechos empatará
con la clave de un producto de la tabla dimensional Producto, a
través de la integridad referencial.
La tabla de hechos tiene su propia clave primaria conformada
por un grupo de claves foráneas que es llamada clave
compuesta o concatenada. Cada tabla que expresa una relación
con cardinalidad muchos a muchos es una tabla de hechos, las
demás son tablas de dimensiones.
En un modelo dimensional, las tablas de hechos expresan una relación
de cardinalidad muchos a muchos entre dimensiones.
17. Clave primaria en una
tabla de hechos
Solamente un subconjunto de las claves foráneas que
tiene una tabla de hechos basta para identificar a
cada fila. De una docena o más de claves, pueden ser
2 o 3. Por ejemplo, código de venta y código de
producto. En la mayoría de casos no hay ninguna
ventaja en crear una clave primaria con un código en
la tabla de hechos, pues la tabla se hace más grande,
y un índice sobre este atributo no tiene ningún valor.
Sin embargo, puede ser útil para facilitar la
administración del sistema y cuando puede haber
varias filas con todos los valores iguales.
18. TABLAS DE
DIMENSIONES
Son la compañía integral de una tabla de hechos,
contienen las descripciones textuales del negocio. En un
modelo dimensional bien diseñado, las tablas
dimensionales contienen muchas columnas o atributos
que describen las filas. Se debe incluir tantas
descripciones textuales como sea posible. Es común que
una tabla dimensional tenga entre 50 y 100 atributos.
Tienden a ser pequeñas en cuanto al número de filas
(mucho menos de 1 millón) pero son muy extensas
horizontalmente, con muchas columnas. Cada dimensión
tiene una clave primaria única, que se enlaza a través de
integridad referencial a cualquier tabla de hechos a la cual
esté juntada.
19. Tabla de la dimensión
Producto
DimProducto
ProductoCodigo
ProductoDescripcion
Numero de referencia (SKU)
Marca
Categoría
Departamento
Tipo de empaque
Tamaño de empaque
Contenido de grasa
Tipo de dieta
Peso
Unidades de medida
Tipo de almacenamiento
Vida útil de la caja
Ancho de la caja
Alto de la caja
Profundidad de la caja
20. Los atributos de las
dimensiones
Los atributos de las dimensiones son utilizados en
condiciones de consultas, agrupamientos y reportes
etiquetados, y son claves para hacer al DW usable y
entendible. El DW es tan bueno como son los atributos
dimensionales, depende de la calidad y profundidad de
sus atributos dimensionales. Mientras más elementos y
terminología del negocio se incorporen en los atributos
dimensionales, mejor es el DW.
Las tablas dimensionales son los puntos de entrada a las tablas
de hechos. Atributos dimensionales robustos llevan a una
capacidad de análisis robusto. Las dimensiones implementan la
interfaz de usuario del DW.
21. Atributos de las
dimensiones
Los mejores atributos son textuales y discretos, deben ser
palabras reales y completas en vez de abreviaciones.
Atributos típicos para una dimensión producto pueden
incluir una descripción corta (10 a 15 caracteres) o larga
(40 – 50 caracteres). Ejemplo: tipo de producto, categoría
de producto, tipo de empaque, tamaño, y otras
numerosas características. Aunque el tamaño de un
producto se expresa en números, es un atributo
dimensional porque se comporta como una descripción
textual antes que como un valor sumable. El tamaño es un
descriptor discreto y constante de un producto.
22. ¿Atributo de una dimensión o de
una tabla de hechos?
Algunas veces en el diseño no está claro si un dato
numérico que es extraído de un sistema fuente pertenece
a una dimensión o a una tabla de hechos. Para tomar la
decisión debe preguntarse si ese atributo tiene muchos
valores y éstos servirán para hacer cálculos, si es así,
pertenece a una tabla de hechos, o, si es una descripción
discreta que es más o menos constante y participa en las
condiciones de búsqueda, es un atributo dimensional. Por
ejemplo, el costo estándar de un producto puede verse
como un atributo constante del producto, pero puede
cambiar varias veces, y también se puede decidir tratarlo
como un hecho medible.
23. Códigos de las aplicaciones
operacionales
Se debe tratar de minimizar el uso de códigos en una
tabla dimensional reemplazándoles con atributos
textuales mas explícitos. Se debe tener decodificación
estándar para los códigos operacionales disponibles como
atributos dimensionales para que las etiquetas de las
consultas y reportes sean consistentes. Algunos códigos
operacionales o identificadores tienen una significación
específica del negocio para los usuarios, o se requieren
para regresar al sistema operacional, en estos casos, los
códigos deben aparecer como atributos de las
dimensiones, acompañados de su descripción explicita
textual.
24. Códigos con
información adicional
En otros casos, el código puede llevar información
adicional del negocio, por ejemplo, los primeros dos
dígitos pueden identificar la línea del negocio, los
siguientes dos dígitos indican la región, etc. Aquí se
debe extraer de los códigos esa información y
ponerlas como atributos adicionales que puedan ser
filtrados, agrupados y reporteados con facilidad.
Las tablas dimensionales a menudo representan
relaciones jerárquicas dentro del negocio.
25. Jerarquías
En el ejemplo de la tabla dimensional Producto, los
productos se agrupan en tipos, y los tipos en categorías.
Para cada fila en la dimensión Producto se almacena el
tipo y la categoría asociada con cada producto. Se puede
ver que la información descriptiva jerárquica tiene
redundancia, pero se hace esto para facilitar las consultas
y mejorar el rendimiento. Las tablas dimensionales son
altamente desnormalizadas, y como su tamaño es muy
pequeño en relación con las tablas de hechos, el aumento
del almacenamiento por la redundancia no es
significativo.
27. Esquema estrella
En la figura, la tabla de hechos que consiste de
medidas numéricas está unida a un set de tablas
dimensionales que contienen atributos descriptivos.
Este tipo de esquema se le conoce como esquema
estrella.
La primera cosa que se nota en el esquema es su
simplicidad y simetría, lo que hace más fácil
entender y navegar. Además, el reducido número de
tablas y el uso de los descriptores de negocio hacen
menos probable que se produzcan errores.
28. Modelos dimensionales
La simplicidad también trae beneficios en el
rendimiento, ya que el optimizador procesará las
consultas más eficientemente porque tienen pocas
junturas.
Los modelos dimensionales son muy adaptables a
los cambios, el marco de trabajo predecible de un
modelo dimensional resiste cambios inesperados en
la conducta de los usuarios. Cada dimensión es
equivalente, todas las dimensiones son
simétricamente iguales puntos de entrada a la tabla
de hechos.
29. Granularidad de los
hechos
Mientras más granularidad exista y se tengan datos
más atómicos, mas dimensionalidad existe. Los datos
atómicos, es decir, que no han sido resumidos, son
los más expresivos y son la base de diseño de las
tablas de hechos para resistir consultas de los
usuarios no esperadas.
30. Los cambios se hacen
fácilmente
Se puede ir agregando nuevas dimensiones al
esquema. También se puede agregar nuevos e
inesperados hechos a la tabla de hechos. También se
puede incrementar nuevos atributos en las tablas
dimensionales, o aumentar un nuevo nivel de
granularidad desde un punto en el tiempo, todo esto
utilizando el comando de SQL ALTER TABLE, sin
tener que recargar los datos, y sin que se afecten las
aplicaciones que están funcionando.
32. Facilidades para
reportes
Otra manera de ver como se complementan entre
tablas de hechos y dimensiones es verlas traducidas
en un reporte. Como se ve en la figura, los atributos
dimensionales aportan los títulos de los reportes,
mientras que las tablas de hechos proporcionan los
valores numéricos de los reportes.
34. Modelo dimensional de ventas
en una cadena de supermercados
El modelo le permite al usuario cruzar el negocio
para analizar las ventas al detalle desde varias
perspectivas. Los administradores pueden ver las
ventas por producto para diferentes tiendas y en
diferentes fechas, los gerentes de las tiendas pueden
ver las ventas por fecha y por cajero, los
planificadores de tiendas pueden ver a las ventas por
tipo de tienda y por localización. Como este modelo
es razonablemente robusto, un gran supermercado
podría tener un poco mas de dimensiones, clientes
en particular, y muchos mas atributos.
35. Modelo dimensional de ventas
en una cadena de supermercados
En la figura, los campos marcados con PK son las
claves primarias. En un modelo dimensional las
claves primarias de las dimensiones son
implementadas con un solo campo. Las claves
foráneas FK controlan la integridad referencial. El
campo DD es una dimensión especial degenerada, la
cual es explicada luego.
Para captar el concepto de dimensiones y hechos, es
útil ver ejemplos de modelos dimensionales de una
variedad de industrias y procesos de negocios.
37. Modelo dimensional del proceso
de vuelos en una aerolínea
Las dimensiones han sido llenadas los suficientes
para dar sentido a sus contenidos. Los planeadores
de rutas pueden ver los vuelos por aeropuerto, los de
logística pueden ver la utilización de aeronaves,
marketing puede ver el comportamiento de los
viajeros frecuentes, la actividad de los vuelos por
clase y tarifas base, los de ventas pueden ver el
comportamiento de los canales de ventas. Hay algo
para todos en este modelo dimensional.
