Fase 3 – Progettazione concettuale

Nella fase di progettazione concettuale vengono utilizzati i requisiti utente raccolti nella fase precedente per disegnare, a partire dallo schema riconciliato, uno schema concettuale per il data mart.

Il modello Entity/Relationship (meglio noto come Modello ER) è oggi molto diffuso all’interno delle imprese come strumento concettuale per la documentazione standard delle basi di dati relazionali e per la loro progettazione. Per questo motivo sono stati fatti molti sforzi per permetterne l’utilizzo anche nella progettazione dei sistemi non relazionali, essendo tuttavia il modello più orientato alle interrogazioni che percorrono le associazioni tra i dati piuttosto che alla loro sintesi, esso mal si presta ad essere adottato nel caso dei data mart.

I modelli ER non possono essere compresi dagli utenti, né essere “navigati” efficacemente dai software dei DBMS, per questi motivi essi non possono essere adottati come fondamenti per i data warehouse (Kimball – 1996).

In effetti, un modello ER ha un’espressività sufficiente per rappresentare la maggior parte dei concetti necessari alla modellazione dei data mart, d’altronde nella sua forma base non è in grado di mettere in luce gli aspetti peculiari del modello multidimensionale. Per questo motivo negli ultimi anni sono stati proposti diversi approcci originali alla modellazione dei dati mart, alcuni originati a partire da estensioni del modello ER, altri nati a partire dal modello UML.

Il dimensional fact model (trattato in seguito) permette di rappresentare, oltre che ai fatti, le dimensioni e le misure, anche gli attributi non utilizzabili per l’aggregazione (detti di proprietà), gli attributi opzionali e i percorsi alternativi di aggregazione. Nei paragrafi successivi verranno approfonditi questi concetti.

Dimensional Fact Model

Il Dimensional Fact Model (DFM) è un modello concettuale concepito per fungere da supporto per la progettazione dei data mart. Il DFM si pone i seguenti obiettivi:

  • Dare un supporto efficace alla progettazione concettuale;
  • Creare un ambiente in cui le interrogazioni utente possano essere formulate in modo intuitivo;
  • Rendere possibile la comunicazione tra il progettista e l’utente finale con l’obiettivo di raffinare le specifiche dei requisiti;
  • Costruire una piattaforma stabile per la progettazione logica;
  • Fornire una documentazione di progetto espressiva e non ambigua.

La rappresentazione concettuale generata dal DFM consiste in un insieme di schemi di fatto. Gli elementi di base modellati dagli schemi di fatto sono i fatti, le misure, le dimensioni e le gerarchie. Un fatto è un concetto di interesse per il processo decisionale; tipicamente esso modella un insieme di eventi che accadono nell’impresa. Alcuni esempi di fatti nel dominio delle imprese sono: vendite, spedizioni, acquisti, eccetera. È importante che un fatto abbia degli aspetti dinamici, ovvero che sia in grado di evolvere in qualche modo nel tempo.

Una misura è una proprietà numerica di un fatto che ne descrive un aspetto quantitativo di interesse per l’analisi. Ad esempio ogni vendita è misurata dal numero di unità vendute, dal prezzo unitario, dall’incasso totale, eccetera. Un fatto può anche non avere misure, nel caso in cui sia interessante registrare solo il verificarsi di un certo evento.

Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi. Ogni fatto ha in genere più dimensioni, queste ne determinano la granularità minima di rappresentazione. Dimensioni tipiche per il fatto “vendite” riguardano il prodotto venduto, il negozio in cui è stata effettuata la vendita e la data. Il legame tra misure e dimensioni è espresso a livello estensionale dal concetto di evento. All’interno dello schema di fatto le dimensioni sono rappresentate dagli attributi dimensionali. Le relazioni tra gli attributi dimensionali sono espresse dalle gerarchie.

Un evento primario è una particolare occorrenza di un fatto, individuata da una ennupla costituita da un valore per ciascuna dimensione. A ciascun evento primario è associato un evento per ciascuna misura. Con riferimento alle vendite, un possibile evento primario registra per esempio che: in data 10/10/2017, nel negozio “NuovaFrontiera” sono state vendute 10 confezioni di detersivo “Brillo” per un incasso complessivo di 25 euro.

