Modelatge de dades a Power BI: consideracions per a un model ràpid, fiable i governat

La majoria dels informes de Power BI lents, difícils de mantenir o amb xifres que no quadren no tenen un problema de visualització: tenen un problema de model. Un bon model fa que les consultes volin, que el negoci entengui el que veu i que cada indicador signifiqui el mateix a tota l'organització. Aquestes són les consideracions que apliquem en cada projecte.

1. Comença pel model en estrella

El modelatge dimensional de Ralph Kimball continua sent la referència per a l'analítica, i el motor de Power BI hi està optimitzat. Té dues peces:

• Taules de fets: els esdeveniments del negoci (vendes, comandes, sinistres, hores) amb les seves mesures numèriques, si pot ser additives, i les claus a les dimensions. Responen a «quant?».
• Taules de dimensions: el context descriptiu amb què es filtra i s'agrupa (client, producte, data, territori). Responen a «qui, què, on, quan i com?».

La regla pràctica: les dimensions filtren i agrupen; els fets es resumeixen.

Estrella o floc de neu. En l'estrella, cada dimensió és una sola taula desnormalitzada; en el floc de neu, les dimensions es divideixen en diverses taules (per exemple, producte → subcategoria → categoria). El floc de neu estalvia una mica d'espai, però multiplica les relacions i complica el model. A Power BI, l'opció per defecte és l'estrella: si tens un floc de neu a l'origen, aplana'l en la càrrega.

2. Defineix el gra abans que res

El gra és el nivell de detall de la taula de fets: «una fila per línia de comanda», «una fila per pòlissa i dia». És la primera decisió, i la més cara de canviar després. Un gra massa agregat impedeix respondre preguntes de detall; un de barrejat (files de diferent nivell a la mateixa taula) produeix sumes incorrectes. Cada dimensió ha de ser coherent amb aquest gra.

3. Normalitza el just

La normalització (primera, segona i tercera forma normal) evita duplicitats i inconsistències, i és imprescindible en els sistemes transaccionals i en la capa on es cura la dada. Per a l'explotació, el criteri canvia:

• Dades atòmiques sempre: res de camps amb llistes («600111222, 600333444») ni adreces en un únic text.
• Separa entitats quan els seus atributs no depenen de la clau del fet (el nom del producte no pertany a la línia de comanda).
• No separis per separar: una jerarquia com país → regió → ciutat va en una sola dimensió, llevat que cada nivell tingui molts atributs propis.

4. Cuida les claus i els tipus de dada

• Claus numèriques millor que de text: ocupen menys, es comprimeixen millor i relacionen més ràpid.
• Claus substitutes a les dimensions, per no dependre dels codis del sistema d'origen, que poden canviar.
• Compte amb els autonumèrics generats a la base de dades: si la taula es recrea o es carrega en un altre entorn, la mateixa fila pot rebre una altra clau i trencar validacions i migracions. Millor claus deterministes generades en el procés de càrrega.
• Dates com a clau entera YYYYMMDD per relacionar amb el calendari, i convé comprovar-ne la precisió (té hora?, zona horària?) i homogeneïtzar a UTC en integracions internacionals.
• El tipus correcte per a cada dada: una data desada com a text obliga a fer conversions i espatlla el rendiment; un codi postal és text, no un nombre.

5. Decideix com desar la història (SCD)

Els sistemes operacionals sobreescriuen: si un client canvia d'adreça, l'anterior desapareix. Per analitzar l'evolució, auditar o reconstruir el context d'una decisió, Kimball defineix les dimensions lentament canviants (SCD):

Tipus	Què fa	Quan utilitzar-lo
0	Manté el valor original	Atributs immutables
1	Sobreescriu	Correccions o atributs la història dels quals no interessa
2	Fila nova per cada canvi, amb data d'inici i de fi	Història completa; el més habitual en magatzems de dades
3	Columna amb el valor anterior	Només un canvi i pocs camps
4	Taula de vigents i taula d'històric	Dimensions molt grans en què gairebé sempre es consulta el que és vigent
6 i 7	Variants estrictes del tipus 2 amb versió i clau física pròpia	Diversos canvis el mateix dia, reprocessaments o auditoria estricta

