Quali sono alcuni modi per implementare una relazione molti-a-molti in un data warehouse?

Le topologie dominanti della modellazione di Data Warehouse (Star, Snowflake) sono progettate tenendo conto delle relazioni uno-a-molti. La leggibilità, le prestazioni e la struttura delle query peggiorano gravemente di fronte a una relazione molti-a-molti in questi schemi di modellazione.

Quali sono alcuni modi per implementare una relazione molti-a-molti tra dimensioni o tra la tabella dei fatti e una dimensione in un data warehouse e quali compromessi infliggono per quanto riguarda la granularità necessaria e le prestazioni delle query?

Nella mia esperienza, una gerarchia ricorsiva è il modo più pratico per affrontarlo. Offre i seguenti vantaggi:

1. Profondità illimitata.
2. Compattezza.
3. Flessibilità.
4. Velocità.

Al contrario, richiede un tavolo extra per ogni livello di join "-to-many". Questo è hard coded e difficile da mantenere rispetto agli aggiornamenti dello schema.

Utilizzando gli indici filtrati, una grande tabella di join gerarchici può eseguire a velocità superiore rispetto alle tabelle dedicate. Il motivo è che ogni join è solo "genitore-figlio" rispetto a "per unire la tabella alla tabella dei dati". Quest'ultimo ha più indici da elaborare e archiviare.

Ho cercato di risolvere questo problema per molti anni. Di recente, questo è quello che mi è venuto in mente.

Alcuni scenari per le relazioni M: M in un modello di data warehouse

La maggior parte dei server OLAP e dei sistemi ROLAP hanno un mezzo per gestire le strutture di dati M: M ora, ma ci sono alcuni avvertimenti su cui dovrai prestare attenzione. Se si implementano relazioni M: M, è necessario tenere d'occhio il proprio livello di reporting e quali strumenti si desidera supportare.

Scenario 1: M: dimensione M su una tabella dei fatti

Un esempio di questo potrebbe essere più driver in una politica del motore. Se si aggiunge o rimuove un driver, la transazione di rettifica dei criteri potrebbe avere una relazione con un elenco di driver che cambia con la rettifica.

Opzione 1 - M: tabella bridge fatto-driver M Questo avrà un volume piuttosto grande di dati, poiché ha righe di driver x transazioni per un dato criterio. SSAS può utilizzare direttamente questa struttura di dati, ma è più lento eseguire una query tramite uno strumento ROLAP.

Se la relazione M: M si basa su entità specifiche della riga dei fatti (ad es. Conducenti su un'automobile), ciò potrebbe essere appropriato anche per uno strumento ROLAP, a condizione che lo strumento ROLAP supporti le relazioni M: M (ad es. L'utilizzo di contesti in Business Oggetti).

Opzione 2 - Tabella dimensionale "combinazioni" fittizia Se si sta mappando un elenco di codici comuni su una tabella dei fatti (ovvero le entità collegate non sono peculiari della riga dei fatti), è possibile adottare un altro approccio che ridurrà i volumi di dati. Un esempio di questo tipo di scenario sono i codici ICD in visita ambulatoriale. Ogni visita ospedaliera avrà una o più diagnosi ICD e / o procedure elencate contro di essa. I codici ICD sono globali.

In questo caso, puoi creare un elenco distinto delle combinazioni di codici su ciascun caso. Creare una tabella delle dimensioni con una riga per ogni combinazione distinta e disporre di una tabella dei collegamenti tra le combinazioni e le tabelle di riferimento per i codici ICD stessi.

La tabella dei fatti può avere una chiave di dimensione per la dimensione "combinazioni" e la riga di dimensione ha un elenco di riferimenti a codici ICD effettivi. La maggior parte degli strumenti ROLAP può utilizzare questa struttura di dati. Se il tuo strumento funziona solo con una relazione M: M effettiva, puoi creare una vista che emula la relazione M: M tra il fatto e la tabella di riferimento di codifica. Questo sarebbe l'approccio preferito con SSAS.

Vantaggi dell'opzione 1: - Le query opportunamente indicizzate basate sulla selezione delle righe della tabella dei fatti con una certa relazione attraverso la tabella M: M possono essere ragionevolmente efficienti.

• Modello concettuale leggermente più semplice

Vantaggi dell'opzione 2: - L'archiviazione dei dati è più compatta

• È possibile emulare una relazione 1: M diretta presentando le combinazioni in un formato leggibile come un codice sulla dimensione "combinazioni". Ciò potrebbe essere più utile sugli strumenti di reporting più stupidi che non supportano le relazioni M: M.