Una gerarchia è un albero direzionato i cui nodi sono attributi dimensionali e i cui archi modellano associazioni molti-a-uno tra coppie di attributi dimensionali. È importante non confondere il concetto di gerarchia esistente nei dimensional fact model con quella esistente negli schemi ER, nel contesto della modellazione multidimensionale la gerarchia si riferisce a legami associativi di varia natura.

Sistemi Informativi – Dimensional Fact Model
Sistemi Informativi – Dimensional Fact Model

Dato un insieme di attributi dimensionali (che in genere appartengono a gerarchie distinte), ciascuna ennupla dei loro valori individua un evento secondario che aggrega tutti gli eventi primari corrispondenti. A ciascun evento secondario è associato un valore per ciascuna misura, che riassume in sé tutti i valori della stessa misura negli eventi primari corrispondenti. Ad esempio tutte le vendite possono essere raggruppate a seconda della categoria dei prodotti venduti.

Convenzioni

Tutti i nomi degli attributi dimensionali di uno schema di fatto devono essere univoci. Eventuali nomi uguali devono essere differenziati qualificandoli con il nome di un attributo dimensionale che li precede nella gerarchia, ad esempio: città del negozio e città della marca. Ogni arco della gerarchia modella una dipendenza funzionale.

Aggregazione di eventi

Analizzare i dati al massimo livello di dettaglio risulta spesso impossibile o poco utile, risulta pertanto necessario aggregare gli eventi primari a diversi livelli di astrazione; se una data gerarchia non è interessante per l’analisi corrente, l’aggregazione viene effettuata su tutti i possibili valori che la corrispondente dimensione può assumere. Nella terminologia OLAP questa operazione viene detta di roll-up e il concetto chiave per definirla è quello di pattern (già trattato in precedenza).

L’aggregazione può avvenire su misure additive o su misure non additive, una misura è detta additiva su una dimensione se i suoi valori possono essere aggregati lungo la corrispondente gerarchia tramite l’operatore di somma, altrimenti è detta non-additiva. Una misura non-additiva è non-aggregabile se nessun operatore di aggregazione può essere usato su di essa.

Altri costrutti

In aggiunta a quelli elencati in precedenza un dimensional fact model può contenere un ulteriore insieme di costrutti, tra questi:

  • Attributi descrittivi;
  • Archi opzionali;
  • Archi multipli;
  • Convergenza;
  • Gerarchie condivise;
  • Gerarchie incomplete.
Attributo descrittivo

Un attributo descrittivo contiene informazioni aggiuntive su un attributo dimensionale di una gerarchia, a cui è connesso da un’associazione uno-a-uno. Tale attributo non è significativo per l’aggregazione. Ad un utente, ad esempio, potrà essere utile conoscere l’indirizzo fisico di ciascun negozio, tuttavia difficilmente sarà interessato ad aggregare le vendite a seconda dell’indirizzo del negozio che le ha eseguite.

Un attributo descrittivo specifica una proprietà di un attributo dimensionale di una gerarchia, pertanto è da quest’ultimo determinato tramite una dipendenza funzionale. Gli attributi descrittivi hanno spesso domini di valori continui, per questo motivo non possono essere utilizzati per l’aggregazione.

Sistemi Informativi – Esempio di attributo descrittivo
Sistemi Informativi – Esempio di attributo descrittivo
Archi opzionali

Alcuni archi dello schema di fatto possono essere opzionali, ovvero possono rappresentare associazioni non definite per un sottoinsieme di eventi. L’opzionalità viene impiegata per modellare situazioni in cui un’associazione rappresentata nello schema di fatto non è definita per un sottoinsieme di eventi. Gli archi opzionali sono rappresentati per mezzo di archi attraversati da un trattino.

Sistemi Informativi – Esempio di arco opzionale
Sistemi Informativi – Esempio di arco opzionale
Archi multipli