Dos consells pràctics per al tipus 2: utilitza una data de fi «infinit» (31/12/9999) en lloc de nuls, que compliquen els filtres, i afegeix un indicador de registre vigent en comptes de dependre d'un número de versió que obliga a calcular màxims en cada consulta. I documenta al catàleg quins atributs desen història i quins no.

6. Model governat i model aplanat

No hi ha un únic model perfecte, sinó dues capes amb funcions diferents:

	Model governat (capa gold)	Model aplanat (capa de servei)
Per a què	Auditoria, nucli corporatiu, curació de la dada	Quadres de comandament d'ús massiu, immediatesa, menys cost de còmput
Com	Estrella amb entitats ben definides, regles de qualitat i semàntica	Taules desnormalitzades derivades del governat, amb menys relacions
Risc	Més relacions i pitjor rendiment amb molt volum	Duplicitat i possible desalineació

La recomanació: definir el model governat com a font única i generar automàticament les entitats aplanades a partir d'aquest model, documentades i versionades. Així es guanya rendiment sense perdre una única versió de la veritat.

7. Del model en estrella al model semàntic

Sobre les taules, el model semàntic de Power BI necessita:

1. Relacions d'un a diversos, de la dimensió al fet, amb filtre en una sola direcció. Evita les relacions de diversos a diversos i la direcció bidireccional excepte en casos justificats.
2. Mesures explícites, en una taula de mesures organitzada en carpetes: una mesura base per càlcul i mesures derivades per a intel·ligència de temps, acumulats o ràtios.
3. Jerarquies de navegació (any → trimestre → mes; país → regió → ciutat).
4. Columnes tècniques ocultes: claus, camps de control i atributs que no aporten res a l'anàlisi.
5. Rols de seguretat a nivell de fila (RLS) assignats a grups, no a persones.
6. Una dimensió calendari estàndard marcada com a taula de dates, i l'opció automàtica de data i hora desactivada.

Columnes calculades o mesures. Una columna calculada es materialitza fila a fila i serveix per filtrar, segmentar o categoritzar; una mesura es calcula en el context de cada objecte visual i és l'opció per a agregacions, ràtios i indicadors. Sempre que es pugui, les columnes calculades es fan en la càrrega (ETL), no al model.

8. Rendiment: el que més es nota

• Elimina les columnes que no s'utilitzen i redueix la cardinalitat: els identificadors GUID, els textos lliures i les dates amb hora completa són el que més pesa.
• Dimensions estretes i fets amb les claus i mesures justes.
• En DAX, utilitza variables, DIVIDE en lloc de /, COUNTROWS en lloc de COUNT i SELECTEDVALUE en lloc de VALUES quan esperes un valor únic.
• Als informes, menys objectes visuals per pàgina i segmentadors jeràrquics només quan aporten valor.

Eines per mesurar en lloc d'endevinar:

Eina	Per a què
Analitzador de rendiment de Power BI Desktop	Veure quin objecte visual o mesura alenteix una pàgina i extreure'n la consulta DAX
DAX Studio	Executar i perfilar consultes DAX i trobar colls d'ampolla
VertiPaq Analyzer	Veure la mida i la cardinalitat de cada taula i columna
Tabular Editor	Edició massiva, scripts i el Best Practice Analyzer amb les regles de bones pràctiques de Microsoft
Bravo	Formatar DAX, analitzar el model i generar calendaris

9. Un catàleg únic d'indicadors

El model tècnic no n'hi ha prou si cada àrea calcula «les seves» vendes. Un catàleg corporatiu de KPI es basa en uns principis senzills:

