Chiavi esterne della tabella dei fatti null?

Sono nuovo nel design del data mart e ho bisogno di chiarire alcuni concetti.

Ho letto un po 'sulla modellazione delle dimensioni in cui vedo che le tabelle dei fatti memorizzano i riferimenti di chiave esterna alle tabelle delle dimensioni.

Supponiamo ora di avere una tabella dimensionale numero di telefono e una tabella dimensionale phone_extension. (Queste tabelle hanno dettagli diversi a causa dei quali non riesco a combinarli)

A quanto ho capito, entrambe queste tabelle dimensionali avranno chiavi primarie intere per prestazioni migliori, e la tabella fact avrà la sua chiave primaria integer e memorizzerà anche i riferimenti di chiave esterna a queste tabelle dimensionali.

Ma supponiamo che io abbia una situazione in cui non tutti i numeri di telefono hanno un'estensione del telefono ad essi correlata. (alcuni numeri di telefono non devono avere un interno)

Per i numeri di telefono che hanno un interno, la tabella dei fatti avrebbe riferimenti di chiave esterna a entrambe le tabelle delle dimensioni, ma come posso catturare la situazione in cui ci sono solo numeri di telefono e nessun interno (e viceversa, cioè interno senza numeri di telefono) ?

Devo acquisire tali informazioni con il numero di telefono FK nella tabella dei fatti con valore e phone_extension chiave esterna null ?? O tali oggetti non correlati non sono di fatto registrati nelle tabelle?

Inoltre ho bisogno di generare un report di questo data mart. Quindi, inizio eseguendo una query sulla tabella dei fatti e recuperando i valori della chiave della dimensione o il report direttamente dalla tabella della dimensione?

Grazie per il tuo tempo a leggere questo !!
Apprezzo qualsiasi aiuto !!

È possibile lasciare l'FK in alcune tabelle delle dimensioni come NULL se tali dimensioni non sono note o non applicabili. Devi solo ricordare di utilizzare i join esterni quando esegui la query di report.

In alternativa, alcune persone creano un record di dimensione "none" e / o "n / a" per le dimensioni del data mart e quindi popolano gli FK della tabella dei fatti in modo che puntino a questi anziché utilizzare NULL. Alle persone che fanno questo piace questo approccio perché hanno un'avversione per i join esterni.

Le persone che usano NULL FK in realtà le tabelle di solito hanno una avversione per le persone che hanno una versione per i join esterni. ;) (in altre parole, questa è una questione stilistica che può generare guerre di religione)

Dico di fare quello che preferisci, ma scegli un approccio e seguilo con fervore.

Non mettere null nel magazzino o nei Mart.

Il magazzino dovrebbe essere ben normalizzato (almeno BCNF) e pertanto dovrebbe escludere i null. I valori null potrebbero essere conservati nelle tabelle di gestione temporanea se esistono nelle origini dati ma non dovrebbero essere necessari nel magazzino stesso.

I Marts dovrebbero essere progettati per supportare gli strumenti di presentazione e le query degli utenti. I null si limitano a ostacolare queste cose perché non vengono mai visualizzati e rendono le query degli utenti più complesse e soggette a errori, soprattutto nelle colonne di chiavi esterne che sono spesso soggette a join.

le chiavi delle dimensioni nei fatti non devono essere nulle e imho avere le dimensioni delle dimensioni per eliminare la necessità di join esterni a sinistra da parte di utenti finali, report, ecc. Tutti i carichi di fatti devono eseguire un join esterno a sinistra con la dimensione e impostare per default una chiave 0 o nessuna chiave e fallire. Meglio fallire che unire la dimensione e non avere idea di aver perso righe nel tuo fatto, fino a quando alcuni utenti non lo trovano (se mai dovesse succedere)

creare un record "n / a" nella dimensione phone_extension e collegarlo ad esso.

la mia regola di themb è l'unico valore nullable in un datamart dwh end è il fatto stesso, quindi funzioni aggregate come avg funzionano ancora.