Data Model, più fact table in relazione uno a molti

[David Bianconi]

Ciao a tutti,
spero di aver postato nella sezione corretta!
Vorrei conoscere il vostro pare su questo caso, io posto la mie soluzioni (ne ho ipotizzate un paio) avrei piacere di conoscere la vostra opinione.

Il caso:

Supponiamo che in un Data Model esistano due tabelle dei fatti: RigheFatture e RigheOrdini.

Supponiamo anche che tra le due tabelle esista una relazione di 1 a molti (perché 1 riga della tabella RigheFatture potrebbe essere abbinata a N righe della tabella RigheOrdini ma 1 riga della tabella RigheOrdini punta al massimo ad 1 riga della tabella RigheFatture).

Come strutturare in modo corretto il Data Model per avere la possibilità di "vedere" quando un ordine è stato fatturato o di vedere, magari, quanti ordini si sono chiusi con una fattura (magari riepilogativa di più ordini)?

Soluzione nr.1: denormalizzazione della tabella RigheOrdini con inserimento anche dei dati relativi alla riga fattura a cui punta (un po' la soluzione che si può praticare con le tabelle RigheFattura e Fattura)

Soluzione nr.2: creazione di una tabella "tecnica" con il ruolo di dimensione composta dalla chiave primaria della tabella RigheFatture da collegare sia alla tabella RigheFatture che alla tabella RigheOrdini: questa seconda soluzione mi lascia perplesso perché tanto vale collegare la tabella RigheFatture alla tabella RigheOrdini (è che non mi faceva impazzire collegare due tabelle dei fatti anche se, alla fine, prendere solo la chiave primaria e collegarla ad entrambe le tabelle è un po' fare la stessa cosa).

Spero di essere riuscito a spiegarmi, in caso contrario fatemi sapere.

A presto e grazie a chi vorrà scervellarsi un po' insieme a me.

David

[Andrea90]

Ciao David Bianconi,

La tabella delle fatture rappresenta dunque un dato “aggregato” della tabella degli ordini? Cioè se la fattura X vale 300 ed è composta da 3 ordini avrai nella tabella ordini 3 righe da 100? (supponendo 3 ordini di ugual importo)... perché se così fosse allora mi verrebbe da dire che la misura presente nella tabella delle fatture non ti serve...pertanto porterei il numero fattura dentro alla tabella ordini .. e terrei la tabella fattura con i soli dati “anagrafici” (data, cliente, fornitore, causali, ecc ) da utilizzare nei report che andrai a creare.

Immagino che però il modello sia ben più complicato di come l’ho rappresentato

a presto,

Andrea

[Enrico Galli]

Ciao David Bianconi , grazie per l'argomento interessante. L'idea di denormalizzare la tabella Ordini è valida, come descritto anche nel libro che certamente avrai letto di F&R. C'è solo da stare attenti alle misure che eventualmente devono essere calcolate a livello fattura, che potrebbero diventare difficili da riprodurre nella versione denormalizzata. Ovviamente ogni singolo caso va studiato un po' a sé

[David Bianconi]

Grazie Andrea90 e Enrico Galli per la risposta, replico ad entrambi in un unico post perché le soluzioni che mi proponete sono compatibili e sono d'accordo.
Quanto alla soluzione di Andrea penso che sia corretta e mi pare equivalente a quella proposta da Enrico.
Infatti, spostare il numero di riga della fattura (chiave esterna) nella tabella delle righe ordini a mio modo di vedere è concettualmente equivalente a denormalizzare la tabella delle righe ordini includendo i campi della tabella righe fatture.
La differenza mi pare più formale che altro:
- nel primo caso faccio puntare una tabella dei fatti ad un'altra tabella dei fatti tramite una relazione che nel modello esisterà fisicamente
- nel secondo caso la tabella righe fatture potrebbe essere idealmente eliminata perché il suo contenuto verrebbe trasferito nelle righe della tabella RigheOrdini.
Istintivamente più piace più la seconda soluzione anche se non so dire se, in questo caso, non sia comunque ammissibile una relazione tra fatti (in fondo tra fatture e righe fatture mi sembra di capire che viene tranquillamente tollerata).
Probabilmente la soluzione di Andrea consente di non sprecare spazio di memoria (la riga fattura non viene replicata più volte in corrispondenza di ogni riga ordini che si riferisce ad essa) ma la soluzione di Enrico potrebbe essere più veloce perché non sarà necessario connettere i dati delle due tabelle che saranno già "fusi" in un'unica tabella

[Enrico Galli]

Le due soluzioni possono essere considerate equivalenti se le altre dimensioni sono collegate soltanto alla tabella ordini: se invece hai delle dimensioni collegate a una delle due fact, e altre dimensioni collegate all'altra fact, l'unico modo per utilizzarle insieme è quello di denormalizzare e fare un'unica fact. Oppure, ma come sai è pericolosissimo, attivare il filtro bidirezionale tra le due fact. Sconsigliato!

[David Bianconi]

Giusta osservazione.
A completamento, condividi che, pur mantenendo due tabelle dei fatti separate ed in relazione di uno a molti, se però ci fossero due porzioni concettualmente distinte del data model tali che:

- una serie di dimensioni punti (direttamente o indirettamente) esclusivamente alla tabella RigheFatture

- una seconda serie di dimensioni (dimensionidiverse da quelle che puntano a RigheFattura) punti (direttamente o indirettamente) esclusivamente alla tabella RigheOrdini

- le analisi (per convenzione stabilita a priori) coinvolgano, alternativamente ed in modo esclusivo, l'una o l'altra serie di dimensioni (no incroci tra i due gruppi di dimensioni) e, al più, utilizzino i dati delle due fact table (quella naturalmente collegata e quella "più lontana") che stanno in relazione tra loro senza "andare oltre" quella "più lontana"

allora il tutto può reggere anche nel caso in cui si attivi (magari solo tramite dax e all'occorrenza) una relazione bidirezionale tra le due fact table?

Spero di essere riuscito a spiegare cosa intendo, non era facilissimo rappresentarlo scrivendo

[Enrico Galli]

Ti sei spiegato bene, e direi che nella situazione da te descritta non c'è alcun bisogno del filtro bidirezionale, poiché questo servirebbe solo per far passare il filtro da una dimensione della fact ordini alla fact fatture facendo muovere il filtro in direzione contraria al flusso uno->molti tra le due fact. Ma se, come dici tu, sappiamo a priori che ciascuna dimensione deve filtrare solo e soltanto la "sua" fact, il tutto funzionerà anche mantenendo il filtro unidirezionale

[David Bianconi]

Sì, esatto, ma potrebbe darsi il caso che, provenendo dal "lato" del data model che punta agli ordini (RigheOrdini) potrei, (come hai già sottolineato già tu) voler filtrare le righe della tabella "RigheFattura". In quel caso devo poter usare la bidirezionale (in pratica mi comporto sempre come se il modello finisse con la seconda fact table, quella più lontana dalle dimensioni tempo per tempo utilizzate per l'analisi).
In questo senso mi sembra di aver ancora bisogno della relazione bidirezionale (peraltro, solo quando quando provengo dal "lato" degli ordini).
Possiamo convenire ?

[Enrico Galli]

Se provieni dal lato ordini, la "catena" si deve arrestare alla fact ordini, perché altrimenti torniamo alla situazione "pericolosa" in cui le misure della fact fatture vengono filtrate sia dalle proprie dimensioni, sia dalle dimensioni della fact ordini, e questo può dar luogo a risultati inattesi (e inattendibili). A chiosa del discorso: tutto si può fare se c'è piena consapevolezza e perfetta conoscenza dei propri dati, ma il modello in cui due fact vengono messe in relazione bidirezionale non farlo vedere ai nostri amici italo/americani perché rischi una mega-scoppola virtuale

[David Bianconi]

Hai ragione (e scusa se insisto ma mi piace potermi confrontare, qui con te e con voi del forum, poi, è un piacere) e proprio a questo proposito avevo parlato di relazioni bidirezionali da attivare tramite dax e non fisicamente previste nel modello come impostazione (così da circoscriverle a particolari misure ed avere pieno controllo su quello che accade).
Del resto quando ci sono più fact table che condividono dimensioni (mi ricordo il caso Vendite e Ordini con Prodotto a fare da dimensione condivisa) tutto fila liscio. Il problema, nel mio caso, è che si vorrebbe tenere presente la dinamica amministrativa che coinvolge la fatturazione agli ordini.
Si potrebbe condividere la tabella prodotto tra RigheOrdini e RigheFattura ma si perderebbe la cognizione di quando è stato fatturato cosa mentre io vorrei lavorare su questo punto.
Poi la soluzione che hai indicato (denormalizzazione della tabella RigheOrdini) è forse la soluzione più robusta dal punto di vista del data model.