Dimensiones jerarquias

1. Jerarquías
Las dimensiones se agrupan en jerarquías mediante relaciones uno-a-muchos. Una población
agrupa a muchos clientes. Una provincia agrupa a muchas poblaciones. Una región está formada
por varias provincias. Etcétera. Las jerarquías típicas, que aparecen en cualquier sistema Business
Intelligence, son:
 Jerarquía geográfica o de clientes (país del cliente/región/ciudad/cliente)
 Jerarquía de producto (marca/familia/producto/presentación)
 Jerarquía comercial (país/zona/punto de venta)
 Jerarquía temporal (año/trimestre/mes/día)
Evidentemente, pueden existir jerarquías adicionales, o incluso puede haber diferentes maneras
de jerarquizar una misma información. En particular, es habitual la existencia de diferentes
jerarquías de producto (lo que es una "pesadez" muchas veces necesaria, otro día lo comentaré…).
Esta manera de visualizar jerárquicamente la información resulta muy natural y cómoda para los
usuarios de negocio.
Y, como siempre, podemos cometer errores modelizando las jerarquías. Éste es el error número
10 de esta serie sobre cómo construir un datawarehouse:
Error 10: Dividir las jerarquías y los niveles de las jerarquías en múltiples dimensiones
Existen dos maneras principales de modelizar las jerarquías:
 Modelo en estrella: Donde una única tabla contiene toda la información de la jerarquía.
 Modelo copo de nieve: Donde se crea una tabla para cada nivel de la jerarquía
En la base de datos de presentación (también llamado modelo dimensional) del DWH debe
preferirse siempre el modelo en estrella. Es decir, debe crearse una única tabla para cada jerarquía.

2. La misma tabla de PRODUCTOS debe tener toda la información relativa a los productos
(presentación, producto, familia, marca).
El modelo dimensional es el que ataca nuestra herramienta de Business Intelligence, por lo que
interesa que las consultas generadas sean sencillas (con pocas tablas y pocas relaciones). El
modelo en estrella es perfecto para conseguir este objetivo. Además, desaparece el problema que
generan las diferentes jerarquías en que se pueden agrupar los productos.
Sin embargo, por desgracia, no siempre es posible tener un modelo en estrella perfecto. La
herramienta de explotación puede requerir normalizar parte de una jerarquía en una tabla
independiente. Esta limitación aparece cuando diferentes "hechos" están definidos con diferente
granularidad. Por ejemplo, las ventas están a nivel de "producto", pero los objetivos de venta se
marcan a nivel de "familia". En este caso, muchas herramientas BI exigirán la existencia de una
tabla de FAMILIAS.
Finalmente, es importante destacar que además del "modelo dimensional" el DWH debe
mantener un modelo normalizado de la información (llamado "modelo relacional"). En este otro
modelo, la información sí que debe estar normalizada, unificada y limpia.
Dimensiones
Denominamos dimensiones a aquellos datos que nos permiten filtrar, agrupar o seccionar la
información. El término "dimensión" sigue teniendo un cierta connotación técnica, por lo que
muchas personas lo siguen denominando "atributo", "característica", "propiedad", "campo", o
incluso "cuadradito azul" (en el caso de una instalación de BO).
Algunas aplicaciones Business Intelligence utilizan el término "dimensión" como equivalente a
"jerarquía" (especialmente en bases de datos multidimensionales). De esta manera, se habla de la
dimensión geográfica que agrupa los diferentes niveles de continentes, países, regiones,
provincias y localidades.

3. Personalmente, prefiero reservar el término "dimension" para referirme a cada uno de los niveles
de la jerarquía.
En el modelo relacional del datawarehouse las dimensiones se almacenan en las "tablas de
dimensión", lo que nos lleva al error número 11 de nuestra serie:
Error 11: Abreviar las descripciones en las tablas de dimensión con la intención de reducir
el espacio requerido.
El espacio requerido por las tablas de dimensión es despreciable frente a lo que ocupan los
hechos. Por ejemplo, una cadena como Zara puede tener unas 5000 tiendas, y debe generar unos
3 o 4 millones de registros de venta diarios. En este y otros ejemplos que podríamos citar, también
las dimensiones de cliente o producto son despreciable frente a las ventas, los envíos o la
producción diaria.
Por lo tanto, no debemos considerar el espacio como un aspecto determinante para modelizar
las dimensiones. En particular, cada código debe tener su descripción. Las dimensiones son la
interfaz que tendrán los usuarios para navegar por la información, por lo que conviene que sean
lo más explícitas y claras posible.
Incluso debemos plantearnos la necesidad real de introducir los códigos en la capa de
presentación a los usuarios. Aunque algunos trabajadores pueden estar acostumbrados a trabajar
con los códigos de familia, las referencias o los códigos de proveedor, nadie los conoce todos, y
especialmente los nuevos empleados pueden tener dificultades para reconocerlos. Siempre son
preferibles las descripciones.
Personalmente, omito por defecto todos los códigos de la capa de presentación, y sólo cuando
algún usuario lo solicita explícitamente lo añado en el sistema. Esta manera de actuar nunca me
ha generado un problema. De hecho, es sorprendente lo rápido que se acostumbran los usuarios
a trabajar con las descripciones y lo rápido que se olvidan de los códigos con los que han
trabajado toda la vida... (una causa de esto es que con una herramienta Business Intelligence
raramente se ha de teclear un código, ya que se trabaja con clics de ratón y con listas de valores).