Scenario 2: relazione M: M tra dimensioni:

Più difficile pensare a un caso d'uso, ma si potrebbe prevedere di nuovo qualcosa fuori dall'assistenza sanitaria con i codici ICD. Su un sistema di analisi dei costi, la visita ospedaliera può diventare una dimensione e avrà relazioni M: M tra la visita (o episodio di consulente in NHS-talk) e le codifiche.

In questo caso è possibile impostare le relazioni M: M ed eventualmente codificare un rendering leggibile dall'uomo sulla dimensione di base. Le relazioni possono essere fatte tramite tabelle di collegamenti M: M diritte o tramite una tabella "combinazioni" di bridge come prima. Questa struttura di dati può essere interrogata correttamente tramite Business Objects o strumenti ROLAP di migliore qualità.

Dalla parte superiore della mia testa, non riesco a vedere SSAS che è in grado di consumarlo senza prendere la relazione fino alla tabella dei fatti, quindi dovresti presentare una vista della relazione M: M tra la codifica e la tabella dei fatti righe per utilizzare SSAS con questi dati.

Vorrei sapere esattamente che tipo di relazione molti-a-molti hai in mente nel tuo modello, sia come è nel sistema transazionale o qualunque sia il modello di dati in cui si trova attualmente.

In genere, le relazioni molti-a-molti tra dimensioni sono fatti relativi alle dimensioni. Il fatto che un cliente ordini da diverse filiali che servono molti clienti o qualcosa del genere. Ognuno di questi è un dato di fatto. Avrebbe una data effettiva o qualcosa del genere, ma la relazione potrebbe essere "senza fatti". La relazione stessa può avere altre dimensioni oltre al cliente e alla filiale. Quindi è un tipico schema a stella con una tabella dei fatti (potenzialmente senza fatti) al centro. Il modo in cui questa stella può relazionarsi con altre stelle dimensionali nel magazzino dipenderà ovviamente. Ogni volta che combini stelle diverse, lo faresti con le chiavi aziendali e devi assicurarti di non eseguire un cross-join involontario.

In genere non si fa riferimento a tali tabelle di relazioni dimensionali allo stesso modo delle tabelle dei fatti più grandi e quando lo fanno, non sono sempre tanti dati, quindi non tendono a influire sulle prestazioni. Nel caso sopra, potresti considerare l'utilizzo del cliente / filiale nel tempo, ma dati migliori sulle quantità effettive degli ordini sarebbero disponibili nella tabella dei fatti dell'ordine, che presumibilmente avrebbe anche dimensioni per il cliente, la filiale, ecc. Questi non sono ciò che la maggior parte delle persone prenderebbe in considerazione il numero molti (anche se un ordine potrebbe definire una relazione molti-a-molti dal cliente alla filiale), quindi sono più tipici negli ambienti di data warehouse. Faresti aggregati numerici su modelli molti-a-molti se avessi arrotolato le informazioni di riepilogo a quel livello di relazione, ad esempio cliente, filiale, mese,

Ecco alcuni articoli rilevanti di Kimball e altri che possono applicarsi alla modellazione di una data relazione molti-a-molti proposta. Si noti che una relazione molti-a-molti è un concetto solo nel dominio problematico / modello logico. In un modello OLTP normalizzato verrebbe comunque gestito con una tabella di collegamenti che è, ovviamente, una a più in ciascun modo. In un modello non normalizzato di data warehouse Kimball ci sono diversi modi per farlo, uno dei quali tratta sostanzialmente quella tabella di collegamento come il fatto al centro di una stella. Un altro è come una matrice di colonne di bandiera.

In definitiva, la scelta dipenderà esattamente da cosa stai modellando, come sta cambiando e come vuoi riferire su di esso. È qui che la modellazione dimensionale e il data warehousing in generale differiscono nettamente dal modello normalizzato. Il modello normalizzato si concentra sulle relazioni logiche e teoriche nei dati, che il data warehousing tiene sempre d'occhio i casi d'uso realistici e denormalizza per renderli performanti.

Modellazione di gerarchie alternative utilizzando una tabella bridge:

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

Tre opzioni per una relazione da molte a molte (legata alle allocazioni di quote numeriche - vedere i commenti per alcuni interessanti avanti e indietro)

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

Sfortunatamente, molti articoli di Kimball sull'Information Week / DBMS non hanno più buoni collegamenti ...

Un modo per risolverlo è avere una tabella dei fatti con solo 2 colonne, di chiave esterna dalle 2 dimensioni con una nave di relazione da molte a molte.