La construcción de un modelo de Bi no es algo que debe tomarse a la ligera e ir cargando tablas en Power Bi e intentando relacionar como estén. Ciertamente escribo este post para que comprendan una forma de modelado que puede ayudar a mejorar la performance de su bi y ahorrarles muchos dolores de cabeza en peticiones del cliente y DAX. Pensar en un modelo es tener un diseño de datawarehouse que luego puede ser llevado a una capa semántica (SSAS o Power Bi) o podríamos aplicarla en ésta última capa en caso que no tengamos un Warehouse.
En esta oportunidad vamos a construir un modelo de estrella.
CONTEXTO
La realidad inicia en bases de datos normalizadas donde toda la información está al mínimo evitando todo tipo de replicaciones y muy relacionada entre si.
Nuestro objetivo para concretar el modelo es denormalizar este conjunto tomando solo aquellas tablas que estén alineadas al objetivo o área de negocio en la cual diseñaremos un modelo.
Los modelo de estrellas consisten en dos tipos de tablas construidas
Tablas de hecho: son tables que mantienen los datos numéricos o calculables que podrían ser usados como agregaciones en los reportes posteriormente.
Tablas dimensiones: son tablas que mantienen la información descriptiva que podría ser usada como segmentación de datos sobre la tabla de hecho.
Tabla Dimensión
Una tabla dimensión is una tabla llena de campos descriptivos y ninguno calculable.
Ésta tabla necesita estar relacionada a las otras tablas incluyendo dimensiones y hechos que van a ser filtrados. Por tanto esta tabla necesita tener un campo de identificador único (semejante a PK). Éste campo puede ser una combinación de varios siempre y cuando llegue a ser único para cada fila. Por ejemplo: la tabla Customer de AdventureWorks puede ser identificada por la columna CustomerKey como se ve a continuación;
Ésta columna, de la dimensión Customer, será relacionada de uno a muchos (1-*) contra una tabla de hecho.
La mayoría de las veces las relaciones entre dimensiones y hechos debería ser uno a muchos. Son muy pocos los casos de uno a uno. Entonces quedaría así:
La dimensión es una tabla llena de campos descriptivos y categóricos, donde uno o más campos de su identificador único tiene muchos hechos que contar.
Si más de una columna es la identificación única de la tabla, deberías hacer una combinación de ambas, siempre y cuando pueda hacerlo también el hecho a contar.
Tabla de Hecho
La tabla de hecho intenta hacerle fidelidad a su nombre y contar un hecho que normalmente ocurre a lo largo del tiempo. Un hecho es un campo numérico que generalmente será agregado y utilizado en las visualizaciones. Ejemplos: columnas Sales Amount, Order Quantity, Profit, Cost, etc.
La tabla de hecho esta repleta de esos valores. Entonces si pensaste en una tabla de hecho como la siguiente imagen:
Estabas equivocado. La imagen puede representar la definición de una tabla de hecho, pero le falta algo muy importante. Los datos de dicha tabla deben ser agrupados o relatados por las dimensiones. Por ejemplo: deberías poder ver como fueron las Ventas (Sales Amount) para cada Categoría de Producto, Cliente, Tienda, etc. Con la estructura de la tabla anterior no podríamos verlo, pero con la siguiente si podremos. Tengamos en cuenta que una de las dimensiones más claves en la construcción y bajo la cual se cuenta el hecho es la Fecha, que requerirá su propia tabla. En este enlace puedes ver como crear una.
La imagen muestra una tabla de hecho con calves/keys de las tablas dimensiones.
Una tabla de hecho incluye dos tipos de campos; campos de dimensiones (normalmente clave o combinación de claves para relacionarla), y hechos (campos numéricos que serán agregados).
Normalmente, la tablas de hecho son nombradas como el principal hecho a relatar. Por ejemplo, la tabla anterior dedicada a analizar datos de ventas podría llamarse Hecho_Ventas, en ingles Fact_Sales.
La granularidad de una tabla de hecho
Cuando construimos una tabla de hecho, queremos tener un detalle de la máxima granularidad detallada a la hora de relatar ciertos hechos. Por ejemplo:
En un caso como adventureworks, cuando queremos analizar ventas, nuestra máxima granularidad sería una tabla de detalle de ventas mezclada con los ids de sus dimensiones aplicados en una gran consulta.
Hecho_Ventas. tendría dimensiones como las pintadas en amarillo.
El detalle de la tabla sería un registro por combinación de Product, Order Date, Customer, Promotion, and Sales Territory.
Mientras más columnas tengas de granularidad en tu tabla de hecho, significa que más dimensiones tenes conectada a ella y más poder de filtrabilidad en los reportes de Power Bi. Por otro lado, más columnas puede significar más filas y necesitarías más memoria para almacenar o navegar los datos.
Si construimos la tabla de hecho con máxima granularidad, más detallada tendremos las dimensiones. Pero tengamos en mente que en grandes volúmenes de datos haya que diferenciar si realmente es necesaria una dimensión para evitar el crecimiento masivo de filas.
Modelo de estrella
Se llama modelo de estrella cuando hay un relación directa entre una tabla de hecho y cada una de sus dimensiones. Una tabla de hecho puede tener muchas relaciones, las cuales irán directo a cada dimensión, lo cual se vería algo así:
Cabe aclarar que el modelo de estrella no tendrá siempre cinco dimensiones quedando igual que la imagen. Puede tener tanto más como puede tener menos. La importancia no esta en la cantidad de dimensiones sino en la relación directa entre el hecho con sus dimensiones.
La importancia del Modelo de estrella
Hoy, el modelo de estrella es la mejor forma de diseñar un modelo de datos para reportes. De él, se obtiene la mejor performance y flexibiilidad entre los modelos. No siempre tendremos la posibilidad de tener modelos de un solo hecho. Los requerimientos complejos que se solicitan hoy en día podrían llevarnos a tener dos hechos que comparten dimensiones. Dos estrellas en un mismo modelo. El modelo de estrella es como un conductor de orquesta. Una orquesta sin conductor puede tocar música, como Power Bi puede implementarse sin un modelo de estrella. Pero, la música no estará sincronizada y no será lo mejor que puede lograrse pudiendo no tener el resultado esperado por la audiencia. Sin embargo, si Power Bi implementa un modelo de estrella, podría tocar la música a sus máximas capacidades respondiendo por todos los requerimientos de su audiencia.
Como diseñar un modelo de estrella
Ser un maestro de diseño de modelos de estrella puede tomar años de experiencia. Hay ciertas reglas fundamentales para aprender al inicio y luego se aprenden tips o trucos en el modo de resolver de cada uno. Hay libros y cursos explicando mucho respecto de ellos y como construirlos. No es posible abarcar todo en un solo artículo. Aún así, puedo mencionar unas reglas que ayuden al inicio.
Definir Dimensiones
El diseño de todo en una gran tabla no es flexible ni tiene buen rendimiento. Las dimensiones son tablas descriptivas que van a describir los información involucrada en un hecho, como productos de una venta. Es bueno pensar que las dimensiones pueden ser entidades, objetos como categorías por la cual relatar el hecho. No necesariamente serán únicas como Materia y Carrera en casos académicos, tal vez Materia y Carrera pueda ser una única dimensión filtrable en cadena. Una forma de visualizarlo es comprender que los campos de las dimensiones son normalmente usados en segmentadores de datos (filtros) o ejes de gráficos de barra/lineas.
Definir Hecho
Son el corazón del modelo. Esta profundas y largas tablas pueden hacer tu modelo muy grande y complejo de rendimiento. Los hechos explican una acción ocurriendo, la mayoría de las veces durante el tiempo. Las mismas incluyen campos que juegan el rol de valores y medidas en las partes visuales que construiremos en Power Bi. Recordemos que llamamos hecho a un número que puede ser agregado en un gráfico.
Espero que esta introducción les sirva para iniciar este camino de modelado de datos. Si quieren profundizar más en el tema recomiendo el libro de modelado de Kimbal o el curso de data model de SQLBI.