SCD di tipo II con entità che si fondono nel tempo

Question

Diciamo che abbiamo una dimensione che rappresenta gli uffici vendite. Gli uffici potrebbero spostarsi, il che sarebbe un cambiamento di tipo II. Vorremmo tenere traccia delle operazioni avvenute nel vecchio ufficio e delle operazioni che ora accadono nel nuovo, e sapere quando è avvenuto il cambiamento. Finora, solo il design di tipo II standard. Ora diciamo che un ufficio si fonde con un altro ufficio. Cioè, l'attività operativa di due uffici originariamente distinti (gli "uffici principali") si sta ora svolgendo in un unico ufficio (l '"ufficio unito"), che potrebbe essere una continuazione (fisica o di personale) di uno dei due degli uffici originali, o potrebbe essere un nuovo ufficio nel suo insieme, dal punto di vista del business, una continuazione dei due precedenti.

I requisiti/analisi di segnalazione sono i seguenti:

• Vogliamo essere in grado di vedere tutte le attività in corso per il nuovo ufficio unito.
• Vogliamo essere in grado di vedere tutte le attività che sono mai state fatte dall'ufficio unito o dagli uffici principali.
• Vogliamo essere in grado di vedere attività nel tempo che si sono svolte in uno degli uffici principali sia prima che dopo la fusione, senza visualizzare attività dall'altra sede principale (almeno prima della fusione).

io non sono sicuro di come modellare questo con qualsiasi tipo di SCD. Se sostituiamo semplicemente le due voci dell'ufficio principale con una singola nuova e aggiorniamo di conseguenza tutte le tabelle dei fatti, abbiamo un tipo I che cambia. Questo ci permette di vedere l'attività corrente bene, ma perdiamo la storia. Se teniamo separati i record, non sapremo della fusione. Se aggiungiamo un terzo record per rappresentare l'ufficio unito, perdiamo anche la cronologia (quale sarebbe la chiave naturale?) Né le chiavi naturali degli uffici parentali sarebbero adatte).

Devo utilizzare un bridge/tabella molti-a-molti? Ciò introduce complessità che vorrei evitare. Tuttavia, se questo è il modo migliore per farlo, allora così sia. Non sono ancora sicuro, tuttavia, di come sarebbe strutturato. Forse la tabella dei fatti indicherebbe un ingresso in ufficio, e gli uffici sarebbero raggruppati in modo molti-a-molti. La segnalazione verrebbe effettuata in base ai gruppi, anziché direttamente sulla dimensione dell'ufficio.

risposte alle domande della ElectricLlama

• interazione La maggior parte dell'utente avviene tramite rapporti in scatola, in modo che qualsiasi complessità della struttura sottostante verranno nascosti da loro.
• Alcuni utenti utilizzano SQL o SAS per ottenere i dati. Al momento, è improbabile che si preoccupino di questo specifico problema, ma questo potrebbe cambiare in quanto portiamo più utenti a bordo con questi strumenti.
• Non ci sono scrittori di query in questo frangente.
• Non credo che ci saranno fusioni multilivello, ma non posso dire definitivamente di no. Sarei sorpreso, però, se ci fossero.
• Non so come rendere questo tipo di cose facile per l'utente finale, il che potrebbe essere un argomento sufficiente per attenuare alcuni requisiti.

Answer 1

Preferirei la soluzione più semplice possibile che il cliente potesse accettare, quindi farei quanto segue. Vorrei fornire due campi ufficio nella dimensione ufficio:

1. Office_as_today
2. Office_original

(ovviamente dovete scegliere i nomi che sono buoni per il vostro cliente) Al via la due i campi sarebbero uguali. Quando due uffici si uniscono tornerei nei due uffici originali e aggiorno il campo Office_as_today, con il nome dell'ufficio unito.

I nuovi dati (dall'unione in poi) verranno registrati con una nuova riga con i due campi nuovamente uguali.

La soluzione è molto semplice e soddisfa quasi tutti i requisiti, con l'eccezione di non riuscire a seguire gli uffici originali dopo l'unione (qui sottolineo il "almeno").