Nei capitoli 7 e 8 il DFM è stato presentato come modello concettuale: prima nei suoi costrutti di base, poi nelle sue estensioni. Questo capitolo risponde alla domanda che quei capitoli lasciavano aperta: come si arriva, in pratica, da uno schema sorgente a uno schema di fatto? La risposta è una metodologia in cinque passi — scelta dei fatti, costruzione dell'albero degli attributi, editing, scelta di dimensioni e misure, creazione dello schema di fatto — che parte dalla documentazione del database riconciliato e produce, per ogni fatto, uno schema di fatto completo. È il cuore operativo della progettazione concettuale, e il punto di partenza obbligato per la progettazione logica del capitolo 11.
Mentre è universalmente riconosciuto che un data warehouse si appoggia sul modello multidimensionale, non c'è altrettanto accordo sulla metodologia di progetto concettuale. Il modello Entity/Relationship è molto diffuso nelle imprese come formalismo per la documentazione dei sistemi informativi relazionali, ma non può essere usato per modellare il DW: è nato per descrivere la realtà operazionale, non per rappresentare fatti, misure e gerarchie di aggregazione.
Alcuni progettisti di DW disegnano direttamente gli schemi a stella. È una tentazione comprensibile, ma concettualmente scorretta: uno schema a stella non è altro che uno schema relazionale, e racchiude pertanto solo la definizione di un insieme di relazioni e di vincoli di integrità. Disegnarlo «subito» significa saltare la fase concettuale e fissare prematuramente scelte che appartengono alla progettazione logica.
Il DFM è un modello concettuale grafico per data mart, pensato per: supportare efficacemente il progetto concettuale; creare un ambiente su cui formulare in modo intuitivo le interrogazioni dell'utente; permettere il dialogo tra progettista e utente finale per raffinare le specifiche dei requisiti; creare una piattaforma stabile da cui partire per il progetto logico (indipendentemente dal modello logico target); restituire una documentazione a posteriori 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 — gli stessi costrutti che il capitolo 7 ha definito e che qui vengono messi al lavoro dentro una procedura di progetto.
Le slide mostrano quattro esempi completi di «DFM in azione» — lauree universitarie, ordini e fatture, attività di un'azienda di consulenza, transazioni bancarie — che servono a fissare l'idea che ogni fatto di interesse aziendale produce un proprio schema di fatto. Li ritroverete come esercizi: la metodologia di questo capitolo è quella che permette di costruirli da zero.
Un fatto è un concetto di interesse per il processo decisionale; tipicamente modella un insieme di eventi che accadono nell'impresa (vendite, spedizioni, acquisti, …). È essenziale che un fatto abbia aspetti dinamici, ovvero evolva nel tempo. Una misura è una proprietà numerica di un fatto e ne descrive un aspetto quantitativo di interesse per l'analisi (ogni vendita è misurata dal suo incasso). Una dimensione è una proprietà con dominio finito di un fatto e ne descrive una coordinata di analisi (dimensioni tipiche per il fatto vendite sono prodotto, negozio, data).
Un fatto esprime un'associazione molti-a-molti tra le dimensioni: ogni combinazione di un prodotto, di un negozio e di una data individua una vendita, e a ciascuna vendita sono associati i valori delle misure. Con il termine generale attributi dimensionali si intendono le dimensioni e gli eventuali altri attributi, sempre a valori discreti, che le descrivono: un prodotto è descritto dal suo tipo, dalla categoria cui appartiene, dalla sua marca, dal reparto in cui è venduto.
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. Essa racchiude una dimensione, posta alla radice dell'albero, e tutti gli attributi dimensionali che la descrivono.
Il DFM non nasce dal nulla: ogni costrutto ha un corrispondente preciso nello schema E/R della sorgente, e questa corrispondenza è ciò che rende la costruzione dello schema di fatto un procedimento quasi meccanico. A ogni arco della gerarchia corrisponde un'associazione molti-a-uno dello schema E/R; a ogni attributo dimensionale corrisponde un attributo (o un identificatore) di un'entità; al fatto corrisponde un'entità o un'associazione n-aria; alle misure corrispondono attributi numerici dell'entità fatto.
| Costrutto DFM | Corrispondente nello schema E/R |
|---|---|
| Fatto | Entità F oppure associazione n-aria R tra entità |
| Misura | Attributo numerico di F (o di R) |
| Dimensione | Entità collegata a F da un'associazione molti-a-uno |
| Arco di gerarchia | Associazione molti-a-uno tra due entità |
| Attributo dimensionale | Attributo (o identificatore) di un'entità |
Questa corrispondenza è la chiave di tutto il capitolo: se ogni costrutto del DFM «sa» da dove viene nello schema sorgente, allora la costruzione dello schema di fatto può essere automatizzata — ed è esattamente ciò che fa il passo 2 della metodologia.
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 valore per ciascuna misura. Dato un insieme di attributi dimensionali (group-by set), ciascuna ennupla di loro valori individua un evento secondario che aggrega tutti gli eventi primari corrispondenti.
Con riferimento alle vendite, un possibile evento primario registra per esempio che, il 10/10/2001, nel negozio NonSoloPappa sono state vendute 10 confezioni di detersivo Brillo per un incasso complessivo pari a 25 euro. L'evento primario è quindi la riga più fine della fact table: una combinazione di valori delle dimensioni più un valore per ciascuna misura.
Le gerarchie definiscono il modo in cui gli eventi primari possono essere aggregati e selezionati significativamente per il processo decisionale. La dimensione in cui una gerarchia ha radice ne definisce la granularità più fine di aggregazione; agli altri attributi dimensionali corrispondono granularità via via crescenti. Per esempio, raggruppando per tipo di prodotto e mese si ottengono eventi secondari che riassumono tutti gli eventi primari di quel tipo in quel mese.
Il concetto di evento secondario è importante perché è ciò che le interrogazioni OLAP restituiscono: ogni cella di un cubo è un evento secondario. E la scelta delle dimensioni (passo 3 della metodologia) non è altro che la scelta del group-by set più fine che il data mart dovrà supportare.
L'aggregazione richiede di definire un operatore adatto per comporre i valori delle misure che caratterizzano gli eventi primari in valori da abbinare a ciascun evento secondario. Da questo punto di vista è possibile distinguere tre categorie di misure:
La categoria determina quali operatori di aggregazione hanno senso lungo le gerarchie temporali e non temporali:
| Gerarchie temporali | Gerarchie non temporali | |
|---|---|---|
| Misure di flusso | SUM, AVG, MIN, MAX | SUM, AVG, MIN, MAX |
| Misure di livello | AVG, MIN, MAX | SUM, AVG, MIN, MAX |
| Misure unitarie | AVG, MIN, MAX | AVG, MIN, MAX |
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.
L'esempio delle slide è l'INVENTARIO: la misura quantità ingresso è additiva su tutte le dimensioni (data, prodotto, magazzino), mentre il livello — una misura di livello, appunto — non è additivo sulla dimensione temporale: sommare i livelli di due giorni non dà il livello del periodo. Lungo la gerarchia temporale si usa AVG o MIN/MAX; lungo le gerarchie non temporali (prodotto, magazzino) la somma resta invece legittima, perché i livelli di prodotti diversi in magazzini diversi si sommano.
La domanda classica è: «data una misura, quali operatori di aggregazione ha senso usare lungo la gerarchia temporale?». La risposta si ricava dalla categoria: flusso → anche SUM; livello → AVG, MIN, MAX (mai SUM sul tempo); unitaria → AVG, MIN, MAX. Attenzione al caso del livello sulle gerarchie non temporali, dove la somma è ammessa: è il dettaglio che distingue chi ha capito la definizione da chi l'ha imparata a memoria.
Uno schema di fatto si dice vuoto se non ha misure. In questo caso il fatto registra solo il verificarsi di un evento: l'esempio delle slide è FREQUENZA, dove si registra che uno studente ha frequentato un corso in un semestre, senza alcuna quantità da sommare. La misura implicita è il conteggio (COUNT) delle occorrenze.
La natura degli eventi registrati distingue due tipologie di schema:
La scelta tra i due non è libera: uno schema transazionale è la soluzione migliore se, nel dominio applicativo, gli eventi sono misurati come «flussi» entranti e uscenti (delta), e non può essere adottato se gli eventi sono misurati come livelli, a meno che non sia possibile decomporli univocamente in flussi. Viceversa, uno schema istantaneo è la soluzione migliore se gli eventi sono misurati come livelli; può essere adottato anche quando gli eventi sono misurati come flussi, se è nota la funzione che compone i flussi per determinare i livelli — ma in questo caso può comportare perdita di informazione. In generale, la scelta dipende comunque anche dal carico di lavoro.
Avanzate i due processi e osservate come il livello di magazzino viene ricostruito nei due schemi.
Prima di entrare nei passi operativi, le slide distinguono due approcci alla progettazione concettuale, che differiscono per il punto di partenza:
Il progettista deve essere in grado di enucleare, dalle interviste condotte presso l'utente, un'indicazione precisa circa i fatti da rappresentare, le misure che li descrivono e le gerarchie attraverso cui aggregarli utilmente. Il problema del collegamento tra lo schema concettuale così determinato e le sorgenti operazionali viene affrontato in un secondo tempo.
È possibile definire lo schema concettuale in funzione della struttura delle sorgenti, evitando il complesso compito di stabilire il legame con esse a posteriori. Inoltre, è possibile derivare uno schema concettuale prototipale dagli schemi operazionali in modo pressoché automatico.
I due approcci non sono in competizione: il supply-driven è quello che rende possibile la costruzione automatica dell'albero degli attributi (passo 2), mentre il demand-driven è quello che garantisce che lo schema risponda davvero ai bisogni degli utenti. La metodologia delle slide li combina: si parte dalla documentazione del database riconciliato (supply) e si rifinisce il risultato sulla base dei requisiti raccolti nelle interviste (demand).
La progettazione concettuale viene effettuata a partire dalla documentazione relativa al database riconciliato: schemi E/R, schemi relazionali, schemi XML, e così via. I passi di progettazione sono:
I fatti sono concetti di interesse primario per il processo decisionale; tipicamente, corrispondono a eventi che accadono dinamicamente nel mondo aziendale.
Sullo schema E/R un fatto può corrispondere o a un'entità F o a un'associazione n-aria R tra le entità E₁, E₂, …, Eₙ. Sullo schema relazionale un fatto corrisponde a una relazione F. Il criterio pratico è la dinamicità: le entità o relazioni che rappresentano archivi frequentemente modificati (come VENDITA) sono buoni candidati per definire fatti; quelli che rappresentano archivi quasi-statici (come NEGOZIO e CITTÀ) no.
Nell'esempio delle vendite si sceglie come fatto l'associazione VENDITA, corrispondente alla relazione VENDITE: è l'archivio che cresce a ogni scontrino, con le misure quantità e prezzo unitario. Ogni fatto identificato diviene la radice di un nuovo schema: la scelta dei fatti determina quindi quanti schemi di fatto comporranno il data mart.
Un errore frequente è scegliere come fatto un'entità quasi-statica (per esempio NEGOZIO) perché «interessa analizzare i negozi». Il negozio è una dimensione, non un fatto: ciò che si analizza è l'andamento delle vendite per negozio. Se un concetto non evolve nel tempo, non ha aspetti dinamici, e quindi non è un fatto.
L'albero degli attributi è un albero in cui: ogni vertice corrisponde a un attributo — semplice o composto — dello schema sorgente; la radice corrisponde all'identificatore (chiave primaria) di F; per ogni vertice v, l'attributo corrispondente 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. È questo il cuore dell'approccio supply-driven: la struttura dello schema sorgente determina la struttura dell'albero, senza bisogno di intervento umano.
Nell'esempio delle vendite, la radice è la chiave composta prodotto + num. scontrino della relazione VENDITE. Da prodotto si raggiungono tipo, categoria, reparto, marca, dieta, peso, dimensione; da num. scontrino si raggiungono data e negozio, e da negozio città, regione, stato, distretto di vendita, responsabile delle vendite, indirizzo e telefono.
La costruzione automatica non è sempre lineare: lo schema sorgente può presentare situazioni che l'albero deve saper trattare. Le slide ne elencano cinque:
Il «taglio» della gerarchia merita un esempio concreto: nel ciclo TRASFERIMENTO–REPARTO–DIVISIONE–PERSONALE, si può decidere di tagliare l'arco che risale da PERSONALE a REPARTO, ottenendo un albero senza cicli. Il prezzo è che la gerarchia ricorsiva (chi è il responsabile di chi) viene rappresentata in modo semplificato; il vantaggio è che l'albero resta un albero e la traduzione logica resta uno schema a stella.
In genere non tutti gli attributi dell'albero sono d'interesse per il data mart; quindi l'albero può essere manipolato per eliminare i livelli di dettaglio non necessari. Le due operazioni fondamentali sono la potatura e l'innesto.
La potatura di un vertice v si effettua eliminando l'intero sottoalbero con radice in v: gli attributi eliminati non verranno inclusi nello schema di fatto, quindi non potranno essere usati per aggregare i dati. L'innesto viene utilizzato quando, sebbene un vertice esprima un'informazione non interessante, è necessario mantenere nell'albero i suoi discendenti: si collegano tutti i figli di v direttamente al padre v' e si elimina v; come risultato verrà perduto il livello di aggregazione corrispondente a v ma non i livelli corrispondenti ai suoi discendenti.
Due regole operative completano il quadro:
Nella pratica possono rendersi necessarie ulteriori manipolazioni: può essere necessario modificare radicalmente la struttura sostituendo il padre di un certo nodo (ciò corrisponde ad aggiungere o eliminare una dipendenza funzionale); in presenza di un'associazione uno-a-uno sono consigliabili due soluzioni — quando il vertice v determinato dall'associazione ha dei discendenti di interesse lo si elimina tramite innesto; quando v non ha discendenti di interesse lo si rappresenta come attributo descrittivo. In alcuni casi può convenire invertire i due nodi coinvolti.
Data la situazione descritta, scegliete l'operazione di editing corretta.
Le dimensioni devono essere scelte nell'albero degli attributi tra i vertici figli della radice; possono corrispondere ad attributi discreti o a intervalli di valori di attributi discreti o continui. La loro scelta è cruciale per il progetto poiché definisce la granularità degli eventi primari.
Nell'esempio delle vendite, i figli della radice sono prodotto e num. scontrino: si scelgono come dimensioni prodotto, negozio (raggiunto da num. scontrino) e data (anch'essa raggiunta da num. scontrino). La granularità degli eventi primari è quindi «una riga di VENDITE»: ogni combinazione prodotto–negozio–data.
Il tempo dovrebbe sempre essere una dimensione. Due casi:
In entrambi i casi, il significato che si dà alla dimensione tempo è quello di tempo di validità, inteso come l'istante in cui l'evento si è verificato nel mondo aziendale. Al tempo di transazione — l'istante in cui l'evento è stato memorizzato nel database — non viene data tipicamente importanza nei DW, non essendo considerato rilevante per il supporto decisionale.
Se tra le dimensioni compaiono tutti gli attributi che costituiscono un identificatore dell'entità fatto, allora le misure corrispondono ad attributi numerici figli della radice dell'albero. Nell'esempio delle vendite, le dimensioni prodotto, negozio e data coprono l'identificatore di VENDITE (prodotto + num. scontrino, con num. scontrino che determina negozio e data): le misure sono quindi quantità e prezzo unitario, i due attributi numerici figli della radice.
Altrimenti le misure si definiscono applicando, ad attributi numerici dell'albero, funzioni di aggregazione che operano su tutte le istanze di F corrispondenti a ciascun evento primario: somma, media, massimo, minimo di espressioni, oppure conteggio del numero di istanze di F. Qualora la granularità del fatto sia differente da quella dello schema sorgente, può essere utile definire più misure che aggregano lo stesso attributo tramite operatori diversi.
Il glossario delle slide per l'esempio delle vendite:
quantità venduta = SUM(VENDITA.quantità)
incasso = SUM(VENDITA.quantità * VENDITA.prezzoUnitario)
prezzo unitario = AVG(VENDITA.prezzoUnitario)
num. clienti = COUNT(*)Notate la differenza tra quantità venduta (somma di un attributo) e incasso (somma di un'espressione): entrambe sono misure di flusso, additive su tutte le dimensioni. Il prezzo unitario è invece una misura unitaria, non additiva: si aggrega con la media. Il num. clienti è un conteggio, definito per aggregazione perché la granularità del fatto (riga di VENDITE) non coincide con quella della sorgente (scontrino).
L'albero degli attributi può ora essere tradotto in uno schema di fatto che include le dimensioni e le misure definite:
Eventuali attributi cross-dimensionali e archi multipli possono essere evidenziati in questa fase. Identificare queste tipologie di attributi a partire dallo schema sorgente è complesso, poiché richiede di navigare anche le associazioni a-molti; per questo si preferisce definirli a partire dai requisiti utente e rappresentarli solo successivamente sullo schema di fatto. Due corrispondenze utili:
In questa fase devono anche essere identificate le eventuali non-additività e non-aggregabilità presenti nello schema, considerando tutte le accoppiate dimensione-misura. Dato uno schema di fatto n-dimensionale, per la dimensione dᵢ e la misura mⱼ la domanda da porsi sarà:
«Siano {val₁, …, valₖ} i valori assunti dalla misura mⱼ nei k eventi primari corrispondenti a k differenti valori presi dal dominio della dimensione dᵢ e da un valore prefissato di ciascuna delle altre n−1 dimensioni. Volendo caratterizzare complessivamente i k eventi con un unico valore di mⱼ, quali operatori di aggregazione ha senso utilizzare?»
La risposta si costruisce con la tabella della sezione 4: se per la coppia (dimensione, misura) l'unico operatore sensato non è la somma, la misura è non-additiva su quella dimensione; se nessun operatore ha senso, è non-aggregabile.
Data la situazione descritta, riconoscete il passo della metodologia che la riguarda.
Perché è nato per descrivere i sistemi informativi relazionali operazionali, non per rappresentare fatti, misure e gerarchie di aggregazione. Anche disegnare direttamente gli schemi a stella non è una soluzione concettuale: uno schema a stella non è altro che uno schema relazionale, e racchiude solo la definizione di un insieme di relazioni e di vincoli di integrità.
È un modello concettuale grafico per data mart, pensato per: supportare efficacemente il progetto concettuale; creare un ambiente su cui formulare in modo intuitivo le interrogazioni dell'utente; permettere il dialogo tra progettista e utente finale; creare una piattaforma stabile da cui partire per il progetto logico; restituire una documentazione a posteriori espressiva e non ambigua. La sua rappresentazione concettuale consiste in un insieme di schemi di fatto.
Un fatto è un concetto di interesse per il processo decisionale, tipicamente un insieme di eventi che accadono nell'impresa; deve avere aspetti dinamici. Una misura è una proprietà numerica di un fatto che ne descrive un aspetto quantitativo. Una dimensione è una proprietà con dominio finito di un fatto che ne descrive una coordinata di analisi. Un fatto esprime un'associazione molti-a-molti tra le dimensioni.
Un evento primario è una particolare occorrenza di un fatto, individuata da una ennupla con un valore per ciascuna dimensione, a cui è associato un valore per ciascuna misura. Dato un group-by set (insieme di attributi dimensionali), ciascuna ennupla di loro valori individua un evento secondario che aggrega tutti gli eventi primari corrispondenti. Le gerarchie definiscono il modo in cui gli eventi primari possono essere aggregati.
Misure di flusso (valutate in modo cumulativo a fine periodo: SUM, AVG, MIN, MAX su tutte le gerarchie), misure di livello (valutate in istanti particolari: AVG, MIN, MAX sulle gerarchie temporali, SUM ammessa su quelle non temporali), misure unitarie (espresse in termini relativi: AVG, MIN, MAX). Una misura è additiva su una dimensione se si aggrega con la somma; non-additiva altrimenti; non-aggregabile se nessun operatore ha senso.
Uno schema di fatto senza misure: il fatto registra solo il verificarsi di un evento. L'esempio è FREQUENZA (uno studente ha frequentato un corso in un semestre), dove la misura implicita è il conteggio (COUNT) delle occorrenze.
Uno schema transazionale registra singole transazioni o insiemi di transazioni in un intervallo di tempo, con misure prevalentemente di flusso; è la soluzione migliore se gli eventi sono misurati come flussi (delta). Uno schema istantaneo registra fotografie periodiche del fatto, con misure prevalentemente di livello; è la soluzione migliore se gli eventi sono misurati come livelli. La scelta dipende dal dominio applicativo e dal carico di lavoro.
Il demand-driven enuclea dalle interviste agli utenti fatti, misure e gerarchie, affrontando in un secondo tempo il collegamento con le sorgenti operazionali. Il supply-driven definisce lo schema concettuale in funzione della struttura delle sorgenti, evitando il legame a posteriori e permettendo di derivare uno schema prototipale in modo pressoché automatico.
Scelta dei fatti; poi, per ogni fatto: (1) costruzione di un albero degli attributi, (2) editing dell'albero, (3) scelta delle dimensioni, (4) scelta delle misure, (5) creazione dello schema di fatto. Si parte dalla documentazione del database riconciliato (schemi E/R, relazionali, XML, …).
I fatti sono concetti di interesse primario per il processo decisionale, tipicamente eventi che accadono dinamicamente. Sullo schema E/R un fatto corrisponde a un'entità F o a un'associazione n-aria R; sullo schema relazionale a una relazione F. Gli archivi frequentemente modificati (VENDITA) sono buoni candidati; gli archivi quasi-statici (NEGOZIO, CITTÀ) no. Ogni fatto diviene la radice di un nuovo schema.
È un albero in cui ogni vertice corrisponde a un attributo dello schema sorgente, la radice all'identificatore di F, e ogni vertice determina funzionalmente i suoi discendenti. Si costruisce in modo automatico navigando ricorsivamente le dipendenze funzionali espresse dagli identificatori e dalle associazioni a-uno. I problemi tipici sono: stessa entità raggiunta due volte (convergenza, gerarchia condivisa), cicli di associazioni molti-a-uno (gerarchie ricorsive o taglio), gerarchie di specializzazione, associazioni n-arie (solo le false n-arie), attributi composti (due livelli).
La potatura di un vertice v elimina l'intero sottoalbero con radice in v: gli attributi eliminati non saranno inclusi nello schema di fatto e non potranno essere usati per aggregare. L'innesto collega i figli di v direttamente al padre v' ed elimina v: si perde il livello di aggregazione di v ma non quelli dei suoi discendenti. Quando un vertice opzionale viene innestato, i suoi figli ereditano il trattino di opzionalità.
Le dimensioni si scelgono tra i vertici figli della radice dell'albero degli attributi; possono corrispondere ad attributi discreti o a intervalli di valori. La scelta è cruciale perché definisce la granularità degli eventi primari. Il tempo dovrebbe sempre essere una dimensione: nelle sorgenti storiche lo si rende figlio diretto della radice (innesto o eliminazione di una dipendenza funzionale); nelle sorgenti snapshot lo si aggiunge manualmente. Il significato è il tempo di validità, non quello di transazione.
Se tra le dimensioni compaiono tutti gli attributi che costituiscono un identificatore dell'entità fatto, le misure corrispondono ad attributi numerici figli della radice. Altrimenti si definiscono applicando funzioni di aggregazione (somma, media, massimo, minimo di espressioni, conteggio) ad attributi numerici dell'albero. Se la granularità del fatto differisce da quella della sorgente, può essere utile definire più misure che aggregano lo stesso attributo con operatori diversi.
L'albero degli attributi viene tradotto in uno schema di fatto: le gerarchie corrispondono ai sottoalberi con radice nelle dimensioni; il nome del fatto è quello dell'entità scelta; si possono potare e innestare dettagli, aggiungere attributi dimensionali per intervalli, contrassegnare come descrittivi gli attributi non usati per aggregare. Gli attributi alfanumerici figli della radice non prescelti diventano descrittivi del fatto se la granularità coincide, altrimenti vanno potati. In questa fase si evidenziano anche attributi cross-dimensionali e archi multipli e si identificano non-additività e non-aggregabilità.
Perché richiede di navigare anche le associazioni a-molti, mentre la costruzione automatica dell'albero naviga solo le associazioni a-uno. Per questo si preferisce definirli a partire dai requisiti utente e rappresentarli solo successivamente sullo schema di fatto. Un attributo cross-dimensionale corrisponde in genere a un attributo su un'associazione molti-a-molti R; un arco multiplo a un'associazione a-molti da un'entità E a un'entità G.