Esistono dei casi in cui è utile (se non necessario) includere attributi che in corrispondenza di un singolo valore assunto dall’attributo padre possono assumere valori multipli. Consideriamo lo schema di fatto che modella le vendite di libri in una libreria. Le dimensioni di interesse in questo caso sono la data e il libro in questione. Sarebbe sicuramente utile aggregare e selezionare le vendite sulla base degli autori dei libri venduti, tuttavia, poiché molti libri sono scritti da più autori, non sarebbe corretto modellare autore come attributo dimensionale figlio di libro. In questi casi si tende ad utilizzare la notazione dell’arco multiplo.

Convergenza

Due attributi dimensionali possono essere connessi da più cammini direzionati distinti, ciascuno dei quali rappresenta una dipendenza funzionale. Il concetto di convergenza riguarda la struttura delle gerarchie, di fatto queste possono non essere “veri alberi”, due attributi dimensionali possono essere connessi da due o più cammini direzionali distinti, a patto che ciascuno di essi rappresenti ancora una dipendenza funzionale.

Si consideri la gerarchia geografica su negozio: i negozi sono raggruppati in città, che a loro volta sono raggruppati in regioni e in stati. Si supponga anche che i negozi siano raggruppabili anche in distretti di vendita, e che tali distretti non siano includibili al di sotto delle città o delle regioni ma che facciano parte dei vari stati.

Gerarchie condivise

Una gerarchia condivisa viene utilizzata per condividere uno o più attributi comuni. Accade spesso che intere porzioni di gerarchie vengano replicate due o più volte. Si ritiene pertanto consigliabile l’introduzione di una notazione grafica abbreviata che enfatizzi la condivisione delle gerarchie, anche nell’ottica di permettere l’adozione di soluzioni ad hoc nella fase di progettazione logica.

Sistemi Informativi – Esempio di gerarchia condivisa
Sistemi Informativi – Esempio di gerarchia condivisa
Gerarchie incomplete

Abbiamo finora dato per scontato che, per ogni valore di a_i (attributo), esista esattamente un valore per ciascuno degli altri attributi del percorso. Ci sono però situazioni, non poco frequenti, in cui questa assunzione cade. Consideriamo ad esempio la gerarchia (comune, provincia, regione e nazione) e due nazioni a noi vicine: la Repubblica di San Marino e la Città del Vaticano per le quali non è definita alcuna scomposizione in regioni o province (o in comuni, come nel caso del Vaticano).

Chiamiamo gerarchia incompleta una gerarchia in cui, per alcune istanze, risultano assenti uno o più livelli di aggregazione.

Passi per la progettazione concettuale

La progettazione concettuale di un data mart secondo il dimensional fact model viene effettuata a partire dalle sorgenti operazionali. Durante la progettazione vengono prima definiti i diversi fatti e successivamente, per ogni fatto, vengono svolte alcune operazioni:

  • Costruzione di un albero degli attributi;
  • Editing dell’albero degli attributi;
  • Definizione delle dimensioni;
  • Definizione delle misure;
  • Creazione dello schema di fatto.

La definizione dei fatti è centrale nel processo di progettazione concettuale, come abbiamo avuto già modo di vedere i fatti sono concetti di interesse primario per il processo decisionale. Tipicamente essi corrispondono a eventi che accadono dinamicamente nel mondo aziendale. Nello schema ER un fatto può corrispondere ad un’entità F o ad un’associazione n-aria R tra le entità E_1 , E_2 \dots , E_n (che conviene trasformare in entità mediante reificazione).

In generale le entità, o relazioni, che rappresentano archivi frequentemente modificati (come l’insieme delle vendite) sono buoni candidati per definire fatti, quelli che rappresentano archivi quasi-statici (come il negozio o la città) invece no.

Una volta completata la definizione dei fatti si passa alla creazione dell’albero degli attributi. Data una porzione di schema ER di interesse e una sua entità designata come fatto F , l’albero degli attributi è un albero in cui:

  • La radice corrisponde all’identificatore di F ;
  • Ogni vertice corrisponde a un attributo (semplice o composto) dello schema sorgente;
  • Per ogni vertice v , il corrispondente attributo determina funzionalmente tutti gli attributi corrispondenti ai discendenti di v .

