Come creare la tabella di cronologia?

Question

Ho alcune entità nel mio data warehouse:

.

1. Persona - Con Attributi Personid, Datedrom, Dateto e altri quelli possono essere modificati, ad es. Cognome, data della nascita e così via - Dimensione mutevole della lentamente

2. Documento - DocumentID, Numero, Tipo

3. Indirizzo - Addressid, City, Street, House, Flat

Le relazioni tra (persona e documento) sono uno-a-molti e (persona e indirizzo) è molte-a-molti.

Il mio obiettivo è quello di creare la tabella di fatto della cronologia che può rispondere alle seguenti domande:

.
1. Quali persone con quali documenti vissero all'indirizzo definito sulla data definita?

2, quale storia dei residenti ha definito l'indirizzo ha su intervallo di tempo definito?

Questo non è solo per ciò che DW è progettato, ma penso che sia la cosa più difficile nel design di DW.

Ad esempio, Miss Brown con Personid= 1, documenti con DocumentID= 1 e DocumentID= 2 erano stati vissuti all'indirizzo con ArdiniD= 1 dal 01/01/01/2005 al 02/02/2010 e quindi spostati in AddressID= 2 dove è stato vissuto dal 02/03/2010 alla data corrente (null?). Ma aveva cambiato cognome con la signora Green dal 04/05/2006 e il suo primo documento con DocumentID= 1 a DocumentID= 3 dal 06/07/2007. Mr Black With Personid= 2, DocumentID= 4 è stato vissuto a AddressID= 1 dal 02/03/2010 alla data corrente.

Il risultato atteso sulla nostra query per la domanda 2 dove AddressID= 1 e intervallo di tempo è dal 01/01/2000 A ora, deve essere come:

Righe:

last_name="Brown", documentId=1, dateFrom=01/01/2005, dateTo=04/04/2006

last_name="Brown", documentId=2, dateFrom=01/01/2005, dateTo=04/04/2006

last_name="Green", documentId=1, dateFrom=04/05/2006, dateTo=06/06/2007

last_name="Green", documentId=2, dateFrom=04/05/2006, dateTo=06/06/2007

last_name="Green", documentId=2, dateFrom=06/07/2007, dateTo=02/01/2010

last_name="Green", documentId=3, dateFrom=06/07/2007, dateTo=02/01/2010

last_name="Black", documentId=4, dateFrom=02/03/2010, dateTo=NULL

.

Ho avuto un'idea per creare una tabella di fatto con il tasto composito (Personid, Documentid, Addressid, DateDend) ma non ho idea di come caricare questa tabella e quindi ottenere quel risultato atteso con questa struttura.

Sarò soddisfatto per qualsiasi aiuto!

Answer 1

Interrogazione interessante @ARGNIST!

Quindi per creare un linguaggio comune per il mio esempio, vuoi un

.
• Dimperson (PK= Kcperson, Suggatori chiave per persone uniche= Kperson, tipo 2 Dim)
• dimDocument (PK= KCDocument, Suggatori chiave per documenti unici= KDocument, tipo 2 Dim)
• Dimaddress (pk= kcaddress, suggerisci chiave per indirizzi unici= kaddress, tipo 2 dim)

Un collega ha scritto un breve blog sull'utilizzo di due tasti surrogato per spiegare il Dims sopra " Utilizzo di due tasti surrogato sulle dimensioni ".

aggiungerei sempre Dimdatato con PK nel modulo YYYYMMDD A qualsiasi data warehouse con colonne di attributo extra.

Allora avresti la tua tabella dei fatti come

.
• Facthistory (fks= kcperson, kperson, kcdocument, kdocument, kcperson, kperson, kdate) più qualsiasi misura adizionale.

Quindi aderire alla "KC" s puoi mostrare le informazioni sulla persona corrente / documento / dell'indirizzo. Se ti sei unito a "K" s puoi mostrare le informazioni sulla dimensione della persona storica / documento / indirizzo.

Il sottooscatto di questo è che questa tabella di fatto ha bisogno di una riga per ogni combinazione di ogni persona / documento / indirizzo / data. Ma è davvero un tavolo molto stretto, dal momento che il tavolo ha solo un numero di chiavi straniere.

Il vantaggio di questo è molto facile da interrogare per i tipi di domande che stavi chiedendo.

In alternativa, potresti avere la tua tabella dei fatti come

.
• Factoristoria (FKS= KCperson, Kperson, KCDocument, Kdocument, Kcperson, Kperson, Kdatefrom, Kdateto) più qualsiasi misura adizionale.

Questo è ovviamente molto più compatto, ma la query diventa più complessa. Potresti anche mettere una vista sulla tabella dei fatti per rendere più facile la richiestazione!

La scelta della soluzione dipende dalla frequenza del cambiamento dei dati. Sospetto che non cambierà questo rapidamente, quindi il design alternativo della tabella dei fatto potrebbe essere migliore.

Spero che ti aiuti.