erDiagram
DIM_EMPLEADOS {
numero id_empleado PK
texto nombre
texto apellido
texto desc_territorio
}
DIM_CLIENTES {
numero id_cliente PK
texto nombre
}
DIM_PRODUCTOS {
numero id_producto PK
texto nombre
texto categoria
numero precio_unitario
texto proveedor
}
DIM_TIEMPO {
numero id_tiempo PK
numero anio
numero mes
numero trimestre
texto nombre_mes
numero dia
texto dia_semana
}
FACT_FACTURAS {
numero id_tiempo FK
numero id_cliente FK
numero id_producto FK
numero id_empleado FK
numero total
}
DIM_TIEMPO ||--o{ FACT_FACTURAS: fecha
DIM_PRODUCTOS ||--o{ FACT_FACTURAS: producto
DIM_CLIENTES ||--o{ FACT_FACTURAS: cliente
DIM_EMPLEADOS ||--o{ FACT_FACTURAS: empleado
3 Modelado analítico
El modelado cubre una necesidad muy real y operativa. El modelado, tal y como lo hemos vista hasta ahora permite eliminar redundancias, hacer la gestión de datos coherente con los requisitos del negocio y aún así, sacar el máximo provecho del sistema. Sin embargo no está orientado a ser sencillo de operar o entender por parte de aquellos que quieren extraer conocimiento de los datos.
Por ello, ya que de todos modos tenemos que disponer un sistema pensado para analítica, por qué no darle una forma que haga la información más fácil de consumir. Aunque este proceso no está falto de trabajo. William (Bill) Inmon es reconocido como el padre del concepto almacén de datos o data warehouse (Inmon 2005). Un data warehouse es esencialmente ese repositorio donde residen todos los datos de la compañía, no de forma operacional, si no para poder realizar consultas, análisis e informes sobre ellos. Esto permite además unificar las distintas fuentes para dar una visión cohesionada de los procesos en la empresa y sus datos asociados.
Sin embargo, el modelo de Inmon requería una consolidación entre fuentes que es difícil de construir. Además, el ritmo al que operan las distintas unidades hace que existan urgencias de datos que “no pueden esperar”. Un enfoque algo más pragmático que permitía enfocarse en necesidades concretas es asociado con Ralph Kimball, cuyo Data Warehouse Toolkit (Kimball y Ross 2013) sigue siendo la referencia canónica del modelado dimensional. Fue años más tarde y quizás el progreso de la tecnología hacia los 90 hizo posible el enfoque de Kimball pero sin duda es uno de los modelados más comunes cuando nos acercamos a las áreas de consumo de datos. De hecho, el término Business Intelligence se inicia en esta época gracias al foco en el warehousing y el modelado analítico.
3.1 Modelado dimensional
El modelado dimensional, en estrella o también referido Kimball, se enfoca en disponer las dimensiones de corte de los análisis en tablas muy próximas a los conceptos de entidad que comentamos en el modelado Entidad-Relación y los hechos, acontecimientos en otra entidad de crecimiento más frecuente y vertical.
El enfoque se basa en que las dimensiones son instancias de datos poco cambiantes (listado de empleados, clientes, productos,…) mientras que los hechos crecen de forma constante (en nuestro caso las ventas facturadas). Aunque esto no siempre pasa así y podemos tener información cambiante en nuestras dimensiones como veremos más adelante.
Las dimensiones cubren aspectos relativos a puntos de corte en nuestros análisis:
- quién
- qué
- dónde
- cómo
Mientras que los hechos son los hechos cuantificables:
- cuántos
- en total
- promedio
De modo que la pregunta de negocio
¿cuantos pedidos que contengan salsa de tomate hemos tenido en este último trimestre?
Se aterriza indicando:
- DIM_PRODUCTOS: salsa de tomate
- DIM_TIEMPO: último trimestre
- FACT_FACTURAS: número de facturas asociadas a DIMs
Pudiendo variar únicamente la métrica (cuantas unidades, cuantos dolares, qué porcentaje de descuentos, …). Esto hace que muchas consultas puedan componerse de forma aditiva en base a preguntas frecuentes, atributos concretos usados frecuentemente, agregadas de forma distinta.
3.1.1 SCD
El concepto de Slowly Changing Dimension (SCD) nos obliga a indicar distintos valores para nuestras dimensiones en base a una condición temporal. Un producto que cambia de nombre a una fecha dada, un cliente que cambia de apellidos,… Existen varias modalidades con las que podemos intentar paliar este hecho, y una de las más comunes es historificar los cambios con fechas de efecto, también conocido como dimensión de tipo 2.
erDiagram
DIM_EMPLEADOS {
numero id_empleado PK
texto nombre
texto apellido
texto desc_territorio
fecha efectivo_desde
fecha efectivo_hasta
}
DIM_CLIENTES {
numero id_cliente PK
texto nombre
fecha efectivo_desde
fecha efectivo_hasta
}
Esto nos obliga a añadir condiciones que filtren los registros vigentes, o indiquen la fecha de efecto pudiendo así consultar la información como hubiera sido consultada en un intervalo entre fechas efectivas. Esto sin duda complica la composición de consulta, aunque nos permite copar con estos cambios.
3.2 Modelado de copo de nieve
El modelo de copo de nieve extiende el modelo estrella arriba mencionado a jerarquías de dimensiones. Pensemos que por ejemplo, cuando hablamos del territorio que cubre un empleado, esto se refiere a una entidad o dimensión en esta etapa, donde se determinan todos los territorios existentes.
erDiagram
DIM_TERRITORIOS {
numero id_territorio PK
texto desc_territorio
}
DIM_EMPLEADOS {
numero id_empleado PK
texto nombre
texto apellido
texto id_territorio FK
}
DIM_CLIENTES {
numero id_cliente PK
texto nombre
}
DIM_PROVEEDORES {
numero id_proveedor PK
texto nombre
texto direccion
}
DIM_CATEGORIAS {
numero id_categoria PK
texto categoria
}
DIM_PRODUCTOS {
numero id_producto PK
texto nombre
numero precio_unitario
numero id_categoria FK
numero id_proveedor FK
}
DIM_TRIMESTRES {
numero id_trimestre PK
texto trimestre
numero num_trimestre
}
DIM_MESES {
numero id_mes PK
texto mes
numero num_mes
}
DIM_TIEMPO {
numero id_tiempo PK
numero anio
numero id_mes FK
numero id_trimestre FK
}
FACT_FACTURAS {
numero id_tiempo FK
numero id_cliente FK
numero id_producto FK
numero id_empleado FK
numero total
}
DIM_TERRITORIOS ||--o{ DIM_EMPLEADOS: en
DIM_CATEGORIAS ||--o{ DIM_PRODUCTOS: pertenece
DIM_PROVEEDORES ||--o{ DIM_PRODUCTOS: provee
DIM_TRIMESTRES ||--o{ DIM_TIEMPO: en
DIM_MESES ||--o{ DIM_TIEMPO: en
DIM_TIEMPO ||--o{ FACT_FACTURAS: fecha
DIM_PRODUCTOS ||--o{ FACT_FACTURAS: producto
DIM_CLIENTES ||--o{ FACT_FACTURAS: cliente
DIM_EMPLEADOS ||--o{ FACT_FACTURAS: empleado
Si conseguimos tener dimensiones comunes a todas las áreas de negocio, esto nos da una consolidación de la información con poca variación entre unidades. Sin embargo, suele ser común la variación entre unidades de esas dimensiones comunes a nuestra actividad. El control sobre estas dimensiones clave ha hecho que la gestión de datos maestros se convierta en una actividad en si misma.
3.2.1 Gestión de datos maestros
La gestión de datos maestros (Master Data Management, MDM) es una disciplina tecnológica en la que las empresas y los departamentos de TI colaboran para garantizar la uniformidad, la precisión, la gestión, la coherencia semántica y la responsabilidad de los activos de datos maestros compartidos de la empresa.
Es un marco utilizado por empresas que buscan aprovechar sus datos de manera más efectiva, asegurando la precisión, coherencia y accesibilidad de los datos comerciales centrales, como información de clientes, detalles de productos o registros de proveedores.
MDM se define como una disciplina en la que el negocio y la tecnología trabajan juntos para asegurar la uniformidad, la exactitud, la custodia, la consistencia semántica y la responsabilidad de los activos de datos maestros oficiales de la empresa.
3.3 Data Marts
Siendo prácticos, por mucho que dispongamos de toda la información de una empresa, solo necesitaremos ciertas dimensiones y hechos para conformar nuestras métricas y realizar nuestro análisis. Habitualmente la organización se dispone de manera que un subconjunto de los datos es accesible por la unidad que los necesita y a ese subconjunto lo conocemos como data mart. Dónde reside y cómo se modela no cambia, pero es el nombre que se le atribuye a esas colecciones de tablas que permiten a la unidad gestionar los datos necesarios en el universo de datos disponibles.