De-normalizzare i dati in tempo reale a scopo di segnalazione - Buono o cattivo?

Question

Quali sono i pro/contro della de-normalizzazione di un database di applicazioni aziendali perché renderà più facili i report di scrittura?

Pro - progettare report in SSRS sarà probabilmente "più semplice" poiché non saranno necessari join.

Con - lo sviluppo/mantenimento dell'applicazione per gestire i dati non normalizzati diventerà più difficile a causa della duplicazione dei dati e della sincronizzazione.

Altri?

Answer 1

La denormalizzazione a fini di segnalazione è Bad, m'kay.

La creazione di viste o un data warehouse denormalizzato è buono.

Le viste hanno risolto la maggior parte dei miei bisogni relativi ai rapporti. I data warehouse sono eccezionali quando gli utenti generano i report quasi costantemente o quando le visualizzazioni iniziano a rallentare.

Questo è il motivo per cui si vuole normalizzare il database

1. per liberare la raccolta delle relazioni da indesiderabili dipendenze di inserimento, aggiornamento e cancellazione;
2. Per ridurre la necessità di ristrutturare la raccolta di relazioni quando vengono introdotti nuovi tipi di dati e quindi aumentare la durata dei programmi applicativi;
3. Per rendere il modello relazionale più informativo per gli utenti;
4. Per rendere la raccolta di relazioni neutrale rispetto alle query statistiche, dove queste statistiche possono cambiare col passare del tempo.

-E.F. Codd, "ulteriore normalizzazione del Data Base relazionale Modello" via wikipedia

Answer 2

L'unica volta che si deve considerare la de-normaliozazione è quando il tempo impiegato dal rapporto per generare non è accettabile. La de-normalizzazione causerà problemi di coerenza che a volte sono impossibili da determinare, specialmente nei dataset di grandi dimensioni

Answer 3

Un altro difetto è che i dati sono suscettibili di non essere in tempo reale, in quanto v'è un certo tempo si muove attorno ai dati di passare da una forma normalizzata per un de-normalizzato. Se qualcuno vuole che il rapporto sia all'altezza del secondo richiesto, ciò può essere difficile da fare in questa situazione.

Se si tratta di una duplicazione della sincronizzazione nel post originale, mi dispiace non l'ho visto in quel modo.

Answer 4

Non denormalizzare solo per eliminare la complessità dei rapporti, può causare enormi problemi nel resto dell'applicazione. O non si applicano le regole risultanti in dati errati o se lo si fa, quindi inserimenti, eliminazioni e aggiornamenti possono essere seriamente rallentati per tutti, non solo per le due o tre persone che eseguono i report.

Se i report non funzionano veramente bene, quindi creare un data warehouse denormalizzato e popolarlo in un feed notturno o settimanale. Il tipo di report che in genere richiedono questo tipo di solito non interessa se i dati sono aggiornati al minuto, in quanto sono di solito report mensili, trimestrali o annuali che elaborano (e soprattutto aggregano) grandi quantità di dati dopo il fatto.

Answer 5

Puoi fare entrambe le cose ...lascia il database normalizzato per le applicazioni. Quindi creare un database denormalizzato per i report e creare un'applicazione che regoli i dati di copia da un database all'altro.

Dopo tutto, i report non devono sempre disporre dei dati aggiornati più recenti, il più delle volte è possibile avviare facilmente un aggiornamento ogni 1 ora nel database di report e solo una volta al giorno.

Answer 6

Oltre il data warehouse e le soluzioni di visualizzazione fornite in altre risposte, che sono buone in qualche modo, se si è disposti a sacrificare alcune prestazioni per ottenere un buono all'ultimo secondo di dati, ma si desidera comunque un database normalizzato, è possibile utilizzare su Oracle una vista materializzata con aggiornamento rapido su commit, o in SQL Server, è possibile utilizzare gli indici cluster per una vista.