Il capitolo 14 ha introdotto l'interrogazione OLAP con Power BI; questo capitolo ricostruisce il Modulo 2 del corso nella sua interezza: il programma, il software usato in laboratorio con le relative licenze, le modalità d'esame (un esercizio da 30 minuti valutato 6/32), e il percorso di progettazione guidato sul benchmark TPC-D con Indyco Builder — dalla progettazione concettuale (DFM) a quella logica, fino ai DDL della progettazione fisica. È il ponte fra i due mondi del corso: la metodologia dei capitoli 1–13 e la pratica di laboratorio dei capitoli 14–16.
L'obiettivo del Modulo 2 è creare, alimentare e interrogare un data warehouse, lavorando sul benchmark TPC-D. Il percorso si articola in due grandi blocchi:
Gli strumenti del Modulo 2 non possono essere usati per scopi commerciali. Le macchine del laboratorio sono già pronte, ma gli strumenti possono essere installati anche sulle macchine personali:
| Strumento | Licenza |
|---|---|
| Indyco Builder | Licenza necessaria — può essere richiesta al docente |
| Power BI Desktop | Nessuna licenza necessaria — la versione Desktop è gratuita |
La distinzione licenze/software ricorre nelle domande d'esame: Indyco Builder richiede una licenza (richiedibile), Power BI Desktop è gratuito. La licenza educativa di Indyco Builder, come si vedrà nella sezione 4, non supporta la generazione automatica del modello logico né il reverse-engineering.
Il contenuto del Modulo 2 fa parte dell'esame finale del corso. La prova consiste in un singolo esercizio da 30 minuti, nel quale lo studente deve:
La valutazione è di 6/32 punti — la quota del Modulo 2 all'interno dell'esame complessivo del corso.
Indyco Builder è un software commerciale di Iconsulting che supporta la progettazione concettuale di un data warehouse: fornisce funzionalità di validazione DFM e metriche di valutazione, una GUI web per l'esplorazione del DW, e la generazione automatica del modello logico (non supportata dalla licenza educativa). Anche il reverse-engineering non è supportato dalla licenza educativa.
Nel Modulo 2, Indyco Builder viene usato per definire i modelli concettuale (DFM) e logico del data mart di esempio. Le funzionalità escluse dalla licenza educativa — generazione automatica del modello logico e reverse-engineering — vanno quindi svolte a mano, ed è esattamente ciò che il corso insegna: la progettazione concettuale e logica si fanno con la metodologia dei capitoli 7–11, Indyco Builder serve a validare ed esplorare.
Il caso di studio del Modulo 2 è il benchmark TPC-D, con le sue tabelle relazionali. La legenda delle slide spiega come leggere lo schema:
p_ per PART, l_ per LINEITEM);Lo schema TPC-D dà origine a due cubi: il fatto principale è il cubo Sales, il fatto alternativo è il cubo Orders. La differenza è nell'evento primario: per Sales il fatto è la linea d'ordine (la riga di LINEITEM), per Orders il fatto è l'ordine stesso. Di conseguenza i due cubi hanno misure e dimensioni diverse, come mostra l'albero degli attributi.
Per ciascun cubo, Indyco Builder visualizza l'albero degli attributi: le dimensioni con le loro gerarchie e gli attributi caratterizzati dalla legenda delle slide:
| Legenda | Significato |
|---|---|
| not interesting | attributi non interessanti per l'analisi |
| descriptive | attributi descrittivi (usabili solo con l'attributo che descrivono) |
| key swapped | attributi la cui chiave è stata scambiata (la chiave diventa descrittiva) |
| measure | misure del fatto |
| shared | attributi condivisi fra più dimensioni (collegamenti fra tabelle) |
L'albero del cubo Sales ha il fatto LINEITEM con le misure l_quantity, l_extendedprice, l_discount, l_tax; le dimensioni PART (p_, con la gerarchia partkey → mfgr → brand → type → size → container...), SUPPLIER (s_), CUSTOMER (c_, con la gerarchia custkey → nation → region), ORDER (o_, con la gerarchia orderkey → orderdate...), DATE, e la partizione di PARTSUPPLIER (ps_, con ps_partkey+ e ps_suppkey+ che collegano due dimensioni). Le chiavi con il simbolo + (l_partkey+, l_suppkey+, ps_partkey+, ps_suppkey+) sono chiavi importate: attributi condivisi che realizzano il collegamento fra il fatto e le dimensioni.
Il cubo Orders ha come fatto l'ordine (DT_ORDER diventa il fatto FT_ORDERS): cambiano le misure (per esempio o_totalprice diventa misura) e le dimensioni che si collegano direttamente al fatto. La differenza fra i due cubi è esattamente ciò che la progettazione concettuale deve decidere: qual è l'evento primario, la linea d'ordine o l'ordine?
Per ciascun cubo si definisce lo schema di fatto (DFM) con Indyco Builder: dimensioni, gerarchie e misure emergono dall'albero degli attributi. La progettazione concettuale del cubo Sales porta alle dimensioni PART, SUPPLIER, CUSTOMER, ORDER, DATE (con la gerarchia temporale) e alle dimensioni degenerate; il cubo Orders, avendo come evento primario l'ordine, richiede di gestire l'arco multiplo fra PART e SUPPLIER (un ordine può contenere prodotti di più fornitori).
La progettazione logica del cubo Sales combina gli strumenti classici dei capitoli 8 e 11:
l_linestatus e l_returnflag restano nella fact table;l_shipmode e l_shipinstruct vengono raccolti in una tabella junk (JDT_SHIPMENT);La progettazione logica del cubo Orders introduce la bridge table BRIDGE_PS: poiché un ordine può contenere prodotti di più fornitori (la relazione molti-a-molti fra PART e SUPPLIER attraverso PARTSUPPLIER), il collegamento diretto fatto-dimensioni non basta. La bridge table esplicita le associazioni PART–SUPPLIER, e la fact table FT si collega a DT_PART, DT_SUPPLIER, JDT_ORDER e alle dimensioni data, come mostra lo schema logico delle slide.
Avanzate le tre fasi del percorso di progettazione del Modulo 2.
Per la progettazione fisica, le tabelle sono già state create: i DDL sono disponibili su Virtuale (ddl_sales.sql e ddl_orders.sql). La slide è esplicita su un punto importante per l'esame: nessun DDL è necessario per l'esame.
Il Modulo 2 non richiede di scrivere DDL: la progettazione fisica del data mart TPC-D è già data, e l'esame del modulo si concentra su connessione, gerarchie, query e grafici (capitolo 16). I DDL restano però materia dei quesiti teorici del corso — la metodologia della progettazione fisica è quella del capitolo 13.
Creare, alimentare e interrogare un data warehouse basato sul benchmark TPC-D: progettazione concettuale e logica con Indyco Builder (DFM), interrogazione con Power BI (gerarchie e query OLAP).
Indyco Builder: licenza necessaria, richiedibile al docente. Power BI Desktop: nessuna licenza, la versione Desktop è gratuita. Gli strumenti non possono essere usati per scopi commerciali.
Un singolo esercizio da 30 minuti: connettersi a un DW con Power BI, configurare le gerarchie, definire query e grafici. Valutazione: 6/32 punti.
Un software commerciale di Iconsulting per la progettazione concettuale (DFM): validazione e metriche, GUI web di esplorazione. La licenza educativa non supporta la generazione automatica del modello logico né il reverse-engineering.
Le parentesi dopo il nome della tabella contengono il prefisso dei nomi di colonna; le frecce puntano nella direzione delle relazioni one-to-many; le linee tratteggiate sono tabelle/relazioni opzionali; il numero o formula sotto il nome è la cardinalità della tabella.
Il fatto principale è il cubo Sales (evento primario: la linea d'ordine, FT LINEITEM); il fatto alternativo è il cubo Orders (evento primario: l'ordine, FT ORDERS).
not interesting: attributi non interessanti; descriptive: attributi descrittivi (usabili solo con l'attributo che descrivono); key swapped: chiave scambiata; measure: misure; shared: attributi condivisi fra dimensioni (le chiavi con «+» come l_partkey+).
Dimension table per le dimensioni standard; dimensioni degenerate per l_linestatus e l_returnflag (restano nella fact table); junk dimension JDT_SHIPMENT per l_shipmode e l_shipinstruct; snowflake o redundancy per le gerarchie derivate (es. nation/region del customer).
Per l'arco multiplo fra PART e SUPPLIER: un ordine può contenere prodotti di più fornitori (relazione molti-a-molti attraverso PARTSUPPLIER). La bridge table esplicita le associazioni PART–SUPPLIER che il collegamento diretto fatto-dimensioni non può rappresentare.
Niente: le tabelle sono già state create con i DDL disponibili su Virtuale (ddl_sales.sql, ddl_orders.sql). Nessun DDL è necessario per l'esame.