Un utilizzo e una diffusione a livello Aziendale del Sistema Power BI pretende il rispetto di alcune Regole
L’Adozione di queste regole, generalmente chiamate Buone Pratiche, ha varie finalità:- perfetta conoscenza e comprensione del Data Model (l'insieme dei dati elaborati nel Report) da parte di chi realizza il Report stesso
- il Data Model, una volta completato, deve essere ufficializzato in modo da poter riutilizzato anche per altri Report
- occorre definire regole che riguardino aspetti grafici ed organizzativi per tutti i Report a carattere Aziendale (creazione di Templates vuoti)
- occorre definire regole che riguardino la creazione di Colonne e Misure, ecc.
- magari diventare un NO VAX delle Colonne e ragionare sempre in termini di Misure
- occorre definire regole per facilitare le successive manutenzioni non solo da parte del primo autore
- occorre definire regole per facilitare il riutilizzo di Data Model e di tutto o parte del Report
- ecc.
Nota:
useremo il termine Visual per indicare un oggetto visuale presente nella pagina (in Power BI Desktop si chiama Visualizzazione/Visualization)
Prg | Titolo | Note | |
---|---|---|---|
01 |
Scelta Fonti Dati Controllo a monte Caricamento Completamento |
I Dati sono la Materia Prima del Report. La prima fase della creazione di un nuovo Report consiste nel Caricamento (import) o nel Collegamento (direct query) alla Fonte o alle Fonto dei Dati. E' quasi sempre opportuno un primo lavoro di pulizia e di preparazione dei dati, tanto più necessario quanto più questi vengano da sorgenti meno nobili o addirittura non sicure. Per eseguire queste importanti attività si utilizza il Query Editor. Altra Buona Regola è quella di Aggiungere a Tutte le Tabelle che ne fossero sprovviste di un campo ID che identifici una singola riga, prima o poi potrebbe servire. Di queste cose e di tante altre se ne occupa il Query Editor svolge anche funzione di controllo errori (esempio buchi nei dati o tipi non riconoscibili, ecc.) e in casi in cui sia possibile anche di correzione...ecc. |
|
Sei il Data Model è fatto male tutto il Report non funzionerà. Se il Data Model è corretto una Pagina sbagliata di può sempre correggere! | |||
02 |
Controllo dei Dati Tabella per Tabella, Colonna per Colonna |
Una volta caricati i dati occorre controllare le Tabelle e in ogni Tabella controllare le Colonne, e quindi controllare le Tipologie dei Dati (es. Testo, Numero, Data, ecc.), la loro Formattazione, il loro Comportamento. Il Tipo è un fatto sostanziale la sua Formattazione è un fatto estetico che non ne cambia il tipo e neppure il valore. Dare sempre dei Nomi Tecnici alle Colonne, creando un Dizionario utile per i Report successivi. In fase di creazione della Pagina si può modificare il nome della Colonna nel singolo Visualzzatore in modo che sia di facile comprensione da parte dell'utente. In sostanza invece del nome Tecnico della Colonna viene mostrata una Etichetta più .. umana. |
|
Un nome di una Misura TotaleVenditeMesePrecedente non è sbagliata. E' inutilmente lunga, basta TVMP. | |||
03 |
Controllo Creazione dei Collegamenti tra le Tabelle |
Il Data Model contiene le Tabelle. Le Tabelle sono di due Tipi:
I Tipi di Relazione "normali" sono due:
|
|
Le Relazioni createle voi!!. E' un argomento troppo importante per farlo gestire da Power B! | |||
04 |
Creazione Tabella Calendario |
Se in nessuna Tabella ci sono Colonne con una Data non è necessario nè possibile, ovviamente, creare Pagine in cui in qualche modo entri una Data (es. Vendite per Mese). Se in una o più Tabelle c'è una Data allora è sempre FONDAMENTALE creare subito una Tabella di Tipo Calendario, possibilmente dinamico, in cui ci siano tutte le Date (anche Natale) e quindi collegare tutte le date in giro per il Data Model all'unica data sicura, quella del Calendario. Vediamo alcuni perchè:
|
|
C'è anche una sola Data nel Data Model? Fate subito un Calendario!! Non ve ne pentirete! | |||
05 |
Creazione Tabelle di Supporto (ETL) |
Il concetto di ETL (Extract/Transform/Load)
è ben noto a chi viene dal mondo dei Database Relazionali in cui esistono comandi che creano "al volo" delle nuove Tabelle eseguendo una serie di operazioni su una o più Tabelle con i Dati. Le Tecniche ETL si usano, ad esempio, nella creazione dei DB di tipo Data Warehouse. Le operazioni sono tradizionalmente Raggruppamento, Calcolo, Filtraggio, Ordinamento. Ebbene anche DAX mette a disposizione un Set di comandi del tutto analoghi. Rientrano tra i Comandi di Creazione Tabelle e in alcune situazioni permettono al creatore del Report di "togliersi dall'impaccio" creando delle Tabelle di Appoggio da usare in Pagine particolari. Nel Caso Studio inserito in questo Sito ce ne sono degli esempi che chiariscono il concetto meglio di qualsiasi spiegazione testuale. |
|
Ci sono Tabelle con centinaia di migliaia di righe, sul Croscotto si accende una Spia Gialla (non Verde ma Gialla) | |||
06 |
Organizzazione delle Misure in Tabelle specializzate |
Il motivo della Potenza e del Successo di Power BI è dovuto soprattutto alla Misura. La Misura permette qualsiasi tipo di Calcolo ed è ricalcolata nel Contesto. Se ad esempio la Pagina è filtrata per Anno la misura viene ricalcolata filtrata per Anno. Le Misure possono usare, anzi soprattutto usano, i Comandi del linguaggio DAX. Le Misure possono sostituire le Colonne Calcolate, motivo per cui io sono un "NO-VAX" delle Colonne, sono un No-Columns. In un Report Complesso le Misure possono essere svariate decine e quindi la cosa migliore è creare delle Tabelle contenitrici specializzate per una singola categoria. |
|
Mettereste mai dei Calzini nel cassetto delle Camicie? Anche le misure vanno messe nelle Tabelle Giuste | |||
07 |
Definizione di una Strategia per i Filtri |
Un Report Power BI deve essere interattivo, se no ci alziamo e ce ne andiamo. Per interattività si intende il fatto che l'utente del Report agendo su filtri e/o sui vari elementi della pagina deve poter ottenere facilmente il dato di suo interesse, o perchè già c'è oppure perché viene calcolato grazie ai Filtri e alle Misure. Esistono Visual di classe Filtro esistono Visual che si comportano anche da Filtro. In una Pagina con tanti Visual di classe Filtro o di altra Classe è possibile e spesso necessario "gestire il traffico" insomma definire chi filtra cosa. Attenzione! Se i Visual della Pagina sono 10 occorre gestire 81 rapporti tra coppie di Visual. Filtri che non si vedono Oltre ai FIltri Visual che fanno mostra di sè sulla Pagina ci sono filtri che non si vedono e che si impostano usando la Barra verticale sulla destra della Pagina. Possono agire sul singolo Visual, sulla Singola Pagina, su Tutte le Pagine. Altra variante è quella che consente il fitraggio tra le pagine, ecc. ecc. Filtro molto utile e sofisticato è il Filtro per Ruolo che filtra i dati mostrando solo quelli di competenza degli Utenti che appartengono a quel ruolo. Mi fermo qui. |
|
Mettereste mai dei Calzini nel cassetto delle Camicie? Anche le misure vanno messe nelle Tabelle Giuste | |||
08 |
Tabelle di Misure |
Come esempio di quanto detto ai precedenti punti 6 e 7 indico alcune di Tabelle Misure che servono SEMPRE (ovviamente la classificazione ed organizzazione delle Misure è una delle Buone Pratiche).
☞ Misure Numeriche Filtrabili, Non Filtrabili e Parzialmente Filtrabili Somme, Medie, Massimo, Minimo, ecc. di tutti i Valori numerici di interesse. ☞ Misure di Time Intelligence Sono circa quaranta e nella loro sintassi c'è una Data, che come detto dovrebbe essere quella del Calendario. Es. MesePrecedente, StessoMeseAnnoPrecedente, ecc. ☞ Misure che Leggono i valori dei Filtri attivi SelectedValue, AllSelected, ecc. |
|
E' stato trovato un Report senza nessun filtro. Dopo accurato studio si è scoperto che era fatto con Power Point, dove la staticità è di casa. | |||
09 |
Misure di contenuto testuale |
In molte delle situazioni in cui si deve inserire un Parametro Power BI mostra un simbolo Fx. Questo vuol dire che il Parametro non deve per forza essere fisso, può essere il risultato del calcolo di una Misura. Questa possibilità può essere molto utile quando si inserisce un Titolo di un Visual. Può essere creata una vera e propria frase esplicativa, con parti testuali fisse ottenute concatenando Testi fissi con i valori dinamici delle Misure. |
|
"Sempre caro mi su quest'ermo colle.." Ai tempi di Giacomo Leopardi Power BI non c'era.. se no.. | |||
10 |
Ingegnerizzazione dei Nomi delle Colonne e dei Nomi delle Misure |
Quando si crea una Misura bisogna sempre pensare che prima o poi quando si dovrà realizzare un nuovo Report, servirà di nuovo. Ad esempio supponiamo la Misura TotMesePrec, il cui significato è evidente. Quando si crea la prima volta si deve pensare che si potrà usare infinite volte in altri Report. Altra regola date nomi tecnici alle Colonne e alla Misure e possibilmente sintetici. Questo per alleggerire la pesantezza delle formule. In qualsiasi Visual sarà comunque possibile nascondere alla vista il nome tecnico supponiamo ToTVnd con un etichetta in chiaro Totale Vendite. |
|
Riutilizzo, riutilizzo, riutilizzo, ... Si perde un po' di tempo la prima volta che si crea una Misura. Zero perdita di tempo quando si riutilizza. | |||
11 |
Si è proprio un Coltellino Svizzero. La Funzione, sicuramente la più importante del linguaggio di Power BI il potentissimo DAX, che si chiama Calculate risolve tutte le questioni che le altre funzioni non sono in grado di risolvere. La Sintassi è apparentemente semplice : cosa calcolare e in quali condizioni: CALCULATE(<expression>[, <filter1> [, <filter2> [, …]]]) Siccome l'espressione può essere una formula qualsiasi anche dinamica e i filtri possono essere qualsiasi anche dinamici è possibile costruirsi una propria funzione che a sua volta può essere ingegnerizzata. Basta così. |
||
Nei primi 11 punti abbiamo parlato solo dei Dati. Il loro Caricamento, il necessario Controllo Preventivo, la lunga ed estenuante fase di Preparazione. Possiamo passare alla preparazione del Report. Inserisco un Link relativo alla Ricetta delle Lasagne alla Bolognese prevede 48 passaggi, 46 dei quali riguardano Ingredenti e Preparazione. I punti 47 e 48 riguardano la Cottura. Vedo una perfetta analogia con la Preparazione di Report complesso, in cui la fase di caricamento dei Dati (Materia Prima), controllo ed eventuale pulizia, preparazione di Colonne e Misure, è la fase più critica. Se i Dati non sono perfetti il Report riesce sempre male e la situazione potrebbe non essere recuperabile. Se i Dati sono perfetti al massimo si sbaglia una Pagina, ma ma situazione è sempre recuperabile. I punti successivi riguardano le Buone Pratiche relative alla creazione delle Pagine del Report. |
|||
Pausa Caffè |
Nella Pausa Caffè leggiamo il Manuale di Riferimento delle Funzioni del Linguaggio DAX Si scarica dal Sito Vedi il Sito Lo abbiamo scaricato per voi Vedi il Documento. |
||
12 | Identificazione dei Destinatari |
La conoscenza dei futuri destinatari dei Report potrebbe condizionare la preparazione dei Report stessi. Più in alto in grado sono i destinatari più i dati devono essere, almeno al caricamento del Report, sintetici. Poi con le Tecniche di Drill Down si può scendere fino al massimo dettaglio. Destinatari più operativi in genere devono tener sotto controllo anche i singoli record in cui eventuali situazioni critiche possono esser ben evidenziate con segnali di pericolo, anche con una semplice visualizzazione in ROSSO. |
|
13 | Estetica del Report |
Per la cura dell'estetica rivolgersi a Power Point. Ci tengo a tener distanti la finalità di una presentazione Power Point che ha modalità di visualizzazione "statiche", magari perchè viene proiettato davanti a decine di persone, da quelle di un Report Power BI, che deve essere principalmente uno strumento operativo e quanto più possibile interattivo. Personalmente sono per uno stile minimalista, tipo Calvin Klein, per intenderci. Ovviamente per le Aziende che hanno loghi, colori, stili di caratteri propri possono essere facilmenti adottati anche nei Report Power BI. |
|
14 | Livelli di Interattività |
L'utente deve esser messo in grado di interagire con facilità con il Report e di poter raggiungere con facilità gli elementi e i dati di suo interesse. Gli strumenti per interagire sono diversi e di differente difficoltà nell'uso. Un filtro a bottoni è facile da capire e da usare, un filtro gerarchico un po' meno, una combinazione di più filtri ancora di meno. Come esempio estremo di Interattività cito il Visual Decomposition Tree in cui partendo da un valore numerico di partenza (es. Vendite, Produzione, ecc.) l'utente può scegliere un percorso, tra i cento che gli vengono proposti, per raggiungere il dettaglio di suo interesse. Si potrebbe dire che l'utente si cerca il dato da solo. |
|
15 |
Aiuti allo uso del Report e alla comprensione dei Dati |
Un Report DEVE essere
Interattivo e deve essere
Navigabile al massimo livello.
E' quindi indispensabile che l'utente sia aiutato quanto più possibile nel suo uso, anche con spiegazioni testuali, e nella sua navigazione con indicazioni su quali siano le strade praticabili. Lo strumento più potente per ottenere questo scopo sono le Misure Testuali vere e proprie frasi che spiegano quello che si sta vedendo e quello che si può vedere ancora di più. Abusate delle Misure Testuali. |
|
Nei primi 11 punti abbiamo parlato solo dei Dati, nei successivi 4 abbiamo dare Regole relative alla preparazione del Report. Ora ci dobbiamo occupare la fase finale la Pubblicazione che come le fasi precedenti ha sue specificità e sue funzionalità. In genere questa fase viene sottovalutata come se alla fine della stesura di un Documento lo si dovesse semplicemente o stampare o inviare a qualcuno. Un Report Power BI non si stampa e non dovrebbe essere oggetto di una eMail. Un Report Power BI si PUBBLICA! |
|||
16 |
Power BI il Servizio Cloud L'ambiente |
L’Editor Power BI Desktop con cui si creano i Report è gratuito. Una volta creato il Report (file con desinenza PBIX) va pubblicato sul Servizio Power BI del Cloud Microsoft 365. Questo servizio invece non è gratuito e quindi sia la persona che crea il Report sia le persone che vedono il Report devono disporre di un Account Microsoft 365 che comprenda questo Servizio. L’ambiente di Pubblicazione è sempre e per tutti il Sito: https://app.powerbi.com L’ambiente di Pubblicazione prevede una serie di Funzionalità di tipo Organizzativo, in quanto funge anche da Repository dei Report che possono essere pubblicati all’interno di Cartelle, altre di tipo Operativo. |
|
17 |
Power BI il Servizio Cloud Varie destinazioni |
Le varianti sono una mezza dozzina: semplice condivisione via eMail, semplice condivisione via Teams, pubblicazione su un Sito Intranet (creato ad Hoc), pubblicazione il SharePoint (altro Servizio di Microsoft 365 che facilita vari aspetti organizzativi), pubblicazione su un sito accessibile a tutti (alcune limitazioni). Per i Programmatori sono disponibili Servizi che permettono di pubblicare da Codice i vari Report .. dove vi pare! |
|
18 |
Power BI il Servizio Cloud Varie permissions |
Chi sono i Destinatari dei Report e quali siano i dati di loro competenza riguarda il vasto argomento delle Permissions, anche questo gestito in fase di Pubblicazione. Power BI nel Sistema Microsoft 365 In quanto Servizio interno al Cloud Microsoft 365 può interagire direttamente oppure indirettamente grazie a Power Automate e in modo bidirezionale con tutti gli altri servizi. Le combinazioni possibili sono parecchie decine, alcune delle quali sicuramente utili. L'Argomento merita un Trattamento a parte (in preparazione) |
|
19 |
Power BI il Servizio Cloud Schedulazione Aggiornamenti |
Si aggiornano i Dati e non i Report. L'utente del Report non può aggiornare i Dati quando gli pare. Le modalità e le frequenze degli Aggiornamenti vanno definite nell'ambiente di pubbicazione Ad esempio possono essere schedulate 4 volte al giorno (ore 6.00 12.00 18.00 24.00). Esistono ulteriori modalità e funzionalità più evolute. Es. Aggiornamento incrementale, oppure Aggiornamento Continuo, ecc. |
|
Power BI non basta una vita. Non può bastare perchè il Cloud evolve e Power BI lo deve seguire a ruota. |