Il capitolo 15 ha progettato il data mart TPC-D; questo capitolo lo collega a Power BI: i dati di connessione al database PostgreSQL del corso, le tre finestre principali (Report, Data, Model), l'inizializzazione della sorgente dati (Get data, selezione delle tabelle dw, caricamento), la gestione delle relazioni (inferite automaticamente dai nomi dei campi, poi corrette con drag&drop e controllo delle cardinalità), il problema della duplicazione di dt_date (non possono esserci più collegamenti alla stessa tabella) e l'opzione Cross filter direction = Both. Segue il setup del modello multidimensionale: nascondere le chiavi surrogate, verificare i tipi, definire le gerarchie dal più aggregato (coarsest) al più fine (finest), e l'uso di RELATED() con il prefisso rel_ per le gerarchie fra tabelle diverse. Chiude l'Esercizio 1.
Il data warehouse del Modulo 2 è un database PostgreSQL raggiungibile 24/7, anche fuori dalla rete Unibo. I dati di connessione forniti dalle slide:
| Parametro | Valore |
|---|---|
| DBMS | PostgreSQL |
| Host | 137.204.78.85 |
| Port | 5432 |
| Database | bi |
| Username | student |
| Password | busint-MOD2 |
| Schema | dw |
| Tabelle | usare quelle con il prefisso sample_ |
dw le tabelle da usare sono quelle con il prefisso sample_.Power BI è uno strumento commerciale per la visualizzazione e l'analisi dei dati, parte della Microsoft Power Platform. Fornisce una GUI semplice per formulare query su qualunque tipo di sorgente dati. Le slide precisano: non è esattamente uno strumento OLAP. Oltre ai software BI avanzati (Oracle, SAP), le alternative commerciali simili sono Tableau e Qlik; le alternative open-source sono Saiku e Apache Superset. Power BI è relativamente facile da usare, fornisce visualizzazioni accattivanti e la versione Desktop è gratuita.
Il percorso guidato del Modulo 2 si articola in: inizializzazione della sorgente dati, setup del modello multidimensionale, OLAP basics (capitolo 14) e opzioni di interrogazione avanzate; gli esercizi individuali chiedono di definire query OLAP a partire da requisiti in linguaggio naturale.
Il primo passo è selezionare i dati da interrogare: connettersi al database, selezionare le tabelle dw, impostare i collegamenti di join e verificare i tipi di dato. La sequenza operativa:
Dalla connessione al database al modello pronto per le gerarchie: il simulatore è popolato dagli script del capitolo.
Se le foreign key non sono impostate, le relazioni di join vengono inferite automaticamente, in base ai nomi dei campi — ma, avverte la slide, non funziona molto bene. Passando il mouse su un collegamento si vedono i campi uniti; con il click destro sul collegamento lo si può eliminare o cambiare le proprietà.
Per eliminare più collegamenti insieme si usa Manage relationships — in particolare le slide consigliano di eliminare tutti i collegamenti relativi alle date. Per creare un collegamento fra due campi A e B, si trascina A e lo si rilascia su B, ottenendo il risultato mostrato in figura; è poi fondamentale assicurarsi che le cardinalità siano corrette.
Il problema: non possono esserci più collegamenti alla stessa tabella. Nel modello TPC-D, dt_date è raggiunta sia da dt_order (orderdate) sia da dt_commit_date e dt_ship_date: servono più relazioni verso la stessa tabella data. La soluzione: duplicare dt_date. Per duplicare una tabella: click sui tre puntini > Edit query, poi click destro su dt_date > Duplicate, rinominare i duplicati e infine premere "Close and Apply" (in alto a sinistra).
Il cross filter direction è la seconda correzione necessaria. Per poter eseguire DISTINCTCOUNT su campi di una dimension table mentre si filtra su dimension table non correlate (ad esempio il numero di clienti distinti che hanno acquistato articoli di un certo brand), bisogna impostare l'opzione "Cross filter direction" = "Both" sulle relazioni dalla prima DT alla FT. In questo modo il filtro può viaggiare in entrambe le direzioni della relazione.
Completata l'inizializzazione, si passa al setup del modello. I passi manuali sono quattro:
DT_CUSTOMER.custkey va portato a Text, e DT_COMMIT_DATE.month va portato a Date nel formato 'yyyy-mm';Il punto critico delle gerarchie: gli attributi devono essere elencati sempre dal più aggregato (in alto) al più fine (in basso), per garantire la correttezza del drill-down. La slide mostra il confronto fra una gerarchia Wrong e una Correct. Per correggere l'ordine: Properties della gerarchia, riordinare con il drag&drop e premere Apply Level Changes.
Le gerarchie possono essere definite solo all'interno della stessa tabella — ma nel modello esistono snowflake: ad esempio DT_ORDER e DT_CUSTOMER sono tabelle diverse, e la gerarchia dell'ordine dovrebbe attraversarle. Il «trucco» delle slide: creare riferimenti virtuali sul lato many della relazione many-to-one, cioè attributi virtuali su DT_ORDER che importano custkey, nation e region del cliente corrispondente.
Operativamente, nella finestra Data:
custkey, nation e region;rel_ per distinguere questi attributi dagli altri;rel_ per riconoscerli.L'Esercizio 1 chiude il percorso guidato: completare il setup multidimensionale per il cubo Sales, e fare lo stesso per il cubo Orders. In pratica, per ciascun cubo: connessione alla sorgente, correzione delle relazioni (con la duplicazione di dt_date e il cross filter direction Both dove serve), nascondere le chiavi surrogate, verificare i tipi, definire tutte le gerarchie dal coarsest al finest, e creare gli attributi virtuali rel_ per le gerarchie fra tabelle. È la verifica pratica di tutto il capitolo, ed è la stessa abilità richiesta dall'esame del Modulo 2 (capitolo 15, sezione 3).
Il setup del modello in Power BI corrisponde esattamente alla progettazione logica del capitolo 15: le gerarchie coarsest→finest materializzano le gerarchie DFM, il prefisso rel_ realizza i collegamenti fra dimension table in snowflake, e il cross filter direction Both abilita i DISTINCTCOUNT del capitolo 14 (ad esempio il numero di clienti distinti che hanno acquistato articoli di un brand).
PostgreSQL, host 137.204.78.85, porta 5432, database bi, utente student, password busint-MOD2, schema dw, tabelle con il prefisso sample_. Accessibile 24/7 anche fuori rete Unibo.
Uno strumento commerciale della Microsoft Power Platform per visualizzazione e analisi dei dati, con GUI semplice per formulare query (non esattamente un OLAP). Finestre: Report (grafici e dashboard), Data (tipi di dato), Model (connessione alla sorgente e gerarchie). Desktop è gratuito; alternative: Tableau, Qlik (commerciali), Saiku, Apache Superset (open-source).
Get data > More > Database > PostgreSQL database, inserire le credenziali con Connectivity mode Import, selezionare tutte le tabelle dw e premere Load. Poi si impostano i join connections e si verificano i tipi.
Se le foreign key non ci sono, le relazioni vengono inferite dai nomi dei campi (ma in modo poco affidabile). Si controllano in hover, si eliminano/modificano col click destro o con Manage relationships, e si creano con drag&drop di un campo sull'altro, verificando che le cardinalità siano corrette.
Perché non possono esserci più collegamenti alla stessa tabella, e dt_date è raggiunta da orderdate, commit date e ship date. Si duplica con tre puntini > Edit query > click destro su dt_date > Duplicate, si rinomina e si preme Close and Apply.
Consente di eseguire DISTINCTCOUNT su campi di una DT mentre si filtra su DT non correlate (es. clienti distinti che hanno acquistato articoli di un brand). Va impostato sulle relazioni dalla prima DT alla FT.
(1) Nascondere i campi inutili, tutte le chiavi surrogate (primary e foreign key); (2) verificare i tipi (custkey → Text, month → Date 'yyyy-mm'); (3) definire le gerarchie, una per percorso lineare root-to-leaf, nominata dal coarsest attribute; (4) eventualmente estenderle con binning e gruppi.
Sempre dal più aggregato (coarsest, in alto) al più fine (finest, in basso), per garantire la correttezza del drill-down. Per correggere: Properties della gerarchia, riordino con drag&drop e Apply Level Changes.
Le gerarchie si definiscono solo dentro la stessa tabella: per gli snowflake si creano attributi virtuali sul lato many della relazione many-to-one con RELATED() (es. su DT_ORDER gli attributi rel_custkey, rel_nation, rel_region dal cliente), usando il prefisso rel_, poi si crea la gerarchia nella finestra Model.
Di completare il setup multidimensionale per il cubo Sales e fare lo stesso per il cubo Orders: connessione, relazioni (dt_date duplicata, cross filter Both), chiavi nascoste, tipi, gerarchie coarsest→finest e attributi rel_.