L’albero degli attributi corrispondente a F può essere costruito in modo automatico applicando una procedura che naviga ricorsivamente le dipendenze funzionali espresse nello schema sorgente dagli identificatori e dalle associazioni “a-uno”. Per ogni entità E esaminata si crea nell’albero un vertice v corrispondente all’identificatore di E e si aggiunge un vertice figlio per ogni altro attributo di E .

In genere non tutti gli attributi dell’albero sono d’interesse per il data mart, quindi durante la fase di editing l’albero può essere manipolato per eliminare i livelli di dettaglio non necessari. Nello specifico:

  • La potatura di un vertice v si effettua eliminando l’intero sottoalbero con radice in v . Gli attributi eliminati non saranno inclusi nello schema di fatto, quindi non potranno essere utilizzati per aggregare i dati;
  • L’innesto viene utilizzato quando, sebbene un vertice esprima un’informazione non interessante, è necessario mantenere nell’albero i suoi discendenti. L’innesto del vertice v , con padre v^, , viene effettuato collegando tutti i figli di v direttamente a v^, ed eliminando v . Come risultato verrà perduto il livello di aggregazione corrispondente all’attributo v ma non i livelli corrispondenti ai suoi discendenti.

Le dimensioni devono essere scelte nell’albero degli attributi tra i vertici figli della radice (fase di definizione delle dimensioni). Esse possono corrispondere ad attributi discreti o ad intervalli di valori di attributi discreti o continui. La loro scelta è cruciale per il progetto poiché definisce la granularità degli eventi primari. Ciascun evento primario riassume tutte le istanze di F corrispondenti a una combinazione di valori delle dimensioni.

Se tra le dimensioni compaiono tutti gli attributi che costituiscono l’identificatore di F , ogni evento primario corrisponderà a un’istanza di F . Se qualche attributo dell’identificatore di F viene potato/innestato, ciascun evento primario potrà corrispondere a più istanze di F .

Il tempo è un fattore chiave nei sistemi di data warehouse e corrisponde a una dimensione:

  • Se la sorgente è uno schema storico, il tempo è rappresentato esplicitamente come un attributo. Se appare nell’albero degli attributi come figlio di un vertice diverso dalla radice, si può effettuare un innesto o eliminare una dipendenza funzionale al fine di farlo diventare un figlio diretto della radice e quindi una dimensione;
  • Nelle sorgenti snapshot il tempo non viene rappresentato esplicitamente. In questi casi il tempo viene tipicamente aggiunto “manualmente” allo schema di fatto.

Infine, nella fase di creazione dello schema di fatto, l’albero degli attributi viene tradotto in uno schema di fatto che include le dimensioni e le misure definite:

  • Le gerarchie corrispondono ai sottoalberi dell’albero degli attributi con radice nelle diverse dimensioni;
  • Il nome del fatto corrisponde al nome dell’entità scelta come fatto;
  • È possibile potare e innestare l’albero per eliminare dettagli inutili;
  • È possibile aggiungere attributi dimensionali definendo opportuni intervalli per attributi numerici (ad esempio sulla dimensione tempo);
  • Gli attributi che non verranno usati per l’aggregazione possono essere contrassegnati come descrittivi. Tra questi compariranno in genere anche gli attributi determinati da associazioni uno-a-uno e privi di discendenti;
  • Per quanto riguarda eventuali attributi alfanumerici figli della radice ma non prescelti né come dimensioni né come misure: se la granularità degli eventi primari coincide con quella dell’entità F , essi possono essere rappresentati come attributi descrittivi associati direttamente al fatto di cui descriveranno ciascuna occorrenza; se invece le due granularità sono differenti essi dovranno necessariamente essere potati.

In questa fase devono anche essere identificate le eventuali non additività e non-aggregabilità presenti nello schema, considerando tutte le accoppiate dimensione-misura.

Esempi di conversione di diagrammi ER in schemi concettuali di tipo DFM: Esempio 1, Esempio 2