• Unicitat: cada indicador existeix una sola vegada, amb un identificador.
• Font de la veritat: sistema i dataset oficials de cadascun.
• Definició tancada: fórmula, filtres, període, gra i desglossaments permesos.
• Responsables: qui defineix la dada i qui respon del resultat.
• Versionatge i periodicitat: canvis controlats i calendari de publicació.
• Pocs i bons: entre 15 i 25 indicadors corporatius; la resta, per àrea.

Cada indicador només existeix si té la fitxa completa i ha superat una validació tècnica, metodològica i de negoci. Ho expliquem amb detall a gestió de metadades i qualitat de les dades.

10. Estàndards que estalvien temps

• Nomenclatura: Dim_ per a dimensions, Fact_ per a fets i noms de mesures amb sentit de negoci, sense duplicats ni sigles críptiques.
• Plantilles: un tema .json corporatiu i una plantilla .pbit amb pàgines base, navegació i tooltips reutilitzables. Acceleren el desenvolupament, unifiquen l'experiència d'usuari i faciliten la incorporació de persones noves a l'equip.
• Documentar i versionar el model com qualsevol altre codi.

11. Tria bé la tecnologia que hi ha a sota

El model lògic és el mateix, però cada plataforma demana matisos:

Plataforma	Què cal tenir en compte
Bases de dades relacionals (SQL Server, Oracle, PostgreSQL)	Índexs, particionament, plans d'execució i finestres de càrrega, perquè la lectura i l'escriptura competeixen
Magatzems al núvol (Fabric, Snowflake, BigQuery, Redshift)	El cost el marca el còmput: desnormalitzar amb criteri i distribuir les dades per evitar lectures massives
Motors tabulars (Power BI, Analysis Services)	Compressió per columnes: la cardinalitat i el nombre de columnes pesen més que el nombre de files
Big data i dades semiestructurades	Normalitzar JSON en temps real pot frenar la ingesta; s'aplana després, a la capa d'explotació

12. Arquitectures: on encaixa el model

El model de Power BI és l'última peça d'una cadena: sistemes operacionals, capa d'integració (abans ODS, avui capes bronze i silver), magatzem o lakehouse amb la capa governada (gold) i, finalment, el model semàntic. Enfocaments com Data Mesh (descentralitzar la responsabilitat per dominis) o Data Fabric (una capa unificada de govern sobre entorns distribuïts) canvien qui és l'amo de cada producte de dades, però no les regles del modelatge dimensional: fets, dimensions, gra i semàntica comuna continuen sent la base.

Errors freqüents

• Importar les taules tal com són al sistema d'origen i relacionar-les a Power BI com un model transaccional.
• Una taula de fets amb tot: mesures de processos diferents i grans barrejats a la mateixa taula.
• Relacions bidireccionals «perquè funcioni», que creen ambigüitats i alenteixen.
• Calcular en DAX el que hauria de venir calculat de la càrrega.
• Utilitzar la jerarquia automàtica de dates en lloc d'una dimensió calendari.
• Duplicar la mateixa mesura amb noms diferents en informes diferents.

Llista de comprovació abans de publicar un model

• [ ] El gra de cada taula de fets està documentat.
• [ ] Les dimensions estan desnormalitzades i tenen clau substituta.
• [ ] Hi ha una dimensió calendari marcada com a taula de dates i la data automàtica està desactivada.
• [ ] No hi ha relacions de diversos a diversos ni bidireccionals sense justificar.
• [ ] Les columnes tècniques estan ocultes i les que no s'utilitzen, eliminades.
• [ ] Les mesures són en una taula de mesures, amb carpetes i format.
• [ ] Els noms segueixen la nomenclatura acordada.
• [ ] La seguretat per files està definida i assignada a grups.
• [ ] El Best Practice Analyzer no mostra incompliments rellevants.
• [ ] Els indicadors corresponen a fitxes del catàleg de KPI.
• [ ] El model està documentat i versionat.

A Bidatia dissenyem i optimitzem models semàntics a Power BI i Microsoft Fabric, des del model governat fins al quadre de comandament, i formem els equips per mantenir-los.